Jammer dat in het Fox-it rapport sommige delen zijn afgelakt.
Maar dat zal wel een goede reden hebben denk ik.

Dank voor het delen.

De mens is de zwakste schakel, daarna komt het OS pas. :)

Ik weet van mensen die niet alleen zichzelf compartimenteren (segmenteren), maar zeker ook het OS. In feite compartimenteer je alles wat te compartimenteren valt. Dat begint met de keuze van het OS, de keuze van de machine om mail op te halen, de wijze van mail ophalen, de training van de gebruiker.

Je kunt zelfs de keuze van de machine zo opdelen, dat je voor e-mail ophalen een andere computer gebruikt dan de computer die aangesloten is op het netwerk dat interessant is voor hackers. Hierdoor is penetratie van het doelnetwerk via een phishingmail vrijwel nihil. De compartimenteringstechniek kan je dus in elke geleding van de gebruiker, de machine, het OS, de rechten, de monitoring van het netwerk op illegale acties, etc doorvoeren.

Het wordt voor cybercriminelen dan uiterst lastig om de zaak helemaal over te nemen, zo leert althans de ervaring.

@TS: dank voor de links!

In https://security.nl/posting/642671 beargumenteer ik dat je meer kunt (en m.i. zou moeten) doen dan proberen de "mens-kwetsbaarheid"aan te pakken. Er bestaan volgens mij geen eenvoudige en/of enkelvoudige oplossingen die redelijk effectief zijn.

Ook vraag ik mij daarin hardop af waarom UNIMAAS 287 Windows servers had/heeft.

Ik ben zeer benieuwd of er nog extractie van data heeft plaatsgevonden uit de zgn. kroonjuwelen.

Mijn aanname is, nee, de criminelen zijn daar niet in geïnteresseerd. Die informatie is weliswaar gevoelig en onvrijwillige publicatie er van is ongewenst, maar criminelen zullen daar geen financieel gewin uit kunnen peuren.

De mens staat aan het front van je bedrijf. Sommige spamfilters kunnen al veel tegenhouden, maar een mailtje kan er altijd doorheen glippen. Juist daarom is training van de mensen belangrijk binnen je bedrijf. Daarnaast valt het te betwisten of je endpointproduct in observe-mode zetten de ideale oplossing is, en laten we dan maar niet beginnen over het feit dat systemen nog kwetsbaar waren voor eternalblue :)

Als de aanvallers bijvoorbeeld een kopie van de database van de personeelsadministratie hebben buitgemaakt (vaak compleet met paspoortscans, BSN-nummer, salarisgegevens, verslagen van functionerings- en/of beoordelingssgesprekken, mogelijk medische gegevens), en dreigen die te publiceren en/of verkopen, kun je kiezen tussen:

1) Losgeld betalen, mogelijk bij herhaling. En, met punt 2 als gevolg, wellicht alsnog bewust lekken van die data, of onbedoeld doordat de ransomware inzetters zelf gehacked worden of een "nog minder ethische medewerker" in dienst hebben;

2) Boos personeel dat jouw organisatie aansprakelijk kan stellen voor wanbeheer, zowel voor als na identiteitsfraude. En een vette boete van de AP wegens het nog hebben draaien van een Windows 2003 R2 server in jouw UNIMAAS domein, waar je notabene hebt nagelaten om MS17-010 (tegen EternalBlue) op te installeren - een update die Microsoft gratis beschikbaar heeft gesteld voor EOL systemen.

Misschien dat in dit specifieke geval (UM) er geen vertrouwelijke gegevens (anders dan gebruiker-ID's, wachtwoorden en private keys) zijn geëxfiltreerd. Maar als je de berichtgeving op met name https://bleepingcomputer.com/ een beetje volgt (voorbeeld: https://bleepingcomputer.com/news/security/doppelpaymer-ransomware-sells-victims-data-on-darknet-if-not-paid/), zie je dat steeds meer inzetters van ransomware deze tactiek overnemen. Hoe meer offline back-ups we maken, of vanwege ethische bezwaren weigeren te betalen voor de decryption-key, hoe meer dit gaat gebeuren. Ik kan me niet voorstellen dat de inzetters van de Clop ransomware niet snel zullen volgen.

Denk omdat het dan beheersbaarder lijkt. Omdat vele softwarefabrikanten dit vereisen om nare problemen te voorkomen. Memoryleaks, IIS dat geheugen niet vrij wil geven, etc. etc. Er zijn wel meer van dat soort kleine vervelende problemen. Daarnaast zijn er veel afdelingen met eigen servers, eigen software, met eigen (applicatie)beheerders. Tegenwoordig veel virtueel, maar hierdoor voor iedere scheet een nieuwe server. Enne je weet licenties voor scholen kosten geen drol.

Vergis je niet, een universiteit kan heel snel complex worden kwa netwerk.

Toen ik gisteren in de presentatie op de slide las "verouderd OS" moest ik onmiddellijk aan XP denken,
en vervolgens aan het XP-gerelateerde server OS: Windows 2003 en het risico ervan.
Nu blijkt het dit inderdaad te zijn geweest, en naar ik begrijp is dit een hele belangrijke oorzaak geweest voor de problemen?

Stel dat die servers wel gewoon hun eternal blue patch hadden gekregen,
hoe groot is dan de kans dat de hele ransomware-ellende hun bespaart zou zijn gebleven?

Eternalblue is eevoudig in te zetten en geeft snel resultaat, maar is niet de enige manier om door een netwerk te bewegen. Het voornaamste probleem zit hem in het onnodig gebruik van DA accounts, een onhandig gebruik van antimalware en gebrek aan monitoring.

Om een beeld te schetsen: de UM krijgt ongeveer 100.000
updates per jaar binnen, die allemaal verwerkt dienen te
worden op 1.647 servers en 7.307 werkstations.

Per seconde worden 30.000 inbraakpogingen geblokkeerd en
per dag worden 1400 malware aanvallen gestopt. Daarnaast
komen nog eens duizenden signalen per dag binnen in logs.

De UM infrastructuur bestaat uit 1.647 Linux en Windows
servers en 7.307 werkplekken. De Clop aanval heeft zich
uiteindelijk gericht op 267 Windows-domein servers.

Deze getallen komen uit het Addendum UM 05-02-2020, dat
voorafgaand aan het geredigeerde Fox-IT rapport als de
seminar inleiding van de UM publicatie is opgenomen.

Wow, dat is maar liefst 11 updates per computer, ik krijg er per maand al meer voor een Raspberry PI of zo.
30.000 inbraak pogingen per seconde, ja ja, incl. verkeerde ssh connecties, pings en netwerkscans van echte onderzoekers.
Op hoeveel IP adressen?

Ik had op een moment op 1 particulier IP adres 200.000 'hackpogingen' op jaarbasis alleen op ssh.

Mooi rapport, met hier en daar wat schoonheidsfoutjes. Zo schaar ik MeterPreter niet onder malware, maar onder tools. Het had net zo goed powershell kunnen zijn, gezien de matige stand waarop hier systeembeheer bedreven wordt.
Windows Server 2003, die patches uit 2010 mist is ook wel een dingetje. Maar CyberHygiene is sws een dingetje in Nederland waar we nog heel veel van gaan horen.

Diep respect dat men de durf heeft gevonden dit rapport openbaar te maken.

1) altijd updaten en als dat met MS software niet klakkeloos en pijnloos kan, herzie je keuze in software.
2) Als nu eens beheer met 2FA was gedaan en niet overal een en hetzelfde domain beheer account (ze kie toe evriesing) gebruikt zou worden op gewone servers voor normaal beheer........... is wat lastiger voor die beheerders, ja sure, maar niet voor de onderzoekers, studenten en andere werknemers.

