Docker und IPv6

Zu meinem Root-Server gab es ein /64-IPv6 Netz (z.B. 2a03:4000:15:3b7/64)  und somit mehr als genug Adressen. Doch wie kann ich Docker-Container unter über diese Adressen ansprechen?

Zunächst fügt man eine IPv6-Adresse aus dem Netz der Netzwerkkarte hinzu:

ip -6 a a 2a03:4000:15:3b7::3/64 dev eth0

Dann startet man einen Container und ruft die IPv4 Adresse aus dem Docker-internen Netz ab:

docker run --name testnginx -d nginx
docker inspect --format '{{ .NetworkSettings.IPAddress }}'\
    testnginx

Anschließend leitet man mit socat die IP-Pakete von der IPv6-Adresse an die IPv4-Adresse des Containers weiter:

socat TCP6-LISTEN:80,reuseaddr,fork,bind=[2a03:4000:15:3b::3]\
    TCP4:172.17.0.15:80

Nun kann man direkt auf den Port des Containers über IPv6 zugreifen.

Influxdb und Grafana

Aus meinem beruflichen Umfeld ist mir Grafana als Lösung zur grafischen Aufbereitung gut bekannt. Daten beziehen wir klassisch aus Graphite.

Für ein Projekt habe ich nun die Daten über öffentliches Netz (also das Internet) in die Datensenke einliefern müssen. Zunächst auch hier an Graphite gedacht, jedoch ergab sich schnell die Überlegung, das der Graphite Port 2003 (hier lauscht der Carbon Daemon) jedwede Daten ohne Authentifizierung annimmt. In einem  öffentlichen Netz sicher kein akzeptabler Zustand, da hier jeder mit Kenntnis von Port und IP beliebige Stördaten einliefern kann. Also auf die Suche nach Alternativen.

InfluxDB bietet laut db-engines.com  als Berechtigungskonzept mit einer „einfache[n] Rechteverwaltung mit Benutzeraccounts“ mehr als Graphite. Auch verspricht die Implementierung in Go mehr Performance. Grund genug, sich InfluxDB näher anzusehen.

InfluxDB

Dank des offiziellen Docker Images ist InfluxDB schnell probeweise gestartet. Hinweise liefert die Seite des Docker-Hub. Zunächst wird die Standardkonfiguration extrahiert:

docker run --rm influxdb influxd config > influxdb.conf

In dieser Datei muss die Option auth-enabled nun aktiviert werden:

...
[http] 
...
auth-enabled = true
...

In Kombination mit meinen beiden Projekten docker_nginx_auto_proxy und docker_ssl_endpoint kann man nun einen Docker Container starten, der Daten über TLS abgesichert entgegen nimmt:

docker run --name=influxdb_1 -d \
 -e PROXY_DATA=server_names:$INFLUXDOMAIN,port:8086 \
 -v /data/influxdb/data:/var/lib/influxdb \
 -v /data/influxdb/conf:/etc/influxdb/influxdb.conf:ro \
 influxdb -config /etc/influxdb/influxdb.conf

Nun müssen wir mindestens einen Admin-Nutzer anlegen. Zunächst verbinden wir uns auf die InfluxDB-CLI:

docker run --rm --link=influxdb_1 -it influxdb influx -host influxdb_1

Anschließend legt folgendes Statement den Admin-Nutzer bofh an:

CREATE USER bofh WITH PASSWORD 'rrzs42' 
  WITH ALL PRIVILEGES

Anschließend die CLI beenden und beim Neuverbinden zusätzlich die Parameter username und password zur Authentifizierung verwenden. Weitere Informationen zur Nutzerverwaltung von InfluxDB findet man in der offiziellen Dokumentation.

Eine Datenbank sollte in der CLI ebenfalls erstellt werden:

CREATE DATABASE datensenke

Testweise können nun bereits Daten eingeliefert werden:

curl -X POST -u bofh:rrzs42 \
  --data-binary 'wert,key=value wert=42.23'\
  'https://$INFLUXDOMAIN/write?db=datensenke'

Die genaue Beschreibung über das Schreiben von Daten findet man in der offiziellen Dokumentation.

Grafana

Für Grafana gibt es ebenfalls ein offizielles Docker-Image. Der erste Schritt ist das Extrahieren der Konfiguration:

docker run --rm --name grafana grafana/grafana
docker cp grafana:/etc/grafana/grafana.ini .

