protokollanalyse mit wireshark

Rechnernetze, Dr. Ing. Kemmerich Noshaba Cheema

Protokollanalyse mit WIRESHARK®

Protokoll zum Modul Rechnernetze SoSe13

Noshaba Cheema

Abgabedatum: 26.07.2013Hochschule Bremen

1


Inhaltsverzeichnis

1. Theoretischer Teil 3

1.1 Protokoll 3

1.2 ISO/OSI-Referenzmodell 3

1.3 TCP/IP-Referenzmodell 7

1.4 Kommunikation zwischen den Schichten 11

2. Praktischer Teil 13

2.1 Versuchsbeschreibung 13

2.2 Beschreibung der Versuchsdurchführung 13

2.3 Ergebnisse mit Beschreibung und Screen Shots 13

2.4 Fehler- und Problembeschreibung 27

2.5 Fazit 27

3. Literatur- und Quellenverzeichnis 29

3.1 Literaturquellen 29

3.2 Internetquellen 30

4. Erklärung zur selbstständigen Abfassung des Protokolls 31

2


Protokollanalyse mit WIRESHARK ®

1. Theoretischer Teil

Dies ist der theoretische Teil der Arbeit. Er soll ein Grundwissen vermitteln, was benötigt

wird, um den praktischen Teil, der darauf folgt, besser zu verstehen.

1.1 Protokoll

Ein Protokoll ist eine Menge von Regeln, die festhält zu welchem Zeitpunkt oder in welcher

Reihenfolge welcher Vorgang durch wen oder was veranlasst wurde. Eine Vereinbarung, die

beispielsweise den Aufbau und Abbau von Verbindungen, die Formate der auszutauschen-

den Nachrichten [6], den benutzen Code und Absprachen über eine Fehlererkennung und

Fehlerkorrektur [23], die zu verwendende Betriebsart, Übertragungsgeschwindigkeit der

Nachrichten oder den Ablauf der Übertragung, wie z.B. welche Station wann und wie lange

senden darf [18], zwischen Computern [23] bestimmt, nennt man Kommunikationsprotokoll

[6].

Realisiert werden Protokolle größtenteils über Software, teilweise aber auch über Hardware

[23].

1.2 ISO/OSI-Referenzmodell

Um die Struktur und Funktion von Datenkommunikationsprotokollen zu beschreiben, entwi-

ckelte die International Standards Organization (ISO) 1984 [24] ein Architekturmodell, das

man als „Open Systems Interconnect Reference Model“ (OSI) bezeichnet [13]. Im Wesentli-

chen beschreibt dieses Modell eine Möglichkeit der Aufteilung der Kommunikationsproble-

me in Schichten („layers“) [6]. Jede Schicht kann man somit weiterentwickeln ohne dabei die

gesamte Kommunikation zu beeinflussen [24].

Solche Kommunikationsarchitekturen beschreiben abstrakt, unabhängig von Hardware und

Technologie, drei Aspekte von Kommunikation: Datenaustausch (Interkommunikation), Da-

teninterpretation (Interoperation) und Systemverwaltung [30].

Durch das OSI-Modell sollte erreicht werden, dass unterschiedliche Netz-Komponenten ver-

schiedener Hersteller durch die Verwendung einheitlicher Schnittstellen zusammen einge-

setzt werden können [10].

Man sollte das OSI-Modell jedoch nicht zu genau nehmen. Der wahre Wert des Referenzmo-

dells ist, dass es eine Verständnis darüber liefert wie verschiedene Komponenten miteinan-

3


der kommunizieren. [26]

Das OSI-Referenzmodell hat sieben Schichten. Folgende Prinzipien haben zu der Sieben-

schichtigkeit geführt:

1. Bei einem neuen Abstraktionsgrad sollte eine neue Schicht entstehen.

2. Jede Schicht sollte eine genau definierte Funktion erfüllen.

3. Die Funktionswahl sollte international genormte Protokolle berücksichtigen.

4. Die Grenzen zwischen den Schichten sollten so gewählt werden, dass der Informati-

onsfluss über die Schnittstellen möglichst gering ist.

5. Die Schichten sollten groß genug gewählt sein, dass keine Notwendigkeit besteht un-

terschiedliche Funktionen auf eine Schicht zu packen, aber auch so klein, dass die ge-

samte Architektur nicht unhandlich wird. [27]

Das Schichtmodell ist aufgebaut wie eine Zwiebel: Jede aufeinanderfolgende Schicht schließt

die ihr unterliegenden Schichten ein [16].

Die sieben Schichten des ISO/OSI-Referenzmodells:

Layer 1:

Name: Bitübertragungsschicht („Physical Layer“) [27]

Kommunikationseinheit: Bit [27]

Funktion: Definition und Kontrolle der physikalischen Eigenschaften des Übertragungsweges

[13].

Protokolle oder Standards: EIA1 RS-2322, EIA RS-4493, IEEE4 8025 [5]

Layer 2:

Name: Sicherungsschicht („Data Link Layer“) [27]

Kommunikationseinheit: Frame, Rahmen [27]

Funktion: Für eine zuverlässige Übertragung der Daten über die physikalischen Verbindungen

[13]. Besteht aus zwei Unterschichten: „Media Access Control“ (MAC) und „Logical Link Con-

trol“ (LLC). MAC verwaltet die Sendung von elektrischen Signalen über das physikalische Me-

dium mit anderen Hosts im lokalen Netz. MAC-Adressen bestehen aus 12 Hexadezimalzif-

1 „Eletronic Industries Allience“ - Unternehmensverbund zur Entwicklung von Standards zur Gewährleistung von Zusammenarbeit von Geräten unterschiedlicher Hersteller [28]

2 RS-232: Standard für serielle Schnittstellen bei Computern [28]3 RS-449: Standard zur Definition der mechanischen und funktionalen Charakteristika der Interfaces zwischen den

Datenendeinrichtungen und den Datenübertragungseinrichtungen [28]4 „Institute of Electrical and Electronics Engineers“ [28]5 IEEE 802: Projekt der IEEE das Netzwerkstandards auf den OSI-Schichten 1 und 2 festlegt [28]

4


fern, die in der Regel in Zweiergruppen aufgeteilt sind (Bsp. 20-10-7a-3e-94-c7 oder

cc:af:78:bb:73:1d). MAC-Adressen sind die physikalischen Adressen der Geräte (Hardware-

adressen). [19]

LLC liefert Kontrollfluss, Fehlerkontrolle und Synchronisation. [19]

