Das Kennwort: Eine Methode zur Erzeugung guter Kennwörter für sensible Datenbestände.

Dieser Teil betrifft nicht die Public/Private Key Verfahren. Ein Kennwort sollte „sicher“ gewählt werden, was bedeutet, dass es nicht leicht zu erraten sein darf. Darunter fällt auch, dass ein Brute-Force-Angriff möglichst ultimativ lange dauern muss, um schlussendlich an die Daten zu gelangen. Natürlich ist letzteres anhängig von der Rechenleistung des Angreifers und Spezialkenntnissen, die normalerweise wenig ihren Weg in die Öffentlichkeit finden. Nun welches „sicheres“ Kenntwort? Zahlen, Buchstaben (Groß- und Kleinschreibung), Sonderzeichen und keine Wörter, die in Wörterbüchern vorkommen.

Schlecht: KeksDose7178. Gut: K3k5D0se$782. Besser: 4H.7&fV$k?6ß.

Doch wie möchte man sich soetwas einprägen? Gar nicht. Es gibt diverse Eselsbrücken, aber nach der nächsten durchzechten Nacht hilft auch das eigene von Gott geschaffene fsck.brain nicht immer weiter. Doch ja – am Ende hat man es vergessen. Vorgestellt wird eine etwas ungewöhnliche Methode: Man wähle ein gutes oder besseres Kennwort. Das wird auf einen echten Zettel mit einem echtem Stift notiert. Niemals wird es digital gespeichert oder digital transferiert (auch keine Kopierer oder anderes Hexenwerk, handgemeißelt auf Granitplatten ist zur Not auch okay (Moses-Backup)). Vielleicht wird es in eine Plastikkarte im Geldbeutel einlaminiert? Oh, erlaubt ist die Hemmingway-Notiz auf einer Pappkarte (fürs Laminieren) mit einer echten völlig analogen Schreibmaschine aus dem Antiquariat. Dabei ist allerdings darauf zu achten, dass anschließend das verwendete Farbband verfeuert wird. Gut soweit, jetzt nehme man sich ein Buch, was einem besonders gefällt. Ein cooler Spruch, ein Lebensmotto, alles ist gut geeignet, was mindestens aus fünf Wörtern mit Satzzeichen, wie „,.?“ besteht. Es muss sich fehlerfrei merken lassen. Es darf nicht zu lang sein. Das Kennwort dient als eine Art Salt des Merksatzes. Jetzt besitzt man zwei Geheimnisse, die nötig sind, um die Daten entschlüsseln zu können. Der Satz ist im Buch unauffällig abgelegt und zudem im Kopf. Der Rest kann recht unauffällig woanders sicher abgelegt werden. Fertig. Pro Datei eine neue „Notiz“ anlegen.

UDP Socket Fehlermeldung bei Cisco Switch (SNMP)

Folgender Fehler wird öfters in der Kosole angezeigt.

%IP_SNMP-3-SOCKET: can’t open UDP socket

Wurde keine IP Adresse konfiguriert, wird diese Fehlermeldung ebenso angezeigt. Möchte man weiter den SNMP Server betreiben, so muss eine IP Adresse konfiguriert werden. Dazu gibt es hier im Blog eine entsprechende Anleitung. Eine weitere Möglichkeit ist, den SNMP Server des Gerätes auszuschalten. Dies funktioniert so:

Lösung:

> enable
# conf t
# no snmp-server
# end
# copy run start

Nach dem Neustart des Gerätes sollte der Fehler weg sein.

Einem Cisco Switch eine IP Adresse vergeben

Ist kein VLAN konfiguriert, so kennt der Switch immer das VLAN1. Dies ist sozusagen das Native VLAN. Hier wird nicht weiter auf eine VLAN Konfiguration eingegangen, hierzu gibt es andere Einträge im Blog. Um eine IP auf einem Switch zu konfigurieren, kann die IP an ein Interface oder an ein VLAN geknüpft werden. Das ist je nach Baureihe verschieden. Kann das Switch IPs nur an ein VLAN knüpfen, so muss ein VLAN existieren. Wir nehmen als Beispiel daher das VLAN1, das native VLAN.

Folgendes unter der Konsole eingeben:

> enable
# conf t
# int vlan1
# ip add 192.168.13.2 255.255.255.0

# Strg+Z (Tastenkombination drücken oder wahlweise exit eingeben)
# wr mem
# reload

