Weer een Windows gerelateerde aanval dus. Leert men het dan nooit? Dat men een besturingssysteem voor lichte consumententoepassingen niet moet inzetten voor professioneel gebruik! Goed gereedschap is het halve werk en je ziet het professionele klusbedrijf toch ook niet langskomen met dat goedkope gereedschapssetje - met korting bij de Praxis gekocht - dat bij het eerste gebruik al uit elkaar valt.

ik lees toch echt: Dat is toch echt weer de zoveelste faal in het OSS evangelisme.
Zullen we eerst eens kijken welke normale beheersrichtlijnen ontbraken? Segmentatie, least privileges, DR, geen vinkenlijstje maar ook uitgewerkt en getest. Een IDS met IDR is ook iets. Er gebeurt in de nacht iets en wat was he echte eerste moment? Gangbaar verhaal: ze liepen al maanden rond.

Net als bij Desso en Tarkett gisteren ligt ook hier Het Active Directory Woud op zijn gat.
Ongetwijfeld zal Mohammed Saeed al-Sahhaf zo proberen dat het de zoveelste faal is in het OSS evangelisme dat deze (The services RUB Mail, Moodle, RUBCast, Zoom, Matrix (Riot) are currently still up and running.) systemen het nog doen.

RUB students and employees are advised to limit the usage of Windows-based applications to the most necessary communication processes, not to open any email attachments, and to send documents that need to be shared as PDFs.
The university also said that its administration systems are currently unavailable, as are e-mail services via the Exchange system." kennelijk hebben de studenten nog werkende endpoints.

Als je inderdaad iets niet goed neerzet, is het vragen op problemen. Tiering model, Minimale rechten, segmentatie en patching zijn de belangrijkste punten hierin. Maar daaraan wordt vaak al niet voldaan.

Hoe is het bijvoorbeeld mogelijk om domain admin rechten te krijgen? Dit zou in een goed neergezette omgeving nooit mogen gebeuren.

Doe dat niet, dan is het vragen om problemen. Zie de voorbeelden.

Sommige gaan dan preken, maar de rest snapt waar vaak exact waar en hoe de de issues in de omgeving zitten.

Leuke vraag zou zijn: https://www.security.nl/posting/656094/Datingsite+MobiFriends+lekt+gegevens+3%2C6+miljoen+gebruikers
Zal dit ook van een Windows omgeving afkomen?

"die mogelijk zijn getroffen" en "Tevens kregen alle faculteiten het advies om hun Windowsservers uit te schakelen."

wees niet verblind en concludeer niet dat deze getroffen servers OSS of iets anders zijn aangezien het toch vrij duidelijk benoemd wordt allemaal.

Ik zie het verband niet. Leg maar uit.

Alle windows systemen uit en de Linuxsystemen doen het nog. Gelukkig hebben ze DNS en DHCP blijkbaar niet onder windows draaien en geen koppeling met AD. https://news.rub.de/presseinformationen/servicemeldungen/2020-05-07-digitale-lehre-laeuft-weiter-cyber-angriff-auf-die-ruhr-universitaet-bochum.

Is helemaal geen goeie vraag. Je post in het verkeerde topic. De windows werkstations worden natuurlijk met domainrechten ge-patcht. Kwestie van geduldig sniffen en op zoek naar niet gepatchte windowsystemen. Schijnt koud kunstje te zijn gezien al die gevallen van de laatste dagen. De rest snapt inderdaad wat de issues zijn. Die kan je het beste vergelijken met een varend vergiet. Segmentatie etc helpt niet. malware floept ook van de ene naar de andere kant net als de gebruikers. Het enige wat helpt is goed gereedschap, een schip met compartimenten. Compartiment lek, betekent niet gelijk dat het schip zinkt. Voorbeelden genoeg ook bij Ruhr Universiteit Bochum en Maastricht.
Je kan niet steeds naar beheer wijzen wat MS ook graag doet. Daarvoor zijn de aantallen te groot en ook nog eens beheerd door het oligopolie zelf.

