Galileo Computing < openbook > Galileo Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Vorwort
1 Einleitung
2 Die Installation
3 Erste Schritte
4 Linux als Workstation für Einsteiger
5 Der Kernel
6 Die Grundlagen aus Anwendersicht
7 Die Shell
8 Reguläre Ausdrücke
9 Konsolentools
10 Die Editoren
11 Shellskriptprogrammierung mit der bash
12 Die C-Shell
13 Benutzerverwaltung
14 Grundlegende Verwaltungsaufgaben
15 Netzwerkgrundlagen
16 Anwendersoftware für das Netzwerk
17 Netzwerkdienste
18 Mailserver unter Linux
19 LAMP
20 DNS-Server
21 Secure Shell
22 Die grafische Oberfläche
23 Window-Manager und Desktops
24 X11-Programme
25 Multimedia und Spiele
26 Prozesse und IPC
27 Bootstrap und Shutdown
28 Dateisysteme
29 Virtualisierung und Emulatoren
30 Softwareentwicklung
31 Crashkurs in C und Perl
32 Einführung in die Sicherheit
33 Netzwerksicherheit überwachen
A Lösungen zu den einzelnen Aufgaben
B Kommandoreferenz
C X11-InputDevices
D MBR
E Die Buch-DVDs
F Glossar
G Literatur
Stichwort

Download:
- ZIP, ca. 15,7 MB
Buch bestellen
Ihre Meinung?

Spacer
 <<   zurück
Linux von Johannes Pl&ouml;tner, Steffen Wendzel
Das umfassende Handbuch
Buch: Linux

Linux
geb., mit 2 DVDs
1302 S., 39,90 Euro
Galileo Computing
ISBN 978-3-8362-1704-0
Pfeil 15 Netzwerkgrundlagen
  Pfeil 15.1 Grundlegendes zu TCP/IP
    Pfeil 15.1.1 Network-Access-Layer
    Pfeil 15.1.2 Internet-Layer
    Pfeil 15.1.3 Transport-Layer
    Pfeil 15.1.4 Application-Layer
  Pfeil 15.2 Grundlegendes Netzwerk-Setup
    Pfeil 15.2.1 Hostname setzen
    Pfeil 15.2.2 Netzwerkadressen für alle
    Pfeil 15.2.3 Wireless LAN
    Pfeil 15.2.4 DHCP
    Pfeil 15.2.5 /etc/hosts
    Pfeil 15.2.6 /etc/networks
    Pfeil 15.2.7 /etc/resolv.conf
    Pfeil 15.2.8 Nun gibt es aber ein Problem ...
    Pfeil 15.2.9 Windows und Namensauflösung
  Pfeil 15.3 Grundlagen des Routings
    Pfeil 15.3.1 Routing-Administration: route
    Pfeil 15.3.2 Router aufsetzen
  Pfeil 15.4 Netzwerkverbindungen
    Pfeil 15.4.1 Datenaufkommen von Schnittstellen
    Pfeil 15.4.2 Protokollstatistiken
    Pfeil 15.4.3 Aktive TCP-Verbindungen
    Pfeil 15.4.4 Listen-Ports
    Pfeil 15.4.5 ARP-Cache
    Pfeil 15.4.6 tcpdump
  Pfeil 15.5 Mit Linux ins Internet
    Pfeil 15.5.1 Das Point-to-Point Protocol
    Pfeil 15.5.2 Einwahl mit einem Modem
    Pfeil 15.5.3 Einwahl über DSL
  Pfeil 15.6 Zusammenfassung
  Pfeil 15.7 Aufgaben


Galileo Computing - Zum Seitenanfang

15.4 Netzwerkverbindungen  Zur nächsten ÜberschriftZur vorigen Überschrift

