Die ID88 bringt wie bereits geschildert zwei Netzwerkschnittstellen mit, die dann an die virtuellen Maschinen durchgereicht werden müssen. Damit dies reibungslos funktioniert und auch die Zusammenarbeit mit dem Router (hier: Fritzbox) klappt, kann man wie folgt vorgehen, um sich eine virtualisierte Firewall zu installieren:
In der Fritzbox wird der DHCP abgeschaltet. Die IP für den Host / den Homeserver wird auf dessen nach Außen / zum Router zeigendem / rotem Interface händisch vergeben. In meinem Fall wäre das eth1 auf dem Host.
- Der Router hat die IP 192.168.2.1 und nutzt eine Netzmaske 255.255.255.0
- Das vom Host zum Router zeigende Interface erhält im folgenden Beispiel die IP 192.168.2.200
Auf dem nach Innen / zum Heimnetz zeigenden / grünen Interface des Hosts / Homeservers (in meinem Fall eth0) benötigt man eine Bridge, damit alle virtuellen Maschinen im internen Netz mit ihren eigenen MACs (und damit später auch ihren eigenen IP-Adressen) auftauchen können. Hier ist die IP der Bridge auf dem Host nicht mehr als die IP eines Switches – die IP Adresse des Gastes wird im Gast selbst festgelegt.
- Nach Innen erhält der Host die IP 10.16.1.100 (eingestellt auf dessen Bridge br0 und nicht auf eth0. Eth0 auf dem Host bleibt komplett unkonfiguriert)
- Das Heimnetz selbst ist ein 10.16er Netz mit Netzmaske 255.255.0.0 oder 10.16.0.0/16 (damit bekomme ich genug Freiraum für die nächsten Jahre und kann außerdem dafür sorgen, dass Geräte, die ich zwischen Schule und zu Hause hin und her trage immer die gleiche IP haben)
Sollte Ubuntu als Host-Betriebssystem zum Einsatz kommen, dann greift man zur Server-Ausgabe. Diese bringt keinen network-manager mit, der einem beim Setup dazwischen schießen würde. Setzt man eine Desktop-Version ein, dann muss der network-manager zuerst entfernt werden. Das Setup funktioniert nur, wenn man die Interfaces selbst konfigurieren kann.
Zusammengefasst: Auf dem Host steht in /etc/network/interfaces:
# Das Interface in Richtung Router
auto eth1
iface eth1 inet static
address 192.168.2.200
netmask 255.255.255.0
network 192.168.2.0
broadcast 192.168.2.255
gateway 192.168.2.1
dns-nameservers 213.73.91.35 192.168.2.1 85.214.20.141
# Das Interface in Richtung Heimnetz
auto br0
iface br0 inet static
address 10.16.1.100
netmask 255.255.0.0
bridge_ports eth0
bridge_fd 5
bridge_stp no
Eth0 auf dem Host bleibt – wie oben schon geschildert – unkonfiguriert. Der Host ist dann aus dem Heimnetz unter der IP der Bridge direkt zu erreichen und lässt sich so leicht warten.
Eth1 auf dem Host habe ich nicht nur mit dem Nameserver auf dem Router, sondern zusätzlich noch mit den DNS des CCC und Foebud versorgt. Man weiß ja nie.
Nun legt man sich die erste Virtuelle Maschine (hier unter VirtualBox, das unter einem normalen Benutzeraccount läuft) mit zwei Netzwerkkarten an.
Das „zum Router“ zeigende Interface der VM wird als NAT angelegt.
Damit ich die Netzwerkkarten später in der VM wieder finde, schreibe ich deren MAC Adressen immer so um, dass „rot“ eine 1 (für eth1 des Hosts) am Ende hat – und „grün“ eine 0 (für eth0 des Hosts).
Das „nach Innen“ ins Heimnetz zeigende Interface der VM wird an die Bridge br0 des Hosts angeschlossen.
Ist der erste Host (hier IPFire als Firewall) gestartet, richtet man dessen Interfaces ebenfalls händisch her. Das nach Außen zeigende, rote Interface erhält vom DHCP auf dem NAT der VirtualBox irgendeine 10er Adresse. Welche, ist relativ egal. Später eingerichtete Portweiterleitungen übernimmt VirtualBox. Wichtig sind die Angaben für das interne, grüne Interface (also das, das an der Bridge des Hosts hängt). Hier muss die /etc/network/interfaces des Gastes angepasst werden (im Falle von IPFire über dessen Weboberfläche).
# Das rote Interface zeigt in Richtung Router und haengt am VBox NAT
auto eth0
iface eth0 inet dhcp
# Das gruene Interface zeigt in Richtung Heimnetz und haengt an der Bridge des Hosts
auto eth1
iface eth1 inet static
address 10.16.1.1
netmask 255.255.0.0
Die erste VM ist aus dem Heimnetz dann unter 10.16.1.1 zu erreichen.
So lange auf dem IPFire noch kein DHCP Server auf grün läuft, muss man sich auf einem Client eine 10.16.er Adresse händisch selbst zuweisen, damit man an die Weboberfläche kommt.
Die Installation weiterer VMs hängt direkt vom Sicherheitsbedürfnis ab. Zwei Wege sind möglich: einer führt über virtuelle Netzwerkkarten an der Firewall-VM (blau und orange), der andere richtet VMs „neben“ der Firewall ein.
Wählt man die sicherere Variante (weitere Netzwerkkarten in der Firewall-VM), richtet man diese NICs in VirtualBox als „Internes Netzwerk“ ein. Die VMs hängen dann mit ihrem roten Interface direkt an der Firewall und ebenfalls im VM-internen-Netzwerk. Das wäre z.B. ein Weg, um ein orangenes Netz einzurichten (siehe Bild oben für die Netzwerkkarte eines Webservers im orangen Netz von IPFire).
Aside: Ein blaues Netz ist nicht so einfach zu haben, weil WLAN Karten auf dem Host nicht als solche in VMs hinein gereicht werden können. Man kann sich hier aber mit USB-WLAN-Sticks helfen, die an die VM gebunden und aus dieser heraus konfiguriert werden.
Wählt man die unsicherere Variante, richtet man weitere VMs „neben“ der Firewall ein. Das Setup entspricht hierbei jeweils der Einrichtung der ersten VM: Eth1 des Gastes mit VBox-NAT zeigt nach Außen. Die nach Innen zeigende Schnittstelle des Gastes (eth0) wird im Gast händisch mit einer IP versorgt und klebt an der Bridge br0 auf dem Host.
Fällt ein derartiger Gast in fremde Hände, steht dem Angreifer das komplette interne Netz offen. Die Firewall ist hier reduziert auf ihre Webfilter-/DHCP-Funktionen für das interne Netz. Schutz von Außen bietet sie so nur bedingt. Man sollte aber wegen einer derartigen Konstruktion nicht gleich in Panik ausbrechen. Ge-nat-ete VMs dürften von Außen schwer zu knacken sein. Bei Portweilterleitungen vom Router auf eine solche VM macht man jedoch ein Türchen für Angriffe auf und muss eine derartige VM (eine Brücke zwischen Internet und Heimnetz) dann noch einmal gesondert absichern (iptables, fail2ban, tripwire etc. pp.). Oder man spart sich das interne Interface gleich komplett.
Hier vermehren sich die VMs fast täglich: Die Firewall war zuerst da, dann kam ein Fileserver, dann ein Nameserver, ein Webserver, ein Gameserver … 10er Netze und viel RAM auf dem Host lassen viel Raum für Spinnereien 🙂