Dez 262013
 

Die neuesten Nachrichten aus den USA über das Mitlauschen der NSA des nahezu gesamten Internet-Verkehrs hat gezeigt, dass es heißt mit Daten sehr sensibel umzugehen. Es hat sich aber auch gezeigt, dass die bloße Verschlüsselung z.B. über HTTPS alleine nicht ausreicht, da häufig Verschlüsselungsalgorithmen (z.B. RC4) eingesetzt werden, von denen man vermutet, dass die erzeugten verschlüsselten Daten von der NSA in Echtzeit mitgelesen werden können. Insbesondere Sparkassen und Banken in Deutschland bevorzugen leider immer noch RC4. Hier kann man sich z.B. bei Benutzung des Firefox dagegen schützen, indem man hier RC4 ausschaltet. Die Banken bieten häufig genug andere, bessere Verschlüsselungsalgorithmen an, sodass die Seiten weiterhin uneingeschränkt benutzt werden können. Bei itemis habe ich mit meinem Kollegen Dominik Kupschke sämtliche verschlüsselten Dienste auf sichere Algorithmen gehärtet, sodass sie z.B. gar nicht erst RC4 anbieten. Dieser Artikel soll eine Zusammenfassung dieser Ergebnisse liefern und Aufschluss über gute Verschlüsselungsverfahren bieten. Es soll hier nicht auf deren Funktionsweise eingegangen werden, hierfür gibt es genug Quellen im Internet.

Für eine gute SSL-Verschlüsselung sind vier Punkte wesentlich:

  1. Das Zertifikat
  2. Der Schlüsselaustausch für die synchrone Verschlüsselung
  3. Die synchrone Verschlüsselung
  4. Die Prüfung der Authenzität

Die verwendeten Algorithmen werden in ihrer Kombination Cipher genannt. Diese können bei den meisten Diensten konfiguriert werden.


Anzeige:


Das Zertifikat

Das Zertifikat ist ein Public Key, der von einer Zertifizierungsstelle (CA) signiert wurde, bei einem Verbindungsaufbau gegen diese Zertifizierungsstelle verifiziert werden. kann. Die entscheidende Kenngröße ist die Breite des Schlüssels. Für die typischerweise verwendeten RSA-Schlüssel sollten mindestens 2048 Bits verwendet werden. Für wirklich sensible Daten sollten mindestens 4096 Bits verwendet werden.

Der Schlüsselaustausch

Mit dem asynchronen Verschlüsselungsverfahren wird das Verteilungsproblem des Schlüssels gelöst. Mit dem Public Key kann nur verschlüsselt werden und mit dem Private Key kann entschlüsselt werden. Wie die Namen schon andeuten, darf der Public Key in fremde Hände geraten. Der Private Key verbleibt auf dem Server und muss entsprechend gegen unberechtigten Zugriff geschützt werden. Diese Verschlüsselungsart ist gegenüber der synchronen Verschlüsselungsart sehr langsam. Es gibt Verfahren, die mit asynchroner Verschlüsselung einen zufälligen synchronen Schlüssel aushandeln, der dann für den weiteren Verbindungsverlauf verwendet wird. Hier gibt es zwei herausragende Verfahren:

  1. Diffie-Hellman
  2. Elliptic Curves

Beide Verfahren behandeln sog. Perfect Forward Secrecy. Damit werden auch im Laufe der Verbindung die synchronen Schlüssel ausgetauscht. Das erhöht die Sicherheit, da mit immensen Aufwand nur ein Teil der Verbindung geknackt werden könnte. Bei den Perfect Forward Secrecy Verfahren lassen sich aufgezeichnete Verbindungen nicht mit dem Privaten Schlüssel des Servers entschlüsseln, hier spricht von man Folgenlosigkeit.  Das Verfahren, das die Elliptic Curves benutzt wurde von dem amerikanischen Normungsinstitut spezifiziert. An diesem Verfahren hat die NSA mitgewirkt und daher steht dieses Verfahren im Verdacht, eine Backdoor der NSA zu haben. Das Diffie-Hellman-Verfahren kann mit unterschiedlichen Schlüsselbreiten arbeiten. Natürlich sollte auch hier ein möglichst breiter Schlüssel verwendet werden.

Zusammenfassung:

Auch wenn Elliptic Curves performanter sind, sollte auf dieses Verfahren verzichtet werden! Das empfohlene Schlüsselaustauschverfahren lautet DH Group 15.


Anzeige:


Die synchron verschlüsselte Verbindung