Zolang je geen Windows gebruikt klopt dat wel ja. Maar het moge duidelijk zijn dat Microsoft zeker een onderdeel was van het probleem.

Nee je mag de 100.000 updates niet verdelen over machines.
Uitzoeken welke updates waar op welke machine wat aangebracht moet worden. een 10-tal stacks misschien 30 voor de endpoints. en enkele honderden voor de servers waar de verschillen veel grote zijn. Dan zal het meeste werk vermoedelijk op al die Linux machines plaatsgevonden hebben. Die machines die toch eol waren en nog even door moesten konden laer wel eens. Het is een aanpak en verklaart waarom je machines vergeet. een CMDB goed bijhouden is vrij kostbaar.

Microsoft op zich is het niet het probleem
Het probleem is dat het Microsoft Ecosysteem compleet OPEN is preinstalled.
Dit enkel om te voldoen aan de wensen van de massa
waarom kiezen de meeste mensen nog steeds en massa voor Microsoft en niet voor Linux?
Omdat bijna alles plug and play werkt op het Microsoft OS.
No thinking just easy setup meer willen de meeste mensen niet .....
Logische gevolg van deze openheid van CODE is dat hackers altijd Microsoft OS zullen blijven targetten......
Simpel
Deze hack is er gewoon eentje
Er gaan er ongetwijfeld nog vele tientallen volgen overal waar het geld zit Dus overal bij ons in het Westen.
Gaat niet stoppen dit soort toestanden

Back-up systemen horen niet online bereikbaar te zijn !! Slechts alleen intern met fatsoenlijke beveiliging dus geen FTP bewijzen van spreken. Hadden we toch ergens gelijk, update infrastructuur was niet in orde. Anders was de schade vele malen kleiner geweest.

#pupSocket

hmmmm voor RHEL/CentOS is het slechts eenmalig "systemctl enable yum-cron" uitvoeren bij opzetten met het handje en zo nu en dan bij een kernel update kijken of je een reboot moet geven of een service herstarten.

je kunt het zelfs nog fancier doen via ansible bij automatische deployments die je vlug over wilt doen mocht je je server moet herinstalleren / dupliceren om welke reden dan ook. geen gedoe met CMDB-achtige dingen a la SCSM ofzo. zie bijvoorbeeld: https://docs.ansible.com/ansible/latest/modules/cron_module.html

het punt is dus dat voor die unix omgeving het misschien wel een heel een stuk eenvoudiger was up to date te blijven, updates van het OS door te voeren en configuraties te managen omdat dat jouw kennis vwb het profesioneel beheer van unix omgevingen een hiaat heeft. mede daarom ben jij niet in staat in te zien dat dingen ook anders zouden kunnen zonder in je eigen bubble vast te zitten.

nu ben ik niet een unix is beter dan MS flame aan het starten, maar ik wil je opmerkingen hierboven voor de andere lezertjes wel even relativeren naar de werkelijke wereld :).

De waslijst van alle hacks met Linux is ongelooflijk lang. Dat geschreeuw om aandacht voor een OS met alle flaming is nu juist een hoofdoorzaak van gebrek aan informatieveiligheid. Het waanidee dat een OS en OSS het enige is om iets veilig neer te zetten. Gebrek aan segmentatie goede backup en behoorljk DR is wat ik waarneem daaraan te wijten.

De backup was er niet en wat er was via het gebruikersnetwerk te benaderen. Dat gaat niet met een SAN en gescheiden netwerk. Vermoedelijk wat Nasjes (SMB) omdat makkelijker en ogenschijnlijk goedkoper zijn.

Kap jij daar zelf nou maar eens mee!


regelrechte ONZIN!

alle servers / clients die schrijfrechten hebben kunnen files encrypten, ongeacht of er nu SMB, NAS of iSCSI en SAN gebruikt wordt!

Linux? Hoezo? Die systemen zijn buiten beeld gebleven dus waar heb je het over.

Dank! Dit type reactie waardeer ik.
Yum en Cron begrijp ik; jouw link naar Ansible ga ik lezen.
Kan je ook aanduiden of en hoe jouw RHEL /CentOS is voorzien van IPS en eventueel SIEM? Gebruik je Snort, OSSEC, Prelude of een ander programma? Hoe zijn je ervaringen daarmee?

Verdiep je even in wat het fundamentele verschil in tussen een NAS en SAN is, De eerste SAN's werden eind jaren 80 in de mainframe wereld gebruikt. De ontkoppeling van direct gekoppeld hardware, ooit rarmac naar een aparte box er buiten voor meerder machines. https://en.wikipedia.org/wiki/Storage_area_network het block access lijkt veel die van sectoren.
Een NAS werkt als fileserver https://en.wikipedia.org/wiki/Network-attached_storage SMB CIFS Samba met alle kwetsbaarheden. De synology was een voorbeeld die gehackt werd.
In het wikipedia artikel SAN staat een plaatje met het verschil tussen die twee. Een SAN deelt geen toegang met de endpoints het heeft een afgescheiden netwerk. DIe van een NAS hangt wel direct in het netwerk met de gebruikers.
Binnen een SAN zet je gedeelde tape units neer voor automatische backups.
Alle kenmerken voor het werken met een SAN ontbreken in verhaal van de uni.

