Custom routes in OpenVPN client

Um vom Server gepushte Routen zu ignorieren und nur eigene im VPN-Client zu verwenden, genügen folgende Zeilen in der openvpn.conf des Clients:

route-nopull
route 192.168.23.0 255.255.255.0

Ich nutze dies hier mit Tunnelblick auf dem Mac um bei der OpenVPN Config der Astaro wahlweise nicht den gesamten Traffic durchs VPN zu schicken.

Optimale MTU feststellen

Statt endloser ping-Orgien mit unterschiedlichen Paketgrössen erledigt tracepath die Suche nach der optimalen MTU mit einem Kommando:

otto@thinkpad-otto:~$ tracepath 88.151.64.34
 1:  10.0.3.44                                             0.110ms pmtu 1500
 1:  10.0.0.254                                            0.739ms 
 1:  10.0.0.254                                            0.961ms 
 2:  10.0.0.254                                            0.709ms pmtu 1300
 2:  192.168.5.254                                         1.479ms 
 3:  79.173.156.177                                        2.790ms 
 4:  806.gi0-1.managed-lns01.inx.dsl.enta.net             21.856ms 
 5:  806.gi4-37.interxion.dsl.enta.net                    21.036ms 
 6:  te2-3.interxion.core.enta.net                        21.271ms asymm  9 
 7:  te5-1.gs1.core.enta.net                              21.556ms asymm  8 
 8:  te5-8.telehouse-east2.core.enta.net                  47.876ms asymm  7 
 9:  te5-7.telehouse-north0.core.enta.net                 26.689ms asymm  8 
10:  te5-4.amsterdam.core.enta.net                        27.880ms asymm  9 
11:  te-0-1-0.peer1.sara.ams.man-da.net                   28.509ms asymm 10 
12:  te-1-3-0-400.core1.fra1.ix.f.man-da.net              35.467ms 
13:  ge-1-2-9-0.core1.fra3.de.smartterra.net              35.483ms 
14:  xe-0-0-2-501.core1.dus2.de.smartterra.net            38.502ms 
15:  ge1-910.j-3.dus2.hk-net.de                           44.076ms asymm 16 
16:  ge1-99.j-1.dus1.hk-net.de                            42.926ms asymm 17 
17:  wan1.fw-1.dus1.hk-net.de                             39.980ms 
18:  ns2.hk-net.de                                        41.161ms reached
     Resume: pmtu 1300 hops 18 back 47 

Danke Hendrik!

Exchange MailboxFolderPermission

Gedankenstütze zum MailboxFolderPermission Cmdlet:

# Berechtigungen auflisten
Get-MailboxFolderPermission -identity otto@bergerdata.de:\Kalender
 
# Entfernen von Berechtigungseintrag für Gruppe "bergerdata.de"
Remove-MailboxFolderPermission -identity otto@bergerdata.de:\Kalender `
-User bergerdata.de
 
# Standardrechte auf nur Frei-Gebucht-Info setzen
Set-MailboxFolderPermission -identity otto@bergerdata.de:\Kalender `
-User Default -AccessRights AvailabilityOnly
 