Protokolle oder Standards: Ethernet6, Token Ring7, IEEE 802.118 [5]

Layer 3:

Name: Vermittlungsschicht („Network Layer“) [27]

Kommunikationseinheit: Paket [27]

Funktion: Verwaltung der Verbindungen zwischen Rechnern im Netz für höhere Schichten

[13]. Liefert eine eindeutige Adresse zu jedem Host im Netz und Mittel zur Verbindung von

Layer 1 und 2 durch Router. IP ist das meist verwendete Protokoll der Schicht 3. IP-Adressen

sind Beispiele von Layer 3 Objekten. IPv4 Adressen bestehen aus vier Gruppen von Nummern

zwischen 0 und 255 wie 192.168.0.1 oder 10.1.55.223. IPv6 Adressen bestehen aus 32 Hexal-

dezimalziffern, die in Vierergruppen aufgeteilt sind (Bsp. 2001:0db8:85a3:08d3:1319:8a2e:

0370:7344 oder 2001:0db8:0000:0000:0000:ff00:0042:8329). [19]

Protokolle oder Standards: IP („Internet Protocol“), OSPF („Open Shortest Path First“),

ICMP(„Internet Control Message Protocol“), RIP („Routing Information Protocol“), ARP („Ad-

dress Resolution Protocol“), RARP („Reverse Address Resolution Protocol“) [5]

Layer 4:

Name: Transportschicht („Transport Layer“) [27]

Kommunikationseinheit: TPDU („Transport Protocol Data Unit“) [27]

Funktion: Verbindet die höheren OSI-Schichten (Layer 5 bis 7) mit den unteren OSI-Schichten

(Layer 1 bis 3). Die Transportschicht unterscheidet jede Anwendung durch die Zuordnung ei-

ner Portnummer. Port 80 steht beispielsweise für die Anwendung HTTP, Port 53 für DNS [19].

Firewalls und ACLs („Access Cotrol List“) machen Zugriffssteuerungen basierend auf diesen

Portnummern [25]. TCP und UDP sind die am häufigsten anzutreffenden Protokolle der

Transportschicht [19].

Protokolle oder Standards: TCP („Transmission Control Protocol“), UDP („User Datagram Pro-

tocol“), SPX („Sequence Packet Exchange“) [5]

6 Vorherrschende LAN-Technologie [20]7 Netztypografie in Form einer Ringtypologie [26]8 IEEE 802.11: IEEE-Standard für Kommunikation zwischen drahtlosen LANs (WLANs) [28]

5


Layer 5:

Name: Kommunikationssteuerungsschicht („Session Layer“) [27]

Kommunikationseinheit: SPDU („Session Protocol Data Unit“) [27]

Funktion: Liefert Mechanismen zur Einrichtung und Aufrechterhaltung einer Netzverbindung

oder Sitzung (engl. „Session“) zwischen zwei Hosts [19]. Um eine Sitzung aufrechtzuerhalten

muss sie vorher von den jeweilig implementierten Firewall bzw. ACL Regeln der Hosts oder

der Router akzeptiert werden [25].

Protokolle oder Standards: SQL („Structured Query Language“), X-Window9, ASP („AppleTalk

Session Protocol“), SCP („Secure Copy“), NFS („Network File System“), RPC („Remote Proce-

dure Call“) [5]

Layer 6:

Name: Darstellungsschicht („Presentation Layer“) [27]

Kommunikationseinheit: PPDU („Presentation Protocol Data Unit“) [27]

Funktion: Standardisiert das Format der Daten auf dem Netz [13]. In dieser Schicht geschieht

die Umwandlung, Formatierung, Ver- und Entschlüsselung der Daten in ein für die Übertra-

gung akzeptables und kompatibles Format [5]. Zum Beispiel könnten Audio-, Video- oder

Bilddateien, die zwischen Systemen transferiert werden MP3, MPEG4 oder GIF Codierung

verwenden. Die Kompression von Dateien z.B. mit einem Lempel-Ziv Algorithmus wie er häu-

fig in den Zip-Datei Archivierungen verwendet wird, geschieht ebenfalls auf dieser Ebene

[19].

Protokolle oder Standards: MPEG („Moving Picture Experts Group“), JPEG („Joint Photogra-

phic Experts Group“), TIFF („Tagged Image File Format“) [5]

Layer 7:

Name: Anwendungsschicht („Application Layer“) [27]

Kommunikationseinheit: APDU („Application Protocol Data Unit“) [27]

Funktion: Liefert die Protokolle für Anwendungen wie E-Mail oder HTTP [19].

Protokolle oder Standards: HTTP („Hypertext Transfer Protocol“), FTP („File Transfer

Protocol“), TFTP(„Trivial File Transfer Protocol“), DNS („Domain Name System“), SMTP („Sim-

ple Mail Transfer Protocol“), SFTP („Secure File Transfer Protocol“), SNMP („Simple Network

Management Protocol“), Rlogin („Remote Login“), BootP („Bootstrap Protocol“), MIME

9 Protokoll zum Bau einer grafischen Oberfläche

6


(„Multipurpose Internet Mail Extensions“), POP3 („Post Office Protocol Version 3“) [5]

Jede der Schichten stellt der ihr jeweils übergeordneten Schicht bestimmte Dienstleistungen

zur Verfügung. Die Kommunikation zwischen benachbarten Schichten erfolgt über sogenann-

te „Primitives“. Der CCITT10-Standard X.210 beschreibt vier Typen von Primitives in Zusam-

menhang mit Dienstleistungen der 1. bis 6. Schicht des OSI-Modells [11]:

„Request“ Anforderung einer bestimmten Dienstleistung durch den Anwender

„Indication“ Vermittlung eines Anstoßes einer Dienstleistung an den Dienstleistungs-lieferanten durch den Dienstleistungsanwender oder dem Lieferanten selbst (z.B. beim Abbau einer Verbindung im Fehlerfall)

„Response“ Bestätigung an den Anwender einer vorher empfangenen Anzeige (Indi-cation) einer Dienstleistung

„Confirm“ (Abschluss-)Bestätigung an den Dienstleistungslieferanten einer vorher-gegangenen Anforderung (Request)

Abb. 1[11] | Dienstprimitives im OSI-Referenzmodell

1.3 TCP/IP-Referenzmodell

Wir wenden uns nun vom OSI-Referenzmodell dem Referenzmodell zu, das im APARNET

(„Advanced Research Projects Agency Network“), dem Urahn aller Rechnernetze, und seinem

