en dell moet stoppen met de verplichte koppel verkoop van windows bij hun producten.

De titel en het artikel bovenin kloppen niet. Uit http://www.secureworks.com/cyber-threat-intelligence/threats/teslacrypt-ransomware-threat-analysis: Opvallend, de Redactie is meestal erg "secuur" :)
1. Het gaat niet alleen om .zip files, maar ook andere formaten zoals .rar, .7z en .arj - zeg maar alle formaten die recente versies van bijv. 7Zip, WinZip, WinRar en PeaZip kunnen uitpakken.
2. Het artikel spreekt niet van .exe maar van executable files (naast .exe is bijv. ook .scr populair, maar er zijn veel meer bestandformaten die je als executable zou moeten kwalificeren).

Los van bovenstaande kritiek op het artikel: hoe het aantal ransomwarebesmettingen via webmail zich verhoudt tot besmettingen via dedicated Exhange/IMAP/POP3 MUA's (Mail User Agents, programma's als Outlook en Thunderbird), weet ik niet. Heeft iemand hier wel eens iets over gelezen?

Feit is dat desktop-antivirus, voor zover ik weet, geen onderscheid maakt tussen reguliere downloads en downloads van e-mail bijlagen uit webmail.

Feit is ook dat niet alle unpackers de uitgepakte bestanden voorzien van een "SmartScreen" attribuut (via een ADS = Alternate Data Stream, die je met Notepad kunt toevoegen of wijzigen, zie bijv. http://www.hanselman.com/blog/RemovingSecurityFromDownloadedPowerShellScriptsWithAlternativeDataStreams.aspx). Als ik me niet vergis voegen 7Zip en de ingebouwde unpackers in Total Commander zo'n ADS helaas niet toe (bij uitpakken). Windows verkenner/explorer doet dat overigens wel (maar kan niet veel formaten uitpakken).

Malware verspreiders gebruikten recent zip, rar, jar. Soms gebruiken ze andere extensies van compressietools, terwijl de inhoud een ander format is. Bestanden met com, bat of andere extensie zijn meestal gewoon PE executables. cpl en scr zijn PE executables (hetzelfde als een Windows exe).

Veel aanvallers gebruiken Office documenten met macro's. Die worden in veel gevallen doorgelaten, terwijl veel content mail scanners executables blokkeren. De penetratiegraad van macro's is dus groter. Al moet de gebruiker wel worden overgehaald om de macro bescherming uit te zetten. Dat is niet zo heel moeilijk omdat de macro waarschuwing tamelijk onduidelijk is.

Bij de selectie van een content scanner verdient het dus aanbeveling te letten op de mogelijkheid van het blokkeren van documenten met macro's.

Maar wat moeten ze dan gaan leveren?

Er is geen alternatief voor bedrijven, dus waarom zou Dell dan moeten stoppen om Windows te leveren?

-- Eens Erik. Ook de rest van geode kwaliteit. Dan je mail vraag.
- Met webmail moet er apart actie ondernomen worden om het te uploaden/downloaden (webdav). De sites worden vaak geblokkeerd vanuit bedrijven. De reden is dat het vaak, te vaak als uitwijk gebruikt wordt voor opslag die intern afgeschermd is. Onderbouwing is afscherming gegevens is nodig (dus dicht) gebruiker gaat er toch omheen (compliancy?).
- De webserver (exchange / lotusnotes / ..) kan zo ingesteld worden dat bijlagen van bepaalde types niet doorgelaten worden. zip/exe etc. komen niet eens tot de mail client. Dit is gangbaar bij grotere bedrijven, zie b.v. http://www.belastingdienst.nl/wps/wcm/connect/bldcontentnl/standaard_functies/prive/contact/per_brief_of_email/voorwaarden_e-mailen/bestanden_die_wij_niet_kunnen_ontvangen/bestanden_die_wij_niet_kunnen_ontvangen
- In de mailclients gebeurt ook nog een en ander. Ook hier worden bepaalde extensies uitgesloten. Het bestand (MS-tools) wordt gemarkeerd met de ADS waar het vandaan komt (zone). De link heb je al gepost. Het rare is dus dat MS-tools de boel netjes markeren in Windows (hiermee veiliger is) en dat veel andere tools dat niet doen.

Je moet de foute bestanden ook niet herkennen aan de hand van de extensie. Je komt dat zo vaak tegen in mail
scanners, als er een mogelijkheid is om executables of compressed archives te blokkeren dan gebeurt dat heel vaak
alleen op extensie. De goede methode is uiteraard om de header en/of trailer van de file te bekijken. Dit is wat onder
Unix/Linux het commando "file" doet.

@Erik, het wordt een semantische discussie, maar titel en inhoud kloppen wel :)
zip is zoals je zegt een archiefbestand. Als er wordt aangeraden archiefbestanden te blokkeren, wordt dus ook aangeraden zip te blokkeren. Hetzelfde als de dokter zegt dat je geen chocola mag, dan mag je dus ook geen mars.

