• Starke Verschlüsselung: Das Backup muss sicherer sein als diese unsägliche ZIP-Verschlüsselung hinreichend sicher sein und ein statistischer Angriff soll keinen Erfolg versprechen.

• Gute Komprimierung: Ich möchte in kurzer Zeit das Backup klein eindampfen können und beim Zugriff effizient entpacken, also nur die Dateien, die ich benötige.

• Mountbares Backup: Ganz ohne vorheriges Entpacken soll ein sofortiger Zugriff auf alle Dateien im Backup möglich sein.

• Keine unverschlüsselten temporären Dateien: Weder beim Packen noch beim Entpacken sollen unverschlüsselte temporäre Dateien anfallen, einerseits aus Sicherheitsgründen, andererseits weil eine temporäre Datei auf einem zufällig verschlüsselten Dateisystem Prozessorlast erzeugt.

Bis vor kurzem habe ich einfach Archive mit Tarballs mit Twofish verschlüsselt (openssl bietet ein komfortables Subkommando) und diese auf DVD gebrannt. Neben den oben genannten Nachteilen kam das Problem dazu, dass auf einem ISO-9660-Dateisystem die Dateigrößengrenze bei 2GB lag.

Meine Lösung sah eine Kombination aus bekannten Technologien vor: Eine Containerdatei sollte per losetup zum blockorientierten Gerät mutieren, dort wiederum sollte mit cryptsetup ein verschlüsselter Datenträger entstehen, der wiederum ein komprimiertes Squashfs-Dateisystem aufnehmen sollte. Klingt kompliziert? Ist es aber nicht:

Benötigt werden die im Tutorial /home reisetauglich verschlüsselt erwähnten Pakete und die squashfs-tools sowie SquashFS-Module für den laufenden Kernel.

Anlegen des Containers und Befüllen mit Daten

Zuerst wird ein Container angelegt, verschlüsselt und dann mit Daten gefüllt

• Erstellen des Containers: Ein Sparse-File mit der maximal zulässigen Größe einer DVD5 (4700372992 Bytes oder 2295104 Blöcke — bei einer DVD9 müssten es 4150388 Blöcke sein) entsteht mit dem folgenden Befehl. Die Datei belegt am Anfang nur 2048 Byte, angezeigt wird dennoch die maximale Größe:

  dd if=/dev/zero bs=2048 count=1 seek=2295103 of=crypt_squash.data

• Erstellen eines Loop-Devices: Mittels losetup entsteht jetzt eine der Datei zugeordnete Blockdevice:

  losetup /dev/loop0 crypt_squash.data

  Sollte /dev/loop0 bereits besetzt sein, zeigt losetup -f freie Loop-Devices.

• Erstellen des Containers: Auf der Loop-Datei wird nun das verschlüsselte Blockgerät vorbereitet:

  cryptsetup luksFormat -c aes-cbc-essiv:sha256 -s 256 -y /dev/loop0

• Öffnen des verschlüsselten Gerätes: Nun wird die verschlüsselte Gerätedatei geöffnent. Das Resultat ist ein Blockdevide /dev/mapper/cryptdvd auf das geschrieben werden und von dem gelesen werden kann. Die Verschlüsselung erfogt hier komplett transparent:

  sudo cryptsetup luksOpen /dev/loop0 cryptdvd

• Erstellen des komprimierten Dateisystems: In /dev/mapper/cryptdvd entsteht nun das komprimierte Dateisystem SquashFS. Weil wir in eine Gerätedatei schreiben, muss explizit -noappend angegeben werden, um diese zu überschreiben. Die restlichen Parameter sind Kosmetik: Ich bevorzuge noch aus Kompatibilitätsgründen Komprimierung mit gzip und möchte nur einen Prozessor einspannen.

  mksquashfs Projekte WichtigeDaten /dev/mapper/cryptdvd  -nolzma -check_data -noappend -processors 1

Test des Containers

Nun ist der Test des Containers dran. Funktioniert das Backup so, wie wir es uns vorgestellt haben?

• Mounten des Containers: Das Cryptdevice existiert ja noch, mounten wir es einfach:

  mkdir /tmp/cryptdvd
  mount /dev/mapper/cryptdvd /tmp/cryptdvd/

  Falls ein unbekanntes Dateisystem angegeben wird, sollten Sie sicherstellen, dass das SquashFS-Modul geladen ist und gegebenenfalls den Dateisystemtyp angeben:

  mount -t squashfs /dev/mapper/cryptdvd /tmp/cryptdvd/

