VLAN Hopping bei Cisco-Switchen

Im Zuge meines Praktikums habe ich mich in den letzten zwei Tagen ein wenig mit VLAN Hopping [1] beschäftigt.

Es gibt dabei zwei Arten des VLAN Hopping:
1. Man verbindet sich als Trunk mit einem Port eines Switches welcher entweder selber ein Trunk-Port ist, oder auf Auto/Desirable steht und somit vom Switch zu einem Trunk-Port gemacht werden kann. Klappt dies, hat man Zugriff auf andere VLANs und kann munter Frames durch die Gegend schicken.
2. Man baut sich ein Paket, mit sog. double encapsulation. Sprich: Man sendet als ganz normales Endgerät ein Paket an einen Trunk-/Auto-/Desirable-Port eines Switches, in dem bereits zwei VLAN-Tags vorhanden sind. Das Switch liest das Paket ein und entfernt Tag 1 und wirft das Paket ins zugehörige VLAN. Das nächste Switch nimmt das Paket auf, sieht Tag 2, entfernt es und wirft das Paket in das Ziel-VLAN.

Soweit die Theorie! Ich habe mir zwei Cisco [2] Switches besorgt (2940 und 3500XL) und zwei Rechner und habe alles folgendermaßen konfiguriert:
Rechner 1 -> 2940 -> 3500 -> Rechner 2
Dabei war Rechner 1 in VLAN 5 und Rechner 2 in VLAN 7. Es sollte also keine Kommunikation stattfinden können, da die Rechner sich überhaupt nicht sehen konnten und kein Router im Spiel war.

Während des Tests habe ich mehrere ICMP-Pakete fingiert und zwei VLAN-Tags eingefügt (mit Packeth [3]), es ist allerdings kein Paket zum Zielrechner durchgekommen.

Warum? Nun, das ist ganz einfach zu erklären: Diese ganzen tollen VLAN-Theorien werden schlichtweg ausgehebelt, wenn man als Attack-Rechner nicht an einem Trunk-Port hängt. Da bei meiner Konfiguration DTP [4] abgeschaltet war, mein Verbindungsport zum Switch als festeingestellt ein Access Port war, kam kein einziges Paket durch.

Im Nachhinein habe ich das ganze dann nochmal über einen Trunk-Port getestet und schon kamen meine Pakete durch. Wer also Switche sicher(er) konfigurieren will, legt selber fest, welcher Port welchen Modus hat.

Konfiguriert man normale Ports als Access-Ports, müsste ein Angreifer schon physischen Zugriff auf das Switch haben, um sich auf einen Trunk-Port zu verbinden und das sollte doch in den meisten Fällen sehr unwahrscheinlich sein.
In diesem Zusammenhang sei noch folgendes angemerkt:
Wenn man die Switches konfiguriert, AUF JEDEN FALL Passwörter setzen.
Wenn man das Webinterface zur Konfiguration nicht benötigt, ABSCHALTEN.
Wenn man das Switch remote Verwalten möchte, SSH [5] statt Telnet nutzen.
Benutzt man SNMP [6], dann bitte nicht in Version 1, sondern Version 3.
Nicht benötigte Ports abschalten.
Wenn möglich, MAC-Filter setzen.

So, das war mal mein Wort zum Samstag.

---

[1]: http://en.wikipedia.org/wiki/VLAN_hopping
[2]: http://www.cisco.com
[3]: http://packeth.sourceforge.net/
[4]: http://en.wikipedia.org/wiki/Dynamic_Trunking_Protocol
[5]: http://en.wikipedia.org/wiki/Ssh
[6]: http://en.wikipedia.org/wiki/Snmp

Vim: Autoindent abschalten

Wer kennt das nicht: Man hat sich ein paar hundert Zeilen in die Zwischenablage kopiert, erstellt mit dem Vim ein neues Dokument, fügt den Inhalt der Zwischenablage ein… und es sieht grauenhaft aus! Jede Zeile ist um ein Tab weiter eingerückt. Wunderbar – besser gesagt: Nicht lesbar!

Doch auch dafür gibt es Abhilfe:
echo set noautoindent >> /etc/vim/vimrc
und schon wird der Inhalt der Zwischenablage sauber formatiert eingefügt!

Ethernet-Bridge DHCP-Paket Analyse

Zugegeben, der Titel klingt spannender als die Arbeit eigentlich war. Aber egal, interessant war es trotzdem!

Vorweg noch ein wichtiger Hinweis: Die im folgenden beschriebenen Arbeiten habe ich ausschließlich in meinem privaten Netzwerk durchgeführt und die gewonnenen Daten dienen auch lediglich der Analyse. Mal davon ab, handelte es sich bei dem ganzen „Projekt“ um eine Hausaufgabe!

So, jetzt gehts los:
Mein Analyse-PC hat vor ein paar Tagen eine zweite Netzwerkkarte spendiert bekommen, weil ich die Pakete, die aus meinem Zimmer Netzwerk in Richtung Router (und damit Internet) gehen, einfach mal sehen wollte.
Oder um es ganz simpel auszudrücken:
Welche Anwendung brüllt was ins Netz?

Schritt 1 (Einbau der zweiten Netzwerkkarte):
Na ja, es sollte jedem klar sein, wie man eine Netzwerkkarte in einen PC bekommt. In meinem Fall war das Ganze mit ein wenig Fummelei verbunden, da mein Test-PC ein Micro-ATX-Board mit nur 2 PCI-Steckplätzen eingebaut hat.

