Wie lade ich ASDM von einer Cisco ASA 5505 herunter und installiere es?

Hat der Benutzer seine Cisco ASA 5505 nun endlich ausgepackt, gestartet, Serial online, gefreut, Hostnamen eingestellt und… ja konfiguriert? Ja, möglicherweise gibt es da einen Hackenfuß. Auf beiliegenden Datenträgern wird der Benutzer unter Umständen nicht fündig, noch spricht die ASA HTTP über ein Interface. Der Quick Start Guide ist ebenso wenig hilfreich, da es oft nicht am Kabel anstecken hapert. Somit bleibt dem Anfänger das Rätsel: Wo ist mein Web-Interface zum Konfigurieren hin? Natürlich birgt die beiliegende CD ganz viel interessanter Sachen, aber leider sucht der Benutzer vergebens, was er nun gerade braucht. 🙂

Nun gut. Kabel angesteckt, also PC an die ASA, bzw. ASA an das Switch. Ein DHCP Server könnte konfiguriert werden, aber dies wird hier an der Stelle nicht beschrieben, da oft der PC und das Netzwerk an sich läuft. Es wird aber kurz auf die Vergabe von IPs und so weiter eingegangen. So, die Lampen leuchten schonmal. Nun schaut der Benutzer auf die Kommandozeile oder Powershell seines Windows Systems und betrachtet die IP Konfiguration. Hier ein Beispiel:

