136423
Goto Top

SMTP Traffic über die Firewall

Liebe Community,

ich hätte eine kurze Frage an euch. Seit nunmehr ein paar Tagen registriere ich auf unserer Firewall (ASA-5508X) einen permanenten Traffic von unserer Firewall [IP_1] zu unserem Mail-Hoster [IP_2] über den Port 25.
Die Source IP-Adresse ist die IP-Adresse unserer Firewall am Outside Interface. Es gibt ungefähr 5-7 Versuche pro Sekunde. Die Verbindung wird sofort wieder beendet ("Teardown").
Was ist der Hintergrund? Wie kann ich das blockieren?

Ein ACE für die IP-Adressen an den Interfaces kann ich schreiben, doch eine für die Firewall selbst geht irgendwie nicht.
Es sieht fast so aus, als sendet die ASA direkt tausende Anfragen Richtung Mail-Hoster.

Sep 03 2019 13:12:33 [IP_1] 15666 [IP_2] 25 Built outbound TCP connection 9102470 for outside:[IP_2]/25 ([IP_2]/25) to identity:[IP_1]/15666 ([IP_1]/15666)

Content-Key: 491085

Url: https://administrator.de/contentid/491085

Printed on: April 26, 2024 at 07:04 o'clock

Member: sabines
sabines Sep 03, 2019 at 12:20:27 (UTC)
Goto Top
Moin,

welchen ASA Release Stand hast Du und wie, wenn nicht über die FW, versendet/empfangt ihr Mails?
Wie lange ist die ASA schon online, ggfs. mal einen reload machen.

Gruss
Member: Pjordorf
Pjordorf Sep 03, 2019 at 12:50:37 (UTC)
Goto Top
Hallo,

Zitat von @136423:
Was ist der Hintergrund? Wie kann ich das blockieren?
Frag dich lieber warum deine ASA eine Vernbindung auzubauen versucht und es mit Teardown endet. Nur du kannst wissen wie bei euch die Mails laufen oder welche Dienste auf der ASA Mails generiern oder wer oder was sonst Mails verschicken will. Vielleicht ist ein Neustart die Lösung, Firmaware Updates die Lösung oder euren Mailserver verbieten Mails an ein Smarthost zu senden oder es ist einfach ein Zertifikat abgelaufen oder der Mailanbieter hast enfach was geändert. Wir können hier nicht sehen was du evtl sehen kannst. Und ihr scheint auch nicht nur eine IP ausm Internet zu beziehen wenn dies die Subnetzmaske sein soll (/25) oder das ist das nur Port 25?

Es sieht fast so aus, als sendet die ASA direkt tausende Anfragen Richtung Mail-Hoster.
Es wird so sein wenn keiner sonst Ausgehend Port 25 nutzt, noch dazu auf diese eine IP eures Mailanbieters. Wer oder was das von Intern auslöst - siehe Firewall Logs.

Gruß,
Peter
Member: aqui
aqui Sep 03, 2019 at 13:48:17 (UTC)
Goto Top
Traffic von unserer Firewall [IP_1] zu unserem Mail-Hoster [IP_2] über den Port 25.
Unverschlüsslter Email Traffic. Das ist ja Steinzeit. Wer macht denn heutzutage noch unverschlüsselten Email Transfer ?!
Die Source IP-Adresse ist die IP-Adresse unserer Firewall am Outside Interface.
Logisch, denn die macht ja NAT (IP Adres Translation) wenn der Mailserver im internen Netz positioniert ist !
Was ist der Hintergrund?
Was erwartest du ?? Hellsehen können wir auch nicht. Minimum wäre mal ein Screenshot dieses Traffic mit dem Wireshark gewesen um das zielführend und helfend beurteilen zu können ! Leider Fehlanzeige... face-sad
Kann man aber nachliefern...
Interessant wäre auch mal per http://www.utrace.de herausszubekommen WEM die Empfänger IP zuzuordnen ist !
Auch da leider Fehlanzeige bei dir face-sad
Wie kann ich das blockieren?
Mit einer simplen Access Liste zum Beispiel. Wozu hast du eine Premium Firewall von Cisco ? Sowas ist doch das erste an was ein normaler Netzwerker denkt ohne ein Admin Forum zu befragen ?!
Es sieht fast so aus, als sendet die ASA direkt tausende Anfragen Richtung Mail-Hoster.
Sorry, aber das klingt eher nach einem hilflosen Rateversuch statt gemesener Fakten ?!
Also Wireshark an die Hand nehmen oder den Debugger der ASA aktivieren und etwas mehr Infos. Dann müsen auch wir nicht hilflos raten.
Mitglied: 136423
136423 Sep 03, 2019 at 21:16:59 (UTC)
Goto Top
Ersteinmal danke für eure Antworten, aber ich denke ihr habt mich falsch verstanden.

