seeseekey.net - Invictus Deus Ex Machina

Wenn man unter Linux eingehende und abgehende Pakete kontrollieren, umleiten oder blockieren möchte, so kann man für diese Aufgabe iptables nutzen. Das Problem an iptables ist das es relativ kompliziert in der Anwendung ist.

Damit man hier nicht im Regen steht, gibt es (neben vieler anderer Firewall-Lösungen für Linux) die uncomplicated firewall kurz ufw. Technisch gesehen handelt es sich bei ufw um ein Frontend für iptables. Seit der Version 8.04 (Hardy Hedon) ist ufw ein Bestandteil der Ubuntu-Distribution. Neben Ubuntu ist ufw unter anderem auch für Debian verfügbar. Installiert werden kann ufw mittels des Befehls:

apt-get install ufw

Standardmäßig ist ufw deaktiviert, so das die Installation im ersten Schritt keinerlei Auswirkungen hat. Den aktuellen Status sowie die definierten Regeln können dabei mittels:

ufw status

eingesehen werden. Das könnte dann z.B. so aussehen:

Status: Aktiv

Zu                   Aktion      Von
--                   ------      ---
8080/tcp             DENY        Anywhere                                
22/tcp               ALLOW       Anywhere                            
22/tcp (v6)          ALLOW       Anywhere (v6)

Ist der Status auf inaktiv gesetzt, so muss ufw erst mit dem Befehl:

ufw enable

aktiviert werden. Hierbei muss man beachten das eine unbedachte Aktivierung von ufw dazu führen kann das man sich aus dem Rechner aussperrt. Dies liegt daran das am Anfang keinerlei Regeln definiert sind – so werden Pakete an Port 22 ignoriert; dies führt dazu das keine Verbindung per SSH möglich ist. Um dem vorzubeugen sollte eine Regel für SSH definiert werden, bevor ufw aktiviert wird:

ufw allow 22/tcp

Bei dieser Schreibweise handelt es sich um die vereinfachte Form zum Anlegen einer Regel. Neben allow, sind dabei auch die Werte deny und reject möglich. Während bei allow die Pakete passieren können, werden sie bei deny blockiert – im Gegensatz dazu wird bei reject der Absender darüber informiert das die Pakete abgelehnt wurden. Möchte man komplexere Regeln definieren nutzt man ufw nach folgendem Schema:

ufw allow proto tcp from any to 127.0.0.1 port 1234

Damit werden alle Verbindungen per TCP von beliebigen IP-Adressen an die spezifizierte IP-Adresse weitergeleitet. Als Port wird als Eingangs- und Zielport Port 1234 genutzt. Die Regeln welche ufw verwaltet werden in drei Dateien gespeichert:

/etc/ufw/before.rules
/var/lib/ufw/user.rules
/etc/ufw/after.rules

Abgearbeitet werden die Regeln in der Reihenfolge wie oben angegeben – somit könnte eine Regel in der user.rules-Datei definiert sein, welche anschließend von einer anderen Regel in der after.rules-Datei überschrieben wird. Die selbst definierten Regeln sind dabei in der user.rules zu finden. Neben dem Anlegen ist es natürlich auch möglich Regeln wieder zu löschen. Für obige SSH-Regel würde das dabei so aussehen:

ufw delete allow 22/tcp

Daneben ist es möglich ufw auf die Standardeinstellungen zu setzen. Dazu dient der Befehl:

ufw reset

Alle Regeln werden dabei auf die Standardeinstellungen zurückgesetzt. Für die bestehenden Regeln wird ein Backup im Verzeichnis /etc/ufw/ angelegt. Möchte man ufw wieder deaktivieren, so nutzt man den Befehl:

ufw disable

Beim beschriebenen reset-Befehl wird ufw ebenfalls deaktiviert. Damit sind die grundlegenden Konfigurationsschritte erklärt – für die weitergehende Konfiguration empfiehlt sich der entsprechende Artikel bei ubuntuusers.

Viele Netzwerke, wie z.B. öffentliche WLAN-Zugänge lassen Verbindung ohne Authentifikation zu. Nachdem man sich mit dem Netzwerk verbunden hat, muss man sich meist auf einem sogenannten Captive Portal anmelden. Dabei handelt es sich um eine Vorschaltseite, welche einem beim Aufruf einer Webseite angezeigt wird und der Anmeldung bzw. Identifizierung dient. Bei vielen dieser Netzwerken funktioniert die Kommunikation über das DNS-Protokoll ohne weitere Probleme (trotz Captive Portal) und Authentifikation, so das man diese nutzen kann um einen Tunnel ins freie Internet zu errichten.

code.kryo.se/iodine/

code.kryo.se/iodine/

