Posts on [ENC]BladeXP's Blog

Das richtige Partitionierungsprogramm

Thu, 21 Feb 2019 21:04:15 +0000

Vor längerer Zeit hatte ich das große Vergnügen mich mit den verschiedenen Linux Partitionierungstools zu beschäftigen. Die getestete Auswahl beschränkte sich dabei auf:

GNU Parted
fdisk
gdisk

Und bevor gefragt wird: Alle Versionen waren auf dem aktuellen Stand, Arch Linux sei Dank. Generell lässt sich die Erkenntnis aus diesem Artikel aber auch auf andere Distributionen oder Versionen übertragen.

Ausgangslage

Es wurden die Daten von einer SSD mit 256GB auf eine mit 250GB kopiert, das Dateisystem wurde vorher natürlich entsprechend verkleinert, sodass alle nützlichen Daten auch zur neuen Plattengröße passen.

Kurzfassung:

sudo -i
e2fsck -f /dev/sda3
resize2fs /dev/sda3 200G
dd if=/dev/sda of=/dev/sdb

Der naive Ansatz war jetzt einfach die Zielplatte bei der Partitionierung etwas anzupassen, doch hier hatten die unterschiedlichen Partitionierungsprogramme verschiedene Meinungen.

fdisk

Der erste Versuch war fdisk, dieser ging ordentlich in die Hose. Denn bedingt durch GPT wurde nur eine pseudo Partition erkannt, welche die komplette Platte umfasst.

An dieser Stelle möchte ich erwähnen: Das gute alte fdisk ist mittlerweile ein gefährliches Werkzeug geworden, es kann mit GPT Partitionstabellen die man heute (denkt hier an UEFI) oft vorfindet, nicht richtig umgehen. Wer hier an dem was er damit findet, rumspielt gefährdet somit seine Daten. Je nach fdisk Version kann das Ergebnis hier sehr unterschiedlich ausfallen.

Achtung: Auch cfdisk ist hier keine gute Idee, also Finger weg von Tools, die kein GPT kennen oder damit nicht richtig umgehen können.

parted

Auch parted wollte mit der Kopie der Platte nicht wirklich arbeiten, denn natürlich ging die GPT der alten Platte von einer anderen Plattengröße aus. Das brachte parted, welches ja als Allround Tool konzipiert ist, durcheinander.

gdisk

Das, wenn auch altmodische, da sehr fdisk ähnlich, gdisk macht seinen Job wie gewünscht. Unter Angabe der richtigen Zielplatte aufgerufen hat es sofort erkannt, was Sache ist. Konkret passte die GPT-Größe nicht mehr zur Plattengröße und die letzte Partition ragte etwas über das Ende der Platte hinaus.

Beides konnte gut behoben werden, anschließend die Änderungen speichern und alles ist wieder gut.

Fazit

Wer heute partitioniert, will mindestens parted, da dort zumindest (manchmal auch nur theoretisch) die Chance besteht, eine Partitionstabelle unabhängig vom Typ zu bearbeiten. Es fällt nicht sofort bei GPT auf die Nase und ist dank diverser Frontends recht frustrationsfrei benutzbar. Es lohnt sich bei Problemen mit der Partitionierung auch mal einen Blick auf andere Tools zu riskieren, vor allem wenn einem die Ausgabe komisch vorkommt.

Abgesehen davon warnt parted auch sehr brauchbar vor Partition misalignment, was für die Performance gerade bei SSDs sehr hilfreich ist.

Zuletzt gilt das alte Leitmotto: Das richtige Werkzeug für die richtige Arbeit, wer also GPT verwenden möchte, nimmt dafür auch bevorzugt gdisk, das spart Ärger, Zeit und rettet im Zweifelsfall deine Daten ;)

U2F in Firefox 57 aktivieren

Tue, 28 Nov 2017 18:57:53 +0000

Die aktuelle Firefox Version (57/Quantum) kann, sofern aktiviert, auch mit dem beliebten U2F Standard umgehen.

Was ist U2F?

U2F ist ein Standard zur Anbindung eines zweiten Faktors (2FA) zur Authentifizierung gegenüber von Webanwendungen und Diensten, für viele eine beliebte Alternative zum Google Authenticator. Der Vorteil ist, das selbst bei bekanntem Benutzernamen und Passwort, ohne den zusätzlichen Faktor, ein Login und Missbrauch eines Dienstes ausgeschlossen ist. Vor allem für zentrale Dienste wie E-Mail oder dem Online Banking ist dies sehr wichtig, wobei gegenwärtig vor allem typische Nerd Dienste 2FA unterstützen. Das Prinzip von 2FA ist, das zum Login sowohl Wissen (Benutzername/Passwort) als auch Besitz (USB Dongle) notwendig sind.

U2F in Firefox aktivieren

Die Firefox Unterstützung für U2F muss gegenwärtig über about:config aktiviert werden, und zwar indem der Schlüssel security.webauth.u2f auf den Wert true gestellt wird. Ist dies erledigt funktioniert zumindest beim Test über die Yubico Demo Seite, sowohl die Registrierung als auch die spätere Anmeldung ohne Probleme. Ich gehe stark davon aus, das im Laufe der nächsten Firefox Versionen das manuelle aktivieren der U2F Unterstützung entfällt.

Aktuelle Probleme

Leider gibt es noch einige Seiten, vor allem von Google, welche U2F zwar offiziell unterstützen, diese Unterstützung jedoch auf bestimmte Browser (Chrome) limitieren. Hintergrund ist, dass diese Seiten prüfen, welcher Client verwendet wird, anstatt wie technisch korrekt zu prüfen, ob der Client bestimmte Features bereitstellt.

Das größte Problem ist aber die nach wie vor geringe Verbreitung von U2F oder 2FA im allgemeinen, vor allem die meisten deutschen Banken befinden sich hier noch in der Steinzeit. Allerdings ist die Branche auch erst damit beschäftigt die Sache mit der Digitalisierung zu lernen, in 5-10 Jahren klappt es dann auch mit der sicheren Authentifizierung ;)

Strom sparen mit udev und hdparm

Sat, 18 Feb 2017 10:00:00 +0000

Für meine Datensicherungen nutze ich ausschließlich Platten vom Typ Western Digital Green, oder wie in Technikforen immer liebevoll Ökoplatten genannt. Diese werden per Wechselrahmen in das System eingebunden und regelmäßig rotiert um die Sicherungen auf verschiedene Datenträger zu verteilen. Die Platten werden nur für wenig Betriebszeit pro Tag wirklich benötigt, eben immer dann, wenn eine neue Sicherung zu erstellen ist. Aus diesem Grund fahren die Platten automatisch nach 20 Minuten in den Standby Betrieb. Gemäß Spezifikation benötigt dieser Typ Platten dann lediglich 0,4 Watt statt 2,5 Watt Leistung.

Eine einfache, und sehr dynamische Lösung, ist durch udev möglich. Man prüft, welcher Typ ein Datenträger ist, und stellt dementsprechend das Energiemanagement eben dieser Platte passend ein. Hierzu legt man die Datei /etc/udev/rules.d/50-wdgreen-hdparm.rules mit folgendem Inhalt an:

ACTION=="add|change", KERNEL=="sd*", ATTRS{model}=="WDC WD10EZRX*" RUN+="/usr/bin/hdparm -S 240 /dev/%k"

Durch den Befehl sudo udevadm control --reload lädt udev seine Regeln neu. Ab dem nächsten Plattentausch werden die Regeln dann automatisch angewendet.

Der Trick ist hierbei wirklich den Typ der Festplatte zu verwenden, man möchte ja nicht versehentlich die Platten aus seinem RAID ständig in den Standby schicken. Den für mein ständig verfügbares Datengrab verwende ich ausschließlich Platten, die auch 24/7 tauglich sind, für welche ein ständiger Wechsel zwischen Standby und Normalbetrieb als schädlich sein könnte.

Der genaue Typ einer Festplatten kann per udevadm info --query=all --attribute-walk --name=/dev/sdd | grep model ermittelt werden. Bevorzugt kürzt man die Typenbezeichnung etwas ein, um verschiedene Chargen des gleichen Typs mit zuvor genannter Regel zu treffen. In meinem Beispiel wurde so WDC WD10EZRX-00L auf WDC WD10EZRX* gekürzt.

borgbackup: LZMA, ZLIB und LZ4 im Vergleich

Sat, 12 Nov 2016 16:07:22 +0000

Seit einigen Wochen experimentiere ich mit Borg Backup als mögliche Lösung für mein neues, privates, Backup Konzept. Die Ziele dieses Konzeptes würden den geplanten Umfang dieses Artikels sprengen, ich möchte an dieser Stelle daher nur auf einen älteren Artikel von mir zum Thema Datensicherung verweisen.

Im Zuge der Planung für dieses neue Konzept habe ich verschiedene Backup Programme getestet und anschließend rein subjektiv bewertet. Neben einer möglichst einfachen Benutzbarkeit war es mir auch wichtig, möglichst effektiv an meine gesicherten Daten zu kommen und gleichzeitig gut mit inkrementellen Sicherungen arbeiten zu können.

Ohne die Alternativen zu erwähnen, war Borg Backup das Resultat meiner "Forschungsarbeit", es vereint die Möglichkeiten der Kompression, Deduplizierung als auch Verschlüsselung in einem Tool, zusätzlich ist es möglich, ältere Datenstände per FUSE Dateisystem direkt verfügbar zu machen.

Sobald man sich für ein Backup Programm/Tool entschieden hat, geht es jedoch schon an dessen Konfiguration. Ein wesentlicher Aspekt, ist hierbei das verdichten von Daten mittels Kompression, und der sich daraus ergebende Gewinn an Speicherplatz unter Einsatz wertvoller CPU Zyklen. CPU Zyklen kosten Geld, bedingt durch die dafür nötige Energie. Je nach verbautem Prozessor, im für die Datensicherung notwendigen Rechner, wird Wärme erzeugt und Energie beim Energieversorger verrechnet.

Doch nicht nur die ökologischen und wirtschaftlichen Gesichtspunkte sollte man beachten, sondern auch das ein größerer Zeitverbrauch auch bedeutet das die Sicherungszyklen länger werden müssen. Als Referenz dient hierbei die Zeit, welche erforderlich ist, eine inkrementelle Sicherung zu erzeugen. Dauert es 2 Stunden die 500 GiB zu sichernden Daten auf Änderungen zu prüfen, diese zu komprimieren und anschließend zu sichern, dann kann minimal alle 2 Stunden eine neue Sicherung erzeugt werden.

Lange Sicherungszyklen führen dabei automatisch zu einem Zeitfenster in welchem ungesicherte Änderungen im Schadensfall verloren gehen. Die beiden Ziele, eine möglichst gute Kompression zu erreichen, und gleichzeitig möglichst schnell zu sichern, stehen also im Widerspruch. Bei den heute erzielbaren Preisen für zusätzlichen Speicherplatz (€/TB) ist es eine Überlegung wert nicht bestmöglich, sondern stattdessen so gut wie nötig, zu komprimieren.

Zuletzt bestehen unsere heute verfügbaren und sehr großzügig bemessenen Datenmengen auch primär aus Daten, die sich schlecht bis kaum komprimieren lassen. Wer eine große Musik und Filme Sammlung sein eigen nennt, kann hiervon sicherlich ein Lied singen.

Nach all diesen, hier zumindest grob dargestellten Überlegungen, stellte sich mir die Frage aller Fragen: Wie groß ist der Zeit und Platz Unterschied für die von Borg Backup unterstützten Kompressionsmöglichkeiten? Aktuell bietet Borg Backup folgende Möglichkeiten:

Keine Kompression
LZ4
ZLIB
LZMA

Da es sich bei meinem Testsystem um den Homeserver handelt, schwankte die zu sichernde Datenmenge mit jeweils +/- 10 GiB pro Testlauf. Der Einfluss hiervon auf das Gesamtergebnis ist aber deutlich niedriger als erwartet. Hier kurz und schmerzlos die Ergebnisse im Überblick:

Name: 2016-11-02_17:17:43
Fingerprint: e1a2cf764b5e8f1f024507ec1a9149ffa547583c72e56e0ff0c47c95304be368
Hostname: server
Username: root
Time (start): Wed, 2016-11-02 17:17:43
Time (end):   Wed, 2016-11-02 21:54:29
Command line: /usr/bin/borg create --lock-wait 3600 -s -C none /mnt/backup/monthly::{now:%Y-%m-%d_%H:%M:%S} …
Number of files: 244822

                       Original size      Compressed size    Deduplicated size
This archive:              532.15 GB            532.15 GB            501.53 GB
All archives:              532.15 GB            532.15 GB            501.53 GB

                       Unique chunks         Total chunks
Chunk index:                  407311               442322

Name: 2016-10-29_20:22:10
Fingerprint: 19e4c5ada051047065cefad817022a72fe6e3dc24bde1ead47c4080fe41749c8
Hostname: server
Username: root
Time (start): Sat, 2016-10-29 20:22:10
Time (end):   Sun, 2016-10-30 01:03:44
Command line: /usr/bin/borg create -s -C lz4 /mnt/backup/weekly::{now:%Y-%m-%d_%H:%M:%S} …
Number of files: 249949

                       Original size      Compressed size    Deduplicated size
This archive:              540.24 GB            533.61 GB            503.59 GB
All archives:              540.24 GB            533.61 GB            503.59 GB

                       Unique chunks         Total chunks
Chunk index:                  414894               450402

Name: 2016-10-30_13:00:22
Fingerprint: da644b0301e9bcc76ecafa5b221ff3382d0525725a6a502b951d466eb433fadb
Hostname: server
Username: root
Time (start): Sun, 2016-10-30 13:00:22
Time (end):   Sun, 2016-10-30 22:58:35
Command line: /usr/bin/borg create --lock-wait 3600 -s -C zlib,9 /mnt/backup/monthly::{now:%Y-%m-%d_%H:%M:%S} …
Number of files: 249302

                       Original size      Compressed size    Deduplicated size
This archive:              530.58 GB            515.89 GB            486.54 GB
All archives:              530.58 GB            515.89 GB            486.54 GB

                       Unique chunks         Total chunks
Chunk index:                  410586               446084

Name: 2016-10-31_18:00:11
Fingerprint: 4e0678501bf551fa57458f9762aacb1c2ee13380a18f1612cf930e786fb93061
Hostname: server
Username: root
Time (start): Mon, 2016-10-31 18:00:11
Time (end):   Wed, 2016-11-02 13:28:34
Command line: /usr/bin/borg create --lock-wait 3600 -s -C lzma,9 /mnt/backup/monthly::{now:%Y-%m-%d_%H:%M:%S} …
Number of files: 244775

                       Original size      Compressed size    Deduplicated size
This archive:              532.14 GB            514.07 GB            485.11 GB
All archives:              532.14 GB            514.07 GB            485.11 GB

                       Unique chunks         Total chunks
Chunk index:                  407571               442572

Lässt man diese Ergebnisse etwas auf sich wirken, kommt man auf folgendes Ergebnis:

Keine Kompression dauert ca. 16606 Sekunden bei 532.15GB zu 501.53GB
LZ4 Kompression dauert ca. 16894 Sekunden bei 540.24GB zu 503.59GB
ZLIB Kompression dauert ca. 35893 Sekunden bei 530.58GB zu 486.54GB
LZMA Kompression dauert ca. 70103 Sekunden bei 532.14GB zu 485.11GB

Die Zeiten hier noch als Tabelle, für den schnellen Vergleich:

Kompression	Zeit (Sekunden/Minuten/Stunden)	Zeit (Differenz)	Original vs. Compressed Size
Keine	16606 / 276 / 4.61	-	-
LZ4	16894 / 281 / 4.69	+1.73%	-1.23%
ZLIB	35893 / 598 / 9.97	+116.14%	-2.77%
LZMA	70103 / 1168 / 19.47	+322.16%	-3.4%

Zu beachten ist, dass ich in der zuerst aufgeführten Liste die Größe inkl. Deduplizierung als Referenz genommen habe, in der Tabelle aber tatsächlich nur die Kompression als solches. Deduplizierung brachte unabhängig von der Kompression ca. 6% an Platz ein, was jede der getesteten Kompressionsmöglichkeiten schlägt.

Meine Empfehlung lautet daher LZ4 als Kompression zu benutzen und sich mit dem Rest erst nicht zu beschäftigen, eine Ausnahme dürften Personen sein, deren Daten weitgehend aus komprimierbaren Inhalten bestehen, also z.B. lokale Kopien der Wikipedia oder Quelltext von Programmen. Beim durchschnittlichen Anwender dürfen jedoch Mediendaten der größte Teil der genutzten Datenmenge sein, welche sich eben nur sehr schlecht weiter komprimieren lassen.

Disk Images platzsparend archivieren

Sat, 12 Nov 2016 15:00:00 +0000

Windows ist bei mir vor allem ein Zweitsystem, es dient für Steam zum Spielen und für Lightroom um meine Fotos zu bearbeiten. Das alte Windows 7 wollte seinerzeit durch Windows 10 ersetzt werden, denn der aktuelle PC soll noch länger genutzt werden als es der Service für Windows 7 gestattet.

Ein wichtiger Aspekt für große Veränderungen an einem System ist natürlich das Backup, während die Mediendaten, welche ich nutze entweder auf dem Homeserver liegen (Fotos) oder aus der Cloud kommen (Steam) ist das Betriebssystem als solches bei mir nicht im Backupkonzept vorgesehen. Zu groß der Platzverbrauch, zu gering der Profit.

Die einfachste Möglichkeit eine komplette Festplatte 1:1 zu sichern ist ein Disk Image, doch dafür benötigt man Platz mit der gleichen Größe, wie die Quelle von welcher man ein solches erstellen möchte. Die Nutzung einer Festplatte ist aber in der Regel kleiner, meist sogar deutlich, als die tatsächlich vorhandene Kapazität eben dieser. Die Idee ist daher mit möglichst geringem Aufwand, möglichst viel Platz zu sparen.

Windows verkleinern

Zuerst kann man, sofern Windows auf der Quelle ist, die Auslagerungsdateien und die Hibernation Files zu deaktivieren, das allein spart in der Regel schon deutlich Platz. Der nächste Schritt ist die obligatorische und großzügige Datenträgerbereinigung mit dem gleichnamigen Tool.

Jetzt kommt das Wichtigste: Das überschreiben der nicht vom Betriebssystem benötigen Blöcke im Dateisystem mit nullen. Der Hintergrund liegt in der Struktur moderner Betriebssysteme versteckt, den dort werden Dateien und dementsprechend auch Blöcke auf dem Datenträger, nicht mehr gelöscht, sondern lediglich als frei markiert. Ein Verhalten, das gut für die Geschwindigkeit und eventuell erforderliche Wiederherstellungsmaßnahmen ist, aber sehr schlecht um davon ein Image zu machen.

Um zuvor genanntes Problem zu umgehen, kann man sich das Tool sdelete herunterladen, und anschließend in einer Befehlszeile mit Administratorrechten ausführen: sdelete.exe -z c:. Dieser Prozess dauert je nach Geschwindigkeit des zugrunde liegenden Datenträgers etwas. Nach Abschluss sollte man das Betriebssystem herunterfahren und in sein Lieblingslinux booten.

Möglichkeiten

In meinem Fall waren nach dieser Aktion noch ca. 96GiB Nutzdaten (inkl. Betriebssystem) vorhanden, auf einem Datenträger mit einer Kapazität von 250GB. Die Frage, die sich mir nun stellte, war, wie viel Platz benötige ich tatsächlich um die Bruttodatenmenge, also die Kapazität vom Datenträger, als Image zu sichern. Zur Auswahl standen für mich dabei 2 Verfahren:

Sparse File
Komprimiert, mittels LZO

Nun stelle sich für mich die alles entscheidende Frage: Was ist der Größen und Zeitunterschied zwischen Sparse File mit dd_rescue und lzop?

Sparse File

Mit dem Befehl dd_rescue -a -d -b 32M /dev/sdb sdb_backup.img erzeugte ich zuvor genanntes Sparse File, basierend auf dem Block Device /dev/sdb. Der gesamte Vorgang dauert bei meinem System 9 Minuten und 12 Sekunden, je nach Kombination aus HDD/SSD dauert dies mehr oder weniger lang. Das Ergebnis ist eine Datei die zwar mit 239GiB angegeben ist, aber nur 145 GiB auf dem Datenträger verbraucht:

[root@pc2007:/srv] 21s $ ls -l -h -s
145G -rw-r----- 1 root   root  239G 17. Jun 16:53 sdb_backup.img

LZO Compression

Der nächste Versuch war es mittels lzop < /dev/sdb > sdb_backup.image.lzo ein LZO Komprimiertes Images zu erzeugen. Dieses mal dauerte der Vorgang 10 Minuten und 7 Sekunden, ein marginaler Unterschied, wenn man bedenkt, dass noch eine Kompression der Daten durchgeführt wird. Das Ergebnis in diesem Fall ist eine Datei welche 107 GiB groß ist, also ca. 26% weniger Platz im Vergleich zum Sparse File benötigt:

[stefan:~] 10m32s $ ls -l -h -s /srv/sdb_backup.image.lzo 
107G -rw-r--r-- 1 root root 107G 17. Jun 17:17 /srv/sdb_backup.image.lzo

Fazit

Als kurzes Fazit lässt sich sagen das sich die Kompression mit lzop bewährt hat, vor allem weil ein derartiges Image auch auf Dateisysteme kopiert werden kann, die nicht Sparse fähig sind. Für mein neu geplantes Backup Konzept werde ich einen weiteren Blick auf die Kompression mittels LZO und LZ4 werfen, doch dazu später mehr. Mit anderen Kompressionsmöglichkeiten kann zweifelsfrei eine noch kleinere Datei (Image) erzeugt werden, der Zeitaufwand darf hierbei jedoch nicht unterschätzt werden.

Auswirkung der mkinitcpio Kompression

Fri, 28 Oct 2016 12:07:13 +0000

Schon länger war es etwas still in diesem Blog, diese stille möchte ich nun vertreiben und regelmäßig neue Beiträge für die digitale Nachwelt erstellen. Den Anfang soll hierbei ein kleines Experiment aus Dezember 2015 machen.

Konkret geht es um die Auswirkung der unterschiedlichen Kompressionsmöglichkeiten von mkinitcpio unter Arch Linux, die Ergebnisse sind aber auch auf andere Distributionen wie Debian, Ubuntu oder Fedora anwendbar. Die Idee ist es die Initial Ramdisk vom Linux Kernel so klein wie möglich zu bekommen, gleichzeitig aber auch die dafür erforderliche Zeit zu berücksichtigen.

Bei den angegebenen Zeiten wurde jeweils gemessen wie lange mkinitcpio -P benötigt um sowohl die Standard als auch die Fallback Ramdisk zu generieren, wir reden hier also immer von der Kompressionszeit. Die Zeit, welche für die Dekompression beim Systemstart erforderlich ist, wurde nicht explizit gemessen, erfahrungsgemäß liegen diese unabhängig vom verwendeten Algorithmus bei unter einer Sekunde.

Kompression	Fallback (MiB)	Standard (MiB)	Zeit (s)	Prozent (%)
none	80	40	18.021	100
gzip	27	14	19.787	34
bzip2	25	13	38.675	32
lzma	18	8.4	67.259	22
xz	18	8.4	65.069	22
lzop	38	20	13.152	48
lz4	39	20	8.670	49