Aus Gründen der Performance wird für den Datentransport synchrone Verschlüsselung verwendet. Hierbei wird zum Ver- und Entschlüsseln derselbe Schlüssel verwendet. Folgende Verfahren werden typischerweise angeboten:

  • RC4
  • DES
  • 3DES
  • AES
  • CAMELLIA

Man geht davon aus, dass RC4 von der NSA in Echtzeit mitgelesen werden kann. Daher sollte dieser Algorithmus dringend vermieden werden! Leider bevorzugen gerade viele Banken und Sparkassen diese Verschlüsselung. Im Firefox kann man die Verwendung dieser Verschlüsselung abschalten. Dazu ruft man die URL about:config auf. Im Suchfeld sucht man nach „rc4“. Die sechs angezeigten Werte werden mittels Doppelklick auf „false“ gesetzt.

RC4

DES benutzt eine Schlüsselbreite von nur 56 Bits und ist somit ebenfalls zu schwach. 3DES ist ein dreifach hintereinander durchgeführter DES. Derzeit gilt dieser Algorithmuss noch als sicher. AES ist der bevorzugte Algorithmus. Er kann mit 128, 192 und 256 Bits Schlüsselbreite verwendet werden. AES ist über einen Wettbewerb ausgeschrieben worden, der unter Anderem die Implementierung in Soft- und Hardware erleichtern soll. AES mit 256 Bits ist daher der bevorzugte Algorithmus. Java kann in der handelsüblichen Form nur AES mit 128 Bits. Diese Verschlüsselung ist dem 3DES vorzuziehen. CAMELLIA ist ein weiterer Algorithmus, der nicht selten auftaucht und ebenfalls als sicher gilt.

Zusammenfassung:

AES256 ist optimal. 3DES ist zwar noch sicher, aber AES128 ist 3DES vorzuziehen.

Die Prüfung der Authenzität

Um beim Schlüsselaustausch sog. Man in the middle-Attacken zu vermeiden, gibt es sog. HMAC-Verfahren. Hier werden Hashing-Algorithmen eingesetzt. Häufig wird SHA eingesetzt. Lässt sich SHA 256 oder SHA2 einsetzen, sollte dieser benutzt werden. Auf MD5 sollte dringend verzichtet werden.

Gesellschaftliche Aspekte

Verschlüsselung und das Abschöpfen des Internet-Verkehrs ist für IT-Laien ein undurchschaubares Thema. Im Zusammenhang mit der NSA-Affäre taucht sehr häufig das Argument auf: „Ich habe nichts zu verbergen!“. Vielleicht veranschaulicht die Tatsache, dass wir nicht nackt rumlaufen, weil wir was zu verbergen haben, diesen Unterschied. Hier muss zwischen Unschuld und Scham unterschieden werden. Man hat sich nichts zu Schulden kommen lassen und es wird durch das Abschöpfen der Internet-Daten mit gutem Gewissen nichts ans Licht kommen. Allerdings ist im Grundgesetz das Recht auf Privatsphäre festgeschrieben. Wir hängen unsere Kontoauszüge auch nicht an den nächsten Baum und hier greift das Argument: „Wenn es den Nachbarn nicht zu interesssieren hat, dann hat es die NSA auch nicht zu interessieren!“.

Die NSA schöpft ohne zu fragen die Daten ganzer Völker ab und stellt damit ganze Völker unter Generalverdacht. Das ist der Anfang eines Überwachungsstaates und untergräbt bestehende rechtsstaatliche Demokratien.

Mehr zu diesem Thema:

Feb 092011
 

Linux bietet auf x86-Architekturen die Möglichkeit, statt der normalerweise 4K großen Memory Pages auch 2M große Pages zu nutzen. Der Vorteil hierbei ist, dass die MMU der CPU deutlich seltener ein Address Mapping von virtuellem Speicher auf die physikalische Adresse durchführen muss. Dieser Vorgang wird auch Table Walk genannt. Er hat den Nachteil, dass der Zugriff auf diese Mapping-Tabellen am Cache vorbei durchgeführt werden muss und somit sehr langsam ist. Das Ergebnis des Table Walks landet seinerseits in einem speziellem Cache, dem sog. TLB. Es bietet sich unter Linux an, Software mit hohem Speicherverbrauch diese Huge Pages oder Huge Tables nutzen zu lassen. Gerade Server-Prozesse wie JBoss fallen da schnell ins Auge.