• Unmounten:

  umount /dev/mapper/cryptdvd

• Auflösen des Cryptdevices:

  cryptsetup luksClose /dev/mapper/cryptdvd

• Lösen des Loop-Devices: So stellen wir sicher, dass auch alle Daten im Container gelandet sind und wir gefahrlos brennen können:

  losetup -d /dev/loop0

Brennen der DVD

• Brennen der DVD: cdrecord ist es herzlich egal, was für Daten da gebrannt werden, es bannt unseren Container 1:1 auf den optischen Datenträger:

  cdrecord -v -speed=4 -dev=/dev/scd1 crypt_squash.data

Test der gebrannten DVD — Mounten und Unmounten des Backups

• Loop-Device erstellen: Zunächst entsteht ein Loopdevice auf der gebrannten DVD. Es könnte eigentlich auch ohne funktionieren:

  losetup /dev/loop1 /dev/scd1

• Öffnen des Crypt-Devices: Jetzt wird die Datei /dev/mapper/cryptdvd erzeugt, welche die Entschlüsselung transparent macht. Hier ist die Eingabe des Passwortes erforderlich:

  sudo cryptsetup luksOpen /dev/loop1 cryptdvd

• Mounten des Dateisystems: Möglicherweise ist die Angabe des Dateisystemtyps erforderlich:

  mount /dev/mapper/cryptdvd /tmp/cryptdvd/

• Unmounten wie oben:

  umount /dev/mapper/cryptdvd

• Lösen des Crypt-Devices:

  cryptsetup luksClose /dev/mapper/cryptdvd

• Lösen des Loop-Devices:

  losetup -d /dev/loop1

  Nun kann die DVD entnommen werden.

Die meisten der angegebenen Schritte lassen sich leicht automatisieren, so dass sichere Backups sehr einfach durchgeführt werden können und der Zugriff genauso einfach möglich ist. Ein Manko bleibt: Für das Hinzufügen neuer LUKS-Schlüssel muss der Container natürlich mit dd auf Festplatte transferiert und in ein Loop-Device überführt werden, bevor er neu gebrannt wird.

Nachtrag I: Ich stelle diesen Artikel hiermit unter BY-SA zur Verfügung. Wer möchte, kann ihn also per Copy und Paste ins UbuntuUsers-Wiki (oder andere Wikis) übernehmen und dort weiterbearbeiten, solange auf mich als Urheber verwiesen wird. Viel Spaß damit! creativecommons.org/licenses/by-sa/3.0/de/

Nachtrag II: Da einige Community-Wikis NC-BY-SA verwenden und BY-SA nicht nach NC-BY-SA überführt werden kann, zusätzliche Bereitstellung unter NC-BY-SA. Viel Spaß damit! creativecommons.org/licenses/by-nc-sa/3.0/de/

Bei einer näheren Kontrolle wird jedoch die verschlüsselte Partition gefunden werden. Die Verschlüsselung selbst ist zwar so stark wie Ihr Login-Passwort, in der Praxis entscheidet über die Knackbarkeit der Verschlüsselung aber die Tiefe der “Kryptanalyse” des bereisten Staates: Wer Länder bereist, die Gartenschlauch-Kryptanalyse betreiben, sollte ein aufwendigeres Verschlüsselungsmodell mit geschachtelten Containern (TrueCrypt) verwenden, welches allerdings umständlicher zu nutzen ist.

Software-Installation und Vorbereitung der Partition

Zunächst muss etwas Software nachinstalliert werden:

sudo apt-get install cryptsetup libpam-mount

Rebooten Sie anschließend, um sicherzustellen, dass alle Bibliotheken richtig geladen werden.

Nun geht es um die Identifikation der Partition. Prüfen Sie mit fdisk -ul die Partitionierung des Ziellaufwerkes und stellen Sie sicher, dass es nicht gemoutet ist. Mein Ziellaufwerk war die im Kartenslot steckende SD-Karte, deren erste Partition ich mit fdisk mit einer normalen Linux-Partition versah. Hier die Partitionierung:

Platte /dev/sdb: 4029 MByte, 4029677568 Byte
233 Köpfe, 63 Sektoren/Spuren, 536 Zylinder, zusammen 7870464 Sektoren
Einheiten = Sektoren von 1 × 512 = 512 Bytes
Disk identifier: 0x00000000

   Gerät  boot.     Anfang        Ende     Blöcke   Id  System