Prima een inhoudelijke poging. De frustratie of Linux is in de praktijk opgedaan waarbij er zeer wonderlijk ideeën over dienstverlening leven. De werkelijke wereld van stack is nogal weerbarstig.
Met je poging en je beperking in enkel het os heb je jezelf neergezet als iemand die het totaalplaatje van de dienstverlening mist. Van Amex (pulse secure) en Citrix heb je de voorbeelden hoe het in de aannames van geloof omdat anderen het ook zo doen, goed fout kan gaan.

Ansible https://www.ibm.com/cloud/blog/end-to-end-application-provisioning-with-ansible-and-terraform
Het zoveelste tooltje met een terugkerend doel, denken dat configuratie en uitrol van een applicatie stack foutloos te automatiseren valt zoals de pc gebruiker setup enter enter doet.
Een beetje automatiseerder weet dat je aan monitoring een siem koppelingen met security beheer moet denken.

Grappig IBM had lang geleden al tools met dat soort beloften, In de praktijk te veel problemen er mee. (SMP/E) als je het met andere producten wilde gebruiken. Vele andere scripted aanpak methodes gezien en geen enkele echt altijd perfect het juiste opleverend. Dan heb je nog dat applicatie beheerders erna aan de slag moeten metten configureren ….

Er waren in het univerhaal 2 administrators gecompromitteerd. Het bleek genoeg om ze voor het blok te zetten.
https://threatpost.com/trickbot-evolves-ssh-keys/150617/ net zo kwetsbaar of liever gezegd veel kwetsbaarder.

Weet je wat hier tekenend is? Jij bent de enige die dit soort vreemde ervaringen rapporteert. Ergo het ligt aan jou.

Alleen waren hier Windows-systemen aangetast en Linux-systemen juist niet. Jij bent dus een OS aan het flamen waar in dit geval juist niet iets mis mee is gegaan en doet alsof anderen hier aan het flamen zijn.
Getver, da's nog eens een neerbuigend toontje.
Alleen is het hier op Windows-systemen misgegaan en niet op Linux-systemen. Ervaringen projecteren naar situaties waar ze duidelijk niet op van toepassing zijn getuigt niet van realiteitszin maar van het soort dogmatisme waar je anderen voortdurend van beschuldigt.

Ik lees het fox-it rapport, ze rapporteren exact hetzelfde wat ik altijd al beweer. Ergo ligt niet aan mij.
Het enige verschil is dat ik ook de stoorzenders zoals de evangelisten aanwijs. Daarvoor mag klokkenluiders verhalen volgen. Je kunt die zelfde houding terugvinden in:
https://www.cnet.com/news/how-target-detected-hack-but-failed-to-act-bloomberg/
https://computerworld.nl/security/112680-hoe-maersk-herstelde-van-zijn-ransomware-aanval
Het met least privileges goed inrichten en met gedegen functiescheiding is het echte hiaat.
Het meest droevige met het notoire onveilige IOT waar overal hard code password de norm is en de open databases in de cloud https://selfkey.org/data-breaches-in-2019/ De keer dat microsoft daar voorkomt is het de open source database.

Ik zie Fox-IT in dat rapport niet op Linux of OSS afgeven, en dat is waar jouw reacties vaak van doorspekt zijn. Ik geloof niet dat ik iemand ooit tegen jou tekeer heb zien gaan omdat je segmentatie of goed rechtenbeheer benadrukt, wel omdat je elke gelegenheid lijkt aan te grijpen om open source of open source-aanhangers af te kraken.

The FOSS laat zich inderdaad regelmatig als evangelist kennen. Opvallend genoeg is juist dit een thread waarin dat (tot nu toe) reuze meevalt. Op deze pagina ben jij juist degene die opvalt door je negatief over een OS uit te laten bij een bespreking in problemen die optraden op systemen die een heel ander OS draaien.

Dat zijn zaken die Fox-IT niet steunt in hun rapport. Ze beweren niet exact hetzelfde als jij altijd al beweert; er is overlap in de beweringen maar ze beweren een heleboel niet waar jij maar niet over op schijnt te kunnen houden.

Je bent zelf een van de stoorzenders hier.

Als je algemene open deuren als netwerksegmentatie, e.d. bedoelt dan klopt dat. Duh...


Dat bedoel ik inderdaad. Jouw idee-fixe van (F)OSS als bron van alle kwaad is bijna pathologisch te noemen!


Je lijkt niet in staat om een redering logisch te vervolgen. Nu heb je het namelijk weer over die open deuren. Het (F)OSS evangelistenverhaal vind je nergens anders terug dan tussen jouw eigen oren!


Nu heb je het weer over IoT-fabrikanten die voor een dubbeltje op de eerste rang willen zitten en alle configuratie, updateability, etc. overboord gooien. Stel je eens de ellende voor die zou zijn ontstaan als deze fabrikanten Windows hadden gebruikt voor hun IoT-apparatuur. Dan zou het leed écht niet te overzien zijn geweest!

ok. hier ruweg de opzet van onze end-points:

Onze machines gebruiken iptables + tcpwrappers en laten enkel ssh toe van bepaalde (interne) netwerken. Root mag NOOIT via ssh inloggen en alle root wachtwoorden zijn uniek en lokaal per machine (salted sha512). Beheerder logt in vanaf werkstation via ssh key in op persoonlijk account (dat default een 'locked' password heeft en dus geen toegang biedt behalve dan via die ssh key ivm UsePAM) en gaat dan naar root / sudo en moet daarbij dat het unieke root ww gebruiken. Op den duur willen we daar std yubikey voor gaan gebruiken om 2FA te hebben om naar root te gaan.

Verder fail2ban voor ssh en rapporteren dagelijks via logwatch naar een centraal punt. Ze doen ook audit logging maar ivm volume en 'te veel ruis' slaan dat lokaal op en het is logwatch die daar een dagelijkse samenvatting van maakt en door geeft naar centraal punt dat deglijks gemonitord word door 4 ogen. Ook gebruiken we AIDE raportages om te zien welke files van het OS er (dagelijks) verandert zijn. Part of the centrale logging. Dagelijks updates doorvoeren via yum-cron van locale repo mirror met protection en priorities enabled en PGP verificaties. Ook gelogged. Verder gebruiken we targeted SELinux. Op die enkele kritieke systemen die wel ssh van internet moeten kunnen gebruiken we extra auditing en logging van alle gemaakte tcp connecties en processen via accounting. Dit zodat we bij problemen een 'trace' kunnen uitvoeren.

