Angreifer outet sich als Localhost
Mit tShark, von Wireshark, analysiere ich mittels PHP in Echtzeit den Datenstrom auf meinem Server. Mein Ziel ist es, Angreifer früh zu erkennen und über die integrierte Windows Firewall auszusperren. Das funktioniert so weit ganz gut. Angreifer, die für ihren Verbindungsaufbau einen Hostnamen verwenden, lasse ich in deren IPs auslösen, um sie auszusperren. Nun ist es leider so, dass manche dieser Hostnamen ihre tatsächliche IP verschleiern. Nslookup liefert bei einem Angreifer sogar 127.0.0.1, womit ich ihn leider nicht aussperren kann. Die Windows-Firewall erlaubt lediglich die Sperre in Form der IP. Und die Hostsdatei ist keine Lösung für den Input. Hat jemand eine Idee, wie man den Verkehr bzw. wie man Hostnamen anderweitig blockiert bekommt? Und das am besten mittels Command Line damit ich die Sperre automatisch setzen und entfernen kann. Per DNS scheint es auch nicht zu gehen. Na ja, freue mich auf ein konstruktives Gespräch mit euch.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 6126476607
Url: https://administrator.de/forum/angreifer-outet-sich-als-localhost-6126476607.html
Ausgedruckt am: 06.02.2025 um 02:02 Uhr
25 Kommentare
Neuester Kommentar
Das ganze Konstrukt klingt merkwürdig — aber Tshark zeichnet die IP auf, da muss man nichts übersetzen. Nur vielleicht mal konfigurieren, dass man keine IP-Adressen in Hostnames aufgelöst haben will, was eigentlich sowieso fast immer Murks ist. Lass dir von TShark die unübersetzte IP ausgeben, Problem gelöst.
moin...
und du schaust dir das 24/7 an....
Frank
Zitat von @thor68:
Mhm, die übersetzte IP ist 127.0.0.1. was ist daran gelöst? Die Strategie dahinter ist, Angreifer früh zu erkennen, um sie im Ansatz zu blockieren.
Mhm, die übersetzte IP ist 127.0.0.1. was ist daran gelöst? Die Strategie dahinter ist, Angreifer früh zu erkennen, um sie im Ansatz zu blockieren.
und du schaust dir das 24/7 an....
Frank
Moin,
Falsch! Du interpretierst die Daten, die u mit tsharkl/wireshark sammelst verkehrt. Du darfst nicht die per reverse-DNS aufgelösten Namen verwenden, um daraus eine IP-Adresse abzuleiten, sondern mußt direkt die mitgeschnittenen IP-Adressen nehmen. Als Angreifer hat man normalerweise imme rdie Möglichkeit, per reverse-DNS belibige Namen zu IP-Adressen anzugeben u.a. auch "localhost" oder auch per DNS zu jedem Namen aus seiner eigenen Domain jede belibeige IP-Adresse auszuliefern, u.a. auch 127.0.0.1
Also:
Wenn Du das vernünftig umsetzen willst, nimm direkt die IP-Adressen aus dem Mitschnitt und nicht irgendwelche IP-Adresse die nach zweimaligem durchnudeln durch das DNS rausfallen.
lks
Angreifer outet sich als Localhost
Falsch! Du interpretierst die Daten, die u mit tsharkl/wireshark sammelst verkehrt. Du darfst nicht die per reverse-DNS aufgelösten Namen verwenden, um daraus eine IP-Adresse abzuleiten, sondern mußt direkt die mitgeschnittenen IP-Adressen nehmen. Als Angreifer hat man normalerweise imme rdie Möglichkeit, per reverse-DNS belibige Namen zu IP-Adressen anzugeben u.a. auch "localhost" oder auch per DNS zu jedem Namen aus seiner eigenen Domain jede belibeige IP-Adresse auszuliefern, u.a. auch 127.0.0.1
Also:
Wenn Du das vernünftig umsetzen willst, nimm direkt die IP-Adressen aus dem Mitschnitt und nicht irgendwelche IP-Adresse die nach zweimaligem durchnudeln durch das DNS rausfallen.
lks
Zitat von @thor68:
Es gibt eine Art konformen Verkehr und einen, wobei Angreifer versuchen, das System zu kompromittieren. Mit einem Portscan beginnt zumeist der Angriff. Wenn jemand einen Port abfragt, der nicht zur Verfügung steht, ist das bereits ein erstes Zeichen für einen nicht konformen Betrieb. Das erkennt mein Skript und sperrt den Angreifer über die Firewall aus. Wenn er mehrere IPs besitzt, blockiere ich die ebenfalls. Ich versuche verschiedene Strategien. Zum Beispiel werte ich das Windows- Ereignisprotokoll aus und sperre Loginversuche auf die Datenbank.
Es gibt eine Art konformen Verkehr und einen, wobei Angreifer versuchen, das System zu kompromittieren. Mit einem Portscan beginnt zumeist der Angriff. Wenn jemand einen Port abfragt, der nicht zur Verfügung steht, ist das bereits ein erstes Zeichen für einen nicht konformen Betrieb. Das erkennt mein Skript und sperrt den Angreifer über die Firewall aus. Wenn er mehrere IPs besitzt, blockiere ich die ebenfalls. Ich versuche verschiedene Strategien. Zum Beispiel werte ich das Windows- Ereignisprotokoll aus und sperre Loginversuche auf die Datenbank.
Ein Portscan sollte gar nicht erst auf deinem Zielserver ankommen. NG-Firewalls haben fast durch die Bank weg entsprechende Pattern, die Portscans automatisch erkennen und blockieren.
Die Windows-Firewall sollte ausschließlich genutzt werden, um die Kommunikation im selben Subnetz zwischen zwei Servern weiter zu steuern / limitieren.
Als Edge-Firewall reicht diese, sowie alle anderen Software-Firewalls nicht aus.
Was ist denn überhaupt dein use-case?
Hallo,
Du hast es ja schon gelöst, aber die Reihenfolge ist ja eher
- IP des Zugriffes
- Hostname zu IP ermitteln mit kurzem Timeout (um die Verbindung nicht zu verzögern)
- Land und ggf. Reputation mittels IP-DB ermitteln (offline oder online)
- Dann IP-Reputation und Geo-Block prüfen und ggf. gleich blocken
- Rate-Limiter in abhängigkeit der IP-DB
Auch kannst Du prüfen ob Du von einem Blacklist- zu einem Whitelist-Modus wechseln.
Z.B. lässt Du nur IP-Adressen zu die vorher eine "versteckte" URL geöffnet haben (Trigger)
Kommt halt darauf an ob es ein offenes System (Web-Seite oder -Shop) ist oder ein geschlossenes für einen geschlossenen Benutzerkreis.
Portscans auszuwerten ist meist vergebene Zeit. Die kommen zu 99% über gehackte Proxy-Server.
Stefan
Du hast es ja schon gelöst, aber die Reihenfolge ist ja eher
- IP des Zugriffes
- Hostname zu IP ermitteln mit kurzem Timeout (um die Verbindung nicht zu verzögern)
- Land und ggf. Reputation mittels IP-DB ermitteln (offline oder online)
- Dann IP-Reputation und Geo-Block prüfen und ggf. gleich blocken
- Rate-Limiter in abhängigkeit der IP-DB
Auch kannst Du prüfen ob Du von einem Blacklist- zu einem Whitelist-Modus wechseln.
Z.B. lässt Du nur IP-Adressen zu die vorher eine "versteckte" URL geöffnet haben (Trigger)
Kommt halt darauf an ob es ein offenes System (Web-Seite oder -Shop) ist oder ein geschlossenes für einen geschlossenen Benutzerkreis.
Portscans auszuwerten ist meist vergebene Zeit. Die kommen zu 99% über gehackte Proxy-Server.
Stefan
Zitat von @thor68:
Kann ich dazu nähere Informationen bekommen?
"Auch kannst Du prüfen ob Du von einem Blacklist- zu einem Whitelist-Modus wechseln.
Z.B. lässt Du nur IP-Adressen zu die vorher eine "versteckte" URL geöffnet haben (Trigger)"
Kann ich dazu nähere Informationen bekommen?
"Auch kannst Du prüfen ob Du von einem Blacklist- zu einem Whitelist-Modus wechseln.
Z.B. lässt Du nur IP-Adressen zu die vorher eine "versteckte" URL geöffnet haben (Trigger)"
Ja, wobei das ein sehr weites Feld ist.
Ich habe eine Web-Application-Firewall programmiert welche wir kommerziell anbieten.
Sowohl im Proxy- als auch API-Modus.
D.h. jeder Zugriff, auch schon der 1. läuft durch unser System bevor an das Zielsystem weitergegeben wird.
Wenn es ein geschlossenens System ist, z.B. Intranet, werden alle Zugriff mit einem 403 geblockt.
Ein ganz einfaches System ist z.B. wenn man z.B. die URL https://login.firma.de/connect öffnet, kommte die IP auf eine temporäre Liste und wird für 8 Stunden erlaubt. Dazu optional Geo-Block, Login, 2FA, Client-Zertifikate. Kommt sehr auf den Kunden und das System an. Meist als Art Pre-Login für einfache Websysteme wie CMS oder Shops. Deutlich günstiger als richtige WAFs.
Hier https://secureaccess.pro/ z.B. in Verbindung mit einem Login-Webinterface und RDP ohne VPN.
Stefan
Moin
Was machst du wenn der Angreifer die Domain wechselt? Was machst du, wenn die Angriffe plötzlich von er anderen IP-Adresse kommen, zum Beispiel 107.170.238.15. Richtig. Da fängst du einfach wieder von Vorne an. Richtiger Ansatz ist meiner Meinung nach: stell die Firewall auf Deny all um und erstelle Ausnahmen.
Gruß
Doskias
Zitat von @StefanKittel:
Auch kannst Du prüfen ob Du von einem Blacklist- zu einem Whitelist-Modus wechseln.
Das ist meine Meinung der einzige vernünftige Weg. Du hast jetzt eine IP. Nämlich, wie du selbst schreibst:Auch kannst Du prüfen ob Du von einem Blacklist- zu einem Whitelist-Modus wechseln.
Der Angreifer ist: zg-1220b-158.stretchoid.com
Die originale IP ist 107.170.238.14
Die originale IP ist 107.170.238.14
Was machst du wenn der Angreifer die Domain wechselt? Was machst du, wenn die Angriffe plötzlich von er anderen IP-Adresse kommen, zum Beispiel 107.170.238.15. Richtig. Da fängst du einfach wieder von Vorne an. Richtiger Ansatz ist meiner Meinung nach: stell die Firewall auf Deny all um und erstelle Ausnahmen.
Z.B. lässt Du nur IP-Adressen zu die vorher eine "versteckte" URL geöffnet haben (Trigger)
Klappt bis die URL mit dem Trigger bekannt ist. Aber wieso das ganze? Entweder ich will den Zugriff erlauben oder nicht. Ich bin doch Admin meiner Umgebung und ich pflege die Ausnahmeliste, die steuert was zugelassen wird. Wieso sollte ich das einer externen Person überlassen? Wenn ich einer externen Person erlaube, sich (auch wenn es nur temporär ist) auf die Ausnahmeliste zu setzen, dann kann er mir in dieser temporären Zeit auch schon schaden.Gruß
Doskias
Kommt ja darauf an was das für ein System ist. Das hat er leider noch nicht gesagt.
z.B. ein Exchange mit OWA/ECP ohne VPN oder ein Wordpress-CMS wo ich nur den Admin-Bereich versteken möchte.
Es kommt wie immer auf viele Faktoren an.
Hallo Stefan,
da sind wir wieder bei dem Punkt des Netzwerkdesigns. Wenn ich es mir schon leiste einen eigenen Exchange-Server on premise zu betreiben, was ja auch einiges an Hardware, Lizenzen und Aufwand kostet, dann sollte man das auch bis zum Ende durchdenken. Zugriff auf den Exchange via OWA von außen ist ja noch nachvollziehbar. Aber wieso sollte die ECP ohne VPN von außen erreichbar sein. Wenn ich so ein Konstrukt habe, dann hat der Admin auch eine VPN-Verbindung wenn er von außerhalb arbeiten soll. Und wenn nicht, dann muss er von außerhalb auch nicht auf die ECP. Oder habe ich dich falsch verstanden?
Gruß
Doskias
da sind wir wieder bei dem Punkt des Netzwerkdesigns. Wenn ich es mir schon leiste einen eigenen Exchange-Server on premise zu betreiben, was ja auch einiges an Hardware, Lizenzen und Aufwand kostet, dann sollte man das auch bis zum Ende durchdenken. Zugriff auf den Exchange via OWA von außen ist ja noch nachvollziehbar. Aber wieso sollte die ECP ohne VPN von außen erreichbar sein. Wenn ich so ein Konstrukt habe, dann hat der Admin auch eine VPN-Verbindung wenn er von außerhalb arbeiten soll. Und wenn nicht, dann muss er von außerhalb auch nicht auf die ECP. Oder habe ich dich falsch verstanden?
Gruß
Doskias
Zitat von @Doskias:
Hallo Stefan,
da sind wir wieder bei dem Punkt des Netzwerkdesigns. Wenn ich es mir schon leiste einen eigenen Exchange-Server on premise zu betreiben, was ja auch einiges an Hardware, Lizenzen und Aufwand kostet, dann sollte man das auch bis zum Ende durchdenken.
Du glaubst gar nicht wieviele KMUs es da draußen mit Exchange gibt ohne eigenes IT-Personal und mit zu geringem IT-Budget. Die SBS2011 mal gar nicht mitgerechnet.Hallo Stefan,
da sind wir wieder bei dem Punkt des Netzwerkdesigns. Wenn ich es mir schon leiste einen eigenen Exchange-Server on premise zu betreiben, was ja auch einiges an Hardware, Lizenzen und Aufwand kostet, dann sollte man das auch bis zum Ende durchdenken.
Aber wieso sollte die ECP ohne VPN von außen erreichbar sein.
Weil man ohne ECP in Outlook keine Abwesenheitskonfiguration vornehmen kann.Dazu der Unwille der Mitarbeiter sich auf ihren Privathandys für die Firmenemails mit VPN befassen zu wollen.
Nein, ich finde das auch nicht gut und will es nicht schönreden. Aber häufig ist es halt so.
Inzwischen betreue ich keine IT-Mehr vollzeit, sondern Web-Kunden. Da wird aber um so mehr von Kundenseitig konstruiert
Zitat von @StefanKittel:
Oh doch das glaube ich. Das weiß ich. Ich glaube nach 18 Jahren Systemhaus kann ich mir das gaaanz gut vorstellen. Jetzt interne IT, aus gutem Grund . Und ich weiß auch, dass grade dort die Firewall oft nur blockt was gesperrt wird. Und genau da liegt ja das Problem, grade bei KMUs. Und es muss kein eigenes IT-Personal sein. Ich war teilweise 1 x die Woche bei einem Kunden, Rest hat das Office übernommen, wenn es nicht warten konnte.Zitat von @Doskias:
Hallo Stefan,
da sind wir wieder bei dem Punkt des Netzwerkdesigns. Wenn ich es mir schon leiste einen eigenen Exchange-Server on premise zu betreiben, was ja auch einiges an Hardware, Lizenzen und Aufwand kostet, dann sollte man das auch bis zum Ende durchdenken.
Du glaubst gar nicht wieviele KMUs es da draußen mit Exchange gibt ohne eigenes IT-Personal und mit zu geringem IT-Budget. Die SBS2011 mal gar nicht mitgerechnet.Hallo Stefan,
da sind wir wieder bei dem Punkt des Netzwerkdesigns. Wenn ich es mir schon leiste einen eigenen Exchange-Server on premise zu betreiben, was ja auch einiges an Hardware, Lizenzen und Aufwand kostet, dann sollte man das auch bis zum Ende durchdenken.
Aber wieso sollte die ECP ohne VPN von außen erreichbar sein.
Weil man ohne ECP in Outlook keine Abwesenheitskonfiguration vornehmen kann.Die ECP hat bislang noch keiner meiner User gebraucht. Nicht in den letzten 9 Jahren. Das was man von unterwegs mal schnell machen muss, geht alles über OWA. Mit der ECP kann man zu viel Unsinn anstellen, grade wenn das Adminkennwort nicht gut gewählt ist. Und das, das kann ich dir nach 18 Jahren sagen, ist bei KMUs leider auch häufig der Fall.
Dazu der Unwille der Mitarbeiter sich auf ihren Privathandys für die Firmenemails mit VPN befassen zu wollen.
Das hat ja nichts mit Unwille zu tun. Ich persönlich bin ein Fan von strikter Trennung zwischen dienstlichen und Privatem Handy. Wenn der AG will, dass der AN seine Mails abruft, dann muss er dafür auch das Equipment zur Verfügung stellen. Wenn ich es auf meinem Privathandy zusätzlich einrichte, dann besteht immer die Gefahr, dass Firmendaten abwandern. Das einzige, was ich auf meinem privaten Handy habe, sind die Tokens für die MFAs. Aber auch eher als Backuplösung und datenschutztechnisch unkritisch.Nein, ich finde das auch nicht gut und will es nicht schönreden. Aber häufig ist es halt so.
Ja, aber wir müssen ja immer darauf hinweisen, damit es anders wird. Grade und vor allem in KMUs Und da schließt sich der Kreis zum Ursprungsthema auch schon wieder, bevor wir zu weit abschweifen:
Kommt ja darauf an was das für ein System ist. Das hat er leider noch nicht gesagt.
@ Thor68: Magst du uns noch ein Paar Infos zu dem System und Netzwerkaufbau geben?Gruß
Doskias
Serie: Angreifer outet sich als Localhost
Angreifer outet sich als Localhost25