Daarnaast verspreidt de meeste ransomware zich via zip is en is zip het enige archiefbestand dat Windows standaard kan openen afaik.

Dat geeft weer andere problemen. Ik weet nog dat ik een klant updates voor ons product (een exe file dus) moest mailen om te testen, en die kwam er niet door. "Rename de .exe maar naar .doc, dat komt er wel door. Renamen wij hem wel weer terug". Dat was wel veel gedoe en men zal dat natuurlijk niet bij onbekende afzenders doen maar de perceptie bij de meeste mensen bij die klant was "virusscanners zijn lastig en je moet leren er omheen te werken".

Ja maar bij een scanner die ook maar enigszins een knip voor de neus waard is werkt dat dus niet!
Bij de scanner die ik op het werk gemaakt heb kun je gerust een exe renamen naar .doc, die dan zippen en de zipfile
renamen naar .jpg, het resultaat in een arj file stoppen en die renamen naar .txt en dat dan mailen als attachment, en dan
nog wordt het feilloos geblokkeerd als "bevat een executable".
Maar inderdaad, de meeste producten van gerenommeerde leveranciers die gaan hier hardstikke nat op.

Het verhaal van de "software restriction policy" is wel goed. Het staat er een beetje krom, maar met een dergelijke
policy kun je het uitvoeren van allerlei al dan niet per ongeluk overgehaalde executables heel goed voorkomen.
Het idee is dan dat software staat op locaties die de eindgebruiker niet kan beschrijven (de bekende mappen op de C:
schijf, en in een enkel geval misschien ergens een netwerkshare) en dat de uitvoering van executables op plekken waar
de gebruiker wel mag schrijven geblokkeerd is. Dat is dan inderdaad o.a. de AppData map.
Daardoor werkt het klikken op executable attachments in mails ook niet meer, want die worden in een bestand in de
tijdelijke directory neergezet OF ze worden gesaved op een plek waar de gebruiker mag schrijven (mijn documenten of
downloads mappen) en daar dan gestart. En dat mag dan dus niet.

Het sturen van software updates zal dan begeleid moeten worden door een beheerder die het bestand plaatst op een
locatie waar het wel uitgevoerd mag worden.

Is het niet beter een platform te gebruiken dat niet vatbaar is voor .exe en .zip infecties ?
De meeste platformen, op die van Microsoft na, zijn hier redelijk immuun voor.

Als je persé een exe wilt versturen en het gaat niet via email, renamen van extensie of via wetransfer, dan kan je altijd nog bmp-packer (http://www.jens-goedeke.eu/tools/bmppacker/) toepassen. Het nadeel is wel dat zender en ontvanger dit programma op zijn PC moet kunnen en mogen installeren. Bmp-packer maakt aan de zendende kant van een exe-bestand een bmp-bestand wat meestal wel te versturen is. Aan de ontvangende kant kan deze bmp-bestand eenvoudig weer omgezet worden naar een exe-bestand.

Als ik exe bestanden verstuur hernoem ik ze eerst. Aan de ontvanger meld ik vervolgens dat ze de extensie kunnen veranderen.

optioneel windows bijkopen, of Linux laptops verkopen.

U heeft het over bdrijven, Ik heb al 2 laptops afgenomen van dell, als thuisgebruiker.
levering is een ramp, maar de producten zijn goed en erg Linux vriendelijk.

Uhmm... Heeft Dell misschien een nieuwe release binnen zijn Sonicwall portfolio op touw staan?

"bedrijven moeten zip- en exe-bestanden blokkeren"

Dat moeten ze al sinds e-mail bestaat. Zijn ze lekker snel mee.

Zip is een zeer gemakkelijke tool om (bedijfs)vertrouwelijke informatie eenvoudig uit te wisselen. Natuurlijk met een goed password op het archief. En als er een goed wachtwoord op staat, weet je ook van wie de file komt. Dan kan je de file met meer vertrouwen uitpakken. Anti-malware zal dan de file(s) alsnog scannen. Ik zou zip files dus juist niet blokkeren.
En ZIP files zonder wachtwoord kunnen gemakkelijk door een goede malware scanner bekeken worden.

En al die blokkades hebben geen enkele zin als gebruikers gewoon hun hotmail/gmail of andere webmail kunnen open en via die weg alsnog hun alles verwoestende zipjes met nepfacturen kunnen openen...

Succes iedereen met al je mailfilters maar vergeet de via SSL versleutelde webmail diensten niet!

Veel beter idee: pak je grootste beveiligings probleem eens aan, ook wel bekend onder de naam gebruiker... en dat doe je niet met een technische oplossing...