Schritt 1,5 (Installation des Betriebssystems)
Bei mir notwendig, weil ich gleichzeitig noch eine neue Festplatte in den PC gebaut habe.
Debian Testing gabs auf die Platte, zu beachten nichts weiter, außer dass die Installation beide Netzwerkkarten als eth0 und eth1 erkennt und man wählen muss, welches die primäre Netzwerkkarte werden soll.
Das Netzwerk nicht per DHCP konfigurieren lassen, sondern feste IPs vergeben!

Schritt 2 (Ethernet-Bridge bauen)
Dank Werner (Arbeitskollege), der mich auf einen Artikel auf heise.de hingewiesen hat, war das erstellen der Ethernet-Bridge denkbar einfach:
ifconfig eth0 -arp promisc 0.0.0.0 up
ifconfig eth1 -arp promisc 0.0.0.0 up
brctl addbr br0
brctl addif br0 eth0
brctl addif br0 eth1
ifconfig br0 -arp promisc 0.0.0.0 up
Funktioniert brctl nicht, muss das Paket bridge-utils nachinstalliert werden. (Das geht aber nur vor den beiden ifconfig-Schritten, wenn man nur über 2 Netzwerkkarten verfügt)
Zu beachten gibt es eigentlich nichts weiter, bei mir hat das alles auf Anhieb geklappt.

Schritt 3 (Pakete analysieren)
Es gibt sicher andere Tools, aber ich habe den Wireshark benutzt. Als capture device einfach br0 angeben und bei Bedarf die Paketauswahl eingrenzen und dann kann es losgehen

Schritt 4 (Fazit):
Einfach und schnell, aber effektiv. So geht der Einstieg in die Netzwerkanalyse gut von der Hand und macht sogar Spaß Quasi etwas für die ganze Familie
Interessant fand ich folgenden Sachverhalt:
Debian-Kommunikation mit dem DHCP-Server:
(Client) Discover -> (Server) Offer -> (Client) Request -> (Server) Acknowledge -> (Client) Release

Windows XP-Kommunikation mit dem DHCP-Server:
(Client) Request -> (Server) Acknowledge -> (Client) Inform -> (Client) Inform
Kein Discover, kein Offer, kein Release… die Frage ist nur: Warum?

So, damit erstmal genug für heute. Mal sehen, es noch so zu entdecken gibt…

EDIT: Wieder was dazu gelernt! Ich weiß jetzt warum Windows weniger DHCP-Pakete durch die Gegend schickt als Debian.
Das Lease für die Windows-IP ist noch nicht abgelaufen, also wird nur geprüft (Request -> Acknowledge) ob die Informationen noch gültig sind. Außerdem wird an dieser Stelle das Lease verlängert.
Bei meinem Debian ist das so nicht möglich, da beim runterfahren ein Release gesendet wird, womit das aktuelle Lease gecancelt und die IP-Adresse wieder freigegeben wird.
Laut RFC2131 sind beide Wege korrekt – der Debian-Weg kostet aber etwas mehr Netzwerktraffic, was sich vor allem in großen Netzwerken bemerkbar machen dürfte.
Im Gegensatz dazu läuft bei einer langen Lease-Time die Range des DHCP-Servers schneller voll, wenn Windows nie ein Release sendet…

ScummVM MIDI-Problem

So, da wollte ich doch mal ein paar alte Klassiker über ScummVM spielen. Zu Anfang sah alles noch recht einfach aus:

apt-get update
apt-get install scummvm
/usr/games/scummvm

Dann ein paar Spiele hinzufügen (die muss man schon selber zur Verfügung stellen – Beneath A Steel Sky und Flight Of The Amazon Queen gibts aber zu Linux dazu).

Und dann gib ihm. Dachte ich.
Using configuration file: ~/.scummvmrc
Looking for monkey
Trying to start game 'The Secret of Monkey Island'
Can't subscribe to MIDI port (65:0) see README for help!

Nach ein wenig googlen fand ich dann die Lösung! Man muss ScummVM auf den Alsa-Port 17:0 umbiegen:
vim ~/.scummvmrc
alsa_port=17:0 einfügen
/usr/games/scummvm

Looking for monkey
Trying to start game 'The Secret of Monkey Island'
Can't subscribe to MIDI port (17:0) see README for help!

Mmh. Weiter googlen! Irgendjemand schrieb dann was von aconnect -o -l

ocelot:/home/nickolsen# aconnect -o -l
client 14: 'Midi Through' [type=kernel]
0 'Midi Through Port-0'

Idee: Warum ScummVM nicht auf den vorhandenen Port 14 umbiegen?

vim~/.scummvmrc
alsa_port=14:0
/usr/games/scummvm

Und die Spiele starten… aber leider ohne Sound.

Wieder eine Baustelle…

VIM: Syntax Highlighting

Wenn der VI erkennt, um welche Art von Programmiersprache es sich handelt (an Dateiendung?!), ist das Highlighting im VI aufrufbar per
:syntax on
abschaltbar
:syntax off

Standardmäßig aktivieren kann man es in der:
/etc/vim/vimrc
und zwar einfach bei der Zeile
syntax on
das Kommentarzeichen entfernen und speichern!
Ab sofort wird dann bei jeder Datei, die man im VIM öffnet, die Syntax farbig markiert.

Danke an www.dappes.com für die Anleitung!