[HaBo]

schmidtl_dd

Anzeige

Hi,

kleine Streitfrage.

Wie haltet es ihr mit dem Blocken von ICMP auf einer Firewall (eine "richtige", keine Desktopfirewall.)

Meine Auffassung sagt: zulassen, auch wenn der Angreifer dann vieles in Erfahrung bringen kann. Andere Leute wiederrum sagen, was der Angreifer nicht weiß kanner nicht nutzen...

Aber ist "Security by Obscurity" nicht böse?

Heinzelotto

also ich brauche icmp (es macht auf jeden Fall sinn), da ich einen eigenen ssh- und webserver auf meinem pc laufen hab und es immer praktisch ist, mal von der schule schnell anzupingen um z.B. zu gucken, ob der Rechner noch an ist..

bitmuncher

Solange man die ICMP-Nachrichten auf Echo-Replies (Pings) beschränkt, sehe ich keine Probleme mit ICMP. Andere Nachrichten sollte man aber blocken. Security by obscurity mag zwar auf Dauer nicht viel bringen, macht es aber zumindest den Skript-Kiddies um einiges schwerer. Gerade Broadcast-Pings sollte man unterbinden, damit nicht gleich das ganze Netzwerk mit einem simplen Ping aufgedeckt werden kann. Ausserdem gibt es diverse ICMP-Nachrichten, die durchaus auch in einigen Systemen zu Problemen führen können (Stichwort: ICMP-Flood).

__________________

Gulliver

@bitmuncher

warum ausgerechnet ping zulassen und die anderen (eher wichtigen) verbieten?
und generell icmp verbieten macht ueberhaupt keinen Sinn.

bitmuncher

Mir ist keine Sicherheitslücke für Pings bekannt. Warum die anderen ICMP-Nachrichten wichtig sind, ist mir zugegebenermassen etwas unklar, ausser man will das Netzwerk leicht scanbar machen. Ping ist halt brauchbar um zu schauen ob der Rechner überhaupt online ist. Den Rest habe ich bisher noch nie gebraucht, weswegen ich sie nie als wichtig betrachtet habe. Rechner-Infos kann man über SNMP wesentlich besser und umfangreicher im Netzwerk zur Verfügung stellen, ohne dass sie für die ganze Welt zur Verfügung stehen.
Gerade auf einem Firewall-Router sollte man ICMP meiner Meinung nach unterbinden um das Ausschnüffeln des dahinter liegenden Netzwerks zu erschweren. Damit sind Scans per ICMP auf laufende Services im Netzwerk nicht mehr möglich. Mir würde z.B. nur eine Möglichkeit einfallen um rauszubekommen ob ein Rechner überhaupt routet und das geht per ICMP (ICMP 5 und 9). Auch ein Traceroute ins LAN hinter dem Router ist nur noch begrenzt möglich, wenn der Router nicht jeden ICMP-Kram beantwortet. Ich denke daher, dass es durchaus sinnvoll ist nur Echo-Replies zuzulassen.

__________________

+++ATH0

Dass es "über SNMP wesentlich besser" gehe, ist doch kein Grund dafür, ICMP nicht zu erlauben.
Was hat man denn eigentlich in einem Netzwerk zu verbergen? Wenn man Sicherheitslücken zu verbergen hat, hat man eh etwas falsch gemacht...

bitmuncher

Es geht nicht darum etwas zu verbergen, sondern das Ausschnüffeln des Netzwerks hinter der Firewall zu erschweren. Dass man das durch Blocken von ICMP-Messages nicht verhindern kann, dürfte wohl den meisten hier klar sein, aber man muss es einem potentiellen Angreifer ja nicht noch einfacher machen. Ich sehe keinen Grund, warum man ICMP zulassen sollte und in jedem Netzwerk sollte eigentlich die Devise sein: "Was nicht gebraucht wird sollte deaktiviert oder dicht gemacht werden." Wer das nicht so macht, macht wohl wesentlich eher was falsch.
Daher sollte man sich evtl. nicht unbedingt die Frage stellen "Warum sollte ich es dicht machen?" sondern eher "Warum sollte ich es erlauben?".

Im Übrigen hat jeder in einem Netzwerk potentielle Sicherheitslücken zu verbergen, denn niemand kann garantieren, dass jegliche im Netzwerk eingesetzte Software fehlerfrei ist (vor allem dann nicht, wenn hinter der Firewall Windows-Rechner stehen). Von daher sollte man ein Netzwerk so gut wie möglich abschirmen und dazu gehört nunmal, dass man deaktiviert und blockt, was nicht für die Funktionalität des Netzwerks notwendig ist.

Daher würde ich anraten: Denkt mal lieber drüber nach warum ihr ICMP zulassen wollt (ausser um es einem potentiellen Angreifer beim Sniffen möglichst einfach zu machen). Wenn man es wirklich nutzt, ist es klar, dass man es zulassen muss, aber wer es nicht nutzt, sollte es halt dicht machen.

