datenritter blog

Wieder mal ein Grund, sich ungebremst über die Linux-Welt zu freuen: Traffic Shaping mit Squid.

Wenn man seine Bandbreite fair verteilen will, dann hat man mit einem Proxy ein Problem. Der Proxy ist im Upstream Quelle aller Anfragen, die können also nicht nach User unterschieden werden, egal was man vorher in der mangle table angestellt hat. Ohnehin ist Shaping im Upstream von begrenzter Nützlichkeit.

Im Downstream kann man die Bandbreite zwar fair verteilen, muss sich dann aber nach der Geschwindigkeit des Netzwerkes hinter dem Proxy richten. Das ist meistens langsamer als das Netz, aus dem die Anfragen kommen. Zum Beispiel wenn der Proxy zwischen einer DSL-Leitung und einem schnelleren LAN sitzt. Der Vorteil des Proxys, dass er zwischengespeicherte Daten schneller ausliefert als die DSL-Leitung es könnte, wäre bei einem solchen Shaping dahin.

Squid 3 kann deshalb Pakete abhängig davon, ob die gelieferten Daten aus dem Cache kommen oder nicht, markieren. Anhand der Markierung sortiert man die dann in verschiedene Qdiscs oder Klassen — einmal Bandbreitenmanagement mit DSL-Geschwindigkeit, einmal mit LAN-geschwindigkeit. Problem gelöst.

Aus der Doku:

This setting is configured by setting the source TOS values:

local-hit=0xFF Value to mark local cache hits.

sibling-hit=0xFF Value to mark hits from sibling peers.

parent-hit=0xFF Value to mark hits from parent peers.

(...)
disable-preserve-miss
If set, any HTTP response towards clients will
have the TOS value of the response comming from the
remote server masked with the value of miss-mask.

miss-mask=0xFF
Allows you to mask certain bits in the TOS received from the
remote server, before copying the value to the TOS sent
towards clients.
Default: 0xFF (TOS from server is not changed).

Update 2010-04-28: Ok, ich hätte vielleicht erwähnen sollen, dass Squid3 dazu mit --enable-zph-qos kompiliert werden muss. Im Debian-Paket ist das nicht der Fall, es führt also kein Weg dran vorbei.

Wer hin und wieder mit SSH tunnelt, kennt längliche Eingaben wie ssh -p1234 -L60777:userkiste1:8080 root@mainserver.example.com.

Gut, das könnte man mit beliebigen weiteren Optionen auch in ein Script packen, aber eigentlich gehören die Parameter in eine Konfigurationsdatei. Dass man Port und zu verwendendes Keyfile problemlos in der ~/.ssh/config eintragen kann, ist bekannt, weniger jedoch die Verwendung eines Aliases und die Möglichkeit, den Tunnel fest einzustellen. Das geht so:

Host main-tunnel
Hostname mainserver.example.com
Port 1234
User root
LocalForward 1234 userkiste1:8080
IdentityFile ~/.ssh/id_mainserver


Danach genügt es, einfach ssh main-tunnel einzugeben. (Mit Tab-Completion fällt das ganze dann vielleicht sogar zu ssh m<tab> zusammen.)

Dieser Komfort ist es, denn ich an der Linux-Welt mag.

(Ja, SSH ist ein BSD-Projekt, ich weiß...)

Nur mit Linux: Mittels ClusterSSH, mit dem man sich auf mehreren Rechnern gleichzeitig einloggen kann, auf neun Maschinen parallel den Kernel aktualisieren, Grafiktreiber und Updates einspielen.



Der neue Kernel wurde natürlich nur einmal kompiliert, und zwar mit distcc. :)

Die Distribution Ubuntu dürfte mit ihrem Sinn für Benutzerfreundlichkeit wesentlich dazu beigetragen haben, dass sich der NetworkManager (Homepage), ursprünglich ein Projekt von Red Hat, durchgesetzt hat. Er konfiguriert Netzwerkschnittstellen automatisch und macht damit Linux-Notebooks eigentlich erst richtig benutzbar.

