Gestern lief auf Fritz-Radio Chaosradio Folge 172 zum Thema “SSL. Oder: Einmal aufmachen bitte – Warum die Verschlüsselung nicht (mehr) funktioniert.” Hier ist die MP3.

Alle braven Nutzer bekommen seit Ewigkeiten beigebracht: Wenn wir sicher surfen wollen, müsst ihr ein httpS vor die Webadresse eurer Onlinebank schreiben. Nur dann ist die Kommunikation wirklich, ehrlich und total sicher. Und das gilt auch für alle anderen Seiten, bei denen irgendwelchen Informationen übertragen werden. Oder halt eben nicht. Spätestens seit den Skandalen um Zertifikatsherausgeber wie Diginotar (Infos), dem Abhören von GMail-Traffic durch den Iran und der weitreichenden BEAST-Attacke ist klar: SSL und TLS sind kaputt. So kaputt, dass sich die Frage stellt, ob es ein Fehler im System oder eine behebbare Sicherheitslücke ist. Eine Problem um das es im Chaosradio gehen soll. Stephan ”tomate” Urbach, fukami und Matthias “wetterfrosch” Mehldau werden monoxyd und euch die Funktionsweise, Fallstricke und fundamentalen Fehler bei verschlüsselter Datenübertragung im Netz erklären, beleuchten und diskutieren.

Globaleaks behauptet nach einer Analyse diverser Systeme in seinem LeakDirectory, die bisherigen Whistleblower-Systeme seien nicht sicher: "The existing software lacked basic privacy-aware (anonymity) and security features (encryption)" (Slide 6/45). Ich frage mich, wie man zu dieser Aussage kommen kann, ...

Bitte auf der Website weiterlesen.

Globaleaks behauptet nach einer Analyse diverser Systeme in seinem LeakDirectory, die bisherigen Whistleblower-Systeme seien nicht sicher: "The existing software lacked basic privacy-aware (anonymity) and security features (encryption)" (Slide 6/45). Ich frage mich, wie man zu dieser Aussage kommen kann, ...

Bitte auf der Website weiterlesen.

Mal wieder ist WikiLeaks in aller Munde. Mal wieder ist Julian Assange auf den Titelblättern. Die Massenmedien vermelden das Ende eines revolutionären Projekts, besingen den Untergang eines Anti-Helden. Dabei zeigt die jüngste Episode um die Leaking-Plattform vor allem eins: ...

Bitte auf der Website weiterlesen.

Mal wieder ist WikiLeaks in aller Munde. Mal wieder ist Julian Assange auf den Titelblättern. Die Massenmedien vermelden das Ende eines revolutionären Projekts, besingen den Untergang eines Anti-Helden. Dabei zeigt die jüngste Episode um die Leaking-Plattform vor allem eins: ...

Bitte auf der Website weiterlesen.

Philip Banse hat für Deutschlandradio Kultur ein 30 Minuten langes Feature zum Thema “Hacker im Handynetz – Wie unsicher sind deutsche Mobilfunknetze?” gemacht. Davon gibt es das Transcript und eine MP3 zum Nachhören.

Das Abhören von Handygesprächen war bisher eine Sache von Polizei und Geheimdiensten. Mittlerweile kann jeder mit etwas technischem Sachverstand Handys ausspionieren oder sogar Handynetze teilweise lahmlegen. Denn nahezu alle Mobilfunknetze der Welt basieren auf GSM – dem global System for Mobile Communication. Doch ausgerechnet dieses so wichtige technische System unserer Gesellschaft ist voller Fehler und Sicherheitslücken.

Nicht nur Gespräche können abgehört und SMS mitgelesen werden, auch sensible Daten, die über GSM-Netze verschickt werden, sind leicht von Dritten abzufangen, wie zum Beispiel beim Telefonbanking oder in der Kommunikation zwischen Zügen. Bislang haben die Netzbetreiber jedoch nichts getan, um die Sicherheitslücken zu schließen.

Thomas Stadler hat anscheinend mindestens eine Nachtschicht eingelegt, in der er eine lange und bedrohlich anmutende Liste der bereits genehmigten Überwachungsmaßnahmen zusammengetragen hat. Kostprobe gefällig? Bitte:

Aufzeichnung des E-Mail-Verkehrs während der Übertragungsphase (§ 100a StPO)
Ermittlung der sog. IMSI zur Identifizierung oder Lokalisierung durch sog. IMSI-Catcher (§ 100i StPO). Die IMSI (International Mobile Subscriber Identity) ist eine Kennung mit der ein Mobilfunkteilnehmer in den Funknetzen eindeutig identifiziert werden kann.*
Zugriff auf Daten in geschlossenen Internetforen mithilfe von Zugangsdaten, die ohne oder gegen den Willen der Kommunikationsbeteiligten erlangt wurden (§ 100a StPO bei Liveüberwachung über Netzbetreiber; §§ 94, 98 StPO gegenüber Telemediendiensten nach Abschluss des Telekommunikationsvorgangs, betrifft z.B. Chatprotokolle, Bilder etc.)
Ermittlung von PIN/PUK (§§ 113 Abs. 1 S. 2 TKG, 161, 163 StPO)

Die gesamte Liste gibt es auf Internet-Law. Zudem gibt es eine begrüßenswerte Initiative des DAV, die bestehende Gesetze überprüfen soll: Experimentelle Gesetzgebung.

* Dieses Verfahren hat die Dresdner Polizei bei ihrer kürzlich erfolgten beispiellosen Trackingaktion verwendet.

Einsortiert unter:Datenschutz, Netzpolitik, Politik, Telekommunikation, Web 2.0

Sollte zu jeder Website gehören: der rote Notfallordner!

Endlich steht die neue Website, das Projekt ist beendet, alle Arbeit getan. Aber halt, noch nicht ganz: Neben dem initialen Aufwand für einen neuen Webauftritt gibt es natürlich auch im laufenden Betrieb das eine oder andere zu tun. Darum geht es in diesem Artikel.

Nicht alle besprochenen Punkte sind dabei für jeden gleichermaßen relevant. Dies hängt beispielsweise davon ab, wie umfangreich und unternehmenskritisch die Website ist und welche Entscheidungen Sie beim Thema Hosting getroffen haben. Dennoch sollten Sie bei jedem der folgenden Themen einmal überlegen, wie es Ihre neue Website im zukünftigen Betrieb betrifft.