__________________

Elderan

Hallo,
also wenn man alle ICMP Packete blockt, so würde das Netzwerk wahrscheinlich nicht mehr laufen.

Allerdings würde ich es bevorzugen, möglichst wenig vom Netzwerk preiszuegeben, sofern das Netzwerk an sich nicht beeinträchtigt wird.

Allerdings einfach nur Echo Reply unterbinden, und dann behaupten, dass Netzwerk sei perfekt gesichert, so wie es oft Desktop-Fw oder Planetopia versprechen, ist auch nicht richtig, denn es gibt andere Methoden, alle IP Adressen des Netzes zu ermitteln.
Ergo, gegen kleine Kinder würde das verhindern von pingen was bringen, aber gegen Leute mit Kentniss eher weniger, bzw. den Untergang nur herrauszöger ^^

bitmuncher

Ähm, ich meinte aber, dass man ausser Echo-Replies alles andere unterbinden sollte. Pings unterbinden halte ich persönlich für unsinnig, aber gerade Traceroute u.ä. ICMP-Requests sollte man unterbinden. Ein Rechner hinter eine Masquerading-Firewall ist ja eh von aussen nicht anpingbar.

__________________

ERit

ich denke mal ein unsichtbar im netz ist schon gut, kommt immer darauf an wie man seinen rechner nützt. antworten auch pings sollten meiner meinung nach doch unterdrückt werden, je nachdem was man gerade benötigt. ich sag mal fürs schulnetz wärend der stunde, wennma sich nicht gerade mit dem netz befasst ist es doch sinnvoll.
lg

The Dude

und kann auch sonst nicht von aussen erreicht werden, wenn keine forwarding regeln eingerichtet sind. also auch nicht ueber traceroute.

es gibt keine traceroute icmp nachricht.
unix traceroute schickt udp pakete an einen hohen port, an dem vermutlich kein dienst auf dem zielrechner laeuft und setzt die ttl im ip datagramm auf 1, dann auf 2 usw. bis nicht mehr icmp "time exceeded" (type 11, code 0) von den routern dazwischen, sondern icmp "port unreachable" (type 3, code 3) vom zielrechner empfangen wird.

wenn die rede davon ist "icmp zu blocken" dann ist immer "echo request" (type 8, code 0) gemeint. hat man hinter einem router ein netz in dem die rechner offizielle (d.h. im internet geroutete) ip nummern haben, dann verhindert man so eine methode um schnell alle erreichbaren rechner zu ermitteln. es geht einfach nur darum einem potentiellen angreifer so wenig informationen wie moeglich zu geben.
zu sagen "icmp ist boese" ist genauso schwachsinnig wie zu sagen "tcp ist boese".

wenn man an einem router alle icmp nachrichten blockiert wird das internet vom internen netz aus dadurch praktisch unbenutzbar. werden nachrichten wie "host unreachable" (type 3, code 1), "port unreachable" (type 3, code 3), oder "fragmentation needed, but don't-fragment bit set" (type 3, code 4) im netzwerk hinter dem router/der firewall nicht mehr empfangen wird immer auf einen timeout gewartet und alles wird arschlahm. wird type 3, code 4 nicht mehr empfangen kann ueberhaupt keine verbindung zum entsprechenden zielrechner aufgebaut werden.[1]

bevor man seinen paketfilter konfiguriert sollte man wissen wie der scheiss funktioniert. was man mit icmp zu "scanning" zwecken anstellen kann steht z.b. in [2]. eventuell gibt die lektuere anregungen was man noch so blocken koennte, wenn mans nicht lassen kann.

[1] http://www.faqs.org/faqs/computer-se...ection-18.html
[2] http://www.sys-security.com/archive/...nning_v3.0.pdf

bitmuncher

Sofern man nicht eine bestehende Verbindung ausnutzt.

Ich nehme an, dass du dich auf RFC792 beziehst. Dann schau dir aber mal bitte RFC1393 an, Kapitel 2:

Zitat:
2. Traceroute Tomorrow

The proposed traceroute would use a different algorithm to achieve
the same goal, namely, to trace the path to a host. Because the new
traceroute uses an ICMP message designed for the purpose, additional
information, unavailable to the original traceroute user, can be made
available.

Wie ein Unix-Traceroute heutzutage funktioniert ist mir durchaus klar, aber das heisst nicht, dass es nur so funktioniert und in Zukunft immer so funktionieren wird. Man sollte einen Rechner und/oder ein Netzwerk durchaus auch gegen mögliche Angriffs- und Scan-Methoden sichern um so schon potentiellen Lücken vorzubeugen, zu denen erst in Zukunft entsprechende Tools entwickelt werden. Manchmal sollte man als Administrator auch mal schauen, was evtl. möglich wäre, denn wie die Geschichte zeigt, findet sich (fast) immer ein findiger Kopf, der die notwendige "Technik" dazu entwickelt um aus dem "theoretisch möglich" ein "praktisch möglich" zu machen.