Das Tool netstat kennen Sie bereits. netstat ist in der Lage – der Name lässt bereits darauf schließen – eine Übersicht über den »Status« des Netzwerks zu geben. Das beinhaltet zum Beispiel eine Übersicht über bestehende IPv6-Verbindungen oder die Nutzung der Netzwerkschnittstellen. Letztere erhält man im Übrigen auch via ifconfig.


Galileo Computing - Zum Seitenanfang

15.4.1 Datenaufkommen von Schnittstellen  Zur nächsten ÜberschriftZur vorigen Überschrift

Das Datenaufkommen kann entweder durch ifconfig oder via netstat abgefragt werden.

$ ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:50:04:E9:AE:1B
inet addr:192.168.0.3  Bcast:192.168.0.255
Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1207 errors:0 dropped:0 overruns:0 frame:0
TX packets:1086 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:126448 (123.4 Kb)  TX bytes:171926 (167.8 Kb)
Interrupt:9 Base address:0xd400
[netstat]
$ netstat -i|egrep 'Iface|eth0'
Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0  1500  0 1254  0      0      0      1121      0      0      0 BMRU

Listing 15.26  Informationen zur Ethernet-Schnittstelle

Gehen wir die wichtigsten Teile dieser beiden Ausgaben einmal durch. Zunächst fällt vielleicht der Parameter HWaddr 00:.... auf. Dabei handelt es sich um die sogenannte MAC-Adresse der Ethernet-Schnittstelle. [MAC steht für Medium Access Control.] Die Adressierung auf Layer 1 des TCP/IP-Schichtenmodells verwendet diese MAC-Adresse zur Identifikation. Die Internet-Adresse sowie die Netzmaske sind Ihnen bereits bekannt. Die Broadcast-Adresse (Bcast) hingegen ist Ihnen wahrscheinlich neu. Über diese Adresse lassen sich alle Hosts in diesem (Sub-)Netzwerk zugleich erreichen (sofern diese darauf konfiguriert sind, auf Broadcast-Nachrichten zu antworten).

Die Flags UP, BROADCAST, RUNNING und MULTICAST signalisieren, dass das Interface aktiv ist, Daten empfangen kann und Broadcasting sowie Multicasting unterstützt. [Multicasting ist eine spezielle Möglichkeit, um, ähnlich wie beim Broadcasting, mehrere Systeme auf einmal anzusprechen. Näheres erfahren Sie im RFC zum IGMP-Protokoll.]

Außerdem ist zu sehen, dass die maximale Datenmenge (Maximum Transmission Unit, MTU) 1500 Bytes beträgt – der Standardwert für Ethernet-Netzwerke. Die Routing-Metrik dieses Interfaces hat den Minimalwert »1«. Das bedeutet, dass Datenpakete auf direktem Wege zum Ziel gelangen. Weitere Informationen stellen unter anderem die bereits über das Interface übermittelte Datenmenge, die Anzahl der Kollisionen und die Anzahl der versendeten bzw. erhaltenen Frames dar.

Die Ausgabe von netstat -i ist der von ifconfig inhaltlich recht ähnlich. Die Spalten MTU und Met geben die bereits bekannte Maximum Transmission Unit sowie die Metrik der Schnittstelle an. Die RX- und TX-Spalten geben an, wie viele Pakete empfangen bzw. gesendet wurden. Dabei stehen die Abkürzungen »OK« jeweils für erfolgreich versandte bzw. empfangene Pakete, »ERR« für fehlerhafte Pakete, »DRP« für gedroppte (verworfene) Pakete und »OVR« für Overruns.


Galileo Computing - Zum Seitenanfang

15.4.2 Protokollstatistiken  Zur nächsten ÜberschriftZur vorigen Überschrift

Allgemeine Protokollstatistiken kann netstat ebenfalls ausgeben. Dazu übergibt man einfach den Parameter -s. Von System zu System scheint einem die Datenmenge dabei entweder zu genügen oder überraschend groß zu sein. Zu sehen ist zunächst ein Aufruf des Kommandos unter Linux und später – allerdings stark verkürzt und nur, um Ihnen einen Einblick in die Statistikfähigkeit des BSD-Kernels zu geben – eine Ausgabe des gleichen Kommandos unter OpenBSD.

