Im zu replizierenden LDAP-Server (“Provider”) muss man lediglich dafür sorgen, dass das syncprov-Modul in der slapd.conf geladen wird:

modulepath      /usr/lib/ldap
moduleload      back_hdb
moduleload      syncprov

Im Zielserver (“Consumer”), wird so eine 1:1 Replikation des Quellservers konfiguriert:

# replication settings
syncrepl rid=001
    provider=ldaps://ldaps.yourdomain.de:636
    type=refreshAndPersist
    searchbase="dc=yourdomain,dc=de"
    schemachecking=on
    type=refreshAndPersist
    retry="60 +"
    bindmethod=simple
    binddn="cn=replicator,dc=yourdomain,dc=de"
    credentials=assword

Natürlich müssen im Quellserver entsprechende Credentials hinterlegt werden. Durch das Keyword refreshAndPersist bleibt die Verbindung dauerhaft bestehen und Änderungen im Quellserver werden sofort auf dem Zielserver repliziert.

Achtung: im Zielserver müssen natürlich die gleichen Schemata geladen sein, wie im Quellserver. Schaut euch also die Include-Section entsprechend an, sonst hagelt es Fehler.

Mit dieser Methode kann man den LDAP-Server super-komfortabel umziehen, einfach Replikation einschalten, DNS-umschwenken und dann die Replikation auf dem Zielserver ausschalten.

Die Modemsoftware bringt jedoch einen DynDNS-Client mit, allerdings ist der nur via Telnet zu konfigurieren. Das Modem ist vom LAN und WLAN aus unter seiner Standard-IP 192.168.1.1 erreichbar.

Die Zugangsdaten lauten:

• User: admin
• Passwort: AliceXXXXXX123

Die Zeichenfolge XXXXXX muss durch die letzten sechs Zeichen der LAN MAC-Adresse des Modems ersetzt werden. Lautet die MAC-Adresse des Modems z.B. 00:25:5E:AB:64:FE, so muss man als Passwort AliceAB64FE123 verwenden:

$ telnet 192.168.1.1
 
Entering character mode
Escape character is '^]'.
 
Alice Modem WLAN 1121
Login: admin
Password: AliceAB64FE123
 
>

Man findet sich auf einer kastrierten Linux(?)-Shell wieder. help liefert eine Liste der möglichen Kommandos. Mit ddns kann man den DynDNS-Client konfigurieren:

> ddns
ddns add hostname --username username --password password --interface interface --service tzo|dyndns
     remove hostname
     show
ddns --help>

Ok, mit add fügt man eine DynDNS-Konfiguration hinzu, mit remove wird sie wieder entfernt und mit show kann man alle anzeigen lassen.

Der folende Aufruf fügt eine Konfiguration für den Hostnamen myhomedsl.dyndns.org beim Dienst dyndns mit dem Usenamen user6 und dem Passwort 123456 hinzu:

dns add myhomedsl.dyndns.org --username user6 --password 123456 --interface ppp_0_1_32_1  --service dyndns

Wichtig: man muss im parameter --interface den Namen des WLAN-Interfaces eingeben. Den Namen bekommt man mit dem Kommando ifconfig heraus. Es listet alle Interfaces auf, gesucht ist das mit ppp im Namen:

ppp_0_1_32_1    Link encap:Point-Point Protocol  
                inet addr:85.178.209.191  P-t-P:213.191.89.4  Mask:255.255.255.255
                UP POINTOPOINT RUNNING NOARP ALLMULTI MULTICAST  MTU:1492  Metric:1
                RX packets:9540 errors:0 dropped:0 overruns:0 frame:0
                TX packets:7456 errors:0 dropped:0 overruns:0 carrier:0
                collisions:0 txqueuelen:3 
                RX bytes:6444034 (6.1 MiB)  TX bytes:1135835 (1.0 MiB)

In meinem Beispiel lautet der Name des Interfaces also ppp_0_1_32_1.

Kind 1: (zeigt auf Knie) “Papa Loch!”
Papa: “Ja, die Hose hat ein Loch.”
Kind 1: (zeigt auf anderes Knie) “Papa, auch Loch!”
Papa: “Ja, da ist noch ein Loch.”
Kind 1: “Cool!”
Papa: (grinst)

Shot for the upcoming third demo of Cancer Clan.

The setup was pretty simple:

We tried to use a second flash to get a shadow of the chainsaw-blade. It was hard to adjust everything and when we got finally a good shadow, the whole photo looked pretty boring…

Camera Model: Nikon D90
Lens: Nikon AF-S DX Nikkor 18-105mm 1:3.5-5.6G ED VR
Focal Length: 18.00 mm
Focal Length (35mm Equiv): 27 mm
Exposure Time: 1/125 sec
F-Number: f/16
Shooting mode: Manual
Exposure bias: 0 EV
Flash: Yes
ISO: 200
Image at flickr, large version

I posted already the recipe, but this time we modified it slightly.

Camera Model: Nikon D90
Lens: Nikon AF-S DX Nikkor 18-105mm 1:3.5-5.6G ED VR
Focal Length: 105.00 mm
Focal Length (35mm Equiv): 157 mm
Exposure Time: 1/80 sec
F-Number: f/6,3
Shooting mode: Manual
Exposure bias: 0 EV
Flash: Yes
ISO: 200
Image at flickr, large version

If you come close enough, you will see a double galaxy