Addiert man die Größe, der unkomprimierten Fallback und Standard Ramdisk, kommt man auf 120 MiB, was so auch die 100% Marke in der Tabelle definiert. Wie unschwer zu erkennen ist steht none für keine Kompression.

Nachfolgend möchte ich die Ergebnisse meines Tests basierend auf meiner Erfahrung erläutern:

none: Man würde erwarten, dass keine Kompression am schnellsten ist, dies ist jedoch ein Trugschluss. Zwar wird keine Zeit für eine Kompression benötigt, im Gegenzug aber die Zeit für Plattenzugriffe drastisch erhöht. Ich würde aus diesem Grund davon abraten unkomprimierte Ramdisks zu verwenden.
gzip: Der alte Freund gzip erreicht brauchbare 14 MiB für die typischerweise genutzte Ramdisk, was ca. 20 Sekunden dauert. Wie erwartet gibt es hier keine großen Überraschungen. Insgesamt benötigen wir somit 41 MiB. Vorteil von gzip ist das bis auf wenige Ausnahmen wohl jede Linux Distribution damit umgehen kann.
bzip2: Auch bzip2 ist ein guter alter Freund, der jedoch in diesem Beispiel keine gute Wahl gewesen ist. Insgesamt benötigen wir damit ca. 38 MiB, also lediglich 3 MiB weniger bezogen auf gzip. Gleichzeitig benötigen wir für dieses geringe Ersparnis an Plattenplatz fast doppelt so viel Zeit, und das bei jedem Kernel Upgrade.
lzma / xz: Sowohl xz als auch lzma gelten als gute Kompressionsmöglichkeiten, benötigen dafür aber auch überdurchschnittliche Lange. Da die Kompression unverhältnismäßig lange dauert, würde ich vom Einsatz dieser für derartige Zwecke abraten.
lzop: Durch btrfs hat LZO, und damit auch lzop an Beliebtheit gewonnen. Der Ansatz ist es Daten möglichst CPU schonenden zu komprimieren und dadurch das Nadelöhr Disk-IO / Festplatte zu entlasten. Die Rechnung geht bei modernen Prozessoren voll auf, in der Regel ist die zusätzliche Belastung durch lzo kaum der Rede wert. Immerhin werden noch über 50% des Platzes eingespart, was für diese Anwendung ein brauchbares Ergebnis ist.
lz4: Das in letzter Zeit zunehmend beliebtere lz4 ist eine Art lzop mit Heckspoiler und Ralleystreifen, die Kompressionsraten sind in der Regel marginal schlechter, die Geschwindigkeit jedoch deutlich höher.

Für mich ist lz4 die Kompression der Wahl für die Initial Ramdisks, eine Ausnahme bilden Systeme auf denen /boot zu klein ist, dort dann je nach Verfügbarkeit xz oder lzma. Bei den heute verfügbaren Systemen mit schnellen HDDs oder SSDs spielt es keine wesentliche Rolle mehr, ob eine Datei 10 oder 20 MiB groß ist, die Zeit welche eine Kompression oder Dekompression benötigt jedoch schon. Insbesondere bei Arch Linux gibt es öfters neue Kernel Versionen, dort stets über eine Minute auf die Kompression zu warten ist in meinen Augen nicht Verhältnismäßig. Hohe Kompressionsraten sollte man wählen, wenn Platz und Bandbreite knapp ist, in anderen Fällen kann man pauschal lz4 oder lzop auf das Problem werfen ohne sich groß sorgen über die Konsequenzen machen zu müssen.

Der Artikel erläutert bewusst nicht genau, wie man die verwendete Kompression umstellt, die unterstützten Kompressionsmöglichkeiten unterscheiden sich je nach Kernel Version und Distribution erheblich, eine falsche Auswahl führt sofort zu einem nicht mehr startenden System. Die oben genannten Ergebnisse wurden Ende 2015 ermittelt, die ermittelten Zeiten und Dateigrößen sind also nur als Richtwert zu verstehen.

Defekte Festplatten im Linux Software RAID ersetzen

Sun, 06 Sep 2015 09:00:00 +0000

In einer idealisierten Welt würden Festplatten nicht ausfallen, aber in der Realität müssen wir damit Leben das von Menschen geschaffene Dinge auch mal kaputt gehen. Ärgerlich ist dies vor allem bei Datenträgern, um hier einen Ausfall zu kompensieren werden auch im SOHO-Bereich zunehmend RAID-Systeme verbaut. Eine gerne verwendete Lösung ist hierbei das in Linux integrierte Software-RAID, es ist zuverlässig und erfordert keinerlei spezielle (und damit teure) Hardware.

Vorwort

Um ein RAID mit einer oder mehreren defekten Platten wieder in den gewünschten redundanten Status zu bekommen sind bestimmte Aktionen erforderlich, diese möchte ich nachfolgend erklären. Wie bei allen Operationen am laufenden System sollte man aber vorher sicherstellen das ausreichend aktuelle und funktionierende Backups vorhanden sind. Wer die nachfolgenden Operationen nicht aus dem bestehenden System heraus ausführen möchte, kann dafür auch eine der vielen Rescue Systeme nehmen, je nach Distribution und verwendeter Hardware kann dies sogar erforderlich sein. Der Vorteil eines Rescue Systems ist das man nicht auf die Bootfähigkeit seines Systems angewiesen ist, um nachträglich noch Korrekturen durchführen zu können.

RAID Status

Den Status eines RAIDs können wir mittels cat /proc/mdstat prüfen:

Personalities : [raid1] 
md0 : active raid1 sdc1[0] sda1[2]
      976628736 blocks super 1.1 [2/2] [UU]
      bitmap: 2/8 pages [8KB], 65536KB chunk

unused devices: <none>

Auf meinem Homeserver ist natürlich alles bestens, wenn eine Platte ausgefallen wäre, würde man in der dritten Zeile statt [UU] ein [U_] oder [_U] sehen, eine ausgefallene Platte wird durch ein _ dargestellt. Wie viele Festplatten ausfallen dürfen, hängt vom verwendeten RAID-Level ab.

Neben dem offensichtlichen Ausfall einer Platte gibt es aber auch noch den schleichenden Tod, dazu zählen z.B. auch die S.M.A.R.T. Werte und Selbsttests einer Festplatte. Gefallen einem die Werte seiner Festplatte nicht mehr kann man diese manuell auf den failed Status setzen:

mdadm /dev/mdX --fail /dev/alt1

Defekte Platten aus dem Verbund entfernen

Im Anschluss können alle Festplatten mit diesem Status aus dem Verbund entfernt werden:

mdadm /dev/mdX --remove failed

Defekte Platte tauschen

Im nächsten Schritt muss die defekte Festplatte aus dem System entfernt werden (physikalisch), dies geht einfach, wenn ein Wechselrahmen mit LEDs vorhanden ist. In diesem Fall genügt es einfach etwas Aktivität auf dem RAID zu erzeugen, die defekte Festplatte ist diejenige, bei welcher die Aktivitäts-LED unbeeindruckt bleibt.

Schwerer wird es, wenn kein derartiger Wechselrahmen vorhanden ist, den dort hilft es oft nur durch smartctl -i /dev/alt1 die Seriennummer der Platte auszulesen und mit dem Aufdrucken auf der Platte zu vergleichen. Wer etwas Feingefühl hat, kann auch mit den Fingern die Platten bei Aktivität erfühlen, eine inaktive Platte brummt gleichmäßig vor sich hin, eine aktive Platte vibriert passend zur ausgeführten Aktion. In jedem Fall sollte es vermieden werden den Server auszuschalten, den nicht jede Distribution fährt mit einem unvollständigen RAID wieder hoch.

Wurde die alte Platte entfernt, kann die neue Platte an das System angeschlossen werden, hierzu genügt zur Not auch ein externes USB-Gehäuse. Eleganter ist natürlich wieder der Wechselrahmen, schneller als USB geht zur Not auch das öffnen des Gehäuses und direktes anschließen der Platte an das Mainboard und Netzteil, zumindest sofern noch ein SATA-Anschluss vorhanden ist.

Partitionierung

Der nächste Schritt ist es die frisch eingebaute Platte mit einer Partitionstabelle zu versehen, da wir faul sind, lassen wir dies natürlich automatisch durch geeignete Tools erledigen:

# MBR/BIOS Partitionstabellen:
sfdisk -d /dev/master | sfdisk /dev/neu
# GPT/UEFI Partitionstabellen:
sgdisk -R /dev/neu /dev/master
sgdisk -G /dev/neu

Im oben genannten Codeblock ist /dev/master eine Platte mit passender Partitionierung, da bei einem RAID meist alle Platten gleich Partitioniert sind, kann jede aus dem Verbund als Master genommen werden. Die Festplatte /dev/neu ist die neue Festplatte. Zu beachten ist natürlich auch, ob GPT oder MBR für die Paritionstabellen verwendet wird.

RAID wiederherstellen

Wenn die Partitionstabellen passend sind, kann man die neue Platte auch schon dem vorhanden RAID-Verbund hinzufügen:

mdadm /dev/mdX --add /dev/neu1

Damit wären alle Arbeiten erledigt, das RAID führt nun einen sog resync durch, das bedeutet, die neue Platte wird mit den Daten bespielt und im Anschluss wäre unser RAID auch wieder redundant. Der resync kann mittels cat /proc/mdstat beobachtet werden. Wenn auf der ausgefallenen Platte auch ein Bootloader installiert war, sollte dieser auch wieder installiert werden, was je nach Bootloader unterschiedlich funktioniert und außerhalb des Umfangs dieses Artikels ist.

Automount der GNOME Shell deaktivieren

Sat, 15 Aug 2015 11:09:42 +0000

Das automatische einhängen von Datenträgern war mir schon immer ein Dorn im Auge. Insbesondere wenn man des Öfteren Datenträger zur Datenrettung benutzt, ist jeder unnötige Prozess zu vermeiden. Bei meinem Lieblingsdesktop, der GNOME Shell, kann dieser Automount mit folgender Zeile in einem Terminal deaktiviert werden:

$ gsettings set org.gnome.desktop.media-handling automount false

Willkommen zurück im Firefox deaktivieren

Wed, 15 Jul 2015 19:20:22 +0000

Firefox verfügt seit Version 25 über eine Funktion die es dem Anwender ermöglicht wieder ein frisches Firefox Profil zu erstellen. Diese sollte normalerweise nur aktiv werden wenn Firefox länger als 60 Tage nicht mehr genutzt wird. Bemerkbar macht sich diese Funktion durch folgende Meldung:

It looks like you haven't started Firefox in a while. Do you want to clean it up for a fresh, like-new experience? And by the way, welcome back!

In der deutschen Fassung natürlich:

Sie haben Firefox lange nicht mehr genutzt. Soll jetzt aufgeräumt werden, damit Sie ein Benutzerlebnis wie am ersten Tag erfahren? Übrigens, willkommen zurück!

Gelegentlich wird diese Meldung aber auch angezeigt, wenn man den Browser täglich benutzt, Abhilfe schafft es hierbei die Variable browser.disableResetPrompt mit dem Wert True zu erstellen. Hierzu einfach about:config in die Adresszeile tippen und dort mit der rechten Maustaste einen neuen Eintrag vom Typ Boolean mit oben genanntem Namen und Wert erstellen. Bei zukünftigen Starts vom Firefox unterbleibt so diese Meldung.

Die Meldung ist übrigens nicht nur rein optisch ein Problem, sie löscht auch wenn man nicht aufpasst, das aktuelle Profil und man darf mit der Konfiguration wieder von vorne Anfangen.

Platz auf der SSD mit Windows sparen

Thu, 16 Apr 2015 18:23:33 +0000

Egal ob in einer virtuellen Maschine oder noch auf richtiger Hardware, Windows gönnt sich mit den Standardeinstellungen von Microsoft ordentlich Platz auf der Platte. Problematisch wird dies bei richtiger Hardware, denn SSDs sind noch relativ teuer, aber auch als virtuelle Maschine verfügt der Host in der Regel nicht über unbegrenzte Ressourcen.

Mit den Standardeinstellungen gibt es zwei große Dateien auf dem Laufwerk C, diese wären:

hiberfil.sys
pagefile.sys

Diese beiden Dateien können selbst vom Administrator nicht gelöscht werden, was auch sinnvoll erscheint, wenn man weiß, für was diese Dateien gut sind. Nachfolgend eine kleine Erklärung aus leichter Linux Perspektive und natürlich eine Möglichkeit sich dieser beiden Dateien zu entledigen.

SWAP deaktivieren/verkleinern

Beide Dateien entsprechend grob dem unter Linux bekannten Swap, sind also Auslagerungsspeicher, welcher genutzt wird, wenn entweder kein RAM mehr im System frei ist, oder der Kernel den RAM lieber für sinnvollere Dinge verwenden würde. Beide Dateien sind in der Regel so groß wie der installierte Arbeitsspeicher, bei den hier installierten 32GB also zusammen 64GB. Auf einer 1TB Festplatte spielt dies keine große Rolle, auf einer 256GB SSD schon.

Der erste Schritt sollte auf jeden Fall sein den Auslagerungsspeicher zu verkleinern, dies wäre die Datei pagefile.sys. Je nach Arbeitsspeicher kann man auf diesen sehr langsamen RAM Ersatz vollständig verzichten, oder zumindest diesen auf 2-4GB begrenzen. Wird die Auslagerungsdatei regelmäßig und viel genutzt, sollte man sich ohnehin mehr Gedanken um mehr RAM machen 😉

Um diese Einstellungen zu verändern, muss man zuerst den Eintrag System in der Systemsteuerung öffnen. Anschließend hangelt man sich durch die in Screenshots dokumentierten Dialoge:

Hibernate deaktivieren

Der nächste Schritt führt dazu, dass eine Funktion entfällt: Hibernation. Gemeint ist damit ein Verfahren, das auch Suspend to Disk genannt wird. Das Betriebssystem speichert den aktuellen Inhalt des RAMs in der Datei hiberfil.sys und schaltet dann den Computer aus. Beim nächsten Einschalten wird dieses Image geladen und alles geht an der Stelle weiter, wo zuvor unterbrochen wurde.

Einfacher als das Anpassen der SWAP Einstellungen geht das Deaktivieren der Hibernation. Hierzu muss lediglich in einem Administrator Terminal (cmd.exe mit rechter Maustaste als Administrator ausführen) der Befehl powercfg -h off eingegeben werden.

Bei virtuellen Maschinen ist die Funktion der Hibernation eh äußerst fragwürdig, denn hier kann man den Zustand der Maschine jederzeit von außen einfrieren, ganz ohne Platzverschwendung im Image der virtuellen Maschine.

Auflösung ist nicht gleich Auflösung

Fri, 13 Mar 2015 20:33:57 +0000

Wie groß ist eigentlich ein Pixel? Was wie die Frage eines Kindes klingt, ist selbst für erwachsene nicht einfach zu beantworten. Die richtige Antwort, welche vor allem Juristen freuen dürfte: Das kommt drauf an!

Beispiel

Ein Ordner welcher 14 PNG Dateien mit jeweils 1648x2290 Pixel Auflösung enthält, sollte mit nachfolgendem Befehl in ein PDF umgewandelt werden:

convert Folder/*.png -quality 20 -compress JPEG target.pdf

In den letzten Jahren leistete dieser Befehl stets großartige Arbeit, doch heute war etwas anders. Das Resultat war, dass 2 der 14 Seiten trotz vermeintlich gleichem Format der Quelldaten nur ca. 60% der Größe hatten. Wie ich gut eine Stunde (und 2 Bier) später feststellen durfte, war die Ursache in den Einstellungen meines Scanners zu finden: Die vorhandenen Dateien wurden mit 200 DPI Auflösung gescannt, die heutigen Dateien aber mit 300 DPI (man gönnt sich ja sonst nichts). In den Quelldaten ist die Auflösung des Scanners enthalten, eine Eigenschaft die mein typischer Arbeitsablauf (Bilder anpassen und konvertieren mit GIMP) nicht verändert hat. Durch diese Information in der Quelldatei ging convert davon aus, es müsse die unterschiedlichen Dateien angleichen.

Lösung

Des Rätsels Lösung bestand darin innerhalb von GIMP zu definieren, welche Druckgröße ich gerne haben möchte. Im Menü Bild findet man den im Screenshot sichtbaren Dialog Druckgröße, dort kann direkt die gewünschte Auflösung als DPI Wert (oder auch eine andere für den Zweck passende Einheit) hinterlegt werden. Nach einem erneuten Exportieren der Datei im PNG Format war auch das PDF, welches convert erzeugte, im richtigen Format. Alternativ können auch alle Dateien neu als PNG exportiert werden, wichtig wäre dabei, dass der Haken Auflösung speichern entfernt wird, ich halte den zuerst genannten Weg jedoch für sinnvoller.

Fazit

Wie groß ist jetzt ein Pixel? Das ist immer abhängig vom Zielmedium und dessen Auflösung in Abhängigkeit zur Größe. Eine Grafik mit 640x480 Pixeln Auflösung wirkt auf einem 50" Full-HD TV vergleichsweise klein, auf einem 10 Meter LED Board im Außenbereich (Werbetafel, 1024x768) wirklich groß und an einem 1200-DPI-Drucker geradezu winzig. Indem einer Datei hierzu Informationen auf den Weg gegeben (“Ich wurde mit 300 DPI gescannt.”) kann Software automatisch eine entsprechende Anpassung durchführen.

In meinem Beispiel hat convert festgelegt, dass die erste Seite 1648x2290 Pixel bei 200 DPI hat, die nachfolgenden Seiten werden an diesem Standard angepasst. Meine heute gescannten Seiten hatten 300 DPI, was bedingt, dass diese, um die gleiche Fläche zu füllen, 2472x3435 Pixel haben müssen. Denn ob ich 300 Pixel pro Inch unterbringe oder 200 ist ein wesentlicher Unterschied, es ist also wichtig, Auflösung immer in Relation zur Größe zu setzen.

Rechte von Dateien und Ordnern rekursiv anzeigen

Sat, 07 Mar 2015 15:05:30 +0000

Häufig kommt es vor das man für eine Anwendung, z.B. einem Webserver, aufpassen muss, welche Berechtigungen das Zielobjekt hat. Doch neben den Rechten für das Zielobjekt, also einer Datei oder einem Ordner, sind auch noch die Berechtigungen auf dem Weg zum Ziel innerhalb des Dateisystems relevant.

Ein großartiges Tool um die Berechtigungen vollständig anzuzeigen ist das Tool namei welches auf jeder Linux Distribution installiert ist, denn es ist Bestandteil des Paketes util-linux.

[stefan@hostname:~] namei -l /home/stefan/Documents/Entwicklung/Python/inyoka/development_settings.py
f: /home/stefan/Documents/Entwicklung/Python/inyoka/development_settings.py
drwxr-xr-x root   root  /
drwxr-xr-x root   root  home
drwx------ stefan users stefan
drwxr-xr-x stefan users Documents
drwxr-xr-x stefan users Entwicklung
drwxr-xr-x stefan users Python
drwxr-xr-x stefan users inyoka
-rw-r--r-- stefan users development_settings.py

Im Beispiel ist gut ersichtlich das mit namei -l der komplette Pfad rekursiv aufgelöst wird, für jedes Element werden dabei die jeweiligen Berechtigungen (Benutzer, Gruppe, Rechte) angezeigt. Leider funktioniert dies nur für normale Unix Berechtigungen, ob es ein Tool gibt welches ähnliches auch für Posix ACLs leistet ist mir gegenwärtig nicht bekannt.

Sicheres Heimnetzwerk trotz TR-069

Thu, 26 Feb 2015 09:26:11 +0000

Das beliebte Protokoll TR-069 ermöglicht die Fernkonfiguration und Administration der meisten heute üblichen DSL Router durch den Provider. Auf dem 31c3 wurde auch ausschließlich positiv darüber berichtet. Ein Grund, sich Gedanken zu machen, wie man den Schaden den TR-069 anrichtet, etwas eindämmen kann.

Die von uns verwendeten und liebevoll Plasterouter genannten DSL Endgeräte werden vor allem unter dem Kostenaspekt entwickelt, das Budget welches in die Sicherheit dieser Geräte gesteckt wird, dürfte sehr überschaubar ausfallen. Spürbar wird dies vor allem, da Millionen dieser Geräte mit relativ ähnlicher Software im Einsatz sind, relativ ähnliche Software meint auch vergleichbare Angriffswege. Auch wenn ich in diesem Artikel stets DSL Router schreibe, gemeint sind natürlich auch andere Übertragungswege, das Problem ist also nicht auf DSL als Technologie beschränkt. Je nach Provider ist es aktuell nicht oder nur umständlich möglich an die Internetzugangsdaten zu kommen, für den Laien macht TR-069 also einen hervorragenden Job. Bedingt durch die automatische Konfiguration ist eine Herausgabe dieser Informationen nicht mehr erforderlich, zumindest, bis der Gesetzgeber hier etwas unternimmt. Problematisch ist, wenn man sein Netz nicht in die Hände seines Providers legen will, sondern auch gerne weiterhin der einzige Administrator sein möchte.

Nachfolgend möchte ich eine Lösung für dieses Problem anbieten, ich akzeptiere dabei, dass es TR-069 gibt und verzichte auf eine Aktion mit Fackeln und Mistgabeln. Dabei betrachte ich den heimischen DSL Router als potenziell kompromittiertes Gerät, welches zu umgehen ist. Der Vorteil meiner Lösung ist auch, dass man ohne großartige Umkonfiguration den Provider wechseln kann, an der heimischen Vernetzung ist nur noch der DSL-Router durch einen beliebigen anderen zu tauschen.

Aufbau

Für mein sicheres Heimnetz habe ich unterschiedliche Anforderungen, einige davon sind:

Administrativen Einfluss des Providers auf meine Geräte verhindern oder zumindest minimieren.
LAN/WLAN für Gäste, ohne die Gefahr für dessen Nutzung haftbar gemacht zu werden.
Providerspezifische Probleme (Youtube vs. Telekom) umgehen. Nach reichlicher Überlegung bin ich dann auf eine Lösung mit mehreren unterschiedlichen Netzen gekommen, es wird also zukünftig folgende Netzwerke geben:
Providernetz
Privates LAN
Gast LAN
Provider Internet
Richtiges Internet

Dass die einzelnen Netze stets durch geeignete Maßnahmen (iptables) voneinander geschützt sind, versteht sich von selbst.

Providernetz

Das Providernetz ist das Netz, welches direkt aus dem DSL Router vom Provider tröpfelt, da hier TR-069 im Spiel ist und billigste Komponenten ohne Rücksicht auf Sicherheit verbaut werden, traue ich diesem Netz nicht weiter als ich ein voll bestücktes Bladecenter werfen kann.

Im Providernetz befinden sich vor allem Geräte, die ohnehin dem Provider gehören, also z.B. Entertain Büchsen und Smart-TVs.

Privates LAN

Mein privates LAN ist ein Netzwerk welches Geräte enthält, die von mir als vertrauenswürdig eingestuft wurden, es handelt sich dabei also primär um PCs, Notebooks oder Drucker. Ob man ein Android, iOS oder Windows Gerät in dieses sensible Netz lässt, muss jeder für sich selbst entscheiden 😉

Dieses Netz hat einen eigenen Router, dieser wird an das Providernetz mit der WAN Seite angeschlossen, vor dem Router meines privaten Netzes ist also das böse Providernetz, hinter diesem meine eigenen Geräte.

Gast LAN

Bedingt durch fehlende flächendeckende kostenlose Hotspots und fragwürdige Tarifstrukturen, wünschen sich viele Besucher ein WLAN um den neuesten Cat Content begutachten zu können. In der einfachsten Variante nimmt man hierfür einfach Freifunk, wodurch auch das Problem mit der Anbieterstörhaftung beseitigt wäre. Das Gast-LAN ist auch mit der WAN Seite an das Providernetz angeschlossen, hat also sinnvollerweise keine Verbindung zu unserem privaten Netz.

Provider Internet

Der ISP (Internet Service Provider) stellt ja als Hauptaufgabe vor allem Internet bereit. Problematisch hierbei sind häufig Verstöße gegen die nicht vorhandene Netzneutralität. Das bekannteste Beispiel sind “zufällige” Probleme bei Google Diensten wie Youtube. Dieses Internet nutzen wir nur ausgehend vom Providernetz, den anderen Netzen spendieren wir richtiges Internet 😉

Richtiges Internet

Richtiges Internet? Durch Tunneln von unserem privaten Netz zu einem (v)Server erreichen wir durch einen kleinen Umweg ein Internet, welches nicht von unserem Provider beeinflusst wird. Für diesen haben wir nur 1-2 ausgehende VPN Verbindungen am Laufen, der Rest geht durch den Tunnel und verlässt diesen erst am VPN Endpoint. Unser Gast-LAN geht auch durch einen Tunnel, bei Freifunk ist das dank der aktuellen Rechtssprechung Standard.

Aufbau als Bild

Da ein Bild oft mehr sagt als 1000 Worte:

Für einen Picasso wird es wohl nicht reichen, aber ich hoffe man kann grob meine Idee nachvollziehen.

Vorteile

Durch diesen Aufbau hat der Provider nur noch Zugriff auf den DSL-Router sowie Geräte im Providernetz, die Gäste, als auch meine privaten Geräte bleiben davon isoliert. Für “problematische Gäste” entfällt eine Haftung, wer weiß, welche Virenschleudern kreative Dinge im Internet machen 😉

Mit dem Providernetz ist auch sichergestellt, dass von diesem bereitgestelltes Equipment wie Media Receiver (Entertain) auch einfach funktioniert, im Support Fall kann direkt die Hotline angerufen werden und man muss nicht erst 2 Stunden dem netten Sachbearbeiter erklären, dass ein Problem mit dem Routing nicht auf einen alternativ verwendeten Router zurückzuführen ist.

Bisher problematische Dienste werden zukünftig funktionieren, da die Beschränkungen des Providers nicht mehr greifen. Der typische Telekom Kunde darf sich über ruckelfreies Youtube HD freuen 😉

Nachteile

Der komplexe Aufbau dürfte vor allem Laien überfordern, ich sehe diese aber auch nicht als Zielgruppe für ein solches Setup. Ein weiteres Problem ist der deutlich höhere Hardware Einsatz (3 Router statt einer) und damit verbunden höhere Energieverbrauch. Neben den etwas höheren Kosten für diesen Energieverbrauch müssen auch die Anschaffungskosten für die zusätzlichen Router bedacht werden, eventuell reichen im Haus vorhandene Datendosen nicht mehr aus und man muss welche nachträglich installieren oder kreativ VPNs im eigenen Haus über das Providernetz schalten.

Fazit

Mein eigenes LAN wird im Laufe des Jahres auf dieses Setup umgestellt, sollten sich dabei nützliche Erfahrungen oder notwendige Korrekturen ergeben werde ich natürlich wieder berichten.

Löschen von Partitionen und Volumes

Thu, 26 Feb 2015 08:10:00 +0000

Eine häufig getroffene Fehleinschätzung vieler Anwender ist es, das durch Entfernen von Partitionen oder Volumes (LVM), auch die darauf enthaltenen Daten gelöscht werden. Es handelt sich dabei um einen Trugschluss, denn durch diese Schritte werden nur Metadaten, also Verwaltungsinformationen, verändert oder bestenfalls gelöscht. Die Nutzdaten, also der Inhalt bleibt vollständig erhalten.

Partitionierung mit GPT oder altmodisch

Bei klassischen HDDs oder der klassischen Partitionierung (GPT oder MS-DOS Partitionstabellen ist hierbei egal) muss hier Hand angelegt werden: Freigegebener Platz muss vor der Freigabe überschrieben werden. Dies kann am einfachsten mit dd erledigt werden:

dd if=/dev/zero of=/dev/sda2

Das funktioniert allerdings nur dann zuverlässig, wenn eine komplette Partition (oder Volume) gelöscht werden soll, wird eine Partition (oder Volume) verkleinert darf nur dieser Bereich überschrieben werden. Zuvor muss aber das Dateisystem an die neue Zielgröße angepasst werden. Folgende Schritte müssen also durchgeführt werden:

Unmounten des Dateisystems. Ausgenommen bei Dateisystemen welche auch Online verkleinert werden können, dies ist z.B. bei btrfs der Fall.
Verkleinern des Dateisystems, häufig ist zuvor noch eine Prüfung des Dateisystems mit fsck sinnvoll oder sogar erforderlich.
Löschen der nicht mehr erforderlichen Bereiche, diese müssen ermittelt werden und dd mittels Offset (Option seek) mitgeteilt werden.
Verkleinern der Partition bzw. des Volumes.
Mounten des Dateisystems.

Da es sich bei dieser Aktion um eine größere Änderung am Datenbestand handelt, wäre ein aktuelles aber ohnehin vorhandenes Backup sinnvoll ;)

Problematisch ist hier zum einen der Zeitaufwand, zum anderen auch der Einsatz menschlicher kognitiver Kapazität. Eine Kombination, die schon Petabyte an Daten vernichtet hat! Unseren Auszubildenden rate ich immer bei der Durchführung von Arbeiten möglichst nicht zu denken, überspitzt ist damit gemeint, dass wohlüberlegte Denkprozesse in der Vorbereitung, spätere Überraschungen bei der Durchführung auf ein Minimum reduzieren.

LVM und SSD

Wer sowohl LVM als auch Solid State Drives (SSD) im Einsatz hat, ist hier klar im Vorteil, denn TRIM kann alle anfallenden Arbeiten automatisch und zuverlässig übernehmen. Einzige Bedingungen ist es die Option issue_discards der /etc/lvm/lvm.conf zu aktivieren. Durch diese Änderung werden nicht nur TRIM/DISCARD Anweisungen beim Löschen innerhalb des Dateisystems (mount Option oder manuell mittels fstrim) erzeugt, sondern auch wenn Bereiche innerhalb der Volume Group wieder frei werden.

LUKS

Eine praktische Eigenschaft von Verschlüsselung ist es, auf dem Datenträger nur einen großen Haufen Datenmüll zu hinterlassen, einzig der LUKS-Header und die Partitionstabelle enthält unverschlüsselt lesbare Daten. Eine Sonderbehandlung beim Löschen von Volumes ist also nicht zwingend erforderlich.

Sicherheit vorinstallierter Software

Wed, 25 Feb 2015 13:33:11 +0000

Auf den meisten Geräten wie Smartphones, Tablets, Notebooks oder den verbleibenden klassischen PCs, sind im Auslieferungszustand meist sehr viele Programme vom Hersteller vorinstalliert. Die Hersteller bekommen für viele dieser Programme (auf neumodischen Geräten auch Apps genannt) Geld vom jeweiligen Softwarehersteller, nur ein kleiner Teil wird installiert um die Funktionalität des Gerätes zu "verbessern". Der primäre Nutzen dieser Programme dient also dem wichtigsten Unternehmensziel: Der Gewinnmaximierung. Der Nutzen aus Kundensicht ist oft nicht vorhanden oder zumindest nicht nachvollziehbar.

Spätestens seit Superfish, wissen wir das es Hersteller hierbei übertreiben. Was für den Laien nur eine lästige Beigabe darstellt, ist für den Administrator oder Angreifer ein offenes Scheunentor. Es werden Modifikationen an wichtigen Systemkomponenten vorgenommen, wodurch grundlegende Sicherheitskonzepte ausgehebelt, ersetzt oder empfindlich geschwächt werden.

Moderne Betriebssysteme, wozu selbst Windows gehört, gelten als relativ sicher. Voraussetzung sind natürlich die jeweils aktuellen Updates, welche ein verantwortungsbewusster Systemadministrator zeitnah installiert hat. Viele Dinge sind heute Standard, dazugehört z.B. Reduzierung der verfügbaren Dienste über die Netzwerkschnittstelle oder Maßnahmen um administrative Rechte einzuschränken (sudo unter Linux, User Account Control unter Windows). Zusätzliche Maßnahmen um sein System abzusichern würden den Rahmen des Artikels sprengen, aber die heutigen Systeme haben nachweißlich ein besseres Sicherheitsniveau als noch 2001 ;)

Sicherheitsprobleme vorinstallierter Software lassen sich verschieden klassifizieren, eine mögliche Aufteilung hierbei:

Dienst läuft mit administrativen Rechten, selbsterklärend ohne diese zu benötigen.
Dienst lauscht an den Netzwerkschnittstellen, die vorhandene Firewall wurde hierfür natürlich "angepasst".
Programm macht keine automatischen Updates.
Programm modifiziert die Liste "vertrauenswürdiger" CAs (Certificate Authority).

Je länger man darüber nachdenkt, desto mehr mögliche Kategorien gibt es. Die oben genannt dürften aber die Wichtigsten und damit am problematischsten sein. Ich werde nachfolgend kurz auf die jeweiligen Kategorien eingehen.

Dienste als Administrator laufen zu lassen ist einfach und hat den Vorteil, dass man sich nicht mit dem jeweiligen Berechtigungssystem des Betriebssystems beschäftigen muss. Aus Perspektive eines Angreifers sind Dienste die als Administrator laufen besonders lohnenswerte Ziele, in Kombination mit einer vorhandenen Lücke gibt es kaum einen Weg einfacher (unbemerkt) an administrative Rechte zu kommen. Der Administrator entscheidet was auf einem System passiert, bekommt man durch einen fragwürdig konstruierten Dienst an diese Rechte übernimmt man diese Möglichkeit.

An Netzwerkschnittstellen lauschen, also Dienste im Netzwerk bereitstellen, wird gerne von vielen automatischen Konfigurationstools für Drucker oder andere Netzwerkgeräte genommen. Ein normalerweise von außen nicht oder nur schwer erreichbares System bietet mir so, die Möglichkeit einen Zugang zum System zu erhalten. Läuft der Dienst zusätzlich noch als Administrator, haben wir ein offenes Scheunentor, Premium Style.

Dienste und Anwendungen die keine automatischen Updates aktiviert haben, müssen vom Anwender manuell aktualisiert werden. Das klingt je nach Betriebssystem (z.B. Linux) trivial, kann aber zu mehrstündigen Update Sessions (z.B. Windows) führen. Der einfache SOHO-Anwender ist hiervon meist überfordert und verzichtet auf diesen Aufwand. Ob dies am Unwissen liegt oder Absicht ist, muss jeder selbst entscheiden, es dürfte in der Regel wohl eine Kombination aus beidem sein. Problematisch ist, dass nicht aktualisierte Anwendungen auch nicht von Sicherheitsupdates profitieren, geschlossene Sicherheitslücken bleiben also bis in alle Ewigkeit vorhanden und nutzbar.

Neben diesen sehr offensichtlichen und nachvollziehbaren Problemen gibt es aber auch noch die Option einfach an der Liste "vertrauenswürdiger" CAs zu spielen. Die meisten Anwendungen welche mit TLS (früher SSL) umgehen können haben eine Liste dieser Zertifizierungsanstalten. Eine CA prüft mehr oder weniger aufwendig ob der Inhaber einer Domain brauchbare Informationen über seine Identität liefert, es wird nicht geprüft ob dieser wirklich vertrauenswürdig ist! Die Anwendung kennt also viele dieser CAs, die CAs wiederum "kennen" den Betreiber der Seite. Die Konsequenz aus dieser ganzen Aktion ist, dass der Browser keine Fehlermeldung beim Verbindungsaufbau anzeigt und ein kleines Schlosssymbol signalisiert, das alles bestens sei.

Durch Modifikation dieser Liste, in der Regel werden zusätzliche CAs eingetragen, kann erreicht werden, dass verschlüsselte Verbindungen gebrochen werden. Es handelt sich dabei um einen Man-in-the-Middle-Angriff, wobei der böse Mann (oder Frau) in der Mitte, plötzlich unser eigener PC ist. Unsere Anwendung, z.B. Firefox oder der Internet Explorer, signalisieren uns das alles funktioniert. In Wirklichkeit haben wir nur eine "brauchbar" verschlüsselte Verbindung bis zum fragwürdigerweise vorinstallierten Tool des Herstellers, erst dieses Tool baut die "korrekt" verschlüsselte Verbindung zum Zielsystem auf.

Problematisch ist hierbei das Dienste/Programme wie Superfish hierbei äußerst schlampig vorgehen und die Zertifikate nicht korrekt überprüfen. Der Browser bzw. die Anwendung zeigt also keine Probleme an, obwohl wir ein ungültiges Zertifikat bekommen haben. Dieses ungültige Zertifikat hat jedoch nie unseren Browser (Anwendung) erreicht, wir leben in trügerischer Sicherheit während jemand gemütlich unsere Informationen mitlesen kann. Wenn man jetzt noch darüber nachdenkt, dass der Hersteller des Gerätes diese fragwürdige Software nur aus Werbezwecken vorinstalliert hat, könnte einem dabei richtig schlecht werden ;)

Es wäre falsch das Problem jetzt ausschließlich bei Lenovo zu suchen, es handelt sich meiner Meinung nach um ein Problem, welches in der Branche grundsätzlich vorhanden ist. Seitens der Industrie erwarte ich hier auch keine Lösung, ich selbst werde bei meiner bisherigen Lösung bleiben: Neu gekaufte Geräte werden von einem potenziell sauberen Installationsmedium frisch installiert.

Ein Nachteil meiner Lösung ist das sich dies nicht auf alle Geräte anwenden lässt, Techniken wie SecureBoot oder vernagelte Bootloader an Smartphones und Tablets nehmen mir zunehmend die Freiheit mit meinem Gerät zu machen, was ich als Kunde möchte. Die Gefahr die Herstellergarantie zu verlieren ist allgegenwärtig, einzig der Gesetzgeber könnte, wenn er den wollte, hier eine Lösung erzielen.

Die schuldigen im Fall MongoDB

Tue, 10 Feb 2015 12:30:30 +0000

Über offene Firmendatenbanken wird gerade von heise online und einigen anderen Medien berichtet. Hintergrund sind MongoDB Installationen, welche (weitgehend) die Standardkonfiguration verwendet und öffentlich über das Internet erreichbar sind.

Meiner Ansicht nach gibt es für dieses Problem drei Personengruppen, welche in unterschiedlichem Ausmaß hierfür verantwortlich sind. Auf diese möchte ich nachfolgend, zumindest grob, eingehen.

Administratoren

Administratoren von IT Systemen sind zuständig für die Wartung und Inbetriebnahme von Computersystemen, was sowohl Hardware als auch Software umfasst. Organisationen erwarten das ein Administrator IT Systeme so betreut, dass die Ziele der Organisation nicht gefährdet werden. Aus diesem einfachen Grundsatz lassen sich Themen wie Datenschutz, Ausfallsicherheit und einige andere herleiten.

Ein Administrator, welcher eine Software öffentlich zugänglich macht handelt, meiner Ansicht nach grob fahrlässig, und damit gegen die Ziele der eigenen Organisation. Zumindest unter Ubuntu ist MongoDB nämlich nicht öffentlich erreichbar, dies muss erst manuell über eine Konfigurationsänderung aktiviert werden.

Ausgenommen von dieser Regel sind natürlich Dienste, welche öffentlich erreichbar sein müssen, hierzu gehört zum Beispiel der Webserver oder ein Mailserver. Doch bei diesen Diensten gehört eine zusätzliche Absicherung gegen Angriffe zum Aufgabenfeld des Administrators.

Distributoren

Distributoren übernehmen die Aufgabe Software für den Anwender (Administratoren sind auch nur Anwender, alles eine Frage per Perspektive) bereitzustellen. Auf diese Art ist nicht jeder Computerbesitzer darauf angewiesen, sein komplettes Betriebssystem aus den Quellen der Entwickler händisch zu bauen.

Einige Distributionen gehen schon länger dazu über, dem Anwender auch weitere Aufgaben abzunehmen. Eine dieser zusätzlichen Aufgaben ist das Standardmäßige aktivieren von installierten Diensten, etwas das ich nach wie vor für grundsätzlich falsch halte. Jeder aktive Dienst erhöht die Angriffsfläche für ein System, wie stark ist abhängig vom jeweiligen Dienst.

In meinem Blog habe ich hierzu schon 2012 etwas geschrieben. Ich stehe nach wie vor zu den damals getätigten Aussagen.

Entwickler

Die letzte, aber nicht weniger wichtige, Gruppe bilden die Entwickler einer Software. Diese Treffen wichtige Entscheidungen über die Sicherheit einer Software, z.B. ob Verschlüsselung und Authentifizierung im Standard aktiv oder überhaupt deaktivierbar sind.

Ich bin der Überzeugung, dass es falsch ist, Software anzubieten, welche ohne Verschlüsselung und Authentifizierung auskommt. Bei vielen Anwendern und Administratoren siegt viel zu oft die Bequemlichkeit, Sicherheit kommt erst an zweiter Stelle oder wird nachgelagert erledigt, wenn gerade jemand (der Azubi?) etwas Zeit übrig hat.

Eine Standardmäßige aktive und nicht deaktivierbare Authentifizierung hätte das aktuelle MongoDB Problem zumindest entschärft, was an der ein oder anderen Stelle sicherlich viele Millionen Kundendaten "gerettet" hätte.

Entwickler sollten auch sonst in ihrer Konfiguration von einem sicheren Setup als Standard ausgehen, d.h. Benutzerwechsel im Service, Erreichbarkeit nur über localhost und dergleichen.

tl;dr

Machen wir es kurz:

Administratoren sollten genau Aufpassen was installiert wird, und wie es geeignet gegen Angriffe oder unerlaubte Zugriffe zu schützen ist.
Distributoren sollten endlich damit aufhören Dienste im Standard zu aktivieren, zumindest eine kleine Nachfrage bei der Installation kann wirklich nicht zu viel verlangt sein.
Entwickler sollten standardmäßig auf Verschlüsselung und Authentifizierung setzen, eine Option zum deaktivieren sollte entfernt werden.

Natürlich lösen diese wenigen (aber effektiven) Maßnahmen nicht alle Probleme, ein ungeübter Benutzer (um es mal neutral zu formulieren) wird immer Mittel und Wege finden, etwas unsicher zu machen. Der Standard sollte es aber sein, Dinge in einem sicheren Zustand auszuliefern.

Linux Software-RAID Metadaten

Tue, 14 Oct 2014 17:40:45 +0000

Linux Software-RAID ist eine gerne verwendete Lösung, um auf die schnelle ein RAID System an dem einen oder anderem Server zu realisieren. In den meisten Fällen funktioniert dies auch einfach so, doch lästige moderne Systeme haben durch zunehmend dynamischere Hardware (USB, SATA, …) und stetige Verbesserungen am Init Prozess (z.B. Upstart, systemd) ein großartiges Potential sich bei der beliebten Kombination RAID und LVM in den Fuß zu schießen.

Doch auch andere Kombinationen sind möglich, genau genommen jede Option, bei welcher eine Anwendung oder ein Systembestandteil pauschal alle Block Devices nach einem bestimmten Header durchsucht. Auf einem RAID System können genau diese Header, in exakt gleicher Form, nämlich auf mehreren Block Devices zur gleichen Zeit vorhanden sein. Problematisch ist dies vor allem bei RAID1, aber ich gehe davon aus das auch andere RAID-Level hier Probleme bereiten könnten.

Um das Problem zu verstehen, muss man dessen Ursache kennen, daher ein kleiner Überblick über die gängigen RAID Metadatenversionen:

0.90: Dabei handelt es sich um das nach wie vor oft verwendete, aber inoffiziell als PITA bezeichnete Metadatenversion. Limitierungen sind u.a. maximal 2TB bei einem RAID-Level größer oder gleich 1 und zusätzlich die Limitierung auf maximal 28 Geräte im Verbund, welche weniger problematisch sein sollte. Dummerweise ist bei dieser Metadatenversion je nach Partitionierung auch nicht definiert ob sich ein RAID Verbund über die gesamte Platte oder nur einen Teil davon (Partition) erstreckt.
1.0: Das neue Metadatenformat, hier liegt der RAID Header genauso wie beim 0.90er Format am Ende der Partition/Platte. Die Bugs aus 0.90 wurden hierbei gefixt und es gibt auch einen Satz neue Features welche in der Manpage erläutert werden.
1.1: Wie 1.0, jedoch liegt der RAID Header hier nicht am Ende, sondern am Anfang einer Partition/Platte.
1.2: Wie 1.0, jedoch liegt der RAID Header hier nicht am Ende der Platte/Partition, sondern 4KB nach dem Startsektor derselben.

Das PITA (0.90) Format möchten wir wirklich nicht mehr einsetzen, aber die anderen Versionen klingen doch sehr verlockend. Aufpassen muss man hier aber bei der Wahl der Version, den einzig 1.1 sorgt dafür das am Anfang der Partition der RAID Header ist. Dadurch erkennen die meisten Tools welche ihre Header ebenfalls am Start der Partition/Platte erwarten dort keinen eigenen Header mehr und kommen nicht auf die blöde Idee diesen zu verwenden.

Durch eine ungünstige Situation (z.B. eine Race Condition) kann es z.B. beim Startvorgang vorkommen das so /dev/sda1 in eine LVM Volume Group aufgenommen wird obwohl nur wenig später das richtige Block Device, nämlich /dev/md0 zu Verfügung stehen würde. Der Schutz durch das RAID besteht so ggf. nicht, im schlimmsten Fall überschreiben sich das Software-RAID und LVM gegenseitig die Daten, ein großartiges Szenario.

Beobachten konnte ich das recht theoretische Problem bisher 2-3x auf meinem Homeserver, durch viele Schutzmaßnahmen ist aber nichts passiert, mal davon abgesehen das die gängige LVM Befehle auf einmal jammerten, dass keine PVs verfügbar wären, obwohl das System schon seit Wochen stabil läuft. Beobachten konnte ich ebenfalls das dieses Problem nur auftritt wenn der lvmetad verwendet wird, dies ist z.B. bei Arch Linux der Fall. Ich gehe auch davon aus das dieses LVM spezifische Problem eher dort zu suchen ist, unabhängig davon gibt es neben LVM noch einige andere Dinge die gerne mal Metadaten am Anfang der Partition/Platte suchen, durch die Wahl der richtigen Metadatenversion können hier schon beim erstellen des RAIDs potentielle Probleme vermieden werden.

Be A Sheep

Sat, 04 Oct 2014 13:05:45 +0000

Keine Angst, ich werde jetzt nicht Anfangen mit Fremdsprachen in meinem Blog zu experimentieren. Aber ich möchte gerne etwas auf Be a Sheep eingehen, natürlich aus technischer Sicht, von Biologie habe ich zu wenig Ahnung.

Jens hat im Forum von ubuntuusers.de ein paar tolle Ansätze in einem ausgezeichneten Beitrag erläutert. Der Themenersteller hatte hier einige, teilweise berechtigte, Bedenken wegen Maßnahmen zum Fingerprinting einiger Kommunikationsanbieter.

Einen Fingerabdruck kennen wir, egal ob neuer Personalausweis, Reisepass oder eine Ermittlung der Polizei. Als Steigerung gibt es noch den genetischen Fingerabdruck, dieser wird auf Basis unseres einmaligen genetischen Profils erstellt. Doch beide Varianten des Fingerabdrucks sind auch mit möglichen Fehlern belastet, beim genetischen Fingerabdruck kann es sich z.B. um einen Zwilling handeln oder um den Patienten einer Knochenmarkstransplantation. Die oft geforderten 100% Sicherheit gibt es auch mit diesem Verfahren nicht.

Für viele gilt eine IP-Adresse als Fingerabdruck, eine Spur, die an jedem "Tatort" hinterlassen wird und unweigerlich auf meine Person schließen lässt. Doch in Wahrheit kann man mit einer IP-Adresse bestenfalls den Eigentümer eines Gerätes, in der Regel sogar nur den Anschlussinhaber, ermitteln. Zusätzlich ändern sich in Zeiten von Zwangstrennung (IPv4), NAT (IPv4) und Privacy Extensions (IPv6) diese Adressen auch ständig. Eine IP-Adresse ist damit nach heutigem Standard für viele Anwendungen ungeeignet, wobei hier Gerichtsurteile oft noch an der technisch bedingten Realität scheitern.

Zusätzlich zur IP-Adresse generiert bzw. versendet unsere moderne Software, meist der Browser unserer Wahl, viele weitere Informationen. Dazu gehören unter anderem bevorzugte Sprachen, installierte Plugins, Betriebssystem und natürlich die jeweiligen Versionsinformationen. Als Sahnehäubchen gibt es noch einen ordentlich Satz Cookies, DOM Storage und Flash Supercookies. Je mehr und genauer Informationen durch meine Software versendet werden, desto besser kann ich zweifelsfrei von der breiten, mehr oder weniger anonymen, Masse unterschieden werden. Die meisten dieser Informationen sind unabhängig von einer IP-Adresse, niemand arbeitet gerne mit sich ständig verändernden Informationen. Mit einem Login beim Dienst unserer Wahl können all diese Informationen definitiv mit einer bestimmten Person, genauer einem Account, verknüpft werden.

Doch nur sehr große Anbieter, wie Facebook, Twitter oder Google, sind in der Lage durch eine sehr breit angelegte Datensammlung und ständige Nutzung brauchbare Informationen und Verknüpfungen zu erzeugen. Die breite Masse der Dienste ist zu klein und unbedeutend, was die Quantität und Qualität der entstandenen Profile schmälert. Allgegenwärtige Like Buttons und omnipräsente Werbenetzwerke der wenigen großen Provider ermöglichen eine gigantische Datensammlung.

Durch eine intelligente Kombination aus Firefox und den teilweise umstrittenen Addons Adblock Plus und Ghostery wird unser Profil weniger umfangreich und aussagekräftig ausfallen. Je unschärfer unser Profil wird, desto mehr Schaf sind wird auch. Und wir alle wissen, dass nur die Schwarzen Schafe in der Masse auffallen.

Auf der anderen Seite muss man aber auch aufpassen nicht durch zu viel Individualisierung ein neues, vielleicht sogar noch besseres, Profil zu erstellen. Hier ist ein wenig gesunder Menschenverstand gefragt, den es geht hier primär um Werbenetzwerke und nicht um Geheimdienste.

Zum Abschluss noch ein paar kleine Hinweise, wie man ein besseres Schaf bzw. unbrauchbareres Profil wird:

Nutze Firefox als Browser, andere verfügen zwar oft über Adblock Implementierungen aber nur selten über eine wirksame API, um vor Cookies zu schützen.
Adblock Plus, Adblock Edge, oder von mir aus auch eine andere Implementierung eines Werbeblockers sollte bis auf sehr wenige Ausnahmen stets aktiv sein.
Ghostery hilft gegen Zählpixel und gängige Cookies, wichtig ist hier ein automatische Library Update, um auch gegen neue Maßnahmen wirkungsvoll geschützt zu werden.
Informationen die nicht in dein normales Profil einfließen sollten gehört in den Private Mode vom Browser, den was mit dem Private Mode passiert, bleibt auch dort ;)
Nutze, falls möglich, die Suchmaschine der Seite und nicht eine externe Suche wie Google. Natürlich ist eine site:domain.tld bla Suche bei Google sehr bequem, aber zusätzlich zum Anbieter (z.B. Amazon) informierst du hier auch Google über dein neues Hobby.

Mit diesen, wenigen, Tipps wird dein Profil bei den meisten Anbietern deutlich weniger aussagekräftig. Für die Netzwerke bist du nur noch einer dieser vielen Menschen die Adblock liegen und Cookies hassen, aber nur noch nach einem aktiven Login bei den großen Diensten auch ein identifizierbares Individuum. Zum Abschluss möchte ich noch darum, bitten den oben verlinkten Beitrag von Jens auch vollständig durchzulesen.

Umstieg auf systemd-networkd und systemd-timesyncd

Fri, 29 Aug 2014 17:18:21 +0000

Seit Version 210 enthält systemd einen Dienst systemd-networkd für die Konfiguration von Netzwerkschnittstellen, zusätzlich gibt es seit Version 213 mit systemd-timesyncd auch einen einfachen NTP Client. Durch diese beiden Dienste wird die distributionsspezifische Netzwerkkonfiguration langfristig standardisiert.

Zum jetzigen Zeitpunkt bin ich auf meinen Clients, welche DHCP verwenden, auf die beiden neuen Dienste umgestiegen. Als Vorbereitung ist es ratsam dem DHCP Server die Option für den gewünschten NTP Server mit auf den Weg zu geben, so kann eine Anpassung der NTP Konfiguration auf allen Clients ausbleiben. Als Nächstes erstellen wir eine Konfigurationsdatei für unsere Netzwerkschnittstelle enp3s0 mit dem Dateinamen /etc/systemd/network/enp3s0.network:

[Match]
Name=enp3s0

[Network]
DHCP=yes

Durch diese Konfiguration erreichen wir das die oben genannte Netzwerkschnittstelle durch DHCP konfiguriert werden soll. Jetzt können die alten Dienste deaktiviert, und die neuen aktiviert werden:

netctl disable main
systemctl disable ntpd
systemctl enable systemd-networkd
systemctl enable systemd-timesyncd

Wenn es Dienste gibt, welche direkt beim Bootvorgang eine funktionierende Netzwerkverbindung benötigen, wie z.B. NFS oder CIFS Freigaben, kann noch zusätzlich der Service systemd-networkd-wait-online aktiviert werden.

systemctl enable systemd-networkd-wait-online

Nach einem Neustart des Systems läuft die Netzwerkkonfiguration über systemd, weiterführende Informationen zu den beiden neuen Diensten können den jeweiligen Manpages entnommen werden. Ich gehe davon aus das diese in den nächsten Versionen noch deutlich ausgebaut werden, z.b. um auch exotischere Anwendungsfälle abzudecken.

SSD am alten Desktop als Tuning Maßnahme

Sat, 09 Aug 2014 16:38:26 +0000

Erst neulich habe ich das alte Notebook meiner Freundin mit etwas RAM und einer SSD in einen für heutige Verhältnisse angemessenen Arbeitszustand überführt. Diese Woche hat mir S.M.A.R.T. verraten, das auch die Festplatte am Desktop demnächst in den Ruhestand möchte. Aufgefallen ist dies primär durch eine stark gesunkene Performance bei Schreibzugriffen und sporadischen Problemen beim Bootvorgang. Hintergrund war das reorganisieren von Sektoren auf der Festplatte, was bei mechanischen/magnetischen Festplatten ordentlich was ausmacht.

Der mittlerweile ca. 6 Jahre alte Desktop tut abgesehen von der langsamen Festplatte aber noch einen guten Job. Es wäre daher nur wenig wirtschaftlich einen neuen PC zu beschaffen, welcher ohnehin nur für Office Tätigkeiten verwendet wird. Statt eines neuen PCs gab es also eine SSD (Plextor M5S 256GB) und leckeren 4GB RAM um Firefox und LibreOffice ohne Swap Partition zu befriedigen.

Vor dem Hardwareupdate ergaben sich folgende Werte für systemd-analyze bzw. hdparm -t /dev/sda:

Startup finished in 5.311s (kernel) + 39.187s (userspace) = 44.498s
Timing O_DIRECT disk reads: 376 MB in  3.00 seconds = 125.21 MB/sec

Nach dem Einbau der neuen Komponenten gibt es folgende Werte:

Startup finished in 4.703s (kernel) + 3.836s (userspace) = 8.539s
Timing O_DIRECT disk reads: 764 MB in  3.00 seconds = 254.45 MB/sec

Die Migration des Linux Systems auf den neuen, etwas kleineren, Datenträger war recht problemlos möglich. Windows macht hier seine typischen Zicken und war auch nach mehreren Versuchen nicht zum booten zu bewegen, eine Neuinstallation und die damit Verbundene nervenaufreibende Update Orgie waren die Folge.

Da alle von mir betreute Installationen LVM verwenden, bestand die Migration von Linux im Grund aus dem Kopieren und neu installieren vom Bootloader und dem anschließenden verschieben der Daten mittels LVM:

sudo -i
parted /dev/sdb # Partitionen anlegen wie erforderlich
umount /boot
dd if=/dev/sda2 of=/dev/sdb2 # Altes /boot kopieren
e2fsck -f /dev/sdb2 # Dateisystem prüfen
resize2fs /dev/sdb2 # dateisystem an Partition anpassen
mount /dev/sdb2 /boot # Manueller mount, da sdb ja sda wird nach Ausbau
grub-install /dev/sdb # GRUB neu installieren
pvcreate /dev/sdb3 # sdb3 als PV initialisieren
vgextend main /dev/sdb3 # VG um neues PV erweitern
pvmove /dev/sda3 # LVM nötigen das alte PV zu räumen
vgreduce main /dev/sdb3 # VG um altes PV erleichtern

Wie schon beim Asus B50A hat sich auch am alten Desktop das Update auf eine schnellere Festplatte und etwas mehr RAM ordentlich gelohnt. Zumindest die nächsten 3-4 Jahre sollte damit erst mal wieder Ruhe sein, dann wird doch mal ein neuer PC nötig ;)

Homeserver Upgrade

Thu, 03 Jul 2014 18:30:00 +0000

Die letzten Jahre hatte ich verschiedene Homeserver im Einsatz, der Erste war ein Flepo Alpha, welcher aber schon ca. 2010 durch einen leistungsfähigeren Atom ersetzt wurde. Durch ein neues Backupkonzept, welches ich hier demnächst vorstellen möchte, ist aber deutlich mehr Leistung erforderlich. Konkret geht es dabei um die Unterstützung von AES-NI durch die CPU, denn meine Daten sollen auch in den eigenen vier Wänden zukünftig nur noch verschlüsselt vorhanden sein.

AES-NI

Lange Zeit war diese CPU-Erweiterung nur den Intel Core i7 Prozessoren vorbehalten, welche für einen Homeserver meist zu teuer und ineffizient (Energie!) sind. Seit einiger Zeit gibt es jedoch Prozessoren aus der Intel Core i3 Serie, wie z.B. den Intel Core i3 4130T, welche ebenfalls AES-NI unterstützen. Moderne Intel (und wohl auch AMD) Prozessoren unterstützen dabei schon seit einiger Zeit viele von Notebooks bekannte Energiesparfunktionen, welche dabei helfen den Verbrauch ohne Last (Idle) deutlich zu senken.

Hardware

Für meinen neuen/aktualisierten Homeserver habe ich folgende Hardware verwendet:

CPU: Intel Core i3 4130T
Board: Gigabyte H87-HD3
RAM: 8GB Corsair XMS3
HDD: 5x1TB + 2x1TB Western Digital, verschiedene Baureihen
Wechselrahmen: 2x Raidsonic IB-553SSK
NT: 400 Watt 80+

Die hohe Anzahl von insgesamt 7 1TB Festplatten resultiert aus dem von mir entworfenen Backup-Konzept, welches wie oben angesprochen Thema eines anderen Artikels sein wird. Im Betrieb hat der Server immer nur 5 der 7 Platten im Einsatz, der Rest dient zum Auswechseln und Auslagern der Backups.

Energiebedarf

Das System benötigt, im Leerlauf und ohne Festplatten, ca. 25 Watt Energie. Mein altes Atom Board (Gigabyte GA-D525TUD) hatte fast den gleichen Energiebedarf, doch das bei einem Bruchteil der Leistung. Unterschiede gibt es natürlich, wenn das System belastet wird, hier benötigt meine neue Hardware maximal 50 Watt (ohne Platten). Je nach Anzahl und Typ der Festplatten muss man hier 5-10 Watt für eine aktive Festplatte zusätzlich einplanen.

Leistung

Neben dem Energieverbrauch ist natürlich auch die Leistung des Systems ein relevanter Wert, hierzu habe ich verschiedene (wenn auch einfache) Benchmarks ausprobiert. Bitte beachtet, dass der Vergleich von einem Intel Atom zu einem Intel Core i3 nicht gerade fair ist.

Cryptsetup Benchmark

Da es mir bei der neuen Hardware primär um die Tauglichkeit zur Datenträgerverschlüsselung ging, habe ich hierzu cryptsetup benchmark verwendet. Dieser, etwas neuere und nicht in jeder Distribution enthaltene Befehl prüft die grundsätzliche Performance von Kernel und Hardware mit verschiedenen gängigen Verschlüsselungsalgorithmen.

Dieser Befehl existiert seit cryptsetup Version 1.6, welche unter anderem auch in Ubuntu 14.04 enthalten ist. Es ist ausreichend diesen Test mit einer Live-CD durchzuführen, eine Installation der aktuellen Version ist für bessere Performance nicht erforderlich.

7-Zip Benchmark

Das Komprimieren/Dekomprimieren von Daten ist eine weitere häufig durchgeführte und leicht testbare Aufgabe meines Homeservers. Hierzu eignet sich der Befehl 7za b von 7-Zip sehr gut.

7-Zip ist auf Debian basierenden Distributionen im Paket p7zip-full enthalten.

UEFI

Zwar wäre das neue System auch noch in der Lage einen BIOS abwärts kompatiblen Modus zum Booten zu verwenden, ich selbst bevorzuge aber ein UEFI Setup mit gummiboot. Hierzu habe ich einen 4GB USB Stick als festes Bootmedium ausgewählt, dieser steckt permanent im Server. Vorteil dieser Lösung ist, dass kein zusätzliches RAID1 für /boot erforderlich ist, und meine Daten (LVM, RAID) sauber vom Bootvorgang getrennt sind. Die Datenträger haben somit nur noch jeweils eine GPT Partitionstabelle und darauf nur eine einzige Partition, welche ein RAID enthält, auf dem RAID befindet sich nun ein LUKS verschlüsseltes LVM in welchem Betriebssystem und Daten liegen.

Der Umzug ging, abgesehen von der Umstellung auf einen neuen Bootloader, wie bei Linux gewohnt, reibungslos vonstatten.

Fazit

Die neue Hardware hat sich gelohnt, alle Datenträger im System sind vollständig verschlüsselt und damit sind auch meine Daten bei einem Hardwarediebstahl (Einbruch) ausreichend vor Missbrauch geschützt.

Natürlich könnt ihr euch auch die Rohdaten meiner Tests anschauen, ich hab ja nichts zu verbergen 😉

Netzwerktechnik im Eigenheim

Mon, 02 Jun 2014 18:15:23 +0000

Immer öfters werde ich, unter dem Vorwand ich sei doch Elektriker, gefragt, wie man den am besten die Telekommunikationsverkabelung in seinem Haus/Wohnung beim Neubau oder Umbau machen sollte. Und leider gibt es auch heute noch einige Elektroinstallationsunternehmen, bei denen unter Telekommunikation ausschließlich die eine TAE-Dose im Flur gemeint ist.

Telekommunikation hat sich aber auch im privaten Bereich die letzten Jahre deutlich verändert, eine Entwicklung, die auch für den ein oder anderen Techniker anscheinend noch Neuland ist.

Topologie

Die wichtigste Regel: Alle Netzwerkkabel werden zu einem zentralen Punkt im Haus gelegt. Dort trifft sich die Hausverkabelung des Netzwerkes mit der Anschlussleitung des Providers.

Ein zentraler Punkt hat den Vorteil das man dort alle wichtigen Komponenten wie Switches, Router und den Homeserver unterbringen kann. Weniger und dafür zentrale Komponenten sparen nach meiner Erfahrung häufig auch Energie, zumindest wird aber die Anzahl der möglichen Fehlerquellen durch unnötige Komponenten und Verbindungen vermieden.

Auf ein Telekommunikationsfeld im Elektroverteiler würde ich verzichten, diese sind schon bei wenigen Komponenten und Datendosen voll ausgelastet und nicht erweiterbar. Ein richtiger 19" Wandverteiler ist ab 150€ zu haben, bietet deutlich mehr Platz und erlaubt das die Komponenten ordentlich eingebaut werden können. Zusätzlich hat man den Vorteil das herkömmliche 19" Komponenten, wie Patchpanels oder Switches verwendbar sind.

Rohre

Unsere Technikzentrale hat jetzt also einen 19" Schrank an der Wand und wir haben einen Technikraum (vermutlich im Keller oder neben dem Heizraum) in dem alle Kabel zu einem zentralen Punkt verlegt werden. Jetzt brauchen wir noch einen Weg für unsere Datenkabel, auf welche ich im nächsten Abschnitt eingehen werde.

Da Netzwerktechnik ständig im Wandel ist, sollten Netzwerkleitungen ausschließlich im Leerrohr (z.B. FBY Rohr) zwischen Technikzentrale und Datendose verlegt werden. So haben wir später kein Problem unser Kupferkabel gegen Glasfaserleitungen zu tauschen, ein Wechsel, der früher oder später kommen wird.

Auch an Stellen, die aktuell noch keine Datendose benötigen, sollte schon ein Leerrohr gezogen werden, denn Rohr ist billiger als Wand aufreisen und den ganzen Mist in 10 Jahren noch mal neu zu machen.

Kabel

Auch hier wieder eine wichtige Regel: Es gibt nichts mehr anderes als Netzwerkleitungen!

Ein normales (altes) Telefonkabel hat in einem Neubau oder Umbau nichts mehr zu suchen, denn auch für diese altmodischen Dienste kann man ein Netzwerkkabel nehmen. Ethernet über Telefonkabel ist sicher etwas für jemanden der gerne bastelt, aber spätestens bei Gigabit Ethernet (Standard) kein Spaß mehr.

Das Kabel unserer Wahl ist also ein schönes Netzwerkkabel der Kategorie 7, welches auch für viele zukünftige Anwendungen wie 10 Gigabit Ethernet ausreichend ist. Preislich macht es kaum einen Sinn ein schlechteres Kabel zu verlegen, der Aufwand später zu migrieren steht in keinem Verhältnis zum Preisunterschied.

Dosen / Panels

Verteiler, Rohre und Kabel haben wir bis jetzt auf unserer Planungs- bzw. Einkaufsliste. Am Schluss kommt jetzt noch das Wichtigste: Die Netzwerkdosen bzw. Datendosen.

Hier gibt es in jeder Preisklasse etwas, von einfachen Netzwerkdosen mit Cat5 Norm bis hin zu modularen Steckersystemen der Cat6a ist alles geboten. Es ist relativ egal, für was man sich entscheidet, wichtig ist nur dass ein RJ45 Stecker in die Buchse passt. Abgesehen von der Cat Norm unterscheiden sich die verschiedenen Dosen in der Anschlusstechnik und vor allem im Installationsaufwand für das Konfektionieren.

Auf die Gegenseite, also in unseren tollen Netzwerkschrank, kommen normale 24-Port 19" Patchpanels, welche ab ca. 50€ pro Stück zu haben sind. Das ein oder andere Rangierpanel sorgt dafür, dass die Kabel nicht wild in der Gegend rumhängen und das ganze einigermaßen ordentlich aussieht.

Wohin mit den Dosen?

Eine wichtige Frage ist neben der verwendeten Technik, ein Problem, welches wir weiter oben geklärt haben, vor allem die Anzahl und der Ort unserer Netzwerkdosen. Hierzu ein paar Vorschläge bzw. Regeln, welche sich bei mir in der Praxis bewährt haben.

Jedes Zimmer bekommt mindestens eine Netzwerkdoppeldose.
Unser Wohnzimmer bekommt in der TV-Ecke mindestens 2 Netzwerkdoppeldosen, besser sogar 3.
Der Elektroverteiler bekommt auch eine Netzwerkdoppeldose, schließlich wollen wir auch an Daten von unserem Stromzähler kommen und Einfluss auf unser Smart Home nehmen.
Räume die als Büro genutzt werden sollen bekommen auch 2 Doppeldosen, dass gleiche gilt für Räume, die als Kinderzimmer deklariert worden sind.
Auch im Dachboden sehen Netzwerkdosen schick aus, spätestens, wenn der Wechselrichter unserer PV-Anlage einen Netzwerkanschluss hat möchten wir auch diese Daten abrufen können.
Pro Etage sollte, je nach Gebäude, auch eine Netzwerkdose im Flur vorhanden sein. Dort ist ein guter Punkt für unsere Access Points, damit auch WLAN flächendeckend in ausreichender Qualität verfügbar ist.
Türsprechstellen gibt es auch in einer IP-Ausführung, daher sollte auch dorthin eine Leitung gelegt werden.

Um diese Liste kurz zusammenzufassen: Es gibt nicht zu viele Netzwerkanschlüsse, sondern nur zu wenig davon. Langfristig wird jedes Gerät in unserem Haus entweder WLAN können oder über einen Ethernet Anschluss verfügen.

Fazit

Wir können grundsätzlich nicht viel falsch machen, wenn wir nur genug Netzwerkleitungen im Haus verlegen und diese an einer zentralen Stelle bündeln. Wer Geld sparen möchte, sollte auf Leerrohre und Leerdosen in der Wand setzen, an der Anzahl der möglichen Anschlüsse sollte man nicht sparen, außer man baut gerne um weil einem Gartenarbeit keinen Spaß macht.

Viele Empfehlungen aus diesem Artikel sind meine persönlichen Erfahrungen aus der Praxis, jeder kann aber niemand muss es in dieser Form umsetzen.

Smart Home

Fri, 16 May 2014 16:10:27 +0000

Beim Bauen eines Hauses gibt es neben der etablierten konventionellen Elektroinstallation auch ein Konzept das unter dem Namen Smart Home wie die Sau durchs Dorf getrieben wird. In diesem Artikel möchte ich auf mögliche Fallen und falsche Erwartungen eingehen.

Was ist Smart Home?

Fangen wir zuerst einmal mit dem Begriff an, die Wortschöpfung Smart Home besteht aus den beiden englischen Wörtern Smart und Home. Wir kennen diese beiden Worte nur zu gut, dass eine bedeutet für viele von uns einfach nur zu Hause, das andere kennen wir von diesen mehr oder weniger intelligenten Handies welche sich Smartphone schimpfen dürfen.

Eine smarte, also intelligente Wohnung, ist ein durchaus wünschenswertes Ziel. Eine intelligente Wohnung könnte mir lästige Aufgaben abnehmen, z.B. das Automatische öffnen der Rollladen bei Sonnenaufgang im Sommer. Neben viel Komfort lässt sich durch einige Maßnahmen so auch wertvolle Energie sparen, gleichzeitig steigt (wenn alles funktioniert wie es soll) auch der WAF (Woman Acceptance Factor) der eigenen vier Wände.

Was viele glauben was ein Smart Home ist?

Leider glauben viele Menschen das ein Smart Home nichts weiter als die Integration der vorhandenen Elektroinstallation in unser Smartphone oder Tablet ist. Ein gewaltiger Trugschluss, denn die Möglichkeit unser Gebäude mit mobilen Endgeräten zu bedienen ist nur ein netter Nebeneffekt, welchen wir bei der Gelegenheit mit nutzen können. Doch wie intelligent ist ein Haus, wenn ich alles mit dem Smartphone steuern muss? Richtig, irgendwie hat das mit Smart nicht viel gemeinsam.

Warum muss ich 25 Schaltmöglichkeiten im Wohnzimmer haben? Warum nicht einfach eine Szene "Fernsehen" aufrufen und schon fährt die Jalousie passend, die Beleuchtung wechselt die Farbe und Dimmwerte automatisch und alles ist schön? Etwas mehr KISS könnte manchen Technikverliebten Menschen nicht schaden. Nicht selten das Ich 3-4 4-Fach Taster im Wohnzimmer ertragen muss. Wozu muss ich alle 12-16 Schaltmöglichkeit an einer Schaltstelle neben der Tür haben?

Smart Home wird oft zu einem Spielzeug, das Angeben vor Freunden dass man alles einzeln mit dem Tablet steuern kann wird wichtiger als der Nutzen dieser noch relativ teuren Anlagen. Die Vorteile bleiben dabei auf der Strecke, z.B. wird oft auf eine Wetterstation verzichtet, als Ausgleich wird das Licht im Abstellraum dafür dimmbar gemacht.

Smart Home, aber richtig!

Eine Wetterstation ermöglicht es z.B. einfach bestimmte Dinge zu automatisieren, einige davon können auch ordentlich Energie sparen oder sind einfach nur angenehm:

Rollladen bei großen Außentemperaturen automatisch auf der Sonnenseite absenken.
Rollladen im Winter sobald die Sonne verfügbar ist (und man ausgeschlafen hat) nach oben Fahren um die Sonne (und deren Wärme) zu nutzen.
Rollladen steuern den Einfall der Sonne, die Sonne macht Licht, man denke nur mal daran, wie viel Energie man durch die Nutzung der Sonne sparen könnte.
Lichtschächte im Dach von Flachbauten können zur Belüftung automatisch geöffnet werden.
Einschalten einer Wegebeleuchtung (LEDs) bei Dämmerung oder Dunkelheit.
Automatisches Abschalten diverser Beleuchtung in Abhängigkeit der Außenbeleuchtung und dem Status der Rollladen.

Das waren nur die gängigsten Beispiele, einige davon lassen sich auch nicht auf jeden Gebäudetyp anwenden. Ein Passivhaus hat andere Anforderungen als ein Niederenergiehaus, und bei einem sanierten Altbau ist alles komplett anders.

Auch sehr beliebt ist der Zentral-AUS Schalter der durch seine Betätigung die Frage "Ist das Licht oben noch an?" erübrigt. Die Raumtemperatur in Abhängigkeit der gewohnten Anwesenheit zu steuern ist fast schon langweiliger Standard. Bewegungsmelder oder Präsenzmelder sorgen in einigen Räumen dafür, dass Licht nicht länger als unbedingt erforderlich brennt. Durch zusätzliche Sensoren und Aktoren sind die Möglichkeiten beinahe grenzenlos, wobei nicht alles, was möglich ist, auch sinnvoll ist.

Früher haben einige Menschen Netzfreischalter gekauft um die Leitungen in ihren Schlafräumen spannungsfrei zu schalten, egal was man davon halten mag, aber mit einer ordentlichen Elektroinstallation und einem Hauch Smart Home lässt sich der Elektrosmog in den eigenen 4 Wänden eindämmen.

KNX als Standard

In den letzten Jahren gab es viele verschiedene Systeme unterschiedlicher Hersteller, welche oft inkompatibel zueinander sind. Auch die großen Energieversorger sind (leider) auf diesen Zug aufgesprungen, und bieten teils abenteuerliche Konstruktionen als Lösung für den Wunsch nach einem Smart Home an. Doch stirbt ein herstellerspezifischer Standard sitzt man als Kunde auf dem Trockenen. Man sollte sich also immer an Standards orientieren, im Bereich der Gebäudeautomatisierung ist dies vor allem der KNX (früher EIB) Bus.

KNX ist ein Bussystem welches schon einige Jahrzehnte (wenn auch früher unter anderem Namen) als Standard hinter sich hat und viele Hersteller vereint. Es gibt innovative Produkte der großen Hersteller aus dem Elektrobereich, und auch zunehmend Lösungen von kleinen aber kreativen Unternehmen. Der KNX Bus hat sich bewährt, vor allem Unternehmen setzen für Neubauten überwiegend auf die Installation mittels KNX Bus. Vorteil vom KNX ist hauptsächlich die große Auswahl an verfügbaren Sensoren und Aktoren. Sensoren sind z.B. Lichtschalter, Präsenzmelder oder eine Wetterstation, die Dinge die geschaltet werden können oder etwas verändern, nennen sich Aktoren.

Alternativen zum KNX sind natürlich vorhanden, aber überwiegend etwas für Menschen, die gerne Basteln oder experimentierfreudig sind. Von SPS Steuerungen im Verteilerschrank und recht hässlichen (aber wohl sehr billigen) Schaltern über wirklich toll gemachte Lösungen findet man hier alles. Leider ist man meist von einem bestimmten Hersteller abhängig, kündigt dieser seine Lösung nach 3-4 Jahren ab steht man im Regen. Die meisten Gebäude stehen deutlich länger als der Produktlebenszyklus eines Herstellers dauert. Durch die Normung vom KNX können hier einfach verschiedene Hersteller gemischt werden.

Einige der Lösungen werden auf eine sehr ähnliche Art und Weise verkabelt, andere Unterscheiden sich in der Topologie und Technik deutlich. Verzichten sollte man in jedem Fall auf Funklösungen, denn wer Funk im Neubau verwendet hat beim Planen wohl geschlafen.

Fazit

Smart Home kann Fluch und Segen zu gleich sein, wie in vielen anderen Bereichen kommt es vor allem auf die korrekte Umsetzung an. Die kurzfristige Ersparnis bei der Erstinstallation kann sich schon nach wenigen Jahren teuer bemerkbar machen. Eine DIY Lösung, die heute noch total toll ist, kann morgen schon keinen Spaß mehr machen, Änderungen sind immer mit Kosten verbunden, sobald man an die Hardware geht.

Schmerzen mit crond, atd und logrotate

Tue, 13 May 2014 16:52:28 +0000

Gestern Abend habe ich, vor lauter Wut im Bauch, auf Google+ etwas über die "guten" alten Dienste atd, crond und logrotate geschrieben. Der Beitrag war mit insgesamt 114 Zeichen natürlich nicht sonderlich ausführlich, hat aber trotz dieser kürze einige Menschen zum Kommentieren motiviert. Mein Post auf Google+ entstand durch den Umstand, dass ich mal wieder mit diesen sehr alten Unix Tools einen Fehler suchen durfte, den es so mit modernen Lösungen (z.B. journald, Timer Units) nicht geben würde.

Welches Problem hatte ich eigentlich? Nun, meine Icinga Instanz hat mir ein zunehmend volles /var/log gemeldet. Da ich keine Modifikationen an der Konfiguration von Logrotate oder crond durchgeführt habe, sollte logrotate die Logfiles in diesem Ordner wöchentlich rotieren, alte Komprimieren und alles, was älter als 4 Wochen ist, über den Jordan jagen. Das Volume für dieses Verzeichnis hat eine Größe von immerhin 10 GiB, was für die Logfiles für einen Zeitraum von 4 Wochen bei 2 aktiven Diensten (Apache, Postfix) wirklich ausreichend sein sollte. Beim Überprüfen ist mir Folgendes am Anfang der mail.log aufgefallen:

Jul 11 08:17:36 h2022461 cyrus/master[1276]: about to exec /usr/lib/cyrus/bin/imapd
Jul 11 08:17:36 h2022461 cyrus/imaps[1276]: executed
Jul 11 08:17:36 h2022461 cyrus/imaps[1276]: accepted connection
Jul 11 08:17:36 h2022461 cyrus/imaps[1276]: mystore: starting txn 2147483710
Jul 11 08:17:36 h2022461 cyrus/imaps[1276]: mystore: committing txn 2147483710
Jul 11 08:17:36 h2022461 cyrus/imaps[1276]: starttls: TLSv1 with cipher AES256-SHA
(256/256 bits new) no authentication
Jul 11 08:18:00 h2022461 postfix/anvil[901]: statistics: max connection rate 2/60s
for (smtp:X.Y.Z.Z) at Jul 11 08:11:32
Jul 11 08:18:00 h2022461 postfix/anvil[901]: statistics: max connection count 1
for (smtp:X.Y.Z.Z) at Jul 11 08:08:55
Jul 11 08:18:00 h2022461 postfix/anvil[901]: statistics: max cache size 2 at Jul
11 08:14:39
Jul 11 08:18:36 h2022461 cyrus/master[622]: process 1276 exited, status 0

Die Datei hat eine Größe von über 500 MiB und nachweislich Einträge, welche noch vom letzten Jahr sind. Viele andere Logfiles haben ähnliche Größen, die /var/log/xconsole.log war sogar über 1 GiB groß. Insgesamt wurden so mehr als 8 GiB kostbarer Festplattenplatz für unsinnige Logfiles verschwendet. Eine Ursache, warum so viel Platz verschwendet wird und die Rotation der Logfiles nicht richtig gelaufen ist findet man nirgendwo.

Als Admin macht man sich dann erst mal auf die Fehlersuche, der erste Anlauf wäre hier natürlich die /etc/logrotate.conf. Doch von dort gibt es nur einen Hinweis auf 2 unwichtigere Logfiles und natürlich ein Include vom Verzeichnis /etc/logrotate.d. Und genau für den Postfix gibt es dort natürlich keine Konfigurationsdatei, welche sich für die mail.log auch nur im Ansatz verantwortlich fühlt. Die Rotation der Logfiles vom Postfix erfolgt nämlich nicht über logrotate wie man annehmen würde, sondern selbstverständlich über das Script /etc/cron.daily/sysklogd.

Welche Probleme haben wir bisher gesehen? Fassen wir das doch Mal zusammen:

Informationen werden in verschiedenen Logfiles gleichzeitig vorgehalten, die /var/log/xconsole.log enthält viele Informationen die man auch schon in der /var/log/messages, /var/log/daemon.log oder der /var/log/syslog finden kann.
Die Rotation der Logfiles ist nicht an genau einer Stelle, nämlich der Konfiguration vom spezialisierten Tool logrotate, gespeichert, sondern zusätzlich arbeitet auch noch ein Cronjob und übernimmt die gleiche Tätigkeit, aber eben für andere Dateien. Wo ist "One Job, One Tool" wenn man es mal braucht?

Immerhin wissen wir jetzt schon mal, wo unsere Logfiles, zumindest in der Theorie rotiert werden. Ein beherztes grep cron.daily /var/log/syslog bestätigt auch das unsere Cronjobs hierfür täglich ihre Arbeit machen sollten. Jetzt haben wir das nächste Problem: Wo sehe ich ob ein Cronjob wirklich gelaufen ist? Wo sehe ich welche Ausgaben ein Cronjob erzeugt hat?

Diese beiden Fragen sind nicht einfach zu beantworten, denn jetzt können wir uns jeden Cronjob im Detail anschauen:

Wurde im Job pauschal stdout/stderr nach /dev/null umgeleitet?
Wird im Job vielleicht das Syslog bei Fehlern manuell benachrichtigt?
Ist die Mailadresse für diesen Job korrekt und konnte dorthin eine Mail zugestellt werden?
Ist ein MTA installiert und konfiguriert welcher sich um die Zustellung von Mails im Fehlerfall kümmern könnte?

Einige dieser Punkte sind global zu prüfen, andere sind für jedes Script einzeln zu prüfen. Um es kurz zu machen: Ohne einiges an Recherche wissen wir nicht was mit der Ausgabe und den Fehler von einem Cronjob etwas passiert, oder ob dies nicht einfach fälschlicherweise in /dev/null verschwindet.

In den Kommentaren stellte Christian die These auf das mein System falsch konfiguriert sei wenn /var/log voll laufen kann, dem ist und war nicht so. Ein manueller Lauf der Cronjobs und anschließendes Neustarten von crond hat dazu geführt, dass die Logfiles wieder rotiert wurden. Was wir aber weiter oben lesen durften, bestätigt auch die Erfahrungen von Michael (aus den Kommentaren) und mir: Cronjobs machen gerne mal schmerzen, sind schlecht zu kontrollieren und der gute alte Syslog ist dort keine große Hilfe. Die manuelle Suche nach dem Fehler ist mühsam und zeitaufwendig, außer man startet einfach aus Faulheit die Kiste oder irgendwelche Dienste ziellos neu, was ich aber nicht für zielführend halte.

Bei systemd sehe ich in Kombination von Timer Units und dem systemd Journal alle relevanten Informationen an einer Stelle. Genauso gibt es auch nur eine Stelle, welche sich um den Speicherplatzbedarf vom Journal kümmert. Und es werden auch keine Informationen über verschiedene Dateien verteilt oder sogar doppelt gespeichert. Und in der Praxis sieht das so aus:

[root@server ~]# systemctl list-timers
NEXT    LEFT          LAST    PASSED  UNIT                  ACTIVATES
… CEST  5h 41min left … CEST  18h ago man-db.timer          man-db.service
… CEST  5h 41min left … CEST  18h ago shadow.timer          shadow.service
… CEST  5h 41min left … CEST  18h ago updatedb.timer        updatedb.service
… CEST  7h left       … CEST  16h ago my-rdiff-backup.timer my-rdiff-backup.service

5 timers listed.
Pass --all to see loaded but inactive timers, too.
[root@server ~]# systemctl status my-rdiff-backup.timer
● my-rdiff-backup.timer - my-rdiff-backup Service Timer for Hanny/Nanny
   Loaded: loaded (/etc/systemd/system/my-rdiff-backup.timer; disabled)
   Active: active (waiting) since Thu 2014-05-01 10:02:17 CEST; 1 weeks 5 days ago

May 01 10:02:17 server systemd[1]: Starting my-rdiff-backup Service Timer for Hanny/Nanny.
May 01 10:02:17 server systemd[1]: Started my-rdiff-backup Service Timer for Hanny/Nanny.
[root@server ~]# systemctl status my-rdiff-backup.service
● my-rdiff-backup.service - My rdiff-backup for Hanny/Nanny
   Loaded: loaded (/etc/systemd/system/my-rdiff-backup.service; static)
   Active: inactive (dead) since Tue 2014-05-13 02:02:00 CEST; 16h ago
  Process: 8304 ExecStart=/usr/bin/rdiff-backup --meine-parameter (code=exited,
  status=0/SUCCESS)
 Main PID: 8304 (code=exited, status=0/SUCCESS)

May 13 02:00:00 server systemd[1]: Started My rdiff-backup for Hanny/Nanny.

Die Ausgaben habe ich etwas zensiert, um mein Layout nicht zu sprengen, aber es sind noch alle relevanten Informationen vorhanden: Wann lief der Job? Wann läuft er als Nächstes? Wann wurde der Job mit welchem Exit Status beendet?

Der einzige Nachteil, dass binäre Logfiles verwendet werden, kommt mir mittlerweile fast schon lächerlich vor. Das journal unterstützt mich nach anfänglicher Kritik bei der Arbeit, dass gleiche gilt für die Timer Units. Ich vermisse die Tools grep, tail und head in meinem /var/log nicht mehr.

LVM richtig verwenden

Sat, 25 Jan 2014 10:56:41 +0000

Ich verwende auf all meinen Systemen, mal von diesen Android Spielsachen abgesehen, stets LVM zur Verwaltung der vorhandenen Datenträger. Der Vorteil ist, dass ich auf eine umfangreiche und schlecht änderbare Partitionierung verzichten kann, dazu kommen noch einige sehr praktische Features von LVM wie z.B. Snapshots oder die Möglichkeit Volumes online in der Größe ändern zu können.

Das Problem

Ich habe mir mittlerweile für sehr viele Fremde, also nicht von mir installierte, Systeme Zugang verschafft. Dort fällt mir sehr oft auf das zwar LVM verwendet wird, jedoch meiner Meinung nach falsch. Hintergrund ist das dort in der Regel eine große Volume Group existiert, und dort sind genau 2 Volumes enthalten: Swap mit 1-2 GiB, der Rest vollständig für das /-Dateisystem. In der Praxis sieht das dann so aus:

user@hostname:~# vgs
  VG           #PV #LV #SN Attr   VSize  VFree 
  main           1   2   0 wz--n- 19,76g 20,00m
user@hostname:~# lvs
  LV     VG           Attr   LSize  Origin Snap%  Move Log Copy%  Convert
  root   main         -wi-ao 17,74g                                      
  swap   main         -wi-ao  2,00g

Konkret kann so kein Snapshot angelegt werden, es ist nicht möglich ein zusätzliches Volume anzulegen, und so ziemlich alle Vorteile eines LVM sind erst mal dahin. Was übrig bleibt, ist die Option einen zusätzlichen Datenträger im Betrieb einzubauen und das System ohne Downtime umziehen oder erweitern zu können.

Die Lösung

Systeme, die ich selbst installieren durfte, oder bei welchen ich um Rat gebeten wurde, haben meist folgendes Schema:

[user@hostname ~]# vgs
  VG   #PV #LV #SN Attr   VSize   VFree  
  main   1   8   0 wz--n- 465.66g 212.66g
[user@hostname ~]# lvs
  LV            VG   Attr       LSize   Pool Origin Data%  Move Log Cpy%Sync Convert
  arch          main -wi-ao----  20.00g                                             
  aur           main -wi-ao----  10.00g                                             
  bitcoin       main -wi-a-----  20.00g                                             
  geheim1       main -wi-a-----  30.00g                                             
  geheim2       main -wi-a-----  10.00g                                             
  scummvm       main -wi-ao----   5.00g                                             
  swap          main -wi-a-----   8.00g                                             
  virtualbox    main -wi-ao---- 150.00g

Was sofort auffällt, ist, dass in meiner Volume Group noch viel Platz für zukünftige Erweiterungen ist, und dass ich meine Daten gerne auf viele Volumes verteile. Volumes haben bei mir entweder Standardgrößen (z.B. das /-Dateisystem 10-20 GiB) oder den aktuellen Bedarf +50% als Reserve. Durch diese Verteilung kann ich jederzeit von einzelnen Diensten oder Anwendungen Snapshots erstellen und Dinge ohne Reue kaputtmachen. Ein zu klein geratenes Volume stellt kein Problem mehr dar, ich kann es einfach Online vergrößern ohne dafür ein Rescue System nutzen zu müssen. Auch die Möglichkeit bestimmte Volumes auf bestimmte Datenträger (SSD, HDD, …) innerhalb einer Volume Group zu verschieben steht mir zu Verfügung.

Die Datenträger an sich haben bei mir in der Regel auch nur maximal 2 Partitionen, das wäre entweder eine /boot oder UEFI Partition und der Rest direkt als Physical Volume für LVM. Die /boot oder UEFI Partition haben meistens eine Größe von ca. 500 MiB, somit passt auch ein Rescue System für den Notfall noch auf diese.

Die Sache mit der Datenträgerverschlüsselung oder einem Software-RAID habe ich der Einfachheit halber in diesem Artikel unterschlagen, kommen in der Praxis aber natürlich noch dazu.

Nochmal kurz zusammengefasst:

Volume Groups nur in Ausnahmefällen vollständig auslasten. Damit man später auch noch Platz für Snapshots hat.
Volumes anfangs erst mal nur so groß wie erforderlich machen, dazu noch eine angemessene Reserve. Volumes können leicht vergrößert, aber je nach Dateisystem nicht oder schwer verkleinert werden.
Viele Volumes sorgen dafür, dass man später bequem von einzelnen Diensten Snapshots für Testzwecke erstellen kann, auch das Verschieben einzelner Dienste auf unterschiedliche Datenträger wird so sinnvoll möglich.

AES-NI in der Praxis

Mon, 06 Jan 2014 17:11:30 +0000

Nicht erst durch die Geschichte mit der NSA verschlüsseln viele Anwender ihre Festplatten, was auch sehr sinnvoll ist. Dennoch halten sich die Mythen hartnäckig das die Performance darunter leidet und man daher darauf verzichten sollte oder die in Festplatten eingebaute Verschlüsselung genutzt werden sollte.

Die Implementierung in einer Festplattenfirmware kann nicht geprüft werden, es ist egal welche Performance diese liefert, wenn nicht sicher ist ob und wie verschlüsselt wurde. Hersteller versprechen gerne, dass hierbei AES verwendet wird, zum Thema ECB und Co schweigen die Datenblätter aber gerne. Ich selbst stehe technischen Daten von Herstellern stets skeptisch gegenüber ;)

Dann bleibt noch die Sache mit der schlechten Performance, ein Mythos, der wohl in die Geschichte eingehen wird. Wer ein aktuelles System hat, und nicht an der falschen Stelle gespart hat, verfügt über einen Prozessor mit der AES-NI Erweiterung. Mit dem Befehl cryptsetup benchmark kann auf jedem halbwegs aktuellen Linux selbst die Performance der Verschlüsselung, unabhängig vom Datenträger, getestet werden. Nachfolgend die Werte meines Desktop-PCs, welcher schon etwas älter ist und daher noch kein AES-NI unterstützt:

# Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GHz
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1       359101 iterations per second
PBKDF2-sha256     206088 iterations per second
PBKDF2-sha512     134157 iterations per second
PBKDF2-ripemd160  280668 iterations per second
PBKDF2-whirlpool  138407 iterations per second
#  Algorithm | Key |  Encryption |  Decryption
     aes-cbc   128b   138,9 MiB/s   160,6 MiB/s
 serpent-cbc   128b    53,6 MiB/s   196,8 MiB/s
 twofish-cbc   128b   136,5 MiB/s   180,0 MiB/s
     aes-cbc   256b   109,2 MiB/s   121,3 MiB/s
 serpent-cbc   256b    53,6 MiB/s   197,1 MiB/s
 twofish-cbc   256b   136,3 MiB/s   180,1 MiB/s
     aes-xts   256b   162,4 MiB/s   160,8 MiB/s
 serpent-xts   256b   176,0 MiB/s   184,5 MiB/s
 twofish-xts   256b   166,5 MiB/s   166,7 MiB/s
     aes-xts   512b   122,9 MiB/s   121,5 MiB/s
 serpent-xts   512b   176,4 MiB/s   184,6 MiB/s
 twofish-xts   512b   166,5 MiB/s   167,4 MiB/s

Die, meiner Meinung nach, einzig relevante Zeile ist die aes-xts Zeile mit 512 Bit. Dort erreicht meine CPU von 2007 (!!!) immerhin noch ungefähr 121 MiB/s, mehr als die im System verbaute Festplatte. Sehen wir uns das Ganze noch auf meinem Notebook an, dort ist ein aktueller Intel CPU verbaut:

# Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1       465619 iterations per second
PBKDF2-sha256     265596 iterations per second
PBKDF2-sha512     176172 iterations per second
PBKDF2-ripemd160  385505 iterations per second
PBKDF2-whirlpool  215934 iterations per second
#  Algorithm | Key |  Encryption |  Decryption
     aes-cbc   128b   589.8 MiB/s  1961.6 MiB/s
 serpent-cbc   128b    75.6 MiB/s   293.0 MiB/s
 twofish-cbc   128b   168.8 MiB/s   318.4 MiB/s
     aes-cbc   256b   434.8 MiB/s  1514.6 MiB/s
 serpent-cbc   256b    75.7 MiB/s   293.0 MiB/s
 twofish-cbc   256b   168.9 MiB/s   318.4 MiB/s
     aes-xts   256b  1708.7 MiB/s  1716.9 MiB/s
 serpent-xts   256b   303.3 MiB/s   288.4 MiB/s
 twofish-xts   256b   313.2 MiB/s   315.4 MiB/s
     aes-xts   512b  1329.2 MiB/s  1342.5 MiB/s
 serpent-xts   512b   303.2 MiB/s   288.5 MiB/s
 twofish-xts   512b   313.1 MiB/s   315.2 MiB/s

Hier reden wir von schlappen 1329 MiB/s, obwohl dieses System eine ordentliche SSD verbaut hat ist diese der Bremsklotz im System, und nicht wie oft behauptet die Verschlüsselung. Wer möchte, kann sich jetzt noch ein Szenario generieren, indem die Verschlüsselung trotzdem doof und langsam ist, realistisch dürfte das aber bei den wenigsten Anwendern zutreffend sein.

NAT vs. Privacy Extensions

Sat, 21 Dec 2013 17:35:28 +0000

Durch die Migration einiger großer Internet Provider in Richtung IPv6, unabhängig von dessen technischer Umsetzung, häufen sich bei mir die Anfragen, wie es den mit der Privatsphäre aussieht. Dazu kommen dann noch die Fragen, wie es den mit der Sicherheit aussieht, schließlich ist der eigene PC jetzt direkt aus dem Internet erreichbar.

Die meisten Fragen kommen dadurch zustande das NAT, also die bei den meisten DSL Routern verwendete Network Address Translation, als Feature für Datenschutz und Sicherheit verstanden wird. Ich werde nachfolgend mal auf die verschiedenen Mythen und Missverständnisse zu diesem Thema eingehen, und erläutern warum man mit IPv6 nicht prinzipbedingt schlechter dran ist.

Datenschutz

Im Internet kommunizieren wir in der Regel über die verschiedenen IP Protokolle, dadurch fallen bei der erforderlichen bidirektionalen Kommunikation auch immer IP Adresse an. Während eine Verbindung besteht werden diese benötigt, um überhaupt eine Kommunikation durchführen zu können, im Anschluss landen diese Informationen meist in einem Archiv (Logfiles). Bei aktiviertem NAT landet beim anderen Kommunikationsteilnehmer immer die öffentliche IP Adresse unseres Routers im Protokoll, der PC welcher sich hinter dem NAT befindet ist nicht direkt ersichtlich. Der Router ersetzt hier unsere interne private IPv4 Adresse durch die öffentliche IPv4 Adresse der WAN Schnittstelle. Zusätzlich merkt er sich die ganze Aktion in Tabellen, so dass er auch Antwortpakete an den richtigen Client zustellen kann.

Über diese öffentliche IP Adresse lässt sich prima der Inhaber des Anschlusses durch geeignete Maßnahmen ermitteln, wer genau aus diesem Netzwerk aber etwa eine Straftat begannen hat, ist nicht ermittelbar. Zumindest die IPv4 Adresse unseres Routers bietet keine Information darüber, sondern taugt nur um den Anschlussinhaber zu ermitteln.

Bei IPv6 wurde im grundlegenden Design bewusst auf Krücken wie NAT verzichtet, was meiner Ansicht nach eine sehr gute Entscheidung war. 128 Bit lange Adressen ermöglichen es uns jeden PC und jeden Chip auf diesem Planeten seine eigene Adresse zu geben, ohne das wir auch nur im Ansatz den möglichen Adressraum ausnutzen würden.

Die Konsequenz aus dieser Entscheidung ist, dass jeder Kommunikationsteilnehmer automatisch sein Gegenüber kennt, und nicht wie bisher nur zufällig diese eine IP vom Router. Um zu verhindern das man durch diese sinnvolle Entscheidung eine Zuordnung zu einem einzelnen Client oder gar Benutzer erstellen kann wurden sog. Privacy Extensions definiert. Diese sorgen dafür das sich ein Client mit einem bestimmten Algorithmus selbstständig neue Adresse aus dem gleichen Subnetz generiert. Das Subnetz ist bei IPv6 einem Router und damit einem Anschlussinhaber zugewiesen, es handelt sich dabei in der Regel um die ersten 64 Bit der Adresse. Bei der IPv6 Adresse 2003:65:c77f:d284:f0b4:c9e4:ae6e:8597/64 wäre das Subnetz z.B. die 2003:65:c77f:d284::/64, der Rest wäre ein PC in meinem Netzwerk. Da ich die Privacy Extensions auf allen Clients aktiviert habe bietet diese Adresse keine wertvolle Information, da sich diese eben ständig ändert. In den Logfiles der verschiedenen Provider und Tracking Dienste stehen also ständig sich ändernde Adresse, aber alle aus demselben Subnetz (solange ich daheimbleibe). Mit dem Subnetz, also der IPv6 Adresse, ist es wieder möglich den Anschlussinhaber ermitteln zu lassen, einen individuellen PC aber nicht.

Zusammengefasst erfüllen also, aus der Sicht von einem Abmahnanwalt oder einem Tracking Dienst, beide Techniken (NAT oder PE) den gleichen Zweck: Der Client kann nicht ermittelt werden, der Anschluss aber nach wie vor. Wir erreichen mit den Privacy Extensions also das gleiche Schutzniveau wie zuvor, müssen aber nicht mit den technischen Nachteilen von NAT, wie kaputte P2P Dienste, leben.

Sicherheit

Einige dürften noch W32.Blaster kennen, das war ein Wurm der 2003 die Windows Welt unsicher machte. Blaster war einer der letzten großen Angriffe mittels Server Side Exploit, man nutzte also die Tatsache aus das Computer mit unsicheren Netzwerkdiensten direkt aus dem Internet erreichbar waren. Anwender, die sich hinter einem schon damals recht verbreiteten DSL Router mit NAT befanden, hatten wenig Probleme, andere mit DSL Modems oder ISDN/Modem kamen nicht so gut davon. Konsequenz war das Microsoft mit Windows XP Service Pack 2 eine Personal Firewall aktivierte, um auch Anwender ohne NAT Router zu schützen. Die richtige Konsequenz wäre es gewesen in der Standardkonfiguration einfach keine von außen erreichbaren Services anzubieten, aber damit hatte man wohl so seine Probleme.

Durch den fehlenden Eintrag in der Verbindungstabelle des Routers hat die NAT Implementierung des Routers die eingehende Verbindungsanfrage des Wurmes nicht weitergeleitet. Der Schutz war also eine folge der Art und Weise wie NAT funktioniert und nicht weil NAT hier einen Schutz als Feature bietet. Das gleiche verhalten konfiguriert man bei einem IPv6 Router, indem man alle neuen eingehenden Verbindungen nicht an angeschlossene Clients weiterleitet, ganz ohne den zusätzlichen Aufwand einer Adressumschreibung.

Eine kaputte Routingtabelle würde kaum ein Administrator als Sicherheits Feature bezeichnen, also sollten wir dies bei NAT, auch wenn es manchmal hilft, auch nicht machen.

Auch hier sind NAT und IPv6 gleichwertig zu betrachten, lediglich der Ansatz ist anders und auch hier kann wieder auf technische Krücken beim Einsatz von IPv6 verzichtet werden. Zusätzlich sollte man beachten das 2013 kaum noch ein Angriff über offene Ports erfolgt, sondern man sich einfach der schwächsten Komponenten im System bedient die nach draußen Kommunizieren dürfen. Diese verwundbare Komponente ist heute der Browser, den dieser kommt komfortabel durch alle Proxies, Router und Firewalls und kann den schädlichen Code direkt auf den Client laden.

Fazit

NAT bietet weder mehr Sicherheit, noch mehr Privatsphäre als es mit IPv6 möglich ist. Durch den Verzicht auf diese technische Krücke bekommen wir etwas Komfort (P2P Dienste) zurück, und sonst ändert sich bei einer korrekten Implementierung und ordentlicher Policy im Router für uns als Anwender nichts.

Für viele Anwender ist es nach wie vor schwer, sich von dem Gedanken zu verabschieden NAT sei ein Feature aus dem Bereich der IT Sicherheit. Aber gemeinsam werden wir auch das überleben ;)

Artikelserie über systemd

Sun, 10 Nov 2013 07:40:12 +0000

Der Entwickler von systemd, Lennart Poettering, hat eine meiner Meinung nach großartige Artikelserie über dieses neue Init System veröffentlicht. Insgesamt handelt es sich dabei mittlerweile um 20 Artikel, den letzten habe ich hier verlinkt da am Kopf des aktuellsten Artikels immer alle Vorgänger ebenfalls verlinkt sind.

Der ein oder andere Artikel hat nur selten gebrauchte Features, wieder andere dürften vor allem für Systemadministratoren relevant sein und zeigen das ein neues modernes Init System viele hässliche Workarounds der letzten 20 Jahre überflüssig macht.

Bei Gelegenheit werde ich eventuell nach und nach den ein oder anderen Artikel der Serie ins deutsche Übersetzen. Relevanz hat die Artikelserie übrigens auch für die Nutzer anderer Init Systeme wie z.B. upstart, denn ein Blick über den Tellerrand schadet nicht.

Mein Desktop Workflow

Sun, 03 Nov 2013 09:54:18 +0000

In den letzten Jahren habe ich mir einen ganz bestimmten Workflow angeeignet, dieser ermöglicht es mir Dinge effizient zu tun, ohne viele Anpassungen an meinem Betriebssystem durchzuführen. Ich versuche wann immer möglich Standardsysteme zu verwenden, je weniger Anpassungen ich benötige um Arbeiten zu können, desto weniger Zeit brauche ich auf einem neuem System für meine Arbeit.

Aus diesem Grund nutze ich nur Desktop Umgebungen welche das Starten von Programmen, oder finden von Dateien, standardmäßig über die Windows Taste erledigen. Ich verweigere wann immer möglich also die Arbeit an einem Windows XP System, genauso vermeide ich auch Desktops bei welchen ich erst 10-20 Optionen Einstellen muss um dieses verhalten zu haben. Bei mir gibt es keine Startleisten, Docks oder diese furchtbaren Desktop Icons, all das muss bei mir die Suchfunktion auf der Windows Taste zuverlässig und schnell für mich erledigen. Ich möchte mich also nicht damit beschäftigen wo etwas ist, das ist Aufgabe vom Betriebssystem, denn auf der Shell gebe ich auch keine vollen Pfadangaben an, sondern starte ein Programm und es wird schon irgendwo in meinem Suchpfad vorkommen. Die Windows Taste hat so bei mir einen Sinn, ich mag die Taste, nur das Logo darauf finde ich etwas hässlich.

Durch den Verzicht auf großartige Anpassungen an meinem Desktop kann ich auf den Systemen ab Windows 7 und Linux mit installierter GNOME Shell direkt loslegen und muss mich um keinerlei Einstellungen kümmern, die Standardwerte vom Desktop sind vollkommen ausreichend. Windows benutze ich nur in der Firma, Privat sehe ich keinen Vorteil dieses Betriebssystems und vermeide Produkte aus dem Hause Microsoft nicht erst seit dem NSA Problem ;)

Oben angesprochene GNOME Shell ist aus mehreren Gründen mein Lieblingsdesktop, die funktionierende Suchfunktion ist für mich der Hauptvorteil, dazu kommt noch dass es nicht so viel Schnickschnack (Blingbling) gibt der mich stört oder keinen großen Mehrwert liefert. Die Shell verhält sich unauffällig, wenn ich keine Aktion der Shell ausführe sehe ich kaum was davon, der Fokus liegt also auf den Anwendungen und nicht auf einem Bunten Ding das sich um meine Anwendungen legt und meine Augen mit Farben beleidigt.

Unter Ubuntu komme ich auch mit Unity mittlerweile einigermaßen zurecht, für die vielen Farben sollte man Canonical aber verklagen, das grenzt meiner Meinung nach an versuchter Körperverletzung. Unity hat etwas von OSX übernommen was ich sinnvoll finde, und zwar ist die Menüleiste eines Programms nicht mehr im Fenster der Anwendung sondern global in einer einheitlichen Leiste am oberen Rand des Desktops. GNOME geht hier einen ähnlichen Weg und packt Funktionen die ich nicht ständig benötige in ein Anwendungsmenü das mir nicht ständig im Weg ist. Die meisten Dinge versuche ich über Shortcuts zu erledigen, das Menü benötige ich also nur sehr selten um eben selten genutzte Dinge zu finden.

Aber komplett auf Anpassungen kann ich nicht verzichten, bestimmte Dinge nehme ich also zwischen den verschiedenen Systemen mit, das wäre konkret meine Konfiguration von SSH, Mercurial und dem besten Editor der Welt (vim). Die Shell welche ich benutze ist mir relativ egal, ich vermeide aber die gute zsh da diese auf kaum einem System das ich verwende installiert ist, zusätzlich fehlen mir auch die Adminrechte. Ein persönliches Laster von mir ist Taskwarrior, das muss auf jedem System vorhanden sein welches ich produktiv nutzen möchte, selbst unter Windows wird dies durch die Installation von Cygwin (schlagt mich) erledigt. Gut das ich dieses geniale Tool nur auf Geräten benötige deren Admin ich bin.

Fassen wir das nochmal kurz zusammen:

Ich bevorzuge Software so weit wie möglich in der Standardkonfiguration
Ich hasse Farben, schon allein weil diese so extrem Bunt sind
Ich hasse Dinge die Platz brauchen der keinen Zweck für mich erfüllt
Ich liebe das Task Management Tool task
Ich installiere Cygwin unter Windows
Ich halte Bedienkonzepte wie die der GNOME Shell oder von Unity für effizienter als den kaputten Ansatz mit der Startleiste

Früher habe ich das nicht so gemacht, da war es Standard das ich erstmal meine Konfiguration an einem neuen Rechner bis zum Limit des maximal möglichen frisiert habe. Die Zeit dafür spare ich mir jetzt, dafür ist es (teilweise auch leider) erforderlich mich an die Vorgaben der Entwickler zu halten.

Master Slave Steckdosenleisten

Wed, 02 Oct 2013 19:35:41 +0000

Seit einigen Jahren gibt es diese tollen "Master-Slave-Steckdosenleisten", also Steckdosenleisten bei welchen über den Verbrauch eines Gerätes die jeweils anderen Geräte geschaltet werden. Häufig verwendet werden diese Teile an PC Arbeitsplätzen, meistens geht es darum das Monitor und Lautsprecher vom Netz getrennt werden wenn der PC abgeschaltet wird. Das klingt vom Grundsatz her erstmal sehr sinnvoll, in der Praxis sieht es oft ganz anders aus.

Denn, alles was irgendwie automatisch geht, braucht meistens auch Strom. Und da fangen schon die Probleme dieser Leisten an: Manche Modelle benötigen bis zu 7.5 Watt um überhaupt ihre eigene Elektronik zu betreiben. Zum Vergleich benötigen halbwegs moderne TFT Monitore im Standby Betrieb nur ~0.5 Watt, oft sogar noch weniger. Meine alten Samsung Monitore benötigen hier noch immerhin fast 2 Watt, kaum noch zeitgemäß 2013 ;)

Jetzt wissen wir also das wir beim kauf derartiger Steckdosenleisten aufpassen müssen ob die Elektronik und der Verbrauch der abzuschaltenden Geräte überhaupt eine Amortisierung ermöglicht. Haben wir diesen Schock überwunden gehen wir gleich zum nächsten Problem: Elektrische Geräte gehen nach meiner Erfahrung zu 80% beim Einschalten/Ausschalten kaputt.

Bei einem billigen Monitor mag das relativ egal sein, hat man aber sein Hifi System und noch einige andere teure Elektronik als Opfer auserkoren sollte man sich die Sache noch mal Überlegen. Es bringt nicht viel Energie zu sparen und im Anschluss daran öfters als üblich neue Geräte zu kaufen, denn die meiste Energie lässt sich bei der Anschaffung von Geräten sparen (Energieeffizienz, Standbyverbrauch, …). Das gleiche gilt übrigens auch für normale Steckdosenleisten mit Schalter, nett gemeint aber vielleicht sollte man sich das Geld für die Leiste sparen und beim nächsten mal direkt Geräte kaufen deren Standbybedarf nicht so hoch ist. Ein gutes Beispiel wie man Energie verschwenden kann ist übrigens die Nintendo Wii, im aktiven Standby, also der Modus wo man Updates bekommt und das Laufwerk so schön blau blinkt, verbraucht das Teil 10 Watt Energie.

Der Standbystromverbrauch sollte nicht Unterschätzt, aber auch nicht Überschätzt werden: Die meiste Energie im Haus benötigt nämlich Heizung, Beleuchtung und einiges andere, die paar Geräte im Standby sind da nur ein Tropfen auf den heißen Stein.

Datenschutz als Illusion

Sat, 10 Aug 2013 09:14:39 +0000

Wir schreiben das Jahr 2013, ein Jahr in dem wir ständig gegen einen Grundsatz aus dem Datenschutz verstoßen: Die Datensparsamkeit. Hintergrund von diesem Grundsatz ist das man Daten die nicht entstehen oder zumindest nicht gespeichert werden auch nicht besonders Schützen muss.

Dieser Grundsatz ist eigentlich eine gute Idee, aber leider machen es gerade moderne Anwendungen immer schwerer diesem Grundsatz zu entsprechen. Dazu kommt noch ein weiterer Punkt: Wir verlassen uns beim Thema Datenschutz zu viel auf Schlangenöl wie Privatsphäreeinstellungen von Facebook (und anderen Sozialen Netzwerken) oder die entsprechenden Einstellungen von unserem Smartphone.

Soziale Netzwerke

Gerade Facebook ist hier ein sehr gutes Beispiel, es gibt sehr viele Leute die ihre Einstellungen sehr Restriktiv gewählt haben. Eine (grundlegend) gute Idee, jedoch sammelt Facebook mit großer Wahrscheinlichkeit unabhängig von unseren Einstellungen trotzdem die Daten, da ein filtern der Informationen an der Quelle wesentlich aufwendiger ist als die Daten einfach im Benutzerprofil auszublenden. Wieder andere Menschen verwenden kein Facebook, mit dem glauben an die Illusion das Facebook so kein Profil über einen erstellen kann. Ich muss euch enttäuschen, es ist für Facebook egal ob ihr einen Account bei diesem Verein habt oder nicht, ein Profil habt ihr dort unabhängig von eurem Account. Andere Soziale Netzwerke verhalten sich hier nicht wesentlich anders, ermöglicht wird dies über große Werbenetzwerke und die fast überall vorhandenen Social Buttons (Liken, Sharen, Retweeten) welche permanent euer Surfverhalten aufzeichnen und zu einem ansehnlichen Profil zusammenfassen.

Smartphones

Unsere Smartphones sind nicht besser, technisch gesehen handelt es sich dabei um tragbare PCs auf welchen man Firmen wie Microsoft, Apple oder Google einen Administrator Account geschenkt hat. Herr über seine Daten ist man auf einem dieser Geräte nicht, das sind nämlich eben genannte große Anbieter welche sich aktuell einen Kampf mit den Mobilfunkprovidern darüber liefern wem der Kunde gehört.

Das ein Administrator auf einem System machen kann was er will ist uns bekannt, nur so funktioniert z.B. auch die Remote Installation oder Deinstallation von Anwendungen die heute nur noch Apps heißen. Das es für einen Administrator aber auch egal ist ob wir die Standorteinstellungen Datenschutztechnisch eher positiv gewählt haben ist für diesen zusätzlichen (und von uns freiwillig gewählten) Administrator ebenfalls kein Hindernis.

Shopping

Auch beim Einkaufen (nicht nur im Internet) verschenken wir sehr gerne unseren Daten, unsere Wünsche und auch unsere Neigungen. Ich selbst schenke Amazon ein ganz bestimmtes Profil von mir, der Dienst weiß welche Filme ich mag und welche Bücher ich lese. Suche ich aber Dinge von denen ich nicht möchte das Amazon diese in sein Profil aufnimmt greife ich auf eine andere Art auf den Shop zu. Der Logout Button ist übrigens eine Illusion, nur falls jemand auf die Idee kommt man könne sich ja einfach abmelden und alles wird gut.

Für das Geschenk (unsere Daten) bekommen wir von Anbietern wie Amazon diese tollen Empfehlungen die uns zum Kauf von Artikeln verleiten sollen die wir vielleicht auch haben wollen.

Am schönsten für diese Anbieter (Amazon, eBay, …) ist es aber wenn wir deren Browser-Addon nutzen um einen "Universal Wunschzettel" zu haben, wir ermöglichen es nun diesem Shop all unsere Bewegungen im Internet vollständig zu erfassen und das Profil das bisher nur auf Einkäufe im Shop ermittelt wurde wesentlich zu erweitern.

Abhilfe

Jetzt gibt es 2 Sachen die man Unternehmen kann um mit dieser Situation umzugehen:

Verhindern das die Daten entstehen
Daten für eigene Zwecke verwenden

Verhinderung

Das Verhindern das Daten entstehen ist ohne Zweifel die sicherste Möglichkeit um zu verhindern das wir Daten liefern die wir nicht verschenken möchten. Hierzu gibt es sehr viele Möglichkeiten, am wichtigsten sind hierbei die Erweiterungen für den Browser wie z.B. Ghostery, Adblock Plus oder auch HTTPS Everywhere. Wenn wir diese verwenden sorgen wir dafür das lästige Tracking Dienste durch Werbung und Social Media Funktionen uns nicht mehr erfassen kann. Wir können also selektiv wählen wer unsere Daten bekommt, je nach Einstellung bekommt der Entwickler dieser Erweiterungen noch einen Teil der Daten aber dieser ist uns bekannt und nicht eine Anonyme Menge an mehreren Hundert Tracking Diensten die uns täglich erfassen.

Beim Shopping eignet sich der private Modus prima als Zusatz, ich selbst Suche meine Musik, Filme und andere Produkte auf Amazon nicht in der normalen Browser Session sondern im private Mode und bestellt in der normalen Sitzung sehr gezielt die ausgewählten Artikel. Resultat ist ein Profil mit Empfehlungen auf Amazon die genau meinem Kaufverhalten entsprechen und sehr wenig Angriffsfläche für Dinge die Amazon einfach nichts angehen.

Zum Thema Verhinderung gehört auch die Auswahl an Diensten welchen ihr eure Daten vertraut, bei mir selbst bekommt z.B. Google und Twitter die Daten aber Facebook eben nicht da ich dort keinen Account habe. Ich bin mir bewusst welche Daten in welchem Umfang dort liegen, möchte ich Daten dort nicht haben greife ich wieder auf meine gesonderte Sitzung (private Mode) zurück.

Wenn ihr nicht möchtet das Dienste eure Daten haben dann gebt ihm diese Daten nicht, ein Foto das ihr Privat auf Facebook teilt ist trotzdem ein Datensatz der für Facebook vorhanden und nutzbar ist.

Eigennützig

Oft ist es aber so das man die Ermittlung und Speicherung von Daten nicht wirklich verhindern kann, Dinge die auf meinem Smartphone sind behandle ich wie Dinge die ich Google geschenkt habe. Ich gebe mich nicht der Illusion hin Herr über diese Daten zu sein, aber ich versuche aus dieser unangenehmen Situation das für mich beste zu machen: Die Daten zu nutzen!

Das ist der Grund warum ich Dinge wie den Android Device Manager oder die Standortfreigabe von Google+ nutze, denn die Daten sind schon vorhanden, man kann diese eben nur nicht Einsehen. Durch die Verwendung dieser Standortdaten oder der Remote Administration bekomme ich auf der einen Seite einen gewissen Komfort und auf der anderen Seite bin ich mir auch zu einem größeren Teil bewusst welche Daten (und Möglichkeiten) der Anbieter wirklich hat.

Verschlüsselung

Verschlüsselung ist für dieses Thema "Datenschutz als Illusion" übrigens keine Lösung, auch bei einer Ende zu Ende Verschlüsselung fallen noch sehr viele Daten (Metadaten) an welche für viele Zwecke ausreichend sind. Spätestens dann wenn wir an große Anbieter (Google, Amazon) gehen um deren Dienste zu nutzen handelt es sich nur noch um eine Verschlüsselung für den Transport der Daten. Die Illusion etwas zu verbergen wird hierdurch beim Laien noch verstärkt da diese zu oft glauben das Verschlüsselung ja etwas mit Datenschutz zu tun hat, was eben nicht zwangsläufig so ist.

DNS Tools

Sat, 11 May 2013 15:00:55 +0000

Einer der am meisten unterschätzten Dienste im Internet und auch in vielen lokalen Netzwerken dürfte wohl der DNS Dienst sein. Erst wenn er ausgefallen ist bekommen wir zu spüren das nichts mehr funktioniert und Namensauflösung nicht gerade unwichtig ist. Zusätzlich gibt es durch sog. Virtual Hosts sogar die Anforderung eine funktionierende Namensauflösung zu haben, den ein Webserver mit mehreren Hosts benötigt in der Anfrage zwingend den Hostname und nicht nur eine IP die man sich vielleicht noch merken konnte.

Es gibt insgesamt 5 Tools für DNS welche ich sehr gerne benutze, das wären:

host: Der Standard um zu schauen ob man einen Namen oder eine IP aufgelöst bekommt.
dig: Für Profis das Tool der Wahl wenn es um DNS Records geht und ein Fehler zu suchen ist.
nsupdate: Änderungen an DNS Records ohne ein Zone File manuell bearbeiten zu müssen.
rndc: Nützliches Tool um den Bind Nameserver auf die Sprünge zu helfen.
dnstop: Schauen was im Netzwerk eigentlich los ist.

Ich werde diese jetzt nachfolgend mal kurz vorstellen, mehr Details gibt es in den Manpages ;-)

host

Ist wohl bei den ganzen DNS Tools das am weitesten verbreitete, es gibt davon viele verschiedene Implementierungen mit teilweise vielen besonderen Features. Die Grundlegende Funktion ist aber das Auflösungen von Rechnernamen zu IP Adressen und zurück. Alle weiteren Features sind Optional und je nach Implementierung nicht vorhanden. Die Anwendung von host erfordert keine Erläuterung:

[stefan@pc2007 ~]$ host server.hornynet
server.hornynet has address 192.168.1.1
server.hornynet has IPv6 address fd07:4763:c4fd:8192::1
[stefan@pc2007 ~]$ host 192.168.1.1
1.1.168.192.in-addr.arpa domain name pointer server.hornynet.

dig

Gerne darf es etwas mehr sein, und hierfür nutzt man in der Regel das Tool dig. Der größte und wichtigste Vorteil von dig gegenüber host ist der hohe Informationsgehalt:

[stefan@pc2007 ~]$ dig server.hornynet

; <<>> DiG 9.9.2-P2 <<>> server.hornynet
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14980
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;server.hornynet.               IN      A

;; ANSWER SECTION:
server.hornynet.        86400   IN      A       192.168.1.1

;; AUTHORITY SECTION:
hornynet.               86400   IN      NS      server.

;; Query time: 0 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Sat May 11 15:16:08 2013
;; MSG SIZE  rcvd: 80

Hier sehen wir unter anderem folgende Informationen:

Antwort auf unsere Anfrage
TTL Zeit vom Record (wichtig bei Sachen wie dynamischem DNS)
Zeit die der Nameserver für die Antwort benötigt hat
Welcher Server uns geantwortet hat
Ob es beim bearbeiten unserer Anfrage Probleme gab

Sehr wichtig aus dieser Liste ist vor allem, neben der eigentlichen Anfrage und ob diese Fehlerfrei beantwortet werden konnte, die Verarbeitungszeit vom Server. Bei vielen unterschiedlichen Anfragen welche relativ lange dauern summiert sich das bei heutigen Webanwendungen gerne mal auf mehrere Sekunden, da hilft dann auch eine vorhandene 100 MBit/s Leitung nicht mehr viel.

nsupdate

Um Änderungen am DNS durchzuführen hat man früher und auch heute noch in einigen Heimnetzwerken diese direkt in das entsprechende Zone File geschrieben. Das Zone File ist der Ort von welchem der DNS Server seine Informationen über einen bestimmten Bereich des DNS bezieht, meist also die eigenen Domains.

Das manuelle bearbeiten von Zone Files ist dabei relativ Fehler trächtig und erfordert Zugriff auf das Dateisystem des DNS Servers. Die wenigsten Provider werden daher dem Anwender direkten Zugriff auf diesen (wichtigen) Dienst geben. Um Änderungen auch Remote durchführen zu können gibt es das Tool nsupdate. Mit diesem Tool können einem DNS Server über ein definiertes Protokoll die Änderungen zugespielt werden, dieser schreibt diese (wenn valide) in das Zone File und informiert wenn erforderlich auch gleich Slave Nameserver. Der größte Vorteil ist das hierbei gleiche eine Syntaxprüfung durchgeführt wird und der Nameserver nicht neu gestartet werden muss.

In der Praxis sieht das Anlegen eines neuen Hosts dann so aus:

[stefan@pc2007 ~]$ nsupdate -l
> update add server.hornynet. 86400 A 192.168.1.1
> send

rndc

Speziell für mich als Freund des bind Nameservers ist auch rndc ein nützliches Tool. Es wird zur Verwaltung dieses Dienstes verwendet, aber nicht zum bearbeiten der Zone Files sondern wirklich nur für den Dienst an sich. Eine gängige Anwendung wäre das neu laden der Zonen, oder aber auch das Einfrieren einer Zone. Eine Zone die eingefroren ist kann nicht mehr über Tools wie nsupdate verändert werden. Man kann sich aber auch nur den Status vom Server geben lassen:

[root@server ~]# rndc status
version: 9.9.2-P2 (version.bind/txt/ch disabled)
number of zones: 39
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 0
query logging is OFF
recursive clients: 0/0/1000
tcp clients: 0/100
server is up and running

dnstop

Ein weiteres Tool welches ich gerne verwende, und auch das letzte in diesem Artikel, ist dnstop. Es handelt sich dabei um ein Tool welches auf einem Netzwerkinterface Traffic mitschneidet und Statistiken über den DNS Dienst anlegt.

Das ganze ist sehr informartiv, vor allem Datenschützer wundern sich immer wieder wie viele DNS Anfragen zu Diensten die man eigentlich nicht nutzen möchte rausgehen. Gleichzeitig kann man so auch sehen ob sich ggf. der Einsatz eines DNS Caches lohnt, den gerade bei Veranstaltungen im Bereich von > 20 Personen habe ich schon festgestellt das eine Fritzbox oder ein Telekom Speedport Router gerne mal bei vielen Anfragen in die Knie geht und die Gesamtperformance (wenn man davon bei einem SOHO Router überhaupt sprechen kann) spürbar leidet.

Fazit

Es lohnt sich mal die wichtigsten Tools anzuschauen, spätestens im Fehlerfall ist jedes dieser Tools Gold wert und spart wenn man damit umgehen kann viel Zeit.

SSH mit iptables schützen

Sun, 24 Mar 2013 14:24:29 +0000

Seit vielen Jahren habe ich schon diverse Server am laufen, viele davon sind direkt aus dem Internet erreichbar. Wer direkt aus dem Internet erreichbar ist, kann auch direkt über das Internet angegriffen werden. Ein gängiges und beliebtes Ziel für Angriffe ist der SSH Dienst, die Gründe dafür dürften zum einen dessen Verbreitung (jeder Linux Server hat diesen) und dessen Möglichkeiten (Shellzugang) sein.

In der Praxis gibt es viele Rechner im Internet welche automatisch nach verwundbaren SSH Versionen oder ungeschützten Zugängen (kein oder ein schlechtes Passwort) suchen. Das Problem mit den ungeschützten Zugängen löst man heute in der Regel mittels Public-Key-Authentifizierung, und die Sache mit den verwundbaren SSH Versionen lösen wir mit Updates. Als Administrator wissen wir das SSH sofort nach einem verfügbaren Update auch aktualisiert (und neu gestartet) werden muss.

In der Regel haben wir also mit SSH sehr wenig Probleme, das einzige was noch bleibt sind die vielen Meldungen welche uns die Angreifer im Logfile hinterlässt:

Mar 19 08:03:39 host.stefan-betz.net sshd[2967]: Received disconnect from
 223.4.183.127: 11: Bye Bye [preauth]
Mar 19 08:03:43 host.stefan-betz.net sshd[2981]: reverse mapping checking
 getaddrinfo for ip223.hichina.com [223.4.183.127] failed - POSSIBLE BREAK-IN ATTEMPT!
Mar 19 08:03:43 host.stefan-betz.net sshd[2981]: Received disconnect from
 223.4.183.127: 11: Bye Bye [preauth]
Mar 19 08:03:46 host.stefan-betz.net sshd[2999]: reverse mapping checking
 getaddrinfo for ip223.hichina.com [223.4.183.127] failed - POSSIBLE BREAK-IN ATTEMPT!
Mar 19 08:03:46 host.stefan-betz.net sshd[2999]: Received disconnect from
 223.4.183.127: 11: Bye Bye [preauth]
Mar 19 08:03:49 host.stefan-betz.net sshd[3025]: reverse mapping checking
 getaddrinfo for ip223.hichina.com [223.4.183.127] failed - POSSIBLE BREAK-IN ATTEMPT!
Mar 19 08:03:51 host.stefan-betz.net sshd[3025]: Received disconnect from
 223.4.183.127: 11: Bye Bye [preauth]
Mar 19 08:03:56 host.stefan-betz.net sshd[3057]: reverse mapping checking
 getaddrinfo for ip223.hichina.com [223.4.183.127] failed - POSSIBLE BREAK-IN ATTEMPT!
Mar 19 08:03:56 host.stefan-betz.net sshd[3057]: Received disconnect from
 223.4.183.127: 11: Bye Bye [preauth]
Mar 19 08:04:00 host.stefan-betz.net sshd[3087]: reverse mapping checking
 getaddrinfo for ip223.hichina.com [223.4.183.127] failed - POSSIBLE BREAK-IN ATTEMPT!

Ein wirksamer Schutz dies zu verhindern ist es die maximale Anzahl von Verbindungen auf einen bestimmten Dienst innerhalb einer bestimmten Zeit zu verhindern. Eine andere, von mir jedoch nicht benutzte Maßnahme, sind Dienste welche in den Logfiles schauen was passiert und dann diese IP Adressen sperren. Ich selbst bevorzuge immer Lösungen welche ohne zusätzliche Software auskommen, mit dem Hintergrund das jede Software die zusätzlich installiert wird auch zusätzliche Angriffsfläche zu Verfügung stellt.

Das filtern von IP Paketen ist unter Linux die Aufgabe von iptables, und daher nutze ich dies auch zur Absicherung meiner SSH Zugänge. Konkret werden folgende Regeln benötigt:

iptables -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent \
  --set --name SSH --rsource
iptables -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent \
  --update --seconds 60 --hitcount 4 --name SSH --rsource -j REJECT \
  --reject-with icmp-port-unreachable
iptables -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -j ACCEPT
ip6tables -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent \
  --set --name SSH --rsource
ip6tables -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent \
  --update --seconds 60 --hitcount 4 --name SSH --rsource -j REJECT
ip6tables -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -j ACCEPT

Wenn diese Befehle ausgeführt werden hat man 3 zusätzliche Regeln in seinem Paketfilter vom System installiert. Die erste Regel sorgt dafür das alle Pakete welche den SSH Dienst erreichen möchten, und den Status NEW haben erfasst und dem recent Modul bekannt gemacht werden. Das recent Modul führt eine Liste von Adressen und Ports und kann auf diese verschiedene Aktionen anwendern, z.B. prüfen wann zuletzt ein Paket von dieser Adresse kam.

Genau das machen wir uns bei der zweiten Regel zu nutze, jedes Paket muss auch durch diese Regel (die erste hat keine Aktion ausgeführt). Hier passiert aber was, und zwar wird bei jedem Paket (gleicher Status) ein Zähler aktualisiert auf den aktuellen Wert, gleichzeitig wird geprüft ob es das 4. Paket innerhalb von 60 Sekunden ist. Ist dies der Fall wird der Verbindungsaufbau abgelehnt, und unser Angreifer wird sich relativ schnell ein anderes Ziel suchen.

Die letzte Regel ist Optional wenn man keine weiteren Regeln hat, sie sorgt lediglich dafür das eingehende SSH Anfragen erlaubt werden. Da Regeln der Reihe nach abgearbeitet werden ist dies sehr sinnvoll, um sich nicht versehentlich von seinem System auszusperren. Einen kompletten Paketfilter werde ich an dieser stelle nicht Beschreiben.

Die Maßnahme hat genauso wie alle anderen Systeme die auf das sperren einer IP Adresse aufbauen natürlich auch einen Nachteil: Sitzt man zusammen mit dem Angreifer hinter einem NAT kommt man auch selbst nicht mehr auf den Server, die "angreifende" IP ist nämlich immer die gleiche. Hat man sich selbst ausgesperrt kann man einfach eine Minute warten, dann sind neue Verbindungen zum SSH Dienst wieder möglich, mal davon ausgehend das der böse Angreifer nicht immer noch im eigenen Netz sitzt und die Nachteile von NAT ausnutzt.

systemd Automount

Fri, 04 Jan 2013 08:10:10 +0000

Autofs ist ein vielen Administratoren bekannter Begriff, Ziel ist es ein Dateisystem beim ersten Zugriff einzuhängen. Vom Prinzip her eine sehr gute Idee, ich konnte das früher™ mal testen und war davon nicht begeistert. Das ganze ist jetzt aber schon einige Jahre her, und seitdem hat sich natürlich sehr viel verändert. Autofs und Automount behandle ich in diesem kurzem Artikel gleichberechtigt, auch wenn Autmount natürlich der Überbegriff für das automatische einhängen von Datenträgern ist.

Ein guter bekannter hat mich auf die Idee gebracht dem ganzen mal wieder eine Chance zu geben, und zwar in Form vom systemd automounter. Dieser macht Grundlegend erstmal nichts anderes, er bindet Dateisysteme beim ersten Zugriff ein.

Schon allein die Konfiguration unterscheidet sich aber vom normalen automount welcher via /etc/auto.master konfiguriert wird. Wir verwenden stattdessen einfach unsere /etc/fstab, ein Beispiel eines NFS Shares welches auf meinem System vorhanden ist:

server:/home /home nfs4 defaults,rw,nodev,nosuid 0 0

Wie man sieht würde das Dateisystem beim booten automatisch mit allen anderen Netzwerkdateisystemen eingehängt werden. Das ganze erfordert jedoch das die Netzwerkbindung für das Ziel (Target) network.target schon vorhanden ist.

Dies wird erreicht indem der systemd Service NetworkManager-wait-online.service aktiviert ist, welcher dafür sorgt das unser network.target eben erst verfügbar/erledigt ist wenn auch DHCP durchgelaufen ist. Der Bootvorgang wird hierbei für Dienste die von diesem Ziel abhängig sind natürlich blockiert.

Der entsprechende Eintrag um den automounter von systemd zu verwendet sieht wie folgt aus:

server:/home /home nfs4 defaults,rw,nodev,nosuid,noauto,x-systemd.automount 0 0

Zusätzlich können wir den oben genannten Zusatzdienst für Network Manager deaktivieren:

sudo systemctl disable NetworkManager-wait-online.service

Das war es schon mit der Konfiguration, mehr muss nicht gemacht werden. Beim nächsten Start vom System wird unser /home erst beim ersten Zugriff gemounted, bis DHCP durchgelaufen ist und das Netzwerkinterface bereit ist sollte auf den meisten Maschinen auch schon der GDM am laufen sein, perfekt.

Technisch passiert bei diesem ganzen Vorgang übrigens keine schwarze Magie, systemd legt durch systemd-fstab-generator beim starten für Einträge aus der fstab die x-systemd.automount gesetzt haben ein entsprechendes Unit an, wer möchte kann sich dies auch einmal anschauen (/run/systemd/generator/home.automount):

# Automatically generated by systemd-fstab-generator

[Unit]
SourcePath=/etc/fstab
DefaultDependencies=no
Conflicts=umount.target
Before=umount.target remote-fs.target

[Automount]
Where=/home

Auch in der Ausgabe vom Befehl mount taucht dies auf:

systemd-1 on /home type autofs (rw,relatime,fd=32,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)

Sobald das Dateisystem wirklich gemounted ist sieht man zusätzlich auch noch den normalen Eintrag vom jeweiligen Dateisystem.

Kritik an PPAs

Tue, 04 Sep 2012 11:48:25 +0000

Ein zentraler Ansatz der meisten heute verwendeten Linux Distributionen ist das man Software nicht wie unter Windows oder MacOS üblich mit einem Installationsprogramm installiert, sondern das man diese zentral über eine einzige Stelle bezieht: Die Paketverwaltung.

Nun, so eine Paketverwaltung selbst stellt diese jedoch noch nicht bereit, es ist nur ein Tool welches die Installation aus den sog. Paketquellen oder auch Repositories genannten Speicherorten ermöglicht.

Dieser Ansatz ist gut, der Anwender bekommt (hoffentlich) alles was er benötigt über eine zentrale Stelle, noch dazu werden Programme aus den für die Paketverwaltung verfügbaren quellen auch automatisch auf den neuesten (sicheren) Stand gebracht. Der Anwender muss sich also nicht wie z.B. unter Windows damit beschäftigen wie ein bestimmtes Programm auf die neueste Version aktualisiert werden kann.

Ein Nachteil davon ist allerdings das der Anwender eben nur Programme in der Version bekommt welche der Distributor vorsieht, z.B. ist Firefox oder LibreOffice bei den meisten Distributionen immer 1-2 Versionen hinter der aktuellen - oft sogar noch etwas mehr.

Eine Aktualisierung auf neue Versionen kann viele verschiedene Gründe haben, meistens sind es neue Funktionen oder ein kritischer Fehler welcher in der alten Version nicht behoben wurde und damit den Arbeitsablauf stört.

Der Anwender kann nun Software auf mehrere Arten aktualisieren, die gängigsten hierbei:

Das Paket an der Paketverwaltung vorbei bauen und installieren.
Das Paket für die jeweilige Distribution neu bauen und mit der Paketverwaltung manuell installieren.
Eine externe Quelle einfügen welche das entsprechende Paket bereitstellt.

Möglichkeit 1, also das Paket einfach schnell aus den Quellen bauen ist meistens die dümmste Idee. Bei einem Update des Systems kann es sein das die Paketverwaltung der Meinung ist (die weiß es ja) das bestimmte Dateien zu anderen Paketen gehören, bei der Installation des Paketes wurden diese jedoch ohne die Paketverwaltung zu informieren überschrieben oder anderweitig verändert. Mit der Zeit sorgen zunehmend mehr und mehr Pakete welche manuell gebaut, und oft nicht mehr sauber deinstalliert werden können, dazu das man ein System bekommt welches sich komisch verhält, vor allem wenn man sich mit der Paketverwaltung beschäftigt oder diese nutzt.

Möglichkeit 2 ist der richtige Ansatz, man baut das Paket für die auf dem System verwendete Paketverwaltung in der passenden Version. Gibt es Konflikte sorgt die Paketverwaltung dafür das diese aufgelöst werden, oder zumindest der Administrator (du!) eine Information über das Problem bekommt. Je nach Buildsystem ist dies mehr oder weniger umständlich, daher wird diese Methode von Laien gemieden :-/

Möglichkeit 3 beschreibt eine Methode bei welcher man seinem System eine oder mehrere zusätzliche Paketquellen unterschiebt. Es muss also nichts manuell gebaut werden, gleichzeitig bekommt man (mit etwas Glück) auch Aktualisierungen über eben diese zusätzliche Quelle.

Die PPAs, also Personal Package Archives, welche Ubuntu seinen Benutzern anbietet sind also eine Variante der Möglichkeit 3, eine zusätzliche Paketquelle.

Wie funktioniert das? Nun, ein Entwickler erstellt eine Anleitung zum Bau des Paketes, lädt diese in einem bestimmten Format in sein PPA und eine Maschine bei Canonical kümmert sich darum das ein Paket gemäß Anleitung gebaut wird. Gibt es hierbei einen Fehler bekommt der Entwickler die entsprechende Fehlermeldung, hat alles funktioniert steht dem Anwender die neue Version zu Verfügung. Bis jetzt klingt das ganze richtig toll, jemand anders kümmert sich darum für dich Pakete zu bauen, fast schon eine win-win Situation ;-)

Jetzt kommen aber die Probleme, bisher waren lediglich einige Mitarbeiter vom Distributor in der Lage dir etwas unsicheres auf dein System zu schieben. Inhalte von Paketquellen (egal welche) werden ja immer nur vom zuständigen Entwickler/Maintainer betreut und gewartet. Bei einem PPA jedoch kann jeder Pakete seiner Wahl einstellen, ich könnte also in mein PPA eine Apache Version hochladen welche mir ein Backdoor installiert. Auch könnte ich eine modifizierte Variante der libc auf deinem System installieren, alles was ich dazu machen muss ist das meine Version eine höhere Nummer als die vom Distributor hat.

Hintergrund ist das Paketverwaltungen bei der Installation nur relativ wenig Sachen prüfen:

Paket schon vorhanden?
Paketversion aktuell?
Abhängigkeiten?
Quelle vertrauenswürdig?
Gibt es Konflikte bei Dateien, gehört also eine Datei zu mehr als einem Paket?

Beim Punkt Quelle vertrauenswürdig? ist übrigens nur gemeint ob bestimmte Zertifikate und Signaturen der Pakete passen, nicht mehr, nicht weniger.

Natürlich gibt es Möglichkeiten der Paketverwaltung zu sagen das Pakete doch bitte standardmäßig nur aus Quelle X kommen sollen und andere müssen manuell installiert oder aktualisiert werden (Google: apt pinning), dies hilft jedoch nur jemandem der sich damit auskennt. Die meisten Laien werden ohne nachzudenken gemütlich ein PPA nach dem anderen aktivieren, wie weitreichend hierdurch vertrauen verschenkt/ausgesprochen wird ist den Anwendern aber in der Regel nicht bekannt.

Fazit / TLDR

Hier nur ein paar Stichpunkte, zum nachdenken:

PPAs können dir Software installieren welche du nicht möchtest, das geht sehr einfach z.B. mit Abhängigkeiten von Paketen.
Signaturen von Paketen oder Paketquellen sorgen dafür das ein Paket nicht nach dem Bau verändert wurde, es hat nichts damit zu tun ob ein Entwickler vertrauenswürdig ist, oder eben nicht ;-)
PPAs können, wenn diese schlecht gebaut wurden, sehr effektiv dafür sorgen das ein Update deines Systems Probleme macht oder nach dem Update bestimmte Programme ein komisches/unerwartetes verhalten an den Tag legen.

Vermeidet also PPAs wenn es möglich ist, das kann einem jede Menge ärgern sparen ;-)

Shared Pacman Cache aufräumen lassen

Fri, 23 Dec 2011 13:02:00 +0000

Gerade wenn man etwas mehr Rechner in seinem kleinem (oder auch großem) Netz hat, ist ein Cache für Paketdaten sehr sinnvoll. Es ist nicht zielführend jedes Paket für jeden Rechner immer und immer wieder aus dem Netz zu laden. Denn zum einem wird dadurch natürlich die WAN Anbindung (DSL, ISDN, Modem, Brieftauben) belastet, und auf der anderen Seite spielt natürlich jeder Rechner im Netz Cache für die selben Daten, was Speicherplatz verschwendet (denkt doch auch mal an die Festplattenkrise).

Im sinne der Deduplizierung ist es also ganz sinnvoll diesen Cache in das eigene NAS zu verlegen, das spart Platz und Updates gehen ab dem 2. PC deutlich schneller!

Wie dies eingerichtet wird erklärt das tolle Wiki von Arch Linux in einem Wikiartikel, und wird hier in diesem Blog nicht behandelt.

Was man gerne übersieht, aber auch in diesem Artikel steht ist das man

CleanMethod = KeepCurrent

in seine /etc/pacman.conf zumindest auf dem Server packen sollte. Hat man dies getan kann man über pacman -Sc am Server den kompletten Cache säubern, was ein voll laufen des Dateisystems verhindert.

Ich selbst bin noch ein wenig fauler, und habe mir einen Cronjob erstellt der pacman -Sc --noconfirm einmal pro Monat auf dem Server startet, wozu soll ich mich selbst ums Putzen kümmern wenn es doch Computer gibt ;-)

Datensicherung / Backups

Mon, 22 Aug 2011 16:46:00 +0000

Ein wichtiges Thema in der IT, wenn nicht sogar das Kernthema überhaupt, sind ja Datensicherungen oder im neudeutsch Backups.

Das Problem mit der Datensicherung fängt schon bei der Wahl des Speichermediums an:

Disketten / ZIP: Eine endlich ausgestorbene Technik, heute sind die Probleme die Unzuverlässigkeit, Kapazität und vor allem die mangelnde Verfügbarkeit solcher Laufwerke. Eine Datensicherung auf diesen Medien ist also nichts was man in Betracht ziehen sollte.
CD / DVD / BluRay: Auch wenn man auf den ersten Blick denkt ein optisches Medium ist eine gute Idee, sollte man sich das nochmal durch den Kopf gehen lassen. Hauptproblem ist das immer wieder mal Rohlinge verbrannt werden oder eine Lesbarkeit selbst nach 1-2 Wochen nicht gewährleistet ist. Die Qualität der Medien schwankt gewaltig und die Datenmenge welche man Gesichert bekommt ist, mit Ausnahme der BluRay, für heutige Verhältnisse viel zu klein.
USB Laufwerke: USB Laufwerke gibt es angefangen vom USB Stick bis hin zu mehreren Terabyte großen Festplatten in jeder Preisklasse. Nachteil ist hierbei das die Medien empfindlich auf Überspannung reagieren und ein Anschluss am PC auf Dauer nicht sinnvoll ist, da sonst gerne mal ein Blitz Daten und Datensicherung gleichzeitig hinrichtet. Nachteil dieser Technik ist das der USB Anschluss (von Version 3.0 mal abgesehen) viel zu langsam ist um große Datenmengen zügig zu kopieren. Auch belastet eine über USB angeschlossene Platte das System deutlich mehr als eine über SATA oder IDE angeschlossene Platte.
Festplatten im Wechselrahmen: Das oben genannte Problem mit der Geschwindigkeit kann man einfach mit Festplatten in einem Wechselrahmen umgehen, diese sind an die SATA Schnittstelle angeschlossen und können daher auch große Datenmengen schnell übertragen. Auch die eSATA Schnittstelle eignet sich hier prima, ist aber nicht immer verfügbar. Da es sich beim Datenträger um normale SATA Platte handelt ist, zumindest für die nächsten 4-5 Jahre eine Anschlussmöglichkeit in jedem Standard-PC vorhanden, über entsprechende Adapter auch an USB, FireWire oder eSATA.

Ignorieren wir, aus technischen Gründen, einfach mal die optischen Laufwerke so haben wir noch Festplatten über USB oder intern zur Auswahl. USB Sticks dürften für die meisten Anwendungen zu Teuer pro Gigabyte sein.

Jetzt haben wir noch ein Problem, das leider immer wieder Leute vergessen: Alles was mit dem Stromnetz verbunden ist, sei es direkt oder indirekt wird unter Umständen durch einen Blitzeinschlag zerstört. Selbst externe Platten die neben einer Leitung liegen können durch Induktionsspannungen zerstört werden. Eine Datenrettung für kleine Firmen oder Privatpersonen ist unbezahlbar, daher ist es wichtig wie man mit den Sicherungsmedien umgeht. Nachfolgend hierzu ein paar Tipps:

Ein Datenträger der mit dem Rechner Verbunden ist (USB, eSATA, SATA, Strom, Netzwerk, ...) ist kein Sicherungsmedium da dies bei vielen Problemen mit zerstört wird. Auch ist ein löschen der Daten aus versehen möglich.
Man hat immer mindestens 2 Backups seiner Daten, auf unterschiedlichen Datenträgern, welche nicht am selben Ort gelagert sind.
Daten die nicht gesichert sind, sind auch nicht wichtig.
Datensicherungen macht man immer automatisch, der Mensch vergisst Datensicherungen zu machen, nicht gesicherte Daten sind auch nicht wichtig.
Vor großen Änderungen (Betriebssystem Installation, neues Dateisystem, ...) macht man immer vorher ein Backup.
Sicherungsmedien werden regelmäßig geprüft, dies gilt für das Medium (SMART, badblocks, ...), das Dateisystem (fsck) und auch für die Nutzdaten.
Das Datensicherungsprogramm sollte Dateien immer einzeln Komprimieren und/oder Verschlüsseln, nie alle Dateien auf einmal wie es z.B. tar macht. Das Problem ist das bei einem einzigen kaputten Bit schon das komplette Backup unbrauchbar sein kann. Moderne Backup Tools wie dar (kein Schreibfehler!) erledigen diesen Job richtig.
Nicht nur die Daten, sondern auch die Rechte an den Daten sind oft wichtig, daher sollte das Backuparchiv oder Dateisystem die gleichen Rechte unterstützen wie das Quelldateisystem.

Ich selbst habe hierzu 2 SATA Festplatten in einem Wechselrahmen, jede Kalenderwoche werden diese Platten getauscht. Einmal täglich machen die PCs automatisch ein Backup auf diese Platte, die jeweils nicht eingebaute Platte wird in einem anderem Raum gelagert um zu vermeiden das alles an einem Ort ist. Die Platten werden durch ein Script auch jede Woche geprüft!

Nachteil dieser Lösung ist der Kostenaufwand im Vergleich zu einer USB Festplatte, Vorteil ist das ich nie mehr als eine Woche an Daten verliere. Außer ein Einbrecher würde kommen und mein Haus nach allen Laufwerken absuchen und mir alle Medien auf einmal klauen. Anderes Worst-Case Szenario das ich so nicht abdecke wäre ein Hausbrand, was jedoch hoffentlich nicht vorkommen wird.

Dorf DSL mit langer Leitung

Wed, 15 Sep 2010 14:35:00 +0000

Es ist immer wieder erstaunlich, wie stabil doch ein DSL-Anschluss auf einer eigentlich schlechten Leitung läuft. Aber seht einfach selbst, was mir DMT bei einem Kunden für ein Teledat 431 LAN verraten hat:

Da die Telekom ja schon seit längerem an der Bitratenadaptiven-Schaltung rumprobiert, wäre es interessant zu wissen, ob das bei dieser Leitung noch einen Tick mehr Bandbreite bringen würde.

DMT ist übrigens eines meiner Lieblingstools für Windows. Es gibt auch eine Alternative für Linux, doch diese habe ich bis jetzt noch nicht kompiliert bekommen.

SSH Tuning

Tue, 24 Aug 2010 15:56:00 +0000

Wer wie ich oft SSH verwendet und sich gerne darüber aufregt das ein Login bei großen Schlüsseln (z.b. 4096 Bit) oft lange dauert kann SSH etwas pimpen.

OpenSSH kann nämlich sog. Multiplexing, d.h. es kann mehrere Sessions zum gleichen Server über nur eine Verbindung verwalten. Der Vorteil ist das man sich nicht über jeden Channel neu Authentifizieren muss, und somit die neue Session ziemlich schnell verfügbar ist. Nachteil ist natürlich das beim Abbruch der einen TCP Verbindung auch alle Sessions auf einmal weg sind :-/

Das ganze wird folgendermaßen in der ~/.ssh/config konfiguriert:

ControlMaster auto
ControlPath /tmp/ssh-%h-%r-%p

ControlPath sorgt dafür das der Modus aktiviert wird und automatisch eine neue multiplex Session gestartet wird wenn es noch keine gibt. Als Pfad für das nötige Controlsocket wird der unter ControlPath angegebene Pfad verwendet. Die Platzhalter werden prima in der Manpage von ssh_config erklärt (man 5 ssh_config).

Wenn man in der ssh_config spezifische Einstellungen für bestimmte Hosts hat sollte man diese Einstellungen ganz oben in die Datei schreiben, so das diese für jeden Host gelten.

Mit dem neuen OpenSSH 5.6 das gestern veröffentlich wurde gibt es noch eine zusätzliche, aber sehr nützliche Option:

ControlPersist on

Was dafür sorgt das auch beim schließen der letzten noch aktiven Session die Verbindung für immer aktiv bleibt. Natürlich sollte man aus Sicherheitsgründen statt on lieber 10m Eintragen was für 10 Minuten steht.

Hochzeit: Squid 3 und Active Directory

Mon, 24 Nov 2008 16:16:00 +0000

Nein, ich heirate nicht. Aber ich habe Squid 3 erfolgreich mit einem Active Directory verkuppelt.

Vorbereitungen

Unter Windows muss folgendes erledigt sein:

Proxy Server muss im Microsoft DNS Dienst bekannt sein
Proxy Server muss als “Trusted Host” im AD angelegt sein

Der Proxy Server sollte entweder eine “richtige” statische IP, oder auch eine Reservierung via DHCP haben. Auch muss die Uhrzeit mit NTP Synchron gehalten werden, den Kerberos ist sehr pingelig was das angeht!

Auf der Linux Seite benötigt man natürlich den root-Account, oder ähnliche Rechte (sudo usw…). Alle nachfolgenden Befehl müssen als root eingegeben werden!

Proxy Server

Auf dem Proxy Server selbst braucht man folgende Pakete:

krb5-user
squid3
winbind

Kerberos Setup

Die Kerberos Konfigurationsdatei (/etc/krb5.conf) sollte so aussehen:

[libdefaults]
 default_realm = DOMAIN
[realms]
 DOMAIN = {
  kdc = 192.168.1.1
  admin_server = 192.168.1.1
 }
[domain_realm]
.domain = DOMAIN
[appdefaults]
pam = {
 ticket_lifetime = 1d
 renew_lifetime = 1d
 forwardable = true
 proxiable = false
 retain_after_close = false
 minimum_uid = 1
}

In meinem Fall war DOMAIN der Domänenname und 192.168.1.1 dessen IP-Adresse. Es ist natürlich wichtig das man dafür eine Funktionierende Namensauflösung hat, Optimal ist es wenn man dafür den DNS Server vom AD nimmt. Da sollte ja ohnehin alles drin sein was man braucht.

Natürlich ist für das Kerberos Setup ein Test nicht schlecht:

kinit user@DOMAIN

Man wird nun nach dem Passwort für den AD-User user gefragt. Wenn alles geklappt hat bekommt man von klist folgende Ausgabe:

Ticket cache: FILE:/tmp/krb5cc_0
Default principal: user@DOMAIN

Valid starting    Expires           Service principal
11/26/08 20:57:19 11/27/08 06:57:20 krbtgt/DOMAIN@DOMAIN
        renew until 11/27/08 20:57:19

Kerberos 4 ticket cache: /tmp/tkt0
klist: You have no tickets cached

So sieht man das man erfolgreich ein TGT (eine Art “Chef-Ticket”) bekommen hat, mit diesem könnte man dann Ticket für einzelne Dienste anfordern, was uns aber jetzt nicht weiter interessiert.

Samba / Winbindd Setup

Nachdem jetzt Kerberos läuft, können wir an den nächsten Schritt gehen: Samba (genauer Winbind) will jetzt Domänenmitglied werden, und das geht mit so einer /etc/samba/smb.conf:

[global]
workgroup = DOMAIN
realm = DOMAIN
password server = HOSTNAME.DOMAIN
security = ADS
winbind refresh tickets = yes
idmap uid = 10000-20000
idmap gid = 10000-20000
winbind enum users = yes
winbind enum groups = yes
winbind cache time = 10
winbind use default domain = yes

password server muss der DNS Name vom AD Server sein. Der Rest dürfte selbsterklärend sein. Nun kann man der Domäne beitreten:

net ads join -U user@DOMAIN

Dannach kann man den winbindd starten, was wie gewohnt über

/etc/init.d/winbbind start

geht. Ob dies funktioniert hat kann man mit wbinfo -t prüfen:

checking the trust secret via RPC calls succeeded

Dann kann man auch noch die Gruppen im AD anzeigen lassen, dies geht mit wbinfo -g:

gruppe1
gruppe2
gruppe3
usw...

Damit Squid (genauer ntlm_auth) auch was mit Winbind Anfangen kann muss das Verzeichnis /var/run/samba/winbindd_privileged der Gruppe windbind_priv gehören, und von dieser Lesbar sein.

Squid Setup

Jetzt kommt der letzte Schritt, und zwar die Anpassung der /etc/squid3/squid.conf, hier gehört folgendes noch mit rein:

auth_param ntlm program /usr/bin/ntlm_auth --require-membership-of=DOMAIN\\GRUPPE --helper-protocol=squid-2.5-ntlmssp
auth_param ntlm children 10
auth_param basic program /usr/bin/ntlm_auth --require-membership-of=DOMAIN\\GRUPPE --helper-protocol=squid-2.5-basic
auth_param basic children 5
auth_param basic realm Domain Proxy Server
auth_param basic credentialsttl 2 hours
auth_param basic casesensitive off
authenticate_cache_garbage_interval 10 seconds
authenticate_ttl 0 seconds
acl AuthorizedUsers proxy_auth REQUIRED
http_access allow all AuthorizedUsers

Von dem Parameter cache_effective_user bzw. cache_effective_group sollte man die Finger lassen (die Zeile sollte also ein Kommentarzeichen am Anfang haben), da sonst ntlm_auth nicht mit den nötigen Rechten läuft.

Es ist wichtig das der User proxy auch in der Gruppe winbindd_priv ist:

sudo adduser proxy winbindd_priv

Mit diesen Einträgen erreicht man das SSO bevorzugt wird, jedoch auch noch der alte Benutzername/Passwort Dialog möglich ist. Dies ist vor allem dann sinnvoll wenn man nicht nur NTLM fähige Clients hat. Ich habe bei der Gelegenheit auch gleich eingestellt das nur Mitglieder der AD Gruppe GRUPPE das Recht haben ins Internet zu gehen, was gerade in großen Firmen gewünscht wird.

Jetzt kann man mit /etc/init.d/squid3 start den Squid Proxy starten, und kann einen Test unter Windows machen (z.b. mit dem Internet Explorer). Das der Proxy Server auch schön auf den Clients eingetragen wird, davon gehe ich jetzt einfach mal aus.

SystemRescueCD aus /boot starten

Wed, 22 Oct 2008 15:48:00 +0000

Wer kennt es nicht, es gibt nen neuen Kernel aber der will ausgerechnet nicht booten. In diesem Fall gibt es genau diese 3 Möglichkeiten(Neuinstallation ist für mich keine Alternative!!!):

Man hat noch einen älteren, Funktionsfähigen Kernel auf /boot
Man sucht im ganzen Haus nach einer CD mit der man chroot machen könnte
Man hat wie ich eine SystemRescueCD Bootfähig im /boot liegen haben

Vorbereitung

SystemRescueCD Herunterladen
ISO Image der SystemRescueCD als Loop mounten

sudo mkdir /tmp/sysrcd
sudo mount /pfad/zum/iso/der/systemrescuecd.iso -o loop,ro -t iso9660 /tmp/sysrcd

Installation

Man benötigt von der ganzen CD nur 4 Dateien, das wären:

rescuecd (der Kernel, auf 64-Bit Systemen sollte man rescue64 nehmen)
initram.igz (die Initial Ramdisk)
sysrcd.dat (Root Dateisystem der SystemRescueCD)
sysrcd.md5 (MD5 Prüfsummen der sysrcd.dat)

Der Kernel und die Initial Ramdisk müssen direkt nach /boot kopiert werden. Für das Rootimage (sysrcd.dat sowie sysrcd.md5) muss man etwas nachdenken:

Hat man eine extra /boot Partition (wie jeder der LVM oder RAID hat) so muss man die Dateien nach /boot/sysrcd kopieren (Verzeichnis sollte man natürlich anlegen).
Hat man kein extra /boot so sollte man es einfach direkt in /boot kopieren!

Folgende Befehl würde auf einem System mit extra /boot zum Ziel führen:

sudo -i
mkdir /boot/sysrcd
cp /tmp/sysrcd/isolinux/rescuecd /boot/
cp /tmp/sysrcd/isolinux/initram.igz /boot/
cp /tmp/sysrcd/sysrcd.* /boot/sysrcd/

Hat man ein System ohne extra /boot wäre es folgendes:

sudo -i
cp /tmp/sysrcd/isolinux/rescuecd /boot/
cp /tmp/sysrcd/isolinux/initram.igz /boot/
cp /tmp/sysrcd/sysrcd.* /boot/

GRUB Konfigurieren

Natürlich könnte man jetzt schon booten, aber sinnvoller ist es schon dafür einen Eintrag im GRUB zu machen, das würde auf einem System mit extra /boot Partition so aussehen:

title SystemRescueCD
root (hd0,0)
kernel /rescuecd setkmap=de docache subdir=sysrcd
initrd /initram.igz

Ohne eine extra /boot Partition sieht es dann so aus:

title SystemRescueCD
root (hd0,0)
kernel /boot/rescuecd setkmap=de docache subdir=boot
initrd /boot/initram.igz

Am besten schreibt man dies ans Ende der /boot/grub/menu.lst, im Idealfall sogar hinter dieser Zeile damit update-grub uns keinen Strich durch die Rechnung macht:

### END DEBIAN AUTOMAGIC KERNELS LIST

Das man die Befehle usw. an seine Eigene Konfiguration anpassen muss, davon gehe ich jetzt einfach mal aus! Wenn man meinen Schnipsel aus der menu.lst verwendet hat man automatische ein Deutsches Tastaturlayout und läd das Image in den RAM (auf Systemen mit weniger als 512MB RAM geht das natürlich nicht).

Debian Installer mit bereits vorhandenem verschlüsseltem LVM verwenden

Mon, 20 Oct 2008 18:14:00 +0000

Oft hat man das Problem, dass man ein 2. Debian oder Ubuntu im selben verschlüsselten [LVM](http://de.wikipedia.org/wiki/Logical Volume Manager) installieren will wie ein schon vorhandenes. Dies kann z.B. zum Testen ganz praktisch sein. Leider hat der Debian Installer auch heute noch nicht die Funktion um ein dm-crypt verschlüsseltes LVM richtig zu erkennen. Deswegen hier mal ein wenig wie man das Ganze ohne Umpartitionierung oder debootstrap lösen kann.

Vorbereitung

Debian Installer starten und bis zu dem Punkt gehen wo die Netzwerkkonfiguration stattfindet (wenn man schon im Partitionierungstool ist einfach mit zurück in die Hauptauswahl gehen!)
ALT+F2 drücken und das Terminal mit Enter aktivieren
Diese Befehle ausführen:

depmod -a
modprobe dm-mod
modprobe dm-snapshot
cryptsetup luksOpen /dev/sda2 sda2_crypt
vgchange -a y

Jetzt hat man nur noch das Problem, dass der Debian Installer nicht erkennt, dass man LVM verwalten könnte, er erkennt zwar die Volumes zeigt aber nicht das Menü zum Verwalten von LVM an. Das ist natürlich für eingefleischte LVM Administratoren kein Problem, für alle anderen könnte dieser Crashkurs hier vielleicht hilfreich sein:

Freien Platz anzeigen

Den freien Platz in vorhandenen Volume Groups kann man mit vgs anzeigen:

~ # vgs
  VG   #PV #LV #SN Attr   VSize   VFree
  main   1   7   0 wz--n- 465,57G 206,57G

Volumes anzeigen

Natürlich kann man auch einfach mit lvs vorhandene Volumes anzeigen lassen:

~ # lvs
  LV         VG   Attr   LSize   Origin Snap%  Move Log Copy%
  home       main -wi-ao 100,00G
  images     main -wi-ao  50,00G
  music      main -wi-a-  40,00G
  root       main -wi-ao  20,00G
  swap       main -wi-ao   2,00G
  tmp        main -wi-ao   2,00G
  virtualbox main -wi-ao  45,00G

Volumes anlegen

So würde man ein 5 GByte großes Volume mit dem Namen Name in der Volume Group group anlegen:

lvcreate --size 5G --name Name group

Snapshot anlegen

Für Volumes wie /home kann es natürlich sinnvoll sein vor der Installation einen Snapshot (wofür natürlich auch wieder dm-snapshot geladen sein muss) zu machen, das würde wie folgt funktionieren:

lvcreate --snapshot --size 5G --name homesnap /dev/group/home

Installation Fortsetzen

Um im Installer weiterzukommen wechselt man nun einfach mit ALT+F1 das Terminal und schon kann man wie gewohnt die Installation fortsetzen. Bitte beachte wirklich, dass der Installer neue Volumes usw. nur dann erkennt wenn man Partman neu aufruft, dies geht am einfachsten über zurück bis man im Hauptmenü vom Installer ist.