Computerbeveiliging
- Hoe je bad guys buiten de deur houdt
Waarom DMARC (+SPF +DKIM)
Gisteren ontving ik 2 (vermoedelijke) spams aan de hand waarvan je goed kunt zien waarom zowel SPF, DKIM als DMARC noodzakelijk zijn om e-mails met vervalste afzenderadressen te kunnen blokkeren. Dus, in navolging van Briolet, die in dit forum al geruime tijd pleit voor DMARC, het volgende.
De spams hadden nagenoeg identieke headers, ik toon de relevante uit de eerste (ik heb op enkele plaatsen wijzigingen doorgevoerd, te herkennen aan "REDACTED" en "REDACTED-AT-", en ik heb er voor elke regel een nummer gezet):
Nb. "REDACTED-AT-xs4all.nl" is steeds mijn e-mail adres, waar "REDACTED-AT-" in "REDACTED-AT-gmail.com" staat, kun je dat lezen als "ashley.nivers@" (ik weet niet of dat account bestaat, en zo ja, of zij de werkelijke afzender is van deze spams).
Regel 04 wordt door mailservers als 1 regel geïnterpreteerd (het kan zijn dat de regel die begint met "h=" wrapped/omklapt omdat deze te lang is in deze webpagina).
De gebruikte mailclient (roundcube.xs4all.nl) toont de volgende kop van het bericht:
Analyse
In de regels 06 en 21 zien we dat de getoonde afzender ene "Ashley Nivers" is met een GMail account. Dat adres is waarschijnlijk vervalst. Daarbij vallen de regels 18 en 22 bijzonder op (deze suggereren dat de mail is geforward). Ik zie drie mogelijkheden:
A) Mogelijk wordt geprobeerd de suggestie te wekken dat Ashley Rivers, met haar GMail account, e-mail verstuurt via ip8.rp01.net (en daar niet, zoals gebruikelijk, daar gewoon de uitgaande GMail servers voor gebruikt);
B) Ook denkbaar is dat er helemaal geen sprake is van een GMail account en dat alles gespoofed wordt;
C) Ten slotte is denkbaar (maar iet erg waarschijnlijk) dat echt iemand met een GMail account dit doet, wellicht om spamfilters voor uitgaande mail bij GMail te omzeilen.
Voor deze discussie is met name regel 02 van belang. Hierin zien we:
spf=pass
dkim=pass
dmarc=fail (header.from=gmail.com)
Waarom deze mail toch niet als spam wordt geweigerd, leg ik verderop uit.
In regel 03 zien we dat xs4all de mail ontvangen heeft van IP adres 37.97.66.47 (buiten SPF, DKIM en DMARC het enige betrouwbare gegeven in een e-mail). Aangezien ip8.rp01.net resolvt (met nslookup) naar dat IP-adres, ga ik ervan uit dat ook dat klopt. Deze server lijkt in Roemenië te staan. De andere spam die ik gisteren ontving is verzonden vanaf ip12.rp01.net.
Vanaf *.rp01.net mailservers lijkt regelmatig spam te worden verzonden (op bijv. https://raw.githubusercontent.com/ktsaou/blocklist-ipsets/master/iw_spamlist.ipset staan momenteel 37.97.66.43 en
37.97.66.64 van resp. ip4.rp01.net {correctie 09-03-2016, 13:23 - er stond ip8.rp01.net} en ip25.rp01.net).
SPF
De oorspronkelijke naam voor SPF is "Sender Permitted From". Later is dit omgedoopt in "Sender Policy Framework". SPF is, hoewel destijds anders geadverteerd, geen middel tegen spam omdat met SPF niet het (in mail clients) zichtbare From: veld op vervalsing wordt gecontroleerd, maar het (in mail clients) onzichtbare "Return-Path" of "Envelope-From". Bovendien mag dat veld leeg zijn.
Een ander nadeel van SPF is dat het forwarding kapot maakt. Om dat ongedaan te maken moeten tussenliggende mailservers een andere truc uithalen, die vereist dat "state" wordt bijgehouden. Wat SPF wel helpt bestrijden, is "backscatter" (bounces/DSN's) van niet afleverbare spam waarbij jouw mailserver (of volledige e-mail adres) is vervalst (de zogenaamde "Joe-job"). Pas in combinatie met zowel DKIM als DMARC kan het echt helpen om spam te bestrijden.
Regel 01 bevat de "Envelope-From" header, oftewel Return-Path. Deze wordt gebruikt als mail eerst door een mailserver wordt geaccepteerd, en daarna pas blijkt dat de mail niet kan worden afgeleverd (bijv. omdat de mailbox van de ontvanger vol is). Duidelijk is dat in deze regel rekening gehouden is met SPF en haar probleem met forwarding, anders had daar wel <REDACTED-AT-gmail.com> gestaan. Waar een eventuele bounce (DSN = Delivery Status Notification) uiteindelijk naartoe gaat, kun je hier niet uit afleiden.
Als een ontvangende mailservers SPF checks uitvoert (xs4all doe dat, zie regel 02), werkt dat als volgt:
- De zendende server is ip8.rp01.net
- De ontvangende mailserver doet een DNS lookup, type TXT, voor die domainname. Je kunt dat zelf nadoen op de commandline door nslookup te starten, en dan in te voeren (steeds achter de > tekentjes):
Het "include" statement betekent dat we verder moeten zoeken (uitgangspunt: nslookup type is nog steeds TXT):
Aangezien het IP-adres van de zendende mailserver, 37.97.66.47, binnen de reeks 37.97.66.40/29 (=37.97.66.40 t/m 37.97.66.47) valt, keurt de ontvangende XS4all mailserver deze mail goed qua SPF.
DKIM
Regel 04 bevat een DKIM header, toegevoegd door de zendende mailserver ip8.rp01.net. In de tekst achter "h=" kun je zien over welke velden een digitale handtekening is geplaatst (door de zendende mailserver). De handtekening vind je, BASE64 gecodeerd, achter "bh". De public key, nodig om de handtekening te valideren, kun je weer opvragen uit DNS middels een TXT record. De (fictieve) domainname daarvoor moet je eerst samenstellen door achter elkaar te plakken:
- De selector (veld "s=") uit de DKIM header;
- De tekst "._domainkey.";
- De domainname van de zendende mailserver (veld "d=")
Dat wordt dus: mta0._domainkey.ip8.rp01.net (uitgangspunt: nslookup type is nog steeds TXT):
De ontvangende XS4all mailserver heeft dit duidelijk ook gedaan, en vastgesteld dat de handtekening klopt. Dat betekent dat ip8.rp01.net garandeert dat een heel stel velden in de e-mail authentiek zijn, waaronder het (in mailclients getoonde) From: veld. En dat is een leugen, want ip8.rp01.net is niet van Google en hoort geen mail te sturen namens GMail gebruikers.
Belangrijker: dit maakt duidelijk waarom je, in dit soort situaties, ook niks hebt aan DKIM. Immers, de handtekening is gezet door een niet te vertrouwen server. Mocht deze mail daadwerkelijk vanaf een ander e-mail account zijn verzonden, en zijn geforward door rp01.net, dan is denkbaar dat de oorspronkelijke mail reeds een DKIM header had, en dat deze door ip8.rp01.net is vervangen.
Gebruikelijker was (tot voor kort) dat spammers de hele DKIM header weglaten, maar vermoedelijk helpt zo'n header juist om spamfilters voor de gek te houden. Immers, zowel SPF als DKIM kloppen als een bus, terwijl de afzender waarschijnlijk vervalst is!
DMARC
In tegenstelling tot SPF en DKIM, haalt DMARC de domainname uit het (door mailclients getoonde) From: veld. Net als bij DKIM is sprake van een fictieve domainname. Echter, de informatie daarvoor haal je niet uit de headers, maar plak je als volgt achter elkaar:
- De tekst "_dmarc.";
- De domainname van de zendende mailserver uit het From: veld, dus gmail.com
Dat wordt dus: _dmarc.gmail.com (uitgangspunt: nslookup type is nog steeds TXT):
(vervang "REDACTED-AT-" door "mailauth-reports@").
Achter "p=" staat de policy, d.w.z. welke actie de ontvangende mailserver bij mismatches moet ondernemen, in dit geval "none" - dus niets. Met "rua=" wordt de ontvangende mailserver verzocht om dit soort incidenten wel te melden aan het opgegeven e-mail adres. Meer info hierover vind je onder https://dmarcian.com/dmarc-inspector/gmail.com.
Conclusie
Als GMail als policy "reject" had opgenomen:
- Had xs4all deze specifieke mail geweigerd;
- Is het dus veel lastiger om spam of phishing mails met vervalste afzenders te sturen.
Nb. als een account gehacked wordt, kan er natuurlijk nog wel spam of andere ongewenste mail vanaf dat e-mail afzenderadres worden verzonden; noch SPF, DKIM, DMARC (en wellicht PGP/GPG/GnuPG of S/MIME) helpen dat detecteren.
Om te voorkomen dat je malware- en/of phishingmails van bijv. scanner@jouwdomainname.tld ontvangt in jouw organisatie, raad ik aan:
1) Zorg voor backup mailservers die beschikbaar zijn als je primaire mailserver uitvalt (denk aan calamiteiten zoals brand, landurige stroomstoring etc. dus bij voorkeur bij een geheel andere provider);
2) Publiceer SPF, DKIM en DMARC records, voor al jouw uitgaande mailservers (ook bovengenoemde backups!);
3) Zorg dat al jouw uitgaande mailservers de juiste headers toevoegen;
4) Zorg dat al jouw ontvangende mailservers correct checken op SPF, DKIM en DMARC.
Het algemene advies is om, net als GMail doet, te beginnen met controleren (soft policies gebruiken) en laten melden (niet meteen blokkerende policies invoeren - daar kun je flink spijt van krijgen als zaken anders werken dan je denkt).
Meer informatie
Naast het gebruiken van zoekmachines, vind je meer (Nederlandstalige) info over SPF, DKIM en DMARC in het PDF document te vinden via https://www.ncsc.nl/actueel/factsheets/factsheet-bescherm-domeinnamen-tegen-phishing.html.
Nb. in de PDF v1.0 van NCSC staat een fout bij SPF (dit heb ik aan NCSC gemeld kort na publicatie):
De spams hadden nagenoeg identieke headers, ik toon de relevante uit de eerste (ik heb op enkele plaatsen wijzigingen doorgevoerd, te herkennen aan "REDACTED" en "REDACTED-AT-", en ik heb er voor elke regel een nummer gezet):
01) Return-Path: <sr.BHZsA7Zac0eNQBFoAOH3sg.DVGRxT-tQkawWF578MNNaA@ip8.rp01.net>
02) Authentication-Results: xs4all.nl; spf=pass smtp.mailfrom=ip8.rp01.net;
dkim=pass header.d=ip8.rp01.net; dmarc=fail header.from=gmail.com
03) Received: from ip8.rp01.net (ip8.rp01.net [37.97.66.47])
by mxdrop303.xs4all.net (8.14.9/8.14.9/Debian-xs4all~5) with ESMTP id u28ArKwE018037
for <REDACTED-AT-xs4all.nl>; Tue, 8 Mar 2016 11:53:22 +0100
04) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1457434402; s=mta0;
d=ip8.rp01.net;
h=Date:From:Reply-To:To:Message-ID:Subject:MIME-Version:Content-Type:List-Unsubscribe:Sender;
bh=aV+DO5cNnYZfGf9P5KwFzXkssoue7LAFACRw7t3FufQ=;
b=W6ETsXktOsCzlBFOsiOWc05ATPxPfs8r8/p8+jljE2XxkQDIQFiXHrYn3V2HA9P1
PXJos4qi6FuCpH4HuExKRLqVPdAHLhGr0gFuwmmGMNE9onjfAcGob5P543rn2LZW6IB
1FRBH0ckeoE9+shwzheHlTLzMSPPrH2d9zFggj4I=
05) Date: Tue, 8 Mar 2016 11:53:20 +0100 (CET)
06) From: Ashley Nivers <REDACTED-AT-gmail.com>
07) Reply-To: Ashley Nivers <REDACTED-AT-gmail.com>
08) To: <REDACTED-AT-xs4all.nl>
09) Message-ID: <sr.BHZsA7Zac0eNQBFoAOH3sg.DVGRxT-tQkawWF578MNNaA@ip8.rp01.net>
10) Subject: INVITATION TO THE F5 FORUM
11) MIME-Version: 1.0
12) Content-Type: multipart/alternative;
boundary="----=_Part_18182_1632990917.1457434391885"
13) List-Unsubscribe: <http://eye.sbc35.com/REDACTED>
14) x-priority: 3
15) importance: normal
16) Organization:
17) Feedback-ID: 37638:REDACTED:none:Sarbacane
18) Sender: ashley.nivers=gmail.com@ip8.rp01.net
19) Envelope-To: REDACTED-AT-xs4all.nl
02) Authentication-Results: xs4all.nl; spf=pass smtp.mailfrom=ip8.rp01.net;
dkim=pass header.d=ip8.rp01.net; dmarc=fail header.from=gmail.com
03) Received: from ip8.rp01.net (ip8.rp01.net [37.97.66.47])
by mxdrop303.xs4all.net (8.14.9/8.14.9/Debian-xs4all~5) with ESMTP id u28ArKwE018037
for <REDACTED-AT-xs4all.nl>; Tue, 8 Mar 2016 11:53:22 +0100
04) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1457434402; s=mta0;
d=ip8.rp01.net;
h=Date:From:Reply-To:To:Message-ID:Subject:MIME-Version:Content-Type:List-Unsubscribe:Sender;
bh=aV+DO5cNnYZfGf9P5KwFzXkssoue7LAFACRw7t3FufQ=;
b=W6ETsXktOsCzlBFOsiOWc05ATPxPfs8r8/p8+jljE2XxkQDIQFiXHrYn3V2HA9P1
PXJos4qi6FuCpH4HuExKRLqVPdAHLhGr0gFuwmmGMNE9onjfAcGob5P543rn2LZW6IB
1FRBH0ckeoE9+shwzheHlTLzMSPPrH2d9zFggj4I=
05) Date: Tue, 8 Mar 2016 11:53:20 +0100 (CET)
06) From: Ashley Nivers <REDACTED-AT-gmail.com>
07) Reply-To: Ashley Nivers <REDACTED-AT-gmail.com>
08) To: <REDACTED-AT-xs4all.nl>
09) Message-ID: <sr.BHZsA7Zac0eNQBFoAOH3sg.DVGRxT-tQkawWF578MNNaA@ip8.rp01.net>
10) Subject: INVITATION TO THE F5 FORUM
11) MIME-Version: 1.0
12) Content-Type: multipart/alternative;
boundary="----=_Part_18182_1632990917.1457434391885"
13) List-Unsubscribe: <http://eye.sbc35.com/REDACTED>
14) x-priority: 3
15) importance: normal
16) Organization:
17) Feedback-ID: 37638:REDACTED:none:Sarbacane
18) Sender: ashley.nivers=gmail.com@ip8.rp01.net
19) Envelope-To: REDACTED-AT-xs4all.nl
Regel 04 wordt door mailservers als 1 regel geïnterpreteerd (het kan zijn dat de regel die begint met "h=" wrapped/omklapt omdat deze te lang is in deze webpagina).
De gebruikte mailclient (roundcube.xs4all.nl) toont de volgende kop van het bericht:
20) Subject: INVITATION TO THE F5 FORUM
21) From Ashley Nivers <REDACTED-AT-gmail.com>
22) Sender ashley.nivers=gmail.com@ip8.rp01.net
23) To REDACTED-AT-xs4all.nl
24) Date Tue 11:53
25) Priority Normal
26) Mailing List Unsubscribe
21) From Ashley Nivers <REDACTED-AT-gmail.com>
22) Sender ashley.nivers=gmail.com@ip8.rp01.net
23) To REDACTED-AT-xs4all.nl
24) Date Tue 11:53
25) Priority Normal
26) Mailing List Unsubscribe
Analyse
In de regels 06 en 21 zien we dat de getoonde afzender ene "Ashley Nivers" is met een GMail account. Dat adres is waarschijnlijk vervalst. Daarbij vallen de regels 18 en 22 bijzonder op (deze suggereren dat de mail is geforward). Ik zie drie mogelijkheden:
A) Mogelijk wordt geprobeerd de suggestie te wekken dat Ashley Rivers, met haar GMail account, e-mail verstuurt via ip8.rp01.net (en daar niet, zoals gebruikelijk, daar gewoon de uitgaande GMail servers voor gebruikt);
B) Ook denkbaar is dat er helemaal geen sprake is van een GMail account en dat alles gespoofed wordt;
C) Ten slotte is denkbaar (maar iet erg waarschijnlijk) dat echt iemand met een GMail account dit doet, wellicht om spamfilters voor uitgaande mail bij GMail te omzeilen.
Voor deze discussie is met name regel 02 van belang. Hierin zien we:
spf=pass
dkim=pass
dmarc=fail (header.from=gmail.com)
Waarom deze mail toch niet als spam wordt geweigerd, leg ik verderop uit.
In regel 03 zien we dat xs4all de mail ontvangen heeft van IP adres 37.97.66.47 (buiten SPF, DKIM en DMARC het enige betrouwbare gegeven in een e-mail). Aangezien ip8.rp01.net resolvt (met nslookup) naar dat IP-adres, ga ik ervan uit dat ook dat klopt. Deze server lijkt in Roemenië te staan. De andere spam die ik gisteren ontving is verzonden vanaf ip12.rp01.net.
Vanaf *.rp01.net mailservers lijkt regelmatig spam te worden verzonden (op bijv. https://raw.githubusercontent.com/ktsaou/blocklist-ipsets/master/iw_spamlist.ipset staan momenteel 37.97.66.43 en
37.97.66.64 van resp. ip4.rp01.net {correctie 09-03-2016, 13:23 - er stond ip8.rp01.net} en ip25.rp01.net).
SPF
De oorspronkelijke naam voor SPF is "Sender Permitted From". Later is dit omgedoopt in "Sender Policy Framework". SPF is, hoewel destijds anders geadverteerd, geen middel tegen spam omdat met SPF niet het (in mail clients) zichtbare From: veld op vervalsing wordt gecontroleerd, maar het (in mail clients) onzichtbare "Return-Path" of "Envelope-From". Bovendien mag dat veld leeg zijn.
Een ander nadeel van SPF is dat het forwarding kapot maakt. Om dat ongedaan te maken moeten tussenliggende mailservers een andere truc uithalen, die vereist dat "state" wordt bijgehouden. Wat SPF wel helpt bestrijden, is "backscatter" (bounces/DSN's) van niet afleverbare spam waarbij jouw mailserver (of volledige e-mail adres) is vervalst (de zogenaamde "Joe-job"). Pas in combinatie met zowel DKIM als DMARC kan het echt helpen om spam te bestrijden.
Regel 01 bevat de "Envelope-From" header, oftewel Return-Path. Deze wordt gebruikt als mail eerst door een mailserver wordt geaccepteerd, en daarna pas blijkt dat de mail niet kan worden afgeleverd (bijv. omdat de mailbox van de ontvanger vol is). Duidelijk is dat in deze regel rekening gehouden is met SPF en haar probleem met forwarding, anders had daar wel <REDACTED-AT-gmail.com> gestaan. Waar een eventuele bounce (DSN = Delivery Status Notification) uiteindelijk naartoe gaat, kun je hier niet uit afleiden.
Als een ontvangende mailservers SPF checks uitvoert (xs4all doe dat, zie regel 02), werkt dat als volgt:
- De zendende server is ip8.rp01.net
- De ontvangende mailserver doet een DNS lookup, type TXT, voor die domainname. Je kunt dat zelf nadoen op de commandline door nslookup te starten, en dan in te voeren (steeds achter de > tekentjes):
> set type=TXT
> ip8.rp01.net
Server: google-public-dns-a.google.com
Address: 8.8.8.8
Non-authoritative answer:
ip8.rp01.net text =
"v=spf1 include:spf.rp01.net -all"
> ip8.rp01.net
Server: google-public-dns-a.google.com
Address: 8.8.8.8
Non-authoritative answer:
ip8.rp01.net text =
"v=spf1 include:spf.rp01.net -all"
> spf.rp01.net
Server: google-public-dns-a.google.com
Address: 8.8.8.8
Non-authoritative answer:
spf.rp01.net text =
"v=spf1 ip4:37.97.66.40/29 ip4:37.97.66.48/28 ip4:37.97.66.64/27 ip4:37.97.66.96/30 ip4:37.97.66.100/32 -all"
Server: google-public-dns-a.google.com
Address: 8.8.8.8
Non-authoritative answer:
spf.rp01.net text =
"v=spf1 ip4:37.97.66.40/29 ip4:37.97.66.48/28 ip4:37.97.66.64/27 ip4:37.97.66.96/30 ip4:37.97.66.100/32 -all"
DKIM
Regel 04 bevat een DKIM header, toegevoegd door de zendende mailserver ip8.rp01.net. In de tekst achter "h=" kun je zien over welke velden een digitale handtekening is geplaatst (door de zendende mailserver). De handtekening vind je, BASE64 gecodeerd, achter "bh". De public key, nodig om de handtekening te valideren, kun je weer opvragen uit DNS middels een TXT record. De (fictieve) domainname daarvoor moet je eerst samenstellen door achter elkaar te plakken:
- De selector (veld "s=") uit de DKIM header;
- De tekst "._domainkey.";
- De domainname van de zendende mailserver (veld "d=")
Dat wordt dus: mta0._domainkey.ip8.rp01.net (uitgangspunt: nslookup type is nog steeds TXT):
> mta0._domainkey.ip8.rp01.net
Server: google-public-dns-a.google.com
Address: 8.8.8.8
Non-authoritative answer:
mta0._domainkey.ip8.rp01.net text =
"k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDm8LOXQhq/UV16zgXP/qVqwtwNdiRLGVXWdQeLsOLSC6vAnib0wWFjXq2391OwtOmLjVut1l1U8WrQZQGNXiB3wANyN86tQOs9ER2WaMXBxpqqNRU/vd498PwjWXi47Zn+uWXf2tbH2Qd41O
xROvplBgrHTm5dHfG60eflSpTIdQIDAQAB"
Server: google-public-dns-a.google.com
Address: 8.8.8.8
Non-authoritative answer:
mta0._domainkey.ip8.rp01.net text =
"k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDm8LOXQhq/UV16zgXP/qVqwtwNdiRLGVXWdQeLsOLSC6vAnib0wWFjXq2391OwtOmLjVut1l1U8WrQZQGNXiB3wANyN86tQOs9ER2WaMXBxpqqNRU/vd498PwjWXi47Zn+uWXf2tbH2Qd41O
xROvplBgrHTm5dHfG60eflSpTIdQIDAQAB"
Belangrijker: dit maakt duidelijk waarom je, in dit soort situaties, ook niks hebt aan DKIM. Immers, de handtekening is gezet door een niet te vertrouwen server. Mocht deze mail daadwerkelijk vanaf een ander e-mail account zijn verzonden, en zijn geforward door rp01.net, dan is denkbaar dat de oorspronkelijke mail reeds een DKIM header had, en dat deze door ip8.rp01.net is vervangen.
Gebruikelijker was (tot voor kort) dat spammers de hele DKIM header weglaten, maar vermoedelijk helpt zo'n header juist om spamfilters voor de gek te houden. Immers, zowel SPF als DKIM kloppen als een bus, terwijl de afzender waarschijnlijk vervalst is!
DMARC
In tegenstelling tot SPF en DKIM, haalt DMARC de domainname uit het (door mailclients getoonde) From: veld. Net als bij DKIM is sprake van een fictieve domainname. Echter, de informatie daarvoor haal je niet uit de headers, maar plak je als volgt achter elkaar:
- De tekst "_dmarc.";
- De domainname van de zendende mailserver uit het From: veld, dus gmail.com
Dat wordt dus: _dmarc.gmail.com (uitgangspunt: nslookup type is nog steeds TXT):
> _dmarc.gmail.com
Server: google-public-dns-a.google.com
Address: 8.8.8.8
Non-authoritative answer:
_dmarc.gmail.com text =
"v=DMARC1; p=none; rua=mailto:REDACTED-AT-google.com"
Server: google-public-dns-a.google.com
Address: 8.8.8.8
Non-authoritative answer:
_dmarc.gmail.com text =
"v=DMARC1; p=none; rua=mailto:REDACTED-AT-google.com"
Achter "p=" staat de policy, d.w.z. welke actie de ontvangende mailserver bij mismatches moet ondernemen, in dit geval "none" - dus niets. Met "rua=" wordt de ontvangende mailserver verzocht om dit soort incidenten wel te melden aan het opgegeven e-mail adres. Meer info hierover vind je onder https://dmarcian.com/dmarc-inspector/gmail.com.
Conclusie
Als GMail als policy "reject" had opgenomen:
- Had xs4all deze specifieke mail geweigerd;
- Is het dus veel lastiger om spam of phishing mails met vervalste afzenders te sturen.
Nb. als een account gehacked wordt, kan er natuurlijk nog wel spam of andere ongewenste mail vanaf dat e-mail afzenderadres worden verzonden; noch SPF, DKIM, DMARC (en wellicht PGP/GPG/GnuPG of S/MIME) helpen dat detecteren.
Om te voorkomen dat je malware- en/of phishingmails van bijv. scanner@jouwdomainname.tld ontvangt in jouw organisatie, raad ik aan:
1) Zorg voor backup mailservers die beschikbaar zijn als je primaire mailserver uitvalt (denk aan calamiteiten zoals brand, landurige stroomstoring etc. dus bij voorkeur bij een geheel andere provider);
2) Publiceer SPF, DKIM en DMARC records, voor al jouw uitgaande mailservers (ook bovengenoemde backups!);
3) Zorg dat al jouw uitgaande mailservers de juiste headers toevoegen;
4) Zorg dat al jouw ontvangende mailservers correct checken op SPF, DKIM en DMARC.
Het algemene advies is om, net als GMail doet, te beginnen met controleren (soft policies gebruiken) en laten melden (niet meteen blokkerende policies invoeren - daar kun je flink spijt van krijgen als zaken anders werken dan je denkt).
Meer informatie
Naast het gebruiken van zoekmachines, vind je meer (Nederlandstalige) info over SPF, DKIM en DMARC in het PDF document te vinden via https://www.ncsc.nl/actueel/factsheets/factsheet-bescherm-domeinnamen-tegen-phishing.html.
Nb. in de PDF v1.0 van NCSC staat een fout bij SPF (dit heb ik aan NCSC gemeld kort na publicatie):
~all: alle andere mailservers mogen geen e-mail versturen namens deze domeinnaam.
Dat kringeltje betekent soft fail, mail wordt dan niet geblokkeerd. Dat gebeurt pas bij "-all" (minnetje dus).Reacties (25)
Dus, in navolging van Briolet, die in dit forum al geruime tijd pleit voor DMARC, het volgende.
Te bescheiden. Volgens mij is het net andersom. Heeft hij dat ooit opgepikt naar aanleiding van het feit dat jijzelf daar over schreef. Geloof dat hij het daarna ging testen op de mailbox van zijn papa maar tegen diverse implementatie problemen aanliep en er daardoor ook over is blijven schrijven.Ideetje?
Ik zie dat er een add-on bestaat voor het checken van DKIM.
https://addons.mozilla.org/en-US/thunderbird/addon/dkim-verifier/
->> Tijd voor introductie van een DMARC / DKIM / SPF Verifier add-on?
Jij hebt de kennis en vast ook mensen in jouw netwerk die iets dergelijks zouden kunnen ontwikkelen en het daarmee aan de gebruikerskant wat check vriendelijker zouden kunnen maken.
Want ondanks de schitterend uitgebreide uitleg en je posting gericht lijkt te zijn op organisaties die over het algemeen al de ruime extra mogelijkheden om spam te filteren, isoleren en in quarantaine te plaatsen, zie ik de gemiddelde thuisgebruiker/zzp-er/klein-mkb-er dit soort checks niet uitvoeren.
En het is met name de groep die dat niet kan die veelal slachtoffer wordt van dubbelfoute spam, denk maar aan cryptolockers, en voor wie de gevolgen groter zijn door gebrek aan kennis en kunde ontstane calamiteiten weer te verhelpen.
Ik zie dat er een add-on bestaat voor het checken van DKIM.
https://addons.mozilla.org/en-US/thunderbird/addon/dkim-verifier/
->> Tijd voor introductie van een DMARC / DKIM / SPF Verifier add-on?
Jij hebt de kennis en vast ook mensen in jouw netwerk die iets dergelijks zouden kunnen ontwikkelen en het daarmee aan de gebruikerskant wat check vriendelijker zouden kunnen maken.
Want ondanks de schitterend uitgebreide uitleg en je posting gericht lijkt te zijn op organisaties die over het algemeen al de ruime extra mogelijkheden om spam te filteren, isoleren en in quarantaine te plaatsen, zie ik de gemiddelde thuisgebruiker/zzp-er/klein-mkb-er dit soort checks niet uitvoeren.
En het is met name de groep die dat niet kan die veelal slachtoffer wordt van dubbelfoute spam, denk maar aan cryptolockers, en voor wie de gevolgen groter zijn door gebrek aan kennis en kunde ontstane calamiteiten weer te verhelpen.
Mooie uitleg, maar ik zou deze checks zelf nooit uitvoeren. Teveel moeite. Ik heb momenteel mijn spamprobleem opgelost door al mijn bedrijfsemail te forwarden naar een gmail adres en dit gmail adres forward het weer terug naar mijn bedrijf. Ik ben ZZP'er dus ik heb niet te tijd en verantwoordelijkheid om dit goed in te richten. Ik weet dat google waarschijnlijk meekijkt, maar ik heb niks te verbergen. Ik sms alleen met mijn vriendin en mijn vrouw zie ik het lietste zo min mogelijk.
@Erik: dank voor de heldere analyse.
@ Anoniem 17:00: half om half. Erik heeft mij een jaar geleden duidelijk uitgelegd hoe SPF werkt. Tot dat moment had ik er inderdaad nog nooit van gehoord. Erik heeft toen ook duidelijk gemaakt dat SPF te misleiden is door spammers.
Mijn interesse in DMARC komt echter niet door Erik, maar doordat de mailserver op mijn Synology nas, plots DMARC ging ondersteunen. Ik ben toen diep in de werking ervan gedoken omdat het mij een sterk middel tegen spam met gespoofde afzenders lijkt. Implementatie ervan stelde in mijn geval niet veel voor doordat ik alles via de GUI van de nas kon instellen.
Op een kleine maiserver met maar een paar gebruikers, is het instellen van DMARC geen probleem. Echter, des te groter de organisatie wordt, des te complexer wordt de mail-struktuur en des te moeilijker wordt een goede implementatie omdat je geen legitieme mail wilt blokkeren. Daarom zie ik dat er steeds meer grote firma's een DMARC beleid in hun domein publiceren, maar de policy nog op 'none' laten staan.
In het voorbeeld van Erik wordt de mail toch nog doorgelaten omdat GMail de policy op none heeft staan. Afgelopen Oktober heeft GMail aangekondigd dat ze in Juli van dit jaar het DMARC beleid zullen aanscherpen: https://www.security.nl/posting/448417/Google+gaat+strenger+DMARC-beleid+voor+Gmail+doorvoeren.
DMARC helpt niet direct tegen spam, maar maakt dat je de afzender kunt vertrouwen. Het houdt alleen spam tegen die legitieme afzenders spooft.
Met dat forwarden zou ik overigens oppassen. Een afzender die een SPF beleid heeft die op hard fail staat, zal door GMail geblokkeerd worden, als zij de SPF policy strikt naleven. Zelf ben ik, vanwege het bouncen door de SPF bescherming van sommige verzenders, gestopt met het forwarden van mail. Ik haal ze vanuit die accounts nu op mijn server binnen via pop3. Gmail kun je ook instellen om andere accounts via pop3 in te lezen.
@ Anoniem 17:00: half om half. Erik heeft mij een jaar geleden duidelijk uitgelegd hoe SPF werkt. Tot dat moment had ik er inderdaad nog nooit van gehoord. Erik heeft toen ook duidelijk gemaakt dat SPF te misleiden is door spammers.
Mijn interesse in DMARC komt echter niet door Erik, maar doordat de mailserver op mijn Synology nas, plots DMARC ging ondersteunen. Ik ben toen diep in de werking ervan gedoken omdat het mij een sterk middel tegen spam met gespoofde afzenders lijkt. Implementatie ervan stelde in mijn geval niet veel voor doordat ik alles via de GUI van de nas kon instellen.
Op een kleine maiserver met maar een paar gebruikers, is het instellen van DMARC geen probleem. Echter, des te groter de organisatie wordt, des te complexer wordt de mail-struktuur en des te moeilijker wordt een goede implementatie omdat je geen legitieme mail wilt blokkeren. Daarom zie ik dat er steeds meer grote firma's een DMARC beleid in hun domein publiceren, maar de policy nog op 'none' laten staan.
In het voorbeeld van Erik wordt de mail toch nog doorgelaten omdat GMail de policy op none heeft staan. Afgelopen Oktober heeft GMail aangekondigd dat ze in Juli van dit jaar het DMARC beleid zullen aanscherpen: https://www.security.nl/posting/448417/Google+gaat+strenger+DMARC-beleid+voor+Gmail+doorvoeren.
Ik heb momenteel mijn spamprobleem opgelost door al mijn bedrijfsemail te forwarden naar een gmail adres en dit gmail adres forward het weer terug naar mijn bedrijf.
DMARC helpt niet direct tegen spam, maar maakt dat je de afzender kunt vertrouwen. Het houdt alleen spam tegen die legitieme afzenders spooft.
Met dat forwarden zou ik overigens oppassen. Een afzender die een SPF beleid heeft die op hard fail staat, zal door GMail geblokkeerd worden, als zij de SPF policy strikt naleven. Zelf ben ik, vanwege het bouncen door de SPF bescherming van sommige verzenders, gestopt met het forwarden van mail. Ik haal ze vanuit die accounts nu op mijn server binnen via pop3. Gmail kun je ook instellen om andere accounts via pop3 in te lezen.
10-03-2016, 17:00 door Anoniem:
Best mogelijk dat ik eerder wat over DMARC schreef, maar toen begreep ik de essentie nog niet zo goed. Simpel gesteld:Dus, in navolging van Briolet, die in dit forum al geruime tijd pleit voor DMARC, het volgende.
Te bescheiden. Volgens mij is het net andersom. Heeft hij dat ooit opgepikt naar aanleiding van het feit dat jijzelf daar over schreef.- SPF specifieert IP-adressen die mogen mailen namens de domainname in envelope-From: (onzichtbaar voor ontvangers)
- DKIM = digitale handtekening gezet namens de domainname (onzichtbaar voor ontvangers) genoemd in de DKIM header
- DMARC checkt of domainname in From: ("zichtbaar" voor ontvangers) overeenkomt met SPF- en DKIM domainname
SPF plus DMARC bieden de basis om phishing te voorkomen. In principe kan een spammer het envelope-From: veld leeg laten, waardoor de ontvangende mailserver niet kan bepalen of het zendende IP-adres legitiem is of niet. Echter, een leeg return-path (een andere benaming voor envelope-From) wordt, normaal gesproken, alleen gebruikt voor DSN's (Delivery Status Notifications) - om te voorkomen dat eindeloze bounces ontstaan. Bij zo'n message hoort een bepaalde content, en daar kunnen spamfilters op checken.
DKIM zorgt ervoor dat relevante velden, en het bericht zelf, niet meer kunnen worden veranderd na te zijn gesigneerd door de zendende server. Dat helpt ook replay-attacks voorkomen.
Overigens wordt forwarding (wat o.a. maillist servers doen) met SPF + DMARC weer lastiger, want de forwarding mailserver zal dan zowel het envelope-From als het (message-) From veld moeten aanpassen, en een eventuele DKIM header moeten verwijderen (of vervangen).
10-03-2016, 17:44 door Anoniem: Ik zie dat er een add-on bestaat voor het checken van DKIM.
https://addons.mozilla.org/en-US/thunderbird/addon/dkim-verifier/
Dank voor de tip, die kende ik nog niet! Daar ga ik zeker mee spelen.https://addons.mozilla.org/en-US/thunderbird/addon/dkim-verifier/
10-03-2016, 17:44 door Anoniem: ->> Tijd voor introductie van een DMARC / DKIM / SPF Verifier add-on?
Jij hebt de kennis en vast ook mensen in jouw netwerk die iets dergelijks zouden kunnen ontwikkelen en het daarmee aan de gebruikerskant wat check vriendelijker zouden kunnen maken.
Want ondanks de schitterend uitgebreide uitleg en je posting gericht lijkt te zijn op organisaties die over het algemeen al de ruime extra mogelijkheden om spam te filteren, isoleren en in quarantaine te plaatsen, zie ik de gemiddelde thuisgebruiker/zzp-er/klein-mkb-er dit soort checks niet uitvoeren.
Dat laatste is ook zeker niet mijn bedoeling, mailservers moeten dit gaan doen!Jij hebt de kennis en vast ook mensen in jouw netwerk die iets dergelijks zouden kunnen ontwikkelen en het daarmee aan de gebruikerskant wat check vriendelijker zouden kunnen maken.
Want ondanks de schitterend uitgebreide uitleg en je posting gericht lijkt te zijn op organisaties die over het algemeen al de ruime extra mogelijkheden om spam te filteren, isoleren en in quarantaine te plaatsen, zie ik de gemiddelde thuisgebruiker/zzp-er/klein-mkb-er dit soort checks niet uitvoeren.
Een eventuele plugin bereikt maar een zeer beperkt aantal gebruikers. Hoewel ik wel eens overwogen heb om een Firefox plugin te maken (ander doel) zie ik er flink tegenop om die bij elke FF update te moeten testen en evt. bijwerken (en heb daar feitelijk ook de tijd niet voor).
10-03-2016, 21:27 door Anoniem: Mooie uitleg, maar ik zou deze checks zelf nooit uitvoeren. Teveel moeite.
Hmm, achteraf had ik dat hierboven moeten toelichten denk ik... Mijn bedoeling was en is niet dat iedereen leert hoe je headers moet uitpluizen, maar zoals ik in mijn reactie aan de vorige anoniem schreef: dit is iets dat op alle mailservers zou moeten worden geïimplementeerd (zeker op zendende mailservers, want zonder dat valt er, ook met de hand, niks te checken).Mijn epistel is bedoeld om te laten zien waarom SPF+DKIM+DMARC nodig zijn, en bovendien laat het m.i. aardig zien dat een DKIM header an sich niet betekent dat het dan allemaal klopt (dergelijk misbruik had ik nog niet eerder gezien).
10-03-2016, 21:27 door Anoniem: Ik heb momenteel mijn spamprobleem opgelost door al mijn bedrijfsemail te forwarden naar een gmail adres en dit gmail adres forward het weer terug naar mijn bedrijf.
GMail heeft, als het mail ontvangt, in elk geval uitgebreide checks. Maar die werken alleen als de zendende mailservers SPF, DKIM en DMARC ondersteunen. Vandaar mijn pleidooi!10-03-2016, 21:27 door Anoniem: Ik sms alleen met mijn vriendin en mijn vrouw zie ik het lietste zo min mogelijk.
:-)Dank voor alle reacties!
Aanvulling: ik zie nu de reactie van Briolet, die ga ik morgen lezen - het is bedtijd...
11-03-2016, 11:03 door
[Account Verwijderd]
-
Bijgewerkt: 11-03-2016, 11:08
[Verwijderd]
Door Anoniem: Mooie uitleg, maar ik zou deze checks zelf nooit uitvoeren. Teveel moeite. Ik heb momenteel mijn spamprobleem opgelost door al mijn bedrijfsemail te forwarden naar een gmail adres en dit gmail adres forward het weer terug naar mijn bedrijf. Ik ben ZZP'er dus ik heb niet te tijd en verantwoordelijkheid om dit goed in te richten. Ik weet dat google waarschijnlijk meekijkt, maar ik heb niks te verbergen. Ik sms alleen met mijn vriendin en mijn vrouw zie ik het lietste zo min mogelijk.
:-)
Dan kun je beter je bedrijfsmail gewoon hosten bij google ?
Dan hoef je die forwarding-trombone niet te gebruiken.
11-03-2016, 14:48 door
Briolet
Door Erik van Straten: [Overigens wordt forwarding (wat o.a. maillist servers doen) met SPF + DMARC weer lastiger, want de forwarding mailserver zal dan zowel het envelope-From als het (message-) From veld moeten aanpassen, en een eventuele DKIM header moeten verwijderen (of vervangen).
Ik denk dat daar een groot 'pijnpunt' zit voor invoering. Als de beheerders van maillistings geen zaken aanpassen zullen daar mailtjes gaan bouncen. Wat de beheerders van maillistings moeten aanpassen, geeft de dmarc organisatie ook aan:
https://dmarc.org/wiki/FAQ#senders Iemand die zulke listings beheerd, zal die link zeker moeten doorlezen.
Het leerzame bij dmarc is dat je als eigenaar van een domein, dagelijks een overzichtsmailtje krijgt van alle mail die uit naam van jouw domein is verzonden. Het meeste wat in jouw naam van een vreemd IP adres is verzonden is legitiem, omdat het forwards betreft. Het heeft mij wel verbaasd hoe groot het percentage forwards is, in de totale mailstroom. Bij mij is dat grofweg een kwart van al mijn mail. SPF faalt bij forwards, maar voor DMARC is het voldoende als één van de twee onderliggende protocollen klopt.
Door MAC-user:Hoewel ik DMARC etc niet kende (en dus in de materie moest duiken) heb ik de Add-on in Thunderbird geïnstalleerd…
Ik gebruik geen Thunderbird maar heb het vanochtend eens geïnstalleerd met deze DKIM verifier. Daarbij zie ik direct een limitering van het checken in de mail cliënt zelf i.p.v. bij de mailprovider.
De maandelijkse mailings van Ziggo zijn dkim ondertekend en geven een dmarc pass in mijn mailserver. Echter, ik heb mijn mailserver zo geconfigureerd dat bepaalde html code ineffectief gemaakt wordt (b.v. javascript) Dus na verificatie van de mail, wordt de mail aangepast door de ontvangende mailserver. Ik kan me voorstellen dat dit ook door diverse bedrijfsservers gebeurd. Thunderbird laat nu zien dat de dkim ondertekening niet meer geldig is. In die gevallen krijgt dan false-negative meldingen.
De checks op dmarc (+ dkim en spf) zijn daarom primair zaken voor de mail provider en niet de mail gebruiker zelf. De mail gebruiker moet vooral weten dat deze checks bestaan en door zijn mailprovider met succes uitgevoerd zijn.
Als je eigen mail provider echter geen dkim checkt op inkomende mail, is deze check in Thunderbird zeker een zeer zinvolle toevoeging aan een mail-cliënt. Zeker omdat deze add-on ook direct aangeeft welk domein deze mail gesigneerd heeft.
12-03-2016, 11:21 door
Erik van Straten
Ecxuses, ik zie dat ik eergisteravond met mijn neus gelezen heb - ik zag Mozilla + plugin en heb finaal over Thunderbird heengelezen - ik ging domweg uit van Firefox!
Over een eventuele uitbreiding van de Thunderbird plugin: goed punt wat Briolet hierboven aanhaalt; SPF, DKIM, DomainKeys, SenderID en DMARC checks kunnen het beste door de ontvangende mailserver worden uitgevoerd.
Dat geldt zeker ook voor SPF en SenderID, want die checken op IP adressen en er is geen standaard manier (voor alle verschillende providers en organisaties met eigen mailservers) om het IP-adres van de "zendende" mailservers betrouwbaar uit "Received:" headers te halen.
En die IP-adres-check is onmisbaar om mails met vervalste afzender, of opnieuw verzonden oudere mails (replay atrack), te kunnen herkennen.
Met andere woorden: protocollen als SPF etc. zijn bedoeld voor communicatie tussen domains; voor end-to-end authenticatie, en eventueel encryptie, bestaan andere oplossingen (nauwelijks gebruikt, dat dan weer wel).
Over een eventuele uitbreiding van de Thunderbird plugin: goed punt wat Briolet hierboven aanhaalt; SPF, DKIM, DomainKeys, SenderID en DMARC checks kunnen het beste door de ontvangende mailserver worden uitgevoerd.
Dat geldt zeker ook voor SPF en SenderID, want die checken op IP adressen en er is geen standaard manier (voor alle verschillende providers en organisaties met eigen mailservers) om het IP-adres van de "zendende" mailservers betrouwbaar uit "Received:" headers te halen.
En die IP-adres-check is onmisbaar om mails met vervalste afzender, of opnieuw verzonden oudere mails (replay atrack), te kunnen herkennen.
Met andere woorden: protocollen als SPF etc. zijn bedoeld voor communicatie tussen domains; voor end-to-end authenticatie, en eventueel encryptie, bestaan andere oplossingen (nauwelijks gebruikt, dat dan weer wel).
12-03-2016, 18:29 door
Briolet
Ik heb nog eens naar de settings van die DKIM-verifier in Thunderbird gekeken. Hij ondersteunt ook een vorm van DMARC. Default staat dit uit, maar als je deze optie aan zet, kijkt hij of het afzend domein een DMARC policy heeft.
De meeste banken etc. hebben inmiddels een DMARC policy ingesteld, dus dan geeft Thunderbird een waarschuwing als de DKIM key ontbreekt bij spoofing. Ik heb het net getest door een mailtje uit naam van 'nl.abnamro.com' naar mijn Ziggo account te sturen. Ziggo laat die gewoon door (X-Ziggo-spamscore: 0.0), maar Thunderbird geeft nu aan dat de DKIM key mist.
Op zich mooi deze aanvullende DMARC test, maar je krijgt wel veel vals negatieve meldingen doordat diverse domeinen een DMARC instelling hebben maar nog niet alles ondertekenen. Ze hebben het beleid op 'none' staan, maar dat ignoreert Thunderbird.
b.v. Ziggo heeft een dmarc instelling, maar ondertekent alleen zijn mailings. Mail van privé personen wordt nog niet ondertekent en dan klaagt Thunderbird dat de mail niet ondertekend is. En bij veel vals-negatieve meldingen werkt zo'n waarschuwing niet. Dat zal ook de reden zijn waarom deze optie standaard uit staat.
Bij mailings wordt er vaak door een 3e partij DKIM ondertekend. Thunderbird laat dan zien dat het ondertekend is, maar plaatst er een gevaren driehoek bij als dat niet door het zichtbare afzend domein ondertekend is. Via de settings kun je echter allerlei regels aanmaken waarin je aangeeft welke partijen voor welk domein mogen ondertekenen, zodat die waarschuwingen verdwijnen. Maar als je dat gaat instellen, wordt het al zo ingewikkeld voor een leek, dat dit een expert mode is. En die kunnen ook gewoon zelf in de header kijken.
Ondanks alle mitsen is dit toch een aanrader voor Thunderbird gebruikers.
De meeste banken etc. hebben inmiddels een DMARC policy ingesteld, dus dan geeft Thunderbird een waarschuwing als de DKIM key ontbreekt bij spoofing. Ik heb het net getest door een mailtje uit naam van 'nl.abnamro.com' naar mijn Ziggo account te sturen. Ziggo laat die gewoon door (X-Ziggo-spamscore: 0.0), maar Thunderbird geeft nu aan dat de DKIM key mist.
Op zich mooi deze aanvullende DMARC test, maar je krijgt wel veel vals negatieve meldingen doordat diverse domeinen een DMARC instelling hebben maar nog niet alles ondertekenen. Ze hebben het beleid op 'none' staan, maar dat ignoreert Thunderbird.
b.v. Ziggo heeft een dmarc instelling, maar ondertekent alleen zijn mailings. Mail van privé personen wordt nog niet ondertekent en dan klaagt Thunderbird dat de mail niet ondertekend is. En bij veel vals-negatieve meldingen werkt zo'n waarschuwing niet. Dat zal ook de reden zijn waarom deze optie standaard uit staat.
Bij mailings wordt er vaak door een 3e partij DKIM ondertekend. Thunderbird laat dan zien dat het ondertekend is, maar plaatst er een gevaren driehoek bij als dat niet door het zichtbare afzend domein ondertekend is. Via de settings kun je echter allerlei regels aanmaken waarin je aangeeft welke partijen voor welk domein mogen ondertekenen, zodat die waarschuwingen verdwijnen. Maar als je dat gaat instellen, wordt het al zo ingewikkeld voor een leek, dat dit een expert mode is. En die kunnen ook gewoon zelf in de header kijken.
Ondanks alle mitsen is dit toch een aanrader voor Thunderbird gebruikers.
m.i. functionele side-topic tip
Nog een aanrader om Thunderbird te gebruiken
Een andere reden om Thunderbird aan te raden bij pavlov klikkers!
Om te voorkomen dat men een link in een mail aanklikt met alle te snelle gevolgen van dien?
Simpel SPAM Link gevolgen voorkomen met een tussenstap!
Met een Simpele oplossing in de about:config van Thunderbird aan te brengen!
1) Zoek onder de Thunderbird voorkeuren onder "advanced" en dan de "config editor" op:
Zet hem met een dubbelklik op de regel op de waarde
Daarna kan je klikken op elke actieve link in een mailbericht tot je twee tennis/muis/spam armen hebt,..
het zal geen url in je browser openen!
Oplossing is dan, als je per sé de link wel wil bekijken, even rustig handmatig een link te kopieren en te pasten in je url bar van de browser.
Heb je net even wat meer tijd om je af te vragen waar je precies mee bezig bent.
En omdat het moeite kost zal je in een aantal gevallen denken, "laat ook maar zitten, eigenlijk niet belangrijk".
2) Een waarschuwing instellen kan ook, dan krijg je een pop-up keuze met welke browser de link dan te openen,
ook een vorm van vertraging.
Je laat dan de eerder genoemde waarde wel op true staan maar verandert de volgende waarden.
Verander de volgende regels met een dubbelklik op de regel op een andere (dan de standaard) waarde
en
en
Of je een hardcore Outlooker ('uitkijker'?) kan overtuigen om een andere mailclient te gaan gebruiken is maar zeer de vraag.
Voor iemand die er nog aan moet beginnen en een beetje tegen zichzelf (dus klikgrage vinger) beschermd mag worden is deze meerwaarde onder Thunderbird zeker een aardige optie.
Ik heb er al eens eerder naar gehint op deze site maar dat kwam niet aan, vandaar dan een keer de hele uitleg erbij.
Dus zolang de DKIM SPF DMARC check opties nog niet altijd goed werken om wat voor reden dan ook, dan geeft Thunderbird nog een tweede beveiligingslaag bij SPAM mail met verleidelijke maar ongezonde links.
Doe er je voordeel mee of geef het door aan een ander!
(Mac)Groet
Nog een aanrader om Thunderbird te gebruiken
Een andere reden om Thunderbird aan te raden bij pavlov klikkers!
Om te voorkomen dat men een link in een mail aanklikt met alle te snelle gevolgen van dien?
Simpel SPAM Link gevolgen voorkomen met een tussenstap!
Met een Simpele oplossing in de about:config van Thunderbird aan te brengen!
1) Zoek onder de Thunderbird voorkeuren onder "advanced" en dan de "config editor" op:
network.protocol-handler.external-default
Zet hem met een dubbelklik op de regel op de waarde
false
Daarna kan je klikken op elke actieve link in een mailbericht tot je twee tennis/muis/spam armen hebt,..
het zal geen url in je browser openen!
Oplossing is dan, als je per sé de link wel wil bekijken, even rustig handmatig een link te kopieren en te pasten in je url bar van de browser.
Heb je net even wat meer tijd om je af te vragen waar je precies mee bezig bent.
En omdat het moeite kost zal je in een aantal gevallen denken, "laat ook maar zitten, eigenlijk niet belangrijk".
2) Een waarschuwing instellen kan ook, dan krijg je een pop-up keuze met welke browser de link dan te openen,
ook een vorm van vertraging.
Je laat dan de eerder genoemde waarde wel op true staan maar verandert de volgende waarden.
Verander de volgende regels met een dubbelklik op de regel op een andere (dan de standaard) waarde
network.protocol-handler.warn-external.https;false
naarnetwork.protocol-handler.warn-external.https;true
en
network.protocol-handler.warn-external.http;false
naarnetwork.protocol-handler.warn-external.http;true
en
network.protocol-handler.warn-external.ftp;false
naarnetwork.protocol-handler.warn-external.ftp;true
Of je een hardcore Outlooker ('uitkijker'?) kan overtuigen om een andere mailclient te gaan gebruiken is maar zeer de vraag.
Voor iemand die er nog aan moet beginnen en een beetje tegen zichzelf (dus klikgrage vinger) beschermd mag worden is deze meerwaarde onder Thunderbird zeker een aardige optie.
Ik heb er al eens eerder naar gehint op deze site maar dat kwam niet aan, vandaar dan een keer de hele uitleg erbij.
Dus zolang de DKIM SPF DMARC check opties nog niet altijd goed werken om wat voor reden dan ook, dan geeft Thunderbird nog een tweede beveiligingslaag bij SPAM mail met verleidelijke maar ongezonde links.
Doe er je voordeel mee of geef het door aan een ander!
(Mac)Groet
10-04-2016, 20:12 door
[Account Verwijderd]
-
Bijgewerkt: 10-04-2016, 20:12
[Verwijderd]
En dat is een leugen, want ip8.rp01.net is niet van Google en hoort geen mail te sturen namens GMail gebruikers..
Deze vind ik wat kort door de bocht, zeker in een tijd waar de meeste providers "om spam te voorkomen" je smtp sessie proberen tegen te houden (poort 25 dicht zetten) of zelfs zonder medeweten over hun eigen servers laten lopen....
Helaas, want dit maakt dit soort checks meteen een stuk minder betrouwbaar...
Door Anoniem:
Deze vind ik wat kort door de bocht, zeker in een tijd waar de meeste providers "om spam te voorkomen" je smtp sessie proberen tegen te houden (poort 25 dicht zetten) of zelfs zonder medeweten over hun eigen servers laten lopen....
Helaas, want dit maakt dit soort checks meteen een stuk minder betrouwbaar...
En dat is een leugen, want ip8.rp01.net is niet van Google en hoort geen mail te sturen namens GMail gebruikers..
Deze vind ik wat kort door de bocht, zeker in een tijd waar de meeste providers "om spam te voorkomen" je smtp sessie proberen tegen te houden (poort 25 dicht zetten) of zelfs zonder medeweten over hun eigen servers laten lopen....
Helaas, want dit maakt dit soort checks meteen een stuk minder betrouwbaar...
Je hoort je GMail af te leveren via de Google servers, natuurlijk niet op poort 25 maar op poort 587.
Als je provider dat niet toelaat is dat geen probleem met de check maar een probleem met jouw provider.
11-04-2016, 10:57 door
Erik van Straten
11-04-2016, 07:51 door Anoniem:
Deze vind ik wat kort door de bocht, zeker in een tijd waar de meeste providers "om spam te voorkomen" je smtp sessie proberen tegen te houden (poort 25 dicht zetten)
Dat deze uitstekende maatregel destijds op veel plaatsen (helaas nog lang niet bij alle ISP's) is ingevoerd, zou wel eens mijn "schuld" kunnen zijn (zie de lange quote hieronder).09-03-2016, 11:34 door Erik van Straten, Laatst bijgewerkt: 09-03-2016, 13:23: En dat is een leugen, want ip8.rp01.net is niet van Google en hoort geen mail te sturen namens GMail gebruikers..
Deze vind ik wat kort door de bocht, zeker in een tijd waar de meeste providers "om spam te voorkomen" je smtp sessie proberen tegen te houden (poort 25 dicht zetten)
Een goede provider zet egress verkeer naar TCP poort 25 -by default- dicht, en alleen open voor die enkeling die een eigen mailserver wenst te draaien (bijv. bij xs4all heb je deze keuze). Naast dat dit heel veel spam voorkomt, maakt dit SOHO (Small Office/Home Office) PC's ook een minder aantrekkelijk doelwit voor botnetbeheerders.
Spam (o.a. met ransomware) die ik ontvang zie ik de laatste jaren nooit meer afkomstig zijn van Nederlandse IP-adressen. Ra ra hoe komt dat?
11-04-2016, 07:51 door Anoniem: of zelfs zonder medeweten over hun eigen servers laten lopen....
Voor uitgaande mail (en daar hebben we het hierover) kan dat niet, dat stel je zelf in. Daarnaast is dit een non-issue, want de bijna iedereen die ik ken gebruikt GMail of Hotmail. En het is volkomen terecht dat de uitgaande mailservers van GMail en Hotmail geen bulk-mail toestaan.Met als gevolg dat spammers, die wel graag "<REDACTED-AT-gmail.com>" achter "From:" gebruiken -in een poging spamfilters voor de gek te houden- niet via GMail servers zelf kunnen spammen, en zich dus in allerlei bochten proberen te wringen. Vandaar mijn bovenstaande bijdrage.
11-04-2016, 07:51 door Anoniem: Helaas, want dit maakt dit soort checks meteen een stuk minder betrouwbaar...
Waarom?Uit mijn archief:
From: "Erik van Straten" <evs@cpo.tn.tudelft.nl>
Organization: Charged Particle Optics group - TU Delft
To: Dunet-Discussie@[redacted].tudelft.nl
Date: Mon, 13 Jan 2003 18:46:31 +0100
Subject: Voorstel: kanaliseren van TUD-uitgaande email
Collega's,
De laatste weken vliegen nieuwe computervirussen en andere malware de meeste internetters weer om de oren; hier bij de TU Delft lijken we daarvan verschoond te blijven. Hoewel de meest kwetsbare personen daarvoor in mijn sectie (waaronder de secretaresse) altijd een virusscanner draaien, kost het bij een detectie elke keer veel tijd om uit te leggen wat er aan de hand is, en dat de PC niet besmet is als zo'n virus in quarantaine is gezet; heerlijk dat me dat al geruime tijd bespaard is gebleven. Mocht dit mede mogelijk zijn gemaakt door persoonlijk ingrijpen van de beheerders van de emailscanner op mailhost1/2 tijdens de kerstvakantie, dan wil ik bij deze diegenen daarvoor hartelijk bedanken!
Omdat virussen ook op andere manieren binnen kunnen komen, en die scanners zo goed werken, stel ik voor om ook alle TU Delft-UITGAANDE email via mailhost1.tudelft.nl (of mailhost2) te sturen (of andere mailservers die aan bepaalde voorwaarden voldoen), en dat je dat ook afdwingt. Ik vermoed dat dit een gevoelig punt is, maar ik bedoel uitbreiding van de (bestaande) TCP poort 25 blokkade met uitgaande connecties.
Waarom?
(1) Omdat virussen/trojans/wormen en andere malware ook via andere wegen binnen kunnen komen. Dat kan bijv. alsnog via email in gezipte c.q. encrypted attachments, maar ook KaZaa, ICQ, IRC en online games zijn de laatste tijd populair bij virusbakkers. Met buffer overflows in WinAmp kunnen zelfs MP3's executable code bevatten, en ook al is je hele binnenband oranje van de plakkers, MSIE blijft lek. Als je poort 25 naar buiten blokkeert, kan malware met een eigen SMTP engine op een gecomprimiteerde PC ofwel niets beginnen, of wordt gedwongen om via een van de voorgeschreven mailservers te communiceren, en is daarmee vermoedelijk eenvoudiger van de buitenwereld af te sluiten. Zie ook de recente discussie op securityfocus, waarbij een zeelandnet PC werd "afgesloten" maar dat kennelijk niet hielp (zie onderaan die message):
http://online.securityfocus.com/archive/75/306360
(2) Omdat malware soms zo nieuw is dat deze niet door virusscanners wordt herkend. Meestal zit er enige vertraging tussen het "afleveren" van email en het openen ervan (een "slimme" virusverspreider zal dat op vrijdagavond doen, of aan het begin van een vakantieperiode); als de virusdefinities in de tussentijd zijn geupdate kan worden voorkomen dat de malware naar buiten de TU Delft verder wordt verspreid (en als je van rate-limiting gebruik maakt, kan het aantal binnen de perken worden gehouden, en je detectiemogelijkheden zijn natuurlijk veel beter). Zie mijn rapportage over een spam+trojan (die zo nieuw was dat sophos hem niet herkende; ik heb de betreffende email o.a. naar Sophos gezonden waarop Sophos ons updated definities heeft teruggestuurd):
http://listserv.surfnet.nl/scripts/wa.exe?A2=ind02&L=cert-nl-bulletins&F=&S=&P=6621
(3) Omdat ik me grote zorgen maak over spam. De bovenstaande rapportage heeft betrekking op het planten van backdoors op PC's, waarmee het doel vermoedelijk is om via zo'n PC spam te versturen. Als er vanuit de TU Delft spam wordt verzonden, en de hele TU IP-range belandt daarmee op blacklists van derden, hebben wij boter op ons hoofd als we daar wat op aan te merken hebben; immers, we maken zelf gebruik van dergelijke blacklists. De laatste tijd zie ik in HTTP logs op m'n webservers veel entries van spammers die zoeken naar formmail scripts (vooral pornospam wordt via webservers met dergelijke scripts gerelayed, de email begint dan meestal met iets als "Below is the result of your feedback form", en de reden dat hier zoveel naar gescanned wordt zou best kunnen zijn dat veel universiteiten unix/linux dozen draaien met dergelijke, wijd openstaande, formmail scripts). Maar ook (arme) studenten zouden in de verleiding kunnen komen om wat bij te verdienen als spammer. Natuurlijk kun je ze daarna straffen, maar we weten allemaal dat het makkelijker is om op blacklists te belanden dan om ervan afgehaald te worden. In het verleden heb ik ZELF wel eens meegeholpen om veel mensen via email uit te nodigen voor een conferentie, en dat op basis van een oude adreslijst; hoewel we toen (1997/1998) geen klachten hebben ontvangen, zou het me niet verbazen als dat nu anders zou zijn. Eventueel noodzakelijke bulk-email zou m.i. niet zomaar vanaf elke PC verzonden moeten kunnen worden.
Voorstel:
Sta niet toe dat elke PC poort 25 connecties naar buiten de TU Delft kan maken; beperk dit tot een aantal mailservers die aan een aantal (nader vast te stellen) criteria voldoen, zoals een virusscanner waarvan de definities vaker dan 1x per week worden geupdate, en waarop bij voorkeur een rate-limiter is ingesteld (waarmee het aantal emails per uur vanaf een PC wordt beperkt). Ook zou je emails met waslijsten aan email-adressen in het To: veld kunnen blokkeren (steeds meer mensen, waaronder ondergetekende, worden gallisch van alle spam die ze krijgen, en beschouwen hun email adres als iets persoonlijks dat niet de hele wereld hoeft te kennen - ik wil nog net niet zover gaan om naar deze lijst zelf een gemanipuleerd antispam adres te gebruiken, maar dat moment komt misschien ook nog wel eens).
Mocht een PC besmet raken met malware die zichzelf via email probeert te verspreiden, dan zal dat helemaal niet lukken als deze gebruik maakt van directe adressering of een externe mailserver. Als de malware de "default smtp server" uit de registry (of /etc/sendmail.cf etc.) haalt kan de rate-limiter op de mailserver de flow beperken, en natuurlijk alarm slaan (of cachen totdat de mailhost admin zich ervan heeft verzekerd dat dit de bedoeling is). Dan hoeft ook niet meteen de PC van het net te worden gehaald, maar volstaat het blokkeren van poort 25 naar de SMTP server(s).
Achtergronden:
Aan het kanaliseren van uitgaande email kleven voor- een nadelen. Een van de voordelen is dat je op mailservers in logfiles ten minste na kunt gaan naar WIE malware/spam gestuurd is, mocht het een keer fout gaan. Een nadeel is natuurlijk dat de privacy in het geding is, maar (Europese) wetgeving zou ons sowieso wel eens in deze richting kunnen dwingen; erover nadenken voordat de tijdsdruk groot wordt is wellicht gewenst. Bovendien, als een buitenstaander claimt spam (die de laatste tijd steeds grover wordt, denk aan kinderporno) of malware direct vanaf een TU PC te hebben ontvangen, bijv. met UW email adres en UW IP-adres als afzender, dan is het m.i. prettig als de logs op een TU mailserver dat kunnen helpen ontkennen c.q. bevestigen, en in dat laatste geval is het misschien makkelijker om uit te zoeken of UW PC daar daadwerkelijk voor is gebruikt, of dat uw IP-adres wellicht is gespoofed (al was het maar omdat de datum/tijd gegevens van TU mailservers over het algemeen betrouwbaarder zijn dan die van bijv. Chinese of Russische hosts). Andersom, als iemand buiten de TUD beweert een heel belangrijke email NIET ontvangen te hebben, kunnen dergelijke logs ook uitsluitsel bieden.
Het up-to-date houden van virusscanners op PC's is niet zo eenvoudig als we zouden willen. Soms werkt de automatische update helemaal niet, en ik was gisteren op bezoek bij een computeranalfabeet (niet aan TU verbonden) die braaf NAV draait (met definities van 10 jan.), maar een rood kruis door haar taskbar icoontje had: "Oh, doet ie het dan niet?" (de wekelijkse scan wordt meestal afgebroken omdat het niet goed uitkomt en te lang duurt).
Ondertussen zijn virusdefinities zo groot dat een virusscanner op PC's zo'n 15MB van je geheugen opvreet (het meeste niet swappable). Met 512MB niet zo'n probleem, maar er staan links en rechts nog heel wat oude PCtjes die onwerkbaar worden door actuele virusscanners en wat dies meer zij. De Duitse c't 2002#25 noemt Norton SystemWorks 2003 "Norton Ueberfluessig 2003"; naar verluidt voegt dit pakket onder XP alleen al 1.6MB toe aan je registry. Vele scanners checken slechts een beperkt aantal filetypes (geen .hta bijv., zie de bovenstaande CERT-NL post), en veel mensen weten niet dat achtergrond "on-access" virusscanners zelden "on-the-fly" in zipfiles en emails scannen.
In mijn sectie kan men bij het booten van de PC kiezen of men een virusscanner wil draaien of niet (door hardware profiles, kies je nee dan worden drivers en virusdefs niet geladen, en voila: 15MB extra, snelle boot, logon en logoff, en soepel werken ook op oudere PC's). Door Outlook (Express) te verbieden en Pegasus Mail beschikbaar te stellen is het bij mijn weten meer dan een jaar geleden dat iemand er in trapte een virale .exe attachment te starten, maar door strakke ACL's op het filesysteem en registry (o.a. de HKLM "Run" key) bleef de schade beperkt, en stierf het virus met het uitloggen van de user. Als de user een WAB file had gehad (niet het geval dus) en het virus had z'n eigen SMTP engine, dan hadden er wel een heel stel mails verzonden kunnen worden; met de door mij hier voorgestelde maatregel is de schade die door zo'n incident onstaat in te perken en wordt in sommige gevallen wellicht geheel voorkomen.
Mijn vraag is: wat zie ik allemaal over het hoofd? Voor- en tegen argumenten zijn welkom!
PS:
Met vriendelijke groet,
Erik van Straten
Sysadmin/programmeur
Sectie DeeltjesOptica
Afdeling Technische Natuurkunde
TU Delft
Daar werkte ik tot voorjaar 2004. En, zoals je nu hopelijk wel zult begrijpen, is (na een heftige discussie -op die TU Delft maillijst- met een aantal puristen die menen dat providers niet mogen filteren) deze -pragmatische- maatregel, geheel terecht, ingevoerd. Niet lang daarna volgden ook veel landelijke ISP's.From: "Erik van Straten" <evs@cpo.tn.tudelft.nl>
Organization: Charged Particle Optics group - TU Delft
To: Dunet-Discussie@[redacted].tudelft.nl
Date: Mon, 13 Jan 2003 18:46:31 +0100
Subject: Voorstel: kanaliseren van TUD-uitgaande email
Collega's,
De laatste weken vliegen nieuwe computervirussen en andere malware de meeste internetters weer om de oren; hier bij de TU Delft lijken we daarvan verschoond te blijven. Hoewel de meest kwetsbare personen daarvoor in mijn sectie (waaronder de secretaresse) altijd een virusscanner draaien, kost het bij een detectie elke keer veel tijd om uit te leggen wat er aan de hand is, en dat de PC niet besmet is als zo'n virus in quarantaine is gezet; heerlijk dat me dat al geruime tijd bespaard is gebleven. Mocht dit mede mogelijk zijn gemaakt door persoonlijk ingrijpen van de beheerders van de emailscanner op mailhost1/2 tijdens de kerstvakantie, dan wil ik bij deze diegenen daarvoor hartelijk bedanken!
Omdat virussen ook op andere manieren binnen kunnen komen, en die scanners zo goed werken, stel ik voor om ook alle TU Delft-UITGAANDE email via mailhost1.tudelft.nl (of mailhost2) te sturen (of andere mailservers die aan bepaalde voorwaarden voldoen), en dat je dat ook afdwingt. Ik vermoed dat dit een gevoelig punt is, maar ik bedoel uitbreiding van de (bestaande) TCP poort 25 blokkade met uitgaande connecties.
Waarom?
(1) Omdat virussen/trojans/wormen en andere malware ook via andere wegen binnen kunnen komen. Dat kan bijv. alsnog via email in gezipte c.q. encrypted attachments, maar ook KaZaa, ICQ, IRC en online games zijn de laatste tijd populair bij virusbakkers. Met buffer overflows in WinAmp kunnen zelfs MP3's executable code bevatten, en ook al is je hele binnenband oranje van de plakkers, MSIE blijft lek. Als je poort 25 naar buiten blokkeert, kan malware met een eigen SMTP engine op een gecomprimiteerde PC ofwel niets beginnen, of wordt gedwongen om via een van de voorgeschreven mailservers te communiceren, en is daarmee vermoedelijk eenvoudiger van de buitenwereld af te sluiten. Zie ook de recente discussie op securityfocus, waarbij een zeelandnet PC werd "afgesloten" maar dat kennelijk niet hielp (zie onderaan die message):
http://online.securityfocus.com/archive/75/306360
(2) Omdat malware soms zo nieuw is dat deze niet door virusscanners wordt herkend. Meestal zit er enige vertraging tussen het "afleveren" van email en het openen ervan (een "slimme" virusverspreider zal dat op vrijdagavond doen, of aan het begin van een vakantieperiode); als de virusdefinities in de tussentijd zijn geupdate kan worden voorkomen dat de malware naar buiten de TU Delft verder wordt verspreid (en als je van rate-limiting gebruik maakt, kan het aantal binnen de perken worden gehouden, en je detectiemogelijkheden zijn natuurlijk veel beter). Zie mijn rapportage over een spam+trojan (die zo nieuw was dat sophos hem niet herkende; ik heb de betreffende email o.a. naar Sophos gezonden waarop Sophos ons updated definities heeft teruggestuurd):
http://listserv.surfnet.nl/scripts/wa.exe?A2=ind02&L=cert-nl-bulletins&F=&S=&P=6621
11-04-2016: link bestaat niet meer, desgewenst zoek ik een kopie op internet of in mijn archief
(3) Omdat ik me grote zorgen maak over spam. De bovenstaande rapportage heeft betrekking op het planten van backdoors op PC's, waarmee het doel vermoedelijk is om via zo'n PC spam te versturen. Als er vanuit de TU Delft spam wordt verzonden, en de hele TU IP-range belandt daarmee op blacklists van derden, hebben wij boter op ons hoofd als we daar wat op aan te merken hebben; immers, we maken zelf gebruik van dergelijke blacklists. De laatste tijd zie ik in HTTP logs op m'n webservers veel entries van spammers die zoeken naar formmail scripts (vooral pornospam wordt via webservers met dergelijke scripts gerelayed, de email begint dan meestal met iets als "Below is the result of your feedback form", en de reden dat hier zoveel naar gescanned wordt zou best kunnen zijn dat veel universiteiten unix/linux dozen draaien met dergelijke, wijd openstaande, formmail scripts). Maar ook (arme) studenten zouden in de verleiding kunnen komen om wat bij te verdienen als spammer. Natuurlijk kun je ze daarna straffen, maar we weten allemaal dat het makkelijker is om op blacklists te belanden dan om ervan afgehaald te worden. In het verleden heb ik ZELF wel eens meegeholpen om veel mensen via email uit te nodigen voor een conferentie, en dat op basis van een oude adreslijst; hoewel we toen (1997/1998) geen klachten hebben ontvangen, zou het me niet verbazen als dat nu anders zou zijn. Eventueel noodzakelijke bulk-email zou m.i. niet zomaar vanaf elke PC verzonden moeten kunnen worden.
Voorstel:
Sta niet toe dat elke PC poort 25 connecties naar buiten de TU Delft kan maken; beperk dit tot een aantal mailservers die aan een aantal (nader vast te stellen) criteria voldoen, zoals een virusscanner waarvan de definities vaker dan 1x per week worden geupdate, en waarop bij voorkeur een rate-limiter is ingesteld (waarmee het aantal emails per uur vanaf een PC wordt beperkt). Ook zou je emails met waslijsten aan email-adressen in het To: veld kunnen blokkeren (steeds meer mensen, waaronder ondergetekende, worden gallisch van alle spam die ze krijgen, en beschouwen hun email adres als iets persoonlijks dat niet de hele wereld hoeft te kennen - ik wil nog net niet zover gaan om naar deze lijst zelf een gemanipuleerd antispam adres te gebruiken, maar dat moment komt misschien ook nog wel eens).
Mocht een PC besmet raken met malware die zichzelf via email probeert te verspreiden, dan zal dat helemaal niet lukken als deze gebruik maakt van directe adressering of een externe mailserver. Als de malware de "default smtp server" uit de registry (of /etc/sendmail.cf etc.) haalt kan de rate-limiter op de mailserver de flow beperken, en natuurlijk alarm slaan (of cachen totdat de mailhost admin zich ervan heeft verzekerd dat dit de bedoeling is). Dan hoeft ook niet meteen de PC van het net te worden gehaald, maar volstaat het blokkeren van poort 25 naar de SMTP server(s).
Achtergronden:
Aan het kanaliseren van uitgaande email kleven voor- een nadelen. Een van de voordelen is dat je op mailservers in logfiles ten minste na kunt gaan naar WIE malware/spam gestuurd is, mocht het een keer fout gaan. Een nadeel is natuurlijk dat de privacy in het geding is, maar (Europese) wetgeving zou ons sowieso wel eens in deze richting kunnen dwingen; erover nadenken voordat de tijdsdruk groot wordt is wellicht gewenst. Bovendien, als een buitenstaander claimt spam (die de laatste tijd steeds grover wordt, denk aan kinderporno) of malware direct vanaf een TU PC te hebben ontvangen, bijv. met UW email adres en UW IP-adres als afzender, dan is het m.i. prettig als de logs op een TU mailserver dat kunnen helpen ontkennen c.q. bevestigen, en in dat laatste geval is het misschien makkelijker om uit te zoeken of UW PC daar daadwerkelijk voor is gebruikt, of dat uw IP-adres wellicht is gespoofed (al was het maar omdat de datum/tijd gegevens van TU mailservers over het algemeen betrouwbaarder zijn dan die van bijv. Chinese of Russische hosts). Andersom, als iemand buiten de TUD beweert een heel belangrijke email NIET ontvangen te hebben, kunnen dergelijke logs ook uitsluitsel bieden.
Het up-to-date houden van virusscanners op PC's is niet zo eenvoudig als we zouden willen. Soms werkt de automatische update helemaal niet, en ik was gisteren op bezoek bij een computeranalfabeet (niet aan TU verbonden) die braaf NAV draait (met definities van 10 jan.), maar een rood kruis door haar taskbar icoontje had: "Oh, doet ie het dan niet?" (de wekelijkse scan wordt meestal afgebroken omdat het niet goed uitkomt en te lang duurt).
Ondertussen zijn virusdefinities zo groot dat een virusscanner op PC's zo'n 15MB van je geheugen opvreet (het meeste niet swappable). Met 512MB niet zo'n probleem, maar er staan links en rechts nog heel wat oude PCtjes die onwerkbaar worden door actuele virusscanners en wat dies meer zij. De Duitse c't 2002#25 noemt Norton SystemWorks 2003 "Norton Ueberfluessig 2003"; naar verluidt voegt dit pakket onder XP alleen al 1.6MB toe aan je registry. Vele scanners checken slechts een beperkt aantal filetypes (geen .hta bijv., zie de bovenstaande CERT-NL post), en veel mensen weten niet dat achtergrond "on-access" virusscanners zelden "on-the-fly" in zipfiles en emails scannen.
In mijn sectie kan men bij het booten van de PC kiezen of men een virusscanner wil draaien of niet (door hardware profiles, kies je nee dan worden drivers en virusdefs niet geladen, en voila: 15MB extra, snelle boot, logon en logoff, en soepel werken ook op oudere PC's). Door Outlook (Express) te verbieden en Pegasus Mail beschikbaar te stellen is het bij mijn weten meer dan een jaar geleden dat iemand er in trapte een virale .exe attachment te starten, maar door strakke ACL's op het filesysteem en registry (o.a. de HKLM "Run" key) bleef de schade beperkt, en stierf het virus met het uitloggen van de user. Als de user een WAB file had gehad (niet het geval dus) en het virus had z'n eigen SMTP engine, dan hadden er wel een heel stel mails verzonden kunnen worden; met de door mij hier voorgestelde maatregel is de schade die door zo'n incident onstaat in te perken en wordt in sommige gevallen wellicht geheel voorkomen.
Mijn vraag is: wat zie ik allemaal over het hoofd? Voor- en tegen argumenten zijn welkom!
PS:
11-04-2016: irrelevant stukje over TU Delft admin maillijsten, die ondertussen niet meer bestaan, verwijderd
Met vriendelijke groet,
Erik van Straten
Sysadmin/programmeur
Sectie DeeltjesOptica
Afdeling Technische Natuurkunde
TU Delft
Door Erik van Straten:
11-04-2016, 07:51 door Anoniem:
Deze vind ik wat kort door de bocht, zeker in een tijd waar de meeste providers "om spam te voorkomen" je smtp sessie proberen tegen te houden (poort 25 dicht zetten)
Dat deze uitstekende maatregel destijds op veel plaatsen (helaas nog lang niet bij alle ISP's) is ingevoerd, zou wel eens mijn "schuld" kunnen zijn (zie de lange quote hieronder).09-03-2016, 11:34 door Erik van Straten, Laatst bijgewerkt: 09-03-2016, 13:23: En dat is een leugen, want ip8.rp01.net is niet van Google en hoort geen mail te sturen namens GMail gebruikers..
Deze vind ik wat kort door de bocht, zeker in een tijd waar de meeste providers "om spam te voorkomen" je smtp sessie proberen tegen te houden (poort 25 dicht zetten)
In dat geval wordt je bedankt! ;)
Dat hij inkomen dicht staat, tot daar aan toe, maar uitgaand...
Ziggo zette het zonder aankondiging dicht, en mijn mail server was daardoor voor vele gebruikers opeens onbruikbaar als relay (met authenticatie etc.)
Ook thuiswerkers konden opeens hun mail niet meer via de bedrijfsservers sturen, maar moesten hiervoor ziggo vertrouwen (die zelf nogal graag spam sturen en dus op blacklists staan)
Nee, een provider hoort dit soort censuur niet toe te passen, netneutraliteit toch?
En als ze het dicht zetten, zouden ze toch minimaal een optie moeten hebben dit open te zetten voor klanten die dat willen.
Tuurlijk, er zijn andere smtp poorten, maar erg doeltreffend is deze maatregel niet.
Zolang iedereen met windows nog braaf en massaal trojans op hun pc blijft installeren, mailen de spammers nu gewoon via de smtp omgeving van de provider... Resultaat is dat de providers vaker op blacklists staan en er helemaal geen mail meer door komt.
11-04-2016, 11:41 door
Briolet
Door Erik van Straten: Met als gevolg dat spammers, die wel graag "<REDACTED-AT-gmail.com>" achter "From:" gebruiken -in een poging spamfilters voor de gek te houden- niet via GMail servers zelf kunnen spammen, en zich dus in allerlei bochten proberen te wringen.
Niet kunnen spammen vanaf GMail is misschien te sterk, maar het zal moeilijk gaan. Zelf gebruik ik een blacklist van 'dnsbl.sorbs.net' op mijn mailserver. De 2e helft van maart zag ik plots diverse bounces van gmail adressen in het log die door de blacklist veroorzaakt waren. Blijkbaar is men erin geslaagd de spamdetectie van gmail te omzeilen, waardoor de servers van gmail zelf op blacklisten verschenen. In het log zie ik dan dat gmail meerdere keren geprobeerd heeft om de mail van reguliere afzenders bij mij af te leveren. Steeds, met een paar minuten vertraging, vanaf een andere smtp server met een ander IP, totdat ze een server gebruikten die niet op de sorbs blacklist stond.
Door Erik van Straten:
11-04-2016, 07:51 door Anoniem: of zelfs zonder medeweten over hun eigen servers laten lopen....
Voor uitgaande mail (en daar hebben we het hierover) kan dat niet, dat stel je zelf in.Transparante proxy (of hoe ze die dingen ook noemen. ;-)
Zie ik wel eens in hotels.
b.
DMARC/SPF/DKIM zijn vrijwel zinloos als middel tegen spam. Daar zijn diverse redenen voor:
1. Bepaalde spammers gebruiken DKIM in grote aantallen. Dat kunnen ze makkelijk doen, ze gebruiken hun eigen weggooidomeinen.
2. Phishers gebruiken sinds een aantal jaar niet meer als afzender een echt bankdomein. Ze gebruiken een willekeurig ander domein dat er echt genoeg uitziet.
3. ISP's zijn onder de illusie dat het beperken van de zendmogelijkheden van klanten goed is. Dat is natuurlijk niet zo voor gevorderde gebruikers. Die worden gedwongen van onveilige webmail gebruik te maken zodat het vanaf een toegestaan IP wordt verstuurd.
4. De afdeling debiteuren van veel bedrijven zijn volledig clueless en sturen hun rekeningen vanaf een adres dat niet ondersteund wordt door hun SPF instellingen.
Wat er nu wel ontbreekt is dat deze middelen niet goed worden ondersteund door email clients. Dat is precies waar het wel van pas zou kunnen komen. Bijvoorbeeld om te kijken of een bericht echt van een bank komt. Daar faalt het al jaren.
Dus is het wel bruikbaar als positieve identificatie, maar niet als negatieve identificatie. Tenzij er echt noodzaak is, zou je deze maatregelen niet moeten gebruiken. Gebruik beter een certificaat en/of GPG. Dat is persoonlijke identificatie en veel beter dan domein of IP gebaseerde pseudo authenticatie.
1. Bepaalde spammers gebruiken DKIM in grote aantallen. Dat kunnen ze makkelijk doen, ze gebruiken hun eigen weggooidomeinen.
2. Phishers gebruiken sinds een aantal jaar niet meer als afzender een echt bankdomein. Ze gebruiken een willekeurig ander domein dat er echt genoeg uitziet.
3. ISP's zijn onder de illusie dat het beperken van de zendmogelijkheden van klanten goed is. Dat is natuurlijk niet zo voor gevorderde gebruikers. Die worden gedwongen van onveilige webmail gebruik te maken zodat het vanaf een toegestaan IP wordt verstuurd.
4. De afdeling debiteuren van veel bedrijven zijn volledig clueless en sturen hun rekeningen vanaf een adres dat niet ondersteund wordt door hun SPF instellingen.
Wat er nu wel ontbreekt is dat deze middelen niet goed worden ondersteund door email clients. Dat is precies waar het wel van pas zou kunnen komen. Bijvoorbeeld om te kijken of een bericht echt van een bank komt. Daar faalt het al jaren.
Dus is het wel bruikbaar als positieve identificatie, maar niet als negatieve identificatie. Tenzij er echt noodzaak is, zou je deze maatregelen niet moeten gebruiken. Gebruik beter een certificaat en/of GPG. Dat is persoonlijke identificatie en veel beter dan domein of IP gebaseerde pseudo authenticatie.
13-04-2016, 02:55 door Anoniem: DMARC/SPF/DKIM zijn vrijwel zinloos als middel tegen spam.
Dat klopt. Maar, daar zijn ze dan ook niet voor bedoeld (alhoewel sommigen anders claimen).Ze zijn bedoeld om het spoofen van afzender e-mail adressen (de combinatie van DMARC/SPF/DKIM voor zowel envelope-from als body-from) te verhinderen (voorwaarde is dat ontvangende mailservers hierop checken), en DKIM helpt daarnaast voorkomen dat de body en sommige headers "onderweg" worden gewijzigd.
13-04-2016, 02:55 door Anoniem: Daar zijn diverse redenen voor:
1. Bepaalde spammers gebruiken DKIM in grote aantallen. Dat kunnen ze makkelijk doen, ze gebruiken hun eigen weggooidomeinen.
Klopt. Zoals ik schreef, alleen SPF of DKIM is zinloos.1. Bepaalde spammers gebruiken DKIM in grote aantallen. Dat kunnen ze makkelijk doen, ze gebruiken hun eigen weggooidomeinen.
13-04-2016, 02:55 door Anoniem: 2. Phishers gebruiken sinds een aantal jaar niet meer als afzender een echt bankdomein. Ze gebruiken een willekeurig ander domein dat er echt genoeg uitziet.
Daar heb je een legitiem punt. Maar gisteren heb ik nog een mailtje geanalyseerd (de betreffende mailserver checkt niet op SPF en DMARC, en een DKIM header ontbrak in de mail):- Zowel envelope-from als mail-from luidden:
"ABN AMRO Bank N.V. <noreply@doormijgewijzigd.abnamro.com>"
- Verzonden vanaf 37-97-169-132.colo.transip.net ([37.97.169.132] helo=oranje.nl)
SPF had dit tegen kunnen houden als ABN AMRO haar TXT DNS record zou laten eindigen met "-all" (i.p.v. "?all"):
"v=spf1
include:_spf3.nl.abnamro.com
include:spf.protection.outlook.com
include:spf.messagelabs.com
include:_spf1.nl.abnamro.com
include:_spf2.nl.abnamro.com
?all"
include:_spf3.nl.abnamro.com
include:spf.protection.outlook.com
include:spf.messagelabs.com
include:_spf1.nl.abnamro.com
include:_spf2.nl.abnamro.com
?all"
Probleem is inderdaad wel dat een ontvanger moet weten dat ABN AMRO Nederland alle e-mails verstuurt vanaf e-mail adressen eindigend op nl.abnamro.com - en dat zal niet voor iedereen even logisch zijn (als hun MUA dat adres al toont).
13-04-2016, 02:55 door Anoniem: 3. ISP's zijn onder de illusie dat het beperken van de zendmogelijkheden van klanten goed is. Dat is natuurlijk niet zo voor gevorderde gebruikers. Die worden gedwongen van onveilige webmail gebruik te maken zodat het vanaf een toegestaan IP wordt verstuurd.
Los van of dit waar is, de relatie met SPF/DKIM/DMARC ontgaat me.13-04-2016, 02:55 door Anoniem: 4. De afdeling debiteuren van veel bedrijven zijn volledig clueless en sturen hun rekeningen vanaf een adres dat niet ondersteund wordt door hun SPF instellingen.
Mensen zoals jij en ik moeten hen opvoeden.13-04-2016, 02:55 door Anoniem: Wat er nu wel ontbreekt is dat deze middelen niet goed worden ondersteund door email clients. Dat is precies waar het wel van pas zou kunnen komen. Bijvoorbeeld om te kijken of een bericht echt van een bank komt. Daar faalt het al jaren.
Oneens. DMARC/SPF/DKIM zijn protocollen bestemd om te worden ingezet door mailservers (MTA's), niet door mailclients (MUA's).13-04-2016, 02:55 door Anoniem: Dus is het wel bruikbaar als positieve identificatie, maar niet als negatieve identificatie.
Inderdaad, lastig punt. Zie boven (een phisher zou kunnen zenden vanaf nl.abn_amro.com).13-04-2016, 02:55 door Anoniem: Tenzij er echt noodzaak is, zou je deze maatregelen niet moeten gebruiken.
Oneens, deze maatregelen worden pas effectief als iedereen ze inzet.13-04-2016, 02:55 door Anoniem: Gebruik beter een certificaat en/of GPG.
De protocollen PGP/GPG/GnuPG zijn onbruikbaar voor gewone stervelingen. Er bestaat geen betrouwbaar middel om te controleren of een public key daadwerkelijk toebehoort aan de geclaimde persoon.Gratis certificaten zijn waardeloos, want het enige dat daarmee redelijkerwijs wordt bevestigd is dat de gebruiker (nep of echt) op een gegeven moment toegang had tot een mailbox. Vals gevoel van veiligheid dus. En daarnaast zo weinig ingezet dat gewone stervelingen niet begrijpen wat een certificaat betekent.
Gisteren nog kreeg ik een mailtje doorgestuurd van "De Zaak" waarin sprake was van "beveiligingscertificaten" (zie ook http://www.dezaak.nl/2882/vernieuw-beveiligingscertificaat-website.htm). Zucht.
[...]Deze altijd unieke sleutel wordt door de certificaat uitgever gemaakt[...]
Goed om te weten: Google stimuleert SSL (SHA-2)[...]
Het tabelletje erin is netjes, maar de daarboven aangekondigde prijzen ontbreken.Goed om te weten: Google stimuleert SSL (SHA-2)[...]
13-04-2016, 02:55 door Anoniem: Dat is persoonlijke identificatie en veel beter dan domein of IP gebaseerde pseudo authenticatie.
Eens, maar als minder dan 1% van de e-mailers dat snapt heb je daar niets aan.Oneens. DMARC/SPF/DKIM zijn protocollen bestemd om te worden ingezet door mailservers (MTA's), niet door mailclients (MUA's).
Dat is een designfout. Daar is het niet bruikbaar door de fouten die ermee worden gemaakt. Je kunt niet geautomatiseerd beslissingen nemen. Je moet dus de gebruiker informeren en die kan actie ondernemen. Je wilt niet weten hoeveel bezorgingsproblemen dit veroorzaakt. Mailing lists van mail server operators staan er vol mee.
Oneens, deze maatregelen worden pas effectief als iedereen ze inzet.
Nee, duidelijk niet, zie de opgesomde punten. Daarnaast: je gaat er o.a. ten onrechte vanuit dat iedereen met deze "tools" kan omgaan. Dat is niet zo, er worden veel fouten mee gemaakt, ook door multinationals, dat is aan de orde van de dag. Authenticatie op domein niveau is geen oplossing. Zoals gezegd, alleen bruikbaar voor positieve identificatie met een bepaald zekerheidsniveau, die ondergeschikt is aan certificaat- of GPG authenticatie.
Er is bij web surfen ook verschil in certifcaat gebaseerde authenticatie, dat hoeft bij email niet anders te zijn. Er zijn niet meer skills voor nodig als dat fatsoenlijk wordt geimplementeerd. Daar schort het aan. Het middel zelf is niet slecht.
GPG is inderdaad niet makkelijk met de huidige tools, maar daar is ook veel aan te verbeteren met name op het gebied van installatie, setup en interface. Het voordeel van GPG keys is dat ze niet afhankelijk zijn van CA's, maar wel op basis van trust kunnen worden gecontroleerd. Het gaat er dus om eerst die trust relatie te scheppen. Deze decentrale opzet is in principe -mits goed toegepast - het veiligste authenticatie middel, veiliger dan CA's.
Ik zag net dat ABN-Amro nu ook een echte dmarc policy heeft. Toen ik een paar maand geleden keek stond hij op 'none' nu op 'quarantine'
$ host -t txt _dmarc.nl.abnamro.com
_dmarc.nl.abnamro.com descriptive text "v=DMARC1\; p=quarantine\; rua=mailto:dmarc@nl.abnamro.xxx\; ruf=mailto:dmarc@nl.abnamro.xxx\; rf=afrf\; pct=100"
_dmarc.nl.abnamro.com descriptive text "v=DMARC1\; p=quarantine\; rua=mailto:dmarc@nl.abnamro.xxx\; ruf=mailto:dmarc@nl.abnamro.xxx\; rf=afrf\; pct=100"
23-04-2016, 21:03 door
[Account Verwijderd]
[Verwijderd]
25-04-2016, 13:40 door
devias
Nu maar hopen dat alle Nederlandse banken dit doorvoeren.
Nee, voornamelijk hopen dat alle Nederlanse ISPs eindelijk eens wakker worden en DMARC controleren. Want voor 50% van de ontvangers is het altijd raak.
Het aantal mailservers dat niet op DMARC controleert is schrikbarend. Verder is het nog niet zo makkelijk om je email bij een hoster ondertekend te krijgen met je eigen DKIM sleutel.
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