Wat zijn domain rechten? Maar Windows werkstations worden niet met specifieke domain rechten gepatched. Er zijn geen admin rechten nodig om Microsoft patches te installeren. En helemaal geen domain admin rechten of zo iets.

Naar? Als je het netwerk goed inricht is er verdomde weinig te sniffen.

Als je een machine niet patched is het natuurlijk vragen om problemen. Exact hetzelfde voor Linux of applicatie servers. Databases zijn altijd erg interessant.

De rest weet eigenlijk iedere keer direct, en uit eigenlijk alle voorbeelden die in het nieuws komen, de basismaatregelen niet geimplementeerd zijn.
Eigenlijk net zoals een Elasticsearch (PADI) zonder wachtwoord aan het Internet knopen => vragen om problemen.

Tiering, segmentatie en patching zijn waar het iedere keer op fout gaat.
Hoe kan het zijn dat een domain controller geïnfecteerd raakt. Met een goed basic tiering inrichting voorkom je dit al.
Hoe kan een domain admin gebruikt worden, voor standaard werkzaamheden en op een un secure werkstation of server?

Waarom zou een printer server admin, admin rechten moeten hebben met zijn (tier 1) account op een file server als hij daar nooit iets op hoeft te doen.
https://docs.microsoft.com/en-us/windows-server/identity/securing-privileged-access/securing-privileged-access-reference-material

Segmentatie is ook een belangrijke vervolgstap. Waarom zou een print server met een file server moeten communiceren? Of een DHCP server? En database server?

Waarom moeten werkstations onderling kunnen communiceren? Is dat een requirement? Waarom is dit noodzakelijk?

En patches is natuurlijk een no brainer.

Je spreekt jezelf trouwens ook tegen, segmentatie is compartimenten, juist zorgen dat services (of servers) niet onderling kunnen communiceren. Openzetten alleen op requirements.

Echt basis richting allemaal bij bedrijven.

Maastricht was een prachtig voorbeeld van unsupported unpatched Windows 2003 servers, waarop hele privileged accounts actief waren geweest. Prachtig voorbeeld, van hoe fout wil je het inrichten.
Dat is geen direct Microsoft probleem.

Als jij met domain admin rechten op een werkstation werkzaamheden uitvoert, dan ben je niet slim bezig.

En iedere keer gaat het in de basis fout. Standaard best practices worden niet doorgevoerd.
Updates worden niet geïnstalleerd.
Cached Credentials standaard geconfigureerd laten staan.
Segmentaties.

En eigenlijk iedere keer gaat het op dezelfde punten fout als je de informatie leest.

Maar hetzelfde kan je zeggen over alle databases die openstaan. De aantallen zijn te groot.

Ik zie het verband niet. Leg maar uit.[/quote]Backups, een SN beheren, privileged identity management een IDS IDR het heeft allemaal weinig met een OS te maken.
Je ziet wel dat OSS fanatici (OSS) een OS flaming voeren waardoor ze de oorzaak van slecht beheer zijn.

Backups, een SN beheren, privileged identity management een IDS IDR het heeft allemaal weinig met een OS te maken.
Je ziet wel dat OSS fanatici (OSS) een OS flaming voeren waardoor ze de oorzaak van slecht beheer zijn.[/quote]
laten we wel bij de les blijven; het gaat in bochum mis met de windows system nu en als dat aan het beheer van bochum ligt, dan is het onmodelik om dan de conclusie te trekken dat dat door OSS fanatici zou komen aangezien ze daar duidelijk een windows only toko zijn. kortom stop met trollen en ga weg.