Verantwortlichkeiten regeln – Kommunikation etablieren
Wenn eine Website vom Projektstatus in den Betrieb übergeht, gibt es in aller Regel Änderungen in den Verantwortlichkeiten. Vielleicht haben Sie einen Dienstleister für das Projekt engagiert, der sich nach getaner Arbeit und erfolgreicher Abnahme verabschiedet. Oder in Ihrem Unternehmen wechselt die Website die zuständige Abteilung. Oder Sie haben alles alleine zusammen mit einem Hoster gemacht und wenden sich nun neuen Aufgaben zu. In jedem Fall sollten Sie sich folgende Fragen stellen:

Wer ist der ‘Owner’ der Website? Also wer hat die Gesamtverantwortung und übernimmt die Koordination, z.B. wenn eine größere Änderung oder ein Update ansteht?

Wer ist für die Inhalte verantwortlich? Wen kann man anrufen, wenn Inhalte durcheinandergeraten sind? Und wer ist die Vertretung?


Wer ist für den technischen Betrieb verantwortlich? Wer ist zuständig, wenn statt der Site nur noch eine Fehlermeldung kommt? Auch hier: unbedingt eine Vertretungsregelung etablieren (wenn nicht eine ganze Abteilung verantwortlich ist).

Wie ist die Schnittstelle zwischen technischem Betrieb und Hoster geregelt? Meist gibt es technische Dinge, die innerhalb Ihrer Firma erledigt werden und andere, die ein Dienstleister -  z.B. der Hoster – tut (siehe dazu auch Folge 6 dieses Workshops). Hier ist äußerst hilfreich, wenn es klare Regelungen dazu gibt. Typische Fragen:

Wer macht Betriebssystem-Updates? (z.B. Linux/Windows, Apache, PHP, Datenbank)
Wer macht Applikations-Updates? (CMS, Plugins, etc.)
Wer macht die Datensicherung auf Systemimage-Ebene?
Wer macht die Datensicherung auf Datenbank-Ebene?
Wer macht die Datensicherung auf Content-Ebene? (z.B. innerhalb CMS)

Außerdem sollte an dieser Schnittstelle eine gute Kommunikation ‘auf Arbeitsebene’ etabliert werden. Dies ist im Ernstfall meist der wichtigste Faktor für die schnelle Lösung eines Problems.

Wer muss wen in welchem Fall informieren? Überlegen Sie sich, in welchen Fällen Dinge koordiniert werden müssen. Beispiele: Macht die interne IT oder der Hoster Updates einfach dann, wenn es ihm passt? Oder fragt er vorher beim Owner nach, ob zu dem Zeitpunkt gerade eine Präsentation läuft, in der die Website unbedingt funktionieren muss? Ist die Website nach einem CMS-Update wochenlang unbemerkt verunstaltet, oder wird dies anschließend von jemandem systematisch getestet? Wird vor einem Update immer eine Sicherung gefahren?

Dokumentation geordnet ablegen – oder: erstellen
Natürlich gehört zu einem erfolgreichen Website-Projekt auch eine vollständige Dokumentation:

Wie genau wurde das System aufgesetzt, welche Besonderheiten (z.B. Plugins) werden benutzt, wie ist alles parametrisiert.
Auf welcher Hardware bzw. virtuellen Umgebung läuft das Ganze?
Wie ist der Admin-Zugang zum System?
Welche System-Passwörter wurden gesetzt?
Wie laufen die Datensicherung und das Restore technisch ab?

Nachdem dies alles aufgeschrieben wurde, ist es wichtig,

die Information so abzulegen, dass sie jederzeit schnell wieder auffindbar ist
dass jemand die Dokumentation pflegt, wenn sich etwas ändert (der ‘Dokument-Owner’)
dass jede Veränderung zum Initialzustand als Logeintrag im Anhang des Dokuments aufgenommen wird.

Fallen Sie beim Thema Dokumentation bitte nicht auf die typischen Ausreden herein! Meine in langjährigen Feldversuchen ermittelten Top 3:

Dazu haben wir keine Zeit / Geld!
Ist doch alles Standard!
Das ist doch sowieso veraltet, wenn man’s braucht!

Es geht nicht um ein 300-Seiten-Dokument. Vermutlich passt alles Notwendige auf drei bis zehn A4-Seiten. Entscheidend ist, dass diese Dokumentation zum Beispiel nach einem Jahr ggf. jemand anderen dazu befähigt, das System zu verstehen, Änderungen nachzuvollziehen und Probleme zu fixen.

Ein Zweitsystem kann sich lohnen
Bewährt hat sich übrigens, jemand anderen mit der erstellten Dokumentation ein Zweitsystem aufsetzen zu lassen. Damit haben Sie drei Fliegen mit einer Klappe geschlagen:

Sie haben die Dokumentation qualitätsgesichert
Sie können den Restore wirklich einmal testen, nämlich auf dieses Zweitsystem
Sie können zukünftig Ihre Updates und Anpassungen auf dem Zweitsystem testen, bevor Sie die produktive Website zerschießen.

Identity Management…
Natürlich ist es wichtig, dass nur berechtigte Personen Ihren Webauftritt verändern können.

Hilfreiche Fragen dazu:

Sind noch irgendwelche Standard-User aktiv, mit denen man in das Nun-Produktiv-System kann?
Sind Testuser-IDs mit leicht zu erratenden Passwörtern aktiv?
Können alle User-IDs das, was sie sollen, aber nicht mehr?

Und im laufenden Betrieb:

Werden User-IDs gesperrt, wenn ein Mitarbeiter das Unternehmen verlässt?
Wie läuft der Prozess dazu ab und wer macht dies?
Wer ist dafür verantwortlich? (Gut, wenn man oben einen Website-Owner definiert hat.)

…und Hardening-Massnahmen
In diesem Zusammenhang ist es auch sinnvoll, darüber nachzudenken, welche Schwachstellen das CMS an dieser Stelle von Haus aus hat und wie man diesen ggf. mit einfachen Maßnahmen entgegnen kann. Das kann über einfache Konfiguration laufen oder z.B. über Plugins. Typische Themen:

Wird der Account nach einigen Anmeldeversuchen mit falschem Passwort gesperrt (oder kommt ein Angreifer mittels Brute-Force schnell ins System)?
Wird ein Administrator automatisch bei Verdacht auf solche Angriffsversuche informiert? (Und reagiert er dann geeignet?)
Werden die User-IDs / Kennwörter immer verschlüsselt übertragen?
Welche Schwachstellen sind für das System bekannt (z.B. Default-Datenbanknamen) und welche Gegenmassnahmen gibt es?

Und auch immer wichtig in diesem Kontext:

Sind die User dazu sensibilisiert, starke Passwörter zu nutzen und diese z.B. nicht unverschlüsselt in ihrem Webbrowser zu speichern?

Vergegenwärtigen Sie sich, welchen Image-Schaden zum Beispiel ein tagelang unbemerktes Defacement – also eine Verunstaltung Ihrer Website – für Ihr Unternehmen bedeuten kann, bevor Sie solche Maßnahmen leichtfertig übergehen.

Monitoring der Verfügbarkeit

Wie lange dürfen Störungen Ihres Webauftritts unbemerkt bleiben?
Und wie lange könnte es im schlechtesten Fall dauern, bis Sie tatsächlich mitbekommen, dass etwas nicht stimmt?
Können Sie es sich leisten, dass Ihre Kunden Sie darauf aufmerksam machen, dass Ihre Website nicht verfügbar ist?

Die Beantwortung dieser Fragen gibt Ihnen ein Gefühl dafür, wieviel Verfügbarkeits-Überwachung Sie benötigen. Beim einen reicht es möglicherweise, wenn er jeden Morgen seine Website beim Browserstart lädt – und sieht, dass sie noch funktioniert. Der andere verlässt sich lieber auf ein professionelles Monitoring seines Hosters, der internen IT-Abteilung oder eines Drittanbieters. Auch einige kostenlose Angebote findet man dazu im Netz. Beachten Sie, dass es nicht reicht, wenn die Erreichbarkeit des Webservers über das Netzwerk geprüft wird (“Ping”), idealerweise sollte auch das Vorhandensein der Inhalte gecheckt werden (z.B. Prüfung mittels HTTP-Request).

Haben Sie einen Notfallplan?
Wenn es zu Problemen im Betrieb Ihrer Website kommt, hilft gute Vorbereitung. Während bei den einen die operative Hektik beginnt, greifen andere zum roten Ordner und arbeiten routiniert ihren Notfallplan ab. Wie gehen Sie in einem solchen Fall vor? Je wichtiger Ihre Website ist, desto besser sollten Sie natürlich für Notfälle vorbereitet sein. Dabei hilft Ihnen vieles, was zuvor in diesem Artikel erwähnt wurde: Eine saubere aktuelle Dokumentation, Zugriff auf alle nötigen Kontaktinformationen, Klarheit bei den Verantwortlichkeiten, Gewissheit in Sachen Backup und Restore. Aber auch eine Liste mit Aktionen und Massnahmen, die Sie oder Ihre Vertretung abarbeiten können, ist Gold wert.

Und wenn das Problem nicht schnell zu lösen ist: Wieviel Zeit brauchen Sie, um eine Ersatz-Seite zu aktivieren, vielleicht erstmal mit reduziertem Funktionsumfang? Auch ein “Diese Website steht momentan wegen Wartungsarbeiten nicht zur Verfügung. Bitte probieren Sie es später nochmal.” ist besser, als eine SQL-Fehlermeldung, ein Defacement oder eine gefälschte Newsmeldung, dass Ihr CEO zurückgetreten ist.

Fazit
Auch nachdem Sie Ihr Website-Projekt abgeschlossen haben, gibt es noch einiges zu tun. Der angemessene Umfang sieht natürlich bei der Website eines Selbstständigen anders aus als beim Firmenportal eines Großkonzerns. Trotzdem gibt es für jede Größenordnung im Prinzip die gleichen Punkte zu berücksichtigen. Hier zahlt es sich in der Regel aus, wenn man sich zu jedem Thema frühzeitig Gedanken macht und sinnvolle Massnahmen für seinen Website-Betrieb daraus ableitet.

-

Frank Herberg, Jahrgang 1969, lebt in Zürich und ist Informationstechnologie-Profi aus Leidenschaft. In seinen Spezialgebieten IT-Infrastruktur, Netzwerke und Security verfolgt er aktuelle Entwicklungen seit mehr als 15 Jahren. Sein Know-how setzte er in den vergangenen Jahren als Technologie-Berater und Projekt-Manager in verschiedenen internationalen IT-Projekten in die Praxis um. Zur Zeit genießt er ein Sabbatical. In seinem Techblog gibt er Anwendertipps und schreibt über Themen wie neue Technologien oder Internetsicherheit.

Nächste Folge:
19. Letzte Fol[…]

Sollte zu jeder Website gehören: der rote Notfallordner!

Endlich steht die neue Website, das Projekt ist beendet, alle Arbeit getan. Aber halt, noch nicht ganz: Neben dem initialen Aufwand für einen neuen Webauftritt gibt es natürlich auch im laufenden Betrieb das eine oder andere zu tun. Darum geht es in diesem Artikel.

Nicht alle besprochenen Punkte sind dabei für jeden gleichermaßen relevant. Dies hängt beispielsweise davon ab, wie umfangreich und unternehmenskritisch die Website ist und welche Entscheidungen Sie beim Thema Hosting getroffen haben. Dennoch sollten Sie bei jedem der folgenden Themen einmal überlegen, wie es Ihre neue Website im zukünftigen Betrieb betrifft.

Verantwortlichkeiten regeln – Kommunikation etablieren
Wenn eine Website vom Projektstatus in den Betrieb übergeht, gibt es in aller Regel Änderungen in den Verantwortlichkeiten. Vielleicht haben Sie einen Dienstleister für das Projekt engagiert, der sich nach getaner Arbeit und erfolgreicher Abnahme verabschiedet. Oder in Ihrem Unternehmen wechselt die Website die zuständige Abteilung. Oder Sie haben alles alleine zusammen mit einem Hoster gemacht und wenden sich nun neuen Aufgaben zu. In jedem Fall sollten Sie sich folgende Fragen stellen:

Wer ist der ‘Owner’ der Website? Also wer hat die Gesamtverantwortung und übernimmt die Koordination, z.B. wenn eine größere Änderung oder ein Update ansteht?