/dev/sdb1              63     7867943     3933940+  83  Linux

Verschlüsseln der Zielpartition

Zunächst sollten die ersten Megabyte der Zielpartition mit Zufallszahlen überschrieben werden. In diesem Bereich sitzen später die LUKS-Schlüssel, die sich nicht von den umgebenden Daten abheben sollten:

sudo dd if=/dev/urandom of=/dev/sdb1 bs=1M count=2

Im nächsten Schritt wird die Verschlüsselung der Partition vorbereitet. Sie erhält noch kein Dateisystem. Geben Sie das Passwort an, welches später als Login-Passwort verwendet werden wird:

sudo cryptsetup luksFormat -c aes-cbc-essiv:sha256 -s 256 -y /dev/sdb1

Mit dem Subkommando luksOpen wird die verschlüsselte Partition als Gerätedatei verfügbar gemacht. Ich verwendete /dev/mapper/mattias, weil die verschlüsselte Partition mein Heimatverzeichnis aufnehmen soll.

sudo cryptsetup luksOpen /dev/sdb1 mattias

Eine verschlüsselte Partition sollte möglichst kein Muster erkennen lassen und keine Reste der früher enthaltenen unverschlüsselten Daten aufweisen. Recht pragmatisch ist es daher, Nullen als Eingabe zu nutzen, die verschlüsselt ein scheinbar zufälliges Muster ergeben. Wenn nicht große Teile des Ziellaufwerkes mit Daten belegt werden, erleichtert die Kenntnis der Plaintext-Daten (hier der Ansammlung von Nullen) das Knacken des Schlüssels. Um auf Nummer sicher zu gehen können Sie statt /dev/zero daher /dev/urandom als Eingabedatenstrom verwenden — allerdings dauert dann das “randomisieren” deutlich länger:

sudo dd if=/dev/zero of=/dev/mapper/mattias bs=8192

Nun endlich kann die verschlüsselte Partition mit einem Dateisystem versehen und gemountet werden:

sudo mkdir /tmp/home_mattias
sudo mkfs.ext3 /dev/mapper/mattias
sudo mount /dev/mapper/mattias /tmp/home_mattias

Kopieren der Daten

Damit sichergestellt ist, dass keine meiner Dateien geöffnet sind, habe ich zunächst ein Root-Passwort vergeben, rebootet und mich dann auf einer Konsole ([Strg]+[Alt]+[F2]) als Root angemeldet:

sudo passwd

Das Kopieren der Dateien erledigt nun rsync, fancy zum Zuschauen, “trailing slashes” nicht vergessen:

rsync -avHP /home/mattias/ /tmp/home_mattias/

Nun können die Überreste des unverschlüsselten Heimatverzeichnisses auf der Systempartition gelöscht werden. Nach dem Aushängen des Dateisystems muss übrigens die verschlüsselte Gerätedatei abgemeldet werden — sonst droht Datenverlust:

umount /tmp/home_mattias/
cryptsetup luksClose mattias
rm -rf /home/mattias
mkdir /home/mattias
chown -R mattias:mattias /home/mattias

Sollte die Gefahr bestehen, dass sensible Daten zurückgeblieben sind, nullen Sie einfach die freien Festplattenbereiche:

dd if=/dev/zero of=/home/nix.nul bs=8192
sync
rm /home/nix.nul

Konfiguration von pam_mount

Zuerst müssen die “Pluggable Authentication Modules” konfiguriert werden. Um “pam_mount” zu aktivieren genügt es, an die Datei /etc/pam.d/common-session die folgende Zeile anzuhängen:

@include common-pammount

Im nächsten Schritt wird die Datei /etc/security/pam_mount.conf.xml angepasst, damit beim Login die Partition mit dem verschlüsselten Heimatverzeichnis gemountet wird. Mit nur einem Volume sah der Dateianfang bei mir so aus — relevant ist vor allem die mit <volume ... beginnende Zeile:

<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE pam_mount SYSTEM "pam_mount.conf.xml.dtd">
<!--
	See pam_mount.conf(5) for a description.
-->
<pam_mount>
<!-- Volume definitions -->
<volume user="mattias" fstype="crypt" path="/dev/sdb1" mountpoint="/home/mattias" options="fsck" />
<!-- pam_mount parameters: General tunables -->

That’s it! Nun noch einmal rebooten und per Passwort mit dem neuen verschlüsselten Heimatverzeichnis einloggen.

Feintuning zum Schluss