linux# netstat -s
Ip:
1339 total packets received
0 forwarded
0 incoming packets discarded
1309 incoming packets delivered
1309 requests sent out
Icmp:
29 ICMP messages received
2 input ICMP message failed.
ICMP input histogram:
destination unreachable: 15
echo requests: 14
29 ICMP messages sent
0 ICMP messages failed
ICMP output histogram:
destination unreachable: 15
echo replies: 14
Tcp:
1 active connections openings
2 passive connection openings
0 failed connection attempts
0 connection resets received
1 connections established
1310 segments received
1265 segments send out
0 segments retransmited
0 bad segments received.
1 resets sent
Udp:
0 packets received
0 packets to unknown port received.
0 packet receive errors
15 packets sent
TcpExt:
ArpFilter: 0
4 delayed acks sent
2 packets directly queued to recvmsg prequeue.
820 packets header predicted
TCPPureAcks: 191
TCPHPAcks: 888
TCPRenoRecovery: 0
TCPSackRecovery: 0
TCPSACKReneging: 0
TCPFACKReorder: 0
TCPSACKReorder: 0
TCPRenoReorder: 0
TCPTSReorder: 0
TCPFullUndo: 0
TCPPartialUndo: 0
TCPDSACKUndo: 0
TCPLossUndo: 0
TCPLoss: 0
TCPLostRetransmit: 0
TCPRenoFailures: 0
TCPSackFailures: 0
TCPLossFailures: 0
TCPFastRetrans: 0
...
...
openbsd$ netstat -s
ip:
10609 total packets received
0 bad header checksums
0 with size smaller than minimum
0 with data size < data length
0 with header length < data size
0 with data length < header length
0 with bad options
0 with incorrect version number
0 fragments received
0 fragments dropped (duplicates or out of...
0 malformed fragments dropped
0 fragments dropped after timeout
0 packets reassembled ok
10570 packets for this host
39 packets for unknown/unsupported protocol
0 packets forwarded
0 packets not forwardable
0 redirects sent
5819 packets sent from this host
5122 packets sent with fabricated ip header
0 output packets dropped due to no bufs, etc.
       0 output packets discarded due to no route
0 output datagrams fragmented
0 fragments created
0 datagrams that can't be fragmented
0 fragment floods
0 packets with ip length > max ip packet size
0 tunneling packets that can't find gif
0 datagrams with bad address in header
0 input datagrams checksum-processed by h...
0 output datagrams checksum-processed by h...
icmp:
...
igmp:
...
ipencap:
...
tcp:
...
udp:
...
esp:
...
ah:
...
etherip:
...
ipcomp:
...
carp:
...
pfsync:
...
ip6:
...
icmp6:
...
rip6:
...

Listing 15.27  Protokollstatistiken


Galileo Computing - Zum Seitenanfang

15.4.3 Aktive TCP-Verbindungen  Zur nächsten ÜberschriftZur vorigen Überschrift

Um uns eine Liste aktiver TCP-Verbindungen zu verschaffen, verwenden wir wieder einmal unser Lieblingstool netstat, denn TCP-Verbindungen aufzulisten zählt zu seiner Spezialität. Für jede aktive TCP-Verbindung gibt netstat -a das Flag ESTABLISHED aus. [Es gibt noch diverse andere TCP-Flags wie FIN_WAIT. Stevens beschreibt diese Flags hervorragend in seinem leider etwas veralteten Buch »TCP/IP Illustrated Vol. 1«.]

netstat -a | grep ESTABLISHED
tcp 0 48 faust.sun:ssh 192.168.0.1:40406 ESTABLISHED

Listing 15.28  Aktive TCP-Verbindungen

Durch einen Doppelpunkt getrennt sind dabei zunächst der eigene Host und der lokale Port aufgelistet und anschließend der Remote-Host und dessen Port.


Galileo Computing - Zum Seitenanfang

15.4.4 Listen-Ports  Zur nächsten ÜberschriftZur vorigen Überschrift

Auf fast jedem Rechner im Netzwerk laufen ein paar Dienste, etwa SSH oder ein Webserver. Diese Dienste benötigen in aller Regel (und es gibt tatsächlich Ausnahmen) einen offenen Port, um Daten entgegenzunehmen. Geöffnete TCP-Ports werden in netstat mit dem Flag LISTEN versehen; unter UDP sieht man nur einen Eintrag ohne Flag. netstat zeigt Ihnen sogar aktive UNIX-Domain-Sockets an.

$ netstat -a|more
Active Internet connections (including servers)
Proto Recv-Q Send-Q Local Address Foreign Ad. (state)
tcp   0  0  eygo.40406        faust.ssh   ESTABLISHED
tcp   0  0  eygo.nntp         *.*         LISTEN
tcp   0  0  localhost.nntp    *.*         LISTEN
tcp   0  0  *.ssh             *.*         LISTEN
tcp   0  0  *.www             *.*         LISTEN
tcp   0  0  localhost.submissi *.*        LISTEN
tcp   0  0  localhost.smtp    *.*         LISTEN
Active Internet connections (including servers)
Proto Recv-Q Send-Q Local Address Foreign Ad. (state)
udp   0  0  *.*               *.*
udp   0  0  *.syslog          *.*
Active Internet connections (including servers)
Proto Recv-Q Send-Q Local Address Foreign Ad. (state)
tcp6  0  0  localhost.nntp    *.*         LISTEN
tcp6  0  0  *.ssh             *.*         LISTEN
tcp6  0  0  localhost.submissi *.*        LISTEN
tcp6  0  0  localhost.smtp    *.*         LISTEN
Active UNIX domain sockets
...

Listing 15.29  netstat -a

Verwendet man bei netstat -a zusätzlich den Parameter -n, so unterdrückt man die Adressauflösung und sieht blanke IP-Adressen. Das Gleiche gilt für die Dienstbezeichnungen bei den einzelnen Ports. netstat bezieht die Port-Bezeichnungen aus der Datei /etc/services – in diese können gegebenenfalls auch eigene Dienste eingetragen werden. Diese Datei baut sich in der Form »Name Portnummer/Protokoll« auf: [Analoge Informationen zu den einzelnen Protokollen finden Sie in der Datei /etc/protocols.]

tcpmux          1/tcp
echo            7/tcp
echo            7/udp
...
netstat         15/tcp
...
chargen         19/udp
ftp-data        20/tcp
ftp             21/tcp
ssh             22/tcp
ssh             22/udp
telnet          23/tcp
...

Listing 15.30  Auszug aus /etc/services


Galileo Computing - Zum Seitenanfang

15.4.5 ARP-Cache  Zur nächsten ÜberschriftZur vorigen Überschrift

Die Hardwareadresse, also die MAC-Adresse, von Ethernet-Schnittstellen hatten wir bereits erwähnt. Über das (Reverse) Address Resolution Protocol (ARP) tauschen die einzelnen Hosts Informationen über die MAC-Adressen und IP-Adressen aus. Diese Informationen werden im sogenannten ARP-Cache abgelegt, den man über das Programm arp abfragen und administrieren kann. In diesem ARP-Cache werden Zuordnungen zwischen IP- und MAC-Adresse hergestellt. Dadurch kann also von der MAC-Adresse auf die IP-Adresse geschlossen werden und umgekehrt.

Die Informationen sind (bis auf wenige explizit zu konfigurierende Ausnahmen) dynamisch, das heißt, sie werden nach einer bestimmten Zeit wieder gelöscht und müssen neu abgefragt werden, was netzwerkorganisatorische Gründe hat. Den aktuellen ARP-Cache kann man mit arp -a abfragen.

# arp -an
? (192.168.0.2) at <incomplete> on eth0
? (192.168.0.1) at 00:50:BF:11:35:A5 [ether] on eth0

Listing 15.31  ARP-Cache abfragen

Der Rechner im Listingbeispiel scheint also in letzter Zeit keine Kommunikation mit einem Host, der nicht im ARP-Cache steht, geführt zu haben. Um nun beispielsweise den Host 192.168.0.5 zu erreichen, müssen die Rechner zunächst untereinander ARP-Informationen austauschen. Diesen Austausch erzwingen wir, indem wir eine TCP/IP-Kommunikation (der Einfachheit halber über das Tool ping) mit dem Host starten.

# ping 192.168.0.5
PING 192.168.0.5 (192.168.0.5) 56(84) bytes of data.
64 bytes from 192.168.0.5: icmp_seq=1 ttl=128
time=0.279 ms
\^C
--- 192.168.0.5 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss,
time 0ms
rtt min/avg/max/mdev = 0.279/0.279/0.279/0.000 ms

Listing 15.32  Anpingen des Hosts 192.168.0.5

Nun enthält der ARP-Cache auch die IP- und MAC-Adresse des Hosts 192.168.0.5:

# arp -an
? (192.168.0.2) at <incomplete> on eth0
? (192.168.0.1) at 00:50:BF:11:35:A5 [ether] on eth0
? (192.168.0.5) at 00:00:CB:59:FD:BE [ether] on eth0

Listing 15.33  Der aktuelle ARP-Cache


Galileo Computing - Zum Seitenanfang

15.4.6 tcpdump  topZur vorigen Überschrift

Sniffing

Hin und wieder (zum Beispiel bei der Entwicklung von Netzwerksoftware oder zur Fehlererkennung bei der Netzwerkadministration) ist es notwendig, sich die Netzwerkpakete anzusehen, die auf einer Schnittstelle ankommen und gesendet werden. Diese Tätigkeit bezeichnet man als Sniffing (Schnüffeln). Sniffing wird oft auch von Angreifern in Tools integriert, die dann Passwörter aus dem Datenstrom, der über eine Netzwerkschnittstelle läuft, herausfiltern oder Verbindungsinformationen filtern, die für ein erfolgreiches Hijacking benötigt werden. Da wir nun aber keine bösen Absichten verfolgen, werden wir Ihnen einfach das Standardtool vorstellen, mit dem Sie diese Funktionalität zur Fehlererkennung nutzen können.

Dieses Tool nennt sich tcpdump. Da es je nach Betriebssystem auf eine andere Art und Weise an die Daten der Netzwerkschnittstelle herankommt, verwendet tcpdump die Packet Capture Library (PCAP). Diese Library stammt von einigen Entwicklern der University of California (dort kommt auch BSD her) und kann systemunabhängig in jede mögliche Sniffing-Software integriert werden – sehr nützlich.

Startet man das Tool als normaler Nutzer, wird man feststellen, dass man keine Berechtigung zum Sniffen hat. Daher kann auch kein normaler Nutzer Netzwerkdaten auf diese Art und Weise ausspähen, was sicherheitstechnisch eindeutig von Vorteil ist.

Startet man tcpdump als Superuser, gibt man entweder eine gewünschte Schnittstelle an, auf der man sniffen möchte, oder aber man gibt keine an und lässt tcpdump selbst eine Schnittstelle wählen (was nicht immer das gewünschte Resultat bringt).

Übrigens: Läuft tcpdump erst einmal, läuft es so lange, bis man es mit Strg + C beendet.

# tcpdump
tcpdump: listening on ne3
18:24:18.376898 eygo.sun.38307 > yleigu.sun.ssh: P
3028219738:3028219786(48) ack 3768993598 win 16384
<nop,nop,timestamp 427496211 202175> (DF) [tos 0x10]
18:24:18.377807 yleigu.sun.ssh > eygo.sun.38307: P
1:49(48) ack 48 win 10880 <nop,nop,timestamp 351730
427496211> (DF) [tos 0x10]
18:24:18.497974 eygo.sun.38307 > yleigu.sun.ssh: P
48:96(48) ack 49 win 16384 <nop,nop,timestamp
427496212 351730> (DF) [tos 0x10]
18:24:18.498655 yleigu.sun.ssh > eygo.sun.38307: P
49:97(48) ack 96 win 10880 <nop,nop,timestamp 351743
427496212> (DF) [tos 0x10]
18:24:18.542230 eygo.sun.38307 > yleigu.sun.ssh: P
96:144(48) ack 97 win 16384 <nop,nop,timestamp
427496212 351743> (DF) [tos 0x10]
18:24:18.544097 yleigu.sun.ssh > eygo.sun.38307: P
97:145(48) ack 144 win 10880 <nop,nop,timestamp
351747 427496212> (DF) [tos 0x10]
18:24:18.554155 yleigu.sun.ssh > eygo.sun.38307: P
145:705(560) ack 144 win 10880 <nop,nop,timestamp
351748 427496212> (DF) [tos 0x10]
18:24:18.554254 eygo.sun.38307 > yleigu.sun.ssh: .
ack 705 win 15824 <nop,nop,timestamp 427496212
351747> (DF) [tos 0x10]
18:24:18.554609 yleigu.sun.ssh > eygo.sun.38307: P
705:769(64) ack 144 win 10880 <nop,nop,timestamp
351748 427496212> (DF) [tos 0x10]
18:24:18.750072 eygo.sun.38307 > yleigu.sun.ssh: .
ack 769 win 16384 <nop,nop,timestamp 427496212
351748> (DF) [tos 0x10]
^C
10 packets received by filter
0 packets dropped by kernel

Listing 15.34  tcpdump

In unserem Fall hat sich tcpdump die Schnittstelle ne3 ausgewählt, um darauf zu sniffen. Dabei wird (sofern nicht der Parameter -p angegeben wurde) diese Schnittstelle in den sogenannten Promiscuous Mode geschaltet. In diesem Modus werden alle Netzwerkpakete angenommen, die die Schnittstelle annehmen kann (auch wenn sie nicht an die Schnittstelle adressiert sind). In Netzwerken mit einem Hub bekommt man auf diese Weise alle Daten des Netzwerks; in Netzwerken mit einem Switch ist dies nicht der Fall. Ob sich eine Netzwerkkarte im Promiscuous Mode befindet, zeigt ein Aufruf von ifconfig durch das PROMISC-Flag.

$ ifconfig ne3
ne3: flags=8b63<UP,BROADCAST,NOTRAILERS,RUNNING,
PROMISC,ALLMULTI,SIMPLEX,MULTICAST>
mtu 1500
address: 00:50:bf:11:35:a5
media: Ethernet autoselect (10baseT)
inet 192.168.0.1 netmask 0xffffff00 broadcast
192.168.0.255
inet6 fe80::250:bfff:fe11:35a5%ne3 prefixlen
64 scopeid 0x1

Listing 15.35  Promiscuous Mode

Doch nun zurück zur Ausgabe von tcpdump. Wie ist diese Ausgabe zu interpretieren? Leider ist zum wirklichen Verständnis dieser Daten eine detaillierte Kenntnis der TCP/IP-Protokolle vonnöten, die wir in diesem Buch nicht voraussetzen können. Wir wollen allerdings zumindest den Aufbau und einige Details der Ausgabe erläutern.

Jedes empfangene Paket wird (standardmäßig ohne zusätzliche Parameter zur Detailausgabe) in einer Zeile ausgegeben. Zunächst sieht man den Zeitpunkt, an dem das Paket erhalten wurde – den sogenannten Timestamp (etwa 18:24:18.376898). Darauf folgt in diesem Fall (denn es handelt sich um eine TCP-Verbindung) der Quellhost mit Quellport, worauf der Zielhost und Zielport zu sehen sind. Im obigen Listing kommuniziert also der Host eygo.sun als SSH-Client mit dem SSH-Server yleigu.sun. Die restlichen Ausgaben betreffen Details der TCP-Verbindung, etwa das gesetzte PUSH-Flag, die Sequenz- und Acknowledgement-Nummer und die Window-Size. Zu sehen ist auch das Flag DF (vom Englischen don't fragment), das in Verbindung mit dem IP-Header steht, sowie der Type-of-Service-Wert des IP-Headers.

18:24:18.376898 eygo.sun.38307 > yleigu.sun.ssh: P
3028219738:3028219786(48) ack 3768993598 win 16384
<nop,nop,timestamp 427496211 202175> (DF) [tos 0x10]

Listing 15.36  Die erste Zeile der Ausgabe

Möchte man sich nun einen genaueren Überblick über solche Pakete verschaffen, verwendet man den Parameter -v oder auch -X für hexadezimale Ausgaben des Inhalts. Übrigens: Um eine noch detailliertere Ausgabe zu erzielen, kann man anstelle von -v auch -vv verwenden.

18:38:59.185321 eygo.sun.28042 > yleigu.sun.www: P[tcp sum ok] 1:18(17)
ack 1 win 16384 <nop,nop,timestamp 427497973 439551> (DF) [tos 0x10]
(ttl 64, id 44354, len 69)
0000: 4510 0045 ad42 4000 4006 0c0c c0a8 0001  ................
0010: c0a8 0003 6d8a 0050 e1cc 1457 ced0 2310  ................
0020: 8018 4000 9d3a 0000 0101 080a 197b 19f5  ..@..:.......{..
0030: 0006 b4ff 4845 4144 202f 2048 5454 502f  ....HEAD / HTTP/
0040: 312e 300d 0a                             1.0..
18:38:59.185615 yleigu.sun.www > eygo.sun.28042: . [tcp sum ok] 1:1(0)
ack 18 win 5792 <nop,nop,timestamp 439806 427497973> (DF) (ttl 64, id
38895, len 52)
0000: 4500 0034 97ef 4000 4006 2180 c0a8 0003  E..4..@.@.!.....
0010: c0a8 0001 0050 6d8a ced0 2310 e1cc 1468  .....Pm........h
0020: 8010 16a0 9f63 0000 0101 080a 0006 b5fe  ... .c..........
0030: 197b 19f5

Listing 15.37  Auszug aus tcpdump -vvX

Zu sehen ist eine HTTP-Kommunikation zwischen den beiden oben erwähnten Hosts. Dabei wird ein HTTP HEAD-Request von eygo.sun an yleigu.sun gesendet, der daraufhin dieses TCP-Datenpaket bestätigt.



Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.






 <<   zurück
  Zum Katalog
Zum Katalog: Linux, Ausgabe 2011






Linux, Ausgabe 2011
Jetzt bestellen


 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Katalog: Linux-Server






 Linux-Server


Zum Katalog: Linux Hochverfügbarkeit






 Linux Hoch-
 verfügbarkeit


Zum Katalog: LPIC-1






 LPIC-1


Zum Katalog: Debian GNU/Linux






 Debian GNU/Linux


Zum Katalog: openSUSE 11.2






 openSUSE 11.2


Zum Katalog: Shell-Programmierung






 Shell-Programmierung


Zum Katalog: Ubuntu GNU/Linux






 Ubuntu GNU/Linux


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo




Copyright © Galileo Press 2011
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


[Galileo Computing]

Galileo Press, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, info@galileo-press.de