Netzwerkkommunikation oder: wie Knoten reden

Application-Layer

So. Nun sind wir durch den ganzen Protokollstapel bis ganz nach oben zum Application-Layer gewandert. Hier geht es um die konkrete Anwendung um das konkrete Programm um das, wofür der ganze eben beschriebene Aufwand überhaupt gemacht wird. Hier werden die eigentlichen Nutzdaten übertragen. Je nach Anwendung(Rechner fernwarten, Mails senden, Mails empfangen, Dateien übertragen, Chatten, Telefonieren, …) kann das natürlich sehr unterschiedlich aussehen. Viele Application-Layer-Protokolle sind für Menschen lesbar(d.h. einfache ASCII-Kommandos). Als Zeilenumbruchzeichen wird bei den meisten Protokollen 0x0D 0x0A(Carriage Return – Line Feed = CRLF; also der Windows-Standard) benutzt, jedoch sind viele Implementierungen der einzelnen Protokolle nicht so genau und akzeptieren auch nur 0x0A, jedoch kann man nicht davon ausgehen, dass das alle Implementierungen so handhaben. Linux-Nutzer sollten das bedenken…
Wir werden uns im Folgenden einzelne Protokolle ansehen und sehen wie diese funktionieren und, wie man selbst diese Protokolle „spricht“.

DNS

Port: 53 – meist UDP – RFC 1034 und 1035

Im letzten Kapitel haben wir gelernt, dass sich jeder Rechner durch eine IP-Adresse ansprechen lässt. Nun sind solche IP-Adressen zwar für den Computer eine tolle Sache, aber wer will sich schon Zahlen merken müssen, wenn er nur im Internet surfen will? Die Lösung kennen wir alle: Jeder Rechner bekommt einen mehr oder weniger aussprechbaren Namen: den Domain- oder Hostnamen. Domainnamen sind im Allgemeinen folgendermaßen aufgebaut:

1
2
3
subsubdomain.subdomain.domain.tld
bzw.
4th-level-domain.3rd-level-domain.2nd-level-domain.1st-level-domain

Dabei bedeutet tld TopLevelDomain(de, com, org, net, …) und ist gleichbedeutend mit 1st-level-domain. Ebenso ist 2nd-level-domain synonym zu Domain zu sehen. Der Begriff Subdomain wird meist für 3rd-level-domains gebraucht. Genau genommen bezeichnet „Subdomain“ aber einfach eine Domain, die „unterhalb“ einer anderen liegt. Somit wäre also z.B. bei www.example.org „www“ eine Subdomain von example.org und example eine Subdomain von „org“. Letztere Sichtweise ist aber ungebräuchlich, d.h. in diesem Falle würde man nur „www“ als Subdomain bezeichnen.

Um nun die IP-Adresse aus dem Domainnamen zu ermitteln, benutzte man ursprünglich hosts-Dateien, d.h. jeder Rechner hatte(und hat auch heute noch[7]) eine Datei namens hosts(ohne Dateiendung), in der wie in einem Telefonbuch den einzelnen Hostnamen IP-Adressen zugewiesen werden. Das Format ist ganz einfach. Zuerst wird die IP-Adresse angegeben und durch Leerzeichen davon getrennt dahinter den Hostnamen. Alles hinter einem #-Zeichen ist ein Kommentar und wird ignoriert:

1
2
127.0.0.1 localhost  # dieser Eintrag steht in jeder Hosts-Datei
# ...

Die hosts-Dateien funktionieren heute immer noch und so wurden sie zeitweise von Viren missbraucht um z.B. www.google.de auf eine Werbeseite oder die Seite einer Bank auf eine Phishing-Seite umzuleiten. Man kann die hosts-Datei aber auch sinnvoll nutzen: z.B. als Webfilter. Will man bestimmte Webseiten oder Werbebanner sperren, so leitet man diese Domains eben auf 0.0.0.0 um[8]…

Als die Netzwerke immer größer wurden und schließlich das Internet entstand, war es kaum noch möglich alles über hosts-Dateien zu erledigen. Wollte man heute noch alle alle Hostnamen in der hosts-Datei speichern, so wäre diese mehrere GB groß. Ein neues System musste her: DNS, das Domain Name System.
Das Internet ist nun in einzelne Zonen unterteilt, die den TLDs entsprechen. Und diese sind wiederum weiter unterteilt. Jede Zone hat einen oder mehrere Nameserver, der eine Datenbank für diese Zone verwaltet und auf Anfrage entweder gleich die gesuchte IP oder zumindest einen weiteren Nameserver mit genaueren Infos nennen kann. 13 root-Name-Server verwalten die Nameserver der TLDs, diese wiederum kennen Nameserver für einzelne Domains, die wiederum Nameserver für Subdomains haben können[9].
Möchte man einen Domainnamen zu einer IP-Adresse auflösen, so sendet der DNS-Client eine DNS-Anfrage(normalerweise per UDP) an einen DNS-Server(meist zuerst an einen vom jeweiligen Provider). Kann dieser die Anfrage beantworten, sendet er ein Antwort-Paket an den Client. Wenn nicht gibt es zwei Möglichkeiten: Entweder er fragt selbst weiter andere Nameserver(rekursive Methode), die wieder andere befragen können oder er sendet die IP eines anderen Nameservers, den der Client als nächstes befragt(iterative Methode).

Mit dem Kommandozeilen-Tool nslookup kann man auch DNS-Anfragen selbst stellen. Beispiel:

1
2
3
4
5
6
7
~$ nslookup www.wikipedia.de
Server:         192.168.0.1
Address:        192.168.0.1#53

Non-authoritative answer:
Name:   www.wikipedia.de
Address: 80.67.25.148

Telnet

normalerweise: Port 23 – TCP – RFC 854

Das zweite vorgestellte Application-Layer-Protokoll ist wohl mittlerweile eines der unwichtigeren. Telnet(TeletypeNetwork) diente einmal dazu sich auf entfernten Rechnern einzuloggen und wurde auch rege genutzt. Da bei Telnet aber alles im Klartext übertragen wird, es also mit der Sicherheit in etwa so gut bestellt ist, wie mit einer Postkarte, sollte man Telnet nicht mehr verwenden. Stattdessen benutzt man heute für diese Zwecke SSH(Secure Shell), das eine verschlüsselte Verbindung bereitstellt. Trotzdem kann man mit Telnet auch heute noch lustige Sachen machen und so Application-Layer-Protokolle besser verstehen, weshalb Telnet hier zumindest nicht ganz untergehen soll. Für das, was wir im Folgenden tun werden eignet sich auch das Tool Netcat, das Schweizer Taschenmesser für TCP/IP. Allerdings ist dessen Benutzung für unsere Zwecke etwas unhandlich, weshalb wir stattdessen Telnet „missbrauchen“. Netcat ist trotzdem einen Blick wert, da man damit noch viel mehr machen kann.

Ein Telnet-Client ist bei jeder Standard-Installation von Windows und Linux dabei. Beides sind Kommandozeilenprogramme und funktionieren ganz ähnlich. So baut man eine Verbindung zu einem Rechner über einen bestimmten Port auf:
~$telnet <Rechner> <Port>
„~$“ steht hier für den Kommandozeilen-Prompt, also unter Windows „C:\>“ und unter Linux „user@host:/~$“ oder ähnlich.
Dadurch wird Telnet aufgerufen und die Verbindung aufgebaut.