Will man unter Java diese sog. Huge Pages verwenden, reicht da die JVM-Option -XX:+UseLargePages. Allerdings ist das nicht die gesamte Arbeit. Dazu muss man den Linux-Kernel anweisen, Huge Tables zur Verfügung zu stellen. Dazu muss man sich erst klar werden, dass Huge Tables dem allgemeinen Memory Pool entzogen wird und nicht mal dem Linux Caching mehr zur Verfügung steht. Es ist also Speicher, der dem Java-Prozess dediziert zur Verfügung steht. Es empfiehlt sich, 512M mehr als Huge Tables bereitzustellen, als man mit -Xmx der virtuellen Maschine zur Verfügung stellt. Hat man 8G RAM, und will man 3,5G dem Java bereit stellen. Müssen wir 4G an Huge Tables bereitstellen. Das geschieht in der Datei /etc/sysctl.d/hugetlb.conf. Dort müssen drei Einträge gemacht werden:

  1. kernel.shmmax=<max-shared-memory-in-bytes>
    Da Huge Tables als Shared Memory allokiert werden, muss die Maximalzahl hier auf die verwendete Speichergröße hochgesetzt werden.
  2. vm.nr_hugepages=<amount>
    Die Zahl der Huge Tables selbst. Will man 4G an Huge Tables haben, muss hier eine 2048 eingetragen werden, weil 2048 * 2M = 4G ist.
  3. vm.hugetlb_shm_group=<gid>
    Hier muss die Usergroup eingetragen werden, die Huge Tables benutzen darf.

Sind die Werte eingetragen, muss man ein sysctl -p -f /etc/sysctl.d/hugetlb.conf ausführen, um die Werte dem Kernel mitzuteilen. Hat der Server schon eine relativ lange Uptime, muss er vielleicht durchgestartet werden. Grund ist, dass die Huge Tables im Stück im Speicher liegen müssen. Da es auch beim Hauptspeicher eine Fragmentierung geben kann, kann evtl. die Zuteilung der Huge Tables nur teilweise gelingen. Kontrollieren kann man das, indem man cat /proc/meminfo ausführt. Das ergibt dann so eine Ausgabe wie:

HugePages_Total:     512
HugePages_Free:      512
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:       47040 kB
DirectMap2M:     4147200 kB

Hier sind 512 (= 1G) Huge Tables zugewiesen worden. Als Nächstes muss dem entsprechenden Benutzer, der die Huge Tables benutzen möchte, die Erlaubnis geben, diesen Speicher fest im Speicher zu halten, so dass er nicht im Swap landen kann. Das erfolgt in der Datei /etc/security/limits.conf. Hier wird die Größe des Wertes kernel.shmmax aus der Datei /etc/sysctl.d/hugetlb.conf übernommen. Die Einträge lauten:

<username> soft memlock <locked-memory-in-kbytes>
<username> hard memlock <locked-memory-in-kbytes>

Benutzt man für den Usernamen „*“, gilt diese Einstellung für alle Benutzer, ausgenommen root. Für ihn muss man explizit einen Eintrag machen, wenn gewünscht. Üblicherweise läuft JBoss nicht als root, sondern hat einen dedizierten Benutzer, den man dann auch hier eintragen sollte. Hierbei muss man darauf achten, das PAM so konfiguriert ist, dass die Limits auch als Benutzer entsprechend konfiguriert werden. Hat man als Shell die bash, kann man mit ulimit -a überprüfen, ob der Wert max locked memory korrekt gesetzt wurde. Ein Reboot ist hierfür nicht erforderlich!

jboss@master:~$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 20
file size               (blocks, -f) unlimited
pending signals                 (-i) 16382
max locked memory       (kbytes, -l) 3145728
max memory size         (kbytes, -m) unlimited
open files                      (-n) 65536
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) unlimited
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

Sind die Huge Tables verfügbar und die Limits gesetzt, kann man jede JVM mit der Option -XX:+UseLargePages starten und Java benutzt Huge Tables.

Kann Java keine Huge Tables allokieren, kommt es zu folgender Fehlermeldung:

Java HotSpot(TM) 64-Bit Server VM warning: Failed to reserve shared memory (errno = 22).

In diesem Falle allokiert Java „normalen“ Speicher. Wenn zu viele Huge Tables belegt wurden, kann es dann zu einem Engpass an normalen Speicher kommen. Die Wahl der Option -Xmx ist daher wichtig!

Unter JBoss sollte diese Option in die Datei $JBOSS_HOME/bin/run.conf übernommen werden.

Jul 072010
 

