TCP/IP- Grundlagen

http://www.sirius-net.de
 

Inhaltsverzeichnis

Netzzugangsschicht *

Vermittlungsschicht *

PING *

was passiert alles? *

- Falls ja *

- Falls nein *

Zusammenfassung: *

tracerout UNIX *

IP- Header *

Die Transportschicht *

Aufgabe: *

Verwendete Protokolle *

Erste Analyse eines Hexdumps von Netzverkehr *

tcpdump *

Optionen: *

Ausgabe: *

Das 1. Wort: die ersten 4 Byte *

Das 2. Wort: *

Das 3. Wort *

Das 4. Wort *

Transportschicht 2 *

Einge wichtige Ports: *

Das Protokoll TCP *

Vergleich UDP und TCP: *

einer holt Dokumente aus dem www, ein anderer versucht, den Inhalt der übertragenen Daten herauszuholen *

Wann schlägt das Erzeugen des sockets fehl?? *

Ein Programm zum Empfangen von Packeten auf UDP- Port 1234 *

der übertragene String soll als Kommando interpretiert werden und auf dem Zielrechner ausgeführt werden. *

die wichtigsten Dienste der Anwendungsschicht *

FTP (file transfer protocol) *

- Arten von ftp: *

die wichtigsten ftp- kommandos *

kleines Praktikum: ftp- Verkehr abfangen *

TELNET *

man- pages ausdrucken: *

http - hyper text transfer protocol *

HTML- Text *

Perlinterpreter *

Grunddatentypen in Perl *

ein HTML Formular, mit Texteingabefeld, und submitbutton *

ein cgi- script erstellen *

INTERNAL SERVER ERROR *

Aufbau der Datei /etc/hosts *

DNS *

BIND *

Einrichtung des primären Nameserver *

Konfiguration eines Nameservers - Wiederholung *

Die Datei db.gz.de in /var/named *

die Datei db.192.168.17 in /var/named *

Delegierung *

4- Schichten Modell zur Kommunikation zwischen Anwendungen auf verschiedenen Hosts über beliebig komplexe Netzwerke hinweg.

Netzzugangsschicht

(Bitübertragungsschicht u. Sicherungsschicht) Vermittlungsschicht

(auch Netzwerkschicht genannt)

».« voneinander getrennt.) die Größe von Netz- und Hostanteil ist abhängig von dem höchstwertigem Bit im 1. Byte der IP- Adresse von der Netzmaske PING

folgendes Kommando wird abgesetzt: (auf Host 10.10.30.211)

ping 10.10.31.200

was passiert alles?

- Liegt der Zielrechner im selben Teilnetz?

- Netzanteil eigener IP- Adresse und IP- Adresse vom Zielrechner

- Falls ja

- ist die MAC- Adresse (Media Acess Control) des Zielrechners bekannt

- Falls ja

ethernet Frame erzeugen und auf Leitung geben

- Falls nein

- Erzeuge iene ARP- Anfrage (Adress Resolution Protocol) an alle

mit der Bitte um Bekanntgabe der MAC- Adresse (broadcast)

- Falls nein

- sieh in der ROUTINGTABELLE nach, ob ein GATEWAY zum Netz des Zielrechners bekannt ist.

-Falls ja

Erzeuge ein FRAME und schicke es an die MAC- Adresse des Gateways (falls nicht bekannt: ARP- Anfrage)

- Falls nein

Erzeuge ein FRAME und schicke es an die MAC- Adresse des DEFAULT- Gateways.

Nun kann die eigentliche Kommunikation ablaufen:

- der Quellrechner schickt ein ICNP Echo request (Internet Control Message Protocol)

- der Zielrechner antwortet mit einem ICNP echo reply

Zusammenfassung:

Folge des Ping Befehls

arp (who has) - Anfrage an alle

arp (is at) - Antwort auf vorherige Anfrage

icmp (echo request) - Aufforderung zur Abgabe eines Lebenszeichens

icmp (echo reply) - Abgabe des Lebenszeichens
 
 

tracerout UNIX

tracert MS

tracerout www.oreily.com

==> listet alle Router auf, die ein Datagramm vom Quellrechner zum Zielrechner passiert

==> Prinzip:

IP- Header

Version: 4 (IPv4)

IHL: IP Header length - wird in »Wörtern« gemessen (a 4 Byte): 5 (theoretisch bis 15; entspricht 60 Byte)

TOS: theoretisch: Routingpreferenzen;

praktisch: ignoriert

total length: theoretische obergrenze 2hoch16 Byte ==> 65 kByte

==> Fragmentierung erforderlich, falls MTU (Maximum Transfer Unit) eines

Teilnetzes zu klein ist (MTU bei Ethernet = 1500 Byte)

Identifikation ermöglichen Defragmentierung im Enpfänger

Fragment offset

TTL: - von jedem Router dekrementiert