Jetzt kann man munter darauflos tippen und Befehle eingeben.
Arbeitet man unter Windows hat man u.U. dabei ein Problem: Der mitgelieferte Telnet-Client ist – zumindest unter XP – scheinbar „etwas“ buggy: Man muss blind tippen. Alles vor der ersten Antwort der Gegenstelle bleibt unsichtbar. Das hängt wohl damit zusammen, dass wir hier Telnet etwas zweckentfremden(weiteres hierzu siehe unten).
Unter Vista ist zudem der Telnet-Client zu Anfang noch deaktiviert. Wie man das ändert, kann man aber leicht ergooglen.

Als Alternative zum Windows-Telnet bietet sich PuTTY[10] an(oder natürlich Linux[11] ;-)). Nach dem Download der PuTTY.exe, diese einfach starten und im erscheinende Fenster folgendes einstellen:
Unter „Host-Name (or IP address)“ den Rechnernamen, unter „Connection Type“ „Raw“, unter „Port“ den gewünschten Port und unter „Close window on exit“ „Never“.

PuTTY für "Telnet über Port 80"

Beim Klick auf „Open“ wird nun auch hier eine Verbindung aufgebaut. Und, was wir damit schönes anstellen können, gucken wir uns auch gleich an…

HTTP

Port: 80 – TCP – RFC 2616

Das Hypertext Transfer Protocol dient dazu, Webseiten und deren Inhalt(Grafiken, etc.) von einem Webserver herunterzuladen. und das probieren wir am besten auch gleich einmal aus:
Wir öffnen eine Telnet-Verbindung wie oben beschrieben zu einer beliebigen Webseite bzw. eigentlich: zu einem beliebigen Webserver: z.B. www.wikipedia.de über Port 80. Dann senden wir folgendes:

1
2
GET / HTTP/1.1
Host: www.wikipedia.de

Die Anfrage schließen wir mit einer leeren Zeile ab.
Das weist den Webserver, der dort(d.h. auf dem Rechner, mit dem wir uns verbunden haben) läuft, uns den Inhalt der Webseite www.wikipedia.de und zwar die Hauptseite(/) zu senden.
Als Antwort erhalten wir folgendes:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
HTTP/1.1 200 OK
Date: Sat, 22 Dec 2007 09:38:58 GMT
Server: Apache/1.3 (Unix) mod_ssl/2.8.28 OpenSSL/0.9.8f AuthPG/1.3 FrontPage/5.0.2.2635
X-Powered-By: PHP/5.2.4
Set-Cookie: cookies=1
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html

3be
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
        "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="de" lang="de">
<head>
        <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
        <title>wikipedia.de - Wikipedia, die freie Enzyklopädie</title>
        <link rel="stylesheet" media="screen" type="text/css" href="style.css" />
        <script language="JavaScript" type="text/javascript" src="suggest.js"></script>
</head>

<body
[...]
</body>
</html>
0

Connection closed by foreign host.

Ganz oben sehen wir den HTTP-Header:

1
2
3
4
5
6
7
8
HTTP/1.1 200 OK
Date: Sat, 22 Dec 2007 09:38:58 GMT
Server: Apache/1.3 (Unix) mod_ssl/2.8.28 OpenSSL/0.9.8f AuthPG/1.3 FrontPage/5.0.2.2635
X-Powered-By: PHP/5.2.4
Set-Cookie: cookies=1
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html

Hier erhalten wir nähere Infos über die abgerufene Seite:

  • zuerst einmal einen Status-Code. in diesem Fall: 200 OK; möglich wäre aber auch 404, wenn die Seite nicht gefunden wurde oder andere. Eine Liste mit den möglichen Status-Codes findet sich ebenfalls in die Wikipedia: http://de.wikipedia.org/wiki/HTTP-Statuscode
  • das aktuelle Datum des Webservers
  • Daten über die verwendete Serversoftware
  • Cookies
  • Das Feld „Content-Type“ gibt den Content bzw. MIME-Type der übertragenen Daten an. Damit weiß dann ber Browser, wie er die Daten interpretieren soll(als HTML, als reinen Text, als Bild, als Binärdetei(zum Download), …)

Der Header kann auch noch weitere Informationen enthalten.