Das Projekt der modell(-bau-)basierten Eisenbahnsteuerung ist ab sofort auf SourceForge als Open Source verfügbar. Die Startseite ist unter http://sourceforge.net/p/mrw/wiki/Home/ erreichbar. Der Quellcode und die Schaltungen können aus dem Subversion-Repository heruntergeladen werden.

Viel Spaß!

Was nützen die smartmontools?

 Linux, Systemmanagement  Kommentare deaktiviert für Was nützen die smartmontools?
Jul 232008
 

Jede Festplatte besitzt einen eingebauten Standard, der vielleicht Jemandem beim Booten als BIOS-Meldung aufgefallen ist, aber noch nicht aktiv genutzt hat: Das S.M.A.R.T. Es ist eine Abkürzung für Self-Monitoring, Analysis and Reporting Technology. Es handelt sich dabei um die Möglichkeit, den Zustand der Festplatte zu überwachen. Hier werden Werte wie Start/Stop-Zyklen, Betriebssystunden und Fehlerzähler verwaltet. Da heutzutage jede Festplatte über diesen Standard verfügt, macht es gerade in IT-Infrastrukturen Sinn, diese Werte permanent zu überprüfen. Selbst bei Desktop-Rechnern oder Laptops macht es Sinn, von Zeit zu Zeit über diesen Standard den Zustand der Festplatte abzufragen.

Unter Linux gibt es für die automatische Überwachung die sog. smartmontools. Diese haben das Abfragetool smartctl, was den Zustand einer Platte abfragen kann. Ferner gibt es noch einen Daemon, der in regelmäßigen Abständen den Zustand der Festplatte(n) abfragt und im Fehlerfalle sogar eine EMail verschickt. Dadurch ist eine engmaschige Überwachung der Festplatten gewährleistet. Einer Studie von Google zufolge, kann auf diesem Wege ein Ausfall einer Festplatte zu 64% Wahrscheinlichkeit rechtzeitig vorhergesagt werden. Häufigster Indikator ist das Bad-Block-Remapping. Wird ein Festplattensektor schadhaft, verwendet die Festplatte automatisch einen Alternativblock. Dieser Vorgang wird von SMART mitgezählt. Häufen sich Remappings, wird es Zeit, die Platte auszuwechseln. Auch ein relativer langsamer Temperaturanstieg über Wochen ist ein Indikator für ein baldiges Ableben der Mechanik. Platten in kühlen Umgebungen (z.B. durch eine Klimaanlage) sollten nicht über 40 Grad überschreiten, tun sie es trotzdem, kann das ein Indikator für einen baldigen Ausfall sein. Was durch S.M.A.R.T nicht erfasst werden kann, ist der Ausfall der Elektronik.

Ich kann nur Jedem IT-Verantwortlichen die smartmontools ans Herz legen. Mir selbst haben die Tools schon viele Crashes vorhergesagt und größeren Schaden abgewendet. Gerade Betreiber von Root-Servern sollten auf den Einsatz der smartmontools nicht verzichten, da gerade dort die eingesetzten Festplatten nicht redundant in RAID-Verbünde eingegliedert sind.

Quellen:
http://labs.google.com/papers/disk_failures.pdf
http://smartmontools.sourceforge.net

Beispiel für ein Mail-Script:

SMART_MSG=/tmp/smart.msgcat > $SMART_MSG

echo "======================================================================" >>$SMART_MSG

# Append the output of smartctl -a to the message:

/usr/sbin/smartctl -a -d $SMARTD_DEVICETYPE $SMARTD_DEVICE >> $SMART_MSG

echo "======================================================================" >>$SMART_MSG

echo "-- " >>$SMART_MSG

echo "System administrator" >>$SMART_MSG

# Now email the message to the user at address ADD.  Solaris and

# other OSes may need to use /bin/mailx below.

/usr/bin/mail -s "$SMARTD_SUBJECT" $SMARTD_ADDRESS < $SMART_MSG

rm $SMART_MSG

und die Einbindung in die smartd-Konfiguration über die Datei smartd.conf:

/dev/sda -d ata -S on -m <EMail-adresse-des-Admins> -a -M exec /root/bin/smartmail.sh

Subversion im Alltag

 Linux, Systemmanagement  Kommentare deaktiviert für Subversion im Alltag
Jul 032008
 

Subversion wird seit acht Jahren entwickelt und hat im Februar 2004 die erste stabile Version 1.0 erreicht. In dieser Zeit wurden viele Entwickler von den Vorzügen von Subversion überzeugt. Wer CVS kennt, wird sich als Entwickler nicht wensentlich umgewöhnen müssen, da das Konzept Copy-Modify-Merge gleich geblieben ist. Administrativ hat sich allerdings Einiges geändert. Die Versionsdaten werden wie in einer Datenbank gespeichert. Die Backend-Schnittstelle ermöglicht es, verschiedene Backends zu verwenden. Der Vorteil gegenüber CVS ist hier, dass die Dateien nicht direkt manipuliert werden können, da sie nur als Binärdaten vorliegen. Bei CVS werden in einer ASCII-Datei Diffs gespeichert, sodass Manipulationen möglich sind.

In der Praxis hat sich Subversion durch die Stabilität bewährt. Der Verwaltungsaufwand ist nur minimal. Nach dem Einrichten mit svnadmin kann man sofort arbeiten. Es gibt aber noch ein paar Tipps, wie man durch Feintuning die Disziplin der Entwickler fördern kann. Zwei herausragende Punkte sind einerseits die Commit-Meldungen und andererseits die anonymen Commits. Unter Subversion sind leere Commit-Meldungen möglich. Möchte man die Entwicklungsgeschichte nachverfolgen, sind leere Kommentare teilweise frustrierend. Wenn Dutzende von Revisions committed wurden, ohne dass sich scheinbar was geändert hat, muss man ein Difftool bemühen, um Änderungen nachverfolgen zu können. Ähnlich verhält es sich bei anonymen Usern. Subversion lässt bei falscher Konfiguration anonyme Commits zu.

Um leere Commit-Meldungen zu unterbinden gibt es das Mittel der Hook-Skripte. Diese werden zu bestimmten Zeitpunkten während eines Commits aufgerufen. Dadurch können Plausibilitätschecks durchgeführt werden und ggf. ein Commit verhindert werden. Baut man in den sog. pre-commit-hook eine Prüfung ein, die eine leere Meldung verhindert, bleiben die Log-Meldungen deutlich informativer

Das folgende Beispiel zeigt das pre-commit-Skript. Es überprüft, ob mindestens 15 Zeichen und alphanumerischer Text eingegeben wurde.

#!/bin/bash

REPOS="$1"
TXN="$2"

LOG=`svnlook log -t "$TXN" "$REPOS"`
COUNT=`echo $LOG |wc -c`

# Check for at least some chars.
if [ $COUNT -lt 15 ]
then
echo 1>&2
echo 1>&2  "Need at least 15 characters for commit message!"
exit 1
fi

# Check for some clear text characters
echo "$LOG" | grep "[a-zA-Z0-9]" > /dev/null && exit 0
echo 1>&2
echo 1>&2  "Need a clear text message!"
exit 1

Die Konfiguration, um anonyme Commits zu verhindern, muss im Apache erfolgen. In unserer Firma authentifiziert und authorisiert Apache gegen OpenLDAP. Hier kann eine Authentifizierung erzwungen werden und anonymer aber lesender Zugriff erlaubt werden. Bei Schreibzugriffen wird eine Authorisierung gegen eine LDAP-Gruppe durchgeführt.

Die Konfiguration für ein vollständiges Subversion-Repository sieht wie folgt aus:

<IfModule mod_dav_svn.c>

<Location /subversion/webdev>>
        DAV svn
        SVNPath /data/subversion/webdev
        Options +Indexes
        Allow from all

        AuthType Basic
        AuthName "Subversion Repository: webdev"

        AuthzLDAPAuthoritative off
        AuthBasicProvider ldap
        AuthLDAPURL "ldap://master.domain.de slave.domain.de/ou=Users,dc=domain,dc=de?uid?sub?(objectClass=*)"
#       <LimitExcept GET PROPFIND OPTIONS REPORT>
                Require ldap-group cn=webdev,ou=Groups,dc=domain,dc=de
#       </LimitExcept>
        AuthLDAPGroupAttribute memberUid
        AuthLDAPGroupAttributeIsDN off
        SSLRequireSSL
<Location>
</IfModule>

Diese Konfiguration verlangt eine Authorisierung gegen die LDAP-Gruppe webdev. Soll lesender anonymer Zugriff gestattet werden, müssen die # entfernt werden. Zusätzlich wird durch die Direktive SSLRequireSSL SSL-Verschlüsselung verlangt.

Quellen:
www.apache.org
subversion.tigris.org

Erfahrungen mit der OpenSSL Schwachstelle unter Debian

 Linux, Systemmanagement  Kommentare deaktiviert für Erfahrungen mit der OpenSSL Schwachstelle unter Debian