Verder gebruiken alle machines een interne caching DNS die dagelijks een lijst met bekende malware / virus sites blokken en terug vallen anders op 9.9.9.9 en gebruiken we arpwatch.

https://en.wikipedia.org/wiki/TCP_Wrappers
https://en.wikipedia.org/wiki/Fail2ban
https://en.wikipedia.org/wiki/Advanced_Intrusion_Detection_Environment
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/chap-system_auditing
https://wiki.archlinux.org/index.php/Logwatch
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/selinux_users_and_administrators_guide/chap-security-enhanced_linux-targeted_policy
https://github.com/notracking/hosts-blocklists
https://en.wikipedia.org/wiki/Quad9
https://en.wikipedia.org/wiki/Arpwatch

Dus ja concepten als SIEM (en IPS) worden gebruikt, echter op host niveau omdat we zelf niet het netwerk beheren (centraal gedaan door centrale windows IT) en we het (interne) netwerk zelf al als boze buitenwereld beschouwen. De centrale IT is niet zo capabel / secure (is gebleken in de praktijk in het verleden) als dat we zelf zijn en willen.

Er zijn nog veel meer maatregelen die we nemen, maar dat gaat te ver en hangen sterk van de flexibilteit / grote van de omgeving af ook. Zijn minder generiek toepasbaar dus.

Wat JIJ niet begrijpt is dat het voor cryptoware geen ene donder uit maakt of files op een SAN of NAS staan. Zodra iets schrijfrechten heeft naar files of disk, dan kan op die plek cryptoware toe slaan, SAN / NAS doet er gene ene reet toe.

leuk hoor een SIEM. Als dan toch eens de pleuris uitbreekt, ga jij dan lekker met het handje een voor een elke geraakte server weer opbouwen door met het CDtje te rennen? SIEM is een dimensie in security, de snelle responce tijd die uitomatische geverifieerde uitrollen en configuraties kunnen bieden de andere die je heel nuttig kunnen vallen TIJDENS een gevecht met hackers / malware. Je SIEM helpt je dan op dat moment niet meer namelijk.

Je hebt gelijk dat ik dat buiten de reguliere draden probeer te houden. Maar de onophoudelijke provocaties maken dat wel moeilijk.

Dank! Dank! De referenties zijn talrijk. Dit begint te lijken op een college Cybersecurity door een vakman.

Doen julllie ook aan virusscannen (misschien ClamAV, rkhunter, chkroot, of ook real-time).
Kan je ook nog iets zeggen over jullie backup-schema (incremental, off-line, scheduled), omdat onbesmette backups ook bij de recente ransomware aanvallen cruciaal blijken te zijn, en in ieder geval een pijler zijn onder de bedrijfscontinuiteit en informatie/dataveiligheid.

Hoe wissel je (goede en slechte) ervaringen uit met andere beheerders. Ik heb op security.nl nog niet veel "linux best practices" gelezen, maar misschien is de lawine van ransomware en (Citrix)lekken wel een soort Pearl Harbour. Misschien kunnen ook andere linux-beheerders hier een bijdrage leveren.

Yep gebruiken ook up to date ClamAV en rkhunter. Rapporteren weer via logging en logwatch dagelijks centraal.

Hebben een setup waarbij gebruikers data gebackuped wordt. Hier gebruiken we stageing servers voor: data van gebruikers wordt nachtelijks via cron gepushed (rsync) naar stageing server waarbij iedere server of host die pushed dat naar een speciaal opgezet un-priviledged account specifiek alleen voor die host op een stageing server. De hosts zijn verdeeld over enkele stageing servers. Deze syncs kunnen worden gebruikt voor on-line DR van gebruikers data. ClamAV wordt dan regelmatig gedraaid (eens per week) op data op die stageing servers zodat virus scans niet de servers extra belasten [Kunnen vaker ClamAV draaien, maar vooralsnog nooit een virus oid gezien dat schadelijk voor onze RHEL/CentOS machines en werkstations zijn (wij doen ook geen windows). Dus zonde van de stroom denk ik dan].

Dagelijks worden dan snapshots gepulled van die stageing servers naar een backup server die ook aan historie doet. Ook weer met unpriveledged accounts en waarbij scripts en executables als gewone files beschouwd worden. Dit is daarmee niet een letterlijke airgapped backup, maar bijna zo goed als: compromised host kan alleen op stageing server host specifiek un-priviledged account komen maar nooit direct op backup server waar historie ook is. Alles geautomatiseerd en elke dag een rapportage van gemaakte backups via centrale logging. 4 ogen.

Daarnaast wordt die backup history een paar keer per jaar gedupliceerd en off-line (dus echt airgapped) off-site opgeslagen en geverifieerd met sha256 checksums voor opslag. Dat is een beetje een klote klus eigenlijk (niet veel werk, maar wel een doorlooptijd van een weekje) en dat wil ik eens beter automatiseren oid maar weet nog niet hoe zonder te veel inbinden in veiligheid. Tips welkom.

Alles heeft uiteraard RAID redundancy, smart alerts etc. etc. Alle communicatie gaat ook encrypted over de draad (ssh/https only). Altijd! Goes without saying :).

OS wordt niet gebackuped. OS heeft wel meervoudig RAID-1 redundancy, maar wordt ook in geval van uitbreiding of DR from scratch opnieuw uitgerold middels scripting en configuration management (anaconda kickstarts en ansible) vanaf centrale interne CentOS mirror.

Uiteraard is niets 100% lading dekkend, maar security by layers: ACLs, segmentatie, logging en monitoring, en daarna automated DR en je backups op orde hebben naast je OS dagelijks op to date houden, is iets wat je wel kunt doen op end-points zelfs al ben je niet volledig in control van het netwerk zelf. Deze technieken zijn daardoor ook gewoon te gebruiken in de cloud namelijk (doen we niet want AVG).

Van dag een af aan niet denken als een kasteel met een slotgracht en maar de zaak proberen te verdedigen, maar als decentrale end-points dotted in een boze buiten wereld die een keer op een vervelend moment zullen worden gehacked helpt denk ik.

Dus dingen als monitoring, segmentering, DR en backup en vlugge reproduceerbare automated deployments van kritieke servers uit een geverifieerde bron zijn de belangrijk om op orde te hebben.

Andere beheerders bij ons centraal? Dat zijn voornamelijk std windows beheerders, en die 'denken' anders merk ik :). Ze denken veelal in tools en procedures ipv oplossingen en concepten en ik laat ze maar met rust zolang ze mij ook maar met rust laten...

