"ping...
...sendet ein ICMP-echo-request-paket an die zieladresse des zu überprüfenden hosts. der empfänger muss, insofern er das protokoll unterstützt, laut protokollspezifikation eine antwort zurücksenden: ICMP echo-reply. ist der zielrechner nicht erreichbar, antwortet der router: network unreachable (netzwerk nicht erreichbar) oder host unreachable (gegenstelle nicht erreichbar).
aus einer fehlenden antwort kann man allerdings nicht eindeutig darauf schließen, dass die gegenstelle nicht erreichbar ist. manche hosts sind nämlich so konfiguriert, dass sie ICMP-pakete ignorieren und verwerfen." (quelle: wikipedia)

hier mein beispiel (abfrage an einem montag) mit www.orf.at (eingabeaufforderung: ping www.orf.at)

zur info: in den bildern ist ein pfad mit "simone peterseil" zu lesen. das ergibt sich dadurch, dass wir im selben haushalt leben und die abfrage nur einmal durchgeführt haben. (weblog simone)



interpretation: mein rechner hat datenpakete an den rechner von www.orf.at gesandt. normalerweise erhalte ich als antwort zeiten (angaben wie lange meine pakete zum zielrechner und wieder zurück gebraucht haben) und informationen (z.b. datengröße) über meine pakte. zusätzlich kann ich der anfrage entnehmen, ob eine verbindung zum zielhost besteht. in meinem beispiel sieht man, dass ich 4 pakete, mit einer größe von 32bit, an den orf geschickt habe. alle pakete sind wieder zurückgekommen, jedoch mit der information, dass der "zielhost nicht erreichbar" ist. das kann verschiedene gründe haben: zum einen kann es sein, dass der rechner wirklich nicht erreichbar ist. es kann aber auch vorkommen, dass der zielhost den ping deaktiviert hat, um sich vor hackern oder sonstigen angriffen zu schützen. letzteres ist häufig der fall.

"tracer(ou)t(e)...
...ist ein diagnose-werkzeug, mit dem ermittelt werden kann, welche router (zwischensysteme) ein datenpaket über ein IP-netz passiert, bis es bei einem bestimmten host ankommt. [...] die anzeige von traceroute zeigt nicht immer den tatsächlichen weg, den die datenpakete nehmen. es wird beeinflusst von firewalls, fehlerhaften implementierungen des IP-stacks, network address translation, routing und anderen faktoren." (quelle: wikipedia)

warum der zielhost von www.orf.at "nicht erreichbar" ist, demonstiere ich hier (abfrage an einem sonntag) (eingabeaufforderung: tracert www.orf.at)



interpretation: auf dem bild kann man sehen, dass der zielhost existiert, meine datenpakete aber verworfen werden (wie schon bei "ping" erklärt). mit sicherheit hat der orf seinen ping deaktiviert, um hackern keine chance zu bieten, auf den server zuzugreifen.

unterschied: wochenende - wochentag
ich habe beide befehle (ping & tracert) an einem montag und einem sonntag durchgeführt und bin (abgesehen von den zeiten, die die pakete unterwegs waren) immer auf das gleiche ergebnis gekommen >> "zielhost nicht erreichbar".

webtool - tracert
eine andere möglichkeit den befehl tracert auszuführen, gibt es noch über das webtool von uta.



interpretation: es scheint so, als ob der zielhost plötzlich erreicht wurde. das ist nur dadurch möglich, dass die abfrage bei uta beginnt (und nicht wie üblich bei meinem rechner) und der server vom orf erkennt, dass es sich nicht um einen angriff handelt und deswegen die abfrage zulässt.

unterschied: wochenende - wochentag
und wie bei dem windows-befehl ist es so, dass es kaum unterschiede zwischen dem wochenende und dem wochentag gibt. einzig ist wieder eine unterscheidung in der zeitangabe zu erkennen.

portscan
abschließend habe ich noch eine sicherheitsüberprüfung (mit dem webtool von sygate) an meinem computer durchgeführt.


"you are not fully protected:
we have detected that some of our probes connected with your computer."

interpretation: das ergebnis sagt mir, dass mein rechner einige lücken aufweist und er nicht komplett vor hackern geschützt ist.