Wer ist für die Inhalte verantwortlich? Wen kann man anrufen, wenn Inhalte durcheinandergeraten sind? Und wer ist die Vertretung?


Wer ist für den technischen Betrieb verantwortlich? Wer ist zuständig, wenn statt der Site nur noch eine Fehlermeldung kommt? Auch hier: unbedingt eine Vertretungsregelung etablieren (wenn nicht eine ganze Abteilung verantwortlich ist).

Wie ist die Schnittstelle zwischen technischem Betrieb und Hoster geregelt? Meist gibt es technische Dinge, die innerhalb Ihrer Firma erledigt werden und andere, die ein Dienstleister -  z.B. der Hoster – tut (siehe dazu auch Folge 6 dieses Workshops). Hier ist äußerst hilfreich, wenn es klare Regelungen dazu gibt. Typische Fragen:

Wer macht Betriebssystem-Updates? (z.B. Linux/Windows, Apache, PHP, Datenbank)
Wer macht Applikations-Updates? (CMS, Plugins, etc.)
Wer macht die Datensicherung auf Systemimage-Ebene?
Wer macht die Datensicherung auf Datenbank-Ebene?
Wer macht die Datensicherung auf Content-Ebene? (z.B. innerhalb CMS)

Außerdem sollte an dieser Schnittstelle eine gute Kommunikation ‘auf Arbeitsebene’ etabliert werden. Dies ist im Ernstfall meist der wichtigste Faktor für die schnelle Lösung eines Problems.

Wer muss wen in welchem Fall informieren? Überlegen Sie sich, in welchen Fällen Dinge koordiniert werden müssen. Beispiele: Macht die interne IT oder der Hoster Updates einfach dann, wenn es ihm passt? Oder fragt er vorher beim Owner nach, ob zu dem Zeitpunkt gerade eine Präsentation läuft, in der die Website unbedingt funktionieren muss? Ist die Website nach einem CMS-Update wochenlang unbemerkt verunstaltet, oder wird dies anschließend von jemandem systematisch getestet? Wird vor einem Update immer eine Sicherung gefahren?

Dokumentation geordnet ablegen – oder: erstellen
Natürlich gehört zu einem erfolgreichen Website-Projekt auch eine vollständige Dokumentation:

Wie genau wurde das System aufgesetzt, welche Besonderheiten (z.B. Plugins) werden benutzt, wie ist alles parametrisiert.
Auf welcher Hardware bzw. virtuellen Umgebung läuft das Ganze?
Wie ist der Admin-Zugang zum System?
Welche System-Passwörter wurden gesetzt?
Wie laufen die Datensicherung und das Restore technisch ab?

Nachdem dies alles aufgeschrieben wurde, ist es wichtig,

die Information so abzulegen, dass sie jederzeit schnell wieder auffindbar ist
dass jemand die Dokumentation pflegt, wenn sich etwas ändert (der ‘Dokument-Owner’)
dass jede Veränderung zum Initialzustand als Logeintrag im Anhang des Dokuments aufgenommen wird.

Fallen Sie beim Thema Dokumentation bitte nicht auf die typischen Ausreden herein! Meine in langjährigen Feldversuchen ermittelten Top 3:

Dazu haben wir keine Zeit / Geld!
Ist doch alles Standard!
Das ist doch sowieso veraltet, wenn man’s braucht!

Es geht nicht um ein 300-Seiten-Dokument. Vermutlich passt alles Notwendige auf drei bis zehn A4-Seiten. Entscheidend ist, dass diese Dokumentation zum Beispiel nach einem Jahr ggf. jemand anderen dazu befähigt, das System zu verstehen, Änderungen nachzuvollziehen und Probleme zu fixen.

Ein Zweitsystem kann sich lohnen
Bewährt hat sich übrigens, jemand anderen mit der erstellten Dokumentation ein Zweitsystem aufsetzen zu lassen. Damit haben Sie drei Fliegen mit einer Klappe geschlagen:

Sie haben die Dokumentation qualitätsgesichert
Sie können den Restore wirklich einmal testen, nämlich auf dieses Zweitsystem
Sie können zukünftig Ihre Updates und Anpassungen auf dem Zweitsystem testen, bevor Sie die produktive Website zerschießen.

Identity Management…
Natürlich ist es wichtig, dass nur berechtigte Personen Ihren Webauftritt verändern können.

Hilfreiche Fragen dazu:

Sind noch irgendwelche Standard-User aktiv, mit denen man in das Nun-Produktiv-System kann?
Sind Testuser-IDs mit leicht zu erratenden Passwörtern aktiv?
Können alle User-IDs das, was sie sollen, aber nicht mehr?

Und im laufenden Betrieb:

Werden User-IDs gesperrt, wenn ein Mitarbeiter das Unternehmen verlässt?
Wie läuft der Prozess dazu ab und wer macht dies?
Wer ist dafür verantwortlich? (Gut, wenn man oben einen Website-Owner definiert hat.)

…und Hardening-Massnahmen
In diesem Zusammenhang ist es auch sinnvoll, darüber nachzudenken, welche Schwachstellen das CMS an dieser Stelle von Haus aus hat und wie man diesen ggf. mit einfachen Maßnahmen entgegnen kann. Das kann über einfache Konfiguration laufen oder z.B. über Plugins. Typische Themen:

Wird der Account nach einigen Anmeldeversuchen mit falschem Passwort gesperrt (oder kommt ein Angreifer mittels Brute-Force schnell ins System)?
Wird ein Administrator automatisch bei Verdacht auf solche Angriffsversuche informiert? (Und reagiert er dann geeignet?)
Werden die User-IDs / Kennwörter immer verschlüsselt übertragen?
Welche Schwachstellen sind für das System bekannt (z.B. Default-Datenbanknamen) und welche Gegenmassnahmen gibt es?

Und auch immer wichtig in diesem Kontext:

Sind die User dazu sensibilisiert, starke Passwörter zu nutzen und diese z.B. nicht unverschlüsselt in ihrem Webbrowser zu speichern?

Vergegenwärtigen Sie sich, welchen Image-Schaden zum Beispiel ein tagelang unbemerktes Defacement – also eine Verunstaltung Ihrer Website – für Ihr Unternehmen bedeuten kann, bevor Sie solche Maßnahmen leichtfertig übergehen.

