Original von The Dude
und kann auch sonst nicht von aussen erreicht werden, wenn keine forwarding regeln eingerichtet sind. also auch nicht ueber traceroute.
Sofern man nicht eine bestehende Verbindung ausnutzt.
es gibt keine traceroute icmp nachricht.
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.
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.
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.
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".
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 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]
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.
Code:
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
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.
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-security/most-common-qs/section-18.html
[2]
http://www.sys-security.com/archive/papers/ICMP_Scanning_v3.0.pdf
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.
![[HaBo]](/styles/default/logoklein.png){kind=small}
)