Nach dem Header folgt durch eine Leerzeile getrennt der eigentliche Inhalt der angeforderten Seite

Wenn wir jetzt nur am Header interessiert sind, senden wir statt GET eine HEAD-Anfrage:

1
2
HEAD / HTTP/1.1
Host: www.wikipedia.de

Wollen wir eine andere HTML-Seite oder eine Grafik laden, müssen wir nur dem Pfad anpassen:

1
2
GET /about HTTP/1.1
Host: www.wikipedia.de

Genau das sendet der Browser, wenn wir die Seite http://www.wikipedia.de/about aufrufen. Prinzipiell ist eine HTTP-Abfrage also folgendermaßen aufgebaut:

1
2
3
4
<methode> <url> HTTP/1.1
Host: <host>
<weitere Header-Daten>
<leere Zeile>

Die Methode kann GET, HEAD oder POST(es gibt auch noch andere. Diese sind aber irrelevant) sein. HEAD liefert dabei nur den HTTP-Header, GET die ganze Datei und überträgt Daten(z.B. aus Formularen) in der URL im so genannten GET-String[12] und POST überträgt Daten separat im Body der Abfrage, d.h. durch eine Leerzeile vom Header getrennt.
Die URL ist dabei die, die normalerweise in der Adresszeile des Browsers steht: mit eventuellem GET-String, etc. aber ohne http:// und ohne Domain.

Wie wir aber feststellen müssen, wird die Verbindung nach jeder Übertragung automatisch wieder abgebaut. Das ist natürlich nicht besonders performant – insbesondere, wenn wir z.B. eine Seite mit vielen Bildern aufrufen wollen. Aber auch hierfür gibt es eine Lösung: Persistente Verbindungen. Die Verbindung wird so lange offen gehalten, bis einer der beiden Kommunikationspartner(Server oder Client) in seinem Header ein Feld „Connection: Close“ einfügt. Je nach Server und Seite kann es aber auch sein, dass gleich bei der ersten Antwort dieses Feld gesetzt wird und damit abgebrochen wird. Bei der Wikipedia ist dies schonmal der Fall. Eine Möglichkeit dem entgegenzuwirken ist explizit anzugeben, dass man persistente Verbindungen haben möchte(Connection: keep-alive). Dies kann aber auch einfach ignoriert werden.

Versuchen wir nun statt Wikipedia z.B. bei Google eine Seite herunter zu laden, wird die Verbindung u.U. schon getrennt, wenn wir noch gar nicht fertig getippt haben. Das hängt damit zusammen, dass Webserver unterschiedlich geduldig sind. Und der Google-Server ist eben ziemlich ungeduldig. Man muss schon ziemlich schnell tippen, damit die Verbindung nicht getrennt wird, bevor man seine Anfrage senden konnte. Im Normalfall ist das aber kein Problem, da das alles ja eigentlich der Browser macht und dieser die Anfrage entsprechend schnell sendet.

E-Mail

RFC 2822

Bevor wir uns weitere Protokolle ansehen, sei noch etwas zu E-Mails gesagt. Auch diese sind nämlich genormt. Effektiv sind E-Mails nichts anderes als ein ASCII-Text. Wie so eine E-Mail im Quelltext aussieht, kann man sich in manchen E-Mail-Programmen(z.B. mit Thunderbird) anzeigen lassen. Kurz gesagt besteht eine E-Mail aus einem Header und einem Body, die durch eine Leerzeile getrennt sind. Im Header stehen Absender, Empfänger ggf. weitere Empfänger, der Betreff, das Absendedatum und weitere Angaben. Unter anderem verewigt sich auch jeder Server, der die Mail zwischendurch in den Händen hatte, Im Mail-Header in den so genannten Received-Zeilen. Das hat folgenden Grund: Wenn eine Mail aus Platzgründen nicht mehr gespeichert werden kann, wird sie einfach – bereichert um eine Fehlermeldung – zum vorherigen Server zurückgesendet. Hat dieser nun auch keinen Platz, würde der sie ja auch wieder zurückschicken und die Mail würde wachsen und wachsen und immer wieder zwischen den beiden Servern hin- und herpendeln, bis das Netz irgendwann zusammenbricht. Deshalb schauen die Server einfach nach, ob sie diese Mail schonmal hatten(dann ist ja eine entsprechende Zeile im Header vorhanden), und, wenn dies der Fall ist, wird die Mail einfach gelöscht.
Näheres zum Aufbau des Mail-Headers findet sich in der Wikipedia: http://de.wikipedia.org/wiki/Header_(E-Mail)