C:\> ipconfig /all
Ethernet-Adapter LAN-Verbindung:

Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Intel(R) 82577LM Gigabit Network Connection
Physikalische Adresse . . . . . . : 00-88-42-23-32-64
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : Ja
IPv6-Adresse. . . . . . . . . . . : fd23:4264:c0ff:ee42::116(Bevorzugt)
Verbindungslokale IPv6-Adresse . : fe80::dead:beef:1338:4242%10(Bevorzugt)
IPv4-Adresse . . . . . . . . . . : 192.168.42.116(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.255.0
Standardgateway . . . . . . . . . : 192.168.42.254
DHCPv6-IAID . . . . . . . . . . . : 240975669
DHCPv6-Client-DUID. . . . . . . . : 00-01-01-01-13-46-71-5A-5C-AB-35-21-FF-9A
DNS-Server . . . . . . . . . . . : 192.168.42.1
208.67.222.222
208.67.220.220
8.8.8.8
NetBIOS über TCP/IP . . . . . . . : Aktiviert

Gut, die ASA braucht jetzt eine neue IP, die im gleichen Subnetz liegt und frei ist. Es wird der Port 0 konfiguriert, als Ethernet 0/0. Es wird angenommen, dass die IP 192.168.42.200 frei ist. Also los geht es auf der ASA. Dazu verbinde man das serielle Kabel und klinkt sich auf die Serielle Schnittstelle ein. Hat der PC kein COM Port mehr, hilft ein billiger USB to serial Converter von ebay (Ich hab den von Digitus probiert und er läuft gut.). Nun noch PuTTY herunterladen und starten. Unter dem Gerätemanager in Windows kann nachgesehen werden, welcher COM Port virtuellerweise der USB Adapter bekommen hat. Nun auf serielle Verbindung klicken und oben den Port angeben, bei mir ist das COM11. 9600 Baud braucht das Gerät, also unter Speed 9600 eintragen. Und poff, nun sollten Zeichen auf der Console erscheinen. Etwas auf Enter drücken, da kommt dann die Shell. Nun einloggen.

ciscoasa> enable
ciscoasa# conf t
ciscoasa(config)# interface vlan 23
ciscoasa(config-if)# nameif mgnt
ciscoasa(config-if)# security-level 100
ciscoasa(config-if)# ip address 192.168.42.200 255.255.255.0
ciscoasa(config-if)# no shut
ciscoasa(config-if)# end
ciscoasa# conf t
ciscoasa(config)# interface Ethernet 0/0
ciscoasa(config-if)# switchport access vlan 23
ciscoasa(config-if)# no shut
ciscoasa(config-if)# end
ciscoasa#

Nun sollte die ASA auf dem Port 0 unter der eingegebenen IP erreichbar sein. Unter Windows einfach mal mithilfe der Kommandozeile anpingen:

C:\Users\Neurodump>ping 192.168.42.200

Ping wird ausgeführt für 192.168.42.200 mit 32 Bytes Daten:
Antwort von 192.168.42.200: Bytes=32 Zeit<1ms TTL=255
Antwort von 192.168.42.200: Bytes=32 Zeit<1ms TTL=255
Antwort von 192.168.42.200: Bytes=32 Zeit<1ms TTL=255
Antwort von 192.168.42.200: Bytes=32 Zeit<1ms TTL=255

Ping-Statistik für 192.168.42.200:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 0ms, Maximum = 0ms, Mittelwert = 0ms

C:\Users\Neurodump>

Das Tool nmap liefert dem Benutzer eine Portmessung, ob das Port des Webservers offen ist. Dazu muss nmap vorher installiert worden sein. Da später mit https verbunden werden wird, wird hier Port 443 angenommen. Der Port kann bei der ASA frei gewählt werden. Hier werden allerdings die Standardeinstellungen verwendet werden. Nun sollte das Port des HTTPS Servers auf der ASA nicht offen sein, da noch keine Konfiguration erfolgt ist. nmap sollte hier keinen offenen Port zeigen.

C:\Users\Neurodump>nmap -sT -p 443 192.168.42.200

Starting Nmap 5.21 ( http://nmap.org ) at 2012-04-18 12:57 Mitteleuropäische Sommerzeit
Nmap scan report for 192.168.42.200
Host is up (0.0020s latency).
PORT STATE SERVICE
443/tcp filtered https
MAC Address: 88:43:F1:10:E1:AA (Unknown)

Nmap done: 1 IP address (1 host up) scanned in 1.23 seconds

C:\Users\Neurodump>

nmap zeigt den Port als „filtered“ an, also kommt keine Antwort zurück. Das Port ist also nicht geschlossen, sondern die Firewall blockiert den Port komplett. Wurde das Konfigrurationsziel erreicht, so wird der Port als open erscheinen. Jetzt braucht es allerdings noch eine kleine Sache: Es braucht einen Benutzer, der die höchsten Rechte besitzt. Das bedeutet in dem Fall Level 15 Rechte. Die werden folgendermaßen konfiguriert. Danach aktiviert der Benutzer den HTTP Server der ASA.

ciscoasa# conf t
ciscoasa(config)# username admin password cisco privilege 15
ciscoasa(config)# aaa authentication http console LOCAL
ciscoasa(config)# http server enable
ciscoasa(config)# http 192.168.42.0 255.255.255.0 mgmt
ciscoasa(config)# end

Nun wird wieder per nmap gecheckt, ob der Port un offen ist.

C:\Users\Neurodump>nmap -sT -p 443 192.168.42.200

Starting Nmap 5.21 ( http://nmap.org ) at 2012-04-18 14:43 Mitteleuropõische Som
merzeit
Nmap scan report for 192.168.42.200
Host is up (0.0022s latency).
PORT STATE SERVICE
443/tcp open https
MAC Address: 88:43:F1:10:E1:AA (Unknown)

Nmap done: 1 IP address (1 host up) scanned in 0.98 seconds

C:\Users\Neurodump>

So, der HTTP Server ist nun bereit. Nun wird der SSH Dienst konfiguriert. Auf diese Weise muss nicht immer per seriellem Kabel mit der ASA kommuniziert werden.

ciscoasa# conf t
ciscoasa(config)# crypto key generate rsa modulus 2048
INFO: The name for the keys will be: <Default-RSA-Key>
Keypair generation process begin. Please wait...
ciscoasa(config)# write mem
Building configuration...
Cryptochecksum: 3bb9a222 98aaad52 381457af 7e7e9678

2261 bytes copied in 1.630 secs (2261 bytes/sec)
[OK]

Nun wird definiert, welche IP Range sich auf den SSH Dienst verbinden darf. Es muss für den SSH Zugang das Subnetz und das Interface angegeben werden, wo der SSH Dienst arbeiten soll. Der Benutzer muss vorher die Interfacenamen vergeben haben. Ist das der Fall, so tauchen dir mit dem ? Operator einfach auf und gut. Wenn nicht, müssen sie mit nameif in der Interfacekonfiguration definiert werden.

ciscoasa(config)# ssh 192.168.42.0 255.255.255.0 ?

configure mode commands/options:
Current available interface(s):
inside Name of interface Vlan1
mgmt Name of interface Vlan23
ciscoasa(config)# ssh 192.168.42.0 255.255.255.0 mgmt
ciscoasa(config)# username admin password cisco privilege 15
ciscoasa(config)# aaa authentication ssh console LOCAL
ciscoasa(config)# end
ciscoasa#

Nun sollte der SSH Dienst auf dem Port 22 aktiv sein und funktionieren. Getestet wird das fix per nmap.

C:\Users\Neurodump>nmap -sT -p 22 192.168.42.200

Starting Nmap 5.21 ( http://nmap.org ) at 2012-04-18 14:03 Mitteleuropõische Som
merzeit
Nmap scan report for 192.168.42.200
Host is up (0.00025s latency).
PORT STATE SERVICE
22/tcp open ssh
MAC Address: 88:43:F1:10:E1:AA (Unknown)

Nmap done: 1 IP address (1 host up) scanned in 15.53 seconds

C:\Users\Neurodump>

Sieht gut aus, nun wird per PuTTY getestet, ob ein Zugang zum System möglich ist. Dazu entsprechend SSH wählen, Port 22 und die IP der ASA. Hier die Ausgabe der Console unter SSH mit PuTTY.

login as: admin
admin@192.168.42.200's password:
Type help or '?' for a list of available commands.
ciscoasa> login
Username: admin
Password: *****
ciscoasa#

Ausgezeichnet. Nun kann die ASA statt mit dem seriellen Kabel auch mit SSH sicher administriert werden. Final noch die Dinge speichern!

ciscoasa# copy run start

Source filename [running-config]?
Cryptochecksum: 116d4683 e8723782 a00ee28c a1264354

2418 bytes copied in 1.600 secs (2418 bytes/sec)
ciscoasa#

Fertig. Nun mit der IP Adresse auf den Router verbinden und die ASDM Sachen herunterladen und weiter gehts mit dem Tool.

Cisco ASA 5505 auf Factory Default setzen

Möchte ein Benutzer seine ASA 5505 auf die Werkseinstellungen zurückstellen, muss folgendes eingegeben werden. Das Passwort für „enable“ muss bekannt sein.

asa> enable
asa# conf t
asa(config)# config factory-default
asa(config)# no enable password

Der letzte Befehl entfernt das enable Passwort aus der ASA.

Konfigurieren einer Cisco ASA 5505 als transparente Firewall

Eine Cisco ASA 5505 kann in zwei Betriebsarten konfiguriert werden, nämlich sls transparente Firewall oder als Routed Firewall. Normalerweise wird eine ASA meist als eine Routed Firewall eingerichtet. Der Grund liegt darin, dass eine transparente Firewall nicht so ohne weiteres bei der Fehlerdiagnose auftaucht. Sie ist transparent. Damit taucht sie im traceroute nicht als Hop auf. Ein Admin, der einen Fehler sucht, kann über diese Stolperfalle stürzen, sollte eine transparante Firewall Pakete filtern, die gebraucht werden. Es kann nicht einfach sein diese Firewall zu entdecken, sollte sie nicht im Netzwerkplan auftauchen. Daher werden Firewalls gerne als Routed Firewalls konfiguriert. Der Admin schaut von Hop zu Hop, ob alles okay ist und schlußendlich hangelt er sich an das Problem heran.

Hier wird eine ASA als transparante Firewall konfiguriert. Die Anwendung kann im Heimnetzwerk ganz nützlich sein, bzw. die Konfiguration kann verwendet werden, um ganze Netzbereiche aus dem Traffic auszufiltern. Es wird nicht detailliert auf die Inhalte der Access-Liste eingegangen. Die Konfiguration geht nur soweit, dass die transparante Firewall soweit betriebsbereit ist, allerdings wenig bis nichts filtert.

Das Netzwerk sieht so aus, zumindest der kleine Teil.

192.168.200.1 (Router zum DSL)
|
|
ASA <---- 192.168.200.2 (IP zum Konfigurieren der ASA) | | 192.168.200.3 (PC/LAN)

Warum eine transparante Firewall im Netzwerk, die IP Bereiche filtert? Das Problem unliebsamer Besucher, Malware und andere Dinge, nimmt mehr und mehr zu. Es kann sinnvoll sein, als Kleinunternehmen oder Privatmann bestimmte Netzwerke komplett aus seinem Interneterlebnis auszublenden.

Es gibt Netzwerke, woher nichts Gutes kommt. Den ganzen Block, den man ohnehin nicht gerne ansurft, hält man komplett von sich weg. Verbindungen jeder Art werden komplett von der ASA weggeworfen und möglicherweise wird der Aspekt geloggt, wenn man als Admin das wünscht. Damit kann vielleicht ein Exploit erfolgreich wirken, der Loader bekommt aber unter Umständen keinen Connect. Natürlich kann es gut sein, das es dann über einen Proxy oder weiß der Himmel läuft, klar... Pech. Das gefilterte Bereich sollte auch recht riesig sein und ein oder mehrere Länder betreffen. Im Grunde muss jeder wissen, was er gerne im Netz so macht, jedem Kleinunternehmen könnte man ans Herz legen über bestimmte Filter nachzudenken, die Teile des Netzes komplett wegschmeist.

Anhand des Bildes hat man nach wie vor ein flaches Netzwerk. Maschinen, die direkt am DSL Router hängen, der vielleicht ncoh einen WLAN AP eingebaut hat, gehen ungefiltert ins Internet. Die andere Seite der ASA nicht. Auf diese Weise behält man ein wenig seine Flexibilität bei, per WLAN ungefiltert ins Internet, per Kabel mit einem gewissen Filter. Was genau gefiltert werden sollte, werde ich an dieser Stelle nicht erwähnen. Jeder möge sich da seine eigene Blockliste zusammenstellen.

Gut, wie wird so eine ASA eingerichtet?

asa> enable
asa# conf t
asa(config)# firewall mode transparent
asa(config)# no names

asa(config)# interface Vlan1
asa(config-if)# nameif inside
asa(config-if)# security-level 100
asa(config-if)# exit

asa(config)# interface Vlan2
asa(config-if)# nameif outside
asa(config-if)# security-level 0
asa(config-if)# exit

asa(config)# interface Ethernet0/0
asa(config-if)# switchport access vlan 2
asa(config-if)# no sh
asa(config-if)# exit

asa(config)# interface Ethernet0/1
asa(config-if)# no sh
asa(config-if)# exit

asa(config)# interface Ethernet0/2
asa(config-if)# no sh
asa(config-if)# exit

asa(config)# interface Ethernet0/3
asa(config-if)# no sh
asa(config-if)# exit

asa(config)# interface Ethernet0/4
asa(config-if)# no sh
asa(config-if)# exit

asa(config)# interface Ethernet0/5
asa(config-if)# no sh
asa(config-if)# exit

asa(config)# interface Ethernet0/6
asa(config-if)# no sh
asa(config-if)# exit

asa(config)# interface Ethernet0/7
asa(config-if)# no sh
asa(config-if)# exit

asa(config)# access-list OUTSIDE-IN permit ip any any
asa(config)# access-group OUTSIDE-IN in int outside
asa(config)# ip address 192.168.200.2 255.255.255.0
asa(config)# monitor-interface outside
asa(config)# monitor-interface inside
asa(config)# end
asa# copy run start

ICMP Verkehr bei Cisco ASA erlauben/filtern

Standardmäßig ist bei der Cisco ASA einlaufender ICMP Verkehr verboten. Ausgehender ICMP Verkehr ist wiederum erlaubt, allerdings wird das rücklaufende Packet, der PONG geschluckt. Wie erlaubt der Admin nun ICMP Verkehr, so dass alle Clienets, die an der ASA angeschlossen sind, frei pingen dürfen? Man legt eine Access-List an, die entsprechend den ICMP Verkehr zulässt, den man haben möchte. Diese Access-List muss an das Interface zum Internet, meist outside genannt angeknüpft werden, damit sie dort wirkt. Damit wird der einlaufende ICMP Verkahr erlaubt. Unten stehen die Befehle für die IOS Konsole.

asa# access-list 101 permit icmp any any echo-reply
asa# access-list 101 permit icmp any any source-quench
asa# access-list 101 permit icmp any any unreachable
asa# access-list 101 permit icmp any any time-exceeded
asa# access-group 101 in interface outside

Hat der Admin das outside Interface anders benannt, muss hier statt outside der richtige Bezeichner verwendet werden. In dem Beispiel oben, wird mehr als nur der Ping erlaubt. Wozu die einzelnen ICMP Typen gut sind, verrät das entsprechende RFC792.

Erzeugen eines verschlüsselten File-Containers unter Linux

Möchte ein Benutzer auf seinem Webserver oder Heimcomputer einen verschlüsselten Container mit sensiblen Daten erzeugen, so muss zuerst einmal die Datei her, wo diese Daten abgelegt werden sollen. In dem Beipsiel wird eine 2GB große Datei erzeugt. Zuerst wird mit dd eine Datei geschrieben, die mithilfe von urandom viel Schrott beinhaltet. Auf diese Weise kann nicht gesagt werden, wieviele verschlüsselte Daten sich in dieser Datei befinden. Anschließend wird mit mkdir das Zielverzeichnis erzeugt, wohin das Crypto-Device gemounted werden soll.

sample:/# dd if=/dev/urandom of=/home/username/myfile bs=4096 count=524288
sample:/# mkdir /home/username/myfiles
sample:/# ls -l
total 2099208
-rw-r--r-- 1 root root 2147483648 Dec 10 01:16 myfile
drwxr-xr-x 3 root root 4096 Dec 10 02:35 myfiles

Nun muss ein Loop-Device erzeugt werden. losetup erlegt das für uns. So wird sozusagen aus einer Datei ein virtuelles Blockdevice erzeugt. Auf diesem Blockdevice kann wiederum so zugegriffen werden, wie der Benutzer es von Festplatten gewohnt ist.

sample:/# losetup /dev/loop0 /home/username/myfile

Nun existiert ein Blockdevice /dev/loop0. Dieses wird nun mithilfe von cryptsetup initialisiert. Die Parameter finden sich in der man-page wieder. Ab Linuxkernel 2.6.10 kann ein alternatives IV Schema zur Verhinderung einer „Watermark Attack Weakness“ verwendet werden. Hierzu kann aes-cbc-essiv:sha256 verwendet werden.

sample:/# cryptsetup -y -c aes -s 256 -h sha256 create mycrypt /dev/loop0

Nun existiert ein neues Blockdevice unter /dev/mapper/mycrypt. Dies ist wiederum ein virtuelles Gerät, welches durch die Verschlüsselungsroutinen mit dem angegebenen Kennwort so geleitet wird, dass schlußendlich der verschlüsselte Datenstrom auf das Loop-Device /dev/loop0 gelangt, was wiederum dann in der Datei selbst landet. Das wars schon. Nun das Gerät mit einem Dateisystem ausstatten.

sample:/# mkfs.ext3 /dev/mapper/mycrypt

Jetzt kann das Laufwerk gemountet werden. Hierzu einfach das verwendete Dateisystem eingeben und das Laufwerk zum angegeben Verzeichnispunkt mounten.

sample:/# mount -t ext3 /dev/mapper/mycrypt /home/username/myfiles
sample:/# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 15G 7.4G 6.7G 53% /
tmpfs 100M 0 100M 0% /lib/init/rw
udev 10M 16K 10M 1% /dev
/dev/mapper/mycrypt 2.0G 68M 1.9G 4% /home/username/myfiles

Soweit so gut. Nun gibt es ein neues verschlüsseltes Laufwerk im System, auf das der Benutzer nach herzenslust sensible Daten schreiben kann. Die Passphrase sollte entsprechend lang sein und zusätzlich auch eine gewisse Komplexität beinhalten. Das bedeutet, Sonderzeichen, Groß- und Kleinschreibung und Zahlen. Empfohlen wird von mir eine Länge von mindestens 30 Zeichen.

Loop Device fehlt unter Linux

Möchte ein Benutzer ein Loop Device verwenden, kommt es selten zur folgenden Fehlermeldung.

sample:/# losetup /dev/loop0 /home/username/myfile
/dev/loop0: No such file or directory

Der Grund für diese Meldung liegt darin zugrunde, dass das Kernelmodule loop nicht geladen worden ist. Abhilfe schafft kurzerhand:

sample:/# modprobe loop

Nun funktionieren die Loop Devices, jedoch sind nach einem Reboot diese wieder verschwunden. Auch hier gibt es eine schnelle Abhilfe. Unter Debian/Ubuntu/Mint unter /etc/modules eintragen. (Zeile „modprobe loop“ hinzufügen)

Werden bei ICQ MAC-Adressen übermittelt?

Nein, ICQ sendet keine MAC-Adressen zu einem anderen Rechner, es sei denn, die Version würde ein wenig umgeschrieben worden sein. Aber das wäre eher das Bereich eines Trojaners. MAC Adressen werden im Ethernet für die Adressierung der Geräte verwendet. Daher hat jeder Node im Ethernet eine MAC Adresse. MAC Adressen liegen im Layer 2 des ISO/OSI Referenzmodels.

Ungefähr das Ganze aufgemalt. Der Benutzer sendet eine ICQ Nachricht ab. Diese durchläuft schematisch gesehen alle sieben Schichten. Damit die Daten zum DSL Router kommen, müssen sie über das LAN transferiert werden. Hier gibt es nur MAC Adressen für die Adressierung. Ein Stichwort ist hier das ARP Protokoll. Um eine IP im LAN ansprechen zu können, muss das System die MAC Adresse des Systems haben. ARP sorgt dafür, dass das Betriebssystem in der Lage ist das TCP und IP Paket in ein korrektes MAC Frame zu packen, um es schlußendlich über das Ethernet zu senden.

Der Router nimmt nun das Paket entgegen, packt es aus und findet das IP und das TCP Paket vor. Nun wertet er anhand der Routingtabelle aus, wohin das Paket nun soll. IP Masquerading liegt ebenso meist noch dazwischen, so dass zusätzlich noch das TCP und IP Paket noch umgearbeitet wird. Jetzt wandert das bei DSL in PPPoE hinein. Dort gibt es keine Adressierung mit MAC. Der Endpunkt ist ein IP basierender Concentrator. Weiter geht es durch viele IP Router durchs Internet. So endet die MAC Adresse des Quellrechners beim DSL Router des Hauses.

VLAN im Livebetrieb ausrollen, ohne den Betrieb zu stören?

Geht das? Ja, kommt aber darauf an, was die Switches können und wie das Netzwerk generell aufgebaut ist. Liegt kein VLAN vor, so liegt das Netzwerk im Native VLAN. Das ist das VLAN 1. Nun können freie Ports des Switches in weitere neue VLANs gelegt werden. Die Uplinks müssen etwas angepasst werden, damit über einen Trunk das VLAN auch zum anderen Switch durchgereicht wird. Das Netzwerk, welches sich gerade im Betrieb befindet wird dabei nicht angefasst. Sichergestellt werden sollte, dass die ganze Umgebung von einem Hersteller ist. Beispielsweise nur Cisco, 3COM, HP oder Alcatel. Es sollte kein Switch existieren, welches nicht managebar ist.

Sollte die Umgebung aus einem völligen Chaos bestehen, so muss sehr vorsichtig gebastelt und ein wenig experimentiert werden, ob die Geräte sich gegenseitig verstehen. Trunk ist zwar mehr oder weniger genau im 802.1q festgelegt, aber Alcatel hat zum Beispiel auch ein eigenes Trunkprotokoll auf ihren Geräten verbaut. Manchmal gibt es in Mischumgebungen kleine oder größere Rätsel, warum etwas nicht funktioniert. Abgesehen, dass der Admin immer ein anderes Gerät vor seiner Nase hat, was sich anders konfigurieren lässt. Was meiner Erfahrung nach ganz gut ist, dass alle Switche immer die gleiche Firmwareversion drauf haben.

Ist sich der Admin unsicher, sollte er vorher ausprobieren, welche Auswirkungen seine Änderungen haben. Eine falsche Einstellungen hat schnell zur Folge, dass plötzlich ein System nicht mehr erreichbar ist und das kann den Livebetrieb dann schonmal zum Erliegen bringen.

Sind VLAN-fähige Switche robuster gegen Angriffe?

Angriffe auf eine Netzwerkinfrastruktur sind vielschichtig. Ist es möglich, dass Switche, die mehrere VLANs Betreiber robuster gegen Angriffe sind? Ja, aber es kommt drauf an.

Switche, die managebar sind, haben eine IP Adresse in einem LAN. Über diese IP loggt sich der Systemadmin ein und hat die Kontrolle über das Gerät. Natürlich gibt es an dieser Stelle auch Passwörter, die nicht jeden rein lassen, der anklopft. Doch manchmal bekommen Passwörter Beine. Gerade bei geplanten Angriffen ist die Wahrscheinlichkeit recht groß, dass das eine oder andere Passwort bekannt geworden ist. Schließlich befindet sich dann der Angreifer schon erfolgreich im Netzwerk und hat zumindest einen Zugang längst gebrochen.

Daher ist es unbedingt erforderlich, aus Sicht der Netzwerksicherheit, dass das VLAN, womit das Switch administriert werden kann, in keinem Fall durch unberechtigte Benutzer erreichbar sein darf. Das sollte so bewerkstelligt werden, dass es separat gepatcht und in keinster Weise geroutet wird. Auch eine physikalische Verbindung zu Routern und der Außenwelt sollte vermieden werden.

Doch warum so ein Aufwand? Wenn eine Infrastruktur angegriffen wird, so spielt der Betreiber die Kontrolle seine Geräte dem Angreifer in die Hände, sollte er Zugriff auf die Konfigurationsschnittstellen der Netzwerkinfrastruktur bekommen. Je weniger es denkbar ist, dass die Konfigurationsschnittstellen durch einen Angreifer erreichbar sein könnten, je besser.

Ändert ein Angreifer erfolgreich die Kennwörter in einem Netzwerkgerät, so fällt die Kontrolle eines Segments in die Hände der Angreifer. Er kann dann tun und lassen, was er möchte, ohne dass dies vorerst verhindert werden kann. Da hilft nur Stecker ziehen, aber damit wird es bei einem selbst auch dunkel.

Mithilfe von Inter-VLAN-Routing kann ein Angreifer, durch die Änderungen der Config am Switch erreichen, dass er weitere Bereiche ansprechen kann, die vorher für ihn nicht zu sehen waren. Ist das Netzwerk kompromittiert, sind die Möglichkeiten einen Angreifer zu lokalisieren sehr begrenzt. Zugleich wird der Angriff erfolgreicher. Das Monitoring kann durch einen Angreifer erheblich gestört werden, sollte er auf Router und Switche Zugriff haben.

Das Verlagern der Konfigurationsschnittstellen in ein separates VLAN ist also eine gute Idee. Damit leisten VLAN fähige Switche mit einer sinnvollen Einstellung einen wichtigen Beitrag zur IT Sicherheit. Aus diesem Grund sollte an dieser Stelle nicht zu sehr gespart werden. Eine Schnittstelle, die nicht auf Layer 2 erreichbar ist, kann im LAN nicht gehackt werden.

Final muss gesagt werden, dass jedes Switch technisch gleich angreifbar ist. Also alle Layer 2 Angriffe funktionieren genauso auf einem managebaren Switch, wie auch auf einem völligen normalen Consumer-Switch. Für den Schutz des Netzwerkes und der Nodes müssen weitere Komponenten installiert werden. Das sind meist Security Appliances.

Festplatten sicher löschen mit DBAN und GRML

Möchte ein Benutzer sauber seine Daten von einer Festplatte löschen, so ist DBAN die erste Wahl. DBAN gibt es in Version 1.07 und 2.2.6. Je nachdem, um welchen Rechner es sich handelt, funktioniert die eine Version besser, als die andere oder umgekehrt. Hier gilt: Ausprobieren. DBAN ist eine Linux Live CD die nichts anderes startet, als ein kleines Programm, was Festplatten sauber löscht. Da existieren einige Verfahren, die teils sehr nützlich sind, sollte es sich um sehr besondere Daten handeln. Im normalen Falle reicht der Quick Erase. Hierbei werden alle Daten mit Nullen überschrieben. Das reicht für 99,5% aller Fälle vollkommen aus. Die restlichen Kandidaten, sollten ihre Festplatte dann doch lieber in einen Ofen einschmelzen.

DBAN steht für Darik’s Boot and Nuke. Auch Computerschädlinge, wie Viren, Trojaner und Rootkits lassen sich damit sauber entfernen. Es wird wirklich alles gelöscht. Auch die Bereiche, die bei einer Formatierung oder Neuinstallation noch übrig bleiben. Bei einem Befall ist damit DBAN auch eine gute Option.

Natürlich geht das auch anders, etwas komplexer. Man starte die GRML Live CD und verwende dd, um mit dem virtuellen Device zero die Platte zu nullen. Der Befehl würde beispielsweise so aussehen.

dd if=/dev/zero of=/dev/sda bs=512

Damit wird das erste SCSI Gerät mit Nullen überschrieben. Natürlich sollte der Benutzer vorher wissen, welches Gerät er löschen möchte. Es ist schade, wenn doch wichtige Daten durch einen Tippfehler vernichtet werden. Alle Aktionen lassen sich unter keinem Umstand mehr Rückgängig machen. Daher sind ausreichende Linuxkenntnisse an dieser Stelle wichtig. Was weg ist, ist damit wirklich weg. Auch für Labore oder Experten.

DBAN funktioniert bei sehr vielen Rechnern. Wenn das System zu neu ist, tauchen eingebaute Festplatten manachmal nicht auf, weil der Treiber im kernel fehlt. Da hilft dann nur ein Update oder die Handarbeit mit GRML.

Hier gibts GRML zum Herunterladen
Hier gibts DBAN zum Herunterladen