@ Tintin and Milou
Dat AD administrative tier model klinkt leuk maar blijkbaar te ingewikkeld voor MKB+ naast dat patchen al veel te veel werk is.
Hoe vaak ik ook niet gezien heb dat om te kunnen printen een tier 0 of 1 domain account gebruikt wordt omdat anders de netwerktoegang naar de printer niet geregeld kan worden. Gepruts allemaal, natuurlijk maar het gebeurd omdat het kan. Firewalls op werkstations maakt eigenlijk niet zo veel uit. Het zijn de gebruikers zelf die de ellende onder win10 naar binnen harken (via advertenties) omdat MS het zo gemaakt heeft dat de dropper in geheugen default zelfs automatisch opgestart wordt, antivirus uitzet en de malware ophaalt en opstart om te scannen naar een kwetsbare server. Segmentatie vertraagt het proces alleen een beetje. Soms duurt het maanden voor het bingo is. Daarom is een goed monitoring systeem een must. Die MS tools (SCAP Microsoft System Center) zijn niet goed genoeg. Diverse open source is veel beter zoals checkmk/Grafana i.c.m. Tennable security center etc

Veel beter is om het te voorkomen (goed gereedschap is het halve werk). Daarom moet het gewoon niet mogelijk zijn om vanuit de user home en tmp directory een programma op te starten. Wat er allemaal in geheugen gebeurd met javascript etc is veel moeilijker. noscript en dat soort dingen zou ook kunnen helpen. javascript uitzetten is geen doen ivm de webapplicaties tegenwoordig.
Je leest nooit dat er ergens een LInux netwerk is gehackt. Dat komt omdat niemand een soort AD tier1 admin account gebruikt waarmee je op elke server kan inloggen.Hoewel het wel zou kunnen via IPA of zelfs AD via samba/winbind)
Verder wordt Root (admin) toegang op elke server ge-disabled eb password auth ook via het netwerk. Gebruikers hebben alleen toegang via two factor authenticatie (meestal ssh-keys met passphrase). De kunst is een gebruiker te vinden die sudo mag doen. Daarom kan je Admin onder windows ook beter disablen en een nieuwe naam verzinnen.

@ Tintin and Milou
Dat AD administrative tier model klinkt leuk maar blijkbaar (zie incidenten) te ingewikkeld voor MKB+ naast dat patchen al veel te veel werk is.
Hoe vaak ik ook niet gezien heb dat om te kunnen printen een tier 0 of 1 domain account gebruikt wordt omdat anders de netwerktoegang naar de printer niet geregeld kan worden. Gepruts allemaal, natuurlijk maar het gebeurd omdat het kan. Firewalls op werkstations maakt eigenlijk niet zo veel uit. Het zijn de gebruikers zelf die de ellende onder win10 naar binnen harken (via advertenties) omdat MS het zo gemaakt heeft dat de dropper in geheugen default zelfs automatisch opgestart wordt, antivirus uitzet en de malware ophaalt en opstart om te scannen naar een kwetsbare server. Segmentatie vertraagt het proces alleen een beetje. Soms duurt het maanden voor het bingo is. Daarom is een goed monitoring systeem een must. Die MS tools zijn niet goed genoeg. Diverse open source is veel beter zoals checkmk/Grafana i.c.m. Tennable security center etc

Veel beter is om het te voorkomen (goed gereedschap is het halve werk). Daarom moet het gewoon niet mogelijk zijn om vanuit de user home en tmp directory een programma op te starten. Wat er allemaal in geheugen gebeurd met javascript etc is veel moeilijker. noscript en dat soort dingen zou ook kunnen helpen. javascript uitzetten is geen doen ivm de webapplicaties tegenwoordig.
Je leest nooit dat er ergens een LInux netwerk is gehackt. Dat komt omdat niemand een soort AD tier1 admin account gebruikt waarmee je op elke server kan inloggen.Hoewel het wel zou kunnen via IPA of zelfs AD via samba/winbind)
Verder wordt Root (admin) toegang op elke server ge-disabled en password auth ook via het netwerk.
Gebruikers hebben alleen toegang via two factor authenticatie (meestal ssh-keys met passphrase). De kunst is een gebruiker te vinden die sudo mag doen. Daarom kan je Admin onder windows ook beter disablen en een nieuwe naam verzinnen.

. .