# Rechte für den Benutzer "test@bergerdata.de" auf "Prüfer" setzen
Set-MailboxFolderPermission -identity otto@bergerdata.de:\Kalender `
-User test@bergerdata.de -AccessRights Reviewer

Weiter Details hier.

DNS DDOS: fail2ban mit Bind

In letzter Zeit werden einige DNS Server mittels Anfragen wie die folgenden geflutet.

query: ripe.net IN ANY +ED
query: isc.org IN ANY +ED

Mittels fail2ban („apt-get install fail2ban“) kann man diese Querys recht einfach auf die schwarze Liste setzen und mit iptables blocken. Dazu muss der Named erst mal alle Querys loggen:

# /etc/bind/named.conf.local

logging {
    channel query.log {
        file "/var/log/named/query.log" versions 0 size 1m;
        severity debug 3;
        print-time yes;
    };
    category queries { query.log; };
};

Das „versions 0 size 1m“ gibt an, das Named eine Datei von 1MB Größe immer wieder überschreiben soll. Das File hätte ohne diese Anweisung schnell einige GB erreicht…

Für fail2ban habe ich hier ein quick-and-dirty script angepasst, welches auf die beiden oben genannten Domains testet (Download: named-ddos.conf). Das Rezept ist auch gut anpassbar für eigene Zwecke. Das Script „named-ddos.conf“ gehört nach „/etc/fail2ban/filters.d/“.

In der /etc/fail2ban/jail.conf muss das Rezept jetzt noch aktiviert werden:

[named-ddos-tcp]
enabled  = true
port     = domain,953
protocol = tcp
filter   = named-ddos
logpath  = /var/log/named/query.log
maxretry = 8

[named-ddos-udp]
enabled  = true
port     = domain,953
protocol = udp
filter   = named-ddos
logpath  = /var/log/named/query.log
maxretry = 8

Nach einem restart von fail2ban sollte /var/log/fail2ban.log anzeigen, dass IPs gebannt werden:

2012-08-02 22:56:44,886 fail2ban.actions: WARNING [named-ddos-udp] Ban 63.166.xxx.xxx
2012-08-02 22:56:44,903 fail2ban.actions: WARNING [named-ddos-udp] Ban 216.9.xxx.xxx

Wenn alles funktioniert würde ich den loglevel in der /etc/fail2ban/fail2ban.conf auf „1“ setzen damit das logfile nicht überläuft.

Nutzung auf eigene Gefahr 😉 Man sollte sich dessen bewusst sein, dass u.U. auch „legale“ User ausgesperrt werden könnten und bei Bedarf die Schwellwerte anpassen.

Ubuntu: CDROM als APT Repository

Um mal schnell die Ubuntu CD im Laufwerk als APT-Repository hinzuzufügen, hilft folgendes Kommando:

sudo apt-cdrom add

Mir passiert es z.B. öfter, dass ich vergesse bei der Installation das Paket „vlan“ mit zu installieren und stehe dann ohne Netzwerk da…

Linux als Router (z.B. UMTS)

Zugegeben, ich arbeite nicht sooo oft mit iptables. Daher hier mein Spickzettel um mein Notebook temporär als UMTS Router zu nutzen:

sudo su 
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
echo "1" > /proc/sys/net/ipv4/ip_forward

Hintergrund: Am Wochenende hatte sich mein Linux-Router/Server verabschiedet und natürlich hatte ich kein aktuelles ISO Image zur Hand. Die Netzwerkinstallation war aber dann dank des Notebook-Routers kein Problem.

Firefox Verbindungsprobleme

Heute wollte ich mich mit dem Firefox (Ubuntu) zu docs.jquery.com Verbinden. Ohne Erfolg. Ein endloser Verbindungsversuch („warten auf…“). Seite down? Wahrscheinlich. Einige Zeit später nochmal probiert: Gleiches Ergebnis. Hmm. Windows gebootet. Internet-Explorer lädt die Seite problemlos. Firefox unter Windows nicht. Aha. Kurz überlegt und zunächst die MTU-Size im Verdacht (solche Phänomene kommen oft daher). Router überprüft: Alles OK. Also muss es wirklich irgendetwas am Firefox sein.

Die langwierige Fehlersuche erspare ich mir jetzt aufzuschreiben. Ergebnis: Es gab einen ungültigen Eintrag in den Einstellungen für die bevorzugten Sprachen von Webseiten (Einstellungen->Sprachen). In der prefs.js im Profilverzeichnis stand folgender Eintrag:

user_pref("intl.accept_languages", "chrome://global/locale/intl.properties");

Keine Ahnung wo das her kommt. Vermutlich von einer alten Firefox-Version oder einem Firefox von einem anderen Betriebssystem. Da ich Firefox Sync nutze schleppe ich immer alle Einstellungen von einem Rechner zum anderen mit.

Der richtige oder mittlerweile richtige Eintrag sieht so aus:

user_pref("intl.accept_languages", "de-de,en");

Damit lädt Firefox dann auch ohne Probleme die Seite docs.jquery.com.

Vermutlich ist eine weitere Ursache für mein Problem noch ein Bug in der Webanwendung oder im Webserver von docs.jquery.com. Die Serverapplikation bekommt einen ungültigen Languagestring über den HTTP-Header („accept-language“) übermittelt und stürzt ab – es kommen in der Folge keine Daten am Browser an. Wenn ich es recht überlege, ist es auch noch ein Bug im Firefox: Er lässt scheinbar ungeprüft ungültige Einträge im Accept-language Header zu.

Thinkpad UMTS Modul (Qualcomm Gobi 2000 3G)

Mein neues Thinkpad T410i hat ein eingebautes UMTS Modul. Ich bin mir sicher, dass es anfangs unter Ubuntu Maverik ohne Probleme lief. Warum auch immer: nach irgend einem Update wurde es nicht mehr erkannt. Bug ist u.A. hier beschrieben.

Workaround

Firmware Dateien aus dem Windows Treiber kopieren. Diese liegen bei meinem Thinkpad auf der Windows 7 Partition unter „\Program Files (x86)\QUALCOMM\Images\Lenovo\6“ und „\Program Files (x86)\QUALCOMM\Images\Lenovo\UMTS“ (insgesamt 3 Dateien). Diese Dateien gehören dann in /lib/firmware/gobi (erstellen falls nicht existiert).

Danach lässt sich die Karte nach Eingabe der folgenden Kommandos wieder verwenden:

sudo /lib/udev/gobi_loader -2000 /dev/ttyUSB0 /lib/firmware/gobi
sudo killall modem-manager

2 NICs mit Policy Based Routing (PBR)

Es gibt viele Gründe für 2 Netzwerkkarten im Server. Sollen diese in unterschiedliche Netze angebunden werden gibt es Probleme weil normalerweise nur ein Standardgateway existiert.

Der Traffic verlässt zwar korrekt den Server über die gesetzten Routen, jedoch die Pakete an fremde Ziele verlassen den Server immer über die default-route, also u.U. nicht über das richtige Interface.

Folgend kurz die Schritte zum Einrichten eines Policy-Based Routing unter Debian/Ubuntu…

Ausgangslage

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.10.7.56    0.0.0.0         255.255.255.248 U     0      0        0 eth0
10.10.6.32    0.0.0.0         255.255.255.224 U     0      0        0 eth1

Neue Einträge anlegen

echo "1 dmz-a" >> /etc/iproute2/rt_tables
echo "2 dmz-b" >> /etc/iproute2/rt_tables

eth0 Route anlegen

ip route add 10.10.7.56/29 dev eth0 src 10.10.7.58 table dmz-a
ip route add default via 10.10.7.57 dev eth0 table dmz-a
ip rule add from 10.10.7.58/32 table dmz-a
ip rule add to 10.10.7.58/32 table dmz-a

eth1 Route anlegen

ip route add 10.10.6.32/27 dev eth1 src 10.10.6.35 table dmz-b
ip route add default via 10.10.6.33 dev eth1 table dmz-b
ip rule add from 10.10.6.35/32 table dmz-b
ip rule add to 10.10.6.35/32 table dmz-b

Das Kommando „ip route show“ sollte jetzt die entsprechenden Einträge zeigen.
Theoretisch könnte man sich das PBR für eine der beiden NICs sparen wenn man dort einfach die klassische default-route setzt. Hier noch eine ausführliche Anleitung zum Thema.