Der verschlüsselte User ist wertlos, wenn es sich um den einzigen Nutzer handelt. Ich habe daher einen zusätzlichen Nutzer ms mit einfachem Passwort angelegt. Diesem User habe ich Zugangsdaten zu oft von mir benutzten WLANs und einen Satz sinnvolle Bookmarks verpasst. Da dieser Nutzer auch dazu dienen soll, Gäste surfen zu lassen, ohne dass die SDD des EeePC vollläuft, habe ich mich für einen kleinen Trick mit dem temporären Dateisystem entschieden. Zunächst wird /tmp auf ein tmpfs gelegt, was ein Eintrag in der /etc/fstab bewerkstelligt:

tmpfs   /tmp            tmpfs   defaults        0       0

Nun sorgt ein kleines Script /etc/init.d/sync-dummy.sh dafür, dass der Inhalt des von /home/ms nach /home/ms.bak verschobenen Heimatverzeichnisses des Dummy-Users beim Systemstart nach /tmp kopiert wird:

#!/bin/bash
case $1 in
        start )
                rsync -avHP /home/ms.bak/ /tmp/home_ms/
        ;;
esac

Das Script muss jetzt noch ausführbar gemacht und im Runlevel 2 verlinkt werden:

chmod a+x /etc/init.d/sync-dummy.sh
cd /etc/rc2.d
ln -s ../init.d/sync-dummy.sh S95sync-dummy

Damit beim Login auch wirklich das auf tmpfs liegende Heimatverzeichnis verwendet wird, müssen die Pfade in der /etc/passwd noch angepasst werden. Da sich möglicherweise in einigen Konfigurationsdateien harte Referenzen auf /home befinden, ist es ratsam, das alte Heimatverzeichnis durch einen Softlink zu ersetzen:

cd /home/
ln -sf /tmp/home_ms ms

Weiter gedacht

Mit Sicherheit ist die vorgestellte Methode nicht die simpelste. Wenn es schnell gehen soll, dürfte die simple Auswahl eines verschlüsselten Heimatverzeichnisses bei der Installation am ehesten befriedigende Resultate bringen. Vorteil der hier vorgestellten Methode ist jedoch, dass die SD-Karte mit dem Heimatverzeichnis nicht im Netbook verbleiben muss, das Gerätchen funktioniert dennoch unverdächtig. Sollte dann beispielsweise der Zoll den EeePC konfiszieren, werden die Forensiker schnell feststellen, dass die — hoffentlich gut versteckte — SD-Karte fehlt. Und was nicht da ist, kann keiner Kryptanalyse unterzogen werden.

In vielen Fällen ist es mit dem Heimatverzeichnis nicht getan. Wer eine Swap-Partition verwendet, sollte diese auch verschlüsseln oder auf Swap-Dateien auf einem verschlüsselten Datenträger umstellen. Zudem schreiben einige Programme temporäre Daten nach /var/tmp, in diesem Fall sollten Sie auch dieses Verzeichnis auf ein tmpfs legen.

Zu bedenken ist zudem, dass die Wiederherstellung eines defekten Datenträgers schwieriger wird. Ist der LUKS-Header beschädigt, kann das Recovery gänzlich verunmöglicht werden.

Paranoiker dürfte das hier vorgestellte Verfahren nicht befriedigen, weil ich die Existenz einer verschlüsselten SD-Karte gar nicht zu verbergen versuche. Wer ganz sicher gehen möchte, belässt daher das sperrige Xandros auf dem EeePC, bootet sein mit TrueCrypt versehenes Ubuntu komplett von SD-Karte und verwendet einen inneren Container in einem äußeren verschlüsselten Container. Im Falle von Folter gibt er das Passwort des äußeren Containers preis, in dem unverdächtige Dateien und ein paar Dummy-SSH-Schlüssel liegen. Die wirklich privaten Dateien liegen im inneren Container.

Teilen sich mehrere Nutzer (die einander vertrauen) ein Netbook, kann es sinnvoll sein, einen gemeinsamen Container für das gesamte /home zu verwenden. Statt user kommt dann group in der /etc/security/pam_mount.conf.xml zum Einsatz und ein zweiter der acht Passwort-Slots wird für das Passwort des zweiten Nutzers belegt.

Links

• Tutorial “Encryption” auf Blueimp.net — eine große Inspiration für mein Tutorial
• Tutorial “Verschlüsselter Speicherstick”
• Tutorial “TrueCrypt: Hidden volumes unter Linux”
• “Crossing Borders with Laptops and PDAs” — von Bruce Scheier
• Manualpage pam_mount.conf
• Manualpage pam_mount

