exchange 2010 spam en spoofing

[Simke]

Medetweakers,

bij een klant zit ik met een vervelend probleem dat ik niet volledig opgelost krijg.

Klant heeft een exchange 2010 die sinds korte tijd veel spam ontvangt.
Door instellingen te wijzigen (content filter, transport rule) is de spam al veel geminderd maar men krijgt nog altijd spoofed mails binnen.
De mails zijn afkomstig van zowel bestaande als onbestaande interne mailadressen maar ook interne verzendlijsten als sender.

Ik heb al uren zitten zoeken en ben veel zaken tegengekomen, gaande van "je kan er weinig aan doen", spf-record aanmaken en gebruiken maar dat wordt dan weer tegengesproken, tot "need to remove the ms-exch-smtp-accept-authoritative-domain-sender permission" (anonymous logon).

Uiteraard moeten de mails van klanten en leveranciers bestemd voor dat domein toekomen. Heeft iemand een tip hoe ik die spoofingmails toch kan filteren?

Ik heb wel een basis van exchange maar ben geen expert. De firma die de initiële opzet gedaan heeft zegt van een UTM te plaatsen maar hoop dat dit toch anders kan met exchange zelf...

Ik blijf ondertussen ook verder zoeken!

Thx, Simke

[Nakebod]

Ik ken Exchange niet/nauwelijks, maar waarom accepteer je mail van domaina.nl van een externe mailserver die "zegt" domaina.nl te zijn, terwijl je feitelijk al weet dat dit niet klopt.
Zover ik weet heeft Exchange daar opties voor, alleen geen idee hoe ze precies heten.

[Simke]

Nakebod schreef op woensdag 23 maart 2016 @ 10:00:
Ik ken Exchange niet/nauwelijks, maar waarom accepteer je mail van domaina.nl van een externe mailserver die "zegt" domaina.nl te zijn, terwijl je feitelijk al weet dat dit niet klopt.
Zover ik weet heeft Exchange daar opties voor, alleen geen idee hoe ze precies heten.

Wel, die opties ben ik dus aan het uitzoeken.
Het probleem is dat de oorspronkelijke configuratie niet door ons gedaan is en alles heeft een tijd lang goed gewerkt maar geeft nu dus die spoofing.
Mijn kennis is ook te beperkt om zo maar te zeggen ik verander die of die optie en het probleem is opgelost.
Bezig met allerlei info aan het doornemen van mailflow e.d....

edit: uiteraard staat bij accepted domains de domeinnaam van de klant

[ Voor 4% gewijzigd door Simke op 23-03-2016 11:09 ]

[Question Mark]

Nakebod schreef op woensdag 23 maart 2016 @ 10:00:
Ik ken Exchange niet/nauwelijks, maar waarom accepteer je mail van domaina.nl van een externe mailserver die "zegt" domaina.nl te zijn, terwijl je feitelijk al weet dat dit niet klopt.
Zover ik weet heeft Exchange daar opties voor, alleen geen idee hoe ze precies heten.

Probleem is dat er mail gespoofed wordt vanuit/namens bedrijf A via een mailserver B, naar een niet bestaand mailadres bij bedrijf C. De mailserver van bedrijf C gaat dan een NDR sturen naar bedrijf A.

Dat is lastig te verhelpen, want in sommige gevallen zijn NDR's wel valide en wil je ze niet altijd blokkeren.