Mijn grootvader had een motorzaag. Na zijn overlijden is het ding bij ons terechtgekomen. Heb 'm als tiener nog eens helemaal uitelkaar gehaald en weer inelkaar gezet, leuk speelgoed. Nouja, speelgoed. Zoals alles bij mijn grootvader was ook dit ding een stukje ouder dan ikzelf, en zoals ze ze toen maakten, zo krijg je ze nu niet meer. Degelijke constructie, dat wel, maar tweetaktmotortje, zaagblad, ketting, handvat... en dat was het. Beschermkappen, noodstoppen, beveiliging? Die moesten nog uitgevonden worden toen dit ding gemaakt werd. Ze zijn tegenwoordig allemaal standaard op alle kettingzagen die je nu kopen kan, en dat ze standaard geworden zijn is allemaal in bloed en beenderen betaald. Je weet wel, kettingzaag in je been, voet kwijt, dat werk. Dat heet dan voortschrijdend inzicht.

Wat ik hier en elders in de "cyber security industry" zie, heeft veel weg van mensen die kettingzagen zoals die van mijn opa verdedigen met "dan moet je je maar aan de best practices houden!" En wat zijn die "best practices" dan? "Niet op die email klikken!" Dat is goed advies, net zo goed als "niet in je been zagen!" Ja en toch he, en toch is dat niet genoeg, getuige de beschermkappen, de noodstoppen, de verdere bescherming op de moderne versie van het apparaat zelf, plus de beschermende kleding die de professional er nog steeds omheen draagt. Want wat je ook doet, een kettingzaag kan je enorm naar te pakken nemen als er, weetikhet, ineens een knoet of een steen opduiken, of de stam rot is zodat je erdoorheen schiet, of weetikhet.

Dat hele "best practices" verhaal is dus niet genoeg, want het apparaat, nouja het OS, zelf is verradelijk gevaarlijk. Ondanks dat het leuk aangekleed is met lachende hondjes en hulpvaardige paperclips en noem maar op. Net als dat een kettingzaag niet veiliger wordt als je er hello kitty stickers op plakt. Daar is meer voor nodig.

En op de een of andere manier heeft microsoft er problemen mee hier nuttige beveiligingen in te bouwen. Klein voorbeeldje: Ze verbergen nog steeds standaard de bestandsextensies in de windowsverkenner ondanks dat het hun eigen advies is dat toch maar niet te doen. Dat advies alleen al kostte ze enige tientallen jaren om uit te vogelen dus als ze het over tien jaar als standaard doorvoeren is het vroeg. Ik zou dus niet direct op ze durven bouwen als betrouwbare bron van goed advies. Maar daar gaat het nu niet eens om. Waar het wel om gaat is dit:

Waarom wel dat enorme gehamer op "best practices", bijvoorbeeld hier onder dit nieuwsbericht, terwijl de basis gewoon onveilig is, want verstoken van serieuze beveiligingen? Wat maakt het nou zo moeilijk te doen met een OS wat ondertussen wel gelukt is met moderne kettingzagen? Moet er eerst een zaagblad aan je laptop voordat we kunnen leren dat "niet op die email klikken!", "altijd een firewall gebruiken!", "altijd een virusscanner gebruiken!", "tijdig updaten hoor!" en andere van zulke "best practices" niet genoeg zijn als beveiliging?

Mooie metafoor! Die verrekte de bestandsextensies inderdaad ook zo iets. Van de week nog last van gehad met dat idiote Exchange. tekst bestand ge-attached (mail ~r file.txt) komt het aan in een .bin formaat! Of je renamed het in de verkenner plakt windows er nog een extentie ongezien achter. Wat een etterige troep allemaal.

Complimenten dit keer om je post. Goede onderbouwing en netjes neer gezet. Een goede discussie.

Mag ook gezegd worden.