Camera Model: Nikon D90
Lens: Sigma 150mm 2.8 EX Makro
Focal Length: 150.00 mm
Focal Length (35mm Equiv): 225 mm
Exposure Time: 1/200 sec
F-Number: f/2.8
Shooting mode: Manual
Exposure bias: 0 EV
Flash: Yes
ISO: 200
Image at flickr, large version

Es gibt von den Herren btw. ab 10. Februar eine Live-DVD.

Statt dessen habe ich mich dann in Saal 1 zur Wikipedia-Diskussion gesetzt. Fefe hatte es sich auf der Couch bequem gemacht, lest Euch mal den Artikel in seinem Blog durch, er hat die Diskussion ganz gut zusammengefasst.

Blackbox JTAG Reverse Engineering war auch nicht wirklich erhellend, aber vielleicht war auch meine Aufmerksamkeit am vierten Tag arg verschlissen. Ich habe mich dann noch mit ein paar älteren Herren aus dem Internet zum Aisiambiss in den Bahnhof gesetzt.

Photography and the Art of Doing it Wrong war ein interessanter Rückblick auf die Geschichte der Fotografie, außerdem gab es ein paar gute Inspirationen bewusst “falsch” zu fotografieren und die “Fehler” als künstlerischen Effekt einzusetzen. Ein erfrischender Kontrast zur üblichen “Eye Candy Fotografie”.

Falls Ihr den Kongress verpasst habt, schaut Euch die Aufzeichnungen an, Anne hat ein paar gute Empfehlungen zusammengetragen

Danach gab es ein Update zur DECT-Sicherheit. Die Jungs sind schon sehr weit gekommen. Der Grund, warum man den großen Knall nicht gehört hat, ist vielleicht, weil er vom noch viel größeren Knall des Platzens der GSM-Sicherheitsblase übertönt wurde. Interessantes Detail: die Zusammenarbeit mit dem DECT-Forum scheint viel angenehmer und besser zu laufen, als die Zusammenarbeit mit dem GSM-Forum, die derzeit noch nicht einmal zugeben, dass es ein Problem gibt (“das was die machen ist ja Illegal, und deswegen existiert das Problem nicht”).

Dann habe ich mir “DDoS/botnet mitigation and hosting online communities” angeschaut, das war nett, aber insgesamt kein großer Erkenntnisgewinn.

Der GSM-Talk von Harald Welte hiess “Using OpenBSC for fuzzing of GSM handsets”, es war aber eher ein generelles Update zu OpenBSC. Trotzdem interessant, auf welch wackeligen Füßen das ganze System steckt, es gibt nur eine Hand voll (4!) GSM-Stacks und die sind auf 4 Milliarden Geräten deployed. Wenn also ein Stack ein Problem hat, kann man das auf sehr vielen Geräten nachvollziehen.

Was mir im Zusammenhang mit GSM total neu war – und gleich auf drei Vorträgen ausführlich erwähnt wurde – ist, dass im Zuge der 911-Notrufrichtlinie in den USA die Geräte ihren Standort bestimmen können müssen. Wenn ein GPS-Chip eingebaut ist, dann kann man das relativ einfach machen. Wenn kein GPS-Chip eingebaut ist, geht das aber trotzdem. Das Telefon verstellt einfach die Empfangsfrequenz auf die GPS-Frequenz und empfängt die blanken GPS-Signale, die es zur Auswertung an den Provider schickt (GSM funkt i.dR. auf 0.9, 1.8 und 1.9 GHz, GPS liegt mit 1.2 und 1.5 GHz genau dazwischen). Zusammen mit den bekannten Standortdaten der Basisstationen und der derzeit schon vorhandenen GSM-Peilungsmöglichkeiten kommt dabei eine ausreichend genaue Standortinformation heraus.

Da keine Geräte exklusiv für den US-Markt gebaut werden, ist also davon auszugehen, dass alle Geräte, die seit 2006 in den USA verkauft werden, diese Funktion mitbringen. Die Abfrage findet auf sehr sehr tiefen Schichten des GSM-Protokolls statt und kann von der Anwendungssoftware oder dem Betriebssystem des Telefons nicht verhindert oder bemerkt werden.

Bei “Location tracking does scale up” hat Aaron die Funktionsweise von Skyhook erklärt. Das Grundprinzip ist ja recht einleuchtend. Die Standortdaten und Empfangsfeldstärken von WLAN Beacons werden einmal erfasst und in einer Datenbank hinterlegt. Nun kann man anhand dieser Datenbank seinen Standort auch in Gebäuden bestimmen. Das Problem ist, dass die Datenbank mit der Zeit veraltet, weil WLAN AccessPoints sterben und neue hinzu kommen. Die Update-Funktion steckt aber in der Skyhook-Api selbst. Bei Standortabfragen werden alle sichtbaren ESSIDs mitgesendet, ebenfalls die GPS-Position (falls bekannt) und die Basisstation-Id, an der das Telefon angemeldet ist. Zwar funktioniert die API-Abfrage anonymisiert, aber eine Korrelation mit anderen Datensätzen ist natürlich trotzdem möglich.

Der Fnord-Jahresrückblick war ebenfalls wieder Pflicht, statt mir danach gleich den Kaminsky zu geben, habe ich mich zu Andy und “Die Ereignisse des 12.9. und ihre Folgen” angeschaut. Schaut Euch mal die Aufzeichnung an, den Erkenntnisgewinn kann man garantiert auf jeder Demo verwerten.