[url=https//www.sophos.com/en-us/support/knowledgebase/37088.aspx]Description of Backscatter / NDR spam[/]

[Simke]

Question Mark schreef op woensdag 23 maart 2016 @ 11:43:
[...]

Probleem is dat er mail gespoofed wordt vanuit/namens bedrijf A via een mailserver B, naar een niet bestaand mailadres bij bedrijf C. De mailserver van bedrijf C gaat dan een NDR sturen naar bedrijf A.

Dat is lastig te verhelpen, want in sommige gevallen zijn NDR's wel valide en wil je ze niet altijd blokkeren.

[url=https//www.sophos.com/en-us/support/knowledgebase/37088.aspx]Description of Backscatter / NDR spam[/]

Thx voor de link en versta wat er staat.

Eigenlijk wil ik iets simpel maar vind dus niet hoe ik het kan configureren.

Als ik de tracking log explorer bekijk en zoek achter een sender "admin@domein_van_klant.be" (daar is zeker een mail van binnengekomen) dan vind ik die mail. Als returnpath staat hetzelfde emailadres, de clienthostname is ofwel een ip ofwel de hostname.

Ik wil dus heel eenvoudig: mail die van buitenaf komt met als sender het domein_van_klant.be van de klant dat deze mail verwijderd wordt.
Simpel toch? blijkbaar niet

[Question Mark]

En als je nu per ongeluk een bericht verstuurd naar een niet bestaand adres (omdat je bijvoorbeeld een typefout maakt). Dan neem ik aan dat je juist wél geinformeerd wil worden en dus de NDR wél wilt krijgen.

Dat maakt het nu net zo lastig...

[Simke]

Question Mark schreef op woensdag 23 maart 2016 @ 12:40:
En als je nu per ongeluk een bericht verstuurd naar een niet bestaand adres (omdat je bijvoorbeeld een typefout maakt). Dan neem ik aan dat je juist wél geinformeerd wil worden en dus de NDR wél wilt krijgen.

Dat maakt het nu net zo lastig...

Ja dat wel, de NDR's mogen/moeten idd verstuurd worden.

Maar er zou toch moeten kunnen gefilterd worden dat mails die zogezegd komen van @domein_van_klant.be geblocked worden?
Van buitenaf wordt er niet gestuurd als zijnde iemand dan de klant zijn domein toch?

[Question Mark]

Simke schreef op woensdag 23 maart 2016 @ 12:43:
[...]
Maar er zou toch moeten kunnen gefilterd worden dat mails die zogezegd komen van @domein_van_klant.be geblocked worden?

Ja, maar alleen door bedrijf C (in mijn voorbeeld). Zij ontvangen gespoofde mail (met jullie smtp adres), en zij sturen de NDR naar jullie toe (aangezien jullie smtp adres de originator lijkt te zijn). Als zij gespoofde mail zouden blokkeren zou er niets aan de hand zijn.

Dit kun je dus zelf niet regelen, tenzij je fancy anti-spam oplossingen in gaat zetten.

[ Voor 5% gewijzigd door Question Mark op 23-03-2016 13:06 ]

[Yarisken]

Zet er een barracuda voor.
Spoofed mails ga je niet / moeilijk kunnen tegenhouden. Welkom in de onvolwassen wereld van de IT :-).

[Question Mark]

Spoofed mails zijn via SPF records redelijk eenvoudig tegen te houden. Nadeel is dat niet elke partij netjes hun SPF records op orde heeft, maar een heel groot gedeelte kun je hiermee al blokken.

[Simke]

Question Mark schreef op woensdag 23 maart 2016 @ 13:03:
[...]

Ja, maar alleen door bedrijf C (in mijn voorbeeld). Zij ontvangen gespoofde mail (met jullie smtp adres), en zij sturen de NDR naar jullie toe (aangezien jullie smtp adres de originator lijkt te zijn). Als zij gespoofde mail zouden blokkeren zou er niets aan de hand zijn.

Dit kun je dus zelf niet regelen, tenzij je fancy anti-spam oplossingen in gaat zetten.

In dit geval gaat het toch niet in over de NDR? Het is een inkomende mail zogezegd van binnen het domein zelf of mis ik hier iets?

Yarisken schreef op woensdag 23 maart 2016 @ 13:08:
Zet er een barracuda voor.
Spoofed mails ga je niet / moeilijk kunnen tegenhouden. Welkom in de onvolwassen wereld van de IT :-).

Dus de uitleg van de firma die dit oorspronkelijk geconfigureerd heeft zegt "zet een UTM" is toch niet zo gek...

Question Mark schreef op woensdag 23 maart 2016 @ 13:11:
Spoofed mails zijn via SPF records redelijk eenvoudig tegen te houden. Nadeel is dat niet elke partij netjes hun SPF records op orde heeft, maar een heel groot gedeelte kun je hiermee al blokken.

Op dit moment is er geen SPF-record. Ik zal mij hierin eens verdiepen, hopelijk helpt het al iets...

[Yarisken]

Simke schreef op woensdag 23 maart 2016 @ 13:32:
[...]


In dit geval gaat het toch niet in over de NDR? Het is een inkomende mail zogezegd van binnen het domein zelf of mis ik hier iets?


