Ein Blog-Leser hat mich auf eine sehr seltsame Beobachtung aufmerksam gemacht, die in seiner Netzwerkumgebung auftritt. Die E-Mail-Server werden seit 2 Wochen mit "invalid recipient"-Mails bombardiert. Ich stelle es mal in den Blog ein – vielleicht haben andere Leser das ebenfalls beobachtet.
Anzeige
Ein Leserhinweis
Ein Blog-Leser hat mich gestern per E-Mail kontaktiert (danke dafür), um mir seine Beobachtung mitzuteilen und zu fragen, ob das Thema vielleicht für andere Administratoren von Interesse ist. Der Leser schrieb:
Hallo Günter,
ich weiß nicht, ob das ein aktuelles Thema auch für andere ist. Wir beobachten seit ca. 14 Tage eine extremen Zuwachs an Versuchen mit zufälligen Email-Adressen (die natürlich als "invalid recipient" abgelehnt werden.
Das Verhalten ist immer gleich:
- ca. 2-3x pro Stunde sind es ca. 100 Versuche im Block, die From-Adresse ist jedes Mal anders, die Source-IP ist jedes Mal anders
- bei den To-Adressen werden verschiedene Domains von uns genutzt (auch solche, bei denen wir keine aktiven Mail-Adressen nutzen) und mit beliebigen „Namen" zusammengewürfelt.
Das sind aktuell ca. 10-20.000 Versuche pro Tag, am 14.05./15.05. scheint ein Testlauf stattgefunden zu haben uns seit 20./21.05. läuft diese Welle.
Meine Frage:
- Beobachten das andere Unternehmen auch?
- Welche Maßnahmen treffen andere Unternehmen und dies zu verhindern?
Die Versuche werden natürlich an den Server des Lesers geblockt. Aber die eingehenden Requests belasten die Systeme und füllen Log-Dateien, was deren Auswertungen schwieriger macht, usw.
log-File, Zum Vergrößern klicken
Was bedeutet "invalid recipients"?
Der Begriff "invalid recipients" steht für "ungültiger Empfänger", d.h. der empfangende E-Mail-Server hat die angegebene Adresse des Empfängers nicht in der Adressregistrierungsliste des Servers gefunden. Die an diese Adresse gesendeten E-Mails mit der Fehlermeldung "550 – Ungültiger Empfänger" zurückgewiesen – der sendende Server erhält eine entsprechende Mitteilung.
Fortinet beschreibt in diesem Beitrag, dass Spammer manchmal den DSN-Mechanismus nutzen, um Antispam-Maßnahmen zu umgehen. Bei diesem Angriff, der manchmal auch als "Backscatter" bezeichnet wird, fälscht der Spammer die E-Mail-Adresse eines legitimen Absenders und sendet absichtlich Spam an einen unzustellbaren Empfänger, in der Erwartung, dass der E-Mail-Server des Empfängers eine DSN an den Absender zurücksendet, um ihn über die fehlgeschlagene Zustellung zu informieren. Da bei diesem Angriff unschuldige E-Mail-Server und ein Standard-Benachrichtigungsmechanismus verwendet werden, können viele Anti-Spam-Mechanismen den Unterschied zwischen einer legitimen und einer gefälschten DSN nicht erkennen.
Ergänzende Meldungen
Auf Facebook sind mir einige Rückmeldungen von Administratoren zu obigem Thema zugegangen, die ich kurz einstelle:
Anzeige
Leser 1: Hatte ich bei Root-Servern (und somit Einsicht in die Logs des Mailservers) grundsätzlich fast jeden Tag und würde ich als Grundrauschen einstufen. Außer man hat den Mailserver als Open Relay usw. aktiv.
Ebenso sind fehlende SPF, DKIM und DMARC Einträge oft fast schon anziehend für solche Versuche, da dann Mail Spoofing in größerem Umfang auch gerne mal versucht wird.
Leser 2: Ukraine Krieg? Wir verzeichnen ähnliche Attacken auf anderen Wegen.
Leser 3: Bisher nicht. Aber die dürften auch relativ gut auffallen wenn der Absender nicht passt bzw sollte SPF die aussortieren.
2015
Es ist ja nix neues. Das wird schon seit zig Jahren von den Spammern gemacht da vielen Microsoft Afmins das Wissen fehlt um zwischen einem Reject und einem Bouncevzu unterscheiden.
Und da diese Admins schon bei minimal größeren Mailsystemen überfordert sind, nehmen erstmal jede Email an und prüfen erst dann, ob es den Empfänger gibt. Die schicken dann einen NDR an den angegebenen Absender… suuuper Idee.
Das nutzen Spammer aus und missbrauchen so das System als eine Art offenes Relay.
Das wiederum funktioniert, weil in der MS Welt DKIM unüblich ist und so der gefälschte Absender den NDR bekommt.
Man kann solche schlechten Mail Systeme auch als Multiplikator für Denial-of-service Attacken einsetzen.
Der Server landet dann recht schnell auf einer backscattering black Liste. Das sollte dem Admin aber auffallen, denn er prüft ja alle paar Stunden mal ob seine Mailout Server auf schwarzen Listen stehen, oder hält er sich für unfehlbar?
Nach meiner Erfahrung verschwinden solche Attacken nach kurzer Zeit wieder
Zur Not muss man halt die Bandbreite so weit reduzieren das der schlappe Mail Server die Verarbeitung Schaft. Da die Spanner nicht die Kühe schlachten wollen die sue missbrauchen reduzieren sie den Traffic. Auch sollte es dem Betreiber nicht zu weh tun, also nutzen sie nur einen geringen Anteil der möglichen Bandbreite, so das der Eigentümer keinen Anlass hat, irgendwie gegen Maßnahmen zu treffen. Doof sind die ja nicht.
Es ist nicht richtig, das das Opfer Fake DSN nicht erkennen könnte.
Darum hat man DKIM und DMARC erfunden.
Damit werden alle E-Mails unterschrieben.
Kommt eine Email als bounce DSN zurück, kann man an der eigenen Unterschrift feststellen, das es kein Fake Bounce ist.
Aber das erfordert schon einiges Wissen.
Auch fehlt das Wissen das man so eine verteilte Attacke nur aussitzen kann und evtl. den Betreiber der missbrauchten IP benachrichtigen. Das kostet aber viel Zeit und Bandbreite ist billiger…
Was will man denn mit der From Adresse?
man prüft die Absender per SPF und macht sofort einen reject, ganz gemütlich.
Wenn man mit dem Versenden von NDR aufhört enden auch diese E-Mails.
Ah immerhin ein Logfile.
Es scheint immer derselbe Absender zu sein.
Vorallem die selbe IP und zwar eine Adsl IP.
Normalerweise sperren heute alle Mail Server dynamische IPs vom Email Verkehr aus.
pool-adsl klingt nach einer dynamischen IP.
Warum nehnt ihr das Zeug überhaupt an?
Bitte Mal die eigene Outgoing IPs auf den bekannten Black lists suchen.
Das sieht aus, als würde das System massiv für Backscattering missbraucht werden.
Sieht der einliefernde Server wirklich ein 550?
Oder entsteht das erst nach der internen Weitergeleitungen, wie man es oft in historisch gewachsenen Systemen sieht?
Und natürlich diese Spanner IP ausbremsen.
Manche lassen von einem Ab, wenn sie für die dritte Email nicht sofort losgeworden sind.
Hast Du Mal ausgerechnet welche Bandbreite diese 30k emails pro Tag darstellen(was echt nicht soooo viel ist.
wenn man 10kB pro Email annimmt dann find das 30k*10k= 300kB/d.
das ist doch garnix und sollte keinen Mailserver stöhnen lassen.)
Aber gut das Dir das Aufgefallen ist.
Mich wundert das in der Grafik von viurs Mails gesprochen wird. Das würde bedeuten, das die E-Mail komplett empfangen wurde?
Hier scheint dem Spammer die gesamte Bandbreite zur Verfügung zu stehen, soviele E-Mails da innerhalb der 50. Sekunde angekommen sind.
kB * kB = MB, also 300 Megabyte
https://www.abuseipdb.com/check/113.195.172.96
kennt diese IP als böse
Warum hat der Anfrager das nicht selbst eruiert und
warum nimmt er überhaupt von dort E-Mails an?
Hat er da einen kommerziellen Email Filter Anbieter vorgeschaltet?
Das würde allerdings erklären, das er sich sorgen ob der hohen Anzahl macht.
Ich glaube ab 300tsd E-Mails im Monat wird es teuer.
Und klar das solche Anbieter die dicksten Leitungen und Server haben…
Oh…das kam mir so komisch vor…
wenn man 10kB pro Email annimmt dann find das 30k*10k= 300MB/d. nicht kB/d
Also 27Mbit/s
das ist dann doch viel für so einen Exchange.
Aber wie gesagt:
Das Empfangs System wird Backscattering
machen,
und keine SPF Prüfung hart durch ziehen
und wer E-Mails von dialups/Dyn IP überhaupt animmt sollte sich einem anderen Consultant umsehen.
Die Frage war zwar, ob wer das auch hat, aber die Frage ist überflüssig, da man das immer mal hat.
Kurios ist das jedenfalls nicht
auch wenn es früher mal Mailserver gab, die durchdrehen könnten wenn sie ihre E-Mail nicht loswurden. das ist hier nicht der Fall.
Da im Log File Absender konstant ist(anders als im Fließtext steht, ist das doch kein Missbrauch der Bounce Funktion sondern der Versuch, weitere E-Mail Adressen zu ermitteln.
Da man generell keine E-Mails von Dyn IP annimmt funktioniert das Verfahren eigentlich nicht mehr.
Wenn das betroffene System Aber NDR verschickt an diese eine Adresse, weiß der Spammer ob es dieses Email Adresse gibt.
Aber wie gesagt.
Gestaltet man den Local Part hinreichend unquiq lassen sich so keine neuen Adressen gewinnen.
Es ist also eine queme aber doofe Idee, Email Adressen wie Vorname.Nachname@domsin.tld zu erzeugen und extern zu verwenden…
Dafür gibt's Aliasse.Wirklich schützen kann man sich nicht. Auch wenn es nervt, den Brief Kasten sollte man nicht zukleben.
Oder gibt's neue Verfahren um mit Kunden in Erstkontakt zu kommen?
Z.B. per WhatsApp?
"bei den To-Adressen werden verschiedene Domains von uns genutzt (auch solche, bei denen wir keine aktiven Mail-Adressen nutzen) und mit beliebigen „Namen" zusammengewürfelt.
"
Die Namen nennen sich nach Rfc "local part"
Wenn ihr die Domain nicht für Email verwendet, warum habt ihr dafür einen MX Eintrag gemacht und nehmt dafür überhaupt E-Mails an?
Ohne MX Eintrag können die E-Mails ja gar nicht bei eurem Mailserver landen (wie sollte der Spamner das zuordnen können?) oder dieser Server rejectet mit :550 we do not relay…
Allerdings wenn ihr das Problem email Ausgelagert habt und dieser Dienstleister seine Mail Server als MX angegeben hat für alle eurer Domain LS, ist klar, warum ihr Email auch auf die nicht Mail aktivien Domains bekommt…
Die sehen ja im DNS für welche Domains der Dienstleister zuständig ist.
Diese Anbieter wollen natürlich möglichst viele E-Mails für euch verarbeiten. Nicht weil sie nett sind, sondern pro Email bezahlt werden.
Auch pro rejecteter… die fast keinen Aufwand macht.
Darum nehmen sie auch Mails von dynIp an.
Wenn sie schon die IP erden würden, wüssten sie ja gar nicht für wen die Email war.
Achso:
Manche dieser Anbieter sind nicht DSGVO konform und hosten in den USA.
Bitte nicht falsch verstehen – es ist zu begrüßen, wenn Nutzer kommentieren – und ich grätsche auch nicht gerne hier rein. Manche Kommentare beziehen sich ja auch auf Vorposter.
Aber es wurde bereits von anderer Seite angemerkt, dass es kontraproduktiv ist, wenn der Blog von einer Person mit zig Kommentaren geflutet wird.
Es sind jetzt 7 Kommentare in kürzester Zeit eingeschlagen – wer soll das lesen? Etwas fokussiertere und ggf. zusammenfassende Kommentare wären imho für die Mitleser hilfreicher – danke für das Verständnis.
Red Falgs:
– From *.ru
– *adsl-pool*
– *chinaunicom.com
– Anzahl der Anfrage in Abhängigkeit der Zeit (wo ist das Rate Limit?)
Sorry, aber hier wundert mich gar nichts. Ich würde dem Einsender dringend empfehlen auf einen professionellen Mailhoster umzusteigen.
Nicht weil ich ihn für Inkompetenz halte, sondern weil professionelles Mailhosting heut zu Tage mehr braucht als ein paar Log Files.
Der Aufwand ist einfach immens. Und wenn man dann einen Webmail (inkl. Zugriff für mobile eClients) absichern will, dann verdoppelt sich der Aufwand gleich nochmal…
Die Frage ist, ob er das nicht bereits gemacht hat.
Wo kommt das Diagramm her?
Wohl nicht auf Exchange.
Das Sperren aufgrund von Strings ist eine Sysiphus Arbeit und kostet zuviel Ressourcen, für den Vergleich und die DNS lookups.
(RBLs kann man lokal speichern)
Man fragt heute eigentlich als erstes die IP bei einer RBL ab und spricht gar nicht erst weiter mit dem Sender sondern lässt ihn erstmal hängen ehe
man eine 550 gibt.
Wenn Du den falschen Email Hoster hast, kann es aber so aussehen wie hier.
Er berechnet Dir jeden Versuch.
Seltsam finde ich, das auch ungenutzte Domains einen Wörterbuch Angriff aufgesetzt werden.
Das Diagramm kennt offenbar ein Rate Limit(blau).l, aber kein RBL..
Scheinbar wird vom Mail host nur der Empfänger getestet.
Hier bedeutet das das man dem Spammer genau die Informationen liefert die er haben will, neue funktionierende Email-Adressen.
Entweder durch einen (nicht-)Reject, den an die konstante dialup IP ja sieht. Oder durch den (nicht-) Bounce an den konstanten Empfänger.
Für einen unseriösen Mail Hoster ist natürlich jede weitere verbrannte Adresse bares Geld. Also nimmt er alles an. Der Diagramm Legende nach gibt es kein Blocken aufgrund der IP…
Woher kommt das Diagramm?
Welchem email holster kann man trauen?
Das Diagramm und auch das Logfile kommen von einem Barracuda Email Security Gateway. Warum du (Pau1) der Meinung bist, es kann keine RBLs nutzen, ist mir ein Rätsel, aber okay.
Der Check ob es die Empfängeradresse gibt, ist optional und bei Verwendung dieser Funktion, ist es der erste Schritt den das EmailSecurityGateway bei ankommenden Mails durchführt. Wenn es den Empfänger gar nicht gibt, muss die E-Mail auch nicht komplett angenommen werden und wird gleich im ersten Schritt abgelehnt, ohne das die komplette Mail angenommen wurde und an einen Exchange weitergleitet wurde. Die Prüfung auf vohandene Empfänger am Mail Security Gatgeway soll ja auch den Exchangeserver entlasten, sonst würde die komplette Mail an den Exchange gesendet werden, der dann feststellt ich habe gar kein Postfach für den Empfänger.
Alle anderen Prüfungen bspw. mit RBLs kommen erst später in der Mailflow-Reihenfolge, ebenfalls die Prüfung auf Virus Anhänge etc. dafür muss die Mail aber ggf. komplett angenommen werden. Einen Exchangeserver auf Empfängerseite haben all diese Mail bis dahin nie gesehen und durch das Blocking werden sie auch nie einen sehen. Mal davon abgesehen, das auch gar nicht klar ist ob der Ursprungsposter überhaupt einen Exchange betreibt. Selbst wenn es einen Empfänger dann zufällig doch geben sollte, wird die Mail höchstwahrscheinlich dann durch andere Module im Mail Security Gateway geblockt.(natürlich je nach Konfiguration)
In einer Umgebung habe ich genau die gleiche Beobachtung gemacht wie der Ursprungspost beschreibt. Ob da nun nach gültigen Empfängeradressen gesucht wird kann ich nicht sagen, ist aber eine Möglichkeit.
Der betreffende Blog-Leser hat sich per Mail nochmals kurz bei mir gemeldet und sinngemäß geantwortet
Ich kann die Sichtweise des Lesers nachvollziehen – warten wir ab, ob sich die Befürchtung mit den Bot-Netzen bewahrheitet oder nicht.
Warum da keine RBL eingesetzt wird ist ja klar.
Die IP-Adresse hier ist bereits in Zig RBLs drin.
Auch Nachbar-Adressen.
Eigentlich besteht inzwischen die Konvention, keine E-Mails von Dyn.IP anzunehmen.
Warum macht dieser Mail Hoster das trotzdem?
Und warum wurde dann noch überhaupt der Empfänger geprüft ob er existiert?
Außer man will dem Spammer seine Datenbank mit gültigen Adressen per Rejects verraten.
Warum eine Email angenommen wurde dessen Absender Domain keinen MX hat ist auch gegen die Konversation. Wie schön dargestellt, hat wer der eine Email annimmt auch die Verantwortung dafür.
Damit er den Absender benachrichtigen kann, wenn es im weiteren Transport hakt, braucht er einen gültigen Absender.
Barracuda rechnet m.W. nach Anzahl der E-Mails ab.
Also werden die den Teufel tun und erstmal in den RBLs nachsehen um dann den Rest sofort rejekten.
So wüssten sie ja nicht für welchen Kunden die E-Mail war…
Auch haben sie kein Interesse daran, das diese Versuche beendet werden. Die sind ja bares Geld.
Der unwissende Kunde freut sich aber, wie toll der mailhoster arbeitet…
TLD sind nicht pauschal als Red Flag zu sehen. Eine Hilfsorganisation mit internationalen Kontakten, benötigt vielleicht dann eher doch auch .ru und .cn oder dergleichen. Dynamische IP-Adressen hingegen sind grundsätzlich an der Einlieferung zu hindern. Reverse DNS existiert.
Jupp.
Man schaut aber nicht im normalen DNS nach sonderen in einer RBL die speziell nur Dyn-IP listet.
Denn ob man aus dem Namen das so sicher erkennen kann, ist unwahrscheinlich. Auch ist vorstellbar, das ein Unternehmen eine feste IP aus dem dynamsichen Pool bekommen hat.
Ist alles nicht so einfach, sigh.
Genau deshalb schaut man in dem Fall NICHT in irgendeine RBL rein. Reverse DNS hat genau den Sinn, den zu einer IP-Adresse beim Inhaber hinterlegten reverse DNS Eintrag zu ermitteln. Da meine eigene Domain: vergleiche ncc-1701.kaerner.net mit home.kaerner.net via reverse DNS, dann verstehst Du, was ich meine. Eine RBL kann gar nicht sinnvoll und sicher dynamische IP-Adressen in der Datenbank vorhalten, weil ich als Inhaber des Subnetzes ganz allein bestimme, was ich mit den mir zur Verfügung stehenden IP-Adressen anstelle. In meinem öffentlichen Subnetz gibt es jedenfalls Adressen, die ich dynamisch zuweise und solche, die statisch zugewiesen sind.
Es gibt spezielle RBLs die die die dynIP listen.
Sollte man da versehentlich drauf stehen, kann man seine Adresse freischalten lassen.
Filtert der Empfänger aber auf den rDNS darf man den ändern.
In diesem Fall ist die Adresse aber schon als Böse bekannt und hätte geblockt werden können.
Aber wir kommen nicht weiter da jetzt endlich gesagt wurde das da ein externes Securit6Gate way für verantwortlich ist.
Und das sollte ja angeblich die Beste Lösung sein, weil oftmals das Wissen feht.
Der Einsatz eines Mail hosters macht auch klar, warum man ein verzehnfachung des Traffics nicht als "Grundrauschen" abtun kann. Es kostet richtiges Geld, wenn man soviel Traffic hat.
Oder berechnet Baracuda das Email-Volumen nach den erwünschten E-Mails?
Unsere Diagramme sehen sehr ähnlich aus und wir haben ebenfalls seit einigen Wochen das gleiche Verhalten (um mal auf die eigentliche Frage zu antworten).
Wir sind gerade dabei, mit unserem externen Hoster zu sprechen und einige Einstellungen anzupassen.
Auch wenn ich nicht allem zustimmen kann, was pau1 so von sich gibt, bei zwei Dingen unterschreibe ich sofort: dynamische IP-Adressen sollten keine Mails irgendwo einliefern dürfen, gerade auch deshalb, weil so viele Betreiber eines MTA an dynamischer IP-Adresse das so gar nicht verstehen, dass man sie aussperrt. Und natürlich hat im DNS Record einer Domäne ohne Mailverkehr kein MX Eintrag etwas zu suchen. Die zwingend notwendigen Mailadressen, damit das NIC die Füße stillhält, erstellt und pflegt man im MTA einer Domäne, die auch Mail können soll und muss.
@pau1: bevor Du jemanden belehrst, wie der Teil links vom @ nach Rfc heisst, lerne bitte zunächst selbst, dass es IP-Adresse und nicht IP heisst.
oh je. Warum wirst Du wieder mal persönlich?
Und fängst an Haare zu spalten nur um was zu meckern zu haben?
Stimmst meinem Betrag zu, aber nicht ohne mich persönlich erstmal abzuwerten?
Seltsamer Stil.
Der Ausdruck "Name" ist nicht nicht eindeutig.
Vermutlich ist der Teil vor dem @ gemeint, es könnte aber der "Display Name" gemeint sein. Und viele Leute wissen halt nicht, wie man das nennt. Daher mein Hinweis.
OK, ich hätte das als Frage formlieren können.
Viele schreiben auch kurz "IP" wenn klar ist, das das IP-Adresse sein soll.
Hier herrscht eigentlich ein sachliches Niveau.
Was genau meinst Du genau mit der abwertenden Bezeichung"
da Pau1 so von sich gibt", Konkret,
Ich lerne gerne dazu.
Ich hoffe es geht hier jetzt ohne Heise.mäßige persönliche Angemache weiter und
wir können dem Leser konstruktiv niveauvoll helfen,
z.B. mit ein paar Tipps, was er an seinem (nicht gerade billigen)) Exchange einstellen soll (oder wo er Infos dazu findet) oder welchen Mailhoster er vorschalten könnte, wenn er damit überfordert ist. Die Aufgabe ist wirklich nicht einfach zu lösen.
Das sehe ich ja hier an macher Antworten, wie z.B. die einfach *.cn sperren wollen.
Das geht natürlich garnicht.
Ich habe mir jetzt mal die Logfiles meiner MTAs über die letzten Tage angesehen. Neben der üblichen Menge an Versuchen, als Administrator oder root Mail abzuholen und halt eben dann und wann zu testen, ob die Server vielleicht doch open relays sind, sehe ich keinerlei signifikanten Anstieg, wie sie hier von Deinem Blog-Leser gemeldet wurden, Günter. Kann es sein, dass hier eventuell gerade massiv Tests explizit gegen Exchange-Server gefahren werden? Meine MTAs basieren durchweg auf unixoiden Betriebssystemen…
Siehst das nicht in Deinem log.
Du benutzt aber auch kein Baracuda oder so vor Deinem Systemen?
Weil die Spammer ja nur sehen, das da ein Barracuda als MX eintragen ist, aber eher nicht das das Zeug bei einem Exchange abgeladen wird
Und es kommt wohl öfter vor, das das Endsystem nicht richtig einkonfiguriert wurde und es so zu backscattering kommt.
Das erinnert mich an die Zeit, als die Antivirus Gateways aufkamen und die überfordern Admins dessen IP Adresse freigegeben hatten und damit ihr System zum offenen Relay machten…
Da war es auch manchmal schwer den Admin zu überzeugen, das er etwas ändern muss.
Es gab auch früher schon solche Wellen.
Die verebbten dann bald.
Beachte auch was für local parts getestet wurde.
Und diese Wellen waren nicht mit Kosten verbunden.
microshema74.ru
hat 2 IPv4
aber keinen MX Eintrag ,
keinen SPF
und eine
TTL von nur 300..
Schon "kein MX" ist
hinreichend die Email rejecten zu müssen,
denn im Fehlerfall könnte der Absender nicht erreicht werden.
Es wäre schon schön zu wissen
was für eine Konfiguration
das ist.
Ist das ein nackter Microsoft SMTP Host, so wie er von der DVD kam?
Oder ein unseriöser Mail holster, der pro Email abrechnet?
Die beiden IP-Adressen, die Du siehst, gehören Cloudflare. Der Betreiber der Domain bedient sich also der Verschleierungsdienste von Cloudflare, um die tatsächliche Zieladresse für die Domain nicht bekannt geben zu müssen. Ein SPF ist nicht nötig, wenn schon kein MX besteht. Die TTL von 300 ist jedenfalls den Diensten von Cloudflare geschuldet und ganz sicher auch von Cloudflare so gesetzt, um im Fall eines DOS/dDOS die Unerreichbarkeit des Ziels per DNS möglichst klein zu halten.
Interessant das mit Cloud fkare.
D.h. das die Spammer über einen größeren Provider Zugang haben und cloudflare dieses unterstützt.
Es wird ja wohl nicht Baracuda sein, die die Daten über Cloud glare leiten und dann diese Adresse loggen?
Dennoch sind diese Adressen auch in RBLs enthalten.
Wenn man solche Verscheierungs Diente benutzt, kann man schlecht mit SPF arbeiten.
Ja, ich dachte mir ja schon das erstmal der Empfänger geprüft wird, wenn man das -uberhaupt, gegen Aufpreis?- aktiviert hat und all seinen User im Klartext? nach USA? hochgeladen hat und dort aktuell hält.
Auf den ersten Blick erscheint dieses Vorgehen logisch und geboten, weil das keine externen Ressourcen braucht. Aber so kann der Spanner am Nicht-Reject erkennen, welche der Adressen gültig sind. Das möchte man ja auch nicht. Wenn man aber anhand der IP Adresse schon gesperrt hat, bekommt der Spammer keine neuen Informationen. Natürlich kommt dann auch keine Email bei bekannten, erratenen Empfängern an. Aber es ist eh nur Spam.
Für den Mail Hoster bestünde aber nun das Problem, wie er den Traffic den Kunden zuordnen und belegen kann, so ohne Mail from und receipt to Daten.
Dieses Problem entsteht also durch die Anforderungen des externen vorschalteten Security Gateways zur Abrechnung…
ich vermute, das die Kunden von solchen externen Mail hosts gerne als Opfer genommen werden…
Man fragt sich ja auch, wie die Spammer an die nicht benutzen Domains gekommen sind.
Wenn es dafür einen MX record gibt, steht da auch "baracuda" oder so dran…
Also die Frage ist:
Sehen Kunden von Security Gateways auch solche Angriffe?
Sollte das eine Barracuda E-Mail Security Gateway Appliance sein, würde ich die sofort aus dem Rack reissen und in die Tonne treten. Betroffene sollten eigentlich über das Dashboard informiert werden, das diese ESG`s Elektroschrott sind (egal welches Patch-Level)!
https://www.barracuda.com/company/legal/esg-vulnerability
Darum verwende ich CommuniGate Pro – https://www.communigate.world
Ich beantworte auch gerne Fragen.
Man kann nur hoffen daß die armen Tropfe die Barracuda ESG Apliance in einer eigenen Hardware und eigenen DMZ hatten…
Ich hatte deren Website vor einiger Zeit gelesen und danach nie wieder angefasst.
Allein der Umstand daß sie ein eigenes Verfahren entwickelt haben um Fake-bounces zu verhindern, zeigte das es denen nur im eines geht.
Ich fürchte auch, das die Opfer den Email Empfang in die Cloud von Barracuda schieben werden
Die war ja seltsamerweise nie von Expoits betroffen und es ist natürlich weit einfacher, den MX zu ändern als einen neue Hardware für einen eigenen Appliance hochzuziehen.
Zumal man ja fürchten muss, das weitere eigene System kompromittiert werden konnten
..