- falls der Wert 0 erreicht wird, ICMP- Meldung: »TTL exceedet« an Absender

- verwendet u.a. von TRACEROOT (tracert) zur Wegebestimmung von Datagrammen.

Protocol: Nummer des Protocols der Transportschicht

(TCP und UDP) (==> /etc/protocols)

header checksum - Prüfsumme, wird nur über Header, aber NICHT über die Nutzdaten gebildet

==> FALSCH übertragene Nutzdaten werden NICHT erkannt

(wenn gewünscht, kann die Fehlererkennung von der Transportschicht überonmmen werden)

- IP- Datagramme mit fehlerhafter Prüfsumme werden kommentarlos

verworfen

==> IP ist UNZUVERLÄSSIG

(wenn gewünscht, kann Zuferlässigkeit durch die Transportschicht geleistet werden)

Quelladresse Je 4 Byte

Zieladresse

Optionen (max 40 Byte): i.d.R. Nix
 
 

Die Transportschicht

Aufgabe:

- Durchreichen von Datagrammen an den betroffenen Dienst derAnwendungs- schicht (ftp, telnet, http, dns) - Zu diesem Zweck werden im Header der Transportschicht unter anderem die

folgenden Felder geführt: - Quellport: (Absender)

- Zielport: (Empfänger)

- Es gilt:

- Standartdienste im Internet (Http, ftp, telnet...) werden idR unter

Standartportnummern betrieben, die weltweit einheitlich sind und

idR < 1024 sind. (Festlegung durch RFC- Request for Comments)

- ein klient, der zu einem Standartdienst eine Verindung aufbaut, er-

zeugt SEINE Quellportnummer idR DYNAMISCH, diese ist

>1023 und < 2hoch 16 ==> 65535

Verwendete Protokolle

- TCP transmission control protocol

Protokolnummer siehe /etc/protocols : 6 (IP- Header)

- UDP User datagramm protocol : 17 (IP- Header)

Konfigurationsdatei : /etc/protocols

Beide Protokolle enthalten in ihrem Header neben Quellport und Zielport auch eine über die Nutzdaten gebildete Prüfsumme.

- Reaktion auf fehlerhafte Prüfsumme bei:

- UDP: keine Weiterreichung an Anwendungsschicht

- TCP: - Verweigerung einer Empfangsbestätigung;

- nach Wartezeit schickt Absender erneut
 
 

Erste Analyse eines Hexdumps von Netzverkehr

tcpdump

- Analyse von Netzverkehr im ethernet

- ethernet ist ein Broadcastnetz

==> Jede Station kann den ganzen Verkehr in einem Segment mitverfolgen,

auch, wenn sie weder als Absender noch als Adressat beteiligt ist

==> Im normalen Betrieb interessiert sich ein ethernet- Interface nur für die

Frames, die an die eigene MAC- Adresse gerichtet sind; im promis-

kuösen Modus interessiert ses sich für alle Frames (im selben Segment)

==> per Voreinstellung versetzt tcpdump ein interface in den promiskuösen

Modus.
 
 

Syntax:

tcpdump -e -x -i eth0 icmp and host gzscsi.gz.de > /tmp/icmp

Optionen:

-e Es wird auch der link- level- header ausgegeben (Header der Netzzugangsschicht)

hier 6 Byte Mac- Adresse des Absenders

6 Byte Mac- Adresse des Zielrechners

2 Byte Typ- Feld

14 Byte insgesamt

-x die durch SNAPLEN vorgegebene Anzahl Byte (exclusive link- level- header) wird

hexadezimal angezeigt.

Voreingestellter Wert für Sneplen: 68

-i eth0 spezifiziert das abzuhorchende interface (hier: das 1. ethernet interface)

es folgt ein beliebig langer logischer Ausdruck, hier:

icmp and host gzscsi.gz.de

==> protokolliert wied ausschliesslich icmp- Verkehr, an dem der Host gzscsi.gz.de als

Sender oder Empfänger beteilligt ist

Ausgabe:

1) link level header

MAC- Adresse des Absenders: 0:80:ad:ab:8c:6f

MAC- Adresse der Zielrechners: 0:80:ad:74:1c:2

2)

Das 1. Wort: die ersten 4 Byte

IP- Header:

45 Version: 4

IHL: 5 (5 Wörter a 4 Byte == 20 Byte)

00 Type of Service (keine routing- Präferenzen)

0054 total length: 84 Byte geschnappt wurden nur 68, wegen snaplen-

voreinstellung von 68 Byte

Das 2. Wort:

0126 identification

0000 Datagramm wurde nicht fragmentiert, Df- Bit ist nicht gesetzt

( 00000000 00000000 ) --> 4000 Df- Bit gesetzt

Das 3. Wort

40 TTL: 64

01 Protocol(/etc/protocols): hier: 1 = icmp

d5df header checksum

Das 4. Wort

c0a8 1129 Quelladresse: 192.168.17.41 (gzatapi.gz.de)