Bij een hele kleine orginsatie kan je dit ook heel simpel versimpelen.
Gewoon een WKS Admin en een Server (domain) admin. Zorgen dat de domain admin nooit kan aanmelden op een werkstation. Kost minder dan een uurtje om te implementeren.
Wil je het iets uitgebreider doen, dan zorg je voor een apart account voor server beheer, waarmee je 95% van je werkzaamheden kunt uitvoeren. Kost ook iets van tussen de 1-8 uurtjes om in te richten.

Echt complex is dit dus niet.
Als je dit kan of wilt implementeren, dan kun je dit niet afschuiven op de leverancier.
Dit icm met LDAP en cached credentials caching lost al een heel hoop van de ellende bij veel bedrijven op.
En echt complex om te implementeren is het niet.

Alles kan inderdaad. Maar zoals overal het valt en staat met de inrichting. T1 account kan nodig zijn als je admin rechten op een server nodig hebt. Maar om op een firewall appliance in te loggen, zou een een ander dedicated firewall admin account moeten gebruiken.

Dat iets mogelijk is, wil niet zeggen dat het verstandig is.
Dat ligt ook niet aan de leverancier.

Mijn auto kan ook 200 rijden in de bebouwde kom, of dit nu verstandig is....
Op de Duitse autowegen mag ik dit zelfs legaal. Maar dat wil niet zeggen dat ik het ook goed kan. Het zal meestal wel goed gaan, maar ik heb niet veel ervaring hierin. Of het dus echt verstandig is om te doen....

Het is 1 punt vanuit beveiliging. Maar eigen zou je dit op switches moeten regelen, niet op een mogelijke gecompromitteerde client. Maar het is een onderdeel van een totaal oplossing. Zou niet mijn eerste focus zijn om aan te pakken.

Antivirus producten uitzetten is tegenwoordig al een stuk lastiger. Bij veel producten is niet echt niet meer mogelijk.
Drive by Download, komt ook niet zoveel meer voor. Het zijn voornamelijk marco's /scripts die binnen komen. Veel tegenwoordig via Email.

Het is ook niet de holy grail. Het is een onderdeel van de beveiligingen die je implementeert.

Klopt helemaal. Monitoring en logging zijn cruciaal. Maar nog complexer om te implementeren.Voor MKB eigenlijk niet te doen. Voor grote omgeving, zou dit een must moeten zijn.

Weten wat in je omgeving gebeurt.....

Ik denk dat het wel van belang is om een onderscheid te maken tussen een, zoals jij het noemt, drive by download aanval, of een professionele aanval.
Bij de eerste helpt een SIEM een stuk lastiger, maar bij een professionele aanval, kun je hiermee inderdaad veel meer zien, en eerder constateren.

Ik ga mij eens verdiepen in die tools die je noemt. Ik heb daar geen ervaring mee en zijn nieuwe namen voor mij.

Helemaal mee eens. Al verschillen we over wat goed gereedschap is ;-).

Klopt helemaal.


Als je het niet hoord, wil niet zeggen dat het niet gebeurt.
Ik kan je verzekeren dat het wel gebeurt. Ik mag er helaas niets over zeggen ivm NDA. Maar het gebeurt wel, maar een stuk minder.

Klopt, Linux heeft standaard geen centrale authenticatie oplossing. Dat is een voordeel, maar ook een nadeel. Rechten toekennen is een stuk lastiger. Ik kom nog heel vaak oude accounts tegen op Linux server van beheerders die al lang weg zijn, of iets anders doen.

Als mijn private key gecompromitteerd is, heb ik best een hoop werk om deze op alle servers in te trekken. Als ik al weet, op welke servers deze allemaal actief is.

We hebben hier een speciale applicatie ontwikkeld die het allemaal centraal verwerkt op alle servers over al onze klanten. Ziet er goed uit. Maar lokale accounts blijven een probleem.

Het is een voor en nadeel.

Dit is inderdaad een hele mooie oplossing van SSH en werkt heel goed. Nadeel is wel, als je private key gecompromitteerd, moet je wel weten op welke servers je de public key moet verwijderen. En daar mis je standaard een stukje centrale management. Zeker als snelheid van belang is. Hoe vaak komen we niet gepatchte servers tegen omdat we niet meer wisten dat die bestonden?
Juist een voordeel van AD, is dat ik heel gemakkelijk met 1 klik het account dan disablen of een wachtwoord reset kan uitvoeren. Binnen seconden actief in het hele netwerk.