@ Aqui
=> Wir versenden keine Mails über die 25, daher bin ich ja verwundert. Bei uns läuft alles über die 587
=> [IP_1] ist unsere Firewall IP am Outside-Interface. Da sendet auch keine interne Adresse, da sonst die IP unserer internen Netzwerke angezeigt würde (e.g. 192.168.6.6.). face-wink Da ist weit und breit keine andere IP
=> [IP_2] ist wie geschrieben der smtp-host unseres Internetproviders (der auch unsere E-Mails hostet)
=> wir sind ein kleines Unternehmen, daher konnte ich kontrollieren, dass auch wirklich niemand E-Mails versendet

Ich werde einen Neustart versuchen

VG
niLuxx
Mitglied: 136423
136423 Sep 04, 2019 updated at 06:53:09 (UTC)
Goto Top
Hallo zusammen,

Problem besteht nach Neustart leider weiterhin. DEBUG-Mode liefert keine weiteren Informationen zu dieser Sache.
Eine Initiierung von intern schließe ich aus, da dort normalerweise jeweils eine "Built NAT-Translation" Nachricht kommen sollte, die allerdings fehlt. Aus meiner Sicht wird die Verbindung direkt von der ASA gestartet.
Ein ACE habe ich ohne Erfolg versucht.
Source-Interface: Outside
Source-IP: Statische IP der ASA (Outside Interface)
Dest-Interface: Outside
Dest-IP: Any
Service: tcp/25

Der ACE bringt keinen Erfolg. Schätzungsweise kann die ASA sich nicht selber blockieren.
Einen Screenshot habe ich beigefügt.

Ganz viele Grüße,
niLuxx
asa
Member: aqui
aqui Sep 04, 2019 updated at 07:31:04 (UTC)
Goto Top
Aus meiner Sicht wird die Verbindung direkt von der ASA gestartet.
Das wäre Unsinn, denn die ASA supportet ja physisch schon mal gar kein SMTP als Endgerät. Sie kann nicht "emailen". Kann also folglich niemals selber eine SMTP Session aktiv aufbauen. Eigentlich kann das nur ein NAT Prozess sein. Was sagt denn ein show nat trans ? Sieht du dort Port 25 Translations ?
Schätzungsweise kann die ASA sich nicht selber blockieren.
Doch das klappt. Jedes IOS Gerät kann das.
Was sagt denn ein Wireshark Trace. Das wäre doch das Sinnvollste den betreffenden Traffic mal genau anzusehen ! Port 25 ist zudem unverschlüsselt. Du kannst also sogar den kompletten Inhalt mit dem Wireshark mitlesen. Das sollte doch dann sofort Aufschluss über den Verursacher geben !
Mitglied: 136423
136423 Sep 04, 2019 at 08:49:31 (UTC)
Goto Top
Hallo Aqui,

ich habe noch einmal nachgesehen.
Den Befehl *show nat trans* gibt es leider nicht. show xlate zeigt mir allerdings aktive NAT Verbindungen und da gibt es keine auffällige, d.h. ich sehe weder den SMTP Endpunkt unseres Providers, noch den port 25 bei irgendeiner Verbindung.
show conn zeigt ebenso keine Verbindungen dieser IP-Adressen.


Whireshark ist leider ebenso nicht hilfreich. Es zeigt mir nur meine Verbindung, da sich die Clients in einem anderen Subnetz befinden und nicht in Verbindung zu meinem Subnetz stehen.

Gibt es irgendwelche Flash-Viren bei der ASA?
Member: aqui
aqui Sep 04, 2019 updated at 08:57:10 (UTC)
Goto Top
Whireshark ist leider ebenso nicht hilfreich. Es zeigt mir nur meine Verbindung
Kann ja eigentlich nicht sein !!
Du beschreibst ja selber das die SMTP Verbindungen ja angeblich direkt von der ASA ausgehen sollen. Also müssen sie ja dann auch an der ASA mit dem Wireshark zu messen sein. Ganz sicher ja am ASA WAN Port. Wenn sie vom lokalen Netz kommen dann auch am lokalen Inbound Port der ASA.
Logischerweise sollte also DA auch der Wireshark zum Messen angeflanscht sein und NICHT auf einem unbeteiligten Client irgendwo im Netz. Das sagt einem ja aber auch schon der gesunde IT bzw. Netzwerk Verstand ! face-wink
Member: sabines
sabines Sep 04, 2019 at 08:56:14 (UTC)
Goto Top
Moin,

wie ist denn der Relase Stand?
TAC aufmachen?

Gruss
Mitglied: 136423
136423 Sep 04, 2019 at 09:50:33 (UTC)
Goto Top
@ Sabines, sorry, voll verpennt.
show vers

Cisco Adaptive Security Appliance Software Version 9.8(1)
Firepower Extensible Operating System Version 2.2(1.47)
Device Manager Version 7.8(1)

Das mit dem TAC ist eine Idee.

@aqui
Zwecks Wireshark. An den WAN Port kann ich leider nicht, da die Kiste gut 350 km entfernt liegt
Member: aqui
aqui Sep 04, 2019 at 11:36:17 (UTC)
Goto Top
Einen lokalen Kollegen hinschicken zum Messen... face-wink
Mitglied: 136423
136423 Sep 04, 2019 at 12:05:23 (UTC)
Goto Top
Wenn es nur so jemanden gäbe... face-big-smile ich bin Einzelkämpfer, leider. Zumindest gibt es niemanden der sich mit Whireshark sonst noch auskennt face-smile
Ich habe mal den Cisco-TAC bemüht und halte euch auf dem Laufenden.