[...]


Dus de uitleg van de firma die dit oorspronkelijk geconfigureerd heeft zegt "zet een UTM" is toch niet zo gek...


[...]


Op dit moment is er geen SPF-record. Ik zal mij hierin eens verdiepen, hopelijk helpt het al iets...

Je zal nooit op de exchange zelf een config kunnen instellen zoals op een dedicated appliance als bv barracuda. Tegenwoordig kan je deze toestellen ook virtueel draaien dus dat is misschien ook een optie.
Wij moeten praktisch nooit ingrijpen sinds we die barracuda hebben. Soms komt er is een spam mailtje door of wordt een domein geblokkeerd. Het kost natuurlijk wel geld en als dat een bedrijf is van 30 personen gaat dat misschien niet lukken.

[Question Mark]

Simke schreef op woensdag 23 maart 2016 @ 13:32:
[...]
In dit geval gaat het toch niet in over de NDR? Het is een inkomende mail zogezegd van binnen het domein zelf of mis ik hier iets?

Wat bedoel je? De NDR is volkomen terecht en komt van buiten jouw omgeving. Nogmaals:

1. Spammer stuurt gespoofde mail met het smtp adres van jouw bedrijf naar een niet bestaand adres bij bedrijf B.
2. De mailserver van bedrijf B kan de mail niet afleveren en gaat een NDR sturen naar de verzender. Hij denkt vanwege het gespoofde adres dat de mail bij jouw bedrijf weg komt en stuurt daar een NDR heen.
3. Jouw bedrijf ontvangt dan de NDR

Het ontvangen van die NDR is terecht en lastig te blokken omdat deze partij wellicht ook nog wel eens "reguliere" NDR's moet gaan versturen naar jullie.

Er zijn twee oplossingen voor:

1. Bedrijf B moet gespoofde mails gaan in behandeling nemen en gaan droppen (dmv SPF-records)
2. Jullie kunnen een fancy anti-spam oplossing implementeren in de hoop dat dit het oplost, een Baracuda is daar een voorbeeld van, maar het kan ook een willekeurig andere oplossing zijn. Zie ook: Configuring backscatter filtering with Forefront protection for Exchange

.

[ Voor 5% gewijzigd door Question Mark op 23-03-2016 14:04 ]

[Simke]

Question Mark schreef op woensdag 23 maart 2016 @ 14:02:
[...]
Wat bedoel je? De NDR is volkomen terecht en komt van buiten jouw omgeving. Nogmaals:

1. Spammer stuurt gespoofde mail met het smtp adres van jouw bedrijf naar een niet bestaand adres bij bedrijf B.
2. De mailserver van bedrijf B kan de mail niet afleveren en gaat een NDR sturen naar de verzender. Hij denkt vanwege het gespoofde adres dat de mail bij jouw bedrijf weg komt en stuurt daar een NDR heen.
3. Jouw bedrijf ontvangt dan de NDR

Het ontvangen van die NDR is terecht en lastig te blokken omdat deze partij wellicht ook nog wel eens "reguliere" NDR's moet gaan versturen naar jullie.

Er zijn twee oplossingen voor:

1. Bedrijf B moet gespoofde mails gaan in behandeling nemen en gaan droppen (dmv SPF-records)
2. Jullie kunnen een fancy anti-spam oplossing implementeren in de hoop dat dit het oplost, een Baracuda is daar een voorbeeld van, maar het kan ook een willekeurig andere oplossing zijn. Zie ook: Configuring backscatter filtering with Forefront protection for Exchange

.

Of ik druk mij verkeerd uit of ik heb een ander beeld van een NDR.

Voor mij is een NDR een mail die je krijgt van:

"Je hebt naar x een mail gestuurd en die mail is niet afgeleverd om die reden of die reden".
(En dan versta ik uw uitleg van bedrijf a b en c).

De mails die de klant ontvangt zijn niet zulke mails.

Ik ga een concreet voorbeeld geven.

De gebruiker krijgt in zijn mailbox een mail van [e-mail] (mailadres admin@ bestaat niet). Er zit een bijlage bij, meestal een zip of een afbeelding (grote kans op een cryptolocker dus).
Het kan ook zijn dat de mail afkomstig van een bestaand emailadres of een lijst@... emailadres.