Maar ook hier wel, ieder voordeel heeft een nadeel.

Andere naam is security by obscurity. Kost een hacker echt maar een paar seconden extra.
Disablen is een maatregel, maar icm met LDAP https://www.microsoft.com/en-us/download/details.aspx?id=46899 is een veel betere oplossing. En ook vrij gemakkelijk te implementeren.

@ Tintin and Milou
Bedankt voor je uitgebreide vriendelijke commentaar :)

Ik vond AD altijd wel een complex systeem met machines users services en policies die deel uitmaken van verschillende DNS domains. Ik zal het niet over vroeger hebben want dan kan ik een heel boekwerk volschrijven. Het komt er op neer dat het mij niet is gelukt om het spul fail safe op te zetten zonder incidenten. Bij mij was AD verplicht in die tijd door compliance requirements. Heb diverse 3 party commerciële oplossingen geprobeerd zo als Likewise. Hiermee kon je ook group policies opzetten voor een Gnome desktop. Nu overgenomen door BeyondTrust dacht ik: https://github.com/BeyondTrust/pbis-open/

Dat is niet waar. Het ondersteunt meer centrale oplossingen dan windows omdat het zo makkelijk aanpasbaar is voor iedereen. Het is maar een kernel. Voor de rest ben je afhankelijk van een distro. Als grote onderneming kies je heel vaak voor een RedHat distro met in het kielzog CentOS of Suse Heeft te maken gegarandeerde support. Bij een Redhat installatie kan je kiezen voor een Security Policy gedefinieerd door een SCAP standaard ( https://www.open-scap.org )
Daarnaast zijn tools als Ansible heel krachtig om met 1 druk op de knop alles te kunnen doen. Wordt tegenwoordig ook hard aan gewerkt om windows te ondersteunen: https://www.ansible.com/integrations/infrastructure/windows
Als je voor RedHat kiest kom je automatisch in aanraking met IPA https://www.freeipa.org/page/Main_PageMet deze centrale oplossing kan je ook een mutual trust opzetten met AD. Interessante sheets: https://www.freeipa.org/images/1/1e/Devconf2013-linux-ad-integration-options.pdf
Verder zie je ook wel eens: Samba als een AD https://wiki.samba.org/index.php/Setting_up_Samba_as_an_Active_Directory_Domain_Controller

Dat hoef je niet te weten met Ansible. Als het goed is heb je een inventory met servers. Dan kan je met een playbook je inventory langs lopen en wordt de key er af gehaald als deze aanwezig is (werkt ook met windows): https://docs.ansible.com/ansible/latest/modules/authorized_key_module.html
Geldt ook voor (lokale) accounts etc.

Het stelen van private keys komt bijna niet voor. Linux desktop kom je namelijk niet op. Zijn erg stil op het netwerk en kan je ook gerust uit zich zelf automatisch laten patchen. Wel moet je zorgen dat email/web clients software niet automatisch attachments openen en executeren. Gelukkig heeft nog geen ontwerper die stommiteit uitgehaald. Thunderbird en evolution doen het goed.

aangaande ssh key management:

https://www.ssh.com/iam/ssh-key-management/

https://eprint.iacr.org/2018/389.pdf

SSH is inderdaad de global gold standaard voor remote system administration. MS heeft niet voor niks de bash shell toegevoegd als Windows Subsystem for Linux.

follow up;

in RHEL kun je openssh via sssd dmv een IdM (FreeIPA bijv) laten managen:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/linux_domain_identity_authentication_and_policy_guide/openssh-sssd

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/linux_domain_identity_authentication_and_policy_guide/host-keys

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/linux_domain_identity_authentication_and_policy_guide/user-keys


Maar het kan natuurlijk ook anders allemaal.