iptables | Arten von ICMP: Welche sind (potenziell) schädlich?


8

Ich habe gelesen, dass bestimmte Arten von ICMP-Paketen schädlich sein können. Fragen:

  • Welche und warum?
  • Wie soll ich einen iptables-Regelsatz für jeden ICMP-Pakettyp gestalten?
  • Sollte ich eine dieser Arten von ICMP-Paketen auf die Rate beschränken? Und wie?

[¹] Die Typen, über die ich gelesen habe: Weiterleiten (5), Zeitstempel (13) und Adressmaskenanforderung (17). Bitte berücksichtigen Sie bei Ihrer Antwort nicht nur diese.

Weitere Informationen
Es handelt sich um einen Webserver auf einem VPS mit Ubuntu Server.

Das Ziel
Ich versuche, das System sicherer zu machen, das Risiko einiger D / DoS-Angriffe und allgemeinen Missbrauchs zu verringern.

Verwandte
Ist meine Linux-Firewall sicher?
Warum nicht ICMP blockieren?

Antworten:


10

Es hört sich so an, als würden Sie dem Mantra "ICMP IS EVIL" zum Opfer fallen.
ICMP ist NICHT böse, sondern wird nur missverstanden. Die traurige Realität ist, dass viele Administratoren befürchten, was sie nicht verstehen, und deshalb ICMP aus ihrem Netzwerkuniversum entfernen, es auf der Ebene der Rand-Firewall meiden und verhindern, dass es zum Nutzen ihres Netzwerks seinen richtigen und richtigen Platz einnimmt.

Lassen Sie mich dennoch Ihre Fragen beantworten:


Welche Arten von ICMP-Nachrichten können schädlich sein und warum?
So ziemlich alle.

  • EchoPakete können verwendet werden, um Dienste zu stören (insbesondere für Systeme mit schlecht implementierten IP-Stacks); Bei rechtmäßiger Verwendung können sie Informationen über Ihr Netzwerk geben.

  • Destination Unreachablekann böswillig injiziert werden; Bei rechtmäßiger Verwendung können sie Informationen über * Ihre Firewall / Routing-Struktur oder über einen bestimmten Computer in Ihrem Netzwerk bereitstellen.

  • Source Quench kann böswillig gesendet werden, damit Ihr Server effektiv in einer Ecke sitzt und an seinem Daumen saugt.

  • redirect kann verwendet werden, wie der Name schon sagt.

  • router advertisementund router solicitationAnforderungen können verwendet werden, um "interessante" Verkehrstopologien zu erstellen (und MITM-Angriffe zu erleichtern), wenn Ihre Hosts diese tatsächlich beachten.

  • traceroutewurde entwickelt , um Informationen zur Netzwerktopologie bereitzustellen.

…usw...

Die Namen der verschiedenen ICMP-Nachrichten beschreiben ziemlich genau, wozu sie in der Lage sind. Üben Sie Ihre angeborene Paranoia aus, indem Sie sich Alptraumszenarien ausdenken :-)


Wie soll ich einen iptables-Regelsatz für jeden ICMP-Pakettyp gestalten?
Wenn Sie keinen guten Grund haben, sich mit dem ICMP-Verkehr herumzuschlagen, lassen Sie es in Ruhe!
Das Herumspielen mit ICMP-Verkehr verhindert die angemessene Verwendung von ICMP-Nachrichten (Verkehrsmanagement und Fehlerbehebung) - dies ist eher frustrierend als hilfreich.


Sollte ich eine dieser Arten von ICMP-Paketen auf die Rate beschränken? Und wie?
Dies ist möglicherweise die einzige legitime Ausnahme von der Philosophie "Lass es die Hölle in Ruhe". ICMP-Nachrichten mit Raten- oder Bandbreitenbegrenzung können hilfreich sein, um der illegitimen Verwendung der ICMP-Nachrichten zu entgehen. FreeBSD wird standardmäßig mit ICMP-Bandbreiten- / Ratenbegrenzung geliefert , und ich gehe davon aus, dass Linux über ähnliche Funktionen verfügt.

Die Begrenzung der Rate / Bandbreite ist einer pauschalen Firewall-Regel, die den ICMP-Verkehr löscht, weitaus vorzuziehen: Sie ermöglicht es ICMP weiterhin, seinen Zweck im Netzwerk zu erfüllen, und verringert auch teilweise Versuche, Ihren Server zu missbrauchen.


Das Obige stellt die Meinung eines Systemadministrators dar, der seinerseits FREAKIN 'MÜDE ist, FEHLERSUCHE-NETZWERKE ZU HABEN, IN DENEN DER gesamte ICMP-VERKEHR ABGEFALLEN IST - Es ist ärgerlich, frustrierend und dauert länger, Probleme zu finden und zu beheben. :-)


Aber ... aber ... der Ping des Todes ist zu fürchten, auf irrationale Ebenen! (Ist es schlecht, dass ich sagen konnte, wer diese Antwort nach dem ersten Absatz geschrieben hat?)
Shane Madden

In der Tat ist ICMP nützlich. Wenn ich ein Opfer von "ICMP ist böse" wäre, würde ich lieber alle blockieren und diese Frage nicht öffnen :) Ich möchte nur Hilfe, um eine fundierte Entscheidung zu treffen. Sie können sicher sein, dass ich sie nicht alle blockieren werde :)
ML--

@ Shane Madden: Wird --state INVALIDPing of Death fallen lassen?
ML

7
@ ML-- Bitte mach dir keine Sorgen über den Ping des Todes. Kein Betriebssystem aus diesem Jahrtausend ist anfällig.
Shane Madden

2
@ ML-- Der einzige Vektor, um den ich mir Sorgen machen würde, ist Source Quench, und Sie können dies relativ ungestraft blockieren (TCP wird es schließlich selbst herausfinden). Ping & Traceroute sind definitiv Informationslecks, aber in der Praxis glaube ich nicht, dass dies Ihrer Umgebung zu viel echte Sicherheit verleiht. Ihr Kilometerstand (und das erforderliche Maß an Paranoia) können variieren (abhängig von der Empfindlichkeit Ihrer Daten / Umgebung).
voretaq7

4

Es geht nicht so sehr um Typen als um mögliche Angriffsvektoren. Es hat ein ziemlich effektiver DoS - Angriff das unter Verwendung von ICMP - Source - Quench - Paket in vielen gängigen Internet - Host-TCP / IP - Stacks für Jahre - und doch bedeutet dies nicht , dass die Quelle-Quench ICMP - Nachrichten müssen im allgemeinen gefiltert werden. Wie bei allem in der Netzwerksicherheit sollten Sie den Nutzen eines bestimmten Protokolls oder Dienstes anhand Ihrer persönlichen Prioritäten gegen die mögliche Angriffsfläche abwägen . Wenn Sie Hosts in Ihren Netzwerken haben, die durch ICMP für einen Angriffsvektor anfällig sind, können Sie diese nicht beheben und benötigen die spezifischen Funktionen nicht. Sie sollten sie auf jeden Fall filtern.

Für meine verwalteten v4-Netzwerke war es sowohl sicher als auch praktisch, die ICMP-Typen 0, 8 (Echoanforderung / -antwort), 11 (TTL abgelaufen), 3 (Ziel nicht erreichbar) und 12 (IP-Header-Fehler) zuzulassen und alle zu löschen der Rest.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.