☰

Identifizieren und Blockieren von Datenverkehr von Amazon AWS-Servern

tag-icon • tag-icon windows amazon-ec2 amazon-web-services exchange-2013
Identifizieren und Blockieren von Datenverkehr von Amazon AWS-Servern

Wir betreiben einen internen Exchange-Server und haben in letzter Zeit viel Datenverkehr von Amazon-IPs bemerkt. Das Seltsame ist, dass der Datenverkehr nicht SMTP ist; er scheint vielmehr Port 443 zu erreichen (das ist die OWA-/ECP-Website des Client Access Servers).

Wir sind uns über den Zweck dieses Datenverkehrs nicht im Klaren. Uns kam der Gedanke, dass sich vielleicht einer der Benutzer für einen Drittanbieterdienst angemeldet hat, der auf einer AWS-Infrastruktur ausgeführt wird und sich regelmäßig (übermäßig) bei OWA anmeldet, um eine Synchronisierung durchzuführen. Uns ist jedoch nicht klar, ob sich die Sitzungen überhaupt als Benutzer anmelden oder nur die Anmelde-Zielseite durchsuchen.

Wir haben versucht, die beobachteten Adressen zu blockieren, um zu sehen, ob etwas „kaputt geht“, aber der Datenverkehr kommt kurze Zeit später von einem anderen Satz Amazon-IPs wieder zurück.

Ich habe ein freundliches Ticket eröffnet mit[email geschützt]Aber bisher haben sie nichts Nützliches herausgefunden.

  1. Wie kann ich feststellen, was dieser Datenverkehr bewirken soll?

  2. Wie kann ich den gesamten Datenverkehr zu meinem Server blockieren, der von IPs stammt, die zu Amazon AWS gehören?

Antwort1

Blockierung des Verkehrs

Ich habe eine temporäreVorschlaghammerum mich um Nr. 2 zu kümmern.

Die maßgebliche Liste aller AWS IP-Bereiche wird von Amazon veröffentlicht unter https://ip-ranges.amazonaws.com/ip-ranges.json. Die Liste kann mehrmals wöchentlich aktualisiert werden und wird ausführlicher beschrieben indieser Blog-Beitrag.

Das Programm lädt die Liste herunter, analysiert sie und erstellt (oder aktualisiert) eine Blockierungsregel in der Windows-Firewall.

Angesichts der zunehmenden Anzahl von Diensten, deren Identität teilweise verschleiert ist und die auf der AWS-Infrastruktur laufen, hilft dies vielleicht anderen, die auf ähnliche Probleme stoßen.

Untersuchung des Verkehrs

Für #1, diese LogParserEidechseFragen waren hilfreich:

SELECT * FROM #IISW3C#
WHERE c-ip in ('35.153.205.73'; '52.45.133.113'; /* additional IP's here */)

Gruppieren nach Monat, URL und Benutzer:

SELECT TO_STRING(date, 'yyyy-MMM') AS Month, cs-uri-stem, cs-username, COUNT(*) AS Hits
FROM #IISW3C#
WHERE c-ip in ('35.153.205.73'; '52.45.133.113'; /* additional IP's here */)
GROUP BY Month, cs-uri-stem, cs-username
ORDER BY Month, cs-uri-stem, cs-username

Ergebnisse

Bildbeschreibung hier eingeben

Kein Wunder, es waren Treffer für /EWS/Exchange.asmxund /EWS/Services.wsdl. Der Benutzeragent war im Allgemeinen entweder leer, Python-urllib/2.7oder python-requests/2.8.1. python-requests/2.9.0Die Antwortcodes waren 401.0(nicht autorisiert), 401.1(ungültige Anmeldeinformationen) und 200.0(ok). Von beiden gab es jede Menge.

Alle 200verwendeten die Anmeldeinformationen eines einzelnen Benutzers in unserer Domäne. Ich vermute, sie haben sich für einen Dienst wie Amazon WorkMail API (Push-Benachrichtigungen für E-Mail-Zustellung / Kalenderaktualisierungen), Amazon Comprehend (Stimmungsanalyse eingehender E-Mails), Alexa for Business (Alexa nach geplanten Ereignissen fragen, neue per Sprache hinzufügen) oder einen Drittanbieter angemeldet, der überhaupt nichts mit der Marke Amazon zu tun hat und zufällig einen EWS-Client aus der Amazon-Infrastruktur betreibt.

Wir bleiben mit dem Benutzer in Kontakt. Wenn jemand eine genauere Vermutung hat, um welches Produkt es sich handeln könnte, würde ich mich freuen, davon zu hören. Dieses Ding hat in den ersten 10 Tagen im März etwa 25.000 Zugriffe generiert und einige davon haben lange gedauert (wahrscheinlich wurden viele Daten zurückgegeben). Ich weiß, das ist für Amazon-Verhältnisse nicht viel, aber es hat uns gereicht, um darauf aufmerksam zu werden.

verwandte Informationen