Eine Lösung um einen solchen DNS Tunnel einzurichten ist iodine. Mit iodine ist es möglich IPv4-Verkehr über DNS zu tunneln. Pro DNS-Request können dabei bis zu einem Kilobyte an Daten übertragen werden, was sich positiv auf die Performance und den Durchsatz auswirkt. iodine läuft dabei auf vielen unixodien Systemen, sowie unter Windows. Lizenziert ist iodine unter der ISCL und damit freie Software. Der Quelltext ist auf GitHub zu finden.

Wenn man ein CentOS 7 in der Minimal-Installation installiert (und dabei nicht aufpasst), wird man nach der Installation feststellen das man über keine Konnektivität verfügt. Das ist bedingt dadurch das die entsprechende Netzwerkschnittstelle beim Booten nicht konfiguriert wird. Um die Schnittstelle zu konfigurieren, sollte im ersten Schritt in den entsprechenden Ordner gewechselt werden:

cd /etc/sysconfig/network-scripts/

In diesem Ordner befindet sich eine Datei ifcfg-eth0 (alternativ sind auch andere Schnittstellennamen wie ifcfg-enp0s3, em1 und ähnliche möglich). Die entsprechende Datei wird nun mittels vi geöffnet:

vi ifcfg-eth0

In dieser Datei gibt es eine Option mit dem Namen ONBOOT, deren Wert standardmäßig auf no gestellt ist. Dieser Wert muss in yes geändert werden und anschließend die Datei gespeichert werden (:w zum Speichern der Datei, :q um VIM zu schließen). Nach einem anschließenden Neustart, sollte die Netzwerkschnittstelle konfiguriert und funktionsfähig sein.

Beim TL-WR702N handelt es sich um einen mobilen Access Point von TP-Link für WLAN mit einer Reihe von Zusatzbetriebsmodi. Unter anderem verfügt der Access Point über einen Betriebsmodi namens Client, mit welchem kabelgebundene Geräte in ein WLAN eingebunden werden können. Leider lässt sich dieser Modus nur umständlich aktivieren.

Nach dem Reset des Gerätes kann sich per WLAN mit diesem verbunden werden. Die Einstellung über das Quick Setup funktioniert nicht, da der Client Mode dort zwar eingestellt werden kann, aber anschließend nicht übernommen wird. Stattdessen muss der Modus über das Menü Working Mode eingestellt werden und der AP neugestartet werden.

Der TL-WR702N montiert an einer Wand

Der TL-WR702N montiert an einer Wand

Danach ist der TL-WR702N nur noch per Kabel unter der IP-Adresse 192.168.0.254 erreichbar. Die Netzverbindung am Rechner sollte zum Aufbau einer Verbindung auf 192.168.0.1 mit dem Subnetz 255.255.255.0 gestellt werden. Nachdem man sich wieder mit dem Gerät verbinden konnte, kann auf dem Gerät eine statische IP-Adresse im Punkt Network -> LAN eingestellt werden. Nach einem erneuten Neustart ist das Gerät unter der eingestellten IP-Adresse erreichbar. Im letzten Schritt muss in den DHCP Settings der eingebaute DHCP-Server deaktiviert werden. Damit ist der Client Mode nach einem erneuten Neustart nutzbar.

Für einen Server hatte ich vor einigen Tagen unter Ubuntu 14.04 LTS eine Netzwerkbrücke eingerichtet. Die /etc/network/interfaces Datei sah danach in etwa so aus:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto br0
iface br0 inet dhcp
bridge_ports eth0

Nach einem Neustart gab es dann allerdings ein Problem. Der Server war nicht mehr erreichbar. Der Grund dafür war simpel – es fehlte das Paket bridge-utils – nach der Installation desselben mittels:

apt-get install bridge-utils

funktionierte die Netzwerkbrücke wieder ohne Probleme.

Wenn man sich mit einem Mac OS X Gerät zu einem Netzwerkgerät bzw. einer Freigabe auf einem solchem verbindet, kann es passieren das man anschließend eine Menge “.AppleDouble” Ordner auf dem Gerät vorfindet. Möchte man verhindern, das solche Ordner auf Netzwerkfreigaben angelegt werden, sollte man im Terminal:

defaults write com.apple.desktopservices DSDontWriteNetworkStores true

ausführen. Nach einem Neustart werden dann keine solchen Ordner mehr angelegt. Anschließend müssen nur noch die bereits angelegten Ordner auf der Freigabe entfernt werden.

Wenn man größere Netzbereiche mittels Nmap scannen möchte, so kann man sich eine Menge Zeit nehmen. Je nach ausgewähltem Netzbereich, kann das durchaus mal einige Stunden bis Tage dauern. Abhilfe schafft hier der Scanner ZMap mit welchem man den gesamten IPv4 Bereich auf einen Port hin innerhalb von 45 Minuten scannen kann. Allerdings sollte man hierbei mit einer 1 Gigabit/s Leitung ans Werk gehen.