Die wichtigste Anpassung der Konfiguration bezieht sich auf das Abschalten des selbständigen Anmeldens neuer Nutzer (allow_sign_up = false in der Kategorie users). Somit ist nur noch der Administrator (Login: admin) in der Lage, neue Nutzer anzulegen.

Gestartet wird der Grafana-Container mit folgendem Kommando:

docker run --name=grafana -d \
    -e PROXY_DATA=server_names:$GRAFANADOMAIN,port:3000 \
    -v /data/grafana/lib:/var/lib/grafana/ \
    -v /data/grafana/conf:/etc/grafana/grafana.ini \ 
    -e "GF_SERVER_ROOT_URL=https://$GRAFANADOMAIN" \
    -e "GF_SECURITY_ADMIN_PASSWORD=s3cr3t" \
    grafana/grafana

Nun kann die Grafana-Instanz unter  https://$GRAFANADOMAIN aufgerufen werden und der Login funktioniert mit den Credentials admin:s3cr3t.

Der nächste Schritt sollte das Ändern des Passworts des Administrators sein und das Anlegen neuer Nutzer sein. Dies geschieht unter Grafana-MenuAdminGlobal Users.

Um wie die Daten aus InfluxDB in Grafana nutzen zu können, legt man eine Datenquelle unter Grafana-MenuData Sources an. Die Einstellungen für InfluxDB sind in unserem Fall:

  • Type: InfluxDB
  • URL: https://$INFLUXDOMAIN
  • Access: Proxy
  • Http Auth: With Credentials
  • InfluxDB Details:
    • Database: datensenke
    • User: bofh
    • Password: rrzs42

Jetzt sind wir in der Lage, über Dashboards wie gewohnt Graphen an zu legen. Beispielsweise:Et voilà, flexible und ansehnliche graphische Aufbereitung von Zeitseriendaten.

Spielchen mit RSA-Schlüsseln

Als Einstiegshürde für ein CTF (Capture the Flag) dient gerne mal ein RSA Schlüsselpaar, von dem nur der öffentliche Teil bekannt ist. Also kein unrealistischer Ansatz, lediglich die Schlüssellängen sollten entsprechend klein sein.

Vorbereiten der Challenge

Diese Schritte werden vom Spielleitder durchgeführt. Wichtig ist eine geeignete, nicht zu lange Schlüssellänge zu wählen. Hier wählen wir 256 Bit als Schlüssellänge. Das sollte die Teilnehmer vor keine Probleme stellen.

Generieren des Schlüsselpaars

Der wesentliche Schritt bei der Erzeugung eines RSA-Schlüsselpaars ist die Wahl von 2 Primzahlen p und q, deren Produkt n (der RSA-Modulus) die gewünschte Schlüssellänge besitzt.

Dank OpenSSL ist es einfach ein RSA-Schlüsselpaar zu erzeugen:

openssl genrsa -des3 -out private.pem 256
openssl rsa -in private.pem -outform PEM -pubout -out public.pem

Daraus ergibt sich als Public Key beispielsweise:

-----BEGIN PUBLIC KEY-----
MDwwDQYJKoZIhvcNAQEBBQADKwAwKAIhALRUOO0rvPEA282wqL4VF5GibnA1kcux
LHdIOcT807+DAgMBAAE=
-----END PUBLIC KEY-----

Den privaten Schlüssel private.pem können wir nun löschen, da wir diesen zum Einen nicht mehr benötigen und zum Anderen ja rekonstruieren wollen.

Verschlüsseln der Probedatei

Eine Probedatei lesbar.txt wird mit dem öffentlichen Schlüssel mit OpenSSL verschlüsselt:

openssl rsautl -encrypt -inkey public.pem -pubin -in lesbar.txt -out geheim.txt

Das Ergebnis der Verschlüsselung ist eine Datei, die nur unlesbare binäre Daten enthält. Sie kann hier heruntergeladen werden: geheim.txt. Diese Datei und der öffentliche Schlüssel gehen an die Teilnehmer.

Lösen der Challenge

Diese Schritte werden durch die Teilnehmer durchgeführt.

Knacken der Schlüssel

Zunächst müssen wir aus dem öffentlichen Schlüssel die beiden Parameter  n (Modulus) und e (Exponent) extrahieren:

from Crypto.PublicKey import RSA

public_key = RSA.importKey(open('public.pem', 'r').read())
print 'n =', public_key.n
print 'e =', public_key.e