Die Idee, dass ein User die Netzwerkschnittstellen konfigurieren könnte, war der Linux-Welt lange Zeit fremd. Doch das Überall-Netz setzt sich durch und WLANs machen schnelle Wechsel erforderlich.

Zum Daemon gibt es grafische Helferlein, wie den KNetworkManager für KDE, mit denen auch Unbedarfte "mal eben schnell" den WLAN-Zugang einrichten können. Mittlerweile beherrscht er sogar VPNs.



Man versuche zum Vergleich, OpenVPN unter Windows für User ohne Administratorrechte aufzusetzen. Ein schlechter Scherz.

Dennoch ist es gut zu wissen, wie man dem NetworkManager bei Bedarf Einhalt gebietet, zum Beispiel wenn man sein VPN unabhängig eingerichtet hat. Denn der NetworkManager startet den DHCP-Client, wenn kein Server da ist, und ein auf der Konsole manuell konfiguriertes Interface setzt er schnell mal zurück.

Beispiele in der Dokumentation des Debian-Pakets erklären, welche Interfaces von NetworkManager kontrolliert werden, und welche nicht:

1.)
auto wlan0
iface wlan0 inet dhcp
-> This device is managed by NM.

1.a)
allow-hotplug eth0
iface eth0 inet dhcp
-> This device is managed by NM

2.)
auto wlan0
iface wlan0 inet dhcp
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
-> This devices is *not* managed by NM because it has additional options.

3.)
iface wlan0 inet dhcp
-> This device is *not* managed by NM because it is not set to "auto".

4.)
iface eth0 inet static
address 192.168.1.10
netmask 255.255.255.0
gateway 192.168.1.1
-> This device is *not* managed by NM because it is configured as "static" and
has additional options.

5.)
Device is not listed in /etc/network/interfaces.
-> Device is managed by NM.

Da ein beispielsweise von OpenVPN erzeugtes TAP- oder TUN-Device normalerweise nicht in /etc/network/interfaces eingetragen ist, greift die Regel aus Beispiel 5, und der NetworkManager nimmt dem TAP-Device schnell wieder die IP weg, nachdem OpenVPN sie und die zugehörigen Netzwerk-Routen gesetzt hat.

Eine gleichzeitige manuelle Konfiguration gelingt hingegen, weil sie erst nach dem Eingriff stattfindet, und daher eine gewisse Zeit bestehen bleibt. Das Logfile von OpenVPN behauptet, alles sei ok. Die Verwirrung ist perfekt, der Administrator beißt wutentbrannt in die Tastatur.

Wenn man weiß, wie es geht, ist es einfach: Ein Eintrag iface tap0 inet manual in /etc/network/interfaces behebt das Problem. (Der NetworkManager sollte neu gestartet werden.) Das TAP-Device bleibt wie in Beispiel 3 unangetastet, das VPN funktioniert.

Die Annahme, ein Angreifer käme immer von außen, ist bekanntlich falsch. Ebenso wenig taugt der innere Angreifer als Ausrede für Unternehmen mit schlechten Sicherheitsvorkehrungen.

Doch die Begriffe "innen" und "außen" verlieren im Zeitalter der Funknetze ihre Wirkung. Ein im Schrank oder unter dem Schreibtisch versteckter WLAN-Access-Point gewährt dem Angreifer "draußen" (vor der Tür) vielleicht Zugriff auf das interne Netz.

Sherri von philosecurity schreibt darüber, wie solche Access-Points funktechnisch verborgen sein können:

1. Sie funken auf Kanal 14:

If an attacker were to configure an AP to illegally transmit on Channel 14 and export data at 2.484 GHz, security teams monitoring US channels would probably never detect it.

Kanal 14 zu nutzen ist nur in Japan legal. Natürlich sollte ein Sniffer alle 14 Kanäle abhören, um den Feindsender im eigenen Lager aufzuspüren.

2. 802.11n ohne Abwärtskompatibilität:

[The] “Green Field” or “high-throughput only” mode [...] takes full advantage of the enhanced throughput but is not visible to 802.11a/b/g devices. Older devices will see GF-mode traffic only as noise.

Das ist eigentlich der selbe Trick wie 1. Es sollte kein Problem sein, einen Sniffer auch auf 802.11n lauschen zu lassen, doch bis die Spezifikation steht und verbreitet ist, sind 802.11n-Access-Points eine gute Wette für den Fiesling von heute.

3. Bluetooth mit hoher Reichweite statt WLAN:

Even if you’re using a spectrum analyzer like WiSpy, you may not notice it. Bluetooth uses Frequency Hopping Spread Spectrum, and hops 1600 times a second throughout the 2.402-2.480GHz band. Because it’s spread out across the spectrum, it can be hard to notice and easily mistaken for noise by the untrained eye. Most Wireless IDS systems and security teams simply don’t look for it (yet).

4. Wireless Knocking:

With wireless knocking, a rogue AP sits on the network in monitor mode, listening for probe requests. When the rogue AP receives a packet (or sequence of packets) with the preconfigured SSID, it awakens and switches to master mode.

Wireless Knocking ist eine Abwandlung des Portknockings. Und es gibt bereits ein Programm dafür: "WKnock" heißt es und ist für OpenWrt verfügbar. Es dient dazu, den eigenen Access-Point vor Angreifern zu verstecken, doch wie jedes "Hackertool" kann es mit guten und bösen Absichten benutzt werden. Wer Angreifer und wer Verteidiger ist, ist keine Frage der Software.

Sherri von philosecurity wirft einen scharfen Blick auf einen besonderen Kalmar, den Web-Cache (bzw. Proxy-Server) Squid.

Die Logfiles, die Squid anlegt, sind natürlich der Schrecken jedes Datenschützers, für forensische Zwecke hingegen interessant. Der Nutzen wird allerdings begrenzt vom Haltbarkeitsdatum der aufgerufenen Seiten: Sie könnten längst verändert worden sein oder dynamisch generiert werden. Oder sie sind nur mit Passwort zugänglich.

Daher kann man sich den Offline-Modus von Squid zu nutze machen. Er aktualisiert Seiten im Cache nicht, sondern liefert die alte Version. Noch besser ist es aber, die zwischengespeicherten Inhalte direkt aus dem Cache zu rekonstruieren. Wie zu erwarten, ist die recht einfach. Sherri schreibt:

Finally, each of those eight-character files contains- yes! - the pages actually cached by Squid. (...) When you surf to a web page, Squid will add some metadata to the top, which includes the full URI and its MD5sum. Squid then stores this, along with the full HTTP reply (headers and body) as a file in one of these subdirectories. If the page is requested later, it can look it up in swap.state and fetch it.

Und extrahiert dann als Beispiel ein "verdächtiges" Bild: edited.jpg.


Übrigens: Sicherheitsexperte Bruce Schneier schreibt Freitags immer etwas mehr oder weniger spannendes über zehnarmige Tintenfische (engl. Squids). Zuletzt habe ich dort gelernt, dass man Tentakeln nicht einfach füllen darf, da sie sich beim Braten zusammenziehen und die Füllung im Raum verspritzen.

Update 2009-04-25: Ich hatte Mr. Schneier gemailt, er hat den Artikel im Friday Squid Blogging erwähnt. Das dürfte für ordentlich Aufmerksamkeit sorgen.

Ich hatte sowohl mit dem network-manager als auch mit der manuellen Einstellung und dhclient3 und pump einige Probleme, in manchen WLANs eine IP-Adresse zu bekommen. Wireshark zeigte, dass die DHCP-Anfrage eine in diesem Netzwerk ungültige IP verlangte. Eigentlich sollte der DHCP-Server diese zurückweisen, mancher WLAN-Router bleibt stattdessen einfach still.

In /var/lib/dhcp3 lagen einige Lease-Dateien (z.B. dhclient.wlan0.leases). Diese habe ich gelöscht, und nun funktioniert es wieder.