zmap.io

zmap.io

ZMap wurde dabei von einem Team der University of Michigan entwickelt. Auf der entsprechenden Webseite finden sich die wissenschaftlichen Papers sowie der Quellcode der Software. Auch auf GitHub ist das Projekt vertreten. Lizenztechnisch steht das ganze unter der “Apache License 2.0” und ist damit freie Software.

Wer einen Drucker ohne Netzwerkanschluss besitzt, kann ihn mit Hilfe eines Raspberry Pi zu einem Netzwerkdrücker umrüsten. Dazu werden im ersten Schritt die notwendigen Pakete installiert:

sudo apt-get install avahi-daemon cups cups-pdf

Nach der Installation geht es an die Konfiguration. Dazu wird die “cupsd.conf” bearbeitet:

sudo nano /etc/cups/cupsd.conf

Den Sektionen “<Location />”, “<Location /admin>” und “<Location /admin/conf>” wird dabei die Zeile:

Allow @Local

hinzugefügt. Daneben sollte noch die Zeile:

Listen <IP Adresse>:631

hinzugefügt werden. Das sorgt dafür das auf dem passenden Interface gehorcht wird. Danach geben wir in der Konsole folgendes ein:

sudo adduser pi lpadmin
sudo service cups restart

Damit wird der Nutzer “pi” der Gruppe der Nutzer hinzugefügt welche Einstellungen vornehmen dürfen. Außerdem wird der CUPS Service neugestartet, so das die Änderungen in der Konfigurationsdatei wirksam werden. Nun kann sich über die URL:

https://<IP Adresse>:631

mit dem Webinterface von CUPS verbunden werden.

Das CUPS Webinterface

Das CUPS Webinterface

Im Webinterface wird nun unter dem Tab “Verwaltung” der Punkt “Freigeben von Druckern welche mit diesem System verbunden sind” aktiviert. Bestätigt wird das ganze mit den Zugangsdaten des Nutzers “pi”. Abschließend klickt man auf den Button “Verfügbare Drucker auflisten” und fügt die angeschlossenen Drucker hinzu und gibt ihn frei. Dazu muss das passende Modell ausgesucht und bestätigt werden.

Anschließend kann man den Drucker in seinem Betriebssystem hinzufügen und über den Raspberry Pi drucken. Sollte wieder erwarten kein Druck stattfinden, so liegt das meist am falsch gewählten Druckertyp. Mit der beschriebenen Konfiguration lässt sich auch von iOS Geräten mittels AirPrint druchen.

Virtualisierung an sich ist eine feine Sache, man nehme einen Rechner und simuliere auf diesem mehrere Rechner. Dank KVM ist die ganze Sache auch ziemlich einfach. Dazu installiert man auf einem Rechner ein Ubuntu Server 12.10 (mit dem OpenSSH Paket, und einem Nutzer (in diesem Fall “seeseekey”)). Dabei sollte man darauf achten, das der Nutzer kein verschlüsseltes “home”-Verzeichnis hat, sonst könnte es später Probleme mit der Verwendung von SSH Schlüsseln geben. Anschließend überprüft man auf der Konsole mittels:

cat /proc/cpuinfo

ob die CPU über die entsprechende Virtualisierungsfunktionen verfügt. Die erkennt man in der Sektion “flags” der Ausgabe. Dort muss für Intel CPUs das Flag “vmx” und für AMD CPUs das Flag “svn” vorhanden sein. Ist dies der Fall so kann KVM mittels:

sudo apt-get install qemu-kvm libvirt-bin virtinst

installiert werden. Ein anschließendes:

kvm-ok

überprüft dann nochmal ob die CPU wirklich für KVM geeignet ist. Dabei ist zu beachten das es “kvm-ok” nur unter Ubuntu gibt, andere Distribution enthalten es aller Wahrscheinlichkeit nach nicht. Nun muss der Nutzer noch der Gruppe “libvirtd” hinzugefügt werden. Auf der Konsole ist dazu ein:

sudo adduser seeseekey libvirtd

nötig. Danach sollte der KVM Host neugestartet werden, bzw. sich an- und abgemeldet werden. Zur Verwaltung der Maschinen wird der “Virtual Machine Manager” benutzt. Dieser wird auf der entsprechenden Zielmaschine (welche nicht identisch mit dem KVM Host sein muss) mittels:

sudo apt-get install virt-manager

installiert. Auf der entsprechenden Maschine, welche die Verwaltung übernimmt sollte ein SSH Schlüssel erzeugt werden. Dies geschieht auf der Konsole:

ssh-keygen -t rsa -C "user@example.org"

