Ping (wurde entwickelt von Mike Muuss) sendet ein ICMP Echo-Request-Paket an die Zieladresse des zu überprüfen 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, antworten Router: Network unreachable (Netzwerk nicht erreichbar) oder Host unreachable (Gegenstelle nicht erreichbar).

Traceroute ist ein TCP/IP Tool mit dem Informationen darüber ermittelt werden können, welche Computer ein Datenpaket über ein Netzwerk passiert, bis es bei einem bestimmten Host ankommt. Traceroute arbeitet üblicherweise mit dem ICMP-Teil der IP-Spezifikation, über das Rückmeldungen gegeben werden. 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 und anderen Faktoren. In Windows ist Traceroute als tracert.exe implementiert.

Aufgabenstellung war ein ping und ein traceroute zu der Adresse orf.at.

Es wurden vier kleine Datenpakete an den betreffenden Server geschickt. Im Fenster kann man sehen, ob diese (und mit welcher Antwort- zeit) ankommen oder verloren gehen. Hohe Antwortzeiten bzw. verlorene Datenpakte deuten darauf hin, daß der Server aktuell überlastet ist. Leider, zumindest für die Aufgabenstellung, kann man aus einer fehlenden Antwort 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. (Siehe: Security through Obscurity). In unserem Fall scheint das Netzwerk keinen ping von aussen zuzulassen. Es meldet zwar den Empfang, aber keine Zeiten, auch nicht zu unterschiedlichen Zeiten/Tagen.

Das Traceoute über meinen Rechner von lokaler Adresse auf orf.at war nicht möglich. Von einem onlinetool auf uta.at allerdings schon.

Um doch noch zu Messdaten zu kommen, habe ich dasselbe mit meinem Provider, aon.at, über meinen ADSL-Anschluss durchgeführt.

Ich hätte erwartet, dass das Internet, bzw. die Verbindung zu meinem Provider, am Wochenende weniger stark belastet wäre, als dies unter der Woche der Fall ist. Immerhin sind Wochentags viele Firmen online. Meine Werte ergaben aber Reaktionszeiten zu aon.at von 24 ms Wochentags bis zu 94 ms am Wochenende. Nach Rücksprache bei der Telekom Austria musste ich allerdings erfahren, dass Firmen- und Privatkunden auf getrennten Netzen bis Linz geroutet werden, und dieser Unterschied daher vollkommen normal und nachvollziehbar ist, eben weil Privatkunden vornehmlich am Wochenende online sind. Bei anderen Providern ist dies nicht der Fall da diese nicht über die notwendige Infrastruktur verfügen, bzw. aus wirtschaftlichen Gründen kein eigener Business-Backbone vorhanden ist.

Interpretation:

Ping: zeigt die generelle Verbindung zu einem Ziel-Host an, zusätzlich wird die Antwortzeit angezeigt. Die Paketgröße beträgt standardmäßig 32Byte kann aber auch verändert werden, was sich auf die Antwortzeit aber nur unwesentlich auswirkt. Anhand der Antwortzeit kann die Qualität der Verbindung ermittelt werden.

Tracert: zeigt ebenfalls die generelle Verbindung an mit der Zusatzinformation der Hops (IP-Adressen), also der Knoten welche passiert werden. Dadurch kann die Qualität der Verbindung bestimmt werden.

Um eine Verbindung mit einem Ziel-Host qualitativ bewerten zu können sind beide Befehle notwendig (Antwortzeiten und Hops). Je weniger Hops in einer Verbindung sind, umso weniger Fehlerquellen gibt es, je kürzer die Antwortzeit ist umso breitbandiger ist die Verbindung.

Vermutungen über Nicht-Erreichen der orf.at Seite über Provider Aon:

1) Der Proxy Server von Aon übernimmt die Antwortfunktion um andere server vor DoS Attacken zu Schützen.

2) Provider UTA verwented keinen Proxy Server für das Online-Tool

--------------------------------------------

Zur Identifiaktion der verschiedenen Datenströme, die z. B. aus verschiedenen Anwendungen stammen können wurden sogen. Portnummern eingeführt. Für bekannte Dienste sind Portnummern festgelegt. Eine umfangreiche Auflistung und Beschreibung findet sich auf der homepage von Richard Akermann. ( copyright_mido )

Bei einem Portscan wird auf den gewünschten Ports versucht, eine Verbindung zu dem Rechner aufzubauen und das Antwort-Verhalten des Zielsystems je nach verwendeten Protokoll interpretiert. Im Falle von TCP z.B. werden i.d.R. SYN-Pakete von dem Portscanner verschickt, ein Port, der mit einem SYN/ACK-Paket antwortet, wird als offen bezeichnet, ein Port der mit einem RST/ACK-Paket antwortet, als geschlossen und ein Port, der nicht antwortet, als gefiltert.Um auszuschliessen, das Antwort-Pakete übersehen werden, überprüfen Portscanner im letzteren Fall einen Port i.d.R. mehrfach, und passen ihren Timeout dynamisch an. Das Verfahren wird für alle zu untersuchenden Ports wiederholt, wobei um Zeit zu sparen mehrere Ports parallel geprüft werden können. (Wikipedia)

Offene Ports sind vor allem für Hacker interessant, da sie über diese auf fremde Rechner zugreifen können, diese lesen, verändern missbrauchen oder ausspionieren können. Ein Portscan meines Rechners, mit Hilfe eines Internettools (auch nicht ganz unbedenklich, also danach lieber neu einwählen, zumindest bei variabler IP-Adresse) siehe unten:

In meinem Fall sind lediglich die Ports, die ich unbedingt benötige offen, das sind die Ports 21 (FTP) und Port 80 (HTTP), was in Verbindung mit zwei Software-Firewalls eine gewisse Sicherheit gegenüber unerwünschten Zugriffen von aussen bietet. Ein beliebtes Hackerport ist Telnet, das bei meinem Rechner unwissentlich offen war und welches ich nach dem Scan geschlossen habe.