6
Fedora Firewall: ICMP komplett ausschalten
Seit Fedora 20 und auch Redhat (bald auch Fedora Server 21 (freu)) den "firewalld" Daemon statt direkt "iptables" für seine Firewall nutzt, ist es nicht mehr so leicht z.B. den Ping per icmp komplett auszuschalten (es geht nur ein Block und kein Deny über die Config-Files). So reagiert der Rechner/Server noch auf Anfragen und gibt dann ein "Destination Host Prohibited" beim Ping aus. Mein Wunsch ist es aber, dass der Server gar nichts ausgibt und nicht auf einen Ping reagiert.
Um dieses kleine Problem zu lösen, gibt es innerhalb der Shell und dem "firewall-cmd" Befehl die "--direct" Anweisung. Damit kann man direkte iptable Befehle zum firewalld senden (und speichern).
1) Hinzufügen der Regel um keinen eingehenden Ping zu erlauben:
2) Reload der Firewall
3) Testen, ob die Regle jetzt aktiv ist:
Ab jetzt sollte kein Ping zu diesem Server mehr möglich sein.
Um die Regel wieder zu löschen gibt man folgende Befehle hintereinander ein:
Dann kann man mit Punkt 3 wieder nachschauen, ob die Regel noch aktiv ist.
Gruß
Frank
Um dieses kleine Problem zu lösen, gibt es innerhalb der Shell und dem "firewall-cmd" Befehl die "--direct" Anweisung. Damit kann man direkte iptable Befehle zum firewalld senden (und speichern).
1) Hinzufügen der Regel um keinen eingehenden Ping zu erlauben:
firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 0 -p icmp -j DROP
firewall-cmd --reload
firewall-cmd --direct --get-rules ipv4 filter INPUT
Ausgabe:
0 -p icmp -j DROP
Um die Regel wieder zu löschen gibt man folgende Befehle hintereinander ein:
firewall-cmd --permanent --direct --remove-rule ipv4 filter INPUT 0 -p icmp -j DROP
firewall-cms --reload
firewall-cmd --direct --remove-rule ipv4 filter INPUT 0 -p icmp -j DROP
firewall-cms --reload
Dann kann man mit Punkt 3 wieder nachschauen, ob die Regel noch aktiv ist.
Gruß
Frank
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 252774
Url: https://administrator.de/contentid/252774
Printed on: April 18, 2024 at 23:04 o'clock
6 Comments
Latest comment
Ganz nett,
aber ich sehe den Sinn nicht, das antworten auf ICMP-Echo-Requests zu unterbinden. "Verstecken" funktioniert nicht, solange man Serverdienste anbieten will. Böse Buben verlassen sich heutzutage nicht mehr auf Ping-Antworten. sondern machen ausgetüfteltere Scans, um festzustellen, ob eine Kiste da ist oder nicht. Das ist so, als wenn man sich beim Versteckspiel einen zu dünnen Baum aussucht und der Hintern und der Bauch guckt hinter dem Baum hervor.
Das einzige, was ein unterdrücktes ICMP-Echo bewirkt, ist, daß einem "Guten" eine einfache Diagnosemöglichkeit der konnektivität genommen wird.
lks
aber ich sehe den Sinn nicht, das antworten auf ICMP-Echo-Requests zu unterbinden. "Verstecken" funktioniert nicht, solange man Serverdienste anbieten will. Böse Buben verlassen sich heutzutage nicht mehr auf Ping-Antworten. sondern machen ausgetüfteltere Scans, um festzustellen, ob eine Kiste da ist oder nicht. Das ist so, als wenn man sich beim Versteckspiel einen zu dünnen Baum aussucht und der Hintern und der Bauch guckt hinter dem Baum hervor.
Das einzige, was ein unterdrücktes ICMP-Echo bewirkt, ist, daß einem "Guten" eine einfache Diagnosemöglichkeit der konnektivität genommen wird.
lks
Hi,
ob es sinnvoll ist oder nicht, muss jeder für sich selbst entscheiden. Es ist nur eine von vielen möglichen Maßnahmen. Wir haben damit die Scans zum größten Teil unterbunden (deutlich weniger). Die meisten "einfachen" Hacker Tools sind wir damit los - für die sind wir unsichtbar. Bei den "Pro" Tools sieht das sicherlich anders aus. Diesen begegnen wir mit anderen Sicherheitsmaßnahmen. Unsere Diagnosemöglichkeiten sind davon nicht betroffen, da sie nicht über ICMP-Dienste laufen.
Gruß
Frank
ob es sinnvoll ist oder nicht, muss jeder für sich selbst entscheiden. Es ist nur eine von vielen möglichen Maßnahmen. Wir haben damit die Scans zum größten Teil unterbunden (deutlich weniger). Die meisten "einfachen" Hacker Tools sind wir damit los - für die sind wir unsichtbar. Bei den "Pro" Tools sieht das sicherlich anders aus. Diesen begegnen wir mit anderen Sicherheitsmaßnahmen. Unsere Diagnosemöglichkeiten sind davon nicht betroffen, da sie nicht über ICMP-Dienste laufen.
Gruß
Frank
Zitat von @Frank:
ob es sinnvoll ist oder nicht, muss jeder für sich selbst entscheiden.
Es ist nur eine von vielen möglichen Sicherheitsmaßnahmen.
ob es sinnvoll ist oder nicht, muss jeder für sich selbst entscheiden.
Es ist nur eine von vielen möglichen Sicherheitsmaßnahmen.
Ich bin der Meinung, daß es überhaupt keine Sicherheitsmaßnahme ist, aber wie du schon sagst, muß das jeder für sich selbst entscheiden.
Wir haben damit die Scans zum größten Teil unterbunden (deutlich weniger). Die meisten
"einfachen" Hacker Tools sind wir damit los - für die sind wir unsichtbar. Bei den "Pro" Tools sieht das
sicherlich anders aus.
"einfachen" Hacker Tools sind wir damit los - für die sind wir unsichtbar. Bei den "Pro" Tools sieht das
sicherlich anders aus.
Die meisten Skriptt-Kiddietools, die ich kenne, haben auch schon eine "Pro"-Modus wenn Du das so nennen willst. Wenn es Dir hilft, ok. Aber meine Erfahrung ist, daß die wirklich bösen sich durch solceh Kinkerlitzen nicht abhalten lassen.
Diesen begegnen wir mit anderen Sicherheitsmaßnahmen. Unsere Diagnosemöglichkeiten sind davon nicht betroffen, da sie nicht über ICMP-Dienste laufen.
Klar. Aber ich habe es gerne wenn ich einfach nur mit einen Ping schauen kann, ob ein Ziel überhaupt da ist und nicht nmap anwerfen muß, um zu sehen, ob es da ist oder ob einfach nur mein system spinnt und ich deswegen keien verbindugn bekomme.
lks
Ich bin auch der Meinung, dass es keinerlei Sicherheitsmaßnahme darstellt, da das Antwortverhalten durch geblockte ICMP-Anfragen ein anderes ist, als wenn der Host gar nicht da wäre.
Bei geblockten ICMP-Anfragen kommt es einfach zum Timeout, während es bei einem Host, der nicht erreichbar ist, zu Antworten vom Router kommt, dass der Host nicht erreichbar ist.
Also in diesem Fall ist keine Antwort auch eine Antwort.
Bei geblockten ICMP-Anfragen kommt es einfach zum Timeout, während es bei einem Host, der nicht erreichbar ist, zu Antworten vom Router kommt, dass der Host nicht erreichbar ist.
Also in diesem Fall ist keine Antwort auch eine Antwort.
Hi tikayevent,
Das stimmt schon, aber es reicht bisher noch für die meisten Tools aus, einfach nicht zu antworten. Es ist jetzt auch nicht "die Sicherheitsmaßnahme", es verringert nur deutlich die Last auf unseren Systemen (weniger Scans, weniger Logs zum Auswerten, etc). Nicht mehr, nicht weniger.
Gruß
Frank
Ich bin auch der Meinung, dass es keinerlei Sicherheitsmaßnahme darstellt, da das Antwortverhalten durch geblockte ICMP-Anfragen ein anderes ist, als wenn der Host gar nicht da wäre.
Das stimmt schon, aber es reicht bisher noch für die meisten Tools aus, einfach nicht zu antworten. Es ist jetzt auch nicht "die Sicherheitsmaßnahme", es verringert nur deutlich die Last auf unseren Systemen (weniger Scans, weniger Logs zum Auswerten, etc). Nicht mehr, nicht weniger.
Gruß
Frank
Bei geblockten ICMP-Anfragen kommt es einfach zum Timeout
Das ist ja eigentlich auch der Sinn, denn so wehrt man wenigstens alle Gelegenheits Hacker ab. Auch bei Routern macht das Sinn.Frank hat aber Recht und jeder der öffentliche Server betreibt weiss das das die Angriffsrate erheblich runtergeht wenn ICMP echo requests deaktiviert sind.
Schlimm ist eher Frank's Schrotschuss ICMP so gleich ganz zu killen, denn das killt auch alle sinnvollen und notwendigen ICMP Service Typen für den TCP Betrieb.
Mit "iptables -A INPUT -p icmp --icmp-type echo-request -j DROP" würde man es etwas behutsamer machen und wenigstens nur die Echo-requests auf den Server blocken alles andere Sinnvolle aber belassen.