c0a8 112a Zieladresse: 192.168.17.42 (gzscsi.gz.de)

Nun folgt der ICMP- Header

Typ: 00 echo reply

.............

.............Host gzatapi.gz.de antwortet mit einem icmp echo reply auf ein icmp echo

request von gzscsi.gz.de ==> Auntwort auf ein Ping!!!!!

Hinweis:

falls erforderlich vor dem Abhöhren von anderen Stationen das ethernet interface ausdrücklich in den promiskuösen Modus versetzen ifconfig eth0 promisc
 
 

Nun sollte der Verkehr zwischen anderen Stationen abgehört werden können.
 
 

Transportschicht 2

- Protokolle (TCP, UDP)

- Aufgabe (Durchreichen an Anwendungsschicht)

- Komfigurationsdatei (/etc/protocols)

- Protokollnummern (im IP- Header)

- Port < 1024 Standartdienste (RFC- geregelt)

>= 1024 (i.d.R. Dynamisch erzeugt)

- Unter UNIX enthält die Datei /etc/services eine Auflistung aller Dienste der Anwendungs-

schicht mit zugehöriger Portnummer und Protokoll der Transportschicht.

Einge wichtige Ports:

FTP 21 tcp

TELNET 23 tcp

WWW (HTTP) 80 tcp

POP3 110 tcp

SMTP 25 tcp

DOMAIN 53 udp/ tcp
 
 

Das Protokoll TCP

- tcp ist Verbindungsorientiert

mit der Übertragung von Informationen wird erst begonnen, wenn die Gegenstelle sich

zuverlässig gemeldet hat.

==> 3- Wege handshake:

- der Initiator der Vebindung sendet ein Segment mit gesetztem »syn«- bit

(syncronised)- (im TCP- header)

- wenn alles gutgeht, antwortet die Gegenstelle mit einem Segment, in dem

2 Bits gesetzt sind, »syn« und »ack«