Sophos AV is gratis voor Linux. Biedt on demand én on access scanning.

https://www.sophos.com/en-us/products/free-tools.aspx

Kan je de volgende termen nader differentiëren / verduidelijken?
1. compartimenteren
2. segmenteren

En hoezo duiden beide termen niet op 2 verschillende ordes?
En hebben beide ordes noodzakelijkerwijs dezelfde verzameling delers?
Bij segmenten denk ik aan taarten.
Waarbij 1 segment gedeeltes uitsnijdt van hetzelfde object gemeenschappelijk.
Je snijdt 2x of meer keer hele delen dwars door de kern, omliggende delen en rand.
Je krijgt dan 1 of meerdere segmenten.
Bij compartimenten denk ik aan ruimtes, waarbij de kern omliggende delen en randen afzonderlijk van elkaar kunnen zijn gescheiden door barrières.


En vervolgens lees ik:
.......voor e-mail ophalen een andere computer gebruikt dan de computer die aangesloten is op het netwerk dat interessant is voor hackers. Hierdoor is penetratie van het doelnetwerk via een phishingmail vrijwel nihil......

Heb je het hier dan niet gewoon over denkbeeldig uitsplitsen van onderlinge raakvlakken tussen reken-eenheden in 1 dezelfde verwerking-eenheid?
Met verwerking-eenheid doel ik op zaken als centrale processor, werkgeheugen / data dragers / grafische eenheid / toetsenbord / muis e.a. andere elementen die input en/of output verwerken..

En is het compartimentaliseren in dat opzicht in essentie echt iets heel anders dan:
3 het beperken van aantal node-ingangen tot beperkte c.q. unieke node-ingang reeksen?

Waarbij altijd een verwerking eenheid zoals een centrale processor, als gpu / cpu / andere units moeten hierbij in alle gevallen altijd in de node-ingang reeksen worden ingesloten.

Het achterliggende belang is dat als compartimenten gegevens verwerken de gegevens allerlei paden afleggen.
De paden mijn inziens die met de node-ingang reeksen te vormen zijn.
En met meerdere reeksen heb je in essentie ook nog altijd meerdere ingangen.

Het belang achter de vraag:
Dus als we stellen dat het uitmaakt wat de compartimenteringstechniek is waarmee computers / servers worden ingericht, maakt het in essentie niet ook uit of je aan het compartimenteren of segmenteren bent?
Waarbij je met segmenten altijd wel meer gemeenschappelijke delers in alle node-ingang reeksen krijgt dan bij compartimenten. Omdat je met segmenten dus altijd iets van de kern en daaromliggende delen opneemt in je node-ingang reeksen en met opsplitsen in meerdere zinnige compartimenten.
Omdat je bij die laatste niet bij alle reeksen ook iets van de kern en daaromliggende delen opneemt maar dat juist ook virtueel van elkaar scheidt.

@ Anoniem 13:15 college Cybersecurity deel 2 ;-))

Gelukkig is er dus nog een "rots in de branding" als het om Cybersecurity gaat.

".. Kunnen vaker ClamAV draaien, maar vooralsnog nooit een virus oid gezien dat schadelijk voor onze RHEL/CentOS machines en werkstations zijn (wij doen ook geen windows). Dus zonde van de stroom denk ik dan .."

Wow ... Het lijkt misschien heel gewoon wat daar staat, en dat zou het ook moeten zijn, maar het lijkt toch bijzonder in deze tijd van ransomware en andere malware. Ik denk dat een beetje stroom goedkoper is dan een ransom ....

".. Alles heeft uiteraard RAID redundancy, smart alerts etc. etc. Alle communicatie gaat ook encrypted over de draad (ssh/https only). Altijd! Goes without saying :).."

Toch zouden deze - en andere - "best practices" meer besproken moeten worden en aandacht mogen krijgen. Misschien is Maastricht, en de open wijze waarop deze crisis is besproken in samenwerking met Fox-IT, een keerpunt.

".. Van dag een af aan niet denken als een kasteel met een slotgracht en maar de zaak proberen te verdedigen, maar als decentrale end-points dotted in een boze buiten wereld die een keer op een vervelend moment zullen worden gehacked helpt denk ik .."

Dat lijkt mij een goede strategie, ook passend bij een "open" organisatie zoals een universiteit. Maar ook voor andere organisaties.

".. Andere beheerders bij ons centraal? .."

Nou, ik bedoelde eigenlijk dat ook andere linux beheerders bij andere organisaties een bijdrage kunnen leveren aan een uitwisseling van oplossingen. Is er een platform voor het uitwisselen van jouw "architectuur" en "praktische uitvoering" met collega-beheerders, op een site zoals security.nl of tweakers? Waar heb jij jouw kennis opgedaan? Of is deze site nu de enige plek waar cybersecurity op deze manier besproken wordt? Organiseren jullie een "kijkje in de keuken" voor en door collega linux beheerders, "leren van elkaar", zodat er een doorlopende "praktijktest" ontstaat waarbij vanzelf "best practices" komen bovendrijven? Wat is de beste kluis, kluisdeur, kluissleutel, sleutelbeheer, controle, hoe organiseer je gebruiksgemak?? Zodat niemand het wiel opnieuw hoeft uit te vinden. En er misschien een soort "wiki cybersecurity" ontstaat.

".. Daarnaast wordt die backup history een paar keer per jaar gedupliceerd en off-line (dus echt airgapped) off-site opgeslagen en geverifieerd met sha256 checksums voor opslag. Dat is een beetje een klote klus eigenlijk (niet veel werk, maar wel een doorlooptijd van een weekje) en dat wil ik eens beter automatiseren oid maar weet nog niet hoe zonder te veel inbinden in veiligheid. Tips welkom .."

Kijk, dat bedoel ik. Het kan zomaar zijn dat er al een werkende oplossing bekend is bij een andere Linux-beheerder. Misschien wel een lezer van security.nl
My two cents: een hogere netwerk snelheid (GigaBit is al aangelegd denk ik :-) ) of een glasvezelverbinding (duur, maar goedkoper dan een ransom??). Of parallelliseren?

Je merkt misschien dat ik geen vertrouwen heb in "security through obscurity". De wijze waarop Uni Maastricht en Fox-IT nu openheid van zaken geven is gedetailleerd genoeg om ervan te leren. "Open Security" ook wel "Security by design" is qua ontwerp veel beter. Jouw college is daarop een unieke aanvulling.

Dat openheid, en "Security by design" goed werkt werd ook gezegd door Frank Brokken, systeembeheerder bij de RUG, op de TekTok - NCSC One Conference in den Haag, en bevestigd door Rickey Gevers:
https://www.tektok.nl/tts1.html
Onderdeel 7. Frank Brokken (RUG) finally meets @XS2all4me, who hacked his university
https://www.youtube.com/watch?v=A5ANT8BFKNg

Toevallig ... heb ik vorige week nog naar gekeken:
https://www.safetydetectives.com/blog/best-really-free-antivirus-for-linux/
What we don't like: (..) You have to pay for ransomware
Klopt dat? Heb jij bijvoorbeeld in jouw virus-definities van Sophos bijvoorbeeld wel Clop ransomware?

Daarom heb ik CoMoDo geprobeerd te installeren, maar dat vereiste de installatie van een verouderde versie libssl0.9.8 ... daarom eerst nog even "on hold" gezet. Maar info is welkom ...

niet zo vlug...

wel een risico analyse doen:

- al 10j elke week scannen heeft nog niets ooit iets opgeleverd en malware voor linux is minimaal
- backups zijn ingeregeld en op orde
- host intrusion detection is deployed en actief
- virus scanners zijn niet 100% dekkend en lopen vaak achter de feiten aan
- het scannen van alle data kost ook enkele uren en resources

dan de keuze om vooralsnog slechts eens in de week te scannen is een mooi compromis.

Nee , een SAN kun je ook inrichten met CIFS (met domeinkoppeling), iSCSI of Fibrechannel kun je naast de LAN aanbieden op aparte kaarten voor Storage oa. voor VM (als apart netwerk). Vroeger werd dit best veel gedaan. Tegenwoordig veel minder.
Echter deze VM hangen meestal weer gekoppeld aan het domein als disks voor Windows servers in domein en dan toch gewoon kwetsbaar.

WTF? Nee, blijkbaar niet :-( Overgestapt op ClamAV.


Die libssl0.9.8 is wel erg oud :-( Persoonlijk haak ik af wanneer er packages nodig zijn ouder dan wat Debian stable heeft.

Dat koppelen omdat het zo handig is omdat het werkt moet je niet zomaar doen. Je hebt daarmee 1 van de vier hoofdaanbevelingen van fox-it te pakken.

En nee cifs is smb dat is heel wat dan block level access.
San is bloklevel en nas is cifs ofwel files. Niet vergelijkbaar.

details:

er worden twee lege fysieke HDDs in de server bijgeplaatst en direct een copy gedaan. 200Mb/s en met twee disks tegelijk [de snelheide beperkende factor is de streaming write snelheid van een enkele disk in een server]. kost toch nog enkele dagen de hoeveelheid en dan heb je de stap dat ik de disks uit de server haal, ze in een andere server readonly mount en de sha256 van alle files check tov de sha256s van alle files op de backup server [de restore test in essentie]. extra veilig, vrij weinig handelingen of human tijd, maar des al niet te min elke keer weer een doorloop tijd van een week. denk niet dat any netwerk of een andere methode vlugger zal gaan dan dit eigenlijk. het enige wat je kunt doen is een 2e kopie mee laten lopen zodat de data over de tijd (via netwerk) binnen trickled op je 2e locatie oid, maar dan is het ook geen echte airgap meer :). dus we accepeteren het maar zo. of je nu HDDs om moet wisselen of tapes, de data moet er toch op gezet worden, dat kost tijd en dat bepaalde de doorloop tijd. btw gebruiken steeds nieuwe HDDs en hebben dus ook een historie in de kast liggen van vorige off-site kopies. een soort van analoge manuele off-site multiple RAID-1:). HDDs zijn goedkoop en worden steeds groter en goedkoper en zijn wat makkelijker in een server de stoppen dan tapes. een compromis dus vwb kosten baten ook meteen.

zucht, karma-snap-het-niet-en-als-hij-het-nu-begrijpt-geeft-ie-toch-niet-toe-want-....

1) als ik in word een documentje maak en op save druk; hoe gaat dan de data en in welke vorm uiteindelijk op de disks terrecht komen in je SAN omgeving?
2) als nu op die machiene waar ik save druk ook ransomware terrecht komt... oh jeej alle files van mij (en andere van de share oid) encrypted... ja maar ja maar ja maar shock and amazement.... we hadden toch SAN ?!?!?!

je koppigheid werkt als een blokade en belemert je jezelf te verbeteren en jezelf op een nog hoger niveau te tillen karma!

Dus de Sophos definities bevatten inderdaad geen CLOP ... wat mij betreft een gemiste kans van Sophos. Goed dat je dat even terugkoppelt.

Maar ClamAV is weer niet "on-access" (real-time). Ik gebruik ClamAV (met de ClamTK GUI scheduled 1x daags) en overweeg juist Sophos of CoMoDo vanwege deze "on access scanning" er naast te gaan gebruiken, hoewel ClamAV bij mij al jaren geen virus heeft gedetecteerd.

Ook rkhunter en chkrootkit (on-demand) leveren alleen een enkele "warning" op, meestal is dat een "false positive" na een kernelupdate.

Omdat versie libssl0.9.8 mij nogal gedateerd leek (wat jij ook zegt) heb ik ook Comodo eerst niet geinstalleerd.

Toch lijkt mij virusscanning wel nuttig, maar omdat diverse varianten malware in Maastricht wekenlang aanwezig zijn geweest op de besmette Windows servers, lijkt een dagelijkse of wekelijkse "scheduled scanning" door ClamAV ook al voldoende.
De uitgebreide beschrijving van Anoniem 09-02-2020 11:07 ben ik aan het bestuderen, en ik overweeg nu als aanvulling Aide, Snort of OSSEC.
https://en.wikipedia.org/wiki/Host-based_intrusion_detection_system_comparison

Voor de geavanceerde unix beheerders met een oogje op security, is er ook nog:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/scanning-the-system-for-security-compliance-and-vulnerabilities_security-hardening