Monitoring der Verfügbarkeit

Wie lange dürfen Störungen Ihres Webauftritts unbemerkt bleiben?
Und wie lange könnte es im schlechtesten Fall dauern, bis Sie tatsächlich mitbekommen, dass etwas nicht stimmt?
Können Sie es sich leisten, dass Ihre Kunden Sie darauf aufmerksam machen, dass Ihre Website nicht verfügbar ist?

Die Beantwortung dieser Fragen gibt Ihnen ein Gefühl dafür, wieviel Verfügbarkeits-Überwachung Sie benötigen. Beim einen reicht es möglicherweise, wenn er jeden Morgen seine Website beim Browserstart lädt – und sieht, dass sie noch funktioniert. Der andere verlässt sich lieber auf ein professionelles Monitoring seines Hosters, der internen IT-Abteilung oder eines Drittanbieters. Auch einige kostenlose Angebote findet man dazu im Netz. Beachten Sie, dass es nicht reicht, wenn die Erreichbarkeit des Webservers über das Netzwerk geprüft wird (“Ping”), idealerweise sollte auch das Vorhandensein der Inhalte gecheckt werden (z.B. Prüfung mittels HTTP-Request).

Haben Sie einen Notfallplan?
Wenn es zu Problemen im Betrieb Ihrer Website kommt, hilft gute Vorbereitung. Während bei den einen die operative Hektik beginnt, greifen andere zum roten Ordner und arbeiten routiniert ihren Notfallplan ab. Wie gehen Sie in einem solchen Fall vor? Je wichtiger Ihre Website ist, desto besser sollten Sie natürlich für Notfälle vorbereitet sein. Dabei hilft Ihnen vieles, was zuvor in diesem Artikel erwähnt wurde: Eine saubere aktuelle Dokumentation, Zugriff auf alle nötigen Kontaktinformationen, Klarheit bei den Verantwortlichkeiten, Gewissheit in Sachen Backup und Restore. Aber auch eine Liste mit Aktionen und Massnahmen, die Sie oder Ihre Vertretung abarbeiten können, ist Gold wert.

Und wenn das Problem nicht schnell zu lösen ist: Wieviel Zeit brauchen Sie, um eine Ersatz-Seite zu aktivieren, vielleicht erstmal mit reduziertem Funktionsumfang? Auch ein “Diese Website steht momentan wegen Wartungsarbeiten nicht zur Verfügung. Bitte probieren Sie es später nochmal.” ist besser, als eine SQL-Fehlermeldung, ein Defacement oder eine gefälschte Newsmeldung, dass Ihr CEO zurückgetreten ist.

Fazit
Auch nachdem Sie Ihr Website-Projekt abgeschlossen haben, gibt es noch einiges zu tun. Der angemessene Umfang sieht natürlich bei der Website eines Selbstständigen anders aus als beim Firmenportal eines Großkonzerns. Trotzdem gibt es für jede Größenordnung im Prinzip die gleichen Punkte zu berücksichtigen. Hier zahlt es sich in der Regel aus, wenn man sich zu jedem Thema frühzeitig Gedanken macht und sinnvolle Massnahmen für seinen Website-Betrieb daraus ableitet.

-

Frank Herberg, Jahrgang 1969, lebt in Zürich und ist Informationstechnologie-Profi aus Leidenschaft. In seinen Spezialgebieten IT-Infrastruktur, Netzwerke und Security verfolgt er aktuelle Entwicklungen seit mehr als 15 Jahren. Sein Know-how setzte er in den vergangenen Jahren als Technologie-Berater und Projekt-Manager in verschiedenen internationalen IT-Projekten in die Praxis um. Zur Zeit genießt er ein Sabbatical. In seinem Techblog gibt er Anwendertipps und schreibt über Themen wie neue Technologien oder Internetsicherheit.

Nächste Folge:
19. Letzte Fol[…]

Royal Dutch Shell plc - kurz Shell - gab grünes Licht für das Projekt Prelude Floating Liquefied Natural Gas. Hierbei handelt es sich um zu 100 % von Shell finanziertes Projekt, die weltweit erste schwimmende Flüssigerdgasanlage (FLNG). Das “Schiff” soll knapp 90 Seemeilen vor der Nordküste Australiens am Meeresboden verankert sein und Gas aus Offshore-Feldern fördern, das direkt an Bord gekühlt und damit verflüssigt wird.
FLNG soll in einer südkoreanischen Werft gebaut werden. Der Koloss wird 488 m lang, länger als vier Fußballfelder. Voll ausgerüstet bringt die Anlage über 600.000 t auf die Waage, was dem sechsfachen Gewicht des größten Flugzeugträgers der Welt entspricht. Die Superlative endet hierbei nicht: Shell informiert, dass 260.000 t des Gewichts alleine auf die für den Bau erforderlichen Stahlelemente entfallen, was in etwa mit dem Fünffachen der Hafenbrücke in Sydney zu vergleichen wäre.

Foto: "Prelude", die gigantische FLNG-Anlage / Shell

„Durch unsere innovative FLNG-Technologie können wir dann auch Offshore-Gasfelder erschließen, deren Entwicklung sonst zu kostspielig wäre“, so Malcolm Brinded, Executive Director Upstream International bei Shell. „Unsere Entscheidung für dieses Projekts bedeutet einen echten Durchbruch für die gesamte LNG-Branche, da es entscheidend zur Deckung der weltweit steigenden Nachfrage nach dem am saubersten verbrennenden fossilen Brennstoff beitragen wird.“

Shell setzt bei der FLNG-Technologie auf Innovation. Einerseits stellt eine Offshore-Anlage gute Ergänzung der an Land erschlossenen Gasreserven, auf der anderen Seite muss sie besondere Voraussetzungen erfüllen um “seetauglich” zu sein. “Prelude”, wie die Anlage heißt, soll einem Superzyklon, also einem Wirbelsturm der Kategorie 5, standhalten können.
Auf der Wirbelsturmskala wird ein solcher Zyklon als F5-Zyklon klassifiziert. In der Fujita-Skala und Saffir-Simpson-Skala ist es die höchste Platzierung.
Das von “Prelude” geförderte und durch Kühlung auf -162° C verflüssigte Gas wird damit auf das Sechshundertfache seines ursprünglichen Volumens komprimiert. Gedacht ist, dass sowohl Erdgas wie anderen Produkte direkt an der Anlage von speziellen LNG-Tankern abgeholt werden sollen. Von dort werden sie “zur Belieferung der Märkte in aller Welt gebracht”, wie es offiziell bei Shell heißt. Bisher sah die Prozedur so aus, dass das auf See geförderte Gas über Leitungen an Land gebracht werden. Erst dort wurde es in einer LNG-Anlage verflüssigt und anschließend weiter transportiert.