Dazu verwenden wir die Bibliothek pycrypto (Debian: python-crypto). Ausgegeben werden die beiden oben genannten Werte, in unserem Beispiel also:

n = 815651207903382691105573612057017618852
    64115611526254943458542612275141001091
e = 65537

Nun muss der Modulus faktorisiert werden (n ist das Produkt der beiden Primzahlen p und q). Dazu kann das msieve von Jason Papadopoulos verwendet werden.

Für unsere Zahl n liefert msieve auf einem Core2Duo T7400 nach knapp 10 Minuten die beiden Primfaktoren:

p = 264446414907090989475638551039611206507
q = 308437234133027923039636551098640509513

Alternativ können wir auch factordb.com verwenden, wenn die Zahl dort bereits faktorisiert vorliegt.

Nun müssen wir aus p und q den privaten Exponenten d berechnen:

d = 1/e mod (p-1)*(q-1)

oder mit Python und dem Modul gmpy2:

import gmpy2

p = 264446414907090989475638551039611206507
q = 308437234133027923039636551098640509513
e = 65537
d = gmpy2.invert(e,(p-1)*(q-1))

Aus den Werten n,e und d wird nun der private Schlüssel erstellt und ausgegeben:

from Crypto.PublicKey import RSA
key = RSA.construct((n,e,d))
print key.exportKey()

In unserem Beispiel ergibt das:

-----BEGIN RSA PRIVATE KEY-----
MIGrAgEAAiEAtFQ47Su88QDbzbCovhUXkaJucDWRy7Esd0g5xPzTv4MCAwEAAQIh
ALFDhX4nG6FxbaChww6vnyzjasWei1L/rUg3aG/c6MaxAhEA6ArZu41/pzoKRlXH
MfYqSQIRAMbyhuPv26I/S0+zokene2sCEDxkfpDK3huHBp+RubtuJ0kCECAEWecG
6+7Rhto9y4kCkB8CEQCSSbMXMjOybMpz3gCOQYeS
-----END RSA PRIVATE KEY-----

Wir speichern den privaten Schlüssel wieder in der Datei private.pem ab.

Entschlüsseln der Probedatei

Wurde alles richtig durchgeführt, so kann man mit folgender OpenSSL Anweisung die Probedatei entschlüsseln:

openssl rsautl -decrypt -inkey private.pem -in geheim.txt -out lesbar.txt

Der genaue Inhalt von lesbar.txt wird hier jedoch nicht verraten.

Abschluss

