Fragensteller
EX 2007 und NDR DoS

Allgemeine Diskussion
-
Hi,
wir haben auf einem Kundenserver seit ca. 14 Tagen ein massives Problem mit einer NDR Attacke (so unsere Vermutung) und wir bekommen das ganze nicht sauber in den Griff.
Unsere Konstellation ist: EX 2007 Server SP3 mit RUP8, EX 2007 Server SP3 (Edgeserver) RUP8 mit TMG 2007. Am Edgeserver sind Blacklists eingestellt.
Die Server erhalten gezielt E-Mails, die NDRs verursachen von einem Webserver. Die NDRs gehen dann immer z.B. an nadine@nadine.com oder sandra@sandra.com usw.
Als Domänen laufen dann un/bekannte Domänen in den Wartenschlangen auf (yaooo.com, yaom.com, yahool.com usw. bis xcom.com usw.)
Wenn der Angriff läuft, kommt er immer von einer "festen" IP.
Weder der TMG noch der EX2007 Edgeteil fängt diese NDR Mails weg.
Das Eintragen der Sender IP in dei Edge Sperrliste bringt gar nichts. Wir sperren die Sender IP direkt in der Firewall. Da die Sender IP sich nur aller 2-3 Tage ändert kommen wir der Sperrung zwar hinterher eine Lösung ist das aber nicht. Sollte die Attacke auf DDoS umgestellt werden, ist mit Hand sicherlich Schluss.
Wie kriegen wir dies zuverlässig in Griff?
Hier mal ein paar Bilder von den Vorgängen.
Wer kann hier helfen? Was machen wir in so einem Fall? Warum fällt der Exchange auf diese Sache überhaupt rein, obwohl er ja kein SMTP Relay (OK es ist ja ein NDR - aber trotzdem) ist?
Vielen Dank.
Danke und liebe Grüße Oliver Richter
- Bearbeitet Oliver Richter Freitag, 17. August 2012 06:00
- Typ geändert Alex Pitulice Freitag, 24. August 2012 20:03 Warten auf Updates
Alle Antworten
-
Hi Christian,
hier mal die Bilder größer: http://sdrv.ms/S0Yk5f
Den Grund und die Art und Weise, wie die NDRs generiert werden kenne ich nicht. Ich werde hieraus nicht recht schlau.
Als Empfänger ist z.B. ein john@reje.net angegeben. Weder diese Domäne noch diesen Empfänger gibt es im betreffenden Exchange. Als Absender fungiert z.B. nadine.nadine.com. Da der Empfänger nicht existiert, geht an den Absender der NDR zurück. Warum der Exchange aber die Mail für den john@reje.net annimmt bliebt mir ein Rätsel.
Wo kann ich nach der Ursache suchen?
Danke und liebe Grüße Oliver Richter
- Bearbeitet Oliver Richter Freitag, 17. August 2012 12:40
-
Hi Oliver Richter,
Hi Christian,
hier mal die Bilder größer: http://sdrv.ms/S0Yk5f
Den <http://sdrv.ms/S0Yk5f> Grund und die Art und Weise, wie die NDRs generiert werden kenne ich nicht. Ich werde hieraus nicht recht schlau.
Als Empfänger ist z.B. ein john@reje.net <mailto:john@reje.net> angegeben. Weder diese Domäne noch diesen Empfänger gibt es im betreffenden Exchange. Als Absender fungiert z.B. nadine.nadine.com. Da der Empfänger nicht existiert, geht an den Absender der NDR zurück. Warum der Exchange aber die Mail für den john@reje.net <mailto:john@reje.net> annimmt bliebt mit ein Rätsel.
Wo kann ich nach der Ursache suchen?Schau dir mal den SMTP-Dialog zu der Nachricht an und kannst du diesen Posten. Da solltest du sehen, an wen die Nachricht eigentlich gehen sollte.
Viele Grüße
Christian -
-
OK, gefunden. In der Nachrichtenverfolgung mal nur nach Zeit gesucht und dann gefunden.
Alle Mails gehen an den postmaster@ (in der Exchange Domäne). Diesen gibt es aber nicht.
Der Postmaster tritt hier aber als "Sender" auf. Evtl. ein Konfigfehler - wenn ja, wer könnten diesen NDR als Postmaster auslösen?
Bild hier: http://sdrv.ms/Q7ttPZ
Danke und liebe Grüße Oliver Richter
-
Hier erst mal der get-receiceconnector
AuthMechanism : Tls, Integrated, BasicAuth, ExchangeS
erver
Banner :
BinaryMimeEnabled : True
Bindings : {0.0.0.0:25}
ChunkingEnabled : True
DefaultDomain :
DeliveryStatusNotificationEnabled : True
EightBitMimeEnabled : True
DomainSecureEnabled : True
EnhancedStatusCodesEnabled : True
LongAddressesEnabled : False
OrarEnabled : False
Fqdn : remote.arendt-spedition.de
Comment :
Enabled : True
ConnectionTimeout : 00:05:00
ConnectionInactivityTimeout : 00:01:00
MessageRateLimit : 600
MaxInboundConnection : 5000
MaxInboundConnectionPerSource : 20
MaxInboundConnectionPercentagePerSource : 2
MaxHeaderSize : 64KB
MaxHopCount : 30
MaxLocalHopCount : 8
MaxLogonFailures : 3
MaxMessageSize : 30MB
MaxProtocolErrors : 5
MaxRecipientsPerMessage : 200
PermissionGroups : AnonymousUsers, ExchangeServers, Part
ners
PipeliningEnabled : True
ProtocolLoggingLevel : None
RemoteIPRanges : {0.0.0.0-255.255.255.255}
RequireEHLODomain : False
RequireTLS : False
EnableAuthGSSAPI : False
ExtendedProtectionPolicy : None
ExtendedProtectionTlsTerminatedAtProxy : False
Server : FIRE01-SRV
SizeEnabled : Enabled
TarpitInterval : 00:00:05
AdminDisplayName :
ExchangeVersion : 0.1 (8.0.535.0)
Name : Default internal receive connector FI
RE01-SRV
DistinguishedName : CN=Default internal receive connector
FIRE01-SRV,CN=SMTP Receive Connector
s,CN=Protocols,CN=FIRE01-SRV,CN=Serve
rs,CN=Exchange Administrative Group (
FYDIBOHF23SPDLT),CN=Administrative Gr
oups,CN=First Organization,CN=Microso
ft Exchange,CN=Services,CN=Configurat
ion,CN={7A5BBB10-A67A-472E-8602-2650E
11E13B6}
Identity : FIRE01-SRV\Default internal receive c
onnector FIRE01-SRV
Guid : 44640f74-addb-4799-a18f-303c7be491d3
ObjectCategory : CN=ms-Exch-Smtp-Receive-Connector,CN=
Schema,CN=Configuration,CN={7A5BBB10-
A67A-472E-8602-2650E11E13B6}
ObjectClass : {top, msExchSmtpReceiveConnector}
WhenChanged : 01.08.2012 10:34:06
WhenCreated : 04.09.2011 16:36:48
OriginatingServer : localhost
IsValid : TrueObwohl heute schon gut 20.000 NDRs in der Warteschlange standen, ist derzeit mal wieder Ruhe.
Wäre dies richtige SMTP Log:
c:\program files\microsoft\exchange server\transportroles\logs\protocollog\smtpreceive
Danke und liebe Grüße Oliver Richter
-
Hi Oliver,
Relaytest sieht gut aus.
Das Logging sollte aktiv sein, dann findest du auch etwas in dem Verzeichnis:
ProtocolLoggingLevel : None
Identity : FIRE01-SRV\Default internalHabe ich jetzt etwas übersehen oder gibt es keinen externen Connector?
Wäre dies richtige SMTP Log:
c:\program files\microsoft\exchange server\transportroles\logs\protocollog\smtpreceiveGenau...
Wichtig wäre ersteinmal zu sehen, wie die Emails ins System kommen. Im NachrichtenLog sehe ich nicht genug.
Viele Grüße
Christian -
Hi Christian,
das Loggin läuft. Mails kommen auch rein, aber wenn man schon mal einen fangen will ist gerade mal Ruhe (als hätte man es gemerkt).
Die Konstellation ist hier der klassische EBS 2007
Die SMTP Receives laufen daher am EdgeTransport Server ein. Auf dem Edge laufen auch die BLP (spamhaus zen, spamcop usw.). Diese haben aber für diesen Angriff keine Wirkung (bei allen anderen schon)
Danke und liebe Grüße Oliver Richter
-
-
Hallo Oliver,
ist das Problem eigentlich gelöst ? Funktioniert alles OK?
Viele Grüße,
AlexAlex Pitulice, MICROSOFT
Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip „IT-Pros helfen IT-Pros“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können. -
Hallo Alex,
tja das Problem wurde eigentlich nicht gelöst. Es tritt nur nicht mehr auf. Keine Ahnung warum.
Ich vermute, irgendjemand hat von extern Massenmails an eine (oder mehrere) intern unbekannte E-Mail Adressen gesendet um Massen-NDRs zu generieren um damit das System lahm zu legen. Wieso der Exchange auf diesen Angriff rein fällt weiß ich nicht. Es war ja immer ein und die gleiche Mail (zumindest vom Header her) von ein und der selben IP Adresse versandt (wobei die Sender IP sich nach Sperrung innerhalb weniger Stunden änderte). OK, der Absender war immer ein anderer, vermutlich hat deswegen der Exchange massiv neue NDRs generiert.
Sehr eigentümlich ist für mich der Fakt, dass quasi nach Veröffentlichung in diesem Forum der Angriff aufhörte.
Sobald wieder Aktivitäten auftreten würde ich mich melden.
Danke und liebe Grüße Oliver Richter
-
Hallo Oliver,
danke für die Rückmeldung. Dann warten wir auf die Updates.
Gruss,
Alex
Alex Pitulice, MICROSOFT
Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip „IT-Pros helfen IT-Pros“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können.