Jeder Computer bzw. Knoten in einem Netzwerk verfügt über eine Adresse in IP Form, durch welche er gezielt ansprechbar ist. Wir können uns dies bildlich und stark vereinfacht wie ein Postnetzwerk vorstellen.

Internet Exchange Points (IXP) als Posthauptämter mit Flug & Lastwagenverbindungen.
Internet Service Provider (ISPs) als Wohnortpostämter
Exakte IP-Adressen als Postfächer (Mit Personenzuordnung).

Die Befehle ping bzw. tracert (für traceroute) ermöglichen nun, die Wege nachzuverfolgen und deren Geschwindigkeit zu messen bzw. Probleme zu identifizieren.
Der Begriff ping stammt von der Sonartechnik in U-booten, die mittels zielgerichteten Schallwellen und deren Reflektionszeit bzw. Charakteristika Messungen vornehmen können.

Ping ist ein TCP/IP tool und sendet ein ICMP „Echo Request“ Paket an den Zielhost und misst dessen Reaktionszeit.
Tracert (traceroute) ermittelt die Route der Pakete mittels TTL (Time To Live). Die TTL erhöht sich mit jedem Sprung und sendet ein individuelles ping zur jeweils letzten IP.

Vermittlungsstellen können jedoch gezielt ICMP Funktionen deaktivieren, um eine Überlastung (besonders im Zusammenhang mit gezielten Attacken) zu vermeiden.
Anmerkung: Das Ergebnis von tracert ist relativ, da es während den einzelnen hops zu einer Änderung der Route kommen kann.

Beispiel:
Ein Ping an www.heise.de ( IP: 193.99.144.85).

Es wurden am Sonntag Abend 4 Pakete (0% Verlust) gesendet, wobei sich eine Mittelwert in der Reaktionszeit von 29 Millisekunden ergab.

Am Montag Vormittag wurde ein weiterer ping gesendet (0% Verlust), wobei der Mittelwert wiederum 29 Millisekunden ergibt, allerdings mit einem Minimum von 26ms.

Heise.de dürfte über genug Ressourcen (Server, Bandbreite) verfügen, um eine übliche Belastung sowohl im erhöhten Sonntag abends Verkehr als auch im Montag morgens Verkehr ohne wesentliche Reaktionszeitverluste zu bewältigen. Die kürzere Minimum Zeit lässt zwar eine etwas schnellere Reaktion vermuten, kann aber auch durch die Routenwahl bedingt sein.

Etwas mehr Aufschluss gibt hier eine Analyse des tracert Outputs (Sonntag):

Das Output ist folgendermaßen zu lesen:

1 [Hop] 2ms [Paket1] 2ms [Paket2] 2ms [Paket3] 80.123.247.138 [Meine IP, statisch]
Dies Zeiten der einzelnen Hops sind kumulativ.
Es werden je Hop 3 pings gesendet. Je nachdem, ob der Netzwerkknoten bzw. Zielrechner einen DNS Eintrag hat und ob die Antwort des DNS Servers innerhalb eines engen Zeitlimits liegt, wird die IP Adresse auch aufgelöst.
Der Hostname gibt im Gegensatz zur IP relativ genaue Auskünfte zu dessen Funktion und Standort.
Die Anwendung eines von UTA zur Verfügung gestellten tools, bietet hierbei, vermutlich bedingt durch die wesentlich schnellere Anbindung zum DNS, deutlich bessere Leistung:

Sonntag, 29,JAN, 20:50

UTA Traceroute

1 fwsrv1.ces.uta.at (213.90.2.2) 0.611 ms 0.355 ms 0.322 ms

2 213.90.1.17 (213.90.1.17) 1.186 ms 1.195 ms 0.766 ms

3 wat1-15-21.net.uta.at (62.218.15.21) 1.062 ms 0.748 ms 0.678 ms

4 c76wmode1-tengigE4-1.net.uta.at (212.152.192.206) 0.899 ms 1.149 ms 1.077 ms

5 vie3-core.gigabiteth1-0.swip.net (130.244.205.57) 171.321 ms 1.557 ms 4.544 ms

6 shu1-core.pos2-0.swip.net (130.244.205.50) 1.470 ms 1.331 ms 1.509 ms

7 vix2.above.net (193.203.0.45) 1.497 ms 1.385 ms 1.512 ms

8 gi-2-6.mpr1.vie4.at.above.net (212.69.169.6) 1.532 ms 1.440 ms 1.507 ms

9 gi-1-16.mpr1.fra1.de.above.net (64.125.23.241) 25.243 ms 25.190 ms 25.222 ms

10 gi-1-1.er2a.fra1.de.above.net (64.125.23.182) 25.243 ms 25.242 ms 25.111 ms

11 plusline.fra1.de.above.net (62.4.64.54) 24.950 ms 25.125 ms 24.840 ms

12 heise2.f.de.plusline.net (213.83.46.196) 25.241 ms 24.839 ms 25.988 ms

13 www.heise.de (193.99.144.85) 26.390 ms 26.278 ms 25.220 ms

Ausgehend vom UTA Server mit diesem Service in Österreich (fwsrv1.ces.uta.at), über diverse UTA interne Router und Knoten, über das SWIP.net (Schweden), zurück zum VIX (Vienna Internet Exchange), nach Deutschland und abschließend über für Heise reservierte Knoten auf plusline.de zu einem der heise.de Webserver.

Mit 13 hops und einer Zeit von ca. 26ms ist dies etwas schneller als von meiner Verbindung mit Privatanschluss, die durch WLAN Router und zusätzlichen Router sowie ADSL deutlich „gebremst“ wird. Ersichtlich ist auch, dass UTA eine andere Route (dies ist beeinflussbar) als die Telekom verwendet.

Ein Ping zu dem mir nahe gelegenen Webserver www.aon.at ergibt beispielsweise einen Mittelwert von 17ms. Interne Netzwerke (Intranet) weisen üblicherweise <1ms auf. Meldungen wie „Zielhost nicht erreichbar“ oder „Zeitüberschreitung der Anfrage“ weisen auf technische Probleme hin.

Der Portscan:

Ein Portscanner überprüft einen Netzwerkhost auf offene Ports. Jeder Service (Liste) eines Computers im, z.B. heute üblichsten TCP/IP Protokoll, ist über einen oder einen Bereich von Ports (65535 bei TCP/IP) erreichbar. Diese ports können entweder durch das Betriebssystem, in den meisten Fällen aber Firewalls (Software und Hardware), offen (open), geschlossen (closed, im Sinne von Verweigerung der Verbindung) oder deaktiviert (blocked, also unsichtbar) werden.

Da ich keinerlei Dienste (Webserver, FTP, Streams, Filesharing, etc.) anbiete, blockiere ich per default alle Ports meines Computers.

Dies erhöht die Sicherheit des eigenen Systems wesentlich, schränkt aber, besonders bei Unkenntnis der Verfahrensweise zum Öffnen bzw. Umleiten von Ports die Funktion des Betriebssystems bzw. der Applikationen ein. Natürlich ist jeder Schutz nur so gut wie das schwächste Glied der Kette und bietet, besonders bei Angriffen durch Mithilfe von Benutzern mit Administratorenrechten (Trojaner, Spyware, etc.) und Systemschwächen, nur relative Sicherheit.

Achtung: Der Portscan eines Hostes ist zwar technisch zulässig, wird aber von vielen Personen als potentieller Angriff gewertet und ist daher bei vielen ISPs im Rahmen der AGBs verboten! Auch Webdienste müssen die Zustimmung des Inhabers des Hosts einholen.