[Voraussetzungen: -Netz des Zielrechners wird erreicht

-Host wird erreicht,

-Tcp steht auf Zielrechner zur Verfügung

-der Zielrechner muß auf dem angegebenen Port lauschen

- Erst nach Eintreffen der Bestätigung werden Daten übertragen

- Nach Beendigung der Datenübertragung wird die Verbindung ordnungs-

gemäß abgebaut.

- tcp ist zuverlässig

ein Segment gilt nur dann als zugestellt, wenn nach angemessener Zeit eine Empfangs-

bestätigung des Empfängers eintritt. Trifft keine solche ein, so wird nach einer bestimmten

Zeit automatisch erneut gesendet.

- tcp ist streamoorientiert

Große Informationsmengen werden selbstständig in kleinere Einheiten aufgeteilt und

unabhängig voneinander auf Reisen geschickt; Es werden informationen mitgeliefert,

die auf Empfängerseite ein Zusammensetzen in der Ürsprünglichen Reihenfolge gestattet.

- tcp verfügt über eine Flußkontrolle (es wird nicht schneller gesendet, als empfangen

werden kann.

Vergleich UDP und TCP:
 
UDP
TCP
Unzuverlässig Zuverlässig
Verbindungslos Verbindungsorientiert
Keine Flußkontrolle Flußkontrolle
Paketorientiert (Paket) Streamorientiert (Segment)
Geringer Verwaltungs- Overhead Hoher Verwaltungs- Overhead
Schnell und unzuverlässig Langsam und zuverlässig

 

Praktikum:

einer holt Dokumente aus dem www, ein anderer versucht, den Inhalt der übertragenen Daten herauszuholen

==> tcpdump (manpage)
 
 

Erklärung des Pearlskriptes, daß für den 1. zuständig ist

#!/usr/bin/perl Erzwingt Ausführung der nachfolgenden Anweisungen durch das

angegebenen Interpreter

# udpsend.pl kommentar (scriptname)

use IO::socket; Einbindung eines Modules, daß in Pearl Netzwerkfunktionalität bietet

$socket = new IO::Socket::INET( hier wird die Klasse socket (Ip- Adresse und Port-

Nr.) dynamisch instanziert (new).

PeerAddr => `gzzagp.gz.de`, die InstanzVar. PeerAddr wird nit dem String

gzzagp.gz.de instanziert

==> der perl- Interpreter setzt Systemaufruf

(gerhostbyname()) ab, um die IP- Adresse

in Erfahrung zu bringen.

==> der Resolver (Auflöser) wird befragt

--> DNS- Server wird befragt

--> /etc/hosts

--> NIS- Network information Services

Konfigurieren in /etc/resolv.conf

PeerPort => 1234 Zielport: 1234

Proto => `UDP`); -Protokoll: UDP

-Quellport wird dynamisch erzeugz (im Bsp.: 1026)

die "Fehler....$!" unless $socket; Wenn das Socket nicht erzeugt werden konnte,

dann Fehlermeldung ($! enthält dabei einen

geneuen Fehlertext).

Das Programm wird beendet mit einem Exit- Status ungleich 0.

print $socket `$argv[0] \n`; Der wert des ersten Aufrufparameters wird in das

socket geschrieben.

Close ($socket); socket wird geschlossen
 
 

Frage:

Wann schlägt das Erzeugen des sockets fehl??

Das Erzeugen des Sockets schlägt NICHT fehl, selbst wenn

- der Zielrechner unerreichbar ist

- das Protokoll UDP auf dem Zielrechner unerreichbar ist

- der UDP Port 1234 unerreichbar ist

Antwort:

- Wenn die Namensauflösung schiefgeht

- inerner Fehler auf dem Quellrechner (z. B.: kein freier Port mehr)
 
 

Ein Programm zum Empfangen von Packeten auf UDP- Port 1234

#!/usr/bin/perl

# udprecieve.pl

use IO::C; Socket mit S ist ein Modul

$socket = new IO::Socket::INET( $socket sit eine stinknormale Variable

LocaHost => "10.180.213.57", eigener Hostname/ IP- Adresse

LocalPort => 1234, Port, auf dem gehört werden soll

Proto => "UDP");

die "Fehler beim anlegen des Sockets: $!\n" unless $socket;

$recieved = 0; #Anzahl der empfangenen Packete

for(;($Zeile = <$socket>) ne "ende\n";$recieved++)

{

print $zeile;

}

close ($socket);

print "Erhaltene Packete: $recieved\n";
 
 
 
 
 
 

Modifikation

der übertragene String soll als Kommando interpretiert werden und auf dem Zielrechner ausgeführt werden.

Quelltexterklärungen

Use IO::Socket - einbindung des Moduls Socket.pm

- Dieses modul liegt im Verzeichnis IO

- IO ist Unterverzeichnis zu /usr/lib/perl5/5.00503/i586-linux

$socket = new IO::Socket::INET(

LocaHost => "10.180.213.57",

LocalPort => 1234,

Proto => "UDP");

- Erzeugung der "Instanz" $soket der "Klasse" Socket

- Instanzvariablen

- LocalHost

- LocalPort

- Proto

die "Fehler........ $!" unless $socket;

- Programmende mit exit- Status ungleich 0 und Fehlerausgabe auf stderr,

falls das Socket nicht erzeugt werden konnte

- $! enthält Fehlermeldung

- Erzeugug geht schief, falls

- der Port bereits belegt ist

- der Kernel UDP nicht unterstützt

$received = 0; - die Anahl der empfagenen Pakete

for(;($kommando = <$socket>) ne "ende\n") {system($kommando);}

Aktuelles Packet in die not equal Ausführung des Kommandos

Var. Kommando einlesen prog. Ende, falls

kommando "ende" war

close($socket); - Socket schließen
 
 

die wichtigsten Dienste der Anwendungsschicht

FTP (file transfer protocol)

- Holen (download) und schicken (upload) von Dateien

- Ports

- 21 Steuerdaten

- 20 Nutzdaten

- Transportprotokoll: TCP

- FTP- Anforderungen von clients werden vom ftp- Server beantwortet

- 2 MÖGLICHKEITEN:

- ftp- Server läuft permanent

- ftp- Server wird nur im Bedarfsfall gestartet

(bei SUSE- Linux: Start durch INETD)
 
 

- Arten von ftp:
 
Anonymes ftp
"normales"ftp
Kein Useraccount erforderlich Useraccount erforderlich
Username: ftp oder Anonymus

Passwort: email

 
Sicht aufs Dateisystem ist eingeschränkt Uneingeschränkte Sicht
 
i. d. R. Nur download Download und upload
Bitte installieren: Packet ftpdir, serie n  

- bei Anonymus- Anmeldung:

- Stammverzeichnis für anonymen ftp- User ist /usr/local/ftp

(nach Installation von ftpdir)

==> dieses Verzeichnis erscheint als root- Verzeichnis

==> Unterverzeichnis: pub

/ust/local/ftp/pub ==> hier alle Dokumente, die alle downloaden können sollen

abstellen

- ftpclients gibt es wie Sand am Meer
 
 

die wichtigsten ftp- kommandos

(ftp eingeben) Anzeige: ftp>_

- ? Auflistung aller ftp- kommandos

- cd Verz. -wechsel auf entferntem Rechner

- lcd Verz. -wechsel auf lokalem Rechner

- hash Anzeige der Übertragungsgeschwindigkeit (1x#/kb)

- open Verbindung zu host herstellen

- close Verbindung schließen

- get download einer Datei

- mget download von mehreren Dateien

- put upload einer Datei

- mput upload mehrerer Dateien

- ascii Textmodus

- binary binärer Modus

- bye ftp- Sitzung beenden

- ls
 
 

kleines Praktikum: ftp- Verkehr abfangen

download (normaler ftp)

ftpclient ftpserver

Drittrechner

- username und passwort abfangen (geht im klartext rüber)

- mit abgafangenem Passwort einloggen

Lösung:

Drittrechner: tcpdump -i eth0 -w /tmp/sniff host 10.180.213.51 port ftp

ftpclient: ftp 10.180.213.51

Username und Passwort eingeben

strings /tmp/sniff | egrep 'USER|PASS'
 
 

TELNET

- login auf entferntem Rechner; auf dem zielrechner muß ein Useraccount gegeben sein

- Port 23 (/etc/services)

- Protokollder Transportschicht: TCP

- ein direktes einloggen als root ist i.d.R. nicht möglich

- Verwendung :

- Fernwartung, Ferndiagnose
 
 

- Bsp.: telnet 10.180.213.58

Username und Passwort eingeben

Aufgabe: analysieren sie den Datenstrom, der während einer telnet- Sitzung

übertragen wird

Suchen sie die Benutzereingabe

S

U

[RETURN]

man- pages ausdrucken:

man -t | lpr
 
 

http - hyper text transfer protocol

- das protocol, daß das WWW zusammenhält

- Port: 80

- Transportprotokoll: TCP

- www - Client: Browser: netscape

Internet Explorer

Opera

Star Office

lynx (textorientiert)

- www - Server: apache (in der UNIX/ LINUX- Welt)

- wird automatisch gestartet beim hochfahren

- Dämon: httpd (anzeigen von Dänonen: ps ax)

- Stammverzeichnis für Webdokumente:

/usr/local/httpd/htdocs (html- documente)

/cgi-bin (cgi- scripts)

Erster Test:

- netscape Starten

- URL: http://10.180.213.xx

- Default- Dokument: index.html

- Startverzeichnis
 
 

HTML- Text

<HTML>

<HEAD>

<TITLE> Crocodile Action.... </TITLE>

</HEAD>

<BODY>

<IMG SRC = "crocodile-thumb.gif">

<H1> Crocodile........ </H1> H1= header (H1- H6) == Formatvorlagen

<EM> Please send......</EM> emphasized == Text anders darstellen, als normal

<P> neuer Absatz (paragraph)

<HR> (horzontal rule == horizontale Linie)

<P>

<FORM METHOD= "POST" ACTION= "/cgi-bin/comments">

POST: Benutzereingaben werden vom cgi. Script von stdin entgegengenommen

- Datenvolumen unbegrenzt

GET: Benutzereingaben stehen in der Ungebungsvariablen $QUERY_STRING

- Datenvolumen begrenzt (ca. 1- 2 Kb, Betriebssystemabhängig)

Name: <INPUT TEXT NAME="feed_name" SIZE=36> <BR>
 
 

Br- break entspr. new line

Email: <INPUT TEXT NAME="feed_email" SIZE=36>

<P>

<TEXTAREA NAME= "feed_comments" ROWS=8 COLS=40> </TEXTAREA>

Textfeld: 8 Zeilen

40 Spalten

scrollbar

<P>

<INPUT TYPE= "submit" VALUE= "Send Comments">

<INPUT TYPE= "reset" VALUE= "Clear Form">

</FORM> Feld für Benutzereingaben Ende

<P> <HR> >P>

Creation Date: <EM> Jun 18,1994 </EM>

<P>

<ADRESS><A HREF= "rjones.html"> DRJ </A></ADRESS>

ADRESS: Stilattribut, wie EM

A: ...Verweise oder Marken...hier:

HREF: Hyper text reference (link)

</BODY>

</HTML>
 
 
 
 
 
 

Übertragung:

name=wert&name=wert&......

space => +

Sonderzeichen =>%xx --> xx = 2 hexadezimal- Zahlen

Bsp.:

Name:_hansi_müller________

Email:_hm@cdi.de__________

Textfeld:

feed_name=hansi+m%xxller&feed:email=hm%xxcdi.de

Perlinterpreter

Variable wird auf rjones@pa.dec.com gesetzt

%ENV ist ein Hash, in dem die Schlüssel die Namen von Umgebungsvariablen sind und

die zugehörigen Werte die Werte dieser Umgebungsvariablen sind.

==>Assoziatives array oder hash - Array, in dem der index, über den zugegriffen

wird, ein beliebiger String ist.

Bsp.: HOME hat den Wrt /home/gz1

PS2 -"- >

TZ -"- GMT

EDITOR -"- vi
 
 

===> Zugriffsoperator für hashs ist in perl: {}

Bsp.:

$ENV{'HOME'} liefert /home/gz1

$ENV{'EDITOR'} liefert vi

Grunddatentypen in Perl

- Skalar $v1 = 47.3;

$v2 = "lalla";

$v3 = 47;

$v2 = $v3;

- arrays @a1 = (1,3,9,80);

$a1[2]; #9

@a2 = (47.3,"blabla", 980 "gaga");

$a2[3]; #"gaga"

@a1 = @a2;

- hash %h1 =("hund"=>"dog","vogel"=>"bird");

#ein hash mit den Schlüsseln "hund" und "vogel" und

den Werten "dog" und "bird"

$h1{"vogel"}; #"bird"

if($ENV{'REQUEST_ METHOD'} eq 'POST') {

- %ENV ist ein voedefiniertes hash

- Zugriff auf das hash %ENV mit dem Schlüssel REQUESR_METHOD;

der Zugehörige Wert ist POST oder GET, abhängig von Eintrag

<FORM METHOD=.....> im html Dokument

==> wenn die Formularmethode NICHT POST ist, wird dynamisch ein HTML- Dokument generiet, daß eine Fehlermeldung im Browser des Absenders anzeigt

==> der Typ der Daten wird dem Browser mit der Zeile

"Content_type: text/html\n\n" bekanntgegeben

==> alles, was das cgi- script auf stdout schreibt, wird an den Browser weitergeleitet

sonst:

read(stdin, $buffer; $ENV{'CONTENT_LENGTH'});

- lese von stdin

- schreibe in $buffer

- Es werden CONTENT_LENGTH Byte in die Variable $buffer eingelesen

feed_name=.....&feed_email=.....&feed_comments=....

@pairs = split(/&/, $buffer);

- trennt Inhalt von &buffer; Trennzeichen &

- schreibt Ergebnis in Array @pairs => Elemente sind Strings der Form: name=wert

foreach $pair (@pairs) { forschleife - durchläuft nacheinender alle Elemente von @pairs

($name;$value) = split(/=/; $pair,2);

- $name enthält nacheinender die Namen aller Formularelemente

- $value enthält die zugehörigen Benutzereingaben

$value =~ tr/+/ /; - jedes + wird durch ein space ersetzt

$value =~s /%([a-fA-F0-9]{2})/pack("C", hex($1))/eg;

hex- ziffer

2x

treffer in $1 ablegen

- g global jeder Treffer wird zum ersetzen verwendet

- e evaluable/ execute auswerten

Quintessenz: in $value wird jede folge von % und zwei hexadezimalen ziffern durch das entsprechende Byte ersetzt.
 
 
 
 
 
 

$FORM{$name}= $value;

- es wird ein hash namens FORM aufgabaut, dessem Schlüssel die Felder im HTML- dokument sind und dessen Werte die zugehörigen Benutzereingaben sind

if[$FORM{feed_email} !~^[\-a-zzA-Z0-9_\+ \. \t\/\@%]+$/){

in der Email- Adresse beliebig oft eines dieser Zeichen, aber kein anderes !!

t tabstop

die eingabe bekommt die shell zu sehen

wenn Eingabe: `rm -r /' dann Kommandosubstitution des Shell

=====>>>>shell führt script aus, macht rm -r ==>>>das wars!!!!!

&evil_characters Funktionsaufruf

open (MESSAGE," | mail $webmaster $FORM{feed_email}");

- jeder Schreibzugriff auf das Filehandle MESSAGE wird an das UNIX-

Kommando mail gepiped

- webmaser bekommt email

- eingeber auch!

Verschiedene Anweisungen

Print MESSAGE "To $webmaster\n";

- damit wird ans Kommando mail weitergepiped

erst wenn EOF kommt, close (MESSAGE);

legt mail los

&thank_you;

Praktikum:

ein HTML Formular, mit Texteingabefeld, und submitbutton

- in /usr/local/httpd/htdocs erstellen

- Methode POST

ein cgi- script erstellen

- in /usr/local/httpd/cgi-bin erstellen

- der Name muß zum METHOD=... Eintrag im html- Dokument passen

- x- Recht für script nicht vergessen!!

- #!/bin/sh - shell solls ausführen

- read cmd

- diverse cuts und tr`s um das eigentliche Kommando herauszufiltern

- echo "Content-type: text/html"

- echo (Leerzeile)

- echo "<HTML>"

- $cmd

- echo "</BODY>"

- echo "</HTML>"

- Eingabe: ein beliebiges UNIX- Kommando

- das UNIX- Kommando wird in einem CGI- script auf dem Zielrechner

ausgeführt

- der vom Kommando erzeugte Output auf stdout wird in ein dynamisch

erzeugtes html- dokument eingebettet, daß dem Browser geschickt wird

Überlegungen:

INTERNAL SERVER ERROR

- echo ` cmd=(bel. Kommando)& (bel. String zur Kontrolle) | cgi- script
 
 

Aufbau der Datei /etc/hosts

- Kommentarzeilen beginnen mit einem #

- die erste Zeile, die KEINE Kommentarzeile ist, sollte IMMER lauten:

127.0.0.1 localhost (damit ist es möglich TCP/IP Funktionalität ohne echte

Netzanbindung zu testen)

- alle folgenden Zeilen sollten den folgenden Aufbau haben:

IP- Adresse FQDN (fully qualified domain name) Aliases (beliebig viele)

Bsp.: 10.180.213.50 vornerechts.cdi.u1 vornerechts vorne vr
 
 

DNS

- weltweit verteilte, hirarchische Datenbank

- an der Spitze steht die root- domain

- darunter liegen die Top- Level- Domains

-->in den USA organisatorisch

==> com mil edu org gov net int arpa - außerhalb der USA zweibuchstabige Länderkürzel

- darunter Second- Level Domains

- Informationen zum DNS- Namensraum werden vom NAMESERVER geliefert

- man unterscheidet 2 Typen:

==> primär

- bezieht die Informationen, die er liefert, aus eigenen Dateien

==> sekundär

- bezieht die Informationen, die er liefert, von einem anderen Nameserver

- Datenübertragung zum sekundären NS wird als FILE ZONE TRANSFER

bezeichnet

- Zweck von primären/ sekundären Nameservern

- Lastverteilung

- Ausfallsicherheit/ Redundanz

- Verwaltung von informationen zum DNS- Namensraum erfolgt in RECORDS;

- es gibt 3 Klassen von records :

- Internet (die einzige, die für uns von Bedeutung ist)

- hesiod

- chaosnet

- Zu jeder Record- Klasse gibt es diverse Record- Typen

- REVERSE ADRESS MAPPING:

- zu einer IP- Adresse den/die Hostnamen ermitteln

- DOMAIN - ein Teilbaum im DNS- Namensraum

- ZONE - der NICHT delegierte Teil einer Domäne

- ein und derselbe Host kann für bestimmte Zonen primärer und für ANDERE Zonen sekundärer Nameserver sein

- RESOLVER - der Teil der Client- Software, der eine Namensauflösung anfordert

- Aufruf z. B.: gethostbyname();.....

- QUERYS - iterative - es wird lediglich die Adresse eines näherliegenden Servers geliefert

- rekursive - es wird solange gefragt, bis die Antwort geliefert werden kann

- sonstige Leistungen von DNS:

- MAIL- ROUTING- Informationen

Bsp.: mail hans.binder@t-online.de

==> Information, an welche(n) host(s) diese mail weiterzuleiten ist , wird von

MX- Records geliefert.

- Verwaltungsinformationen

BIND

(Berkeley Internet Name Distribution)

- eine in der UNIX. Welt stakr verbreitete Implementierung von DNS

- Installation unter LINUX: Serie N --> Packet: bind

==> Software zum Aufsetzen eines Nameservers

Praktikum

- Jede Reihe setzt einen primäran und einen sekundären NS auf

- Informationen, die geliefert werden

- Hostname --> IP- Adresse

- IP- Adresse--> Hostname

Bildung des hostnamens

nachname.cdi.u1

Für jeden Host soll dabei mindestens ein Alias- Name vergebeben werden
 
 
 
 

Hinweise

- Nameserver heißt named

- named liest beim Start die Konfigurationsdatei /etc/named.boot ein

diese Dtei enthält Angaben über:

- root- Name- server

- Verzeichnis in dem diverse Datendateien abgelegt sind

- Dateien mit Zonendaten

- Fehler/Status- meldungen werden von named nur in die Datei

/var/log/messages geschrieben (tail -f /var/log/messages)

( läuft in Endlosschleife und zeigt die neu

hinzugekommenen letzten 10 Dateien an)

--> starten: named (primär)

==> wenns gutgeht:

--> starten: named (sekundär)

==> wens gutgeht:

--> sekundärer NS macht automatisch FILE ZONE TRANSFER

Test: ping auf Hostnamen, für die kein Eintrag in /etc/hosts existiert
 
 

Einrichtung des primären Nameserver

Erste Schritte:

1. /etc/named.boot erstellen

- diectory /var/named hierhin wechselt der nS beim Start

; Eintrag für de Root- Name- Server

cache . root.cache

; Festlegung der Dateien mit Zonendaten (primär od. Sekundär)

primary cdi.u1 == db.cdi.u1

; dto. für reverse adress mapping

primary c == db.10.180.213

2. die Datei db.cdi.u1

- 1 SOA record (start of authority) = primäre NS

- Parameter: Seriennummer

Refresh

Retry

Expire

TTL == alle in Sekunden

- NS record - für jeden NS ein NS- record

- A- record - für jeden host in der domain ein A- record für die Abbildung

von FQDN auf IP- Adresse

- C- record - für jeden Aliasnamen eines jeden hosts ein C- Name record
 
 

3. die Datei db.10.180.213 für das reverse- adress- mapping

- 1 SOA record (start of authority) = primäre NS

- NS record - für jeden NS ein NS- record

Konfiguration eines Nameservers - Wiederholung

es wird ein Host eingerichtet, de an der Weltweiten Namensraum. Datenbank Abfragen stellt.

Dämon: named -->schreibt Meldungen nach: /var/log/messages

Name Server liest beim Start die Datei ein: /etc/named.boot

Einträge in /etc/named.boot:

directory /var/named

- das Vezeichnis, in das named nach dem Start wechselt

- hier sucht er seine weiteren Dateien

primary gz.de db.gz.de

- named ist PRIMÄR für die Domain GZ.DE

- sucht ALLE für gz.de relevanten Daten (records) in der datei db.gz.de

in Verzeichnis /var/named

primary 17.168.192.in-addr.arpa db.192.168.17

- named ist PRIMÄRER für die Domain 17.168.192.in-addr.arpa

- und sucht alle relevanten Daten (SOA-,NS.-PTR- records) in der Datei

db.192.168.17 im Verzeichnis /var/named

==> inhaltliche Deutung:

Problem: welch(e) Name(n) hat der Host mit der IP-Adresse 193.180.212.176

Lösung: siehe Blatt

cache . Root.cache //root-name-server

hier stehen die Adressen der root-name-server (Datei: root.cache

im aktuellen Verzeichnis "." (also hier /var/named)

Die Datei db.gz.de in /var/named

SOA- Record Start Of Authority

Seriennummer: wenn SN vom sekundary < SN-primary, dann File Zone Transfer

wenn Änderung auf Primary, dann manuell SN-Primary

hochsetzen, damit sekundary fzt macht

expire wie lange betrachtet sekundaryseine daten als gltig

min TTL

NS

A hier steht zum voolqualifizierten namen die IP- Adresse

MX mailexchanger
 
 

die Datei db.192.168.17 in /var/named

zuständig für REVERSE ADRESS MAPPING

- einen SOA-record

- ein NS- record

- PTR- record je IP- Adresse
 
 

/var/log/messages

/etc/resolv.conf

search gz.de

Wirkung:

ping gzscsi :automatische Ergänzung: ==> gzscsi.gz.de

nameserver

- befragter NS

- bis zu 3 NS (durch whitespace getrennt) dürfen angegeben werden

/etc/host.conf

order host bind

==> legt die Reihenfolge fest, in der der Resolver dienste zur

Namensauflösungbefragt

hier: erst /etc/hosts, dann Nameserver befragen

Bsp.: order host nis bind

multi on gibt es zu einem Hostnamen mehr als eine Adresse in /etc/hosts, werden

bei multi on ALLE Adressen geliefert
 
 

Delegierung

Aufgabe: cdi.u1 wird in 4 subdomains aufgeteilt

- r1.cdi.u1......r4.cdi.u1

- subdomains r3 und r4 werden delegiert

- primary für cdi.u1 ist h1.r1.cdi.u1

die Datei db.cdi.u1 auf h1.r1.cdi.u1

cdi.u1. IN SOA h1.r1.cdi.u1. root.h1.r1.cdi.u1 (

----

----

----

)

cdi.u1. IN NS h1.r1.cdi.u1.

; hier secondary

r3.cdi.u1. IN NS h2.r1.cdi.u1.

r4.cdi.u1. IN NS h3.r1.cdi.u1.

h1.r1.cdi.u1. IN A ........
 
Netzzugang 
Vermittlung 
Transport 
Anwendung 
Nutzdaten
MAC

MTU

arp

rarp

Dhcp

tcpdump

-e = LLH

Gateway muß über Mac- adresse

ansprechbar sein

IP Protocol

Aufgabe:

von Host zu Host

IP- Header

min 20 Byte

max 60 Byte

ICMP

Typen

- echo request

- echo reply

- destin.

Unreachable

- ttl exceedet

UDP

TCP

Aufgabe:

Zustellung von 

Nutzdaten von 

Anwendung zur

Vermittlung

Portnummern:

<1024 (standart)

in /etc/services

RFC

Telnet (Port 23)

telnet www.cdi.de

port 80 geht auch 

get (RETURN)

verwandt: rlogin

ftp: Port21 steuer

Port20 daten

anonym- ftp:

/usr/local/ftp/pub

apache

serverrootverz.: /usr/local/httpd

--/htdocs

index.html

--/cgi-bin

html:

formulare etc.

--ACTION

--METHOD

 
         

Kiste gerade hochgefahren

In Netscape URL: http://www.cdi.de

resolver guckt in /etc/hosts.conf Zeile: order

welcher Nameserver? /etc/resolv.conf

kontakt: erkennt an den Netzanteilen der beteiligten IP- Adresse, ob NS

im gleichen Teilnetz ist.

Sonst: Gateway über MAC- Adresse

arp whohas GW schickt MACadresse

Datagramm wird erzeugt

...........................................

DNS = Port 53

im Nutzdatenteil von http läuft eun Get um nach erfolgreichem Verbindungsaufbau das

Dokument index.html zu holen.

Buch

Ports, Header, ICMP- Tabellen, etc.