===================> Hitchhiker's Guide to the Internet ===================> Eine Einführung in die Internettechniken ===================> von Ingo Blechschmidt[fuß: veröffentlicht unter der GNU General Public License, Version 2 oder höher] ===================> Version 2139 : -scale:95 cover : +-------+ : |Daemons| : +-------+ : ^ : | : v : +-----------------+ : | | : +------+ | | +------+ : |Client|<->|B L A C K B O X|<->|Server| : +------+ | | +------+ : | | : +-----------------+ : ^ : | : v : +-------+ : |Routing| : +-------+ [grafik: cover] |-- Einleitung . . . . . . . . . . . . .0151 | |-- Schreibkonventionen . . . . . . . . .0167 | `-- Wishlist . . . . . . . . . . . . .0182 |-- Grundlagen . . . . . . . . . . . . .0192 | |-- Das OSI-Schichtenmodell . . . . . . . .0199 | |-- IP . . . . . . . . . . . . . .0232 | |-- TCP . . . . . . . . . . . . .0255 | |-- UDP . . . . . . . . . . . . .0311 | |-- ICMP . . . . . . . . . . . . . .0324 | |-- Routing . . . . . . . . . . . .0351 | | |-- TTL . . . . . . . . . . . .0395 | | `-- Traceroute . . . . . . . . . . .0442 | `-- Abschluss . . . . . . . . . . . .0471 |-- E-Mails . . . . . . . . . . . . .0486 | |-- Syntax . . . . . . . . . . . . .0496 | |-- Typische Header . . . . . . . . . .0503 | | `-- SMTP-Server-Stempel . . . . . . . .0525 | |-- MIME-Typen . . . . . . . . . . . .0540 | `-- Abschluss . . . . . . . . . . . .0563 |-- SMTP . . . . . . . . . . . . . . .0570 | |-- Grundlegendes . . . . . . . . . . .0589 | |-- Idee . . . . . . . . . . . . . .0609 | |-- Typischer Ablauf . . . . . . . . . . .0638 | |-- Beispiel . . . . . . . . . . . . .0736 | |-- Übersicht aller Befehle . . . . . . . .0771 | `-- Abschluss . . . . . . . . . . . .0783 |-- POP3 . . . . . . . . . . . . . . .0792 | |-- Grundlegendes . . . . . . . . . . .0802 | |-- Typische POP3-Sitzung . . . . . . . . .0813 | |-- Übersicht aller Befehle . . . . . . . .0909 | `-- Abschluss . . . . . . . . . . . .0921 |-- IMAP4 . . . . . . . . . . . . . .0927 | |-- Technische Implementierung . . . . . . . .0940 | |-- Übersicht aller Befehle . . . . . . . .1025 | `-- Abschluss . . . . . . . . . . . .1039 |-- NNTP . . . . . . . . . . . . . . .1089 | |-- Technik . . . . . . . . . . . .1106 | |-- Beispielsitzung . . . . . . . . . .1119 | | `-- Zusammenfassung . . . . . . . . .1223 | |-- Besondere Header . . . . . . . . . . .1275 | | |-- Newsgroups . . . . . . . . . . .1281 | | |-- Followup-To . . . . . . . . . .1290 | | |-- Approved . . . . . . . . . . . .1303 | | `-- Control . . . . . . . . . . .1311 | |-- Austausch zwischen den Servern . . . . . . .1331 | |-- Übersicht aller Befehle . . . . . . . .1361 | `-- Abschluss . . . . . . . . . . . .1377 |-- HTTP . . . . . . . . . . . . . . .1439 | |-- Versionen . . . . . . . . . . . .1449 | |-- Adressen . . . . . . . . . . . . .1467 | |-- HTTP/1.0 . . . . . . . . . . . . .1489 | |-- HTTP/1.1 . . . . . . . . . . . . .1524 | |-- HTTP-Proxies . . . . . . . . . . . .1545 | |-- Überblick . . . . . . . . . . . .1574 | |-- Referer . . . . . . . . . . . .1584 | |-- TRACE-Request . . . . . . . . . . .1613 | |-- User-Agent . . . . . . . . . . . .1641 | |-- Accept-Language . . . . . . . . . .1662 | |-- Keep-Alive . . . . . . . . . . . .1683 | | `-- Chunked-Encoding . . . . . . . . . .1720 | |-- Partial Content . . . . . . . . . .1749 | |-- Cookies . . . . . . . . . . . .1779 | |-- Formulare . . . . . . . . . . . .1853 | | |-- GET-Request . . . . . . . . . .1871 | | `-- POST-Request . . . . . . . . . . .1902 | |-- Weiterleitung . . . . . . . . . . .1940 | |-- HEAD-Request . . . . . . . . . . . .1973 | `-- Übersicht aller Befehle . . . . . . . .1988 |-- Gopher . . . . . . . . . . . . . .2038 | |-- Idee . . . . . . . . . . . . . .2046 | |-- Technik . . . . . . . . . . . .2054 | |-- Beispielsitzung . . . . . . . . . .2077 | `-- Abschluss . . . . . . . . . . . .2114 |-- FTP . . . . . . . . . . . . . .2122 | |-- Idee . . . . . . . . . . . . . .2129 | |-- Passives FTP . . . . . . . . . . . .2165 | |-- Aktives FTP . . . . . . . . . . .2248 | |-- Übersicht aller Befehle . . . . . . . .2325 | |-- Goodies . . . . . . . . . . . .2348 | | |-- Übertragung zwischen zwei Servern . . . . .2357 | | `-- Application-Level-Proxy . . . . . . .2405 | `-- Abschluss . . . . . . . . . . . .2433 |-- IRC . . . . . . . . . . . . . .2443 | |-- Idee . . . . . . . . . . . . . .2451 | |-- Beispielsitzung . . . . . . . . . .2486 | `-- Übersicht aller Befehle . . . . . . . .2543 |-- DICT . . . . . . . . . . . . . . .2559 | |-- Idee . . . . . . . . . . . . . .2568 | |-- Beispielsitzung . . . . . . . . . .2577 | `-- Übersicht aller Befehle . . . . . . . .2666 |-- Finger . . . . . . . . . . . . . .2675 | |-- Idee . . . . . . . . . . . . . .2683 | `-- Beispielsitzung . . . . . . . . . .2709 |-- IDENT . . . . . . . . . . . . . .2745 | |-- Technische Realisierung . . . . . . . .2756 | `-- Anwendungsmöglichkeiten . . . . . . . .2786 |-- Daytime . . . . . . . . . . . . .2798 | `-- Technische Umsetzung . . . . . . . . . .2811 |-- DNS . . . . . . . . . . . . . .2832 | |-- Historie . . . . . . . . . . . . .2842 | |-- Idee . . . . . . . . . . . . . .2861 | |-- Vor- und Nachteile . . . . . . . . . .2900 | |-- Record-Typen . . . . . . . . . . . .2919 | |-- Ausfallsicherung . . . . . . . . . . .2946 | |-- MX-Records . . . . . . . . . . . .3054 | |-- Reverse-Lookups . . . . . . . . . .3109 | `-- Whois . . . . . . . . . . . . .3134 |-- Muhahaha -- oder: Automatisierung . . . . . . .3206 | |-- Whois . . . . . . . . . . . . .3213 | |-- Daytime . . . . . . . . . . . .3259 | |-- HTTP . . . . . . . . . . . . . .3277 | | `-- Lynx . . . . . . . . . . . . .3286 | |-- curl . . . . . . . . . . . . . .3349 | | |-- Standardsyntax . . . . . . . . . .3357 | | |-- GET-Requests . . . . . . . . . . .3388 | | `-- POST-Requests . . . . . . . . . .3394 Einleitung ========== In diesem Dokument werden die verschiedenen Internetprotokolle (sowohl Low-Level als auch Application-Level) vorgestellt, so dass man nach Studieren dieser Datei (welche man im übrigen auch in einem beliebigen ASCII-Viewer betrachten kann) in der Lage ist, nur via Telnet zu surfen, Mails zu verschicken und empfangen, usw. Geschrieben wurde dieses Dokument mit GenuineWord (programmiert vom Autor), einem Präprozessor für LaTeX, der vor allem bei einfachen ASCII-Schemata seine Stärken ausspielt. Über jegliche Kommentare und Ergänzungen würde ich[fuß: Ingo Blechschmidt, <>] mich sehr freuen. Schreibkonventionen ------------------- Einzelne Befehle oder Programme werden im Fließtext <> gedruckt. | Listings | Dies ist die erste Zeile. \ | Dies ist immer noch die erste Zeile, musste aber \ | aus Platzgründen mit einem "\" umgebrochen werden. hingegen bekommen immer einen extra Absatz. Leerzeichen in Listings werden immer wie ein kleines "u" gezeigt. Ein Dialog, etwa zwischen Server und Client, wird wiefolgt dargestellt: | >Client (Anfrage) | Das vereinfachte OSI-Schichtenmodell]). Je weiter "oben" ein Protokoll liegt, so abstrakter ist es. Mit diesen Protokollen werden wir uns am meisten beschäftigen. "Unten" liegt zum Beispiel die physische Schicht: Das entspräche praktisch dem Netzwerkkabel. Da uns aber nur die Software interessiert, wird hier darauf nicht eingegangen werden. : schichten : +-----------+ : |Application| : | Level | : +-----------+ : | Transport | : | Level | : +-----------+ : | Physical | : | Level | : +-----------+ Auf der Transportschicht ist das Protokoll IP[fuß: _Internet Protocol_] angesiedelt. IP ist für die grundlegende Kommunikation aller Rechner im Internet zuständig. Eine Schicht höher (nicht abgebildet) liegt TCP[fuß: _Transport Control Protocol_]. Dieses Protokoll sorgt dafür, dass die mit IP versendeten Pakete am Ziel auch ankommen. Auf der Anwendungsebene schließlich sind alle "hohen" Protokolle angesiedelt, namentlich SMTP, POP3, HTTP und NNTP, denen je ein einzelnes Kapitel gewidment ist. IP -- Heute sorgt für die Kommunikationsfähigkeit aller Knoten im Internet die Version 4 des IP. IPv4 adressiert alle Rechner mit Hilfe eines vier Byte langen "Words", untergliedert in vier Zahlen mit je einem Byte. Was sich hier etwas kompliziert anhört ist ganz einfach: <<66.35.250.209>> ist zum Beispiel eine gültige IP-Adresse. Jede Zahl darf (wegen der 1-Byte-pro-Zahl-Grenze) maximal 255 (die 0 wird mit einbezogen) betragen. Besondere IP-Adressen sind solche, die * mit <<.0>> enden. Diese IP-Adressen definieren ein ganzes Subnetz. So definiert <<10.0.0.0>> zum Beispiel ein Subnetz, mit dem alle Rechner, dessen IP-Adressen mit <<10.>> beginnen, gemeint sind. * Außerdem sind IP-Adressen, die auf <<.255>> enden besonders: Diese repräsentieren das gesamte Subnetz. Schickt man zum Beispiel einen Ping (siehe [ref: ping]) an eine solche Adresse, "pongen" alle anderen Rechner des Subnetzes zurück. Jedes Paket wird auch mit einer TTL versehen, mehr dazu [ref: ttl]. TCP --- Ein gravierender Nachteil von IP ist allerdings die mangelnde Fehlertoleranz: Ist Netzlast hoch, kommen viele Pakete[fuß: IP unterteilt Sendedaten in Pakete] nicht am Ziel an. Deswegen wurde ein weiteres Protokoll entworfen, TCP. TCP sorgt dafür, dass die via "normalem" IP versendeten Pakete auch am Ziel ankommen. Dies erreicht TCP vereinfacht gesagt dadurch, dass es die Pakete nummeriert. Kommt dann ein Paket am Ziel nicht an, fordert der Zielrechner es erneut. Auch ergänzt TCP IP um sogenannte Ports: Auf jedem der insgesammt $2^{16}$ Ports (0 bis 65535) kann ein eigener Dienst (HTTP, SMTP, POP3, IMAP, DNS, etc.) "lauschen". Dadurch erst wird die Dienstevielfalt des Internets möglich. Um zu einem TCP Port eines Hosts zu connecten, benutzt man unter guten System (Linux, Hurd) den Kommandozeilenbefehl <> (siehe Screenshot [shot: telnet ==> Telnet]). Um also zu Port <> des Hosts <> zu connecten, gibt man ein: | telnet Y X [startshot: telnet] iblech@thestars iblech $ telnet mars 13 Trying 10.0.0.4... Connected to mars. Escape character is '^]'. Thu Jul 17 16:29:42 2003 Connection closed by foreign host. iblech@thestars iblech $ [endshot] [label: portscan]Will man eine Übersicht der offenen Ports (Ports, an denen ein Dienst lauscht) haben, verwendet man einen Portscanner. Portscanner verbinden sich praktisch mit jedem möglichen Port des Zielsystems. Wird die Verbindung aufgebaut, ist der Port offen und kann angezeigt werden. Ein guter Portscanner unter Linux und anderen Unix-basierten Systemen ist <> (siehe Screenshot [shot: nmap ==> Nmap]). [startshot: nmap] iblech@thestars genuineng $ nmap thestars Starting nmap 3.27 ( www.insecure.org/nmap/ ) at 2003-07-17 17:20 CEST Interesting ports on thestars.gnus (10.0.0.3): (The 1619 ports scanned but not shown below are in state: closed) Port State Service 22/tcp open ssh 53/tcp open domain 113/tcp open auth 6000/tcp open X11 Nmap run completed -- 1 IP address (1 host up) scanned in 0.451 seconds iblech@thestars genuineng $ [endshot] UDP --- UDP ergänzt IP lediglich um die schon von TCP bekannten Ports, nicht aber um die Fehlertoleranz. UDP kommt zum Beispiel bei der Übertragung von Audio- und Video-Streams zum Einsatz, da dort zum einen die häufige Neu-Übertragung von Paketen, was natürlich die verfürbare Bandbreite noch weiter schmälert, fehlt. Dies ist allerdings bei solchen Übertragungen nicht wichtig: Fehlt ein Frame, kommt schon sehr schnell der nächste. Dieses Fehlen ist dann nur als Knacken zu hören bzw. als kurze Pause zu sehen. ICMP ---- ICMP wird[fuß: von einigen kryptographischen Zwecken einmal abgesehen...] nur zur Statusübertragung für TCP/UDP/IP eingesetzt, zum Beispiel ob der Zielhost existiert, eine Route verfügbar ist usw. [label: ping]Über ICMP werden auch sogennannte "Pings" übertragen. Pings sind kleine Pakete, die, am Zielrechner angekommen, von diesem sofort zurückgeschickt werden. So kann man die Erreichbarkeit von Hosts testen (siehe Screenshot [shot: ping ==> Ping]). [startshot: ping] iblech@thestars iblech $ ping mars PING mars.gnus (10.0.0.4) 56(84) bytes of data. 64 bytes from mars.gnus (10.0.0.4): icmp_seq=1 ttl=255 time=0.173 ms 64 bytes from mars.gnus (10.0.0.4): icmp_seq=2 ttl=255 time=0.175 ms 64 bytes from mars.gnus (10.0.0.4): icmp_seq=3 ttl=255 time=0.176 ms 64 bytes from mars.gnus (10.0.0.4): icmp_seq=4 ttl=255 time=0.175 ms 64 bytes from mars.gnus (10.0.0.4): icmp_seq=5 ttl=255 time=0.181 ms --- mars.gnus ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4008ms rtt min/avg/max/mdev = 0.173/0.176/0.181/0.002 ms iblech@thestars iblech $ [endshot] Routing ------- Eine Frage blieb bisher ganz unbeantwortet: Wie werden die Pakete nun eigentlich von Rechner <> nach <> transportiert, wenn keine direkte Leitung zum Ziel vorhanden ist? Um nicht jeden Computer des Internet mit jedem anderem Computer zu vernetzen, benutzt man sogenannte _Router_. Das Bild [grafik: router ==> Route von A nach B] veranschaulicht dies. Jeder Rechner besitzt[fuß: heutzutage sind die Routing-Tabellen dynamisch, aber das Prinzip ist das gleiche] eine _Routing-Tabelle_. In dieser Tabelle ist festgelegt, welche Verbindungen (Leitungen) zu welchen Rechnern führen. Im Beispiel würde gelten: * <>: * Wenn an <>, direkte Leitung benutzen * Sonst an <>, den ISP[fuß: _Internet Service Provider_], weiterleiten * <>: * Wenn an <>, direkte Leitung benutzen * Wenn an <>, direkte Leitung benutzen * Wenn an <>, direkte Leitung benutzen * Sonst an <> weiterleiten * <>: * Wenn an <>, direkte Leitung benutzen * Wenn an <>, direkte Leitung benutzen * Sonst an <> weiterleiten * <>: * Wenn an <>, direkte Leitung benutzen * Sonst an <> weiterleiten * <>: * Wenn an <>, direkte Leitung benutzen * Sonst an <>, den ISP, weiterleiten : router : +-+ +-+ +-+ : |A| +----|Z| |B| : +-+ | +-+ +-+ : | +-----+ +-+ ^ : +-----| X |---------|Y|-----+ : |(ISP)| +-+ : +-----+ TTL ^^^ [label: ttl]Jeder Router verringert die TTL[fuß: _Time to Live_] jedes Pakets, welches ihn passiert. Angenommen, der Startwert ist <<255>> (theoretisches Maximum) und ein Paket wandert über 16 Router bis zum Ziel, so wird die entgültige TTL (die, die der Zielrechner zu Gesicht bekommt), nur noch <<239>> betragen. Erreicht die TTL zu irgendeinem Zeitpunkt <<0>>, so wird das Paket verworfen und den Quellrechner via ICMP über das Problem informiert. Viele Betriebssysteme verwenden dabei eine andere TTL als Startwert. Kennt man also die Start-TTL eines Rechners (ermittelbar via einem Ping (End-TTL wird geliefert) und Traceroute (siehe nächster Abschnitt; Anzahl der Hops (Router) zwischen Quell- und Zielrechner werden bekannt)), so kann man das eingesetzte Betriebssystem mit einiger Gewissheit vorhersagen (siehe Screenshot [shot: ttl,os,predicting ==> Betriebssystem-Vorhersage mit Hilfe der TTL]). [startshot: ttl,os,predicting] iblech@thestars iblech $ ping -c1 216.109.88.222 PING 216.109.88.222 (216.109.88.222) 56(84) bytes of data. 64 bytes from 216.109.88.222: icmp_seq=1 ttl=241 time=133 ms --- 216.109.88.222 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2012ms rtt min/avg/max/mdev = 133.149/133.859/135.101/0.976 ms iblech@thestars iblech $ traceroute 216.109.88.222 traceroute to 216.109.88.222 (216.109.88.222), 30 hops max, 40 byte packets 1 mars (10.0.0.4) 0.217 ms 0.112 ms 0.108 ms 2 ascend12.augustakom.net (80.81.6.76) 21.710 ms 20.907 ms 21.206 ms 3 router1.augustakom.net (80.81.6.2) 21.089 ms 24.281 ms 23.676 ms [...] 13 216.109.88.222 (216.109.88.222) 127.134 ms 125.593 ms 123.198 ms iblech@thestars iblech $ bc bc 1.06 Copyright 1991-1994, 1997, 1998, 2000 Free Software Foundation, Inc. This is free software with ABSOLUTELY NO WARRANTY. For details type warranty. 241+13 254 iblech@thestars iblech $ [Nun kann man in einer Tabelle nachschauen, welches Betriebssystem als Start-TTL 254 einsetzt.] [endshot] Traceroute ^^^^^^^^^^ Mit Hilfe des Befehls <> (<> auf manchen schlechten Systemen) wird die Route zu einem beliebigen Zielrechner angezeigt (siehe Screenshot [shot: traceroute ==> Traceroute zu www.latein.de]). [startshot: traceroute] traceroute to www.latein.de (217.160.106.142), 30 hops max, 40 byte packets 1 mars (10.0.0.4) 2 ascend5-alt.augustakom.net (80.81.6.10) 3 router1.augustakom.net (80.81.6.2) 4 80.81.7.118 (80.81.7.118) 5 Augustakom.S-3-eth000-106.de.lambdanet.net (217.71.108.37) 6 M-4-atm010-732.de.lambdanet.net (217.71.105.122) 7 MUXS-1-eth010.de.lambdanet.net (217.71.105.86) 8 INXS.gw-backbone-a.muc.schlund.net (194.59.190.46) 9 so-1100.gw-backbone-a.bs.ka.schlund.net (212.227.112.122) 10 v4022.gw-core-a.hs.ka.schlund.net (212.227.121.136) 11 gw-prtr-9-b.dist.hs.ka.schlund.net (212.227.113.88) 12 rohde.net (217.160.106.142) [endshot] Traceroute benutzt dabei keine Magie: Es setzt einfach die Start-TTL zuerst auf <<1>>. Damit kommt ein Paket also nur bis zum ersten Router, welches ein ICMP-Time-to-Live-exceeded-Paket zurück sendet, womit der erste Hop bekannt ist. Dann wiederholt <> das Verfahren mit einer TTL von <<2>>, erhält damit den nächsten Router, usf. Abschluss --------- Zu diesem Zeitpunkt sollte folgenden klar sein, um die nächsten Kapitel zu verstrehen: * Wie routet IP Pakete durch das Internet? * Was ist ein Port? * Wie kann man die Erreichbarkeit eines Hosts überprüfen? * Wie benutzt man * <>, * <>, * <> und * <>? E-Mails ======= [label: mails]Oft wird dazu geraten, Spam-Mails[fuß: Unerwünschte Werbe-Mails] einer sogenannten _Header-Analyse_ zu unterziehen. Dabei ist der Ausdruck insbesondere beim Umgang mit Mails nicht ganz korrekt: Bei E-Mails gibt es zwei Header-Typen, einmal den SMTP-Header (mehr dazu [ref: smtp]) und dann den Mail-Header, um den es in diesem Kapitel geht. Syntax ------ [label: mail-headers]Schaut man sich einmal den Header einer Mail an, so stellt man fest, dass die Headerfelder von den Feldinhalten mit einem <<: >> (Doppelpunkt Leerzeichen) voneinander getrennt sind. Typische Header --------------- Die meisten Header sind standardisiert, in RFC 2076. Die Mit <> beginnenden Header können frei verwendet werden, auch wenn sich einige X-Header auch schon als de-facto Standard durchgesetzt haben (siehe Tabelle [float: typheader ==> Typische Header])... [startfloat: typheader] > Header > Bedeutung > <> > SMTP-Server-Stempel > <> > Zeitpunkt des Versendes > <> > Absender[fuß: Diese Absenderadresse kann extrem leicht gefälscht werden, wie das Kapitel über SMTP noch zeigen wird...] > <> > Adresse, an die Rückantworten gehen sollen > <> > Message-ID, auf die geantwortet wurde > <>, <> > Empfänger > <> > Betreff > <>[fuß: Oft auch mit <> statt <> geschrieben] > Organisation, Firma, etc. > <>, <> > Verwendeter MUA (Mailprogramm) > <> > Zum Verfassen der Mail verwendetes Betriebssystem (Linux, Hurd, ...) > <> > ID des öffentlichen GnuPG/PGP-Schlüssels [endfloat] SMTP-Server-Stempel ^^^^^^^^^^^^^^^^^^^ Mails werden, wie im nächsten Kapitel klar wird, bei SMTP über viele Server geleitet. Jeder Server fügt beim Weiterleiten seinen eigenen <>-Header möglichst weit unten (aber vor den "normalen" Headern wie <> usw.) an, zum Beispiel | Received: from localhost (localhost [127.0.0.1]) | by iblech.dyndns.org (474.22.199) with ESMTP id+h6NFPc301506 | for ; Wed, 23 Jul 2003 17:25:38 +0200 Hier hat also der Server <> vom Server <> via dem Protokoll ESMTP erhalten. So lassen sich manchmal Spam-Versender zurückverfolgen, auch wenn sie ihre Absenderadresse fälschen. MIME-Typen ---------- [label: mime]Ein weiterer Header ist <>. Dieses Feld gibt den MIME-Typ[fuß: _Multipurpose Internet Mail Extensions_] des Inhalts der Mail an. MIME-Typen sind untergliedert in Kategorien, siehe dazu das Schema [grafik: mimetypen ==> Einige MIME-Typen]. : mimetypen : +----+ +->plain (text/plain: ASCII-Dokument) : +-+ +->|text|--+ : |M|/ +----+ +->html (text/html: HTML-Seite) : |I| : |M| : |E|\ +-----+ +->png (image/png: PNG-Bild) : +-+ +->|image|-+ : +-----+ +->xpm (image/xpm: XPM-Bild) MIME-Typen werden heute auch bei HTTP (siehe dazu [ref: httpmime]) eingesetzt, damit der Browser auch ohne die eher von altmodischen Betriebssystemen bekannte Dateinamenserweiterung über den Typ einer Datei bescheid weiß. Abschluss --------- Über den Header kann man also einige wichtige Informationen erhalten. Peinlich ist es natürlich für Firmen, die für ein bestimmtes Produkt per Mail werben, und dann selbst das Konkurrenzprodukt einsetzen... SMTP ==== [label: smtp]Der Mail-Header ist jetzt erklärt, doch eine Frage wurde bisher nur verdrängt: Wie kommen die Mails eigentlich beim Empfänger an? Diesen Part übernimmt das SMTP[fuß: _Send Mail Transport Protocol_]-Protokoll, eines der ersten, die es im Internet[fuß: bzw. damals noch ARPAnet], gab. Um einen Nutzer im Internet eindeutig zu adressieren, entwickelte man ein neues Adressierungsmuster: Man benutzt den Rechner, auf dem der Nutzer meistens anzutreffen ist, und seinen Login-Namen auf diesem als E-Mail-Adresse. Als Trenner fungiert das <<@>>-Zeichen. Für's Verschicken und Empfangen sind zwei unterschiedliche Protokolle zuständig, beide in der Anwendungsschicht angesiedelt (siehe dazu [ref: schichtenmodell]): SMTP zum Versenden und POP3 ([ref: pop3]) zum Empfangen von Mails. Grundlegendes ------------- E-Mails wandern bei SMTP i.A. über viele Server ehe sie ihr Ziel erreichen (siehe Schema [grafik: smtp-netzwerk ==> Eine Mail wird von vielen Servern weitergeleitet]). Dies kommt noch aus der Zeit der vielen Mailboxnetze, wo viele Internetverbindungen nicht permanent aktiv waren und so häufig andere Routen für die Mail-Übertragung genommen werden mussten. : smtp-netzwerk : +------+ +------+ +------+ +------+ : |Client|------>|Server|----->|Server|----->|Client| : +------+ LOKAL +------+ SMTP +------+ POP3 +------+ : SMTP IMAP4 SMTP, definiert in RFC[fuß: Request for Comments] 876, ist ein sehr einfaches, ASCII[fuß: American Standard Charset, Version 2]-basiertes Protokoll, das heißt, auch Menschen können zum Beispiel mit dem <>-Befehl das Protokoll nutzen. Idee ---- Damit jeder Server weiß, wohin er eine eingegangene Mail weiterleiten soll, muss dieser in den sogenannten _Envelope-Header_ schauen. Dieser Header hat noch nichts mit der Mail selbst zu tun! Der Server interessiert sich nicht für den _Mail_-Header, nur der _Envelope_-Header ist entscheidend für das Ziel der Mail. Dies ist vergleichbar mit "traditioneller" Post: Der Briefträger schaut nur auf den Umschlag, nicht aber in den Brief. Somit kann in dem Brief eine ganz anderer Empfänger angegeben sein, ohne das irgendjemand davon erfährt[fuß: korrupte Postboten mal abgesehen... ;-)] (siehe Abbildung [grafik: envelope ==> Unterschied zwischen Envelope- und Mail-Header)]. : envelope : +--------------------------------+ : |Echter Empfänger: foo@B | : | | : | +--------------------------+ : | |Hi blabla@C, | : | | | : | |... | : | | | : | | | : | | | : +-----+--------------------------+ Typischer Ablauf ---------------- Nun zu etwas praktischeren: Wir werden eine Mail, die <> geschrieben hat, an <> weiterleiten. Dabei spielen wir Rechner <>. Also verbinden wir uns zuerst mit Port 25 von Rechner B (siehe Abbildung [grafik: smtp-verbindung ==> Schematische Darstellung einer Mail-Übertragung von Server A zu B]). Dann authorisiert sich A bei B mit dem Kommando <>[fuß: Tatsächlich wird man meistens <> verwenden. <> ist das <> von ESMTP (_Extended SMTP_).]: | >HELO A | <250 B Hello A [foo.bar.com.org], pleased to meet you Die <<250>> am Anfang der Antwort stellt dabei den Statuscode dar. <<250>> bedeutet dabei "alles in Ordnung", wie man an der englischen Antwort daneben auch erkennen kann. Als nächstes erwartet B den Absender der E-Mail, und zwar den Envelope-Sender. | >MAIL FROM: | <250 2.1.0 ... Sender ok Damit B weiß, an wen er die Mail zustellen soll, kommt jetzt das Kommando RCPT[fuß: Recipient]: | >RCPT TO: | <250 2.1.5 ... Recipient ok Dieser Befehl kann auch mehrmals angewendet werden, um eine identische Mail an viele Empfänger zu schicken. Dies machen Spammer leider auch... Nun erst wird mit der Übertragung der eigentlichen Mail begonnen: | >DATA | <354 Enter mail, end with "." on a line by itself | >From: Mister Foo | >To: Bar Com | >Subject: foobar | > | >blabla... | >. | <250 2.0.0 h6EIf8O08948 Message accepted for delivery Ab dem eingegebenen <> kommt die eigentliche Mail (siehe Schema [grafik: mail-body-header ==> Header und Body einer Mail]), im gleichen Format wie schon im vorhergehenden Kapitel erläutert. Diese _Mail_-Header können hier _beliebig_ gesetzt werden, ohne dass das irgendeine Software überprüft. Theoretisch kann der Mail-Header sogar fehlen; Die Mail kommt trotzdem an, dafür sorgt ja der Envelope-Header. : mail-body-header : +-+------------------------------------+ : | |Mail-Header (nicht Envelope-): | : | +------------------------------------+ : |M|From: Mister Foo | : | |To: Bar Com | : | |Subject: foobar | : |A+------------------------------------+ : | |(Leerzeile) | : | +------------------------------------+ : |I|Mail-Body: | : | +------------------------------------+ : | |blabla... | : |L| | : | | | : | | | : +-+------------------------------------+ Zum Schluss muss die Sitzung noch geschlossen werden: | >QUIT | <221 2.0.0 B closing connection : smtp-verbindung : 1. +-+ TCP/IP-Port 25 +-+ : |A|----------------->|B| : +-+ +-+ : : 2. +-+ SMTP: EHLO +-+ : |A|----------------->|B| : +-+ Authentifika- +-+ : tion : : 3. +-+ SMTP: MAIL FROM: +-+ : |A|----------------->|B| : +-+ Absender +-+ : : 4. +-+ SMTP: RCPT TO: +-+ : |A|----------------->|B| : +-+ Empfänger +-+ : : 5. +-+ SMTP: DATA +-+ : |A|----------------->|B| : +-+ Mailinhalt +-+ : (Header und Body) : : 6. +-+ SMTP, TCP/IP +-+ : |A|----------------->|B| : +-+ Schließen +-+ : der Verbindung Beispiel -------- Um also eine E-Mail an <> im Namen von <>[fuß: Diese Adresse gibt es (zumindest bei der ICANN) nicht; da diese aber nur im _Mail_-Header (und nicht im Envelope-Header, der vielleicht auf syntaktische Korrektheit hin überprüft wird) zu finden sein wird, ist dies egal.] zu schicken, verbindet man sich einfach mit einem Open Relay[fuß: Ein Open-Relay ist ein SMTP-Server, der jede Mail annimmt und dann entsprechend weiterleitet. Solche Open-Relays waren früher sehr beliebt und legitim, da ein Internetzugang noch sehr viel gekostet hat und so jemand anderes die Mails weiter verschickt hat (zum Beispiel ein Server einer Universität)] oder direkt mit dem SMTP-Server vom Empfänger (siehe das Kapitel über DNS [ref: dns], oder gleich den Abschnitt über MX-Records [ref: mx]) auf Port 25 (zum Beispiel via <>). Bei der Eingabe des Envelope-Senders ist allerdings zu beachten, dass viele Mailserver die Syntax jenes Absenders überprüfen. Als Envelope-Sender ginge also zum Beispiel <> nicht durch. Deswegen verwendet man immer eine gültig aussehende E-Mail-Adresse als Envelope-Header. Welcher Absender in der Mail selbst dann steht, ist, wie schon erwähnt, vollkommen egal. Also gibt man ein: | >EHLO localhost | >MAIL FROM: | >RCPT TO: | >DATA | >From: The Imperor ¤¢ | >To: You! Yes, you! | >Subject: Hmm... | > | >muhahahaha... | >. | >QUIT Übersicht aller Befehle ----------------------- > Befehl > Wirkung > <> > Authentifizierung, alt > <> > Authentifizierung, neu > <>> > Envelope-Sender > <>> > Envelope-Empfänger > <> > Beginn der Mail > <<.>> > Ende der Mail > <> > Terminieren der Verbindung Abschluss --------- Wer dieses Kapitel aufmerksam gelesen hat, weiß jetzt, * was der Unterschied zwischen dem Envelope- und dem Mail-Header ist, * welcher der beiden entscheidend für den Weg der Mail ist und oft auch kontrolliert wird und * wie man eine Mail unter falscher Absenderadresse versendet. POP3 ==== [label: pop3]POP3[fuß: _Personal Office Protocol_], definiert in RFC 1939, ist praktisch das Gegenstück zu SMTP. Auch auf ASCII basierend, holt es die Mails vom Server ab anstatt sie zu versenden. Auf EPOP3[fuß: _Extended POP3_] wird hier nicht eingegangen, da es im Wesentlichen nur neue Authentifizierungsmöglichkeiten unterstützt. Grundlegendes ------------- Bei POP3 werden die Mails, welche zuvor via SMTP versendet wurden, auf dem Server so lange gespeichert, bis sie vom Client gelöscht werden[fuß: ...oder das Quota erreicht ist...]. Ohne POP3[fuß: oder IMAP] müsste der Client permanent online sein, um E-Mails zu erhalten, was besonders früher wegen der hohen Onlinekosten wirklich nicht erwünscht war... Typische POP3-Sitzung --------------------- POP3 ist eines der einfachsten Protokolle. Im Gegensatz zu SMTP, wo es Hunderte von Statuscodes gibt, findet man bei POP3 nur <<+OK>> oder <<-ERR>> vor. Auch gibt es bei POP3 im Gegensatz zu zum Beispiel IMAP wenig Interaktivität; Der Client verlangt etwas (Liste der auf dem Server gespeicherten Mails oder eine gewünschte Mail), und der Server antwortet sofort. Als Beispiel dient das einfache Abrufen samt anschließendem Löschen der Mails _ohne_ MUA[fuß: _Mail User Agent_, zum Beispiel <>, <> oder <>]: * Zuerst verbindet man sich mit dem POP3-Server, der seine Mails speichert, auf Port <<110>>. Als Banner-Zeile enthält man vom Server zum Beispiel: | <+OK WEB.DE POP3-Server * Dann loggt man sich ein: | >USER iblech | <+OK Bitte Kennwort eingeben/enter password | >PASS Th1s_1s_4_VeRy_S3cRe7_p4s5w0rd | <+OK Postfach bereit/mailbox locked and ready * Nun kann man eine Liste der auf dem Server gespeicherten Messages abrufen: | >LIST | <+OK | <1 1882 | <2 5665 | <. * Um nun zum Beispiel die 2. Mail herunterzuladen, gibt man ein: | >RETR 2 | <+OK Nachricht folgt/message follows | | | >) benutzt. * Jetzt, wo der Client die Mail erhalten hat, kann man die Mail löschen: | >DELE 2 | <+OK Nachricht wurde geloescht/message deleted * Um dann die Verbindung wieder zu schließen tippt man: | >QUIT | <+OK Eine Beispielsitzung ist [shot: pop3 ==> Mit POP3 Mails abrufen] zu sehen. zu sehen. [startshot: pop3] iblech@thestars iblech $ telnet pop3.web.de 110 Trying 217.72.192.134... Connected to pop3.web.de. Escape character is '^]'. +OK WEB.DE POP3-Server USER iblech +OK Bitte Kennwort eingeben/enter password PASS Ultr4 1337 p455w0rd +OK Postfach bereit/mailbox locked and ready LIST +OK 1 1882 2 5665 3 2430 4 1790 5 5079 . RETR 1 +OK Nachricht folgt/message follows Received: from [204.126.2.42] (helo=gentoo.org) by mx16.web.de with smtp (WEB.DE 4.99 #401) id 19crxk-0006K8-00 for iblech@web.de; Wed, 16 Jul 2003 21:29:16 +0200 Received: (qmail 8463 invoked by uid 1002); 16 Jul 2003 19:28:37 -0000 Mailing-List: contact gentoo-user-help@gentoo.org; run by ezmlm Precedence: bulk List-Id: Gentoo Linux mail Reply-To: gentoo-user@gentoo.org X-BeenThere: gentoo-user@gentoo.org ... . DELE 1 +OK Nachricht wurde geloescht/message deleted QUIT +OK Connection closed by foreign host. iblech@thestars iblech $ [endshot] Das war's auch schon. So kann man auch ohne installierten MUA seine Mails abrufen und löschen, zum Beispiel wenn eine $100$ MByte große Mail auf dem Server ist und man gerade keine Lust hat, wegen ISDN $243$ Minuten zu warten. Übersicht aller Befehle ----------------------- > Befehl > Wirkung > <> > Login > <> > Passwort > <> > Liste aller auf dem Server gespeicherten Mails > <> > Zeigt die Anzahl der gespeicherten Mails samt ihrer Größe[fuß: in Octets (Bytes)] an > <> > Holt Nachricht gegebener Nummer > <> > Löscht Nachricht gegebener Nummer > <> > Beendet die Verbindung Abschluss --------- Jetzt sollte das Abholen und Löschen von Mails via POP3 keine Probleme mehr bereiten... IMAP4 ===== Wie POP3 dient IMAP (definiert in RFC 1730) dazu, die auf dem Server gespeicherten Mails abzurufen. Allerdings bleiben bei IMAP die Mails üblicherweise auf dem Server, das heißt der Server übernimmt die permanente Speicherung der Mails. Dies ist besonders für Nutzer, die oft an verschiedenen Computern arbeiten, nützlich, da sie nun auf alle ihrer Mails von jedem Computer aus Zugriff haben. Auch gibt es bei IMAP (server-seitige) Ordner, ein Fremdwort für POP3. Technische Implementierung -------------------------- Direkt nach dem Verbinden auf den Standardport <<143>> des IMAP4-Servers (im Beispiel <>) empfängt man eine Bannermeldung: | <* OK WEB.DE IMAP4-Server Als nächstes loggen wir uns ein: | >A001 LOGIN "iblech" "pa5sword" | >). Die ID kann mehr oder weniger frei gewählt werden, es dürfen nur keine Leerzeichen oder andere Sonderzeichen in der ID enthalten sein. Auch muss die nächste ID _nicht_ unbedingt "höher" (zum Beispiel <>) sein. Nun können wir einen Ordner auswählen: | >A002 SELECT "inbox" | <* 1 EXISTS | <* OK [UNSEEN 1] Message 1 is first unseen | <* OK [PERMANENTFLAGS (\Deleted \Seen \Answered)] | <* OK [UIDVALIDITY 1] | <* FLAGS (\Answered \Flagged \Deleted \Seen \Draft) | >). Bevor wir allerdings die Nachricht herunterladen, können wir schauen, wie groß die Mail (wie bei POP3 angegeben in Octets, also Bytes) ist: | >A003 FETCH 1 RFC822.SIZE | <* 1 FETCH (RFC822.SIZE 2247) | A004 FETCH 1 RFC822.HEADER | <* 1 FETCH (RFC822.HEADER {1446} | | | > (runde Klammer zu) markiert. Auch der Body der Mail ist schnell geholt: | >A005 FETCH 1 BODY.PEEK[TEXT] | <* 1 FETCH (BODY[TEXT] {873} | A005 FETCH 1 RFC822 benutzen können. Nun kann die Mail gelöscht (obwohl das bei IMAP, wie oben erwähnt, eher unüblich ist) werden: | >A006 STORE 1 +FLAGS (\Deleted) | >* 1 FETCH (FLAGS (\Deleted)) | A007 EXPUNGE | <* 1 EXPUNGE | > beenden wir die Verbindung: | * BYE LOGOUT received | >A008 OK Completed Übersicht aller Befehle ----------------------- > Befehl > Wirkung > <> > Login > <
| Alter:
| OS:
| | Die Übertragung solcher Formulare ist über zwei HTTP-Requests möglich: Den einfachen <>-Request[fuß: bei dem allerdings die maximale Länge der Formulardaten (eigentlich der gesamten URL) nicht mehr als 1024 Zeichen betragen darf] und den etwas schwieriger verwendbaren <>-Request. GET-Request ^^^^^^^^^^^ [label: get-request]Der <>-Request ist ja schon vom "normalen" Abrufen von Websites bekannt, das heißt: Nichts neues Lernen! Bei <> werden die Feldnamen von den Feldinhalten mit einem <<=>> getrennt, und dann an die URL, getrennt mit einem <>, angehängt. Die einzelnen Parameter unter sich werden mit einem <<&>> getrennt (siehe Grafik [grafik: get-forms ==> Übertragung der Parameter bei GET-Formularen]). : get-forms : +-----------------------+ +----------------------+ : |http://host/umfrage.php| |http://host/umfrage.ph| : +-----------------------+ |p?name=Ingo&alter=15&o| : |name: Ingo | |s=Gentoo | : |alter: 15 |-->| | : |os: Gentoo | | | : +-----------------------+ | | : |Abschicken! | | | : +-----------------------+ +----------------------+ Zusammenfassend wird * die "normale" URL von den Parametern mit einem <>, * jeder Parameter von den anderen mit einem <<&>> und * Feldname von Feldinhalt mit einem <<=>> getrennt. Auch hierzu mehr im Kapitel über die Automatisierung der ganzen Vorgänge [ref: http-scripts]. POST-Request ^^^^^^^^^^^^ [label: post]Beim <>-Request werden die Felder nicht in der URL gespeichert, sondern im HTTP-Request selbst. Dies ermöglicht Übertragungen größer als einem Kilobyte. Unser Beispielrequest sieht bei Verwendung von POST so aus: | >POST /umfrage.php HTTP/1.1 | >Host: host | >Content-Type: application/x-www-form-urlencoded | >Content-Length: 29 | > | >name=Ingo&alter=15&os=Gentoo | > | >... Der Request ist also verlängert, nach der Leerzeile kommt _nicht_ (wie etwa bei <> und <>) die Antwort, sondern der Inhalt des Formulars. Wichtig ist auch der <>-Header. Die Länge muss exakt mit der Anzahl der Zeichen der Übertragung übereinstimmen. Kennt man die Länge nicht, kann man auch hier Chunked-Encoding verwenden: | >POST /umfrage.php HTTP/1.1 | >Host: host | >Content-Type: application/x-www-form-urlencoded | >Transfer-Encoding: chunked | > | >a | >name=Ingo& | >12 | >alter=15&os=Gentoo | >0 | > Weiterleitung ------------- Oft verweist eine Adresse auf eine andere, zum Beispiel verweist <> auf <>. Während dies zum einen mit Hilfe eines Meta-Feldes von (X)HTML möglich ist, ist die HTTP-Methode (verfügbar sowohl bei HTTP/1.0 als auch bei HTTP/1.1) wesentlich eleganter, da sie bei Dateien jedes Formats funktioniert, nicht nur bei HTML. Erkennbar ist so eine Weiterleitung daran, dass statt des Statuscodes <<200>> <<302>> zurückgeliefert wird. Im <>-Headerfeld wird dann die Zieladresse übermittelt. Um also auf das Beispiel mit Sourceforge zurückzukommen: * Zuerst verbinden wir uns mit Port <<80>> von <>, und verlangen ganz normal <>: | >GET / HTTP/1.1 | > * Aber als Antwort erhalten wir jetzt <<302 Found>>: | >-Request: | >HEAD / HTTP/1.1 | >Host: hostname | > | Befehl > Wirkung > <> > Holt angegebene Datei > <> > Sendet Parameter via <> > <> > Zeigt den Server-Header (Content-Type, etc.) einer Seite an Typische Header-Felder sind > Header-Feld > Bedeutung > Wird gesendet vom > <> > Hostname des Servers > Client > <> > Keep-Alive benutzen? > Client > <> > Zuletzt besuchte Seite > Client > <> > Verwendeter Browser > Client > <> > Gesetzte Cookies > Client > <> > Gewünschte Sprachen > Client > <> > Benutzte Server-Software > Server > <> > Weiterleitung > Server > <> > Cookie(s) setzen > Server > <> > MIME-Typ der angeforderten Seite > Server Eine Beispielsitzung unter Verwendung der meisten Befehle und Header-Felder ist [shot: http,glance ==> HTTP at a glace] zu sehen. [startshot: http,glance] POST /cgi-bin/login.pl HTTP/1.1 Host: wewewe.mein-loginserver.de Connection: close Referer: http://wewewe.mein-loginserver.de/ User-Agent: Lynx/2.8.4rel1 (full-comatible; 128Bit GNU/Linux) Cookie: $Path="/"; Domain="wewewe.mein-loginserver.de"; $Version="1"; ColorScheme="default" Accept-Language: de Content-Type: application/x-www-form-urlencoded Content-Length: 29 username=iblech&password=2600 HTTP/1.1 302 Found Date: Fri, 18 Jul 2003 19:00:37 GMT Server: Apache/21.3.19 (GNU Gentoo/Hurd) Content-Type: text/plain Location: http://wewewe.mein-loginserver.de/cgi-bin/main.pl Set-Cookie: Path="/"; Domain="wewewe.mein-loginserver.de"; $Version="1"; logged_in="true"; username="iblech"; ColorScheme="red"; SID="d17ed26ab2c53f52a91777fcc5348849" Eine Weiterleitung erfolgt... [endshot] Gopher ====== Gopher ist, oder besser war, ähnlich wie HTTP früher, ein Protokoll zum Abrufen von Informationen. Leider stirbt der "Gopherspace" immer mehr aus, da den Lamern c00le Flash-Animationen wichtiger sind als das schnelle Auffinden von Dateien. Idee ---- Die Informationen sind bei Gopher in einer Art Dateibaum hierarchisch angeordnet, wobei es keine Rolle spielt, auf welchem Server die Daten wirklich vorliegen. Dadurch war es möglich, nur durch wenige Verzweigungen zum Ziel zu kommen. Technik ------- Bei Goher gibt es einige verschiedene Dateitypen, die durch eine Ziffer oder einen Buchstaben symbolisiert werden (siehe Tabelle [float: gopher,typen ==> Einige Dateitypen von Gopher]). [startfloat: gopher,typen] > Kennzeichen > Typ > <<0>> > ASCII-Datei > <<1>> > Verzeichnis > <<3>> > Fehler > <<6>> > UU-enkodierte Datei > <<8>> > Link auf eine Telnet-Sitzung > <<9>> > Binäre Datei > <> > HTML-Seite > <> > Nichtauswählbarer Menü-Eintrag (z.B. eine Willkommensmeldung) > <

> > PDF-Dokument [endfloat] Das URL-Pendant (siehe dazu [ref: url]) von Gopher setzt sich immer aus dem Dateityp und dem Pfad zusammen, zum Beispiel <<1/GNU>> oder <<0/GNU/GPL.txt>>. Beispielsitzung --------------- Um zu erst das in der Abbildung [shot: gopher,iblech,/ ==> Die Einstiegsseite von iblech.dyndns.org] Eingangsmenü via Telnet zu erreichen, verbinden wir uns mit dem Server (im Beispiel <>) auf dem Gopher-Standard-Port <<70>> und geben ein: | >1/ | <1Alles, was mit Linux zu tun hat 1/Linux iblech.dyndns.org 70 + | <1Interessante Links 1/Links iblech.dyndns.org 70 + | <0Test 0/test iblech.dyndns.org 70 + | <. Die einzelnen Rückgabefelder sind dabei durch einen Tabulator getrennt, und geben der Reihe nach * den Link-Namen (mit vorrangestellten Dateityp-Kennzeichen), * das Link-Ziel * den Server des Ziels * und dessen Port an. Das Ende der Übertragung wird wie so oft mit einem einzelnen Punkt auf einer Zeile markiert, woraufhin die Verbindung auch geschlossen wird. "Keep-Alive" (siehe dazu [ref: keep-alive]) ist für Gopher also ein Fremdwort. [startshot: gopher,iblech,/] Home Gopher server: localhost [1] Alles, was mit Linux zu tun hat/ [2] Interessante Links/ [3] Test Press ? for Help, q to Quit Page: 1/1 [endshot] Ist das Ziel unserer Anfrage eine Datei, ist das auch kein Problem | >0/test | >) offen. Dazu kommt dann noch eine Datenverbindung, die erst später geöffnet wird. Der Port dieser Verbindung wird erst durch die Kontrollverbindung festgelegt[fuß: Sehr zum Ärger der Firewalls, die nicht mehr einfach alle Ports blockieren können...]. Die Datenverbindung kann dabei sowohl vom Client (passives FTP) als auch vom Server aus (aktives FTP) geöffnet werden (siehe Grafik [grafik: ftp-daten ==> Dynamische Datenverbindung]). : -scale:93 ftp-daten : Passives FTP: : +-------------------------+ : +------+ |Hey, bei welchem deiner | +------+ : +>|Client|-->|Ports ich meine Daten |-->|Server|-+ : | +------+ |abliefern/deine erwarten?| +------+ | : | +-------------------------+ | : | +--------------------------------------+ | : +---|Verbinde dich mal auf Port xyz von mir|<-------+ : +--------------------------------------+ : : Aktives FTP: : +---------------------------+ : +------+ |Verbinde dich mal mit mei- | +------+ : +>|Client|-->|nem Port xyz um meine Daten|-->|Server|-+ : | +------+ |zu erhalten/deine zu senden| +------+ | : | +---------------------------+ | : | +------------+ | : +------------------|Ok, mach ich|<--------------------+ : +------------+ Man kann folglich FTP als eine TCP-Proxy (!) benutzen, sofern aktives FTP zugelassen ist[fuß: Was sogar bei <> der Fall ist]. Passives FTP ------------ Um irgendeine Transaktion ausführen zu können (Verzeichnislisting erhalten, Dateien herunter- oder hochladen, Verzeichnisse erstellen, etc.) müssen wir uns zuerst einloggen: | >220 Microsoft FTP Service | >USER anonymous | <331 Anonymous access allowed, send identity (e-mail name) \ | < as password. | >PASS abuse@aol.com | <230-This is FTP.Microsoft.Com | <230 Anonymous user logged in. Hier kann man bereits eine Ähnlichkeit zu POP3 und NNTP feststellen: Es werden auch hier Statuscodes verwendet. Der <>-Benutzer ist auf eigentlich allen Servern vorhanden, natürlich ohne Schreibrechte. Als Passwort wird oft die E-Mail-Adresse verlangt, damit der Betreiber der Site uns kontaktieren (=Spam versenden) kann. Jetzt kommt der entscheidene Befehl von passivem FTP, der nach jeder Übertragung wieder neu eingegeben werden muss: | >PASV | <227 Entering Passive Mode (207,46,133,140,191,242). Diese wirre Zahlenkombination verrät uns, wohin wir eine TCP-Verbindung aufbauen müssen. Die IP ist klar in den ersten vier Blöcken angegeben (<<207.46.133.140>>). Der Port errechnet sich aus $a * 256 + b$, wobei $a$ der ersten Zahl nach der IP entspricht (<<191>>) und $b$ der zweiten (<<242>>). Also müssen wir eine Verbindung zu <<207.46.133.140:49138>> aufbauen. Dies erledigen wir in einer zweiten Shell[fuß: Auf schlechten Systemen "MS-DOS-Eingabeaufforderung" genannt]: | iblech@thestars genuineng $ telnet 207.46.133.140 49138 | Trying 207.46.133.140... | Connected to 207.46.133.140. | Escape character is '^]'. Jetzt kann der Gegenstand der Übertragung genannt werden (siehe dazu [ref: ftp-befehle]), eine komplette Beispielsitzung ist [shot: ftp,passiv ==> Passives FTP] zu sehen. [startshot: ftp,passiv] (Kontrollterminal:) iblech@thestars iblech $ telnet ftp.microsoft.com ftp Trying 207.46.133.140... Connected to ftp.microsoft.com. Escape character is '^]'. 220 Microsoft FTP Service USER anonymous 331 Anonymous access allowed, send identity (e-mail name) \ as password. PASS abuse@aol.com 230-This is FTP.Microsoft.Com. 230 Anonymous user logged in. PASV 227 Entering Passive Mode (207,46,133,140,191,242). LIST 125 Data connection already open; Transfer starting. 226 Transfer complete. QUIT 221 Thank-you for using Microsoft products! Connection closed by foreign host. iblech@thestars iblech $ (Datenterminal:) iblech@thestars genuineng $ telnet 207.46.133.140 49138 Trying 207.46.133.140... Connected to 207.46.133.140. Escape character is '^]'. dr-xr-xr-x 1 owner group 0 Nov 25 2002 bussys dr-xr-xr-x 1 owner group 0 May 21 2001 deskapps dr-xr-xr-x 1 owner group 0 Apr 20 2001 developr dr-xr-xr-x 1 owner group 0 Nov 18 2002 KBHelp dr-xr-xr-x 1 owner group 0 Jul 2 2002 MISC dr-xr-xr-x 1 owner group 0 Dec 16 2002 MISC1 dr-xr-xr-x 1 owner group 0 Feb 25 2000 peropsys dr-xr-xr-x 1 owner group 0 Jan 2 2001 Products dr-xr-xr-x 1 owner group 0 Apr 4 13:54 PSS dr-xr-xr-x 1 owner group 0 Sep 21 2000 ResKit dr-xr-xr-x 1 owner group 0 Feb 25 2000 Services dr-xr-xr-x 1 owner group 0 Feb 25 2000 Softlib Connection closed by foreign host. iblech@thestars genuineng $ [endshot] Aktives FTP ----------- Richtig interessant ist allerdings _aktives_ FTP, da wir selbst bestimmen können, wohin der Server seine Datenverbindung aufbauen soll (siehe dazu [ref: ftp-goodies]). Die Basis ist die gleiche wie bei passivem FTP, also erstmal verbinden und authentifizieren: | <220 Microsoft FTP Service | >USER anonymous | <331 Anonymous access allowed, send identity (e-mail name) \ | < as password. | >PASS abuse@aol.com | <230-This is FTP.Microsoft.Com. | <230 Anonymous user logged in. Nun benutzen wir den <>-Befehl, um dem Server mitzuteilen, wohin er seine Daten schicken soll bzw. unsere Daten erhalten soll. Die Syntax ist dabei die gleiche wir bei <>, nur dass wir jetzt selbst die Parameter festlegen. Angenommen, unsere IP-Adresse ist <<80.81.9.189>> und unser gewünschter Port ist <<4712>>, so geben wir | >PORT 80,81,9,189,18,104 | <200 PORT command successful. ein. Die Zahlen, die den Port spezifizieren errechnen sich dabei durch die Formeln <> und <>. In einer anderen Konsole lauschen wir auf dem Port, um die Ausgabe des Servers (Verzeichnislisting oder Herunterladen von Dateien) bzw. unsere Daten einzutippen: | iblech@thestars guide $ nc -l -p 4712 Nun kann (wieder im Datenkanal) die Übertragung zum Beispiel mit <>, <> oder <> initiiert werden. Eine komplette Beispielsitzung ist [shot: ftp,aktiv ==> Aktives FTP] zu sehen. [startshot: ftp,aktiv] (Kontrollterminal:) iblech@thestars iblech $ telnet ftp.microsoft.com ftp Trying 207.46.133.140... Connected to ftp.microsoft.com. Escape character is '^]'. 220 Microsoft FTP Service USER anonymous 331 Anonymous access allowed, send identity (e-mail name) \ as password. PASS abuse@aol.com 230-This is FTP.Microsoft.Com. 230 Anonymous user logged in. PORT 80,81,9,189,15,111 200 PORT command successful. LIST 125 Data connection already open; Transfer starting. 226 Transfer complete. QUIT 221 Thank-you for using Microsoft products! Connection closed by foreign host. iblech@thestars iblech $ (Datenterminal:) iblech@thestars guide $ nc -l -p 3951 dr-xr-xr-x 1 owner group 0 Nov 25 2002 bussys dr-xr-xr-x 1 owner group 0 May 21 2001 deskapps dr-xr-xr-x 1 owner group 0 Apr 20 2001 developr dr-xr-xr-x 1 owner group 0 Nov 18 2002 KBHelp dr-xr-xr-x 1 owner group 0 Jul 2 2002 MISC dr-xr-xr-x 1 owner group 0 Dec 16 2002 MISC1 dr-xr-xr-x 1 owner group 0 Feb 25 2000 peropsys dr-xr-xr-x 1 owner group 0 Jan 2 2001 Products dr-xr-xr-x 1 owner group 0 Apr 4 13:54 PSS dr-xr-xr-x 1 owner group 0 Sep 21 2000 ResKit dr-xr-xr-x 1 owner group 0 Feb 25 2000 Services dr-xr-xr-x 1 owner group 0 Feb 25 2000 Softlib Connection closed by foreign host. iblech@thestars guide $ [endshot] Übersicht aller Befehle ----------------------- [label: ftp-befehle]Sobald der Datenkanal offen ist, kann mit einer Übertragung begonnen werden (siehe Tabelle [float: ftp,befehle ==> Einige FTP-Befehle]). [startfloat: ftp,befehle] > Befehl > Wirkung > Datenkanal benötigt > <> > Login > Nein > <> > Login > Nein > <> > Holt Listing des aktuellen Verzeichnisses > Ja > <> > Lädt Datei herunter > Ja > <> > Speichert Datenkanal auf dem Server > Ja > <> > Hängt Datenkanal an Datei an > Ja > <> > Löscht Datei > Nein > <> > Zeigt aktuelles Verzeichnis an > Nein > <> > Wechselt Verzeichnis > Nein > <> > Erzeugt ein neues Verzeichnis > Nein > <> > Löscht Verzeichnis > Nein > <> > Markiert Datei o. Dir zum Verschieben > Nein > <> > Benennt markierte Datei um > Nein [endfloat] Goodies ------- [label: ftp-goodies]Zwei Features von aktivem FTP machen es jedoch erst richtig interessant: Zum einen kann man eine Datei von einem Server zu einem anderen übertragen, _ohne_ die Datei lokal zwischenspeichern zu müssen. Zum anderen kann man aktives FTP als TCP-Proxy (!) benutzen, man kann also eine Verbindung zu jedem Host auf (fast) jeden Port herstellen! Übertragung zwischen zwei Servern ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ : ftp-2server : Langsam: : +--------+ +--------+ : |Server 1|-+ +>|Server 2| : +--------+ |D D| +--------+ : |S S| : |L L| : v | : +------+ : |Client| : +------+ : Schnell: : +--------+ T1 +--------+ : |Server 1|----->|Server 2| : +--------+ +--------+ : ^ ^ : |D D| : |S S| : |L +------+ L| : +----|Client|---+ : +------+ Zum einen kann man natürlich eine Datei eines Servers auf einen anderen mit der "konventionellen" Methode übertragen (Datei vom ersten Server auf den eigenen Computer herunterladen und vom eigenen Computer aus dann auf den zweiten Server hochladen). Dass diese Methode sehr viel Zeit in Anspruch nimmt, ist klar, schließlich muss zweimal die langsamen DSL-Leitungen verwendet werden. Mit einer Kombination aus aktivem und passivem FTP kann der eigentliche Datenaustausch auch direkt zwischen den beiden Servern stattfinden: Man lässt sich einfach vom zweiten Server via passivem FTP eine Adresse geben, welche man dann dem ersten Server via aktiven FTP mitteilt. Dann initiiert man auf beiden Servern die Übertragung, zum Beispiel mit <> auf dem ersten und <> auf dem zweiten Rechner. Das Ergebnis: Man hat soeben mit T1-Geschwindigkeit eine Datei übertragen (siehe Abbildung [grafik: ftp-2server ==> Daten mit T1-Geschwindigkeit übertragen]). Auch die Implementation ist sehr einfach: | (2)>PASV | (2)<227 Entering Passive Mode (a,b,c,d,e,f). | (1)>PORT a,b,c,d,e,f | (1)<200 PORT command successful. | (1)>RETR file | (2)>STOR file Application-Level-Proxy ^^^^^^^^^^^^^^^^^^^^^^^ Am coolsten ist FTP jedoch, wenn man es als TCP-Proxy einsetzt, obwohl man die Antworten nicht zurück bekommt. Eine TCP-Proxy ist eine Proxy auf TCP-Ebene, das heißt ein TCP-Proxy kann zum Beispiel alle telnet-Sitzungen weiterleiten. Auch die Realisierung ist sehr einfach, wenn man auf dem FTP-Server, der aktives FTP unterstützen muss, Schreibrechte besitzt: * Zuerst speichern wir auf dem FTP-Server (manuell oder via FTP-Programm) eine Datei, die die Komanndos enthält, die dann auf dem Zielrechner ausgeführt werden sollen. Da wir im Beispiel versuchen werden, eine Website abzurufen, verwenden wir | GET / HTTP/1.1 | Host: website.de | * Dann stellen wir die Verbindung auf: | >PORT ip,der,website,de,0,80 | <200 PORT command successful. | >RETR datei-wo-wir-die-http-kommandos-gespeichert-haben * Und fertig ist der HTTP-Request ;-). Der Nachteil ist natürlich deutlich, man empfängt die Antwort des Zielservers nicht. Aber oft ist das auch egal, zum Beispiel wenn die Zielseite ein Counter ist (der dann natürlich hochzählt) oder eine Abstimmung[fuß: ...]... Abschluss --------- Einige werden sich jetzt fragen, wozu das ganze denn gut sein soll. Aber FTP-via-Telnet nützt nicht nur, wenn man mal eben eine TCP-Proxy brauch, sondern auch, wenn ein FTP-Server defekt ist. Durch die (meist englischen) Fehlermeldungen kann ein Mensch sehr schnell die Ursache des Problems feststellen und so trotzdem die vielleicht sehr wichtigen Dateien transferieren. IRC === Nun wieder zu einem einfacheren Protokoll: IRC[fuß: _Internet Relay Chat_], definiert in RFC 1459. IRC ist sehr viel jünger als zum Beispiel SMTP oder FTP und übernimmt einen Bereich des Internets, der immer mehr an Zustimmung findet: Echt-Zeit[fuß: mehr oder weniger...] Chatten. Idee ---- Bei IRC werden Leute mit gleichen Interessen in "Channels" eingeteilt[fuß: natürlich freiwillig...], zum Beispiel <<#linux>> oder <<#hurd>>. Die Kommunikation läuft dann immer über den Server, das heißt, es werden keine Verbindungen zwischen den Client-Rechnern selbst hergestellt. Bei einigen hundert Leuten pro Channel würde man, wenn alle Clients miteinander verbunden werden sollten, tausende Verbindungen benötigen. Wenn sich alle Clients nur mit dem Server verbinden sind nur soviel Verbindungen nötig wie Clients vorhanden sind (siehe Grafik [grafik: irc-netz ==> Die Architektur des IRC-Netzes]). : irc-netz : Schlecht: Gut: : +-+ +-+ +-+ +-+ : |A|<----->|B| |A| |B| : +-+ +-+ +-+ +-+ : ^ P T ^ P T : | \ / | J L : | \ / | +------+ : | x | |Server| : | / \ | +------+ : | / \ | T P : v L J v L J : +-+ +-+ +-+ +-+ : |D|<----->|C| |D| |C| : +-+ +-+ +-+ +-+ Dabei tauschen sich die einzelnen IRC-Server eines IRC-Netzwerkes (es gibt mehrere) auch gegenseitig aus, um ein möglichst synchrones IRC-Netz zu gewährleisten. Somit ist es egal, zu welchem Server eines Netzes ein Client sich verbindet: Er sieht trotzdem alle Nachrichten aller anderen Clients desselben Netzes. Beispielsitzung --------------- Im Folgenden werden wir eine Runde im Channel <<#infothek>> des Servers <> chatten. Dazu verbinden wir uns zuerst mit dem Server, woraufhin wir gleich eine Authentifizierungsmeldungen erhalten: | > und dem Realname[fuß: Echter Name] <> an: | >NICK irc-telnet | PONG :1437972627 | >USER irc-telnet localhost localhost :Telnet Chatter | <:quakenet.org 001 irc-telnet :Welcome... | <... | <:quakenet.org 372 irc-telnet :- **[ End Of MOTD ]****** | <:quakenet.org 376 irc-telnet :End of /MOTD command. | <:quakenet.org NOTICE irc-telnet :on 2 ca 4(4) ft 20(20) Das <>-Befehl als Antwort auf <> beeinflusst die Login-Prozedur nicht; Der Server prüft mit einem <>-Befehl nur, ob der Client noch online ist. Auf ein <>-Paket muss man immer mit einem identischen <>-Paket antworten. Als nächstes gehen wir in den Channel <<#infothek>>: | >JOIN #infothek | <:irc-telnet!~irc-telne@13.9.ak.net JOIN :#infothek | <:quakenet.org 353 irc-telnet = #infothek :irc-telnet @iblech | <:quakenet.org 366 irc-telnet #infothek :End of /NAMES list. Wir sind drin! Und können jetzt eine Nachricht an alle im Channel befindlichen Leute[fuß: Oder Bots...] schicken: | >PRIVMSG #infothek :Hallo? Der erste Parameter des <>-Befehls bezeichnet den Empfänger der Nachricht. Der Empfänger kann entweder ein ganzer Channel (erkennbar an einem <<#>> oder <<&>> als erstes Zeichen des Names) oder eine einzelne Person sein. Sendet man an eine Person, so ist diese Nachricht für den Rest des Channels unsichtbar. Wenn uns jemand anderes Antwort (im Beispiel <>) sieht das dann so aus: | <:iblech!~iblech@13.9.ak.net PRIVMSG #infothek :Hi Das Format der Rückgabe ist dabei | :nickname!benutzername-auf-dem-client@ip-oder-hostname Auch hier zeigt der erste Parameter des <>-Befehls den Empfänger der Nachricht an. Eine private Nachricht des Benutzers <> sähe zum Beispiel so aus: | <:iblech!~iblech@13.9.ak.net PRIVMSG irc-telnet :Private Nachr. Um einen Channel wieder zu verlassen, benutzt man <>: | >PART #infothek | <:irc-telnet!~irc-telne@13.9.ak.net PART #infothek Schließlich können wir die Verbindung beenden: | >QUIT Übersicht aller Befehle ----------------------- Neben denen in der Tabelle aufgeführten Befehle können auch die schon von IRC-Clients wie <> oder <> bekannten Befehle angewendet werden, sofern man den <> (Slash) im Befehl weglässt, also zum Beispiel <> statt <>. > Befehl > Wirkung > <> > Registrierung als <> > <> > Login > <> > Eintreten in Channel > <> > Austreten aus einem Channel > <> > Sendet eine Zeile > <> > Schließt die Verbindung DICT ==== Kommen wir nun zu ertwas ganz anderem, der Online-Recherche: Das _DICTionary Protocol_ erlaubt den Zugriff auf sehr einfach zu bedienende, ASCII-basierte Online-Wörterbücher. Dabei ist es sehr stark an SMTP (siehe dazu [ref: smtp]) angelehnt, was das Lernen natürlich vereinfacht. Idee ---- Beim DICT-Protokoll gibt es üblicherweise mehrere Wörterbücher, die viele Begriffe aus unterschiedlichen Perspektiven definieren. Sucht man zum Beispiel im Wörterbuch <> nach "Windows", so wird man eine objektive (=in diesem Fall schlechte) Antwort erhalten. Sucht man jedoch in der <>-Datenbank, bekommt man die richtige Antwort zu sehen... ;-) Beispielsitzung --------------- Zunächst stellen wir mit dem Standard-Port <<2628>> des gewünschten Servers (zum Beispiel <>) eine Verbindung her: | <220 thestars.gnus dictd 1.8.0/rf on Gentoo Linux In der Bannerzeile ist neben den schon von SMTP oder NNTP bekannten Statuscodes die Versionsnummer des eingesetzten Serverprogramms enthalten. Nun kann man eine einfache Suchanfrage starten: | >DEFINE * "Munich" | <150 2 definitions retrieved | <151 "Munich" gazetteer "U.S. Gazetteer (1990)" | > (Punkt) auf einer Zeile markiert. Aber auch wenn man die exakte Schreibweise eines Begriffs nicht kennt, kann man das DICT-Protokoll benutzen: | >SHOW STRATEGIES | <111 8 databases present | MATCH * soundex "Hitchhiker" | <152 48 matches found | DEFINE jargon "heatseeker" | <150 1 definitions retrieved | <151 "heatseeker" jargon "Jargon File (4.2.3, 23 NOV 2000)" | > die Verbindung wieder geschlossen: | >QUIT | <221 bye [d/m/c = 0/0/0; 130.000r 0.000u 0.000s] Übersicht aller Befehle ----------------------- > Befehl > Wirkung > <> > Suche nach exaktem Treffer > <> > Liste aller Strategien > <> > Suche nach Treffer > <> > Schließen der Verbindung Finger ====== Mit dem Finger-Protokoll ist es möglich, zu sehen, welche Benutzer auf einem Zielsystem eingeloggt sind. Obwohl heute das Protokoll wenn überhaupt nur noch auf alten Unix-basierten Computern unterstützt wird, hat es immer noch eine Daseinsberechtigung, vor allem in größeren LANs. Idee ---- Beim Finger-Protokoll werden, ähnlich wie bei E-Mails, Benutzer mit der Syntax <> eindeutig identifiziert. Möchte man alle eingeloggten Benutzer aufgelistet haben, kann man auch den Benutzernamen weglassen, das heißt man fragt nach <<@host>>. Außerdem kann man <<@host>> weglassen, falls der User, für den man sich interessiert, auf dem Host ist, den man anfragt. Ist der <> im Request nicht der Host, den man gerade anfragt, so wird der Request[fuß: je nach Konfiguration des finger-Daemons] an den "richtigen" Host weitergeleitet, womit man also auch Benutzer innerhalb von LANs "überprüfen" (siehe Grafik [grafik: lan-finger ==> Finger-Requests werden vom Gateway weitergeleitet]) kann. : lan-finger : LAN : +--------------------------+ : | | : +------+iblech@thestars?| +-------+ +--------+ | : |Client|----------------+->|Gateway|-->|thestars| | : +------+ | +-------+ +--------+ | : | | : +--------------------------+ Beispielsitzung --------------- Das Finger-Protokoll ist, ähnlich wie das Whois-Protokoll (siehe dazu [ref: whois]), ASCII-basiert und erwartet nur eine einzige Zeile als Eingabe, nämlich die "E-Mail-Adresse" des Benutzers (wie oben beschrieben): | >iblech@thestars | < | > oder <> auch zum Ziel! IDENT ===== Ähnlich wie das Finger-Protokoll übermittelt das IDENT[fuß: _Identification_]-Protokoll (definiert in RFC 1413) keine Dateien, sondern dient vielmehr zur Authentifizierung. Über das IDENT-Protokoll kann ein Server feststellen, wem (welchem Benutzer auf dem Client) die Verbindung "gehört". So können zum Beispiel Verbindungen von "root" geblockt werden (zum Beispiel Chatten im IRC). Technische Realisierung ----------------------- Um eine Verbindung zu identifizieren, benutzt man nur die zwei betreffenden Ports, da die Hosts ja schon feststehen, Server und Client (siehe Grafik [grafik: ident ==> Das IDENT-Protokoll in zwei Schritten]). : ident : +-------+ +--------+ : |Client | GET / | Server | : |(Brow- | Port 1234 ----------> Port 70 |(Gopher-| : |ser) | (iblech) (nobody) |Daemon) | : +-------+ +--------+ : : +-------+ +--------+ : |Client | 1234, 70 | Server | : |(Ident-| Port 110 <--------- Port 5678 |(Gopher-| : |Daemon | (nobody) (nobody) |Daemon) | : +-------+ +--------+ : : +-------+ +--------+ : |Client | iblech | Server | : |(Ident-| Port 110 ---------> Port 5678 |(Gopher-| : |Daemon | (nobody) (nobody) |Daemon) | : +-------+ +--------+ Realisiert via Telnet sieht das dann zum Beispiel so aus: | >1234, 70 | <1234, 70 : USERID : UNIX :iblech Anwendungsmöglichkeiten ----------------------- Genutzt wird dieses Protokoll auch heute noch bei IRC, wie man an den ersten Zeilen jeder IRC-Verbindung feststellen kann: | >) übermittelt das aktuelle Datum (mit Zeit), weshalb es häufig für die Synchronisation der Systemuhren der einzelnen Nodes eines Netzwerkes dient. Da das Datum in Plain-ASCII übermittelt wird, kann es auch sehr gut in Shellskripten eingesetzt werden (siehe dazu [ref: daytime-script]). Technische Umsetzung -------------------- Über Daytime wird im Regelfall nur eine einzige Zeile versendet, die Datum in menschen-lesbarer Form (zum Beispiel <>) enthält. Das genaue Rückgabeformat ist undefiniert (siehe RFC 867), moderne GNU/Date-Implementationen sind aber in der Lage, viele verschiedene Formate richtig zu parsen (siehe Screenshot [shot: daytime ==> Das Datum wird bei Daytime in nur einer Zeile übermittelt]). [startshot: daytime] Connection closed by foreign host. iblech@thestars archive $ telnet mars daytime Trying 10.0.0.4... Connected to mars. Escape character is '^]'. Thu Jul 31 13:46:21 2003 Connection closed by foreign host. iblech@thestars archive $ [endshot] DNS === [label: dns]Der _Domain Name Service_ sorgt im Internet unter anderem dafür, dass man statt IP-Adressen (siehe [ref: grundlagen]) "symbolische" Namen eingeben kann, zum Beispiel <>. Zusätzlich ist es dafür verantwortlich, dass die E-Mail-Adresse <> gültig ist, obwohl auf <> kein SMTP-Server (siehe [ref: smtp]) lauscht. Mehr dazu [ref: mx]. Historie -------- Am Anfang, als das Internet noch ARPAnet hieß und _sehr_ viel kleiner war, wurden die IP-Adressen mit einer sogenannten <>-Datei übertragen, wie auch heute noch üblich in LANs. In so einer <>-Datei[fuß: gespeichert in <> auf guten Systemen] sind alle IP-Adressen mit ihren jeweiligen symbolischen Namen aufgelistet und mit Whitespace[fuß: Alles, was auf dem Bildschirm leer erscheint, also zum Beispiel der Blank und der Tabulator] getrennt: | 127.0.0.1 localhost localhost.gnus | 10.0.0.3 thestars.gnus thestars | 10.0.0.4 mars.gnus mars Diese Liste wurde dann, immer wenn sie aktualisiert wurde, an _jeden_ Teilnehmer des Internets übermittelt. Als jetzt allerdings das Internet immer größer wurde und dementsprechend immer schneller wuchs, waren die Kosten für die Verbreitung der <>-Datei nicht mehr zu tragen, weswegen ein neuer Dienst entwickelt wurde. Idee ---- Beim DNS sind alle Rechner hierarchisch geordnet (siehe Grafik [grafik: dns-hier ==> Untergliederung des Namespace]). Angefangen von der Wurzel, <<.>>, kann man Hostnamen beliebig weit verschachteln, jede Subdomain ist von ihrer Domain mit einem <<.>> getrennt. : dns-hier : +---+ : |www| : +---+ : ^ : +----+ | : |gnu.|-+ : +----+ | : ^ v +---+ : +----+ | +---+ |www| : |org.|-+ |ftp| +---+ : +----+ | +---+ ^ : ^ | +-------+ | : +-+ | +-------->|google.|-+ +---+ +---+ : |.|-+-+ +-------+ |s1.|->|www| : +-+ | +---+ +---+ : v ^ : +----+ +-----+ | +---+ +---+ : |gov.|->|nasa.|---------------+->|s2.|->|www| : +----+ +-----+ +---+ +---+ Wenn man nun zum Beispiel in einen Browser den Hostnamen <> eingibt, laufen einige Schritte ab, bis der Browser die IP des symbolischen Namens kennt: * "Hey <<.>>, was ist die IP vom Nameserver von <>?" * "Hey Nameserver von <>, was ist die IP vom Nameserver von <<.sf.net>>"? * "Hey Nameserver von <>, was ist die IP von <>?" Erst wenn die endgültige IP-Adresse bekannt ist, kann der Browser via normalen HTTP die Seite anfordern. Vor- und Nachteile ------------------ Die Lösung des oben geschilderten Problems der Verteilung der <>-Datei war damit natürlich gelöst: Jezt brauchte nicht mehr jeder Rechner alle Zuordnungen der IPs zu symbolischen Namen kennen, da es ja jetzt die Möglichkeit gab, sich von der Wurzel <<.>> bis zum Ziel "durchzuhangeln". Heute gehört <<.>> der USA[fuß: no comment.]. Wenn die USA nur eine einzige Zeile in der Konfigurationsdatei der Root-Nameserver[fuß: Es gibt aus Gründen der Redundanz 26] ändern oder löschen würde, gäbe es kein <> mehr[fuß: Zumindest nach ein paar Stunden, wenn alle möglichen Caches aktualisiert sind]. Das heißt, USA hat absolute Macht über das zentral-organisierte Internet[fuß: Allerdings kann jeder beliebiger Computer, wenn entsprechend eingerichtet, Root-Nameserver sein. So gibt es Bewegungen, wie etwa OpenNIC (<>), die eigene Root-Nameserver anbieten und demokratisch organisiert sind. Dort gibt es auch andere Top-Level-Domains, zum Beispiel <> und <>.]. Record-Typen ------------ Nun zur technischen Seite von DNS. DNS ist vielmehr als nur ein <>-Ersatz. Wo das Format der <>-Datei nur je einer IP-Adresse einen oder mehrere symbolische Namen zuordnen kann, uns keine hierarchische Ordnung besteht, unterstützt DNS viele Record-Typen. Aktuell gibt es u.A. folgende Record-Typen: * <>: Ein <>-Record ordnet einem symbolischen Namen eine IP-Adresse zu[fuß: Ein symbolischer Name kann aber durchaus auch mehrere IP-Adressen besitzen, siehe [ref: dns-robin].]. * <>: <>-Records sind praktisch das Gegenteil der <>-Records. Sie ordnen einer IP-Adressen einen (oder mehrere) symbolische Namen zu. Sie sind notwendig für Reverse-Lookups (siehe [ref: reverse-lookups]). * <>: Dieser Record, der bei eigentlich jeder Domain vorhanden ist, gibt die IP-Adresse des für das "Domain-Subnetz" zuständigen Nameservers an. Dies ist notwendig, um das schon angesprochene "durchhangeln" zu ermöglichen. * <>: Mit diesem Record ist es möglich, einem symbolischen Namen einen anderen symbolischen Namen zuzuordnen. Dies nutzen zum Beispiel eigentlich alle Hosting-Anbieter, die ihren Kunden eigene Domains ohne eigenen Server anbieten. In diesem Fall ist dann die Kundendomain nur ein Link auf DNS-Ebene auf einen der zentralen Server des Unternehmens. * <>: <>-Records werden heute für den Mailverkehr gebraucht, wie gleich noch erläutert wird. Ausfallsicherung ---------------- [label: dns-robin]Wenn man sich ersthafte Gedanken über die Ausfallsicherheit eines bestimmten Servers macht, kommt man oft zum Schluss, ein sogenannten Round-Robin-Verfahren anzuwenden. Dabei konfiguriert man mehrere Server auf die gleiche Arbeit, zum Beispiel die Webpräsenz von IBM zu liefern. Dann benutzt man <>-Records, um einem symbolischen Namen (zum Beispiel <>) mehrere IP-Adressen (die IP-Adressen der Server[fuß: Oftmals benutzt man auch nur eine IP-Adresse und verwendet dann, ohne Hilfe von DNS, einen eigenen Server, der die Last selbstständig auf die anderen verteilt.]) zuzuordnen. Der Browser, bzw. die Name-Resolver-Bibliothek des Betriebssystems, pickt sich dann eine IP-Adresse heraus, die dann verwendet wird. So wird zum einen die Last gleichmäßig auf die verfügbaren Server verteilt und die Ausfallsicherheit erhöht (ist ein Server unerreichbar, wird der nächste genommen). Ein schönes Beispiel dafür sind die rsync-Server von GNU Gentoo/Linux (siehe Screenshot [shot: robin ==> Ein symbolischer Name -- mehrere IP-Adressen]): Bei jedem erneuten Ping-Aufruf wird eine andere IP-Adresse angepingt. [startshot: robin] iblech@thestars iblech $ ping -c2 rsync.de.gentoo.org PING rsync.de.gentoo.org (62.75.149.3) 56(84) bytes of data. 64 bytes from portage.de (62.75.149.3): icmp_seq=1 ttl=243 time=119 ms 64 bytes from portage.de (62.75.149.3): icmp_seq=2 ttl=243 time=119 ms --- rsync.de.gentoo.org ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1003ms rtt min/avg/max/mdev = 119.438/119.671/119.905/0.417 ms iblech@thestars iblech $ ping -c2 rsync.de.gentoo.org PING rsync.de.gentoo.org (213.131.230.230) 56(84) bytes of data. 64 bytes from 213.131.230.230: icmp_seq=1 ttl=53 time=42.9 ms 64 bytes from 213.131.230.230: icmp_seq=2 ttl=53 time=43.4 ms --- rsync.de.gentoo.org ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1000ms rtt min/avg/max/mdev = 42.925/43.206/43.487/0.281 ms iblech@thestars iblech $ ping -c2 rsync.de.gentoo.org PING rsync.de.gentoo.org (141.12.220.13) 56(84) bytes of data. 64 bytes from 141.12.220.13: icmp_seq=1 ttl=52 time=2339 ms 64 bytes from 141.12.220.13: icmp_seq=2 ttl=52 time=1339 ms --- rsync.de.gentoo.org ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1011ms rtt min/avg/max/mdev = 1339.558/1839.396/2339.235/499.840 ms, pipe 2 iblech@thestars iblech $ [endshot] Unter Linux gibt es den Befehl <>, der einige Informationen über symbolische Namen gibt. Ausgeführt mit <> als Argument erhält man: | rsync.de.gentoo.org has address 62.75.149.3 | rsync.de.gentoo.org has address 62.138.61.2 | rsync.de.gentoo.org has address 62.245.182.9 | rsync.de.gentoo.org has address 80.190.233.33 | rsync.de.gentoo.org has address 134.147.32.57 | rsync.de.gentoo.org has address 137.226.34.228 | rsync.de.gentoo.org has address 141.12.220.13 | rsync.de.gentoo.org has address 141.71.54.40 | rsync.de.gentoo.org has address 160.45.117.66 | rsync.de.gentoo.org has address 194.97.4.250 | rsync.de.gentoo.org has address 199.108.109.25 | rsync.de.gentoo.org has address 213.131.230.230 | rsync.de.gentoo.org has address 217.172.182.32 Noch mehr Informationen sind verfügbar mit der Option <<-a>> (siehe Screenshot [shot: robinhost ==> Diese Informationen könnte man auch in die Konfigurationsdatei des BIND Nameservers eintragen]). Dort sieht man auch die zuständigen Nameserver (<> und <>). [startshot: robinhost] Trying "rsync.de.gentoo.org" ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8390 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 13, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;rsync.de.gentoo.org. IN ANY ;; ANSWER SECTION: rsync.de.gentoo.org. 86400 IN A 80.190.233.33 rsync.de.gentoo.org. 86400 IN A 62.75.149.3 rsync.de.gentoo.org. 86400 IN A 62.245.182.9 rsync.de.gentoo.org. 86400 IN A 62.138.61.2 rsync.de.gentoo.org. 86400 IN A 217.172.182.32 rsync.de.gentoo.org. 86400 IN A 213.131.230.230 rsync.de.gentoo.org. 86400 IN A 199.108.109.25 rsync.de.gentoo.org. 86400 IN A 194.97.4.250 rsync.de.gentoo.org. 86400 IN A 160.45.117.66 rsync.de.gentoo.org. 86400 IN A 141.71.54.40 rsync.de.gentoo.org. 86400 IN A 141.12.220.13 rsync.de.gentoo.org. 86400 IN A 137.226.34.228 rsync.de.gentoo.org. 86400 IN A 134.147.32.57 ;; AUTHORITY SECTION: de.gentoo.org. 86400 IN NS udns2.ultradns.net. de.gentoo.org. 86400 IN NS udns1.ultradns.net. ;; ADDITIONAL SECTION: udns2.ultradns.net. 105091 IN A 204.74.101.1 udns1.ultradns.net. 105091 IN A 204.69.234.1 Received 348 bytes from 80.81.7.3#53 in 1793 ms [endshot] MX-Records ---------- [label: mx]Wie im Kapitel über SMTP [ref: smtp] erläutert, muss es für jede Mail einen Ziel-SMTP-Server geben, der sich für sie zuständig fühlt. Dieser Servername wird eigentlich durch den Teil nach dem <<@>> der E-Mail-Adresse bestimmt. Aber wenn man mal einen einfachen Portscan (siehe [ref: portscan]) auf einen solchen Server (zum Beispiel <>) durchführt, wird man feststellen, dass dort der SMTP-Service gar nicht angeboten wird. Die Lösung des Problems liegt im <>-Record: Für praktisch jede Domain, die Mail erhalten soll, gibt es einen oder mehrere <>-Records. Diese Records stellen dann zum Beispiel die Zuordnung "der Mailserver für <> ist <>" her. So kann auch der Mailverkehr temporär auf einen Backup-Server umgeleitet werden, wenn der Haupt-Server zum Beispiel gerade gewartet wird. Anscheinend ist für die Lamer zu schwer, statt <<@web.de>> <<@smtp.web.de>> einzugeben... Abfragbar[fuß: Diese Abfrage ist übrigens vollkommen legitim und legal. SMTP-Server führen exakt das gleiche aus, wenn sie Mails zustellen] ist diese Information unter Linux mit Hilfe des schon erwähnten <>-Befehls (siehe Screenshot [shot: hostmx ==> Mit host den MX-Server einer Domain herausfinden]). Von Bedeutung sind diesmal aber nur die <>-Records, im Beispiel <> und <>. Auch hier gibt es also Redundanz: Fällt <> aus, so wird von den SMTP-Servern <> benutzt. [startshot: hostmx] Trying "web.de" ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50616 ;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 4 ;; QUESTION SECTION: ;web.de. IN ANY ;; ANSWER SECTION: web.de. 40000 IN A 217.72.195.42 web.de. 40000 IN NS nsx2.cinetic.de. web.de. 40000 IN NS nsx1.cinetic.de. web.de. 40000 IN SOA nsx1.cinetic.de. root.cinetic.de. 2003071602 28800 7200 604800 3600 web.de. 40000 IN MX 110 mx-ha02.web.de. web.de. 40000 IN MX 100 mx-ha01.web.de. ;; ADDITIONAL SECTION: nsx2.cinetic.de. 86400 IN A 217.72.194.213 nsx1.cinetic.de. 24855 IN A 217.72.193.151 mx-ha02.web.de. 40000 IN A 217.72.192.188 mx-ha01.web.de. 40000 IN A 217.72.192.149 Received 245 bytes from 10.0.0.3#53 in 774 ms [endshot] Reverse-Lookups --------------- [label: reverse-lookups]Manchmal kennt mal aber schon die IP-Adresse und möchte den symbolischen Namen haben. Um dies zu ermöglichen, könnte man entweder alle denkbaren Namen bruteforcen (schlecht) oder sich der <>-Records bedienen (gut). Nur für diese Reverse-Lookups wurde ein eigene Syntax entwickelt: Möchte man zum Beispiel den symbolischen Namen der IP-Adresse <<10.0.0.3>> erhalten, feuert man einfach einen Request nach <<3.0.0.10.in-addr.arpa.>> ab. Als Antwort erhält man dann den Namen (im Beispiel <>). Der Grund für das Umdrehen der IP-Adresse liegt in der Wertigkeit der einzelnen Abschnitte: Beim DNS ist der letzte Teil (die Top-Level-Domain) der höherwertigste. Bei IP-Adressen ist es gerade umgekehrt: Die <<.3>> im Beispiel definiert nur die einzelne Node, die <<10.>> aber ein sehr großes Subnetz. Übrigens nutzen viele SMTP-Server Reverse-Lookups aus, wenn sie überprüfen wollen, ob sie ihrem "Gesprächspartner" trauen können: Sie gehen davon aus, dass, falls es möglich ist, die IP des Gegenübers in einen symbolischen Namen aufzulösen, der Remote-Server wohl einer Firma (= gut) angehören muss. Falls nicht, wird von einem Spammer ausgeganen und die Verbindung geschlossen. Whois ----- [label: whois]Möchte man Informationen über Domains erhalten, benutzt man das Whois-Protokoll, welches von eigentlich allen Registrierungsstellen für Domains (NICs[fuß: _Network Information Centers_]) angeboten wird. Über Whois erfährt man zum Beispiel, wem die Domain gehört, wer der technische Verwalter ist und wer die Nameserver dieser Domain verwaltet. Da Whois nur eine einzige Zeile als Eingabe erwartet, ist es sehr leicht zu bedienen: Möchte man zum Beispiel Informationen über die Domain <> erhalten, so stellt man einfach eine Verbindung zum Whois-Server der NIC von <> (<>) auf Port <<43>> her und gibt | >linux.de ein. Die Antwort enthält dann neben der Copyright-Notiz und dem Disclaimer die gewünschten Informationen: | <% Copyright (c)2002 by DENIC | <% | <% Restricted rights. | <% | <% | <% Except for agreed Internet operational purposes, no | <% part of this information may be reproduced, stored in a | <% retrieval system, or transmitted, in any form or by any | <% means, electronic, mechanical, recording, or otherwise, | <% without prior permission of the DENIC on behalf of | <% itself and/or the copyright holders. Any use of this | <% material to target advertising or similar activities | <% are explicitly forbidden and will be prosecuted. The | <% DENIC requests to be notified of any such activities | <% or suspicions thereof. | < | >[fuß: <> steht für die Top-Level-Domain] zu finden ist. Muhahaha -- oder: Automatisierung ================================= In diesem Kapitel wird gezeigt, wie man die ganzen Protokolle, insbesondere HTTP, mit Linux-Tools automatisieren kann; Wer keine Linux-Kenntnisse hat, wird dieses Kapitel nicht interressieren. Whois ----- Auch wenn man mit dem Whois-Protokoll sehr viele Informationen über Domains sammeln kann, ist das manuelle auffinden des zuständigen Whois-Servers auf Dauer mühsam[fuß: auch angesichts der Tatsache, dass es auch bei Whois Weiterleitungen gibt...]. Deswegen gibt es für gute Systeme einige Whois-Clients, die diesen Vorgang automatisieren und auch den störenden Disclaimer automatisch entfernen. Der Client <> ist dabei besonders praktisch, da er bei vielen modernen Distributionen gleich mitgeliefiert wird (herunterladbar von <>). Die Bedienung ist überaus einfach (siehe Screenshot [shot: whois,client ==> whois auf pro-linux.de]). [startshot: whois,client] iblech@thestars guide $ whois pro-linux.de % Copyright (c)2002 by DENIC domain: pro-linux.de descr: Mirko Lindner descr: Schafhaus 20 descr: D-76698 Ubstadt-Weiher descr: Germany nserver: ns3.kundenserver.de nserver: ns4.kundenserver.de status: connect changed: 20030616 151056 source: DENIC [admin-c] Type: PERSON Name: Mirko Lindner ... [tech-c][zone-c] Type: PERSON Name: Gunther Stoecker Address: PCTOPIA Internet-Service Address: Lindenhof ... iblech@thestars guide $ [endshot] Daytime ------- [label: daytime-script]Das Daytime-Protokoll (beschrieben [ref: daytime]) ist sehr nützlich für die Synchronisation der Systemuhren vieler Rechner in einem Netzwerk. Aber wer will schon manuell in einem größeren LAN alle Uhren stellen? Da kann auch ein simples Shellskript eingreifen, was zum Beispiel als Cronjob[fuß: Cronjobs werden vom crond (dem Cron-Daemon) regelmäßig zu bestimmten Zeiten ausgeführt. Sie können mit Hilfe des Kommandos <> festgelegt werden.] ausgeführt werden kann: | date --set="telnet server daytime | grep :`" | hwclock --systohc --utc Die letzte Zeile synchronisiert die Systemuhr von Linux mit der RTC-Uhr[fuß: _Real Time Clock_] des BIOS. HTTP ---- [label: http-scripts]Die Automatisierung bei HTTP ist natürlich besonders interessant, da heutzutage die meisten Dinge über HTTP laufen. Man kann zum Beispiel jeden Tag eine Website herunterladen und prüfen, ob sie seit dem letzten Tag geändert wurde, und, wenn ja, sie sich automatisch per Mail zuschicken lassen. Oder man manipuliert ein _bisschen_[fuß: grin] an Votes... Lynx ^^^^ [label: lynx]Lynx, fast schon ein Klassiker, ist eigentlich nur zum text-basierten Surfen (siehe Screenshot [shot: lynx ==> Lynx auf linide.sf.net]) gedacht, lässt sich aber auch prima automatisieren. Um zum Beispiel einfach den Sourcecode einer Seite abzurufen, benutzt man | lynx -source http://linide.sf.net/ Der Quelltext wird dann auf dem Terminal angezeigt bzw kann in Pipes weiterverarbeitet werden. Will man schon die gerenderte Version sehen, benutzt man | lynx -dump http://linide.sf.net/ Das Beispiel von oben, zu prüfen ob eine Website geändert wurde und gegebenenfalls per Mail verschicken, ist dann in Shell-Skript schnell implementiert: | OMD5="$(md5sum < /tmp/seite)" | lynx -dump http://linide.sf.net/uebersicht.html > /tmp/seite | [ "$OMD5" = "$(md5sum < /tmp/seite)" ] || \ | mail -s Linux\ Guide < /tmp/seite Ein GET-Request ist klar, wie im Kapitel über HTTP [ref: get-request] beschrieben, also einfach die Parameter mit einem <> getrennt von der eigentlichen URL lynx als Parameter übergeben. POST-Requests sind ein bisschen schwieriger, sind aber auch sehr leicht möglich. Um die Abbildung [ref: img:get-forms] mit Lynx via POST umzusetzen, verwendet man | echo "name=ingo | alter=15 | os=Gentoo | ===" | lynx -post_data -source http://host/umfrage.php und bekommt den Sourcecode der Ergebnisseite zurück. Allerdings ist Lynx ein bisschen begrenzt, da er zum Beispiel nicht den Referer (siehe [ref: referer]) setzen kann, Cookies nicht automatisch akzeptiert und in einer Datei gespeichert werden können[fuß: was normalerweise unerwünscht ist, nämlich ständig Cookies anzunehmen, ist bei der Automatisierung sehr nützlich, manchmal sogar notwendig, da einige Seiten einen nur bei gesetzem Cookie akzeptieren], usf. [startshot: lynx] # Linux Guide - Übersicht (p2 of 8) .~. /V\ // \\ /( )\ ^\`~\'^ Hosted at Sorceforge.net No ePATENTS Viewable With Any Browser Burn All GIFs! Neue Artikel: