Dinge, die die Welt nicht braucht

Überwachung von DNS Abfragen

uwe (Uwe Weissenbacher) — Sat, 07 Apr 2012 17:52:37 +0200

Um einem kleinen DNS Problem auf die Schliche zu kommen habe ich mit dem dem Framework Scapy ein kleines DNS Überwachungsscript zusammengehackt. Ist mehr oder weniger eine prä Alpha aber vielleicht kann es jemand gebrauchen :)

(das Syntax Highlighting Plugin für des Blog ist neu. Sollte es den Code irgendwie unbrauchbar machen, bitte kurze Meldung. Danke)

#!/usr/bin/python
from scapy.all import *
from time import time
from scapy.layers.dns import dnstypes



# REQ = request, ANS = answer, NX = not found

dnsdict= {}

def dnsin(x):
        dnsdata=x.getlayer("DNS")
        try:
                dnsdata.an
        except AttributeError:
                return "ERROR no query data found in packet. Skipping..."
        if (dnsdata.an == None):
                if (dnsdata.ns == None):
                        print "REQ\t%i -> %s" % (dnsdata.id,dnsdata.qd.qname )
                        if (dnsdict.has_key(dnsdata.id)):
                                print "ERROR id %i is an orphan. Overwrting..." % dnsdata.id
                        dnsdict[dnsdata.id] = time()
                else:
                        print "NX \t%i -> %s" % (dnsdata.id,dnsdata.qd.qname )
                        if (dnsdict.has_key(dnsdata.id)):
                                print "### NX  %f seconds -> %s (%i/%s)" % (time()-dnsdict.pop(dnsdata.id), dnsdata.qd.qname,dnsdata.id, dnstypes[dnsdata.qd.qtype])
                        else:
                                print "ERROR request for id %i (%s) not found. Skipping..." % (dnsdata.id,dnsdata.qd.qname)
        else:
                print "ANS\t%i -> %s" % (dnsdata.id,dnsdata.qd.qname )
                if (dnsdict.has_key(dnsdata.id)):
                        print "### ANS %f seconds -> %s (%i/%s)" % (time()-dnsdict.pop(dnsdata.id), dnsdata.qd.qname,dnsdata.id, dnstypes[dnsdata.qd.qtype])
                else:   
                        print "ERROR request for id %i (%s) not found. Skipping..." % (dnsdata.id,dnsdata.qd)


sniff(filter="port 53",prn=lambda x: dnsin(x),count=0)

NMAP und IPv6 scanning

uwe (Uwe Weissenbacher) — Fri, 06 Apr 2012 23:09:34 +0200

Frisch aufgesetzte Firewalls/Paketfilter sollte man immer auch auf Wirksamkeit testen. Das Tool nmap ist oft das Mittel der Wahl um einen Portscan durchzuführen. Ein erster Lauf auf ein neu aufgesetztes Linux endete aber unerwartet:

maninthemiddle ~ # nmap -6 2001:db8::5

Starting Nmap 5.51 ( http://nmap.org ) at 2012-04-06 23:15 CEST
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 3.06 seconds

Da ICMP6 bei IPv6 eine wichtige Rolle spielt sollte es auch nicht gefiltert werden. Folgende ip6tables Regel war eingetragen und sollte dies bewerkstelligen:

ip6tables -A INPUT  -p icmpv6 -j ACCEPT

Ein kurzer Test bestätigte auch, dass die Regel greift:

maninthemiddle ~ # ping6 -c1 2001:db8::5
PING 2001:db8::5(2001:db8::5) 56 data bytes
64 bytes from 2001:db8::5: icmp_seq=1 ttl=58 time=17.1 ms

--- 2001:db8::5 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 17.118/17.118/17.118/0.000 ms

Warum also glaubt nmap, dass der Host down ist. Ein tcpdump enthüllt die Vorgehensweise von nmap

# tcpdump -ni eth0 ip6
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
23:07:23.572046 IP6 2001:db8::7.44131 > 2001:db8::5.80: Flags [S], seq 3558174015, win 5760, options [mss 1440,sackOK,TS val 2940686631 ecr 0,nop,wscale 6], length 0
23:07:23.572305 IP6 2001:db8::7.45053 > 2001:db8::5.443: Flags [S], seq 3564825844, win 5760, options [mss 1440,sackOK,TS val 2940686631 ecr 0,nop,wscale 6], length 0
23:07:25.572913 IP6 2001:db8::7.44134 > 2001:db8::5.80: Flags [S], seq 1277830368, win 5760, options [mss 1440,sackOK,TS val 2940686831 ecr 0,nop,wscale 6], length 0
23:07:25.573181 IP6 2001:db8::7.45054 > 2001:db8::5.443: Flags [S], seq 1263904517, win 5760, options [mss 1440,sackOK,TS val 2940686831 ecr 0,nop,wscale 6], length 0

Bei IPv6 prüft nmap also nur TCP Port 80 und TCP Port 443 auf Erreichbarkeit (also implizit den Parameter -PS80,443). Nicht so bei IPv4 - hier benutzt nmap auch ICMP:

# tcpdump -ni eth0 host 192.0.2.1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
23:40:34.656542 IP 192.0.2.5 > 192.0.2.1: ICMP echo request, id 61369, seq 0, length 8
23:40:34.656697 IP 192.0.2.5.48001 > 192.0.2.1.443: S 740198195:740198195(0) win 2048 
23:40:34.656760 IP 192.0.2.5.48001 > 192.0.2.1.80: . ack 740198195 win 3072
23:40:34.656806 IP 192.0.2.5 > 192.0.2.1: ICMP time stamp query id 51300 seq 0, length 20
23:40:36.658644 IP 192.0.2.5 > 192.0.2.1: ICMP time stamp query id 47887 seq 0, length 20
23:40:36.658684 IP 192.0.2.5.48002 > 192.0.2.1.80: . ack 740263730 win 1024
23:40:36.658706 IP 192.0.2.5.48002 > 192.0.2.1.443: S 740263730:740263730(0) win 1024 
23:40:36.658726 IP 192.0.2.5 > 192.0.2.1: ICMP echo request, id 37760, seq 0, length 8

Bei IPv4 ist der implizite Standard also -PS80,443 -PE -PP. Allerdings handelt es sich hierbei nicht um unterschiedliche Defaults sondern schlicht und einfach wieder um eine fehlende Implementation. Ein erzwungener alive check per ICMP mit dem Parameter -PE führt zur Fehlermeldung.

# nmap -6 2001:db8::5 -PE
ICMP Echo, Timestamp and Address Mask pings are only valid for IPv4.
QUITTING!

Man sollte sich also -Pn merken um den Alive Check zu umgehen. Wieder eine unerwartete Klippe die es bei IPv6 zu umschiffen gilt.

IPv6 auf Cisco WS-C3560

uwe (Uwe Weissenbacher) — Wed, 15 Feb 2012 16:08:46 +0100

Ciscos Switch WS-C3560 kann, sofern man die entsprechende Lizenz hat und dann das richtige Image verwendet, tatsächlich IPv6 Routing in Hardware

The IP Services license provides a richer set of enterprise-class features, including advanced hardware-based IPv6 unicast and IPv6 Multicast routing as well as policy-based routing (PBR).

Mein erster Versuch das die Geschichte mit ipv6 unicast-routing zu aktivieren verlief trotz richtigem Image allerdings überraschend:

Switch(config)#ipv6 ?
% Unrecognized command

Damit IPv6 auf dieser Plattform wirklich funktioniert muss neben dem Image auch das SDM Profil stimmen. Auf meinem Switch war dies noch auf IPv4 eingestellt:

Switch#show sdm prefer
The current template is "desktop default" template.
The selected template optimizes the resources in
the switch to support this level of features for
8 routed interfaces and 1024 VLANs.

number of unicast mac addresses: 6K
number of IPv4 IGMP groups + multicast routes: 1K
number of IPv4 unicast routes: 8K
number of directly-connected IPv4 hosts: 6K
number of indirect IPv4 routes: 2K
number of IPv4 policy based routing aces: 0
number of IPv4/MAC qos aces: 0.5K
number of IPv4/MAC security aces: 1K

Switch#conf t
Enter configuration commands, one per line. End with CNTL/Z.

Switch(config)#sdm prefer dual-ipv4-and-ipv6 routing
Changes to the running SDM preferences have been stored, but cannot take effect
until the next reload.
Use 'show sdm prefer' to see what SDM preference is currently active.

Nach dem reboot taucht auch IPv6 auf

Switch#show sdm prefer
The current template is "desktop IPv4 and IPv6 routing" template.
The selected template optimizes the resources in
the switch to support this level of features for
8 routed interfaces and 1024 VLANs.

number of unicast mac addresses: 1.5K
number of IPv4 IGMP groups + multicast routes: 1K
number of IPv4 unicast routes: 2.75K
number of directly-connected IPv4 hosts: 1.5K
number of indirect IPv4 routes: 1.25K
number of IPv6 multicast groups: 1.125k
number of directly-connected IPv6 addresses: 1.5K
number of indirect IPv6 unicast routes: 1.25K
number of IPv4 policy based routing aces: 0.25K
number of IPv4/MAC qos aces: 0.5K
number of IPv4/MAC security aces: 0.5K
number of IPv6 policy based routing aces: 0.25K
number of IPv6 qos aces: 0.625k
number of IPv6 security aces: 0.5K

Und kann konfiguriert werden:

Switch(config)#ipv6 unicast-routing
Switch(config)#

Länge von Dateinamen ermitteln

uwe (Uwe Weissenbacher) — Thu, 19 Jan 2012 12:29:06 +0100

Da ich gerade die Länge von Dateinamen herausfinden musste und mir nicht eingefallen ist wie man das elegant und schnell lösen könnte hab ich mir in der Shell eben was zusammengehackt. Vielleicht weiß jemand eine bessere Lösung:

for i in `ls -1`; do echo -n "$i:" ;echo $i |wc -m ; done | awk -F':' '{print $2 ":" $1}' | sort -n

SSH über IPv6

uwe (Uwe Weissenbacher) — Sun, 14 Aug 2011 16:05:16 +0200

Eine Änderung von IPv6 gegenüber IP4 besteht darin, dass per Voreinstellung jeder Teilnehmer eines Netzes immer eine sogenannte Link-Local Adresse besitzt. Dieser SLAAC (Stateless Address Autoconfiguration) genannte Automatismus ersetzt und erweitert das von IPv4 bekannte Zeroconf. Während Zeroconf immer durch zusätzliche Software implementiert wird, ist SLAAC Bestandteil des IPv6 Stacks. Das heißt: ist auf einem Host IPv6 aktiviert, so hat dieser auch immer ein IP Adresse auf die zugegriffen werden kann.

Eine Besonderheit ist dabei, dass der Link-Local Adressraum aus dem die IPs vergeben werden (fe80::/10) auf jedem Interface anliegt und man daher immer das Interface angeben muss auf dem man eine solche IP erreichen will. Dem Kommando ping6 wird das Interface mit -I übergeben:


krusty ~ # ping6 -c1 fe80::20a:e4ff:fe3a:cda9
connect: Invalid argument
krusty ~ # ping6 -I eth0 -c1 fe80::20a:e4ff:fe3a:cda9
PING fe80::20a:e4ff:fe3a:cda9(fe80::20a:e4ff:fe3a:cda9) from fe80::20a:e4ff:fe3a:1dc9 eth0: 56 data bytes
64 bytes from fe80::20a:e4ff:fe3a:cda9: icmp_seq=1 ttl=64 time=0.042 ms

--- fe80::20a:e4ff:fe3a:cda9 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.042/0.042/0.042/0.000 ms

Der ssh client bietet nun leider keinen solchen (offensichtlichen) Parameter. Hier wird das Interface direkt an die Adresse, getrennt von einem Prozentzeichen angehängt:


uwe@krusty ~ $ ssh fe80::20a:e4ff:fe3a:cda9%eth0
Last login: Sun Aug 14 16:04:38 CEST 2011 from fe80::20a:e4ff:fe3a:cda9%eth0 on pts/5
uwe@krusty ~ $

Logitech Webcam C250 eingerichtet

uwe (Uwe Weissenbacher) — Mon, 22 Nov 2010 23:04:13 +0100

Nur ein kurzer Eintrag als Gedächtnisstütze wie die Logitech Webcam C250 unter Gentoo zum funktionieren zu bewegen ist. Folgende Kernel-Einstellungen (2.6.34 in diesem Fall, bei anderen Kerneln kann der Pfad unter Umständen ein wenig anders sein) sind vonnöten:

Device Drivers  --->
  Multimedia support  --->
    Video capture adapters --->
      V4L USB devices  --->
        USB Video Class (UVC)
Sound card support  --->
  Advanced Linux Sound Architecture  --->
    USB sound devices  --->
      USB Audio/MIDI driver

Diese Optionen als Modul konfiguriert und mit make ; make modules_install gebaut und udev sollte nach dem Anschluss der Webcam alles automagisch laden. Mit media-video/guvcview sollte dann bereits alles funktionieren. Die C250 bringt zwar ein Mikrofon mit, allerdings hat die schon vorhandene Soundkarte üblicherweise eine niedrigere Device Nummer in ALSA (und damit eine höhere Priorität) und ist damit das Standardgerät. Somit müsste in jedem Programm in dem man das Mikrofon der C250 benutzen will extra konfigurieren. Es ist jedoch auch möglich in ALSA verschiedene Standardgeräte für Wiedergabe und Aufnahme zu definieren. Dies kann entweder Global in der /etc/asound.conf oder für den entsprechenden Benutzer in der ~/.asoundrc geschehen. Zunächst muss man herausfinden welches Gerät welche Nummer hat:

$ cat /proc/asound/cards
 0 [Intel          ]: HDA-Intel - HDA Intel
                      HDA Intel at 0xf3ff8000 irq 22
 1 [NVidia         ]: HDA-Intel - HDA NVidia
                      HDA NVidia at 0xf7cfc000 irq 17
 2 [U0x46d0x804    ]: USB-Audio - USB Device 0x46d:0x804
                      USB Device 0x46d:0x804 at usb-0000:00:1d.0-1.5.1, high speed

Mein Onboard Sound hat demnach Nummer 0 und die Webcam Nummer 2. Mit diesen Infos kann die ALSA Konfigurationsdatei schon korrekt angepasst werden:

pcm.!default {
         type asym
         playback.pcm {
                 type plug
                 slave.pcm "hw:0,0"
         }  
         capture.pcm {
                 type plug
                 slave.pcm "hw:2,0"
         }  
 }

Sollten die entsprechenden Geräte andere Nummern haben muss die Zahl hinter hw: natürlich angepasst werden. Es geht garantiert einfacher, eleganter und schöner mit ALSA, allerdings bin ich mit der Konfiguration nie wirklich grün geworden und das da oben "works for me" :)

Ausgelockt

uwe (Uwe Weissenbacher) — Wed, 21 Apr 2010 10:32:32 +0200

Ich kenne bisher niemanden der auf die Frage "Hast du Capslock/die Feststelltaste schonmal gebraucht?" mit ja geantwortet hätte. Bei der Anschlussfrage, ob Capslock schon einmal genervt hat antworteten bisher auch alle überinstimmend mit "Ja".

Grund genug dieses Ungetüm aus der grauen Schreibmaschienenvorzeit auf den digitalen Friedhof zu verbannen. Das Projekt CAPSoff hat sich der endgültigen Lösung des Problems verschrieben, ich möchte jedoch die "softe" Variante und Linux vorstellen. Die meisten Beschreibungen zu dieser Taste im Netz schalten sie komplett ab. Dabei wird jedoch übersehen, dass man meistens durchaus einen Tastendruck beabsichtigt hatte und eine der Tasten in umittelbarer Umgebung (Tab, A und Shift) erwischen wollte. Bindet man nun auf Capslock A oder Tab, so muss man das zusätzliche Zeichen bei einem Vertipper wieder löschen/die Aktion rückgängig machen. Bindet man jedoch Shift passiert bei einem Vertipper gar nichts. Aus diesem diesem Grund habe ich mich dazu entschlossen Capslock mit Shift zu belegen. Lange Vorrede, kurze Lösung:

Zunächst muss eine Datei (bei mir $HOME/.Xmodmap) mit folgendem Inhalt erzeugt werden:

clear Lock
add shift = Caps_Lock

Diese kann dann einfach mit einem xmodmap $HOME/.xmodmap geladen werden. Um dies Automatisch bei der KDE Ameldung auzuführen habe ich die Datei $HOME/.kde/Autostart/xmodmap erstellt:

#!/bin/bash
xmodmap $HOME/.Xmodmap

Noch mit chmod 755 $HOME/.kde/Autostart/xmodmap ausführbar machen und Capslock sollte nie wieder Probleme verursachen.

Gleichtakt

uwe (Uwe Weissenbacher) — Thu, 24 Dec 2009 12:24:00 +0100

Um die Uhrzeit unter Linux mit der Koordinierten Weltzeit (UTC) synchron zu halten sollte NTP als standardisierte und offenes Protokoll benutzt wurden. Hierbei stehen einige Programme zur Auswahl, welche unterschiedliche Strategien zum Abgleich verfolgen. Das einfachste in dieser Katagorie ist sicher ntpdate, welches einen Server nach der aktuellen Uhrzeit befragt und diese hart im System setzt. Dieses Vorgehensweise übergeht jedoch Daemons wie z.B. cron und so können geplante Backups schlicht "vergessen" werden. Auch wenn man gerade am Rechner arbeitet kann eine plötzliche Veränderung der Zeit den Bildschirmschoner anspringen lassen.

Auch aus diesen Gründen sollte dem ntpd als Standardimplementation der Vorzug gegeben werden. Dieser gleicht Gangdifferenzen zur korrekten Uhrzeit durch Beschleunigung bzw. Verlangsamung der lokalen Systemuhr aus. Stimmt die Zeit wieder, stellt der Daemon die richtige Geschwindigkeit her. Die oben angeführten Nachteile von ntpdate sind damit schon einmal umschifft. Natürlich bringt das eine etwas aufwendigere Konfiguration mit sich, allerdings sollte dies mit den zahlreichen Tutorials im Netz kein Problem sein.

Vereinfacht wird die "richtige" Geschwindigkeit der Systemuhr normalerweise durch einen Baustein auf dem Motherboard bestimmt, wobei ein Quarzkristall x-mal pro Sekunde schwingt. Da es bei solchen Bauteilen allerdings immer auch Fertigungstoleranzen gibt, ist die Sekunde sogar auf auf zwei Motherboards des gleichen Modells unterschiedlich lang. Diese Sekunden unterscheiden sich dann auch noch einmal von der einer (extrem genauen) Atomuhr. Dieser Unterschied wird auch Drift genannt, der bei jedem Computer unterschiedlich ist. Diesen Drift speichert der ntpd standardmässig unter /var/lib/ntp/ntp.drift und kann die Uhrzeit so auch ohne Verbindung in Netz sehr genau halten.

Mit dem Kommandozeilenprogramm ntpq kann man dem ntpd bei der Arbeit zusehen und Problemen auf den Grund gehen. Die verbundenen ntp Server werden mit dem Kommando "peers" angezeigt:


uwe@krusty ~ $ ntpq -n -c peers
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*129.70.132.33   129.70.130.70    2 u   45   64  377   65.492    4.168   0.805
+85.214.29.92    131.188.3.222    2 u    3   64  377   72.744   -0.136   0.702
+78.47.136.197   143.93.99.252    2 u   55   64  377   59.573    1.509   1.118
-92.51.130.224   85.214.71.202    3 u   60   64  377   69.906   -5.627   0.654

Hier sollte mindestens ein Server mit einem * markiert sein. Dieser ist für den ntpd am "stabilsten" zu erreichen und der eigene Referenzserver. Die mit + markierten Hosts wären die nächsten Kandidaten falls der Referenzserver nicht mehr verfügbarsein sollte. Mit "associations" kann man sich diese Beziehungen auch ansehen


uwe@krusty ~ $ ntpq -n -c associations

ind assID status  conf reach auth condition  last_event cnt
===========================================================
  1 54760  9624   yes   yes  none  sys.peer   reachable  2
  2 54761  9424   yes   yes  none  candidat   reachable  2
  3 54762  9424   yes   yes  none  candidat   reachable  2
  4 54763  9324   yes   yes  none   outlyer   reachable  2

Es gibt auch einen Kommandozeilenmodus von ntpq in dem man sich austoben kann:


uwe@krusty ~ $ ntpq
ntpq> ?
ntpq commands:
addvars        debug          lopeers        passociations  rl
associations   delay          lpassociations passwd         rmvars
authenticate   exit           lpeers         peers          rv
cl             help           mreadlist      poll           showvars
clearvars      host           mreadvar       pstatus        timeout
clocklist      hostnames      mrl            quit           version
clockvar       keyid          mrv            raw            writelist
cooked         keytype        ntpversion     readlist       writevar
cv             lassociations  opeers         readvar
ntpq>

IPv6 mit Hurricane Electric und OpenWRT

uwe (Uwe Weissenbacher) — Sat, 21 Nov 2009 15:49:54 +0100

Will man mit einem DSL Anschluss in Deutschland per IPv6 ins Internet und nicht extra dafür zu einem der wenigen Provider die IPv6 nativ anbieten wechseln, so bleibt als einzig praktikable Möglichkeit derzeit nur ein 6in4 Tunnel. Der amerikanische Konzern Hurricane Electric (oder der einfacheit halber: HE) bietet unter http://tunnelbroker.net/ einen kostenlosen IPv6 Tunnelbroker an, zu welchem man von jedem beliebigen DSL aus einen Tunnel betreiben kann. Nach der Registrierung kann unter "Create Regular Tunnel" ein neuer Tunnel beantragt werden. Dabei muss die eigene DSL IP (herauszufinden z.B. bei www.whatismyip.org) allerdings pingbar sein, sonst scheitert der Antrag. Ausserdem sollte man gleich ein "Routed /48" beantragen, damit man die Clients hinter dem eigenen Router gleich mit IPv6 versorgen kann.

Ich benutze auf meinem DSL Router WRT54GL derzeit die Linuxdistribution OpenWRT. Es exitiert zwar eine Anleitung für IPv6 auf dieser Distribution, allerdings ist diese nicht mehr wirklich aktuell. Diese Anleitung wurde erfolgreich mit der OpenWRT Version 8.09.1 (Kamikaze) entwickelt. Um IPv6 mit HE zum fliegen zu bringen sind folgende Schritte notwendig:

Zunächst müssen mit opkg install folgende Pakete installiert werden


ip6tables
kmod-ip6tables
kmod-ipv6
radvd

Der Tunnelbroker geht von einer statischen IP aus, bei DSL ändert sich diese jedoch üblicherweise mit jeder Neueinwahl. Um den Tunnelendpunkt bei jeder Änderung wieder aufzusetzen habe ich ein Shellskript erstellt. Es wird immer aufgerufen wenn sich ein Interfacestatus ändert. Zunächst wird die Benutzernummer gebraucht, welche auf der Hurricane Electric Tunelbroker Homepage direkt neben "UserID" steht. Ebenfalls auf der HE Seite unter "Tunnel Details" ist die "Global Tunnel ID" zu finden. Der letzte notwendige Wert ist das mit MD5 gehashte Passwort. Dies lässt sich am einfachsten an der Shell erstellen:


$ echo -n 'XXX' | md5sum
bc9189406be84ec297464a514221406d  -

Die MD5 Summe das Passworts XXX ist in diesem Beispiel also bc9189406be84ec297464a514221406d. Der letzte Wert der benötigt wird ist die "Client IPv6 address", welche sich ebenfalls bei den "Tunnel Details" befindet.

Diese Werte müssen in das Skript unten eingetragen und in der Datei /etc/hotplug.d/iface/10-ipv6 gespeichert werden:


#!/bin/sh

USER="XXX"
PASS="XXX"
ID="XXX"
CLIENT="XXX/64"
REMOTEV4="216.66.80.30"
ROUTEDNET="XXX::/48"

EXT="wan"
INT="lan"
TUNNEL="he-ipv6"

. /etc/functions.sh      # common functions
include /lib/network     # include /lib/network/*.sh
scan_interfaces          # read and parse the network config


if [ "$ACTION" = "ifup" -a "$INTERFACE" = "$EXT" ]
then
        config_get IPV4 "$EXT" ipaddr
        logger "updating ipv4 tunnel endpoint to $IPV4"
        wget -O - "http://ipv4.tunnelbroker.net/ipv4_end.php?ipv4b=$IPV4&pass=$PASS&user_id=$USER&tunnel_id=$ID" > /dev/null 2>&1
        ip tunnel add $TUNNEL mode sit remote $REMOTEV4 local $IPV4 ttl 255
        ip link set $TUNNEL up
        ip addr add $CLIENT dev $TUNNEL
        ip route add ::/0 dev $TUNNEL
        config_get LANIF "$INT" ifname
        ip route add $ROUTEDNET dev $LANIF
fi

if [ "$ACTION" = "ifdown" -a "$INTERFACE" = "wan" ]
then
        ip tunnel del $TUNNEL
        config_get LANIF "$INT" ifname
        ip route del $ROUTEDNET dev $LANIF
fi

Um die Kommunikation mit dem Tunnelbroker zu erlauben muss dieser in der OpenWRT IPv4 Firewall (/etc/config/firewall) freigeschaltet werden:


config rule
        option src_ip   216.66.80.30
        option proto    41
        option target   ACCEPT

Um den Router auch gegenüber dem Internet zu schützen sollten in die Datei /etc/firewall.user folgende Zeilen hinzugefügt werden:


### ipv6 stuff
ip6tables -F INPUT
ip6tables -P INPUT DROP
ip6tables -A INPUT -p tcp --dport 22 -j ACCEPT
ip6tables -A INPUT -p icmpv6 -j ACCEPT
ip6tables -F FORWARD
ip6tables -A FORWARD -j ACCEPT

Diese Firewall schützt nur den Router und nicht die Clients im Netz dahinter. Entweder man erweitert die Regeln oben entsprechend oder man spendiert jedem Client eine IPv6 Firewall. Die oben gemachten Änderungen werden nach einem "/etc/init.d/firewall restart" aktiv.

Die Einstellungen sind gemacht und nach einem "ifdown wan; ifup wan" sollte der Tunnel stehen. Dies kann gleich mit ping6 geprüft werden:


root@OpenWrt:~# ping6 -c3 www.kame.net
PING www.kame.net (2001:200:0:8002:203:47ff:fea5:3085): 56 data bytes
64 bytes from 2001:200:0:8002:203:47ff:fea5:3085: seq=0 ttl=51 time=294.092 ms
64 bytes from 2001:200:0:8002:203:47ff:fea5:3085: seq=1 ttl=51 time=292.718 ms
64 bytes from 2001:200:0:8002:203:47ff:fea5:3085: seq=2 ttl=51 time=293.255 ms