“Prelude” wurde mit Hochdruck von Shell vorangetrieben. Die Zielsetzung ist, bereits zehn Jahre nach der Entdeckung der Gasvorkommen mit dem Abbau durch diese Anlage zu beginnen. Die FLNG-Anlage wird etwa 3 Billionen Kubikfuß Erdgas aus dem Prelude Feld fördern. Das Prelude-Gasfeld wurde im Jahr 2007 von Shell entdeckt.
Mit einer erwarteten Fördermenge von etwa 110.000 Barrel Öläquivalent pro Tag sollten jährlich mindestens 5,3 Mio. t an flüssigen Kohlenwasserstoffen hergestellt werden können. Hiervon werden Flüssigerdgas (LNG) 3,6 Mio. t, Kondensat 1,3 Mio. t und Flüssiggas (LPG) 0,4 Mio. t pro Jahr ausmachen. Shell geht davon aus, “Prelude” werde 25 Jahre lang im Prelude-Gasfeld verankert bleiben. Dennoch soll sie in späteren Erschließungsphasen auch aus benachbarten Feldern - an denen Shell Beteiligungen hält - fördern können.

Das Prelude-Projekt wird das erste australische Upstream-Projekt sein, bei dem Shell der Betreiber ist. Australien gehört zu Shells wichtigsten Wachstumsgebieten. Alleine im Bereich Upstream werden Shell Investitionen in den nächsten fünf Jahren etwa 30 Mrd. US$ erreichen.

Heute gibt es hier alten Scheiß: Vor vielen Jahren, in einem anderen Leben, habe ich im Rahmen der Ausbildung von Auszubildenden und Neuanstellungen eine Reihe von Slides produziert, die einige Grundlagen der Kryptographie erläutern, ohne daß das ganze übermäßig mathematisch werden würde. Den Text zu diesem Vortrag habe ich nie veröffentlicht, das hole ich hier einmal nach.

Ziel des Textes war es einmal, den Leuten bestimmte kryptographische Primitive und ihre Anwendung deutlich zu machen sowie die Rechtslage mit der Technik zu verknüpfen.
Weil ich uns allen die Mathematik erspart habe, muß man einige Annahmen glauben, anstatt sich durch die entsprechenden mathematischen Beweise zu kämpfen. Und zwar muß man glauben, daß es Algorithmen gibt, die in einer Richtung leicht und mit wenig Aufwand durchzuführen sind (etwa die Multiplikation einiger Zahlen), aber in der umgekehrten Richtung sehr aufwendig sind, weil keine Abkürzung existiert (etwa die Umkehrung einer Multiplikation: die Bestimmung der unbekannten Faktoren, die ein bestimmtes bekanntes Multiplikationsergebnis ergeben).

Mit Hilfe solcher Algorithmen kann man dann Verschlüsselungssysteme bauen.

Die Mathematik, die dem zugrunde liegt, ist von den Mathematikern auch sehr gut verstanden und allgemein bekannt und untersucht. In der Regel ist es auch nicht die Mathematik, die defekt ist, wenn ein Kryptosystem gehackt wird, sondern es ist die umgebende Infrastruktur, die kaputt geht: Zufallszahlengeneratoren, die keine zufälligen Zahlen produzieren oder Verwaltungssysteme für geheime Schlüssel, die geheimzuhaltende Daten herausgeben. Oder halt der Fehler, sich selbst einen Verschlüsselungsalgorithmus auszudenken ohne die entsprechende Mathematik zu beherrschen.

Aber von vorne:

Eine der Grunduaufgaben in der Kryptographie ist ein Sender, Andreas, der einer Empfängerin, Birgit, eine Nachricht senden möchte, ohne daß Dritte mithören können. Die Nachricht wird als Message (M) bezeichnet. Verschlüsselt wird sie mit einer Verschlüsselungsfunktion, die allgemein bekannt und gut untersucht ist, und diese Funktion braucht einen geheimen Schlüssel, den Key (K).

Mathematiker sind faule Säue, sie können sich nicht einmal aufraffen, Multiplikationspunkte zu schreiben (und schreiben also A*B einfach als AB). Entsprechend sollten sie die Formel C = f(K, M) (der verschlüsselte Chiphertext C ergibt sich aus der Anwendung der Verschlüsselungsfunktion f, die die Nachricht M und den Schlüssel K als Parameter hat) schreiben. Stattdessen notieren sie oft falsch C = K(M), als ob K eine Funktion und nicht der Schlüssel wäre.

Andreas verschlüsselt seine Nachricht an Birgit, weil er sich bedroht fühlt.

Wenn man sich mit Sicherheitsdingen beschäftigt ist es wichtig, diese Bedrohung auszuformlieren und die Ziele und Fähigkeiten des Angreifers zu benennen. Nur aus diesen Listen kann man die Gefahren ableiten und dann sagen, ob bestimmte vorgeschlagene Maßnahmen einen sinnvolle Abwehr gegen die Bedrohung darstellen oder nicht.

Man kann diesen Effekt gar nicht genug betonen: Wenn man sich mit Laien (oder in der Politik) über Bedrohungen unterhält, dann diskutieren diese Sicherheit oftmals in den Begriffen von Maßnahmen, anstatt über Angreifer, Bedrohungen, Eintrittswahrscheinlichkeiten und Schadenshöhen zu reden und die Maßnahmen anhang dieser Dinge auszuwählen oder zu bewerten. Das erzeugt dann jede Menge operative Hektik, verbessert die Sicherheit aber in der Regel kein Stück.

Das Schutzziel eines Kryptosystems ist gewissermaßen das Gegenteil eines Angriffes:

Ein Kryptosystem kann das Ziel haben, den Inhalt einer Nachricht geheim zu halten, d.h. nur der Absender und der Empfänger einer Nachricht können ihren Inhalt kennen, Dritte nicht. Eine schwächere Forderung wäre, eine Nachricht integer zu halten, also Veränderungen der Nachricht durch Dritte erkennbar zu machen. Eine stärkere Forderung wäre, nicht nur den Inhalt einer Nachricht vertraulich zu halten, sondern die Tatsache, daß zwei bestimmte Personen überhaupt miteinander kommuniziert haben zu verbergen - Unbeobachtbarkeit.

Man kann fordern, die Identitäten des Senders und des Empfängers voreinander zu verbergen - dann hat man Anonymität. Oder man kann fordern, daß die Identitäten des Senders und des Empfängers beweisbar bekannt und unfälschbar sind, dann bekommt man Authentizität.

Man kann fordern, daß ein System durch gefälschte oder defekte Nachrichten nicht offline gezwungen werden kann, daß es also Verfügbar bleibt.

Angreifer können versuchen, diese Schutzziele zu vereiteln, etwa indem man ihnen die Fähigkeit zugesteht, die Kommunikation mitzuhören, mitgehörte Nachrichten wiederholt abzusenden, Nachrichten zu verändern, sich in der Kommunikationskette zwischen Sender und Empfänger einzuschleichen und sich für die jeweilige Gegenstelle auszugeben, oder indem sie versuchen, die Kommunikation zwischen den beiden Parteien zu unterbrechen.

Man kann sehr starke Angreifer konstruieren, indem man ihnen die Fähigkeit zugesteht, die Hardware oder Systemsoftware des Senders oder des Empfängers von diesem unbemerkt zu verändern.

Und man muß Einsatzzwecke von Kryptographie unterscheiden: Es besteht ein grundlegender Unterschied in den Anforderungen zwischen Transportverschlüsselung (etwa das Abrufen von Webseiten über SSL) und Speicherverschlüsselung (etwa dem Ablegen von Dateien auf einer verschlüsselten Festplatte).

Bei Transportverschlüsselung hat man in der Regel die Anforderung, daß es keine 'Key Recovery' geben darf - nur der Sender und der Empfänger sollen den vereinbarten Schlüssel K kennen.

Bei Speicherverschlüsselung dagegen hat man vielfach weitergehende Anforderungen. Ein Arbeitgeber zum Beispiel wird auf den Laptops seiner Mitarbeiter nicht Festplattenverschlüsselung ausrollen können, wenn er nicht die Möglichkeit hat, auch ohne Kooperation des Mitarbeiters auf dessen dienstliche Daten zugreifen zu können. Ohne diese Möglichkeit besteht sonst die Gefahr, daß betriebskritische Daten für die Firma nicht mehr im Zugriff sind, wenn der Mitarbeiter erkrankt oder sonstwie nicht mehr verfügbar ist. Diese Situation ist für eine Firma klar nicht akzeptabel, daher müssen solche Systeme immer "Key Recovery" erlauben, also eine "Hintertür" haben, die - und das ist der entscheidende Punkt - unter der Kontrolle der Firma steht.

Speicherverschlüsselung ohne Key Recovery ist wertlos, und das entscheidende Merkmal bei der Diskussion über Key Recovery ist nicht, daß sie existiert, sondern wer die Kontrolle über die Recovery Keys hat.

Auguste Kerckhoffs hat 1883 das Kerckhoffsche Prinzip formuliert. Kerckhoffs war ein früher Kryptograph, und hat kryptographische Verfahren untersucht und eine Reihe von Anforderungen an Kryptosysteme formuliert.

In einer modernen Formulierung besagt das Kerckhoffsche Prinzip, daß die Sicherheit eines Kryptosystems nicht von der Geheimhaltung des verwendeten Algorithmus abhängen darf, sondern nur von der Geheimhaltung der verwendeten Schlüssel abhängen darf.

In einer schärferen Formulierung kann man sogar sagen, daß ein Kryptosystem, dessen Algorithmen nicht allgemein bekannt und durch viele anerkannte Kryptographen untersucht und bestätigt worden sind wahrscheinlich unsicher ist und nicht verwendet werden sollte.

Wir können nach dem heutigen Stand der Mathematik nicht beweisen, daß ein Algorithmus unangreifbar ist. Wir können lediglich unsere hellsten Köpfe auf einen Algorithmus loslassen. Wenn die dann alle scheitern (und was das bedeutet klären wir gleich), dann ist der Algorithmus wahrscheinlich zur Zeit sicher.

Es gibt in der Geschichte der Kryptographie eine ganze Menge Beispiele für recht prominent selbstgekochte Kryptosysteme, bei denen die Algorithmen nicht ausreichend untersucht worden sind und die sich dann im Nachhinein nicht als sicher erwiesen haben.

Das CSS-System zur Verschlüsselung von DVD-Inhalten ist zum Beispiel ein solches System: Nicht nur ist seine Schlüssellänge mit 40 Bit sowieso zu kurz, sondern durch eine Analyse des Algorithmus, die bei der Erschaffung von CSS nicht ausreichend durchgeführt worden ist, ist es gelungen, die effektive Schlüssellänge dieser 40 Bit auf 16 Bit zu reduzieren. Damit ist aber ein Angriff auf CSS mit trivialer Rechenleistung möglich und CSS ist in etwa genau so sicher wie Klartext.

Ein anderes Beispiel ist der vom GSM-Konsortium selbstgekochte A5 Algorithmus, mit dem einige Mobilfunkbetreiber GSM-Kommunikation verschlüsselt haben, statt einen anerkannten Algorithmus zu nehmen. Auch die verschiedenen Varianten von A5 sind gebrochen worden und mit diesen (inzwischen nicht mehr verwendeten) Algorithmen verschlüsselte Kommunikation ist abhörbar geworden.

Jedes Verschlüsselungsverfahren läßt sich brechen, indem man einfach alle möglichen Schlüssel durchprobiert. Diesen Angriff nennt man einen 'brute force'-Angriff. Damit er gelingen kann, müssen zwei Dinge gelten:

Einmal muß man überhaupt mitbekommen, daß man fertig ist.