SMTP

Port: 25 – TCP – RFC 821

Das Simple Mail Transfer Protocol ist ein sehr altes Protokoll. In den Anfangszeiten des Internets, noch lange bevor man überhaupt an so etwas, wie WWW gedacht hat, fand man es sinnvoll, kurze Textnachrichten versenden zu können. Daraus entstand SMTP. Und genau so, wie es heißt ist es auch: Es versendet einfach Mails. Authentifizierung, Verschlüsselung, etc. waren erstmal nicht vorgesehen, was Spamming natürlich Tür und Tor öffnete, aber zu der Zeit, als SMTP entwickelt wurde[13], konnte man sich noch gar nicht vorstellen, dass es einmal so viele Internetnutzer, so viele Mails und so etwas wie Spam geben würde. Mit der Zeit wurde SMTP an den verschiedensten Stellen erweitert, sodass es heute auch Authentifizierung, Verschlüsselung, Versand von Anhängen, HTML-Mails und anderes gibt. Das Grundgerüst bildet aber immer noch SMTP bzw. ESMTP(Extended SMTP; für die Authentifizierung) und so kann man auch heute noch recht einfach Mails per Hand schreiben. Wie das geht, sehen wir uns jetzt einmal an:
Wir öffnen wieder eine Telnet-Verbindung. Diesmal zu einem SMTP-Server auf Port 25.
~$ telnet smtp.example.org 25
Zuerst begrüßen wir den Mailserver und nennen unseren Namen. Der Mailclient wird als Namen meist die eigene IP verwenden. Effektiv ist es aber egal, was hier steht:
HELO Alice
Das heißt so viel wie „Hallo, ich bin Alice“. Als Antwort erhält man:
250 smtp.example.org pleased to meet you
Diese Phrasen wie „pleased to meet you“ senden wirklich manche SMTP-Server.

Als Alternative zu HELO gibt es noch EHLO(Extended HELO). Dieser Befehl macht eigentlich genau das selbe, nur sendet der SMTP-Server noch Daten darüber, welche Authentifizierungsmethoden(nach ESMTP) er kennt. Da es kaum noch Mailserver gibt, die keine Authentifizierung verlangen, müssen wir uns erstmal authentifizieren:
AUTH LOGIN
Es gibt noch weitere Authentifizierungsmethoden, diese ist aber die einfachste und soll zur Demonstration erstmal reichen.
334 VXNlcm5hbWU6
Was heißt denn das? Ganz einfach: Das heißt „Username:“… Base64-Kodiert. Base64 ist keine Verschlüsselung, sondern nur eine Kodierung. Man kann das also recht einfach kodieren und dekodieren. Unseren Benutzernamen müssen wir nun auch Base64-Kodiert übertragen. Wer das nicht per Hand machen will, kann sich das entweder recht einfach selbst programmieren, soder greift auf etwas Fertiges zurück: base64 Kodierer/Dekodierer
Genau das selbe passiert mit dem Passwort. Im Ganzen also:

1
2
3
4
5
334 VXNlcm5hbWU6
YWxpY2U=
334 UGFzc3dvcmQ6
bWVpbl9zdHJlbmdfZ2VoZWltZXNfcGFzc3dvcnQ=
235 authentication finished successfully

Dabei sehen wir schon: Benutzername und Passwort werden mehr oder weniger im Klartext übertragen. Deshalb sollte man nach Möglichkeit in seinem E-Mail-Client SSL- oder TSL-Verschlüsselung aktivieren.

Als nächstes geben wir Absender und Empfänger an:

1
2
3
4
MAIL FROM: alice@example.org
250 mail from: <alice@example.org> ok
RCPT TO: bob@example.org
250 <bob@example.org> ok

Jetzt können wir auch unsere Mail schreiben:

1
2
3
4
5
6
7
8
9
DATA
354 Enter mail, end with "." on a line by itself
From: bill.gates@microsoft.com
To: hans@wurst.de
Subject: Test        

Das ist ein Test.
.
250 Message 0MKxQS-1J6orY15tX-0006je accepted by smtp.example.org

Was machen wir hier? Zuerst schreiben wir den Mail-Header. Dort steht der Betreff(Subject) und nochmal Absender und Empfänger. Das ist das, was der User in seinem Mail-Programm zu Gesicht bekommt. Wie wir sehen, kann das auch von dem Abweichen, was wir oben als tatsächlichen Absender und Empfänger eingetragen haben. Das ist auch der Grund, warum es Spammer so leicht haben: Die Header sind sehr einfach zu manipulieren[14].
Im Header kann noch eine ganze Menge weiterer Informationen stehen: CC-, BCC- und Reply-To-Adressen, Datum, Mail-Client, etc. Siehe hierzu: Wiipedia – Mail-Header

Um die Verbindung nun ordnungsgemäß zu trennen, senden wir ein einfaches QUIT. Wir werden dann noch kurz verabschiedet und der Server trennt die Verbindung:

1
2
3
QUIT
221 smtp.example.org Bye
Connection closed by foreign host.

POP3

Port: 110 – TCP – RFC 1939

POP3 ist ähnlich einfach, wie SMTP. Eher sogar noch einfacher, da kein Base64 benötigt wird. Hier eine kurze Beispielsitzung:

1
2
3
4
5
6
~$ telnet pop.example.org 110
+OK POP server ready H mimap22
USER bob
+OK password required for user "bob"
PASS kriegtKeinerRaus
+OK mailbox "bop" has 1 messages (1269 octets) H mimap22 N

Man sieht: Auch hier wird per Default das Passwort unverschlüsselt übertragen.

Statistik anzeigen

1
2
STAT
+OK 1 1269

Eine Mail mit 1269 Bytes.

Ausführlich auflisten, was da ist:

1
2
3
4
LIST
+OK 1 messages (1269 octets)
1 1269
.

Mail mit der ID 1 abholen:

1
2
3
4
5
6
7
8
RETR 1
+OK 1269 octets
Return-Path: <alice@example.org>
Delivery-Date: Wed, 26 Dec 2007 15:29:05 +0100
[...]

test
.

Mail mit der ID 1, die wir gerade abgeholt haben, vom Server löschen:

1
2
DELE 1
+OK message deleted

Is auch wirklich nix mehr da?

1
2
3
4
5
LIST
+OK 0 messages (0 octets)
.
STAT
+OK 0 0

Verbindung trennen:

1
2
3
QUIT
+OK POP server signing off
Connection closed by foreign host.

Wir sehen: POP3 ist ebenfalls ein sehr einfaches Protokoll. Zu einfach, wie manche finden, denn manches ist damit nicht realisierbar(Organisation der Mails auf dem Server in Ordnern, etc.). Um dies auszugleichen wurde IMAP entwickelt.

FTP

Port: 21 und 20 für Daten – TCP – RFC 959