--- www.kame.net ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 292.718/293.355/294.092 ms
root@OpenWrt:~# ping6 -c3 ipv6.google.com
PING ipv6.google.com (2001:4860:a003::68): 56 data bytes
64 bytes from 2001:4860:a003::68: seq=0 ttl=59 time=19.912 ms
64 bytes from 2001:4860:a003::68: seq=1 ttl=59 time=15.248 ms
64 bytes from 2001:4860:a003::68: seq=2 ttl=59 time=15.082 ms

--- ipv6.google.com ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 15.082/16.747/19.912 ms

Um nun die Clients im eigenen Heimnetz per Autokonfiguration mit IPv6 zu versorgen muss der Linux Router Advertisement Daemon konfiguriert werden. Dazu wird das oben beantragte Routed /48 benötigt. Die Konfiguration sieht bei mir folgendermassen aus:

/etc/config/radvd

config interface
        option interface        'lan'
        option AdvSendAdvert    1
        option AdvManagedFlag   0
        option AdvOtherConfigFlag 0
        option ignore           0

config prefix
        option interface        'lan'
        # If not specified, a non-link-local prefix of the interface is used
        option prefix           '2001:470:9888::/64'
        option AdvOnLink        1
        option AdvAutonomous    1
        option AdvRouterAddr    0
        option AdvPreferredLifetime     600
        option AdvValidLifetime 1200
        option ignore           0

config rdnss
        option interface        'br-lan'
        # If not specified, the link-local address of the interface is used
        option addr             ''
        option ignore           1

Für die option "prefix" muss das eigene bei HE beantragte /48 eingetragen werden. Achtung: als Netzmaske für radvd ist /64 zwingend notwendig, denn nur so können sich die Clients mit Hilfe von EUI-64 selbst eine Adresse würfeln. Trägt man hier /48 bleiben 16 Bits übrig, von denen der Client nicht weiss, wie er sie füllen soll. Nachdem man den Daemon aktiviert und gestartet ist sollten alle Clients im dahinterliegenden Netz automatisch mit IPv6 versorgt werden, sofern das Betriebssystem dies unterstützt.


root@OpenWrt:~# /etc/init.d/radvd enable
root@OpenWrt:~# /etc/init.d/radvd start

Bitmagic

uwe (Uwe Weissenbacher) — Thu, 12 Nov 2009 23:52:29 +0100

Da ich eben doch eine Weile gebastelt möchte ich folgendes für die Nachwelt aufbewahren. Die Konvertierung einer Subnetmaske (übliches Format) in die (von Cisco benutzte) Wildcard Notation in python:


uwe@barney ~ $ python
Python 2.6.2 (r262:71600, Sep  3 2009, 02:12:03)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket, struct
>>> a=struct.unpack('!L',socket.inet_aton("255.255.255.0"))[0]
>>> socket.inet_ntoa(struct.pack('!L',~a & 0xFFFFFFFF))
'0.0.0.255'

Ein paar Anmerkungen zum besseren Verständnis

!L wird gebraucht da Network byte order Big Endian(!L) ist, die normalen PC Architekturen aber Litte Endian(L) verwenden.

Das bitweise AND mit 0xFFFFFFFF ist notwendig, da das NOT vor a einen negativen Wert erzeugt, welcher nicht mehr in den Long passt. Das wiederrum erzeugt eine unschöne Warnung. Dieses Vorzeichenbit wird mit der Verknüpfung positiv womit das ganze wieder passt.

Nachtrag:

Um CIDR nach Netzmaske zu Konvertieren nimmt man das hier:


>>> socket.inet_ntoa(struct.pack('!L',8589934591L<<(32-24)))
'255.255.255.0'
>>> socket.inet_ntoa(struct.pack('!L',8589934591L<<(32-25)))
'255.255.255.128'
>>> socket.inet_ntoa(struct.pack('!L',8589934591L<<(32-26)))
'255.255.255.192'
>>> socket.inet_ntoa(struct.pack('!L',8589934591L<<(32-27)))
'255.255.255.224'

2. Nachtrag

Oder einfacher zu lesen (und zu verstehen):


>>> socket.inet_ntoa(struct.pack('!L',0xFFFFFFFF<<(32-24)))
'255.255.255.0'
>>> socket.inet_ntoa(struct.pack('!L',0xFFFFFFFF<<(32-25)))
'255.255.255.128'
>>> socket.inet_ntoa(struct.pack('!L',0xFFFFFFFF<<(32-26)))
'255.255.255.192'
>>> socket.inet_ntoa(struct.pack('!L',0xFFFFFFFF<<(32-27)))
'255.255.255.224'

Abgelegt

uwe (Uwe Weissenbacher) — Mon, 01 Jun 2009 17:22:16 +0200

Konfigurationsdateien unter *nix Systemen werden üblicherweise in /etc abgelegt. Da es sich dabei meist um reine Textdateien handelt bietet sich eine Versionierung mit einem der bekannten Systeme an. Ich habe mich aus reiner Faulheit (meine Diplomarbeit enstand bereits damit) für Subversion entschieden. Die Einführung in SVN, so die Abkürzung für Subversion, und in Versionsverwaltung allgemein spare ich mir an dieser Stelle da es dazu schon viele hervorragende Quellen im Web gibt.

Ich habe diverse Rechner, deren /etc ich auf diese Weise sichern und will und einen Rootserver welchen ich als zentrales Repository zur Speicherung benutzen möchte.

Als erstes wird das dazu das SVN Repository angelegt:

uwe@maninthemiddle ~ $ svnadmin create /home/uwe/repos