Mai 282008
 

Am 13.05.2008 kam eine Meldung über den Heise-Ticker, dass Debian durch einen Patch eine Schwachstelle bei der Schlüsselgenerierung eingepflegt hat. Das Brisante daran ist, dass dieser Patch vor nahezu zwei Jahren eingespielt wurde.

Was passiert genau dabei? Der Patch hat dafür gesorgt, dass der Zufallszahlengenerator aus den Prozess-IDs gefüttert wird. Der Wertebereich ist unter Linux mit 1-32767 äußerst eingeschränkt. Jede Software, die diesen Generator benutzt, erzeugt somit schwache Schlüsselpaare. Dazu gehört z.B. SSH. Jeder Rechner, der nach dem September 2006 mit Debian oder Ubuntu installiert wurde, generiert somit bei der Installation ein schwaches Host-Key-Pärchen. Jeder Benutzer, der unter Ubuntu oder Debian einen neuen Private Key zum Einloggen generiert hat, hat somit auch ein schwaches Schlüsselpärchen generiert. Damit können die Schlüssel sehr schnell geknackt werden.

Was heißt das in der Konsequenz? Das heißt, dass alle mit Debian oder Ubuntu erzeugten Schlüssel die nach dem September 2006 generiert wurden neu generiert werden müssen. Macht man über den üblichen Weg ein Software Upgrade, wird das für die SSH Host Keys automatisch erledigt. Loggt man sich danach auf so einem aufgefrischtem Rechner ein, wird man abgewiesen mit dem Hinweis, dass in der known_hosts-Datei der Schlüssel nicht mehr passt. Der Eintrag in dieser Datei sollte daher gelöscht werden. Das SSH-Paket hat jetzt ein neues Tool: ssh-vulnkey, mit dem die Schlüssel in der authorized_keys-Datei überprüft werden können. Schwache Schlüssel sollten aus dieser Datei entfernt werden. Zusätzlich lässt ein SSH-Daemon diese Schlüssel beim Einloggen nicht mehr zu. Das Neugenerieren eines Schlüssels ist dabei kein Problem. Eher ist es problematisch, dass der Public Key auf Dutzenden von Rechnern untergebracht sein kann. Ein weiteres Problem sind SSL-Zertifikate, so wie sie für Webseiten verwendet werden. Selbst, wenn man keine selbstsignierten Zertifikate verwendet und Zertifikate kauft, wird der Private Key selbstgeneriert. In der Konsequenz müssen nicht nur die Zertifikate neu generiert bzw. gekauft werden, sondern der Private Key muss komplett neu samt Certificate Request generiert werden.

In einem Unternehmen wie itemis mussten nicht weniger als 30 Zertifkate neu generiert werden. Diese mussten natürlich auch auf den Hosts installiert werden. Hierbei kam wenigstens die modellgetriebene Serverkonfiguration unterstützend zum Einsatz. Die Entwicklungsrechner haben zwar selbstsignierte Zertifikate, aber gerade für die öffentlich zugänglichen Server mussten neue Zertifkate gekauft werden. Zusätzlich kam die Überprüfung der SSH-Schlüssel. Die Software-Upgrades haben die Host Keys automatisch erneuert. Die Überprüfung und der Ersatz der User-Schlüssel hat aber sehr viel mehr Aufwand gekostet. Alles in Allem hat dieser Vorgang zwei Tage Arbeit gekostet.

Hat sich der Aufwand gelohnt? Wer hier nein sagt, handelt schlichtweg grob fahrlässig! Im Moment ist es nur Aufwand. Aber langfristig möchte man sich nicht der Gefahr aussetzen, dass Daten ausspioniert werden oder gar Rechner gehackt werden. Die heutige Meldung begründet diese Sorge. Es lassen sich ohne wenig Probleme von außen Rechner ermitteln, die sich hacken lassen!

Wer mehr zu diesem Thema lesen möchte und wie man mit dieser Schwachstelle umgeht, können Sie hier lesen:
http://www.heise.de/security/Der-kleine-OpenSSL-Wegweiser–/artikel/108001

Es gibt auch ein Tool, das schwache Schlüssel ausfindig machen kann. Es hat aber den Nachteil, dass es nicht alle Schlüssel erkennt. Im Zweifel sollte man lieber einen Schlüssel zu viel als zu wenig neu generieren:
http://security.debian.org/project/extra/dowkd/dowkd.pl.gz