Das ist sicherlich eine Möglichkeit, aber IP-Ranges ohne Ping abzuscannen ist ja nun auch nicht das grosse Problem. Ich persönlich lasse Pings allein schon für's Monitoring der Server zu. Ob ein Server akzeptable Antwortzeiten liefert, lässt sich darüber am einfachsten ermitteln.

Wenn ich in einem Linux-System
ausführe, werden auch alle eingehenden ICMP-Nachrichten geblockt. Erst wenn diese zu einer von innen angeforderten Verbindung gehören, werden diese zugelassen.
Dass nicht alle im Netzwerk geblockt werden können, sollte ja wohl klar sein und da stimme ich dir auch voll und ganz zu, aber deswegen muss ich trotzdem noch lange keine unangeforderten Request zulassen.

Ich denke, dass man nicht nur wissen sollte, was heutzutage schon möglich ist, sondern dass man durchaus auch mal schauen sollte, was theoretisch möglich wäre. Dazu sollte man zuerst einmal RFCs lesen und schauen wo ICMP-Request und ICMP-Messages benutzt werden, um dann mal zu überlegen, ob es da nicht evtl. in Zukunft neue "Techniken" geben könnte. Man benutzt ja z.B. auch einen Stack-Smashing-Guard, auch wenn es für die derzeit installierten Programm-Versionen (noch) keine Exploits gibt und man setzt ja auch ein IDS ein, auch wenn man den Server für gut gesichert hält.
Als Admin sollte man nicht nur für hier und heute, sondern auch ein wenig für die Zukunft arbeiten und in Zukunft wird z.B. vielleicht auch auf Unix-System per Default das Traceroute über ICMP realisiert.

__________________

The Dude

oder das automatische anlegen von port forwarding regeln ausloest[1]. das ist allerdings auch irgendwie das ausnutzen einer bestehenden verbindung.

kannte ich noch nicht, wieder was gelernt. aber das aendert ja nichts daran, dass es weiterhin viele moeglichkeiten gibt die funktionalitaet von traceroute zu erreichen. deshalb ist imho das blocken eingehender pakete bestimmter ports/protokolle um traceroute zu verhindern nicht so sinnvoll.

dagegen spricht auch imho nichts, aber es geht hier ja eher um die clients im netz hinter der firewall, oder? bei einem netz in dem oeffentliche ip nummern verwendet werden hat man ja in der regel eine dmz in der die server stehen. in die dmz ping zu erlauben ist wohl nicht so bedenklich, schliesslich sind die server sowieso von aussen erreichbar und sollten so gut es geht gesichert sein. man kann die firewall so konfigurieren, dass sie keine "time exceeded" nachrichten verschickt und auch keine aus dem internen netz rauslaesst. das waere denke ich sinnvoller um traceroute in die dmz (und ins interne netz) zu unterbinden als von aussen eingehende pakete bestimmten typs zu blocken. das wird vermutlich auch oft gemacht, wenn man bei einem traceroute sieht wie die pakete an einem hop versickern (* im traceroute output).
vermutlich hat das keinen negativen effekt auf die verwendung des netzes, da die ueblicherweise verwendeten ttl werte afaik meist groesser sind als die anzahl hops die eine route durch das internet hat.

das klingt aber doch schon ganz anders als "alle icmp nachrichten ausser ping blocken". warum hast du das nicht gleich so ausfuehrlich beschrieben? das haette dem threadersteller vermutlich viel eher weitergeholfen.

[1] http://wiki.hackerboard.de/index.php...ernen_Firewall

bitmuncher

Also so wie ich das verstanden habe, geht es hier um den Firewall-Rechner selbst. Da sollte der Grundsatz an iptables-Regeln etwa wie folgt aussehen:
(man könnte hier natürlich OUTPUT auch noch auf bestimmte IP-Ranges oder Interfaces restrikten, aber wir lassen das hier mal der Einfachheit halber so. )

Ich lasse dann halt immer noch die Pings zu:
und deaktiviere Bogus Error Responses
Dazu dann die Regeln für's Routing und schon lässt man von aussen keine ICMP-Requests mehr zu. Ein entsprechendes Firewall-Skript für einen einfachen Firewall-Router hatte ich mal im Wiki veröffentlicht: http://wiki.hackerboard.de/index.php...nux_einrichten

Ich hatte mich wohl etwas undeutlich ausgedrückt. Sorry dafür.

__________________

steinbock

http://www.computec.ch/download.php?view.788