Nachfolger, dem weltweiten Internet, eingesetzt wird. Das US-Verteidigungsminiterium ent-

wickelte das APARNET als ein Forschungsnetz, was zunächst hunderte von Universitäten und

Regierungsbehörden miteinander über gemietete Telefonstandleitungen verband. Als später

10 „Comité Consultatif International Téléphonique et Télégraphique“ (dt. Internationales Telegraph und Telefon Beratungskomitee) [28]

7


Satelliten- und Funknetze hinzukamen, warfen die verwendeten Protokolle bei der Zusam-

menarbeit der Netze Schwierigkeiten auf, worauf man eine neue Referenzarchitektur benö-

tigte [28]. Das Ziel des neuen Referenzmodells war also mehrere Netze nahtlos miteinander

zu verbinden. Die Umstellung begann Anfang der 80er-Jahre und war offiziell 1983 beendet –

das Ergebnis heißt bis heute Internet. Das neue Referenzmodell wurde später nach den zwei

primären Protokollen das TCP/IP-Referenzmodell genannt [20].

Jede Webseite im Internet, jedes Foto, Bild oder jeder Film wird über TCP/IP übertragen. Für

viele ist diese Fähigkeit als Medium für beliebige Anwendungen zu fungieren die wichtigste

Eigenschaft. Trotzdem kranken viele Multimedia-Anwendungen an der schlecht regulierbaren

Bandbreite. Quality-of-Service-Markmale waren in der Ursprungsversion noch nicht vorgese-

hen. Um nachträglich auch diese Anwendungen zu ermöglichen, musste TCP/IP durch Proto-

kollzusätze wie RSVP („Ressource Reservation Protocol“) nachgerüstet werden. Die grundle-

genden Bestandteile der aktuellen Version wurden seit ihrer Einführung nicht verändert,

trotzdem sind Kompatibilitätsprobleme sehr selten, was im Hinblick auf die Aktualisierungs-

flut moderner Programme beeindruckend ist. [20]

Das TCP/IP-Referenzmodell besteht aus vier Schichten: der Anwendungsschicht, Host-

zu-Host- oder Transportschicht, Internetschicht und der Netzzugangsschicht. [5]

Layer 1: [5]

Name: Netzzugangsschicht

Kommunikationseinheit: Frame (TCP, UDP)

Funktion: Kombiniert die Funktionen der Sicherungs- und Bitübertragungsschicht des OSI-

Modells. Zu den Funktionen gehören unter anderem das Umwandeln von MAC-Adressen zu

IP-Adressen und die Kapselung („Encapsulation“) von IP-Datagrammen zu Frames, die vom

Netz weitergeleitet werden. Sie befasst sich ebenfalls mit der Kommunikation zwischen Hard-

ware und Software, Verbindungen, Spannungspegel des Stroms und der Verkabelung.

Protokolle oder Standards: ARP, RARP, EIA RS-232, EIA RS-449, IEEE 802

Layer 2: [5]

Name: Internetschicht

Kommunikationseinheit: Datagramm (TCP, UDP)

Funktion: Isoliert die Protokolle der höheren Schichten von den darunterliegenden Netzde-

tails und administriert Verbindungen durch das Netz. Dafür benutzt sie Protokolle, die eine

8


logische Übertragung von Paketen über das Netz liefern. Außerdem kontrolliert sie die Kom-

munikation zwischen den Hosts und weist den Netzknoten IP-Adressen zu.

Protokolle oder Standards: IP, ICMP

Layer 3: [5]

Name: Host-zu-Host Transportschicht

Kommunikationseinheit: Segment (TCP), Paket (UDP)

Funktion: Ähnlich zur OSI-Transportschicht. Führt Ablaufplanungen der Pakete durch, stellt

eine zuverlässige Ende-zu-Ende-Datendienste zur Verfügung, versichert Integrität der Daten

und liefert eine fehlerfreie Datenübertragung durch Fehlererkennung und -korrektur.

Protokolle oder Standards: TCP, UDP

Layer 4: [5]

Name: Anwendungsschicht

Kommunikationseinheit: Stream (TCP), Nachricht (UDP)

Funktion: Äquivalent zur Anwendungs-, Präsentations- und der Kommunikationssteuerungs-

schicht des OSI-Modells. Anwendungen kommunizieren über Sockets und Ports.

Protokolle oder Standards: SMTP, POP3, HTTP, FTP

TCP/IP-Modell ISO/OSI-Modell

Anwendungsschicht Anwendungsschicht

Darstellungsschicht

Kommunikationssteuerungsschicht

Host-zu-Host-Transportschicht Transportschicht

Internetschicht Vermittlungsschicht

Netzzugangsschicht Sicherungsschicht

BitübertragungsschichtTbl. 1 | TCP/IP- und ISO/OSI-Referenzmodell im Vergleich

Die Terminologie des OSI-Modells hilft uns das TCP/IP-Modell zu beschreiben. Das TCP/IP-

Modell folgt nicht strikt dem siebenschichtigen Modell, benutzt es aber als Referenz.

9


Abb. 2[30]| Die Architektur von TCP/IP

Die Protokolle TCP und IP sind nur zwei der für den Aufbau einer vollständigen Kommunikati-

onsarchitektur notwendigen Komponenten, aber TCP/IP wird meist als Abkürzung für die ge-

samte Kommunikationsarchitektur, wie sie ursprünglich das Verteidigungsministerium der

USA spezifiziert hatte, verwendet, da diese beiden Protokolle die primären Protokolle bei der

Kommunikation zweier Netzteilnehmer darstellen. Offiziell hat sie aber die Bezeichnung IPS

(„Internet Protocol Suite“) oder zu deutsch Internetprotokollfamilie. [30]

Im TCP/IP-Modell verifiziert das TCP die korrekte Auslieferung von Daten und stellt Möglich-

keiten zur Fehlerbehandlung bereit. Wenn ein Fehlerfall aufgetreten ist, führt TCP eine er-

neute Übertragung aus der Daten aus bis der Empfänger ein valides Paket erhalten hat. Diese

Funktion basiert auf eine Bestätigung („Acknowledgement“), die dem übertragenden Rech-

ner vom Empfänger zurückgesandt werden sollte. Wenn ein Paket nicht bestätigt wurde, sen-

det der Rechner von dem das Paket stammte es erneut. Der empfangende Computer organi-

siert dann die erhaltenen Pakete in ihrer angemessenen Reihenfolge. [5]

Der IP Anteil im TCP/IP ist verantwortlich für das Senden von Paketen von Netzknoten (Rou-

ter) zu Netzknoten bis es zu seiner Zieladresse gelangt. Es routet die Information von einem

Rechner zu einem Netz einer Unternehmenseinrichtung. Von dort gelangt es zu einem regio-

nalen Netz und zum Schluss zum Internet. Das Routing geschieht über die IP-Adressen, die

jedem Rechner zugeteilt wurden. [5]

10


Abb. 3[20]| Routingentscheidung

1.4 Kommunikation zwischen den Schichten

Beim OSI- und TCP/IP-Modell werden Daten beim senden durch das Netz in der Kommunika-

tionsarchitektur nach unten gereicht. Jede Schicht fügt eine Kontrollinformation an, um die

korrekte Auslieferung von Daten sicherzustellen. Diese Steuerinformationen bezeichnet man

als „Header“ (Kopf), weil sie vor den zu übertragenden Daten platziert werden. Jede Schicht

betrachtet die gesamten, von der oberen Schicht empfangenen Informationen als Daten und

stellt ihren eigenen Header vor diese Informationen. Das Hinzufügen solcher Transportinfor-

mationen in jeder Schicht bezeichnet man als Kapselung („encapsulation“). Beim Empfangen.

Der Daten passiert genau das Gegenteil. Jede Schicht entfernt ihren Header, bevor die Daten

an die darüberlegende Schicht weitergereicht werden. [13]

Jeder Header enthält Adressierungsinformationen, Parameter und Informationen darüber,

wie die verschiedenen Schichten die verkapselten Informationen zu benutzen haben. [26]

11


Abb. 4[26]| Kapselung von Daten im ISO/OSI-Referenzmodell

Abb. 5[13]| Kapselung von Daten im TCP/IP-Referenzmodell

Die folgenden Protokolle sind die Kernprotokolle und Starads des TCP/IP-Modells und die da-

zugehörigen OSI-Schichten in denen sie operieren: [5]

12


Layer 2 – Ethernet, Token Ring und IEEE 802.11

Layer 3 – IP und ICMP

Layer 4 – TCP und UDP

Layer 7 – SSH, DNS, HTTP, SSL etc.

2. Praktischer Teil

Dieser Teil der Arbeit ist die Protokollanalyse mithilfe von WIRESHARK®. WIRESHARK® ist ein Netz-

protokoll Analysierer, der den Verkehr im Computernetz erfasst. Diese erfassten Daten, kann

man als Nutzer interaktiv durchstöbern. [32]

2.1 Versuchsbeschreibung

Mithilfe von WIRESHARK® wollen wir uns anschauen wie die Datenübertragung zwischen zwei

Netzteilnehmern in der Praxis aussieht, indem wir beispielsweise eine Internetseite aufrufen.

Zusätzlich werden die von WIRESHARK® erfassten Netzprotokolle, die bei diesem Vorgang ange-

zeigt werden analysiert und näher erläutert.

2.2 Beschreibung der Versuchsdurchführung

Bevor wir mit der Analyse mit WIRESHARK® beginnen, müssen wir unseren eigenen PC nach un-

serer IP Adresse, Subnetzmaske, Default Gateway, MAC-Adresse, Netzadresse des benutzten

Subnetzes und die Broadcast Adresse des benutzten Subnetzes untersuchen. Dies benötigen

wir, um zu erfahren welche Daten von uns bzw. zu uns übertragen werden.

Als nächstes starten wir WIRESHARK® und rufen eine beliebige Internetseite auf, und schauen

uns an zu welcher oder welchen MAC-Adresse(n) unsere Anfragen gelangen.

Anhand von WIRESHARK® kann man ebenfalls die zuvor beschriebene Kapselung des TCP/IP-Mo-

dells gut sehen.

Danach analysieren wir unsere ARP-Tabelle, löschen diese dann wieder, starten WIRESHARK®

neu, browsen im Web und zeigen uns die Tabelle nochmal an, und notieren, was uns auffällt.

Anschließend wird die IP-Datagramm-, TCP-Segment- und die UDP-Paket-Struktur er-

läutert und zu guter Letzt analysieren wir das HTTP-Protokoll.

2.3 Ergebnisse mit Beschreibung und Screen Shots

Um die Daten unseres PCs herauszufinden tippen wir in die Kommandozeile unseres Compu-

ters „ipconfig /all“. Dieser Befehl funktioniert nur auf einem WINDOWS®-Betriebssystem ab den

13


VERSIONEN NT® und 2000® [22]. Unser Ergebnis sieht wie folgt aus:

Abb. 6| Ergebnis nach „ipconfig /all“

Unsere benötigten Daten unseres Computers sind also:

IP-Adresse: 172.16.10.33

Subnetzmaske: 255.255.255.0

Default Gateway 11 : 172.16.10.252

MAC-Adresse: 00:0c:29:ab:f2:3a

Netzadresse 12 des benutzten Subnetzes : 172.16.10.0

Broadcastadresse 13 des benutzten Subnetzes : 172.16.10.255

Da wir nun diese Daten haben, können wir WIRESHARK® starten. Um den Netzverkehr zu analy-

sieren, drücken wir Strg + I und wählen dort alle Interfaces aus und klicken auf „Start“.

Bevor wir eine Internetseite aufrufen, sieht unser Netzverkehr an den Interfaces so aus:

11 Standardgateway zu dem Pakete verschickt werden, wenn sich die IP-Zieladresse des Paketes nicht in der Menge der direkten Router oder in der Menge der indirekten Adressen befindet [20]

12 Kleinstmögliche IP-Adresse des jeweiligen Subnetzes [29]13 Größtmögliche IP-Adresse des jeweiligen Subnetzes [29]

14


Abb. 7| Netzverkehr vor dem Aufruf einer Internetseite

Nun starten wir einen Webbrowser, geben eine beliebige Internetadresse ein. In unserem Fall

entschieden wir uns für www.google.de und starten die Erfassung des Netzverkehrs neu und

erhalten folgendes Ergebnis:

Abb. 8| Netzverkehr nach dem Aufruf einer Internetseite

15

http://www.google.de/


Man sieht, dass TCP- und HTTP-Protokolle aufgeführt werden, da wir beim Aufrufen einer In-

ternetseite eine Anforderung auf die HTTP-Anwendung stellen. Wie genau diese Anforde-

rung abläuft und wie wir auf die Anwendung kommen wird im folgenden erläutert.