Das File Transfer Protokoll(FTP) bietet die Möglichkeit Dateien mit FTP-Servern auszutauschen. Dies ist z.B. dann sinnvoll, wenn man die Dateien einer Website hochladen will. Andererseits wird FTP auch zum Download benutzt. So bieten einige Seiten Ihre Downloads nicht nur als HTTP-Download sondern auch(oder ausschließlich) über FTP. Für letzteren Zweck sind die FTP-Server so eingerichtet, dass die anonyme Benutzer(meist mit dem Benutzernamen anonymous) ohne Passwort(bzw. mit Dummy-Passwort) erlauben.

Da FTP ganz ähnlich funktioniert, wie die bisher vorgestellten Protokolle, hier nur eine Auflistung der wichtigsten Kommandos(den Rest findet man recht leicht im RFC) und der Besonderheiten:

  • USER – legt den Usernamen fest
  • PASS – gibt das Passwort im Klartext an(hier gilt das selbe, wie oben für SMTP bzw. POP3)
  • PWD – gibt das aktuelle Verzeichnis aus
  • CWD ändert das aktuelle Verzeichnis
  • LIST – listet den Verzeichnisinhalt auf
  • RETR – lädt eine Datei herunter
  • STOR – lädt eine Datei hoch

Um Dateien hoch oder herunterzuladen wird bei FTP eine zweite TCP-Verbindung aufgebaut. Dafür gibt es zwei Möglichkeiten: aktiv oder passiv. Beim aktiven FTP baut der Server eine Verbindung zum Client auf und beim passiven umgekehrt. Passiv ist sicherer und deshalb zu bevorzugen. Das funktioniert so:
– der Client sendet „PASSV“
– der Server öffnet einen Port und teilt dem Client mit welchen(es werden IP und Port gesendet, jeweils byteweise durch Komma getrennt. Da der Port aus 2Bytes gesteht, muss man diesen hinterher noch zusammenbasteln.[15])
– der Client verbindet zu diesem Port
– über diese neue Verbindung werden die Daten ausgetauscht

Eine weitere Besonderheit: es gibt verschiedene Übertragungsmodi: ASCII(A) und Binary(I)[16]. Der Unterschied ist, dass bei Übertragung im ASCII-Mode systemspezifische Änderungen an den Daten vorgenommen werden(Zeilenumbruchzeichen werden angepasst[17], etc.)
Das Kommando „TYPE A“ bzw. „TYPE I“ wechselt zwischen den einzelnen Modi.

[7] die hosts Datei befindet sich unter Linux in /etc und unter Windows normalerweise in C:\Windows\System32\Drivers\Etc oder direkt unter C:\Windows
[8] Dies scheint allerdings nicht in allen Fällen problemlos zu funktionieren.
[9] Subdomains können hier aber auch anders realisiert werden, z.B. über den Webserver.
[10] PuTTY kann auch noch mehr als richtiges und Pseudo-Telnet: nämlich SSH
[11] eine weitere Alternative wäre netcat. Netcat ist bei Linux oft schon standardmäßig installiert und es gibt auch Windows-Implementierungen. Allerdings erkennen manche Virenscanner netcat als „Hacker-Tool“.
[12] Das sind die Daten, die URLs angehängt werden können. Sie sind durch ein ‚?‘ von der eigentlichen URL getrennt.
[13] Einen Vorläufer von SMTP, das Mail Box Protokoll, gab es schon Anfang der 70er Jahre. SMTP selbst wurde 1982 entwickelt.
[14] was nicht heißt, dass man den wahren Absender nicht ermitteln könnte. Er wird nur von den meisten Mailprogrammen nicht angezeigt.
[15] Dazu das erste Byte um 8 nach links schieben(d.h. mit 256 multiplizieren) und das zweite Byte addieren(bzw. mit OR verknüpfen).
[16] Windows verwendet hier 0x0D 0x0A, Unixartige Systeme nur 0x0A und Macs 0x0D
[17] Es gibt auch noch andere Modi. Diese sind aber weniger wichtig.

Kapitel: | Zurück | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | Weiter |

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert