Das Rootserver-Experiment

Erlebnisse eines Rootserver (Beinahe-) Neulings

Verantwortlich für den Inhalt dieser Seite ist Mattias Schlenker, Inhaber Mattias Schlenker IT-Consulting Mattias Schlenker work Dietrich-Bonhoeffer-Str. 3, 40667 Meerbusch. Germany work Fon +49 341 39290767. Meine USt-ID (VATIN) lautet: DE240998538. http://www.mattiasschlenker.de

Diese Seite läuft unter Wordpress 2.x.x. News und Kommentare können als RSS-2.0-Feed abonniert werden.

Archiv für 'Security'

Bootfähigen USB-Stick für UEFI Secure Boot erstellen – 1. PreLoader der Linux-Foundation plus Gummiboot

Saturday, March 2nd, 2013

Disclaimer: Dieses kleine Tutorial richtet sich an all jene, die entweder einen Admin-Stick mit verschiedenen Installern und Notfallsystemen erstellen wollen oder einfach eine Fingerübung suchen, um den Bootvorgang von UEFI Secure Boot besser nachvollziehen zu können. Die anfängliche Installation von LessLinux Search and Rescue kann nach und nach um weitere Linuxe erweitert werden. Als Bootloader verwende ich zunächst den unkomplizierten PreLoader.efi der Linux-Foundation in Kombination mit Gummiboot, möglicherweise folgt demnächst eine auf Shim (mit MOK) angepasste Anleitung. Auf den EFI-Boot von 32-Bit-Systemen möchte ich nicht eingehen, weil praktisch nur ältere Apple iBooks und MacMinis (CoreDuo, nicht Core2Duo) mit einem 32-Bit-EFI ausgeliefert wurden. Die paar Netbooks von Asus, die ebenfalls 32-Bit-EFI an Bord haben, sind in der Regel auf das CSM eingestellt (Compatibility Support Module = BIOS-Emulation zum Boot von MBR-Medien).

Hinweis: Auf dieses Tutorial folgt ein weiteres, das die hier gezeigte Konfiguration um GRUB erweitert (um 32-Bit-Systeme booten zu können) und eines, das erklärt, wie schließlich ein hybrider Stick entsteht, der auf MBR- und UEFI-Systemen startet. Wer aus dem dritten Tutorial das Optimum herausholen möchte, sollte eine dritte, 100 bis 200MB große, leere FAT32-Partition einplanen.

Wie bootet UEFI sicher vom Stick?

Der Vorgang von USB ist etwas einfacher als von Festplatte, zumindest wenn es sich um einen GPT partitionierten Stick mit einer einzigen FAT32-Partition handelt. In diesem Fall genügt es, eine Ordnerstruktur “BOOT/EFI” anzulegen, die den Bootloader “BOOTX64.EFI” enthält. Hintergrund dieser Vereinfachung ist wohl, dass es ermöglicht werden soll, alleine durch das Entpacken eines Zips mit den Bootdateien einen Stick bootfähig zu machen – aber das ist Spekulation, weder habe ich nachgeprüft welche UEFI-Implementierungen den einfachen Start unterstützen, noch habe ich getestet, ob in nennenswerten Stückzahlen USB-Sticks am Markt sind, die sowohl GPT als auch BIOS-MBR aufweisen. (more…)

Das Gespenst UEFI Secure Boot

Friday, March 1st, 2013

In den letzten Tagen hatte ich etwas Gelegenheit, mich mit UEFI Secure Boot näher zu beschäftigen: Ich erstelle bekanntlich die Notfall-CDs für einige Computerzeitschriften oder arbeite intensiv daran mit (von Computer Bild bis desinfec’t gibt es einige). Ziel war, alle aktuellen, von Microsoft signierten EFI-Loader unter die Lupe zu nehmen und auf ihre Praktikabilität abzuklopfen. Die gute Nachricht vorweg: Wer Ubuntu oder Fedora verwendet und keine Kernel selbst kompiliert, muss sich nicht mit dem Schlüsselmanagement herumärgern. Beide Distributionen verwenden einen von Microsoft signierten Loader (auf Basis von Shim), der wenigstens sicherstellt, dass GRUB2 und der anschließend geladene Kernel “vertrauenswürdig” ist. Zu Funktionsweise, Unterschieden und Restriktionen der verwendeten gepatchten GRUB2-Varianten hat sich Thorsten Leemhuis in der c’t 5/2013 zur Genüge ausgelassen. Wirklich spannend ist die Thematik aber für den Start selbst kompilierter Kernel, für kleine Distributionen, die verteilt und schnell entwickelt werden und für Administratoren, die Linux basierte Deployment- und Notfall-Systeme per Netz oder vom Wechseldatenträger starten wollen.

In diesem Beitrag möchte ich die eher theoretischen Hintergründe erläutern und Entscheidungshilfen geben, demnächst folgen dann Beiträge zur praktischen Umsetzung von Secure Boot eigener Kernel auf USB-Sticks, optischen Datenträgern und via Netzwerk. (more…)

Linux: Verschlüsselte und komprimierte Backups auf DVD

Wednesday, February 4th, 2009

Ich sichere nach wie vor geschäftsrelevante Daten auf DVD, allerdings stellte mich keine der fertigen Lösungen vollkommen zufrieden. Meine Anforderungen:

  • 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. (more…)

Das perfekte Netbook-Setup: 2. /home reisetauglich verschlüsselt

Wednesday, November 5th, 2008

In den nächsten Tagen steht eine Reise an. Mit dabei sein wird der alte, robuste EeePC 701 mit Xubuntu 8.10 und einer SD-Karte für mein Heimatverzeichnis. In einigen Ländern muss man die Notebooks hochfahren und sich anmelden. Ab und an klickt der Immigration Officer dann durch das Dateisystem und schaut ob verdächtige Dateien vorliegen. Ich stelle hier ein Setup vor, bei dem das Heimatverzeichnis eines Nutzers verschlüsselt auf einer eigenen Partition liegt und beim Login dieses Nutzers eingebunden wird. Andere — evtl. per Auto-Login angemeldete — User hängen die verschlüsselte Partition nicht ein. Das beugt Problemen bei Verlusten des Netbooks vor und mit ein wenig Geschick lässt sich bei einer oberflächlichen Kontrolle die Existenz des verschlüsselten Heimatverzeichnisses verbergen.

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.

(more…)

Unser Server hat Husten…

Thursday, July 17th, 2008

Nein, nicht wirklich. Es läuft gerade das Update von FreeBSD 6.3 auf 7.0 — und dieses wird in den nächsten Stunden immer wieder für ein paar Minuten Nichterreichbarkeit sorgen.

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.

Abkündigungen en Masse: Debian, openSUSE, Ubuntu

Monday, April 7th, 2008

Rootserver-Admins aufgepasst, für einige Distributionen wurden die Sicherheitsupdates eingestellt oder sie werden bald eingestellt. Verrottende Bits und ausbleibende Flicken können so aus Eurem Server eine tickende Zeitbombe machen.

  • 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.

SuSE 10.0 discontinued

Tuesday, January 8th, 2008

Die Ende 2005 erschienene SuSE 10.0 war die erste Nürnberger Distribution mit offener Beta-Phase, im Gegensatz zu den Vorgängern war sie sofort als Open Source Variante zum Download verfügbar. Angesichts der recht konservativen Softwareauswahl wäre aus technischer Sicht die Versionsnummer 9.4 wohl angemessener gewesen. Dennoch erlangte die 10.0 bei Providern nicht die Beliebtheit der Vorgängerversion 9.3.

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.

Wer steckt wirklich dahinter?

Tuesday, September 4th, 2007

Laut FTD, Spiegel, Golem und Heise Online haben angeblich chinesische Hacker versucht, Mailserver des Pentagon zu kompromittieren. Die Angriffe haben sich wohl präzise auf “verschiedene Regionen Chinas” zurückführen lassen. Soweit zu den mageren Fakten. Die Financial Times macht daraus eine nette Schlagzeile, die mehr als mißverständlich ist.

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.

Aua! Ubuntu-Server gehackt

Thursday, August 16th, 2007

Newbies erklärt man immer, dass regelmäßige Updates der beste Schutz vor gehackten Maschinen sind. Hacker suchen sich meist die am schwächsten gesicherten Maschinen, weil diese am leichtesten zu knacken sind. Maßnahmen wie Firewalls, Jails etc. können regelmäßige Sicherheitsupdates ergänzen aber nicht ersetzen.

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.

SuSE 9.3 discontinued

Tuesday, May 22nd, 2007

Fast hätte ich es vergessen: Seit gut zwei Wochen gibt es keine Sicherheitsupdates mehr für SuSE 9.3. Das ist nichts außergewöhnliches, denn SuSE kündigt den Support — je nach Beliebtheit einer Distribution — regelmäßig 24 bis 30 Monate nach deren Erscheinen ab und nennt rechtzeitig ein Datum für die Einstellung des Supports. Bei SuSE 9.3 war dies am 8. März der Fall — umso erstaunlicher, dass heute noch einige Provider Server mit SuSE 9.3 anbieten: Strato (beim Einstieigerangebot “PowerServer” als Option SuSE 9.3, 10.0 und Debian 3.1) und 1&1 als einziges beworbenes Betriebssystem bei den 1&1 “Root Servern”. Immerhin kann man nach meinem Kenntnisstand aus dem Kundenmenü heraus einfach aktuellere Systeme installieren.

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.

SuSE 9.2 weg, openSUSE 10.2 da

Thursday, December 7th, 2006

Betreiber von Rootservern, die noch unter SuSE 9.2 laufen, sollten sich sputen: der Support wurde vor bald drei Wochen eingestellt, es wird keine Sicherheitsupdates mehr geben. Das einst stabile Haus ist dem Verfall preis gegeben. Mit der Einstellung von 9.2 tickt auch die Uhr für SuSE 9.3: Im April wird es
die letzten Sicherheitsupdates geben.

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.

Alles ganz einfach

Wednesday, February 22nd, 2006

In Kundenbeständen habe ich noch einige Warenwirtschaftsserver, die seit ein paar Jahren ohne große Updates laufen. Auf einem tut S.u.S.E. (damals noch mit Punkten) 6.3 seinen Dienst. Diese Rechner wurden nie groß aktualisiert, doch gelegentlich erfordert die sie umgebende Infrastruktur ihren Tribut: mal ist ein neuer Kernel fällig, weil eine Netzwerkkarte gestorben ist und die neue von 2.2.5 nicht erkannt wird, mal will ein RSYNC-Backup in die sich fortentwickelnde Infrastruktur eingebunden werden.

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…

Suse 9.0 discontinued

Monday, February 6th, 2006

Novell hat soeben damit aufgehört, Suse Linux 9.0 zu supporten. Die Einstellung des Supports für Suse 9.1 folgt im Juni. Daraus lassen sich grob die Supportzeiträume für 9.2 und 9.3 abschätzen: die ohnehin kaum eingesetzte 9.2 dürfte zwischen Dezember und März 2007 eingestellt werden,
9.3 zwischen Juni und Oktober 2007.

Wer sich jetzt einen Rootserver mit Suse 9.3 holt, muss wahrscheinlich nach weniger als anderthalb Jahren ein volles Update mit allen Risiken fahren.