Dazu gucken wir uns erst die niedrigste Schicht des TCP/IP-Modells an – die Netzzugangs-

schicht zu der auch der Ethernet Frame gehört [5].

Als Beispiel Frames nehmen wir die Frames mit den Nummern 16, 19 und 20. Die Nummern

der Frames spielen allerdings keine Rolle. Diese ändern sich nämlich nach jeder Sitzung. Auch

die Art des Protkolls ist dabei nicht von Bedeutung. Wir haben uns nur deshalb für diese drei

entschieden, da sich anhand von ihnen der Drei-Wege-Handschlag erläutern lässt. Dazu spä-

ter mehr. Bei den gewählten Frames notieren wir uns jeweils die Quell- und die Ziel-MAC-

Adresse.

Abb. 9| Ethernet Frame 16

Frame Nummer: 16

Frame Länge: 62 bytes

Source MAC-Adresse: 00:0c:29:ab:f2:3a (MAC-Adresse unseres Computers)

Destination MAC-Adresse: 00:22:15:26:bf:7b (MAC-Adresse des Routers)


Frame Nummer: 19


Source MAC-Adresse: 00:22:15:26:bf:7b (MAC-Adresse des Routers)

Destination MAC-Adresse: 00:0c:29:ab:f2:3a (MAC-Adresse unseres Computers)


Frame Nummer: 20


Source MAC-Adresse: 00:0c:29:ab:f2:3a (MAC-Adresse unseres Computers)

Destination MAC-Adresse: 00:22:15:26:bf:7b (MAC-Adresse des Routers)

16


Da wir anfangs unseren PC untersucht hatten, sehen wir, dass eine der MAC-Adressen immer

unsere eigene ist. Die andere MAC-Adresse ist wahrscheinlich die des Routers. Davon können

wir ausgehen, da wir eine IP-Adresse außerhalb unseres lokalen Netzes kontaktieren wollen

(den GOOGLE®-Server) und demzufolge das Paket über den Default Gateway des Routers ver-

sandt werden muss [12].

Unser Router sucht dann die gesuchte IP-Adresse des Servers der Internetseite, indem er die

„alte“ Quell-MAC-Adresse durch seine eigene MAC-Adresse ersetzt. Als Ziel-MAC-Adresse

wird die MAC-Adresse des nächsten Routers genommen, der „weiß“ wo sich die gesuchte IP-

Adresse des GOOGLE®-Servers befindet, bzw. der einen anderen Router kennt, der dies wissen

müsste (indem Fall wird dann wieder die Quell- und Ziel-MAC-Adresse geändert bis man am

Ziel mit der gewünschten IP-Adresse angekommen ist). [29]

Der Server schickt dann die gewünschten Daten zurück an unseren Router und dieser sendet

diese an unseren Computer weiter.

Präambel Start des Frames

Ziel-Adresse

Quell-Adresse

802.1Q tag (optio-

nal)

Länge/Typ Payload FCS Interframe gap

7 octets 1 octet 6 octets 6 octets (4 octets) 2 octets 42-1500 octets

4 octets 12 octets

← 64 – 1522 octets →

← 72 – 1530 octets →

← 84 – 1542 octets → Tbl. 2[23]| Ethernet-Frame-Struktur im Frame-Format Ethernet II

Präambel Bitstrom zur Synchronisation

Start des Frames Synchronisation zwischen Sender und Empfänger

Ziel- und Quelladresse MAC-Adressen der Netzkarten der Endsysteme

802.1Q tag durch das IEEE genormter Standard der VLAN-Technologie („Virtual Local Area Network“)

Länge/Typ beschreibt die Länge des Datenfeldes, um Unbemerkten Ver-lust von Daten zu verhindern

Payload Nutzdaten der OSI Schicht 3 und ggf. Füll-Bytes zum Errei-chen der vorgeschriebenen Frame-Länge

FCS („Frame Check Sequence“) kontrolliert, ob alle Frames angekommen sind und verwirft alles, wenn nicht vollständig empfangen

17


Interframegap minimale zeitliche Abstand zwischen zwei gesendeten Fra-mes auf dem Übertragungsmedium

[23]

Anhand von WIRESHARK® lässt sich auch die Kapselung von Daten im TCP/IP-Modell ansehen.

Dazu schauen wir uns jeweils ein Protokoll der jeweiligen Schicht an:

Abb. 12| ARP (Protokoll der Schicht 1 im TCP/IP-Modell)

Abb. 13| TCP (Protokoll der Schicht 3 im TCP/IP-Modell)

Abb. 14| HTTP (Protokoll der Schicht 4 im TCP/IP-Modell)

18


Wie wir an den Screen Shots sehen, hat jedes aufgeführte Protokoll auch einen Header, der

jeweils darunterliegenden Schicht.

Damit überhaupt eine MAC-Adresse ermittelt werden kann zu der immer die jeweiligen Da-

ten geschickt werden müssen, damit sie zum Ziel gelangen, benötigen wir – wie bereits oben

beschrieben – das ARP.

Um eine zu einer Ziel-IP-Adresse die dazugehörigen MAC-Adresse zu ermitteln benötigt man

das ARP [4].

Um die ARP-Tabelle anzeigen zu lassen geben wir in der Kommandozeile „arp -a“ ein. Dies lie-

fert uns folgendes Ergebnis:

Abb. 15| ARP-Tabelle nach Browsen im Web

Dort sehen wir die IP- und die MAC-Adresse unseres Routers (1. Ergebnis). Die IP- und die

MAC-Adresse, die darunter stehen sind Adressen eines anderen Netzteilnehmers in unserem

lokalen Netz zu dem unser Computer wohl auch eine Verbindung eingehen wollte.

Wenn nun die Tabelle mit „arp -d *“ löschen und mit „arp -a“ anzeigen lassen, sehen wir,

dass die Einträge gelöscht wurden.

19


Abb. 16| Löschen der ARP-Tabelle

Wenn wir nun WIRESHARK® erneut starten, eine Internetadresse aufrufen und dann „arp -a“ in

die Kommandozeile eingeben, sehen wir wieder den Eintrag des Routers (und ggf. anderer

Netzteilnehmer, wenn dieser ebenfalls kontaktiert wurde).

Was genau dabei passiert, kann man sich in den ARP-Einträgen in WIRESHARK® anschauen:

Abb. 17| ARP-Request

Abb. 18| ARP-Reply

Wie man in Abb. 17 sehen kann, sendet unserer Rechner einen Broadcast in unser Netz mit

