Aktuelles in der Kategorie Security

In 6 Monaten wird RHEL 3 sowie alle davon abgeleiteten Distributionen das Ende ereilen: sie werden ab da nicht mehr mit Sicherheitsupdates versorgt werden.

Für Red Hats kommerzielle Linux-Distribution werden regulär 7 Jahre lang Updates angeboten. Für den Zweig 3.x der Distribution nähert sich damit das Ende: am 31. Oktober 2010 sind die 7 Jahre um, es wird keinen weiteren Support mehr geben. Dies betrifft auch die Community-Distributionen, die auf den Quellen von RHEL aufbauen, wie CentOS und Scientific Linux.

Nutzern der Distribution legen wir ein Upgrade auf eine neuere Version wärmstens ans Herz, da sonst nicht garantiert werden kann, dass die Maschinen zuverlässig und vor allen Dingen sicher weiter laufen. Zur Zeit liegen für alle genannten Distributionen die aktuell noch gepflegten Zweige 4.x und 5.x vor, ein Release des Zweigs 6.x könnte eventuell noch rechtzeitig zum EOL des Zweigs 3.x veröffentlicht werden.
Da solche Upgrades sehr umfangreich und arbeitsaufwendig sein können, bietet sich alternativ auch eine Migration auf eine andere Distribution wie Debian an.

Ein entsprechender Upgrade-Plan sollte aber in jedem Fall bereits jetzt evaluiert werden - tendenziell sind es gerade die Maschinen des sensiblen produktiven Betriebs, die selten angefasst und noch seltener aktualisiert werden. Eine tiefgehende Analyse des Ist-Zustands so wie der Ansprüche, Notwendigkeiten und Bedingungen an das System vor dem Upgrade sind genau so unerlässlich wie Tests auf Staging-Systemen und eine frühzeitige Migration lange vor dem EoL. Wer bis zum letzten Tag wartet, tut sich keinen Gefallen.

Alle Blog-Artikel zum Thema CentOS werden auch als Kategorie RHEL/CentOS samt eigenem Feed angeboten. Wir bieten natürlich auch Support und Services für CentOS - insbesondere bei Upgrades und Migrationen auf neuere Versionen oder alternative Distributionen.

Beim Administrieren von Systemen kommt es häufig zu der Situtaion, dass eine SSH-Verbindung auf Host B nur über den SSH-Umweg via Host A möglich ist:
client -> ssh A -> ssh B

Um diesen Zweier-Schritt zu verkürzen, kann ein Eintrag in der ~/.ssh/config den Host A als Jumphost markieren, damit dieser Schritt zukünftig automatisch erfolgt:

Host Bdirekt
Hostname $IP_von_B
User rwo 
ProxyCommand ssh root@A.intern.lan nc %h %p

In der ersten Zeile wird ein Alias definiert - dieser kann beliebig sein, ein Bezug zu B ist aber sicherlich nicht falsch. Die zweite Zeile definiert den Hostname von B - bei Bedarf und je nach Netzwerk ist hier die IP sinnvoller als der Hostname! Die Option ProxyCommand definiert dann die eigentliche Jump-Funktion - hier also den Zugriff via ssh auf A und die Weiterleitung der Daten mittels nc.

Sind nun auch SSH-Keys überall ausreichend verteilt, gibt es auch keine Abfragen mehr. Ein simples ssh Bdirekt führt dann direkt auf den Host B.

Alle Tipps dieses Blogs werden auch als Kategorie Tipp mit eigenem Feed angeboten - und solltet ihr gerade nach Support für Linux suchen, seid ihr bei uns immer richtig.

Die PostgreSQL-Entwickler haben die aktuellen stabilen Versionszweige 8.4, 8.2, 8.1, 8.0 und 7.4 mit neuen Updates versorgt.

Die PostgreSQL Community hat neue Versionen der aktuellen stabilen Zweige veröffentlicht. Dies aktualisiert diese auf die Versionen 8.4.3, 8.3.10, 8.2.16, 8.1.20 und 8.0.24 sowie 7.4.28.

Upgrades können ohne Dump/Restore der Datenbanken innerhalb eines Zweiges durchgeführt werden. Neben einigen kleineren Fehlerkorrekturen beheben diese Aktualisierungen unter anderem:

• Neuer Konfigurationsparameter ssl_renegotiation_limit. Dies erlaubt das Setzen der Menge an Daten, die über eine Datenbankverbindung übertragen werden darf, bevor die SSL-Verbindung neu ausgehandelt wird. Einige ältere OpenSSL-Versionen können einen Fix für das Sicherheitsleck (CVE-2009-3555) enthalten, die in diesem Fall zu Abbrüchen der Datenbankverbindung führen können, so dass dies mit Setzen des Parameters auf 0 abgeschaltet werden kann.
• Beheben eines Deadlocks bei Neustart des Datenbankserver
• Bessere Fehlerbehandlung bei Neuladen des Relcache
• Abstürze beim Recovern von Subtransaktionen wurden behoben
• Fix für mögliche Indexkorrumpierung bei GiST-Indexe, sowie Datenverlust bei GIN-Indexe

Es wird empfohlen, beim nächsten Wartungsfenster auf die neueste jeweilige Minor-Version des eingesetzten stabilen Zweiges zu wechseln. Detaillierte Informationen über die einzelnen Fixes können über die Releasenotes der Projektseite eingesehen werden.

Alle Blog-Artikel zum Thema PostgreSQL werden auch als Kategorie PostgreSQL samt eigenem Feed angeboten - und falls ihr nach Support und Services für PostgreSQL sucht, seit ihr bei uns ebenfalls richtig.

Auf den Chemnitzer Linux-Tagen hält Alexander Wirt einen Vortrag über Single-Sign-On mit Kerberos. Er gibt eine Einführung in Kerberos so wie in die Konfiguration verschiedener Dienste.

Kerberos ist ein Authentifizierungsprotokoll, mit dessen Hilfe verschiedene Dienste und Betriebssysteme transparent in ein System eingebunden werden können. Damit ist es möglich, ein Single-Sign-On zu ermöglichen: der Nutzer tippt nur einmal sein Passwort ein, und kann danach auf alle gesicherten Dienste im Netzwerk zurückgreifen, die Kerberos unterstützen - vom E-Mail-System bis hin zu den einzelnen Webseiten.

Dieses Vorgehen beschreibt Alexander Wirt, credativs Spezialist auf dem Gebiet, im Detail auf einem Vortrag auf den Chemnitzer Linux-Tagen Mitte März: neben einer Einführung in die allgemeinen Grundlagen von Kerberos beschreibt er die praktische Einrichtung des Kerberos-Servers auf der Basis der Heimdal-Implementierung sowie die Konfiguration der eigentlichen Dienste: SSH, Apache und IMAP sind klassische Beispiele. Durch die Praxisnähe des Vortrags wird der Zuhörer in die Lage versetzt, später ein eigenes Setup zu erstellen und weitere Dienste einzubinden.

Der Vortrag findet am 13. März 2010 um 15:00 Uhr im Raum V4 statt.

Einer der schnellsten und einfachsten Wege, den Zugriff auf einen Pfad eines Webservers auf bestimmte Nutzer zu begrenzen ist der Einsatz einer .htaccess-Datei. Diese wird im zu begrenzenden Pfad hinterlegt, und beschreibt, welche Beschränkungen gelten. Ein simples Beispiel für die Begrenzung des Zugriffs auf alle Nutzer, die in einer entsprechenden htpasswd-Datei definiert sind, ist:

AuthType Digest
AuthName "SecretDir"
AuthUserFile /etc/apache2/passwords/secretdir.htpasswd
Require valid-user

Die .htpasswd-Datei enthält die Nutzernamen und Passwörter - und sollte daher außerhalb des Webverzeichnisses stehen!

htdigest -c /etc/apache2/passwords/secretdir.htpasswd SecretDir someuser

Wichtig ist, dass im Directory-Abschnitt der Verzeichnis-Konfiguration (z.B. unter /etc/apache2/sites-enabled) die Option AllowOverride AuthConfig gesetzt ist. Da in diesem Beispiel auch die wenigstens etwas sichere Authentifizierungs-Methode Digest verwendet wird, muss das Modul mod_auth_digest außerdem geladen sein.

Weitere Informationen, tiefer gehende Konfigurationen und weitere Anpassungen finden sich im Artikel Authentication, Authorization and Access Control der Apache-Dokumentation.