Bei einem Brute Force-Angriff entschlüsselt man eine verschlüsselte Nachricht (also unlesbaren Bitsalat) mit dem falschen Schlüsselt (bekommt also anderen unlesbaren Bitsalat). Erwischt man zufällig den korrekten Schlüssel, bekommt man lesbaren Text - und muß diese Situation erkennen. Das heißt, es hilft, wenn man ein wenig über den Klartext weiß ('es handet sich um englischen Text', 'am Ende des Textes ist eine CRC32 Prüfsumme über alle vorhergehenden Bytes und wenn die Prüfsumme aufgeht, ist die Nachricht korrekt').

Hat man solches Wissen nicht, muß man raten - etwa wenn die Nachricht nur gültige Zeichen in dem und dem Zeichensatz enthält und die relativen häufigkeiten der Buchstaben in etwa dem Muster englischer Sprache entsprechen, dann ist die Nachricht möglicherweise korrekt entschlüsselt worden und man legt sie einem Operator zur Kontrolle vor.

Im zweiten[…]

Da es in letzter Zeit vermehrt zu Sicherheitslücken beim größten Sozialen Netzwerk Facebook kam, haben viele User Angst um Ihre persönlichen Daten bekommen. Unabhängig von den Sicherheitslücken haben sie aber auch einfach nicht die Lust oder die Netz-Affinität, um sich durch das Privatsphären-Gewirr von Facebook zu kämpfen. Ein neues Open Source-Tool soll Abhilfe leisten.

Das Tool namens “ReclaimPrivacy.org” ist frei erhältlich und soll die Sicherheitslücken der Facebook-Einstellungen innerhalb weniger Minuten prüfen. In Form eines Bookmarklets, welches man in seine Lesezeichenliste zieht und bei Bedarf einfach anklickt, scannt das Open Source-Tool dann das Facebook-Profil und gibt ein Feedback zu den eigenen Einstellungen. Dem User wird eine Einstufung in “sicher” und “unsicher” ausgegeben und er bekommt bei einer unsicheren Klassifizierung auch eine Hilfe an die Hand, die etwaige Änderungen vorschlägt. Klingt doch einfach fantastisch oder? Einen kleinen Haken hat das Tool allerdings. Da der Service gerade erst gestartet ist, funktioniert es noch nicht in allen Browsern gleich gut – Updates werden also sicherlich folgen!

Geschrieben wurde das Programm von Matt Pizzimenti, dem Co-Gründer des Start-Ups Olark. Einige Familienmitglieder Pizzimentis klagten ständig über die undurchsichtigen Optionen ihrer Privatsphäre-Einstellungen auf Facebook und das nahm der Programmierer zum Anlass, dieses wertvolle Tool zu schreiben. In einem Interview mit Forbes sagte er: “The way that Facebook operates, you have to be vigilant about your privacy settings. In a sense it’s their product and they have the right to change the settings, but I think they are doing a very poor job of communicating to users and doing right by them”. Kurzum übersetzt heißt das soviel wie, “…die Kommunikation von Facebook an deren User schleift gewaltig” – eine Meinung die auch den deutschen Facebook-Nutzern geradezu aus der Seele spricht. Und somit wurde das Tool auch innerhalb weniger Tage bis zu 13.000 mal geteilt!

Der Erfolg gibt Mark Pizzimenti Recht. Er arbeitet weiter an dem Open Source Projekt und baut die Funktionalität auch auf Fotos und Pinnwand-Einträge aus.

Das Tool und eine Bedienungsanleitung findet Ihr hier!

Da es in letzter Zeit vermehrt zu Sicherheitslücken beim größten Sozialen Netzwerk Facebook kam, haben viele User Angst um Ihre persönlichen Daten bekommen. Unabhängig von den Sicherheitslücken haben sie aber auch einfach nicht die Lust oder die Netz-Affinität, um sich durch das Privatsphären-Gewirr von Facebook zu kämpfen. Ein neues Open Source-Tool soll Abhilfe leisten.

Das Tool namens “ReclaimPrivacy.org” ist frei erhältlich und soll die Sicherheitslücken der Facebook-Einstellungen innerhalb weniger Minuten prüfen. In Form eines Bookmarklets, welches man in seine Lesezeichenliste zieht und bei Bedarf einfach anklickt, scannt das Open Source-Tool dann das Facebook-Profil und gibt ein Feedback zu den eigenen Einstellungen. Dem User wird eine Einstufung in “sicher” und “unsicher” ausgegeben und er bekommt bei einer unsicheren Klassifizierung auch eine Hilfe an die Hand, die etwaige Änderungen vorschlägt. Klingt doch einfach fantastisch oder? Einen kleinen Haken hat das Tool allerdings. Da der Service gerade erst gestartet ist, funktioniert es noch nicht in allen Browsern gleich gut – Updates werden also sicherlich folgen!

Geschrieben wurde das Programm von Matt Pizzimenti, dem Co-Gründer des Start-Ups Olark. Einige Familienmitglieder Pizzimentis klagten ständig über die undurchsichtigen Optionen ihrer Privatsphäre-Einstellungen auf Facebook und das nahm der Programmierer zum Anlass, dieses wertvolle Tool zu schreiben. In einem Interview mit Forbes sagte er: “The way that Facebook operates, you have to be vigilant about your privacy settings. In a sense it’s their product and they have the right to change the settings, but I think they are doing a very poor job of communicating to users and doing right by them”. Kurzum übersetzt heißt das soviel wie, “…die Kommunikation von Facebook an deren User schleift gewaltig” – eine Meinung die auch den deutschen Facebook-Nutzern geradezu aus der Seele spricht. Und somit wurde das Tool auch innerhalb weniger Tage bis zu 13.000 mal geteilt!

Der Erfolg gibt Mark Pizzimenti Recht. Er arbeitet weiter an dem Open Source Projekt und baut die Funktionalität auch auf Fotos und Pinnwand-Einträge aus.

Das Tool und eine Bedienungsanleitung findet Ihr hier!

Der Hauptbericht "Botnets: Detection, Measurement, Disinfection & Defence" (dt.: Botnetze: Erfassung, Messung, Desinfektion und Abwehr) gibt einen umfassenden Überblick und eine weitreichende Analyse existierender Ansätze zur Messung und Detektion, als auch Bekämpfung oder Abwehr von Botnetzen. Zusätzlich werden Empfehlungen und bewährte Praktiken vorgestellt, um Botnetze auf verschiedenen Ebenen angreifen zu können.

Sicherheit im Internet (Materialien und Spots)