der „Target IP address:“ (Ziel IP Adresse) 172.16.10.252, was die IP-Adresse des Routers ist.

Der Frame zeigt auch, dass die „Target MAC address“ (Ziel MAC-Adresse) noch nicht bekannt

ist. Sie ist deshalb auf 00:00:00:00:00:00 gesetzt. Unser Rechner fragt praktisch „An das Ge-

20


rät mit der IP-Adresse 172.16.10.252: Kannst du mir bitte deine MAC-Adresse geben?“

(„ARP-Request“). Die Sender IP- und MAC-Adressen sind die unseres Rechners.

In Abb. 18 erkennt man, dass das Gerät mit der Ziel IP Adresse unserem Rechner mit seiner

MAC-Adresse antwortet („ARP-Reply“). Die Sender IP- und MAC-Adressen sind nun die des

Routers und die Target IP- und MAC-Adressen, die unseres Rechners, damit dieser die MAC-

Adresse des Routers in seine ARP Tabelle eintragen kann.

Abb. 19[20]| ARP-Prüfung

Als nächste Schicht im TCP/IP-Modell folgt die Internetschicht wozu das IP-Protokoll gehört

[5].

Dazu schauen wir uns ein IP-Datagramm näher an. Als Beispiel nehmen wir die IP-Paket

Struktur des Frame 19:

21


Abb. 20| IP-Datagramm eines TCP-Segmentes