[ beetje ouder maar goede achtergrond: https://www.redhat.com/en/blog/configuring-and-applying-scap-policies-during-installation ]

Integreerd goed met ansible en anaconda (compliant install at first boot) en de grafische tool Scap Workbench is eenvoudig in het gebruik om systemen op compliancies te toetsen en of te remidiaten.

De gehele guide https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/index is zowiezo al een goede bron van tips and tricks.

ClamAV is tegenwourdig wel "on-access" https://blog.clamav.net/2019/09/understanding-and-transitioning-to.html . Het heeft alleen allemaal geen zin. Wij gebruiken het al 10 jaar omdat de klant het wil maar er is nog nooit 1 virus waargenomen!

Prima houding, het is nog nooit gebeurt dus het zal ook nooit gebeuren.
In Maastricht hadden zo ook nog nooit ransomware gehad.

Blocklevel of niet, het is het protocol, maar meestal de bestanden zelf die kwetsbaar zijn, de blocklevels doen geen reet in dit verhaal anders dan de files faciliteren (aanbieden) in een stukje op de beschikbare disks. Wat je wel kunt doen met een SAN is file-creatie blokkeren via een policy, echter dan zou de randsomeware een bepaald filetype moeten aanmaken (wat ze soms doen). Wellicht dat een NAS dit soms ook kan.

CIFS werd vaak gebruikt omdat de filesharing via SAN beter was in grote omgevingen dan onder windows (performance). Tegenwoordig is dit verschil nagenoeg nihil en is er meer nadruk op anti-virus/malware, dat onder SAN weer regelmatig een beperkende factor heeft.

Nee met aparte switches en fiber kabels kom je in een SAN niet zomaar binnen. Op de machine met blocklevel interceptie komt het heel anders in het OS. Het verschil wordt echt merkbaar met een DBMS als "applicatie".
Apart gescheiden netwerk andere techniek hoewel het met ip ook lijkt te kunnen. En een apart beheer voor data war backups en hardware migraties een eigen vakgebied zijn geworden. SAN is trouwens vanuit mainframe (sysplex) wereld ooit gegroeid, later met Unix en Windows uitgebreid.
Hot failover, hot stanfby, DR in meerdere tijdvensters voor backups.

CIFS Samba is het gedoe dat je vanuit Windows en dan de desktops bestanden met een Unix server wil delen. Het is eenvoudiger omdat het op een Windows file server lijkt. NFS gebruiken tussen meerdere UNIX dozen is niet aan te raden als het om hogere volumes en zwaar gebruik gaat. Niet voor niets is er iets als Hadoop verzonnen.

Als je gegevensbeheer goed wil doen zul je los moeten komen van de machinebeperkingen van wat voor een OS dan ook.

Het is misschien wat geneuzel, maar ik wilde in elk geval voor mezelf weten wat het verschil is tussen CIFS en SMB en heb dat hier meteen maar opgeschreven.

CIFS is SMBv1 (als ik me niet vergis via poort 445 i.p.v. 137 t/m 139). Mogelijk (?) nadat Microsoft inzag dat CIFS toch niet zo'n economisch en veilig protocol was om via Internet bestanden te delen, heeft zij de term CIFS vanaf SMBv2 losgelaten voor communicatie met file shares.

In "Normative References" https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-cifs/ verwijst Microsoft naar een webpagina met historische documentatie (wellicht ook leuk voor de IPX-ers en Token-Ringers onder ons): http://timothydevans.me.uk/n2c.html waar je ook een PDF kunt "veilig stellen".

Uit http://timothydevans.me.uk/nbf2cifs/c2759.html:

Uit versie 59 van het SMBv2 en SMBv3 protocol, te vinden in https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/:

Dus ja, "cifs is smb" (d.w.z. één specifieke variant van SMB, https://tools.ietf.org/html/draft-heizer-cifs-v1-spec-00), maar SMB is niet altijd CIFS.

Opmerkelijk genoeg hanteert Microsoft de term CIFS nog wel in het "browser" protocol (voor het vinden van resources op een netwerk, niet te verwarren met een webbrowser), zie https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-brws/.

Uit veiligheidsoogpunt kun je het beste uitsluitend de laatste versie van het SMB protocol toestaan op je netwerk, SMBv3 (dat, strikt genomen, geen CIFS is). En al die "handige" (meestal chatty) protocollen als NetBIOS over TCP, MDNS, LLMNR, WPAD en network browser messages verbannen - die passieve sniffers gratis veel info geven en actievelingen met tools zoals https://github.com/lgandx/Responder devices aan jouw netwerk laten overnemen.

@Karma De achterkant waar jij steeds aan refereert is inderdaad afgesloten/apart aangesloten. Maar als de "files" of LUN die gepresenteerd worden als disks onder een vm, met in dit geval windows, zijn dan nog steeds kwetsbaar, niet de files an sich, maar wel de inhoud van deze gepresenteerde disks (files) of LUN. Ook al zou je snapshots gemaakt hebben, dan nog kun je in de problemen komen. Kortom Karma je kunt dan andere applicaties erbij roepen, maar het gaat in dit geval om windows en wat blocklevels doen..iSCSI of Fiber is gekoppeld via de virtualhost en daar komt alles samen in een VM, Windows op de VM ? Dan gewoon kwetsbaar en zul je de boel dicht moeten zetten. iSCSI of Fiber maakt dan niets uit, die zijn niet kwetsbaar, maar niets anders dan de methode van koppeling (via protocol en hardware) van de disks van de SAN en beschikbaar te maken voor de virtualhost en ook voor de VM.

Dus stop met verwarring zaaien...

Erik, CIFS is nog steeds een term die gebruikt wordt bij SAN (soort van ingeburgerd) en kan zeker een hogere SMB versie aan zoals je al schreef. Dit is meestal een instelling in de SAN/CIFS config om een hogere SMB-versie te forceren.

" Nee met aparte switches en fiber kabels kom je in een SAN niet zomaar binnen. "

Onzin. zodra je een file kunt opslaan op een server die een LUN heeft ben je binnen.

het is geen houding, het is een constatering (die ik ook reeds deed). er wordt gescanned; maar je mag ook kritisch zijn en je realiseren dat een scanner ook heel gemakkelijk bedonderd kan worden.

kortom; niet zo blind en klakkeloos zonder verder te denken dan 'thou shalt use virus scanner'.

Correct, bij de meeste anti-virussoftware is een kleine afwijking al voldoende om niet aan te slaan.
Tenzij je anti-virussoftware gebruikt die behaviour monitoring doet.

Malwaremakers passen hun malware ook zo aan dat behavioral monitoring, heuristical detection, memory-scanning en andere marketingkreten worden omzeild. Bij verse fileless malware ben je nagenoeg kansloos.

Wat resteert is de detectie van malware van gisteren op basis van patronen in een bestand. Als de door jou gebruikte virusscanner na X tijd al definities maakt en verspreidt voor zo'n specifiek bestand.

Het verschil tussen 0 en 1 is vele malen groter dan tussen 1 en 1000. Antivirus onder Linux is zonde van de energie. Je kan beter tijd stoppen in brute force preventie etc. Linux is geen Windows.

Ik gebruik een ClamAV scan onder Linux op de inhoud van ~/Documents/ ~/Downloads/ en nog een paar andere kritieke directories, waaronder /var/spool/mail/ met behulp van de "on-access" functie. Dat verhindert het per ongeluk doorsturen van reeds besmette email bijlagen of bestanden aan mijn klanten en contacten die op hun zaak of thuis nog Windows gebruiken. Dat gebruik komt voort uit het voorzorg principe. In geen 20 jaar heb ik een wild Linux virus gezien.

Het komt wel sporadisch voor dat er een probleem is. Vaak is dat een ontvangen Word of Excel bestand of dat er een op JavaScript gebaseerde PUA wordt gedetecteerd in een webpagina. Mijn bank en verzekering vereisen het gebruik van regelmatige updates, een firewall en antivirus in hun algemene voorwaarden. Door ClamAV in te zetten voldoen ik aan mijn contractuele verplichtingen. Zo sta ik juridisch sterker, want de genomen preventieve maatregelen kan ik aantonen.

Het rapport met verslag fox-it heeft het over niet op orde hebben van backups monitoring van wat er met data gebeurt.
Als je de inrichting goed had gedaan dan waren die punten niet genoemd.
Met CIFS in NAS geef je een richting hoe je met verwarring zaaien komt tot iets wat niet echt voldoet.

gewoon onzin!

jij snapt niet dat het niet uitmaakt voor cryptoware of files op een NAS staan of dat die files op een server met een LUN vanuit een SAN staan.

en je geeft gewoon niet toe omdat je karma bent en in je trots gekrenkt bent.

Fox IT leverde aan dictaturen in Syria en Egypte en is geen Nederlands bedrijf maar een Brits. Hoe gaat dat na de Brexit? Kan ( mag ) de AIVD en CIA aankloppen bij Nederlanders met exotische meningen over security voordat de Russen er gebruik van maken in assymetrische oorlogsvoering? Neen dat willen "we" nyet. Allemaal in de pas lopen graag, dat maakt het voor de vijand makkelijk om iedereen de identificeren. Wel zo handig, die STANDAARD PROTOCOLLEN.

De behaviour monitoring kijkt wat een file doet die (on)besmet is, als deze buiten verwachting allerlei onbekende processen opstart of aanroept, wordt de executable direct geisoleerd. Heeft heel soms, bijna uitzonderlijk, een beetje finetuning nodig (false positive). Een goed voorbeeld is Palo Alto Traps. Deze monitort op 7 proceslagen. Is zeer lightweight en gebruikt doorgaans maar 3-8% van je CPU ipv 20-35%. Ben zeer tevreden over dit product.


.

Ik heb niets met persoonlijke trots, meer me de ergernis dat het uit onkunde onwetendheid of omdat het niet uitkomt zo vaak mis gaat in de ICT wereld. Dat het mis gaat raakt ons alllen.

Het kan geen kwaad om je te verdiepen wat er speelt in het grotere geheel. kijk even bij Figure 1 INCITS T10 Protection Information Model en 3,2,4 . http://snia.org/sites/default/files/Data_Integrity_Architectural_Model_v1.0.pdf
Als je er verder rondkijkt zul je ook objectstorage zien. Dat is het type storage wat massaal open staat in het publieke internet met de massale datalekken.

Het maakt een groot verschil of de data beheerd wordt in een netwerk onbereikbaar voor anderen (SAN) of dat data direct bereikbaar is in een netwerk met vele gebruikers.

https://helpcenter.veeam.com/docs/backup/vsphere/backup_server.html?ver=95u4 Moet je niet in het domein hangen wat vanuit buiten of via via te benaderen is. Nog steeds moet je die aparte offsite backup hebben.

Er is een verschil in de praktijk en de oorspronkelijke theorie, daarnaast zijn veel opties flexibel (vindt de fabrikant ook fijn), dus worden ze ook zo gebruikt. Dus kom uit je donkere doosje en zie een andere wereld Karma.

Voor windows malware maakt dat niet uit.

Over Shannon entropie detectie als een noodzakelijke aanvulling op de basale functies van ClamAV

Entropy Scanner for Linux
MIT License @ Github
https://www.sandflysecurity.com/blog/sandfly-filescan-open-source-file-entropy-scanner-for-linux/

Shannon entropie theorie
https://en.wikipedia.org/wiki/Entropy_(information_theory)

K. Lee, S. Lee and K. Yim, "Machine Learning Based File Entropy Analysis for Ransomware Detection in Backup Systems," in IEEE Access, vol. 7, pp. 110205-110215, 2019. [Open Access]
https://ieeexplore.ieee.org/abstract/document/8772046#deqn1-3

De sandfly-filescan util is hier vermeld als een optie om entropie detectie onder Linux a la minute toe te kunnen gaan passen, zonder verder uitstel. De IEEE studie van Lee et al. is om te illusteren hoe dat met ML-based entropie detectie beter kan, want alleen sandfly-filescan installeren is niet meer dat een laatste strohalm.

Er is inderdaad een groot verschil in wat handig snel en goedkoop gedaan kan worden en wat echt veilig is.
Dat is nu net de hele clou waar je zelf over moet denken. Dat is gezien de adviezen van fox-it niet goed gegaan.

de entropy van een (of meerdere) files zien veranderen (indicatie van encrytie) is volgens mij niet beter een detectie als een goede intrusion detection middels een database met hashes van je files (die zelfs een hele kleine verandering zal detecteren).

Een controlesom is geschikt voor de monitoring van wijzigingen in kritieke binaire of statische bestanden onder de beheerder, waarin geen onverklaarbare zaken mogen optreden. Mogelijk verdachte codes kan men ook opsporen op basis van de aard en mate van hun compressie of hoogte van de entropie waarde, als aanvulling op de antivirus scan.

Entropie detectie is ook geschikt om de reserve bestanden van de gebruikers te monitoren, omdat de inhoud van hun werk nu eenmaal vaak aan verandering onderhevig is. Een daardoor afgaand alarm bij hoge entropie kan verhinderen dat gegijzelde bestanden met de geplande automatische routines in de kritieke reserve opslag terecht komen.

Besef wel dat de inbreker dan al binnen is. Het komt dan aan op hoe goed de nodige reserve systemen zijn beveiligd.