Hab sogar noch einmal die Postfächer von jedem Client kontrolliert. Alle nutzen SMTP/465. Außer die Exchange-Konten senden dauerhaft über die 25...was ich aber fast nicht denke
Member: aqui
aqui Sep 04, 2019 at 14:22:15 (UTC)
Goto Top
Übrigens hier noch eine spannende Lektüre zum Thema:
https://www.heise.de/security/meldung/Ratgeber-vom-Hersteller-So-erkennt ...
Bzw. für deine ASA und FirePower:
https://tools.cisco.com/security/center/resources/asa_forensic_investiga ...
https://tools.cisco.com/security/center/resources/ftd_forensic_investiga ...

Das TAC Feedback wäre in der Tat recht spannend. Wir sind gespannt...
Member: sabines
sabines Sep 05, 2019 updated at 05:11:08 (UTC)
Goto Top
Zitat von @136423:

Cisco Adaptive Security Appliance Software Version 9.8(1)
Firepower Extensible Operating System Version 2.2(1.47)
Device Manager Version 7.8(1)


Also die 9.8(1) ist mittlerweile bei 9.8(4) 10 (interim), die solltest Du, unabhängig vom derzeitigen Fall, aktualisieren.
Wenn der TAC das nicht sowieso als erstes vorschlägt face-wink
Member: aqui
aqui Sep 05, 2019 updated at 13:36:32 (UTC)
Goto Top
Dann soll das TAC aber auch explizit auf den Bug in der Version verweisen der direkt von der FW selbsständig TCP 25 Sessions in die Welt aufbaut... Und...das dieser Bug mit der neuen Version gefixt ist ! face-wink
Der Fehler klingt wirklich bizarr. Wüsste der TO es nicht besser könnte man vermuten das die ASA zuvor erstmal bei der NSA gewesen ist oder in China... face-big-smile
Member: Pjordorf
Pjordorf Sep 05, 2019 updated at 13:52:19 (UTC)
Goto Top
Hallo @aqui,

Zitat von @aqui:
Dann soll das TAC aber auch explizit auf den Bug in der Version verweisen der direkt von der FW selbsständig TCP 25 Sessions in die Welt aufbaut... Und...das dieser Bug mit der neuen Version gefixt ist ! face-wink
Der Fehler klingt wirklich bizarr. Wüsste der TO es nicht besser könnte man vermuten das die ASA zuvor erstmal bei der NSA gewesen ist oder in China... face-big-smile
Der TO hat doch noch gar keine Rückmeldung hier gegeben oder hat er sich direkt bei dir gemeldet oder hast du Info bekommen das dies ein wirklicher Fehler bzw. Bug im Cisco ist? Oder ist dies dein guter rat an den TO...

Gruß,
Peter
Member: aqui
aqui Sep 05, 2019 updated at 14:10:14 (UTC)
Goto Top
Man beachte den Konjunktiv !! "...die solltest Du, unabhängig vom derzeitigen Fall, aktualisieren.
Also nur für den Fall das das TAC unreflektiert ein Update vorschlagen sollte. face-wink
Fazit: Wir warten auf das TAC Feedback.
Mitglied: 136423
136423 Sep 05, 2019 updated at 16:09:10 (UTC)
Goto Top
Aaaalso. Hier mein finales Update... die Erklärung ist wirklich schlimm...sehr schlimm.
...ich habe vor kurzem versucht (und vergessen) dass ich mir die Logs per E-Mail senden wollte.
Daher hatte ich einen smtp Server in die ASA eingetragen. Seitdem hat die ASA ständig versucht mit dem Server zu kommunizieren, ohne Erfolg, da Port 25 bei unserem Provider nicht mehr unterstützt wird.
Was soll ich sagen...
Mensch = Fehler....

Danke für eure Unterstützung face-smile Auch wenn der Fehler weder ein Bug, noch ein Hack, noch etwas anderes war
Member: aqui
aqui Sep 05, 2019 updated at 16:50:08 (UTC)
Goto Top
noch etwas anderes war
Es war ein Bug zwischen den Kopfhörern ! face-monkey
Wie peinlich !!! Die Konfig hättest du aber nun wahrlich nochmal akribisch durchgehen können...
Dann schliessen wir besser mal ganz schnell und heimlich diesen Thread...!! face-wink
Member: Pjordorf
Pjordorf Sep 05, 2019 at 16:51:28 (UTC)
Goto Top
Hallo,

Zitat von @136423:
...ich habe vor kurzem versucht (und vergessen) dass ich mir die Logs per E-Mail senden wollte.
Daher hatte ich einen smtp Server in die ASA eingetragen. Seitdem hat die ASA ständig versucht mit dem Server zu kommunizieren, ohne Erfolg, da Port 25 bei unserem Provider nicht mehr unterstützt wird.
Dann schnell noch How can I mark a post as solved? und alle sind wieder happy. So passiert es eben manchmal.

Gruß,
Peter