10
Ping oder nicht Ping?
Immer wieder erzählt mir jemand, dass man eine Firewall so konfigurieren soll, dass sie nicht auf ICMP-Echo-Requests ("Ping") antworten soll - das würde Bots fernhalten.
Und dann erzählt mir ein paar Minuten später jemand, dass das totaler Schwachsinn wäre und man exakt gleich viel Bot-Anfragen abbekommt.
Dann gibt es noch die Strategen, die pauschal alles an ICMP verwerfen, aber das ist ein anderes Thema.
Jetzt wollte ich es wissen und habe ein relativ einfaches Experiment gestartet:
Zutaten:
Zwei IP-Adressen aus dem selben /24-Netz, beide werden auf die selbe Maschine geroutet.
Per Firewall wird festgelegt, dass auf einer IP-Adresse ausschließlich auf ICMP-Echo-Requests reagiert werden soll, die andere soll selbst das nicht tun.
Wir haben also ein und die selbe Maschine, die keinen ausgehenden Traffic erzeugt und - wenn überhaupt - nur auf Ping-Anfragen reagiert.
Alles was auf der Netzwerkkarte dann an Traffic anfällt, ist demzufolge Traffic von Bots.
Das Experiment lief über 48 Stunden mit IP-Adressen, die zuvor noch nie in Verwendung waren.
Die Ergebnisse:
Details
Fazit
Reagiert der Server nicht auf Ping-Requests, bekommt er nicht wirklich weniger Anfragen aus Botnetzen - aber die IP-Adresse scheint ein wenig häufiger im Zusammenhang mit IP-Spoofing genutzt zu werden, um den verursachten Antwort-Traffic auf ein "schwarzes Loch" zu leiten, wo es mutmaßlich niemanden stört.
Aber im großen und ganzen behaupte ich, dass es absolut keinen Unterschied mehr macht ob ein Client auf Ping reagiert und man sich durch das filtern/abschalten dieser Funktion nur unnötig das Debugging bei Verbindungsproblemen erschwert.
Auch schon alleine deshalb, weil innerhalb von 48 Stunden höchstens 13 Mal gepingt wurde. In Relation zu den Gesamtpaketzahlen ist das praktisch nicht passiert!
: Anm. 2 : Das sind Versuche, authoritative DNS-Server einer Domain mit einer Flut von Anfragen auszulasten - und um den Antwort-Traffic zu verteilen werden einfach sämtliche IP-Adressen aus dem Internet gespoofed.
Und dann erzählt mir ein paar Minuten später jemand, dass das totaler Schwachsinn wäre und man exakt gleich viel Bot-Anfragen abbekommt.
Dann gibt es noch die Strategen, die pauschal alles an ICMP verwerfen, aber das ist ein anderes Thema.
Jetzt wollte ich es wissen und habe ein relativ einfaches Experiment gestartet:
Zutaten:
Zwei IP-Adressen aus dem selben /24-Netz, beide werden auf die selbe Maschine geroutet.
Per Firewall wird festgelegt, dass auf einer IP-Adresse ausschließlich auf ICMP-Echo-Requests reagiert werden soll, die andere soll selbst das nicht tun.
Wir haben also ein und die selbe Maschine, die keinen ausgehenden Traffic erzeugt und - wenn überhaupt - nur auf Ping-Anfragen reagiert.
Alles was auf der Netzwerkkarte dann an Traffic anfällt, ist demzufolge Traffic von Bots.
Das Experiment lief über 48 Stunden mit IP-Adressen, die zuvor noch nie in Verwendung waren.
Die Ergebnisse:
| Reagiert auf Ping | Reagiert NICHT auf Ping | |
|---|---|---|
| Gesamtzahl Pakete | 4.785 | 5.016 |
| Empfangener Traffic | 501.369 Bytes | 516.788 Bytes |
| TCP-Pakete | 754 | 846 |
| ...davon mit RST-Flag, siehe Anm. 1 | 10 | 8 |
| ...davon mit ACK-Flag, siehe Anm. 1 | 60 | 90 |
| UDP-Pakete | 3.445 | 3.485 |
| ...davon mit SRC-Port 53, siehe Anm. 2 | 1.333 | 1.361 |
| ICMP-Pakete | 1.791 | 1.864 |
| ...davon Typ 8 (Echo-Request) | 8 | 13 |
Details
- Die ICMP-Pakete waren zu weit über 95% Meldungen "Network unreachable", "Port unreachable", "Destination out of order" und "TTL Exceeded". Das dürfte mit dem in Anmerkung 1 und 2 beschriebenem IP-Spoofing zum Zwecke von DDoS-Attacken zusammenhängen.
- Die TCP-Pakete waren zu mehr als die Hälfte SYN-Pakete, gerichtet an die Ports (in Reihenfolge der Häufigkeit) 23, 21, 22, 80, 443, 3389, 3306. Der Rest hat sich auf viele andere Ports verteilt.
- Die UDP-Pakete mit Source-Port 53 waren DNS-Antworten von irgendwelchen Nameservern oder DNS-Resolvern, die für immer wieder die selben Hostnamen mit SERVFAIL oder "No such name" geantwortet haben. Siehe dazu auch Anmerkung 2.
- Die restlichen UDP-Pakete waren in der Regel DNS-Query-Requests, SIP-INVITES, SNMP-Abfragen, NTP-Anfragen und Anfragen gegen Port 19/UDP (CHARGEN), was sich gut für DDoS-Attacken ausnutzen lässt.
Fazit
Reagiert der Server nicht auf Ping-Requests, bekommt er nicht wirklich weniger Anfragen aus Botnetzen - aber die IP-Adresse scheint ein wenig häufiger im Zusammenhang mit IP-Spoofing genutzt zu werden, um den verursachten Antwort-Traffic auf ein "schwarzes Loch" zu leiten, wo es mutmaßlich niemanden stört.
Aber im großen und ganzen behaupte ich, dass es absolut keinen Unterschied mehr macht ob ein Client auf Ping reagiert und man sich durch das filtern/abschalten dieser Funktion nur unnötig das Debugging bei Verbindungsproblemen erschwert.
Auch schon alleine deshalb, weil innerhalb von 48 Stunden höchstens 13 Mal gepingt wurde. In Relation zu den Gesamtpaketzahlen ist das praktisch nicht passiert!
- Anm. 1
- Das könnten SYN-Floods mit gespoofeten IP-Adressen auf Webserver sein, die damit ausgelastet werden sollen. Um mit möglichst wenig Ressourcen viele Verbindungen zu simulieren werden dafür gerne zufällig IP-Adressen aus dem Internet gespoofed.
: Anm. 2 : Das sind Versuche, authoritative DNS-Server einer Domain mit einer Flut von Anfragen auszulasten - und um den Antwort-Traffic zu verteilen werden einfach sämtliche IP-Adressen aus dem Internet gespoofed.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 305143
Url: https://administrator.de/knowledge/ping-oder-nicht-ping-305143.html
Ausgedruckt am: 22.12.2024 um 10:12 Uhr
10 Kommentare
Neuester Kommentar
Moin,
ICMP sollte wirklich NICHT abgeschaltet werden. Das Protokoll gibt es schließlich nicht ohne Grund.
Wer IPv6 ohne ICMP machen will, wird sicher Spaß haben, aber auch unter IPv4 ist der Nutzen dieses Protokolls nicht zu unterschätzen.
Mein persönliches Lieblingsthema hierzu: Path MTU Discovery oder in deutsch:
https://de.wikipedia.org/wiki/Path_MTU_Discovery
Aber ich renne (hoffentlich) offene Türen ein ;)
Gruß
Chris
ICMP sollte wirklich NICHT abgeschaltet werden. Das Protokoll gibt es schließlich nicht ohne Grund.
Wer IPv6 ohne ICMP machen will, wird sicher Spaß haben, aber auch unter IPv4 ist der Nutzen dieses Protokolls nicht zu unterschätzen.
Mein persönliches Lieblingsthema hierzu: Path MTU Discovery oder in deutsch:
https://de.wikipedia.org/wiki/Path_MTU_Discovery
Aber ich renne (hoffentlich) offene Türen ein ;)
Gruß
Chris
Moin,
ICMP generell auszuschalten war schon immer Mist, weil das oft zu Problemen geführt hat.
Aber auf einem WAN.interface sollte man ICMP filtern und ggf z.B. ICMP-Redirects reglementieren.
lks
ICMP generell auszuschalten war schon immer Mist, weil das oft zu Problemen geführt hat.
Aber auf einem WAN.interface sollte man ICMP filtern und ggf z.B. ICMP-Redirects reglementieren.
lks
Hallo,
einer Datenbank oder sogar mehreren Datenbanken.
- Bot 1 scannt die IPs und versendet Pings um zu schauen ob der Host oder die IP antwortet
und trägt das dann in eine Datenbank ein
- Bot 2 nimmt sich aufgrund des Ergebnisses dann die IP (Ranking) und scannt sie auf Schwachstellen ab
und trägt das auch wieder in die Datenbank ein und so weiter und so weiter und so weiter
Doch jedes OS hat eine spezifische Signatur, denn ein Unix System sendet zwar auch nur ein Ping zurück
wie ein MS Server OS oder gar eine Firewall, nur diese unterscheiden sich von einander so das man schon
anhand des Pings bzw. seiner Antwort "sehen" kann wer hat geantwortet und wie schnell hat er das getan.
So kann man dann bekannte Schwachstellen als nächstes abklappern mittels weiterer Bots noch mehr
erfahren bis man weiß an dem anderen Ende ist das OS XYZ und zwar in den und dem Zustand und
Patchlevel und dann kommt es eben auf das Ranking der IP, des Systems und der Schwachstelle an
bevor sich "jemand" aus Fleisch und Blut um diesen Eintrag kümmert.
Es ist zwar nur als Vorarbeit der einfachen "Scouts" (Bots) zu betrachten, aber dennoch oft genug der
erste Schritt um Server, Firewalls oder Router auszuspähen und/oder anzugreifen.
Ich würde es von daher lieber abgeschaltet lassen im WAN Bereich und im LAN ist das dann wieder eine
ganz andere Sache das macht jeder mit sich selber ab ob dort auch oder nicht.
Gruß
Dobby
Dann gibt es noch die Strategen, die pauschal alles an ICMP verwerfen, aber das ist ein anderes Thema.
Das sind nicht ein Bot sondern immer mehrere Bots die zusammen agieren und heute auch locker mittelseiner Datenbank oder sogar mehreren Datenbanken.
- Bot 1 scannt die IPs und versendet Pings um zu schauen ob der Host oder die IP antwortet
und trägt das dann in eine Datenbank ein
- Bot 2 nimmt sich aufgrund des Ergebnisses dann die IP (Ranking) und scannt sie auf Schwachstellen ab
und trägt das auch wieder in die Datenbank ein und so weiter und so weiter und so weiter
Doch jedes OS hat eine spezifische Signatur, denn ein Unix System sendet zwar auch nur ein Ping zurück
wie ein MS Server OS oder gar eine Firewall, nur diese unterscheiden sich von einander so das man schon
anhand des Pings bzw. seiner Antwort "sehen" kann wer hat geantwortet und wie schnell hat er das getan.
So kann man dann bekannte Schwachstellen als nächstes abklappern mittels weiterer Bots noch mehr
erfahren bis man weiß an dem anderen Ende ist das OS XYZ und zwar in den und dem Zustand und
Patchlevel und dann kommt es eben auf das Ranking der IP, des Systems und der Schwachstelle an
bevor sich "jemand" aus Fleisch und Blut um diesen Eintrag kümmert.
Es ist zwar nur als Vorarbeit der einfachen "Scouts" (Bots) zu betrachten, aber dennoch oft genug der
erste Schritt um Server, Firewalls oder Router auszuspähen und/oder anzugreifen.
Ich würde es von daher lieber abgeschaltet lassen im WAN Bereich und im LAN ist das dann wieder eine
ganz andere Sache das macht jeder mit sich selber ab ob dort auch oder nicht.
Gruß
Dobby
Das klingt aber sehr nach "Security by Obscurity"...
Mal ernsthaft: Ein Ping verrät weniger als ein einziger offener TCP- oder UDP-Port. Insbesondere wenn da SSL/TLS aktiviert ist, wird es recht einfach herauszufinden welches Betriebssystem und vor allem welcher Dienst in welcher Version läuft.
Manchmal reicht auch nur ein TCP-Paket wo man wie an einem Weihnachtsbaum alle Options-Bits leuchten lässt um zu sehen, wie das Ziel darauf reagiert. Und irgendeinen Standardport wirst du ja wohl offen haben.
Du siehst ja auch, dass unter den knapp 5.000 Paketen die in Form des Grundrauschens gegen diese IP geworfen wurden nur durchschnittlich 10 Pings dabei waren. Ich glaube aufgrund der Ergebnisse weiterhin nicht, dass es (heutzutage) einen realen Unterschied macht
Mal ernsthaft: Ein Ping verrät weniger als ein einziger offener TCP- oder UDP-Port. Insbesondere wenn da SSL/TLS aktiviert ist, wird es recht einfach herauszufinden welches Betriebssystem und vor allem welcher Dienst in welcher Version läuft.
Manchmal reicht auch nur ein TCP-Paket wo man wie an einem Weihnachtsbaum alle Options-Bits leuchten lässt um zu sehen, wie das Ziel darauf reagiert. Und irgendeinen Standardport wirst du ja wohl offen haben.
Du siehst ja auch, dass unter den knapp 5.000 Paketen die in Form des Grundrauschens gegen diese IP geworfen wurden nur durchschnittlich 10 Pings dabei waren. Ich glaube aufgrund der Ergebnisse weiterhin nicht, dass es (heutzutage) einen realen Unterschied macht
Zitat von @LordGurke:
Das klingt aber sehr nach "Security by Obscurity"...
...
Ich glaube aufgrund der Ergebnisse weiterhin nicht, dass es (heutzutage) einen realen Unterschied macht
Das klingt aber sehr nach "Security by Obscurity"...
...
Ich glaube aufgrund der Ergebnisse weiterhin nicht, dass es (heutzutage) einen realen Unterschied macht
Das mit dem Ping-unterdrücken kommt noch aus einer Zeit, als Rechenzeit und Bandbreite noch teuer war und auch in den IP-Adressräumen "große Lücken" ohne Systeme dahinter waren.
Da hat man halt durch Pings erstmal geschaut, wo überhaupt Systeme sitzen und sich dann auf diese "lohnenden Systeme" gestürzt. Heutzutage kann man prinzipiell immer fast immer davon ausgehen, daß hinter jeder regulären IPv4-Adresse ein System sitzt. da braucht man vorher keine Filter, der "unbenutzte" Adressen aussortiert.
lks
Ich sage nur "Ping of death".
Aber ernsthaft - wer ICMP *deshalb* abschaltet, statt die kompromittierbaren Systeme zu ersetzen bzw. zu isolieren, sollte nicht mal an den Wasserkocher dürfen...
Aber ernsthaft - wer ICMP *deshalb* abschaltet, statt die kompromittierbaren Systeme zu ersetzen bzw. zu isolieren, sollte nicht mal an den Wasserkocher dürfen...
1
und wenn man es schon abschalten will - dann bitte richtig. Und zwar am Router VOR seiner IP (d.h. meist beim Provider - und ob der das mitmacht...). Natürlich kann ich einfach das Ping-Paket verwerfen. Dann kommt halt ein "unreachable" zurück. Es müsste aber vom Provider zurückkommen. Wenn ich das einfach bei mir verwerfe ist das als wenn jemand an der Tür klingelt und ich brülle "niemand zuhause". Ggf. glaubt es ja jemand...
Ganz davon ab: Ich vermute mal das heute 99% der "Angriffe" eh so blöd sind das die gar nicht mehr lang prüfen sondern einfach ihre Scripte losjagen komme was da wolle (ich weiss nicht wieviele Scans auf die cmd.exe mein Linux-Webserver schon hat - und da is es wirklich einfach zu erkennen das es kein Windows is!). Da spart man sich dann also höchstens nen paar Pakete.
Ganz davon ab: Ich vermute mal das heute 99% der "Angriffe" eh so blöd sind das die gar nicht mehr lang prüfen sondern einfach ihre Scripte losjagen komme was da wolle (ich weiss nicht wieviele Scans auf die cmd.exe mein Linux-Webserver schon hat - und da is es wirklich einfach zu erkennen das es kein Windows is!). Da spart man sich dann also höchstens nen paar Pakete.
Zitat von @maretz:
und wenn man es schon abschalten will - dann bitte richtig. Und zwar am Router VOR seiner IP
und wenn man es schon abschalten will - dann bitte richtig. Und zwar am Router VOR seiner IP
Das meine ich ja mit "isolieren".
Und mal ernsthaft - ein Router, bei dem ICMP-Pakete bereits ein derartig großes Risiko darstellen dass man überhaupt auf die Idee kommt, sie zu verwerfen, hat im Internet nichts zu suchen.
"Host-Unreachables" bekommst du von Provider-Routern eher selten bis nie geschickt - denn die Generierung von ICMP-Nachrichten geschieht in der Regel auf der normalen CPU der Router und so etwas will man tunlichst vermeiden. Wenn da nichts ist, kommt einfach überhaupt nichts zurück
Und wenn uns Kunden fragen, ob wir auf unseren Routern Dinge filtern können, dann höchstens temporär wenn ein extrem guter Grund dafür vorliegt und es sich nicht durch eine Nullroute umsetzen lässt.
Jede Regel die wir in einen Router einfügen wird bei jedem Paket was Richtung Kunde geschickt wird abgearbeitet. Und wenn der dann Mal im Rahmen eines DDoS mit vielen Paketen beworfen wird (es gibt auch ICMP-Floods), kommt auch unser Router ins Schwitzen - und es würden dann andere Kunden mit Trafficfiltern ebenfalls getroffen, weil die Filterqueue voll ist.
Das mag bei DSL-Verbindungen vielleicht noch gehen, aber in Rechenzentren funktioniert das nicht.
Wenn der Kunde da unbedingt gefilterten Traffic haben will, muss er sich selbst in Form geeigneter Hardware darum kümmern.
Wir können ja nicht im Mid- und Low-Volume-Netzwerk (wo das feinere Routing für Kunden-Subnetze stattfindet) überall irgendwelche Juniper MX104 oder ähnliche Gerätschaften aufstellen, weil manche Kunden ungerne anpingbar sind
Und wenn uns Kunden fragen, ob wir auf unseren Routern Dinge filtern können, dann höchstens temporär wenn ein extrem guter Grund dafür vorliegt und es sich nicht durch eine Nullroute umsetzen lässt.
Jede Regel die wir in einen Router einfügen wird bei jedem Paket was Richtung Kunde geschickt wird abgearbeitet. Und wenn der dann Mal im Rahmen eines DDoS mit vielen Paketen beworfen wird (es gibt auch ICMP-Floods), kommt auch unser Router ins Schwitzen - und es würden dann andere Kunden mit Trafficfiltern ebenfalls getroffen, weil die Filterqueue voll ist.
Das mag bei DSL-Verbindungen vielleicht noch gehen, aber in Rechenzentren funktioniert das nicht.
Wenn der Kunde da unbedingt gefilterten Traffic haben will, muss er sich selbst in Form geeigneter Hardware darum kümmern.
Wir können ja nicht im Mid- und Low-Volume-Netzwerk (wo das feinere Routing für Kunden-Subnetze stattfindet) überall irgendwelche Juniper MX104 oder ähnliche Gerätschaften aufstellen, weil manche Kunden ungerne anpingbar sind
Oh...sehnse , wieder was gelernt 
Vielen Dank.
Vielen Dank.