Nun übertragen wir den Schlüssel auf den KVM Host, damit wir uns mit diesem verbinden können, was dann so aussehen könnte:

ssh-copy-id -i ~/.ssh/id_rsa.pub seeseekey@kvmhost

Danach sollte der “Virtual Machine Manager” gestartet werden. Über “Datei” -> “Verbindung hinzufügen” wird im darauf folgenden Dialog der KVM Host hinzugefügt.

Eine Verbindung wird hinzugefügt

Nun wird noch eine Netzwerkbrücke eingerichtet. Diese dient dazu, das man die virtuellen Maschinen auch von außen ansprechen kann. Ohne diese Brücke befinden sich die Maschinen hinter einem NAT und können nur mit dem KVM Host kommunizieren.

Um die Bridge zu erstellen wird die Datei “/etc/network/interfaces” geändert. Auf einem normalen System sollte diese wie folgt aussehen:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet dhcp

Nun wird “auto eth0” in “auto br0” und “iface eth0 inet dhcp” in “iface br0 inet dhcp” geändert. Anschließend fehlt nur noch die Zeile:

bridge_ports eth0

welche am Ende hinzugefügt wird. Damit sieht die neue “/etc/network/interfaces” dann wie folgt aus:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto br0
iface br0 inet dhcp
bridge_ports eth0

Danach geben wir im Terminal:

/etc/init.d/networking restart

mit root-Rechten ein und schon ist die entsprechende Konfiguration wirksam.

Die Storage Pools des KVM Host

Nachdem dies geschehen ist kann man eine neue virtuelle Maschine anlegen. Wenn man ein Windowssystem installiert, sollte man darauf achten, das man die entsprechenden Treiber anschließend installiert. Diese findet man unter http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/.

Bei den Storage Pools, in welchem die Daten für die virtuellen Maschinen liegen, empfiehlt es sich den “default” Pool außen vor zu lassen. Stattdessen legt man sich einen Pool “images” und einen Pool “machines” an. Im “images” Pool lagert man dann alle Betriebsystemimages für die Installation neuer Maschinen. Im “machines” Pool hingegen, sollten sich die installierten Maschinen befinden.

Das Quellgerät muss auf die Netzwerkbrücke eingestellt werden

In jeder virtuellen Maschine muss dabei das Quellgerät in der Netzwerkkonfiguration auf die Netzwerkbrücke (br0) eingestellt werden. Damit ist die Maschine ein Teil des Netzwerkes in welchem sich auch der KVM Host befindet. Bei den virtuellen Maschinen, empfiehlt es sich bei grafischen Systemen in der entsprechenden Konfiguration unter “Video” das Modell “vmvga” auszuwählen.

Weitere Informationen gibt es unter:
http://wiki.ubuntuusers.de/SSH
http://wiki.ubuntuusers.de/KVM
http://wiki.ubuntuusers.de/virt-manager
http://wiki.ubuntuusers.de/Virtualisierung
http://de.wikipedia.org/wiki/Kernel-based_Virtual_Machine

Unter Linux (und UNIX) kann man die Ports bis 1024 (die sogenannten Well Known Ports) nur dann binden, wenn man über root Rechte verfügt. Das ist natürlich unschön wenn man einen Server z.B. auf Port 80 laufen lassen will, dieser aber keine dementsprechenden Rechte bekommen darf.

So läuft bei mir zum Beispiel ein Etherpad Light auf dem Port 9001. Jetzt wäre es natürlich schön wenn dieser auf dem Port 80 erreichbar wäre. Dazu würde eine iptables Regel reichen:

iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 9001

Das Problem an dieser Regel ist zum ersten das die Anwendung damit unter Port 80 und Port 9001 zu erreichen ist. Das zweite Problem ist das jeder unprivilegierte Nutzer ebenfalls den Port 9001 öffnen kann und damit auch die Daten von Port 80 bekommt. Und es gibt auch noch ein drittes Problem. Das ganze funktioniert nicht auf Maschinen die mit dem Linux VServer betrieben werden. Dort funktioniert das IP Tables nämlich nicht:

iptables v1.4.4: can't initialize iptables table `nat': Permission denied (you must be root)

Eine weitere Variante wäre setpcaps was allerdings problematisch ist da man diese einem Programm geben muss, was dann bei Skripten nicht funktionieren sollte:

setcap 'cap_net_bind_service=+ep' /path/to/program

Weitere Informationen gibt es unter:
http://www.wensley.org.uk/info#setpcaps
http://serverfault.com/questions/112795/how-can-i-run-a-server-on-linux-on-port-80-as-a-normal-user
http://stackoverflow.com/questions/413807/is-there-a-way-for-non-root-processes-to-bind-to-privileged-ports-1024-on-li