Mit „enable“ aktiviert der Benutzer die privilegierten Befehle. Dazu ist oft ein Passwort nötig. Sollte das Switch nicht nur zum Testen dienen, sollte unbedingt ein Kennwort eingerichtet werden. Mit „conf t“ (Kurzform für configure terminal) wird in den Konfigurationsmodus gewechselt. Hier können die einzelnen Ports konfiguriert werden und vieles mehr. Wir wollen eine IP Adresse dem Switch geben und müssen daher ins VLAN1 (oder in das Interface (statt int vlan1 int FastEthernet(y/x), je nachdem), um dort das IP Kommando abzusetzen. Der Befehl „int vlan1“ (Kurzform für interface vlan1) bewegt uns in die VLAN Konfiguration des ersten VLANs. Nun geben wir diesem VLAN eine IP mit dem Befehl ip add 192.168.13.2 255.255.255.0 (Kurzform für ip address 192.168.13.2 255.255.255.0). Nun besitzt das VLAN eine IP. Änderungen werden sofort aktiv, werden die Einstellungen nicht gespeichert gehen sie verloren. Mit Strg+Z als Tastenkombination oder mit dem Befehl „exit“ wird wieder eine Ebene höher gegangen. Nun schreiben wir vom RAM die Informationen ins Flash oder NVRAM, damit die Daten beim nächsten Reboot auch noch da sind. Der Befehl „wr mem“ erfüllt das. Ebenso funktioniert auch: copy run start. Aktuelle Änderungen befinden sich in der laufenden Config, also running-config. Mit show run kann sie eingesehen werden. Mit „reload“ wird der Switch neu gebootet, muss an der Stelle nicht sein, aber anschließend kann man sicher sein, dass die IP auch definitiv nach einem Reboot noch in den Einstellungen drin ist.

Wird das Switch über Router erreicht, bzw. es gibt mehrere verbundene Subnetze, so muss ein Gateway eingetragen werden, damit die Pakete auch wieder zurückfinden. Mit ? kann man die zur Verfügung stehende Befehle einsehen. Als IP Adresse die sich in dem Subnetz befindliche Adresse des Routers angeben.

Erfassen von Datenströmen eines Keyloggers mit Wireshark

Die Welt der Keylogger ist groß. Alleine diese Tatsache macht es nicht leicht einen Keylogger im System so ohne weiteres zu finden. Warum nicht? Hat der Angreifer den Keylogger durch einen Crypter geschickt, lässt sich dieser mit einem normalen Anti-Virus Programm oft nicht mehr erfassen. Zusätzlich stellt sich die Frage, wie arbeitet der Keylogger?

Es gibt Keylogger, die erst mal die erfassten Daten in eine Datei ablegen. Jetzt könnte der Suchende versuchen alle Dateien nach einem gewissen Inhalt zu durchsuchen. Findet er etwas, so stimmt etwas nicht. Jedoch sind die Programmierer recht schlau und verschlüsseln leicht oder schwer, je nach Geschmack, den erfassten Inhalt und legen diese Daten in den alternativen Datenströmen ab. Auf diese Weise fällt dem normalen Benutzer nicht auf, dass eine Datei immer größer wird und zudem noch immer offen ist. Der Suchende könnte ein Programm verwenden, welches alle offenen Dateien anzeigt, welches eine Menge sein wird. In dieser Liste sollte möglichst nichts Ungewöhnliches stehen. Also tarnen die Programmierer den Programmdateinamen etwas. Zum Beispiel: notepad.exe:29a. Nun befinden sich zwei Dateien unter dem Namen notepad.exe. Damit der Zweite wiedergefunden werden kann, trägt dieser einen Unternamen, hier 29a. Unter dem Windows Explorer wird hier nichts Verdächtiges angezeigt, da dieser die ADS nicht darstellt. Also ein ganz gutes Versteck als Zwischenpuffer für einen Keylogger.

Der obige Gesichtspunkt mal dahingestellt. Muss der Keylogger immer Daten senden? Nicht unbedingt. Wenn nicht live mit einer RAT auf das System gelinst wird, kann er das auch Etappenweise machen. Auch hier gibt es viele Ideen, die ein Programmierer umsetzen kann. Der Keylogger liest die E-Mail Kontodaten des Systems aus und versendet mit einer eigenen Routine eine Mail, wo die Daten mit versendet werden. Im Wireshark sieht man daher oft SSL und die Domain, smtp.meinprovider.de stimmt ja auch. Wenn die Zeitstempel nicht darauf hinweisen, dass gerade der Benutzer keine Mail versendet hat, nun ja – es fällt kaum auf. Andere Ideen ist das Senden der gespeicherten Daten, wenn gewisse Sachen mit dem Rechner gemacht werden. Ruft der Benutzer eine Suchmaschine auf oder sendet eine Suchanfrage, so werden dann die Daten versendet. Das Schöne an diesem Muster ist, dass der Benutzer oft nicht große Teile von Daten mitschneidet und analysiert, sondern immer nur kurze Minutenstücke. Dabei ruft er aber selten etwas bei Google ab, während er auf dem System stöbert. Damit minimiert der Programmierer die Wahrscheinlichkeit, dass die Sendung entdeckt wird. Zusätzlich könnten die Daten auch als HTTP Traffic getarnt werden. Dazu sendet der Keylogger HTTP Aufrufe an eine Domain und überträgt die Daten als normale Parameter. Man denke noch an eine triviale Verschlüsselung und an dem Domainname: updates.ativr32.com. So ohne weiteres fällt es auf dem ersten Blick auch in Wireshark nicht auf, wenn hier und da mal ein paar KB ausgetauscht werden. Auch getarnt als DNS Traffic ist es schwer einfach so zu erkennen, dass es sich um eine Datenübertragung handelt. Hierbei werden normale DNS Aufrufe geformt, die entsprechend an einen selbst gebauten DNS Server gehen, der mit den zusätzlichen Daten etwas anfangen kann.

Doch warum der ganze Zauber? Wegen der Firewall. DNS Pakete werden oft unkommentiert durchgelassen, wie auch HTTP. Auch eine Mail geht oft ohne weiteres raus. Sind die Daten erst mal weg, ist das Kind schon im Brunnen am Wassertreten. Damit die Firewalls möglichst nichts bemerkt, kann sich der Keylogger an Systemprozesse hängen oder an Prozesse wie Thunderbird oder Outlook. Mit dem Process Explorer lässt sich hier und da so etwas erkennen. Natürlich erkennen viele Internet Security Suites auch verdächtige Aktivitäten und blocken das, wenn gewünscht. Jedoch ein normales Anti-Virus Programm ist hierbei fast immer still.

Somit sei etwas dargestellt, dass das Erfassen von Datenströmen von Keyloggern unter Wireshark nicht so einfach ist. Dennoch ist es eine gute Idee ein Auge auf seiner Internetverbindung zu haben. Vielleicht ist der Einsatz eines Proxyservers eine schöne Sache. Surft der Benutzer nur, so kann einmal der Proxy ein sehr genaues Log führen und zudem alles wegwerfen, was nicht in eine HTTP Verbindung gehört. Mail und FTP und was nicht alles kann entweder durchgelassen werden oder es wird auch geblockt. Den Computer noch in ein neues Subnetz, was kein Gateway bekommt und ein zweiter Rechner, der Proxy spielt für das Subnetz mit zwei Ethernet-Karten. Fertig. Die Maschine ist damit einmal aus dem Internet sehr schwer zu erreichen, da sich NAT und PAT ohne Gateway erledigt hat. Gleichzeitig kommt nur die Dinge über den Proxy raus, die der Benutzer auch erlaubt hat. Und das Log, falls gewünscht, kann riesig werden. Je nach Detailgrad. Da findet der Benutzer alles, was passiert ist. Gut, es schützt nicht vor Drive-by-Downloads und so weiter, aber dennoch würde eine RAT nicht über den Proxy nach außen kommen. Für die Malware gibt ja ein AV Programm.

Einsatz von urlsnarf (dsniff Paket)

Urlsnarf ist ein kleines Programm, welches in dem dsniff Paket mitgeliefert wird. Bei dem Programm handelt es sich um einen HTTP Sniffer, der seine Ausgaben im Common Log Format ausgibt. Damit lassen sich die Daten gleich in Web Log Analyser aufbereiten. Damit erhält ein Schnüffler schnell eine Übersicht, wo die Leute im Netzwerk so herumsurfen. Als Web Log Analyser kann beispielsweise SawMill, wwwstat oder ana-log verwendet werden.

urlsnarf kann mit einigen Optionen gefüttert werden. -n weist urlsnarf an, keine IP Adressen über DNS aufzulösen. -i definiert das Netzwerkinterface mit dem gearbeitet werden soll. Desweiteren können mit regulären Ausdrücken URLs definiert werden, worauf urlsnarf achten soll, falls der Schnüffler einen gewissen Kreis von Seiten im Fokus hat.

urlsnarf ist auf der Backtrack, wie auch auf der GRML Live CD zu finden. Dazu läßt es sich natürlich auch unter Ubuntu nachinstallieren. Paketname: dsniff.

urlsnarf kann recht gut zusammen mit ettercap verwendet werden. Schließlich müssen die Daten ja auch am Interface vorbeilaufen, um sie Sichten zu können.

Weiterführende Ideen könnten sein, noch ein transparanten Proxy in die Kette mit einbauen, der entsprechend auf einer ganz bestimmten Seite das LoginScript so umändert, dass die Kennwörter, die sonst per SSL übertragen werden, auch zum Angreifer hinwandern, schon kommt man ohne die SSL Kette beschädigen zu müssen an Logins, ohne dass das grüne Häckchen rot wird.

Wofür kann macof verwendet werden?

Das Programm macof ist ein Flodder. Das Programm befindet sich auf der GRML und auf der Backtrack Live CD. Unter Ubuntu läßt es sich schnell mit apt-get nachinstallieren. Macof flutet ein geswitchtes LAN mit Paketen, die zufällige MAC-Adressen beinhalten. Doch warum wird so etwas gemacht? Das Fluten mit Paketen dieser Art dient keinem DOS Angriff. Vielmehr möchte der Angreifer erreichen, dass die MAC-Tabelle auf dem Switch volläuft. Damit wird erreicht, dass ein Switch sofort als ein Multiport-Repeater arbeitet und alle Pakete, wie ein gewöhnliches Hub, zu allen Rechner weiterleitet. Im Standard steht dieses Verhalten festgeschrieben, jedoch regieren nicht alle Geräte gleich. Besonders, wenn das Switch Sicherheitsfunktionen besitzt, wie alle professionellen Cisco Switches, wird dem Angreifer schnell ein Shutdown des Ports beschert. Es gibt auch IDS Systeme, die einen Flood erkennen und entsprechend Alarm schlagen.

Gut, der Angreifer hat erfolgreich das Switch geflutet und kann nun für eine gewisse Zeit den ganzen Traffic im LAN lesen. Mit Wireshark geht das für gewöhnlich im ganz gut. Stoppt das Fluten, so wird das Switch nach einer gewissen Zeit seine Tabelle aufräumen und schon ist der Zauber wieder vorbei. Somit muss der Angreifer über den ganzen Zeitraum seine Aktivitäten das Switch damit fluten. Ist das Gateway des Subnetzes bekannt und soll entsprechend der dort auslaufende Traffic abgehört werden, ist es sinnvoll das Gateway zu spoofen, um die Pakete dann durch seinen eigenen Rechner umzuleiten und anschließend zum echten Gateway.

Mit dem macof Parameter -i bestimmt der Angreifer das Netzwerk-Interface, woraus die gespooften Mac-Frame herauswandern sollen. Mit -s übergibt der die Quell-IP-Adresse, die das Paket beinhalten soll. Mit -d nun die Ziel IP Adresse. Diese kann existieren, muss aber nicht. Genauso, wie die Quell-IP. Mit -e wird die Mac-Adresse bestimmt. -x gibt das TCP Sourceport an und -y das TCP Destinationport. Das Wichtigste ist -n, welches die Anzahl der zu sendenden Pakete bestimmt.

Arcor DSL mit fester IP konfigurieren

Arcor stellt DSL Anschlüsse mit fester und dynamischer IP zur Verfügung. Der Kunde bekommt zweierlei Zugangsdaten. Einmal die Zugangsdaten, die man als dynamische Kennung bezeichnen kann. Dazu gibt es eine weitere Kennung, die für den Anschluß mit der statischen IP verwendet werden muss.

Doch wie wird nun die feste IP, die Arcor einem zur Verfügung stellt, im DSL Router eingerichtet? Schließlich gibt es verschiedene Möglichkeiten sein DSL einzurichten. Und oft bietet der Router an dieser Stelle auch eine statische Konfiguration an. Diese wird allerdings nicht benötigt. Gebraucht wird eine normale DSL Einwahl.

Die Hotline ist unter Umständen nicht immer in der Lage dem Kunden eine korrekte Antwort zu geben, auch diverse Foren schreiben viel und geben oft nur eine kleine oder gar keine Hilfestellung.

Möchte der Kunde sein ArcorDSL von dynamischer IP zu einer statischen umstellen, so muss er lediglich seinen DSL Router ganz normal konfigurieren, wie für einen dynamischen Anschluß. Also PPPoE und so weiter wählen, dazu die Zugangskennung für den statischen Anschluß. Das wars schon. Der Router fragt bei Arcor nach der zu setzenden IP und Arcor sendet dem Router entsprechend bei der AutoConfig die bestellte statische IP zurück. Diese wird anschließend immer beim Reconnect vergeben.

ZIP-Archiv Verschlüsselung ist nicht sicher genug.

Die interne Verschlüsselung von ZIP-Archiven ist nicht sicher genug. Natürlich stellt sich sofort die Frage, wann etwas sicher genug ist. Und selbstverständlich, warum ist sie nicht sicher genug?

Die Antwort liegt eher im verschlüsselten Inhalt des Archives selbst. Schließlich hat es einen Grund, warum der Benutzer ein ZIP Archiv anlegt und dieses mit einem Passwort sichert. Sind es persönliche oder gar vertrauliche Informationen? Wem schadet eine Veröffentlichung der Informationen? Sind die Informationen pressewirksam, wenn sie irgendwo auftauchen? Sind die Informationen als streng vertraulich oder als geheim eingestuft? Wann läuft die Relevanz der Informationen ab?

Schließlich ist eine Information nur dann etwas wert, wenn diese noch aktuell und richtig ist. Wurde zum Beispiel ein geheimes Kennwort in einer Datei aufbewahrt und diese als verschlüsseltes ZIP Archiv versendet, so ist diese Information nur solange wichtig, wie das Kennwort nicht geändert worden ist. Liegt also eine Richtlinie vor, dass wöchentlich alle Kennwörter zu ändern sind, so kann der Benutzer alle Verfahren verwenden, wovon er weiß, dass Dritte das Kennwort keinesfalls innerhalb einer Woche wiederherstellen können. Bei brisanten Bildern und Adressen, Ausweisdaten, Bankinformationen ist der Zeitraum größer, also muss eine stärkere Verschlüsselung gewählt werden, um die Sicherheit garantieren zu können.

Bloß was ist nun sicher? Schließlich gibt es unzählige Programme die Sicherheit versprechen. Das schließt auch die Packprogramme mit ein. Firmen werben wiederum mit Crackprogrammen. Auf der Seite http://www.password-crackers.com werden verschiedene Formate genannt, die entsprechend geknackt werden können. Möchte also ein Benutzer, dass keinesfalls gewisse Inhalt an der falschen Stelle wieder auftauchen, darf er kein Produkt verwenden, wo in irgendeiner Weise, ob gut oder schlecht, ein Crackprogramm existiert, das in einer machbaren Zeit das Kennwort oder den Schlüssel wiederherstellen kann. Wird dieses Kriterium aufgenommen, so fliegen viele Programme von der Liste und nur wenige Programme bleiben übrig.

Benutzbare wären unter anderem: TrueCrypt, GnuPG, PGP, 7-zip mit AES und andere. Wählt der Benutzer ein Kennwort, so ist natürlich ein sicheres, ausreichend langes und komplexes Kennwort nötig, damit Dritte mit einem Directory oder Brute-Force Angriff scheitern. Daher sind PGP bzw. GnuPG sehr zu empfehlen, da Daten mit Öffentlichen und privaten Schlüsseln ver- und entschlüsselt werden. Das Erzeugen von Kennwörtern ist auf die klassische Weise hiermit nicht mehr nötig. Das Hybride-Verfahren macht es möglich ein Personenkreis eine Information zur Verfügung zu stellen, ohne dass jeder ein spezielles Kennwort benötigt. Das erleichtert das Vermitteln von Daten.

Soweit so gut. Was macht denn nun Zip-Crypto so unsicher? Kennt der Angreifer einen Teil oder ein Stück einer Datei, so kann er einen Known-Plain-Text Angriff durchführen und kommt recht fix zum Ziel. Dazu lässt sich ZIPCrypto recht gut mit einem Brute-Force knacken. Also ist die Wahl des Kennwortes von einer großen Bedeutung gerade weil Rechner heutzutage recht schnell geworden sind.

Im Internet gibt es eine ganze Reihe von Tools, die Word, Excel und PowerPoint Dateien recht schnell öffnen können. Auch dieser Schutz ist zwar nett, aber im Zweifelsfall nicht wirklich sicher. Ausreichend, wenn es um kleine Dinge, wie ein Schreibschutz geht, aber unsicher wenn sensible Informationen gespeichert worden sind. WinZIP und andere Programme stellen den Hackern in neueren Versionen durchaus ein wenig mehr entgegen. Aber nur ein bisschen. Die Programme verwenden zur Verschlüsselung den sog. Zip 2.0-Industry Standard. Dieser sieht vor, dass ein 40 Bit langer symmetrischer Schlüssel aus dem Passwort erzeugt wird. Die 40-Bit Beschränkung stammt noch auf den alten strengen Exportbestimmungen der USA für Kryptografie.

Also ist dieser Schutz aufgrund der geringen Schlüsselbreit nicht für sensible Daten geeignet. Dennoch kann der Benutzer es dem Angreifer zumindest ein klein wenig schwerer machen. Einige Dinge müssen hierbei beachtet werden.

Viele Crackprogramme probieren per Brute-Force einfach alle möglichen Kennwörter durch. Das kann natürlich auch ein Directory sein oder ein permutiertes Directory. Hierbei wird spekuliert, dass es zufällig einen richtigen Treffer gibt. Also darf das Kennwort nicht aus Teilen bestehen, die in einem Directory vorhanden sind. Da bleiben nur wahlose Zeichen, die schwer zu merken sind.

Ist dem Angreifer jedoch eine Datei aus diesem verschlüsselten Archiv bekannt, dann ist das Kennwort mit einem Known-Plain-Text-Angriff schnell errechnet. Bei diesem Vorgang wird der klare Text, mit dem verschlüsselten Text verglichen. Natürlich ist der Algorithmus bekannt und schon kann es losgehen. Theoretisch sind nur 13 Byte nötig, die klar lesbar sind, um einen erfolgreichen Angriff durchzuführen.

Leider hat die Software WinZIP noch eine weitere Schwäche. Hat der Benutzer mehr als sieben Dateien in ein Archiv gepackt, so ist es möglich den Schlüssel mit einer recht hohen Wahrscheinlichkeit zu errechnen. Diese Methode wird Surezip genannt. Der Angriff basiert auf dem Reduced-Known-Plaintext-Angriff. Dieser kommt mit 7 Zeichen Klartext aus. Werden Standard-Dateitypen verwendet, wie Grafiken, Videos und so weiter, so reichen Teile des Datei-Headers selbst aus, um einen erfolgreichen Angriff durchführen zu können. Aufgrund der Geschwindigkeit der Rechner lassen sich die Archive in wenigen Minuten bis einige Stunden knacken.

Final kann gesagt werden, dass ZIP-Crypto für sensible Daten aufgrund der obigen Tatsache einfach ungeeignet ist. So ist der Griff in die PGP Kiste durchaus der sichere. 7-zip beinhaltet gute Verfahren (AES), allerdings auch die Ungeeigneten. Konfiguriert der Benutzer ZIP mit ZipCrypto, so ist die Sicherheit dahin. Sinnvoll ist das 7z Format mit AES, einem 12 stelligen Kennwort oder mehr mit Zahlen, Buchstaben in Groß- und Kleinschreibung mit weiteren Sonderzeichen.

Permission Denied bei TCPDump bei Ubuntu Server 10.04 LTS

Bei der Verwendung von TCPDump stellt der Benutzer nach einer Weile fest: „permission denied“ Und das immer wieder. Der Benutzer kann sich unter Ubuntu Server 9.04 LTS und in der Version 10.04 LTS recht viel Frustration mit aa-enforce und aa-complain sparen. Oft wird das Problem an der falschen Stelle gesucht, meist ist alles in Ordnung und korrekt installiert und auch libpcap tut, was es soll. Das bei der Eingabe von tcpdump in vielen Fällen ein „permission denied“ erscheint hat etwas mit dem Sicherheitskonzept von Ubuntu zu tun. So sieht das bei vielen aus:

# tcpdump -v -s 1800 -w ausgabe.pcap host 192.168.42.1 and tcp port 22
tcpdump: ausgabe.pcap Permission Denied

Zur Lösung:

Die Einstellungen für tcpdump müssen in AppArmor geändert werden. Dies funktioniert so:

# aa-complain /usr/sbin/tcpdump - Dies ändert die Stufe auf "complain".
# aa-enforce /usr/sbin/tcpdump - Dies aktiviert die Änderungen im Profil von AppArmor für tcpdump

Nun läuft tcpdump wieder wie gewohnt. Falls diese Änderungen nicht durchgeführt werden, ist standardmäßig das Verzeichnis /root freigegeben.

IP in IP Tunnel

Ein IPIP Tunnel ist so ziemlich der einfachste Tunnel, den Linux bereits seit einer langen Zeit beherrscht. Hierbei werden verschiedene IP Packete, die zu verschiedenen Verbindungen gehören können in weitere IP Pakete verpackt und zwischen zwei Endpunkten versendet. Schon fertig ist der Tunnel. Hierbei wird der Tunnel allerdings nicht verschlüsselt.

Das Internet Protocol (IP) ist stellt die Grundlage des Internets dar. Im Internet wird nicht, wie im LAN mit MAC adressiert, sondern mit IP Adressen. Daher stellt eine IP Adresse das Ziel eines Paketes im Internet dar, nicht wie im LAN letztendlich die MAC Adresse. Bei IP handelt es sich um die Implementierung der Internetschicht des TCP/IP-Modells bzw. des Network Layers des OSI-Referenzmodels.

IP ist ein unsicheres Protokoll, beschädigte Packete werden einfach verworfen. Die höheren Schichten sorgen für das Nachsenden der verlorengegangenen Pakete. So sorgt sich der IP Tunnel in keiner Weise um beschädigte Pakete. Was ankommt, ist da. Mehr nicht. Über ein TAP Device, einer virtuellen Netzwerkkarte, werden die Daten eingepackt und durch den erzeugten Tunnel gesendet. Das Zielsystem empfängt diese Pakete und entfernt den IP Header des Tunnels und wirft das Paket entsprechend auf dem TAP Device wieder heraus. Dort kümmern sich dann andere Komponenten um die Daten.

Nun, wie wird unter Linux ein IPIP Tunnel eingerichtet? Im wesentlichen werden hierzu zwei kernel-Module benötigt. ipip.o und new_tunnel.o.

Ein praktisches Beispiel dazu. Zwei Rechner sollen miteinander einen Tunnel aufbauen. Diese sind mit dem Internet verbunden. Das Internet wird mal Wolke A genannt. Das Netzwerk des ersten Rechners Wolke B und das Netzwerk des zweiten Rechners Wolke C.

Wolke A: Internet
Wolke B: Netzwerkadr. 192.168.10.0; Netmask. 255.255.255.0;
Gateway. 192.168.10.254; Gateway (Internet). 172.16.23.42
Wolke C: Netzwerkadr. 192.168.20.0; Netmask. 255.255.255.0;
Gateway. 192.168.20.254; Gateway (Internet). 172.18.42.64

So gehts weiter. Als erstes Prüfen, ob die Module geladen worden sind. Der Befehl insmod zeigt an, ob das Modul bereits geladen wurde oder ob es korrekt nachgeladen worden ist.

# insmod ipip.o
# insmod new_tunnel.o

Der Rechner in Wolke B wird folgendermaßen eingerichtet.

# ifconfig tunl0 192.168.10.254 pointopoint 172.18.42.64
# route add -net 192.168.20.0 netmask 255.255.255.0 dev tunl0

Der Rechner in Wolke C wird folgendermaßen eingerichtet.

# ifconfig tunl0 192.168.20.254 pointopoint 172.16.23.42
# route add -net 192.168.10.0 netmask 255.255.255.0 dev tunl0

Fertig. Nun sollten die beiden Netze miteinander verbunden sein. Wenn der Tunnel nicht mehr benötigt wird, wird der Befehl

# ifconfig tunl0 down

den Tunnel beenden.

Das war schon der ganze Zauber. Einige Kleinigkeiten müssen noch erwähnt werden. Es handelt sich um einen IPIP Tunnel. Das bedeutet, das IPv6 nicht einfach so durchflutscht. Genauso werden auch Broadcasts nicht geroutet. Für eine verschlüsselte Verbindnung kann OpenVPN verwendet werden. Genaues steht entsprechend im RFC2003 – IP Encapsulation within IP, auch als Plaintext.