Dus ik stuur u een mail met zip-bestand maar jij ziet dat het van [e-mail] is.

Is dit dan uw toepassing met de NDR waar jij over spreekt?

Thx voor de input al!

[Dennism]

Staat het domain van de klant in hun eigen whitelist? Je moet namelijk niet je eigen domain / E-mail adressen gaan whitelisten. Normaliter worden dit soort mails zelfs door basic mailfilters afgevangen, tenzij het eigen domain gewhitelist is.

Verder is het in deze tijden zeker niet verkeerd om gewoon een redelijk uitgebreid spam filter te hebben, je houd er echt een boel troep mee buiten de deur.

[Simke]

Dennism schreef op woensdag 23 maart 2016 @ 17:15:
Staat het domain van de klant in hun eigen whitelist? Je moet namelijk niet je eigen domain / E-mail adressen gaan whitelisten. Normaliter worden dit soort mails zelfs door basic mailfilters afgevangen, tenzij het eigen domain gewhitelist is.

Verder is het in deze tijden zeker niet verkeerd om gewoon een redelijk uitgebreid spam filter te hebben, je houd er echt een boel troep mee buiten de deur.

Neen, er staat niets in de whitelist (bypassedsenderdomain in get-contentfilterconfig)

[RammY]

Ik weet niet of je de servers op je klant locatie gevirtualiseerd heb staan, anders zou ik er voor de snelheid (en eenvoud sowieso) een MailCleaner voor zetten.
Even de ISO installeren en je kunt binnen 15 minuten de mail verwerken.

[Simke]

RammY schreef op zondag 03 april 2016 @ 14:55:
Ik weet niet of je de servers op je klant locatie gevirtualiseerd heb staan, anders zou ik er voor de snelheid (en eenvoud sowieso) een MailCleaner voor zetten.
Even de ISO installeren en je kunt binnen 15 minuten de mail verwerken.

Ja alle servers draaien op een esxi.
Ik ben momenteel spamfighter exchange module aan het testen en houdt het meeste al tegen, is natuurlijk tegen betaling.

Net eens gekeken naar die mailcleaner, misschien eens een virtuele testserver opzetten en kijken wat het geeft...

[Glashelder]

Met postfix is dit met smtpd_sender_restrictions vrij eenvoudig te blokkeren. Je kan dan mails van het eigen domein die als 'from' adres het eigen domein hebben blokkeren.

Zie de reactie van aenright op 11-20-2008, 03:05 PM:

So, if you are sure you want to block all mail to/from the list of domains, you can add the following directive to your postfix main.cf file:

code:

smtpd_sender_restrictions = hash:/etc/postfix/access
reject_unauth_destination = hash:/etc/postfix/access

Once this has been added to the main.cf, you need to create the /etc/postfix/access file and put entries in it like this:

code:

aol.com     REJECT
yahoo.com   REJECT
msn.com     REJECT

So on and so forth until all the domains have been entered. Once you have created this file and the permissions are correct run the following command:

code:

postmap hash:/etc/mail/access

and finally restart postfix.

This will prevent the offending domains from sending you mail and your users from sending mail to those domains.

**NOTE**I have used smtpd_sender_restrictions in past configurations, I have not used reject_unauth_destination, and based that portion of this reply on what I read on the postfix site. You may want to impliment each one seperately and test.

Best of luck,
~Art

reject_unauth_destination is alleen niet nodig. Wij gebruiken alleen smtpd_sender_restrictions.

[Killah_Priest]

Glashelder schreef op maandag 04 april 2016 @ 14:42:
Met postfix is dit met smtpd_sender_restrictions vrij eenvoudig te blokkeren. Je kan dan mails van het eigen domein die als 'from' adres het eigen domein hebben blokkeren.

Zie de reactie van aenright op 11-20-2008, 03:05 PM:

[...]

reject_unauth_destination is alleen niet nodig. Wij gebruiken alleen smtpd_sender_restrictions.

De TS heeft een Exchange server, geen postfix server.

[Simke]

Glashelder schreef op maandag 04 april 2016 @ 14:42:
Met postfix is dit met smtpd_sender_restrictions vrij eenvoudig te blokkeren. Je kan dan mails van het eigen domein die als 'from' adres het eigen domein hebben blokkeren.

Zie de reactie van aenright op 11-20-2008, 03:05 PM:

[...]

reject_unauth_destination is alleen niet nodig. Wij gebruiken alleen smtpd_sender_restrictions.

mail van @domeinvanklant.be komt ondertussen niet meer toe, firewall aangepast dat dat tegengehouden wordt (er bestond een regel maar die stond na allow: all (niet door ons geïnstalleerd btw ))

Verder lijkt het alsof de spamfilter van exchange niets tegen hield maar ook niet veel reactie gaf, vb het uitschakelen van de spamfilter via powershell gaf aan dat het commando uitgevoerd was maar dat er niets gewijzigd was... Bleef dus aan staan.
Spamfilter dan gedeïnstalleerd en voorlopig spamfighter in test...

[Glashelder]

Killah_Priest schreef op maandag 04 april 2016 @ 15:08:
[...]


De TS heeft een Exchange server, geen postfix server.

Dat weet ik maar hij was toch aan het experimenteren met virtuele servers

[Simke]

Glashelder schreef op maandag 04 april 2016 @ 16:00:
[...]

Dat weet ik maar hij was toch aan het experimenteren met virtuele servers

Awel, bij gebrek aan een testomgeving gebeurt alles direct op de productieomgeving (of toch de productieserver) (don't shoot the Messenger!), daarom dat ik toch voorzichtigheid aan de dag moet leggen...
Die mailcleaner wil ik eventueel wel testen, van de postfix server heb ik totaal geen idee hoe of wat

[Killah_Priest]

Simke schreef op maandag 04 april 2016 @ 17:00:
[...]


Awel, bij gebrek aan een testomgeving gebeurt alles direct op de productieomgeving (of toch de productieserver) (don't shoot the Messenger!), daarom dat ik toch voorzichtigheid aan de dag moet leggen...
Die mailcleaner wil ik eventueel wel testen, van de postfix server heb ik totaal geen idee hoe of wat

Hoe wij het voor klanten oplossen : wij hebben 2 antispam servers (via een reseller welke hierin gespecialiseerd zijn) ergens in een datacenter draaien.
MX records verwijzen hierheen, mails worden vervolgens per domein naar de correcte mailserver gestuurd (beetje standaard oplossing zo).
Voordeel is dat de klant een eigen portal heeft om zelf zaken door te voeren en aanpassingen te maken in het filter (wij hebben uiteraard weer accounts om dit voor alle domeinen te managen).
Simpele oplossing, relatief goedkoop en bijkomend voordeel is dat mail altijd afgeleverd wordt zelfs als de internetverbinding van de klant er tijdelijk uit heeft gelegen (MKB klanten hebben ivm locatie niet altijd de optie voor een stabiele verbinding)

[Simke]

Killah_Priest schreef op maandag 04 april 2016 @ 19:00:
[...]


Hoe wij het voor klanten oplossen : wij hebben 2 antispam servers (via een reseller welke hierin gespecialiseerd zijn) ergens in een datacenter draaien.
MX records verwijzen hierheen, mails worden vervolgens per domein naar de correcte mailserver gestuurd (beetje standaard oplossing zo).
Voordeel is dat de klant een eigen portal heeft om zelf zaken door te voeren en aanpassingen te maken in het filter (wij hebben uiteraard weer accounts om dit voor alle domeinen te managen).
Simpele oplossing, relatief goedkoop en bijkomend voordeel is dat mail altijd afgeleverd wordt zelfs als de internetverbinding van de klant er tijdelijk uit heeft gelegen (MKB klanten hebben ivm locatie niet altijd de optie voor een stabiele verbinding)

Dat is inderdaad een mooie oplossing.
Zo heeft de klant waarvan spraken al mails verloren door een crash van de esxi waarbij de mails niet bijgehouden werden bij de backup MX omdat er nog connectie was met de firewall...
Is dat dan een mail relay of zo?

Nu heb ik gisteren avond van de firma die oorspronkelijk de installatie gedaan heeft een voorstel gekregen voor een up-trade van de firewall incl securitymodule, dus een spamfilter op firewall niveau.

Iemand ervaring met zo een oplossing? Het zou een watchguard T30 zijn met security module... (nu een watchguard X550e)

[Glashelder]

Zo heeft de klant waarvan spraken al mails verloren door een crash van de esxi waarbij de mails niet bijgehouden werden bij de backup MX omdat er nog connectie was met de firewall...

Een relayserver zoals hier beschreven is maakt normaal gesproken geen back-ups van e-mails.. En elke normale (SMTP) mailserver zal pas een mail als verzonden beschouwen als er een bevestiging is van de ontvangende mailserver, dus ik begrijp niet zo goed wat je precies bedoeld met de zin die ik citeer..

Een mail die bezorgd is bij een ESXi VM zal je nog steeds kwijtraken als die omgeving crasht.. back-up relay server of niet..

Als je het mij vraagt is zo'n back-up relay server niet zo heel nuttig. Elke SMTP server zal 3 dagen blijven proberen om een mail af te leveren. Dan heb je er pas wat aan als je internet er 3 dagen uit ligt.

[Simke]

Glashelder schreef op dinsdag 05 april 2016 @ 09:16:
[...]



Een relayserver zoals hier beschreven is maakt normaal gesproken geen back-ups van e-mails.. En elke normale (SMTP) mailserver zal pas een mail als verzonden beschouwen als er een bevestiging is van de ontvangende mailserver, dus ik begrijp niet zo goed wat je precies bedoeld met de zin die ik citeer..

Een mail die bezorgd is bij een ESXi VM zal je nog steeds kwijtraken als die omgeving crasht.. back-up relay server of niet..

Als je het mij vraagt is zo'n back-up relay server niet zo heel nuttig. Elke SMTP server zal 3 dagen blijven proberen om een mail af te leveren. Dan heb je er pas wat aan als je internet er 3 dagen uit ligt.

Ik probeer te verduidelijken:

eerste MX-record verwijst naar ip van klant
2de mx record verwijst naar de provider

Ik dacht dat als een mail niet ontvangen werd door exchange dat de mail dan tijdelijk bijgehouden werd bij de provider (2de mx record)
Na de crash ontbraken er een aantal mails en die kwamen niet binnen ook al was de exchange terug online.
Contact genomen met de provider en daar zei men dat van zodra er connectie is op ip van klant de mail als afgeleverd aanzien werd en dus niet in wacht kwam bij hen...

[Glashelder]

Dat is wel hѐѐl raar.

In principe zou een SMTP server een mail pas uit de queue mogen gooien als:
• deze ofwel goed is afgeleverd,;
• de SMTP server waar afgeleverd moet worden is te lang niet bereikbaar of geeft te lang achtereenvolgens temporary failures (NDR wordt teruggestuurd naar de verzender)
• de eindbestemming geeft een of andere permanente failure (NDR wordt teruggestuurd naar de verzender)

Als jouw Exchange onbereikbaar is OF een temporary failure geeft, dan gaat de andere SMTP server over naar de tweede server zoals gespecificeerd in de MX records. Die SMTP server gaat hetzelfde proces weer doen: retry's, retry en nog een retry..

Ik ben al even aan het nadenken maar ik snap niks van die verklaring van die provider.. dat zou met compliant SMTP servers niet moeten kunnen

[Simke]

Glashelder schreef op dinsdag 05 april 2016 @ 09:46:
Dat is wel hѐѐl raar.

In principe zou een SMTP server een mail pas uit de queue mogen gooien als:
• deze ofwel goed is afgeleverd,;
• de SMTP server waar afgeleverd moet worden is te lang niet bereikbaar of geeft te lang achtereenvolgens temporary failures (NDR wordt teruggestuurd naar de verzender)
• de eindbestemming geeft een of andere permanente failure (NDR wordt teruggestuurd naar de verzender)

Als jouw Exchange onbereikbaar is OF een temporary failure geeft, dan gaat de andere SMTP server over naar de tweede server zoals gespecificeerd in de MX records. Die SMTP server gaat hetzelfde proces weer doen: retry's, retry en nog een retry..

Ik ben al even aan het nadenken maar ik snap niks van die verklaring van die provider.. dat zou met compliant SMTP servers niet moeten kunnen

Dan was mijn denkpiste toch niet zo fout
Tenzij er natuurlijk initieel iets verkeerd geconfigureerd is

Opstelling is: mx verwijst naar ip klant, in modem forward naar firewall, regel in firewall die zegt poort 25 naar ip-van-exchange en lijkt me ook correct.
ip klant MX is 10, MX van ISP is 50