Man erkennt hier am Zeitaufwand zur Faktorisierung eines 256 Bit Schlüssels bereits, dass die Sicherheit von RSA auf genau dieser Schwierigkeit basiert. In der Praxis verwendet man daher Schlüssellängen von mindestens 2000 Bit (siehe dazu die Technische Richtilinie des BSI: Kryptographische Verfahren: Empfehlungen und Schlüssellängen (Seite 39, Kapitel 3.5 – RSA).

Mounten von Partitionen aus Image-Dateien

Ist das Backup einer SD-Karte nur als Image-Datei vorhanden und keine Zeit erst wieder auf SD-Karte zu schreiben? Dateimanager kann Image-Dateien nicht direkt einbinden? Hier die Lösung:

  1. Auslesen der Partitionen und ihrer Startsektoren:
    fdisk -l ${QUELLDATEI}

    (Hier in der Spalte Start nach dem Anfang der Partition suchen, unter Units steht die Größe der Sektoren)

  2. Einbinden der gewählten Partition:
    mount ${QUELLDATEI} /mnt -o offset=$((${ANFANGSSEKTOR}*${SEKTORGRÖßE}
  3. Und fertig!

 

Probleme mit Windows Update KB3033929 (SHA2 Einführung)

Auch bei meinem Desktop hat KB3033929 zu Problemen geführt. Windows 7 befindet sich auf der ersten Festplatte, Linux auf der zweiten. Natürlich wird Grub zum Booten verwendet. Leider befand sich kein Windows Boot Loader mehr auf keiner der beiden Platten.

Woher bekommt man jetzt wieder ein direkt bootfähiges Windows 7?

  1. Die meisten Webseiten empfehlen die Windows 7 Installations Medien zu verwenden um das System zu reparieren. Gut, müsste man suchen und die richtigen Medien erwischen. Meine war „inkompatibel“.
  2. Diverse Linux-Tools wie install-mbr führten auch nicht zum Erfolg.
  3. Zum Glück konnte ich das Windows noch starten und das Programm EasyBCD installieren. Wie auf der Hersteller Web-Seite beschrieben, kann das Tool einen Windows 7 MBR schreiben.

Nach dem Anwenden von EasyBCD kann das Windows wieder nativ von der ersten Festplatte gestartet werden und ebenso von der zweiten Festplatte via Grub.

Problem gelöst!

UUID für Device direkt abfragen

UUIDs werden unter Linux verwendet um Partition eindeutig zu identifizieren. Klassischerweise dient das Kommando blkid zum Abfragen der entsprechenden Information:

/dev/sda1: UUID="612adf0a-1780-ad4c-3fb6-082ee5593158" TYPE="linux_raid_member" 
/dev/sda2: UUID="950bb587-ea1d-4dbf-bd6f-7c9d1c234175" TYPE="swap"              
/dev/sda3: UUID="313669c6-3d82-132e-3fb6-082ee5593158" TYPE="linux_raid_member" 
/dev/sdb1: UUID="612adf0a-1780-ad4c-3fb6-082ee5593158" TYPE="linux_raid_member" 
/dev/sdb2: UUID="bd6fa3c7-37cc-455e-acea-0aaa1fb44290" TYPE="swap"              
/dev/sdb3: UUID="313669c6-3d82-132e-3fb6-082ee5593158" TYPE="linux_raid_member"

Will man nun zu einem Device nun nur die UUID abfragen, so hilft folgendes Kommando:

blkid -o value -s UUID /dev/sdb1

Dabei wird lediglich die UUID ausgegeben:

612adf0a-1780-ad4c-3fb6-082ee5593158

Somit kann man in Skripten problemlos mit UUIDs arbeiten.

nmon: Einschränken auf ausgewählte Festplatten bzw. Partitionen

nmon is bei der Anzeige von Festplattendaten nicht wählerisch und zeigt (zumindest unter Linux, AIX war grade nicht zur Hand ;) ) jeweils Daten zur Gesamtplatte (z.B.  /dev/sda) als auch zu einzelnen Partitionen (z.B. /dev/sda1 und /dev/sda3) an. Soweit ist das kein Problem, nur summiert nmon die einzelnen Werte auf, was zu unsinnig hohen Werten führt, wenn in der Summe sowohl die Festplatte als auch einzelne Partitionen summiert werden.

Nun gilt es also nmon auf ausgewählte Festplatten oder einzelne Partitionen zu beschränken. Das Handbuch (nmon -h) ergibt:

-g <filename> User Defined Disk Groups [hit g to show them]
 - file = on each line: group_name <disks list> space separated
 - like: database sdb sdc sdd sde
 - upto 64 disk groups, 512 disks per line
 - disks can appear more than once and in many groups

Also sieht eine entsprechende Datei für meinen Fall (3 Festplatten, jeweils eine relevante Partition) so aus:

Data1 sda3
Data2 sdb1
Data3 sdc1

Wie in der Hilfe beschrieben, wird nmon nun mit der Datei als Parameter gestartet:

nmon -g disks.dat

Anschließend zeigt nmon nach Druck auf ‚g‚ die entsprechenden Statistiken an.

SuperGRUB2Disk: Booten eines USB-Stick über CD-Rom

Folgendes Szenario/Problem stellte sich:

  • Laptop bzw. Rechner
  • das BIOS erkennt (theoretisch) USB Festplatten/Sticks
  • das Booten von USB wurde per BIOS gesperrt
  • das Booten von CD-Rom ist noch erlaubt

Man kann sich nun zu recht fragen, warum ist booten von CD-Rom noch erlaubt? Das bleibt ein Geheimnis des Besitzers des Rechners.

Die Frage ist nun, kann man diese Einschränkung umgehen? Wenn ja, wie?

Die Antwort lautet: Es kann gehen. USB Festplatten/Sticks dürfen nicht ganz deaktiviert sein, sie müssen zumindest erkannt werden (d.h. sie tauchen nicht im Boot-Menu des Rechners auf). Mit Hilfe der SuperGRUB2Disk und deren Funktion „Detect any OS“ kann man das Betriebsystem (bevorzugt Linux) auf der USB Festplatte erkennen lassen und dieses Starten.

Voilà, booten von USB mit einem kleinen Umweg. Sicher nicht im Sinne des Besitzers, aber manchmal hilfreich für Notfälle wie Datenrettungen, etc.