Das perfekte Netbook-Setup

1. Installation von Ubuntu/Xubuntu 8.10
2. /home reisetauglich verschlüsselt

Als dieser Beitrag entstand war das Grundsystem bereits aktualisiert, auf 13 Jails lief gerade make installworld durch. Ist dieses beendet steht der nächste Reboot an. Dann folgt die Rekompilierung aller aktuell installierter Softwarepakete gegen die neuen Systembibliotheken. Die ganze Aktion wird wohl noch bis Freitag früh dauern, da ich per Reboot sicherstellen möchte, dass garantiert alle Dienste richtig gestartet wurden.

Uptime-Pr0n ist nix für mich. Da vermeidet man einen Reboot und einige Minuten Downtime und vergisst eine Applikation, die noch mit alten Bibliotheken im Speicher läuft. Nach ein paar Wochen wundert man sich, wenn die sich nach einem Reload komisch verhält. Daher gilt heute ausnahmsweise auch unter Unix: Reboot tut gut.

• Debian 3.1 wurde offiziell Ende März eingestellt, jetzt heisst es schnellstens auf Debian 4.0 zu aktualisieren. Vielleicht wird die 5.0 Ende des Jahres fertig, so dass dann bis Anfang 2012 erst einmal Ruhe ist.
• Ubuntu 6.10 ist am 25. April 2008 fällig. Wer mit apt-get dist-upgrade aktualisieren möchte, sollte schrittweise vorgehen: zuerst auf 7.04, dann auf 7.10 und in ein paar Wochen auf 8.04. Die ist dann eine LTS-Version, die mit viereinhalb bis fünf Jahren Patches auf dem Server aufwarten kann.
• openSUSE 10.1 hat noch einige Wochen Gnadenfrist und soll Mitte Mai die letzten sicherheitsrelevanten Updates erhalten. Aus dem Termin lässt sich abschätzen, dass openSUSE 10.2 zwischen Oktober und Dezember fällig sein dürfte. Gerade die Versionen mit dem Zenworks-Daemon haben sich nicht gerade mit Ruhm bekleckert und das Paketmanagement hat einige Änderungen erfahren müssen, so Upgrades von Produktivsystemen auf 10.3 oder 11.0 spannend werden dürften.

Einen Pranger gibt es diesmal nicht. Kein großer Provider bietet derzeit Rootserver mit den auslaufenden Distributionen an. Allerdings könnten 1&1 und Strato langsam von openSUSE 10.2 auf 10.3 aktualisieren, damit Neukunden nicht in sechs Monaten aufwendig updaten müssen.

Kleiner Nachtrag: Server4You bietet heute (8. April 2008) noch Systeme mit openSUSE 10.1 an — es wäre nicht schön, wenn diese tatsächlich so ausgeliefert würden, weil so gleich am Anfang ein Update erzwungen wird.

Nun ist es also so weit: 10.0 wird abgekündigt, es folgen keine Updates mehr. Wer noch eine 10.0 oder 9.3 fährt, sollte schleunigst auf eine neuere Version umsteigen. Leider war der Update-Pfad in den letzten zwei Jahren bei SuSE besonders steinig: Gerade der zuerst in 10.1 eingeführte und den folgenden Versionen wieder entfernte Zenworks Management Daemon zickt gerne — eine saubere Neuinstallation ist deshalb oft die beste Lösung, glücklicherweise ist die per VNC problemlos durchzuführen, auch wenn man keinen physikalischen Zugriff auf den Server hat.

Mein Kritikpunkt der letzten Abkündigung, dass einige Anbieter von Rootservern noch die abgekündigte Version im Angebot haben, ist dieses Mal nicht nötig: Die meisten großen haben den direkten Sprung von 9.3 auf 10.1 vollzogen. Spannend wird es also wieder in sechs Monaten, wenn 10.1 abgekündigt wird.

• Abkündigung SuSE Linux 10.0
• Abkündigung SuSE Linux 9.3 (hier im Blog)
• VNC-Installation von openSUSE 10.x (funktioniert auch mit 10.3)

Die Faktenlage ist dürftig: Angriffe mit Ursprung in China, automatisches Abklopfen auf Sicherheitslücken und nicht gerade unauffälliges “Öffnen” von Rechnern — für mich sieht das eher nach einer der üblichen automatischen Suche nach offenen Proxies, offenen Relays und unzureichend gesicherten PHP-Scripten aus, nur nicht nach Profis. Chinesische Hacker von Amts wegen würden mit Sicherheit keine Rechner aus eigenen Netzbereichen als Basis für Schwachstellenanalysen verwenden, sondern auch geknackte oder gemietete Server beispielsweise in Russland. Auch die Tatsache, dass wohl tatsächlich einige Rechner der Volksbefreiungsarmee an den Angriffen beteiligt waren, sagt wenig. Vermutlich hat die chinesische Armee genauso unterbezahlte Administratoren wie viele andere Behörden, die entweder keine Lust am Abdichten ihrer Systeme haben, oder sich mit automatischen Scans nach offenen Relays für einen gut zahlenden Spammer etwas dazu verdienen wollen.

Ausgerechnet Ubuntu musste dies nun am eigenen Server erfahren: fünf gesponsterte Rootserver (von der “Community” betreut), auf denen seit Breezy Badger keine Sicherheitsupdates eingespielt wurden, konnten über einen längeren Zeitraum hin munter als Hackerbasis mißbraucht werden. [Eintrag im UbuntuWiki] [News bei Golem]. Ursache für den Update-Stop waren problematische Netzwerkkarten in den betroffenen Servern. Das ist mit ein Grund dafür, dass ich nach Möglichkeit (der Kunde hat natürlich immer ein Wörtchen mitzureden und akzeptiert nicht jeden Preis) auf Co-Location-Server setze, die in Rechenzentren untergebracht werden, welche in wenigen Stunden erreichbar sind. So lassen sich schlimmstenfalls vor Ort Netzwerkkarten austauschen oder — wenn die Kiste wirklich gehackt wurde — können hunderte Gigabyte Nutzdaten lokal kopiert werden, was einiges schneller geht als über das Internet.

PS: Kommentare gehen wieder, ich teste gerade reCAPTCHA gegen Spam. Rechnet in den nächsten Monaten wenigstens wieder mit einem Eintrag pro Woche.

Ob der erforderliche Mehraufwand zumutbar ist, soll jeder für sich selbst entscheiden. Da häufig eine andere Partitionierung erforderlich ist, setzen zumindest erfahrene Nutzer ihren Server gleich am Anfang neu auf. Bei Suse geht das ganz nett per VNC mit Kernel und Ramdisk der Installations-DVD: openSUSE 10.1 Remote-Installation im Hetzner-Wiki (klappt auch bei anderen Providern und mit 10.2).

Update: Entgegen ursprünglicher Ankündigungen wurde das letzte Update am 18. Juni veröffentlicht. 1&1 hat seine Rootserverangebote mittlerweile auf openSUSE 10.1 umgestellt. Strato listet beim PowerServer immer noch ein optionales 9.3.

Unterdessen wurde openSUSE 10.2 veröffentlicht. Nach anfänglichen Glitches beim neuen, libzypp-basierten Paketemanagement in 10.1 (kaum bemerrkbar bei Internet-Installation, teilweise aufgefangen durch eine “Remastered Version”) soll 10.2 nun von Anfang an sauber laufen. Im Serverbereich wurde vor allem Versionskosmetik durchgeführt, Desktop-User dürfen ein neues Startmenü ausprobieren und Xen mit einem neuen grafischen Assistenten einrichten.

Ich bin nach vielen Problemen dazu übergegangen, die behutsamsten aller Updates vorzunehmen um Seiteneffekte möglichst auszuschließen. Mein Favorit sind derzeit statisch gegen uClibc und die beim Kunden installierten Kernel-Header gelinkte Binaries, die ich per Softlink gegen die alten austausche. Diese sind kompakt und bereiten praktisch keinen Ärger.

Beim Kompilieren hilft das uClibc-RootFS-Image (lässt sich Loopback mounten) und ein gutes Dutzend Configure-Flags sowie ein paar nachträglich installierte Bibliotheken (zlib, openssl…).

Solch eine Aktion mag vordergründig betrachtet dem Kunden teurer kommen als die Lizenzkosten für ein simples Windows-Update. Unterm Strich dürfte jedoch das Unix- oder Linux-System, das einfach mal sieben oder acht Jahre durchläuft mehr Punkte sammeln.

PS: Der betreffende Host ist nur wenigen Kassenterminals “ausgesetzt”. Das mit dem Hacken braucht Ihr gar nicht erst zu probieren…