Man erkennt, dass die Quell-IP-Adresse die vom GOOGLE®-Server ist (alternativ kann man diese

auch unter http://www.utrace.de/ überprüfen) und die Ziel-IP-Adresse, die unseres Rech-

ners. Das Feld „Version“ zeigt an, ob wir eine IPv4 oder eine IPv6 Adresse nutzen. „Header

length“ zeigt, wie der Name schon sagt, die Länge des IP-Headers an. Das Feld „Differentiated

Services Field“ zeigt die Klassifizierung des IP-Pakets an. Diese kann zur Priorisierung von IP-

Datenpaketen genutzt werden. Das Feld „Flags“ ist ein Kontroll-Schalter mit folgender Be-

deutung: Das erste Bit (Bit 0) ist ein reservierter Bit, dieser muss 0 sein. Der zweite Bit (Bit 1)

legt fest ob das Paket fragmentiert werden darf oder nicht. 0 bedeutet „darf fragmentiert

werden“, eine 1 bedeutet „darf nicht fragmentiert werden“. Das letzte Bit (Bit 2) zeigt an ob

dies das letzte Fragment des Paketes war (0) oder ob noch weitere folgen (1). „Fragment Off-

set“ sagt ab welcher Position innerhalb des Paketes das Fragment anfängt. Das „Time to live“

gibt an wie viele Zwischenstationen („Hops“) ein Paket im Internet passieren darf. Das Feld

„Protocol“ zeigt an, um welches Protokoll es sich handelt, in unserem Fall ist ein TCP-Proto-

koll. „Header checksum“ ist schließlich eine Prüfsumme, die ausschließlich den Kopfdatenbe-

reich sichert. Der Header Checksum ändert sich mit jedem Hop, indem er um eins erhöht

wird. [20]

Nun analysieren wir das TCP-Segment der Frames 16, 19 und 20 und den Drei-Wege-Hand-

schlag mit dem das TCP eine Verbindung herstellt. Das TCP-Protokoll stellt durch ihn eine

Verbindung zu einem anderen Netzteilnehmer her. Eine TCP-Verbindung ist durch folgenden

vier Werte eindeutig identifiziert: Quell-IP-Adresse, Quell-Port, Ziel-IP-Adresse, Ziel-Port. Die-

ses Paar an IP-Adresse und Port wird auch als „Socket“ bezeichnet. Die IP-Adressen werden

benötigt um die beteiligten Rechner zu identifizieren. Die Ports dienen auf den beiden betei-

ligten Rechnern dazu, die beiden miteinander kommunizierenden Prozesse zu identifizieren.

Ports sind 16-Bit Zahlen (Portnummern) und reichen von 0 bis 65535. Die Ports von 0 bis

22

http://www.utrace.de/


1023 sind reserviert und werden von der IANA („Internet Assigned Numbers Authority“) ver-

geben. Zum Beispiel ist Port 80 für die im World Wide Web verwendete HTTP-Anwendung re-

serviert. [31]

Sind Quell-IP-Adresse, Quell-Port, Ziel-IP-Adresse und Ziel-Port identifiziert, kann der Drei-

Wege-Handschlag durchgeführt werden. Beim Drei-Wege-Handschlag wird zunächst ein SYN-

Paket (vom Englischen „synchronize“) vom Klienten (in diesem Fall von unserem Rechner) an

den Server gesendet, mit dem er die Verbindung aufbauen möchte (in diesem Fall mit dem

GOOGLE®-Server), mit einer beliebig gesetzten Sequenznummer. Die Sequenznummern sind

für eine Sicherstellung der vollständigen Übertragung in der richtigen Reihenfolge ohne Du-

plikate wichtig. [1]

In Frame 16 sehen wir, dass ein SYN-Paket versendet wurde, da „Syn“ auf 1 gestzt ist. Außer-

dem sehen wir, dass die Sequenznummer 0 ist. Der angesprochene Server wartet, wie im Bild

zu sehen ist, auf Port 80. Auf der Klient-Seite wird eine beliebige Portnummer ab 1024 zuge-

wiesen (hier: 1145).

Abb. 21| SYN-Paket

Wenn der Server das SYN-Paket erhalten hat, sendet er eine Bestätigung mit einem SYN/ACK-

Paket zurück (ACK vom Englischen „acknowledgement“). Die Acknowledgment Nummer ent-

spricht dabei der um 1 hochgezählten Sequenznummer des Klienten. Außerdem bekommt

das SYN/ACK-Paket eine neue Sequenznummer. [4]

In Frame 19 sehen wir die Bestätigung des Servers, da „Syn“ und „Acknowledgement“ auf 1

gesetzt wurden. Außerdem ist die Acknowledgement Nummer 1 (0 [Sequenznummer des Kli-

enten] + 1 = 1) und die Sequenznummer des Servers ist ebenfalls 0. Die Quell-IP-Adresse und

Ziel-IP-Adresse werden vertauscht und die Quell- und die Ziel-Portnummer ebenfalls, da nun

das Paket vom Server an den Klienten gesendet wird. [4]

23


Abb. 22| SYN/ACK-Paket

Zuletzt bestätigt der Klient den Erhalt des SYN/ACK-Pakets durch Senden eines ACK-Paketes.

Die Acknowledgement Nummer entspricht hier der um 1 hochgezählten Sequenznummer

des Servers. Die Sequenznummer ist hier die um 1 hochgezählte Sequenznummer des Klien-

ten. [4]

In Frame 20 sehen wir schließlich die Bestätigung von uns, dass wir das SYN/ACK-Paket erhal-

ten haben, da unser Rechner ein ACK-Paket versendet hat („Acknowledgmen“ auf 1 gesetzt).

Die Sequenznummer ist 1 (0 [Sequenznummer des Klienten] + 1 = 1) und die Acknowledge-

ment Nummer ist ebenfalls 1 (0 [Sequenznummer des Servers] + 1 = 1). Die Quell-IP-Adresse

und -Portnummer sind wieder die des Klienten und die Ziel-IP-Adresse und -Portnummer die

des Servers. [4]

Abb. 23| ACK-Paket

24


Abb.24[4]| Überblick eines Beispiel-Drei-Wege-Handschlags

Im Vergleich zum TCP schauen wir uns nun das UDP an, was ebenfalls ein Protokoll der

Schicht 3 des TCP/IP-Modells ist. Dieses hat ebenfalls die Aufgabe Daten, die über das Inter-

net übertragen werden, der richtigen Anwendung zukommen zu lassen. Allerdings stellt das

UDP im Gegensatz zum TCP einen verbindungslosen, nicht-zuverlässigen und ungeschützten

Übertragungsdienst bereit. Das bedeutet es ist nicht sichergestellt, ob ein versendetes Paket

ankommt, dass Pakete in der korrekten Reihenfolge ankommen oder dass ein Paket nur ein-

mal beim Empfänger eintrifft. [2]

Es ist also nur für die Adressierung zuständig ohne dabei die Datenübertragung zu sichern. Es

wurde entwickelt, um für die Übertragung von Sprache ein einfacheres Protokoll zu verwen-

den als das bisherige TCP, da dieses sonst zu Verzögerungen in der Sprachübertragung führen

würde, falls beispielsweise ein Paket verloren geht, da beim TCP dann automatisch ein neues

angefordert wird. Dies würde bei VoIP („Voice over IP“ - Internet-Telefonie, Bsp. „Skype“) bei-

spielsweise zu plötzlichen Aussetzern bzw. zu größer angelegten Wiedergabepuffern führen.

[3]

Bei verloren gegangenen Paketen, käme jedoch die Kommunikation nicht ins Stocken, son-

dern die Qualität würde lediglich vermindert werden [7]. Daneben wäre die ungesicherte

Übertragung auch schneller, da nicht immer wieder ein Paket neu angefordert werden müss-

te [7].

Das UDP-Paket besteht aus einem Quell- und Ziel-Port („Source“ und „Destination Port“), ei-

nem Längenfeld („Length“) und einer Prüfsumme („Checksum“). Diese wird über den soge-

nannten „Pseudo-Header“ gebildet. Dieses besteht aus einem IP-Header, UDP-Header und

25


den UDP-Daten. Für die Übertragung eines UDP-Paketes ist das Internet Protokoll (IP) vorge-

sehen. Die hierzu benötigten Daten befinden sich in dem zuvor genannten IP-Header. Der

Pseudo-Header dient nur zur Bildung der Prüfsumme und wird nicht übertragen. Die Prüf-

summe ist optional, findet in der Praxis allerdings fast immer Verwendung, ansonsten wird

sie auf „0“ gesetzt. [13]

Hier sind einige UDP Beispiele zu sehen:

Abb. 25| Beispiel UDP-Paket

Abb. 26| Beispiel UDP-Paket

Hat der Klient nun eine Anfrage an den Server zum Aufrufen einer Internetadresse des Ser-

vers gestellt und wurde eine TCP-Verbindung hergestellt, wird nun das „Hypertext Transfer

Protocol“ (HTTP) an den Klienten übertragen. Dieses besteht aus den Header-Informationen

des Servers und dem tatsächlichen Inhalt der Nachricht, also dem Dateiinhalt. [13]

Abb. 27| HTTP GET Request von Klient

26


Abb. 28| HTTP Found vom Server

2.4 Fehler und Problembeschreibung

Es sind keine nennenswerten Probleme bzw. Fehler beim Ausführen von WIRESHARK® und der

Protokollanalyse aufgetreten.

2.5 Fazit

Computer kommunizieren über Netzsysteme miteinander. Diese Systeme benutzen verschie-

denste Medien zur Übertragung sogenannter Protokolle. In diesen Protokollen, die z.B. für

die Steuerung des Datenflusses und die Zustellung der Daten über verschiedene Knoten-

punkte (Router) zuständig sind, sind wiederum die eigentlichen Nutzdaten enthalten. Rou-

ting stellt sicher, dass Daten über verschiedene Netzwerke versendet werden können. Dazu

werden Informationen benötigt, die angeben, über welche Router oder anderen Rechner

man diese Netze erreichen kann. Routing findet in der Internetschicht des TCP/IP-Modells

statt. Die Informationen über die Wegfindung, also die Routinginformationen, werden dabei

in den Routingtabellen der einzelnen Rechner abgelegt. Diese können entweder statisch vom

Administrator konfiguriert oder dynamisch über Routingprotokolle verwaltet werden. Auf

diese Weise werden die Datagramme von einem zum nächsten Router weitergereicht bis sie

zum Ziel ankommen. Die Transportschicht hat dann die Aufgabe, die durch Layer 1 und 2 des

TCP/IP-Modells zum Ziel beförderten Daten an die richtigen Ports zu senden. Die Anwen-

dungsschicht wird von Netzprogrammen und -diensten verwendet. Sie stellen einen Dienst

auf einem Port zur Verfügung (beziehungsweise greifen auf diesen clientseitig zu) und kön-

nen über ihn senden und empfangen. Diese Applikationen benötigen natürlich jeweils ihre

eigenen, in der Regel standardkonformen Protokolle. Wenn wir eine Internetseite aufrufen

wollen wird dem Klienten das HTTP-Protokoll zugesandt. Zusammengefasst wird eine Verbin-

27


dung mit einem anderen Rechner aufgebaut, indem auf einem Port zugegriffen wird. Diese

Verbindung ist nun nichts anderes als ein TCP-Stream (oder eine beispielsweise eine UDP-

Verbindung), der die Integrität der Verbindung sicherstellt. Dieser TCP-Stream nutzt wieder-

um das IP-Protokoll und damit den Internet-Layer, um sicherzustellen, dass Pakete auch ihr

Ziel finden. Erst die Netzzugangsschicht bringt nun die zwiebelförmig verpackten Daten auf

das Kabel. [17]

28


3. Literatur- und Quellenverzeichnis

3.1 Literaturquellen

[1] ANONYMOUS (1999): Hacker's Guide – Sicherheit im Internet und im lokalen NetzHaar bei München: Markt und Technik, Buch und Software Verlag (New Technology).

[2] BEJTLICH, R. (2005): The Tao of Network Security Monitoring – Beyond Intrusion DetectionBoston, Massachusetts: Pearson Education, Inc.

[3] BADACH, A. (20104): Voice over IP – Die Technik, Grundlagen, Protokolle, Anwendungen, Migration, SicherheitMünchen, Wien: Carl Hanser Verlag.

[4] CLARK, M. P. (2003): Data Networks, IP and the Internet – Protocols. Design and OperationWest Sussex, England: John Wiley & Sons Ldt.

[5] COLE, E. [Hg.], R. KRUTZ, J. W. CONLEY (20092): Network Security BibleIndianapolis, Indiana: Wiley Publishing, Inc.

[6] COMER, D. E. (20023): Computernetzwerke und Internets mit Internet-AnwendungenMünchen: Pearson Studium.

[7] CONVEY, S. (2004): Network Security Architectures – Expert guidance on designing secure networksIndianapolis, Indiana: Cisco Press.

[8] DATE, C. J., H. DARWEN (1998): SQL – Der Standard, SQL/92 mit den Erweiterungen CLI und PSMBonn: Addison-Wesley-Longman Verlag GmbH.

[9] EREN, E., K.-O. DETKEN (2007): VoIP Security – Konzepte und Lösungen für sichere VoIP-KommunikationMünchen: Carl Hanser Verlag.

[10] FUHRBERG, K. (20002): Internet-Sicherheit – Browser, Firewalls und VerschlüsselungMünchen, Wien: Carl Hanser Verlag.

[11] HEIN, M. (20026): TCP/IPBonn: mitp-Verlag.

[12] HUCABY D., S. MCQUERRY, A. WHITAKER (20102): Cisco Routing Configuration Handbook – The single-source guide to configuration the most popular Cisco router featuresIndianapolis, Indiana: Cisco Press.

[13] HUNT, C. (19982): TCP/IP Netzwerk-AdministrationKöln: O'Reilly Verlag.

[14] KAFKA, G. (2005): WLAN – Technik, Standards, Planung und Sicherheit für Wireless LANMünchen, Wien: Carl Hanser Verlag.

[15] LEWIS, W. (2009): LAN-Switching und Wireless – CCNA Exploration Companion GuideMünchen: Addison-Wesley Verlag.

[16] LOWE, D. (20106): Netzwerke für DummiesWeinheim: WILEY-VCH Verlag GmbH & Co. KGaA.

[17] PLÖTNER, J., S. WENDZEL (20072): Praxisbuch – Netzwerk-SicherheitBonn: Galileo Press.

[18] PROEBSTER, W. E. (20022): Rechnernetze – Technik, Protokolle, Systeme, AnwendungenMünchen: Oldenbourg Wissenschaftsverlag GmbH.

[19] RHODES-OUSLEY, M. (20132): Information Security – The Complete ReferenceNew York: The McGraw-Hill Companies.

29


[20] RIGGERT, W. (20053): Rechernetze, Grundlagen – Ethernet – InternetMünchen, Wien: Carl Hanser Verlag.

[21] ROBBE, B. (20042): SAN – Storage Area Network, Technologie, Konzepte und Einsatz komplexer SpeicherumgebungenMünchen, Wien: Carl Hanser Verlag.

[22] SCAMBRAY, J, S. MCCLURE (2002): Das Anti-Hacker-Buch für WindowsLandsberg: mitp-Verlag.

[23] SCHERRF, J. (20102): Grundkurs, Computernetzwerke – Eine kompakte Einführung in Netzwerk- und Internet-TechnologienWiesbaden: Vieweg+Teubner Verlag.

[24] SCHREINER, R. (20093): Computernetzwerke – von den Grundlagen zur Funktion und AnwendungMünchen: Carl Hanser Verlag.

[25] SEDAYAO, J. (2001): Cisco IOS Access Lists – Help for Network AdmisnistratorsSebastopol, Kalifornien: O'Reilly & Associates, Inc.

[26] SOSINSKY, B. (2009): Networking BibleIndianapolis, Indiana: Wiley Publishing, Inc.

[27] TANENBAUM, A. S. (19983): ComputernetzwerkeMünchen: Prentice Hall.

[28] TANENBAUM, A. S. (20034): ComputernetzwerkeMünchen: Pearson Studium.

[29] TEARE, D. (2010): Implementing Cisco IP Routing (ROUTE) – Foundation Learning Guide, Foundation learning for the ROUTE 642-902 ExamIndianapolis, Indiana: Cisco Systems, Inc.

[30] WASHBURN, K., J. EVANS (19972): TCP/IP – Aufbau und Betrieb eines TCP/IP-NetzesBonn: Addison-Wesley-Longman Verlag GmbH.

[31] WEISS, M. [Hg.], A. Bankhamer, M.-C. Billo, B. Hein, L. Hein, S. Hein, S. Hein, R. Moser, M. Reisner, K. Schuiki (2002): TCP/IP HandbuchPoing: Franzis Verlag GmbH.

3.2 Internetquellen

[32] WIRESHARK-COMMUNITY (2008): Wireshark – Frequently Asked Questionshttp://www.wireshark.org/faq.html#q1.1 Zugriff: 25.07.2013.

30

http://www.wireshark.org/faq.html#q1.1


4. Erklärung zur selbstständigen Abfassung des Protokolls

Hiermit erkläre ich, dass ich das vorliegende Protokoll selbstständig angefertigt, keine

anderen als die angegeben Hilfsmittel benutzt und die Stellen des Protokolls, die im Wortlaut

oder im wesentlichen Inhalt aus anderen Werken entnommen wurden, mit genauer

Quellenangabe kenntlich gemacht habe.

Sulingen, den 26.07.2013.

______________________________

Unterschrift der Studentin

31

protokollanalyse mit wireshark

Documents