Mehr muss auf dem Server auch nicht mehr gemacht werden. Der Rest wird vom Clientrechner (in meinem Fall mit dem Namen "Krusty" über SSH erledigt. Dazu bietet es sich an Key-basierende Authentifizierung für SSH zu benutzen. Auch hier sei auf die vielen guten Tutorials im Web verwiesen. Da ich SSH normalerweise als unprivilegierter Anwender benutze /etc aber nur als root vollständig gelesen werden kann, sollte das SSH profil von root dementsprechend angepasst werden. Dies beinhaltet den richtigen Benutzernamen, sowie eine identity Datei welche den private key enthält. Die entsprechende Konfigurationsdatei /root/.ssh/config sieht bei mir dementsprechend so aus:

Host maninthemiddle.de
User uwe
IdentityFile /home/uwe/.ssh/id_rsa

Nun muss im Repository ein Verzeichnis angelegt werden in dem die Dateien später landen sollen:

krusty etc # svn mkdir svn+ssh://maninthemiddle.de/home/uwe/repos/etc-krusty

Dieses wird im Verzeichnis /etc auf dem lokalen Rechner ausgecheckt und ist damit mit diesem verbunden:

krusty etc # svn co svn+ssh://maninthemiddle.de/home/uwe/repos/etc-krusty /etc

Mit svn add können nun Dateien hinzugefügt und mit svn commit ins Repository hochgeladen werden. Unschön ist dabei allerdings, dass nicht hinzugefügte Dateien bei svn status mit einem Fragezeichen auftauchen und die Übersichtlichkeit stark leidet:

krusty etc # svn status
M .
? xinetd.conf
? opera6rc.fixed
? nanorc
? racoon
? java-config-2
...

Bei der Softwareentwicklung sorgt dieser Mechanismus dafür, dass keine Datei vergessen wird. Hier tauchen in diesem Fall jedoch in der Mehrzahl Dateien auf die gar nicht ins Repository kommen sollen. Um den Überblick zu behalten habe ich deshalb SVN angewiesen alle Dateien zu ignorieren, die nicht eingecheckt sind.

krusty etc # svn propset svn:ignore '*' /etc

Für alle anderen Rechner einfach die gleichen Schritte durchführen, womit Probleme mit gelöschten/verschlimmbesserten Konfigurationsdateien der Vergangenheit angehören sollten.

Nachtrag:
Gerade unter gentoo sollte auch die aktuelle Kernelkonfiguration gesichert werden. Ich setze dazu einfach einen Symlink nach /etc und füge diese Datei zum Repository hinzu.

barney etc # ln -s /usr/src/linux/.config kernelconfig
barney etc # svn add kernelconfig
A kernelconfig

Nachtrag 2:
Die alten Versionen einzelner Dateien kann man mittels svn export -r REVISION holen:

uwe@barney ~/tmp $ svn log svn+ssh://maninthemiddle.de/home/uwe/repos/etc-barney/lilo.conf
------------------------------------------------------------------------
r18 | uwe | 2009-11-26 21:49:23 +0100 (Do, 26. Nov 2009) | 1 Zeile

------------------------------------------------------------------------
r17 | uwe | 2009-11-26 21:43:01 +0100 (Do, 26. Nov 2009) | 1 Zeile

------------------------------------------------------------------------
uwe@barney ~/tmp $ svn export -r 17 svn+ssh://maninthemiddle.de/home/uwe/repos/etc-barney/lilo.conf
A lilo.conf
Export abgeschlossen.

Nachtrag 3:
Um z.B. die /etc/X11/xorg.conf ins Repository hinzufügen zu können muss auch das Verzeichnis /etc/X11/ im Repository vorhanden sein. Subversion fügt mit svn add /etx/X11 allerdings auch alle Dateien unterhalb dieses Verzeichnisses ein. Stattdessen möchste man die Option --non-recursive benutzen:

barney etc # svn add --non-recursive X11/
A X11

Versehentlich ins Repository aufgenomme Dateien kann man mit svn delete wieder aus diesem entfernen, allerdings löscht svn dann auch die lokale Kopie. Hier sollte man --keep-local als Option mitgeben:

barney portage # svn delete --keep-local savedconfig/
D savedconfig/sys-apps/busybox-1.13.2
D savedconfig/sys-apps
D savedconfig

Gedreht

uwe (Uwe Weissenbacher) — Sun, 13 Jan 2008 13:57:16 +0100

Wer kennt das nicht. Nach dem Urlaub werden Fotos am Bildschirm bestaunt und es dauert nicht lange bis das kollektive Kopfkippen nach rechts oder links beginnt. Glücklicherweise haben inzwischen sogar Handykameras Neigungssensoren eingebaut, womit die Elektronik die Ausrichtung in den EXIF Daten eines Bildes speichern kann. Somit ist es für ein Ausgabegerät möglich das Foto anhand dieser Daten wieder richtig herum auf den Bildschirm zu bringen. Der Bildbetrachter beispielsweise gqview kann die Fotos so schon vor der Anzeige drehen. Allerdings wirkt sich dies nur auf die Darstellung aus und die gespeicherten Fotos behalten ihre Ausrichtung. Da nicht alle Bildbetrachter so eine Funktion enthalten will man natürlich das gespeicherte Material zurecht rücken. Dabei ist zu bedenken, dass JPEG ein verlustbehaftetes Format ist und das Laden, Drehen und erneute Speichern zur Qualitätsminderung führen würde. Glücklicherweise wurden solche Fälle von der Joint Photographic Experts Group bei der Entwicklung des Formats bedacht. Aus diesem Grund wurden einige spezielle verlustfreie JPEG Operationen definiert wie z.B. drehen um vielfache von 90° und das Beschneiden eines Bildes um vielfache von 16 Pixeln. Das Verarbeitende Programm muss diese JPEG Operationen allerdings explizit unterstützen, sonst werden in der Regel verlustbehaftete Operationen durchgeführt. Genug der Theorie, hier die Linux Praxis:

Unter Gentoo befinden sich alle hier genannten Tools im Paket media-libs/jpeg. Das Programm jpegtran unterstützt besagte JPEG Operationen und kann die Bilder wie gewünscht drehen. Es empfiehlt sich außerdem immer den Parameter -copy all zu verwenden, damit die EXIF Daten erhalten bleiben. Allerdings stimmt nun die in den EXIF Daten gespeicherte Ausrichtung nicht mehr. Diese kann man dann mit dem Tool jpegexiforient und dem Parameter -1 auf Normalausrichtung setzen. Das ganze ist natürlich automatisierbar und mit dem Skript exifautotran umgesetzt. Zunächst wird die Ausrichtung gelesen, dann richtig gedreht und zum Schluss wird im EXIF Teil wieder die Normalausrichtung gesetzt. Ein exifautotran *.jpg entlastet also die Nackenmuskulatur während des Fotoabends.

Update: unter Ubuntu heißt das entsprechende Paket libjpeg-progs

Verschlüsselt

uwe (Uwe Weissenbacher) — Sat, 25 Aug 2007 17:43:35 +0200

Cisco bietet auf einer Menge Devices IPSec zur verschlüsselten Remote Anbindung entfernter Standorte. Ich habe das ganze letzte Woche anhand einiger Laboraufbauten getestet. Mit von der Partie waren ein Router der Serie 2600er mit IOS, ein VPN Concentrator (3000er Serie) und eine PIX. Das ganze sah in etwa folgendermassen aus:

PC1 --(192.168.55.0/24)-- Cisco Device 1 --(192.168.66.0/24)-- Cisco Device 2 --(192.168.77.0/24)-- PC2

Zwischen beiden Cisco Devices sollte ein IPSec Tunnel aufgebaut werden und die Netze 192.168.55.0/24 und 192.168.77.0/24 über diesen verschlüsselt übertragen werden. Ziel war es also, dass PC1 PC2 pingen kann.

Die Konfiguration ist zwar recht einfach, wenn man die Tutorials auf der Cisco-Homepage befolgt, wenn es danach allerdings nicht so tut wie es soll, wird es mühsam. Deshalb hier meine gesammelten Erkenntnisse:

Beide Cisco Devices sollten sich nicht im selben Subnet befinden (der Aufbau von oben bringt also Probleme). Es kommt zu sehr seltsamen Effekten, wenn es kein Default Gateway bzw. keine Default Route gibt. Das Default Gateway sollte dabei natürlich auf dem äußeren Interface liegen.

Die PIX nimmt beim Hashing der Identity standardmäßig den FQDN, was ohne DNS-Namen im Laboraufbau natürlich sinnfrei ist. Mit folgendem Kommando kann man auf IP Adressen umschalten: isakmp identity address

Ich schreib das jetzt so einfach runter, aber besonders der erste Punkt hat doch einiges an Zeit verschlungen. Ich hoffe ich erspare jemand anderem damit die Sucherei nach dem Fehler.

Manipuliert

uwe (Uwe Weissenbacher) — Mon, 05 Mar 2007 21:35:30 +0100

Scapy ist ein ziemlich cooler Packetgenerator/Analyzer/vielesmehr. Die Projektseite gibt mit der "Quick Demo" schon eine kleine Einführung in die Fähigkeiten dieses Tools.

Leider ist die Dokumentation im im Gegensatz zum Programm noch weitgehend unbrauchbar und deshalb will ich versuchen hier immer mal wieder nützliche Scapy Skripte/Einzeiler vorzustellen.

Wilde DHCP Server finden

Problem: irgendwo im Netz schwirrt ein nicht genemigter DHCP Server herum und vergibt IP Adressen. Die umständliche Methode wäre das eigene Interface umzukonfigurieren und einen DHCP Request zu machen. Scapy schafft das ohne diesen lästigen Mehraufwand.

>>> dhcp_request(iface="eth1")
WARNING: conf.checkIPaddr is not 0, I may not be able to match the answer
Begin emission:
Finished to send 1 packets.
.......................................
Received 39 packets, got 0 answers, remaining 1 packets

Ein gleichzeitiger tcpdump offenbart ide MAC-Adresse des Übeltäters:

# tcpdump -e -i eth1 port 67 or port 68
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes

21:43:17.938745 00:11:11:11:11:11 (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 286: 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:11:11:11:11:11 (oui Unknown), length 244

21:43:17.952684 00:22:22:22:22:22 (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 342: ..bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 300

Mit einem managbaren Switch lässt sich die Adresse 00:22:22:22:22:22 nun schnell einem Port zuordnen. Unter IOS z.B. mit show mac-address-table oder unter CatOS mit show cam dynamic. Dann muss man nur noch das Kabel verfolgen und dem User auf die Finger klopfen ;).

Genug

uwe (Uwe Weissenbacher) — Tue, 13 Feb 2007 14:53:04 +0100

Ich hab die Schnauze gestrichen voll. Trotz der Tatsache, dass Trackbacks auf moderieren stehen, erhalten ich ständig Müll von irgendwelchen asozialen Spammern. Aus diesem Grund sind sie jetzt global deaktiviert. Wer einen Trackback setzen will, möge mich per Mail kontaktieren.