ius in Cyber-bello

Cyberangriffe auf kritische Infrastrukturen

In der ARD Dokumentation “Die Story im Ersten – Schlachtfeld Internet” (Sendetermin: 12.01.2015 – 23:30 Uhr) wird durch die Autoren die Aussage getroffen, dass die USA auch die Systeme von zivilen Einrichtungen wie Transportwesen, Energieversorgung und auch Krankehäuser und Universitäten angreifen möchten. Dies geht unter anderem aus dem sogenannten Black Budget, dem Budget der US Geheimdienste hervor und wird durch die folgende Aussage Edwards Snowdens unterstützt:

Continue reading

Quick’n’Dirty Part 2: Poodle Check for Nagios

Again a quick’n’ dirty hack, to check your systems via nagios for enabled SSLv2 or SSLv3 which is both not secure.
Note: You need a recent openssl Version which supports up to TLS 1.2

 

Quick’n’Dirty: Check if your Server supports SSLv3

SSLv3 is known as broken (Poodle – CVE-2014-3566) since last night and should be disabled on all servers. The following bash script is a quick’n’ dirty hack to check which protocols a server support:

Note: You need a recent openssl Version which supports TLS up to Version 1.2

 

SSH, Google Authenticator and Keyfiles

logo

Die Zwei-Faktor-Authentifizierung kennen wir alle schon Lange z.B. von Geldautomaten, wo man sich mit Bankkarte und PIN Authentifizieren muss um auf sein Konto zuzugreifen. Auch für IT Systeme gibt es die Möglichkeit der Zwei-Faktor-Authentifizierung bereits sehr Lange, jedoch entfällt mit der Verbreitung von Smartphones und den passenden Apps ein entscheidender Nachteil den man bisher hatte. Bisher musste man sich z.B. einen sog. RSA-Token anschaffen und hoffen, dass der Nutzer diesen immer mitführt. Heutzutage haben die meisten Leute ihr Mobiltelefon immer dabei und bemerken auch ein Verlieren oder Entwenden des selbigen sehr schnell.

Daher bietet es sich meiner Meinung nach geradezu an, das Smartphone in Verbindung z.B. mit der Google Authenticator App für die 2-Faktor-Authentifizierung via SSH zu nutzen. In Verbindung mit einem Nutzer mit Kennwort ist dies ohne weitere Probleme bereits möglich, jedoch möchte ich hier die Authentifizierung mit einem Keyfile betrachten, bei der eine Zwei-Faktor-Authentifizierung erst mit aktuelleren OpenSSH Versionen möglich ist. (Ja mir ist bewusst, dass ein Keyfile mit einem Passwort eigentlich schon eine Zwei-Faktor-Authentifizierung darstellt / Keyfile = etwas das ich besitze, Passwort = etwas das ich weiß).

Voraussetzung für die Funktion des im folgenden Beschriebenen ist eine OpenSSH Version größer oder gleich 6.2 und damit sind alle Debian Varianten bis einschliesslich Wheezy nicht geeignet. Erst mit dem Wheezy Backports Repository ist OpenSSH in der Version 6.6 enthalten und damit für diese Zwecke tauglich. Eine Anleitung zur Nutzung des Wheezy-Backports Repository findet sich auf den Seiten von Debian.

Nachdem das Repository eingebunden wurde, muss OpenSSH aus dem Repository installiert werden. Dies geht am einfachsten mit dem folgenden Befehl:

Des weiteren müssen für das Google Authenticator Modul noch die Development Header der PAM Library installiert werden. Auch hier hilft wieder das Paketverwaltungssystem:

Für den Google Authenticator gibt es bereits ein fertiges PAM Modul, welches die komplette Arbeit übernimmt und durch uns nur noch gebaut und eingebunden werden muss. Hierzu muss man es als Erstes aus den Repositories von Google herunterladen und dann bauen

Danach sind bereits alle Dateien am korrekten Ort und müssen von uns nur noch aktiviert werden. Dies muss in mehreren Schritten geschehen, als erstes definieren wir jedoch noch eine Ausnahme. Nutzer die sich automatisiert anmelden, z.B. um Wartungsaufgaben zu erfüllen oder Backups durchzuführen können im Regelfall keine Zwei-Faktor-Authentifizierung nutzen, da keine Menschen sondern nur Maschinen diese Accounts benutzen. Für diese müssen wir daher eine Ausnahmeregelung schaffen, da ansonsten der automatische Login fehlschlägt. Ich nutze hierzu eine Gruppe, in welcher die Benutzer angesammelt werden, welche keine Zwei-Faktor-Authentifizierung nutzen sollen. Diese Gruppe wird hier entsprechend angelegt.

Nachdem nun alle Vorbereitungen getroffen sind, muss noch der SSH Server wie auch PAM entsprechend konfiguriert werden. Hierzu muss als erstes in der Datei /etc/ssh/sshd_config die Challenge Response Authentication aktiviert und danach noch die Authentication Methods festgelegt werden. Dazu die beiden folgenden Zeilen in der Datei anpassen bzw. sie hinzufügen.

Nun muss noch eine passende Konfiguration für PAM erzeugt werden, damit über dieses der Google Authenticator aktiviert werden kann. Ich habe weiter unten meine komplette PAM Konfiguration für SSH beigefügt. Ausschlaggebend sind jedoch die folgenden Zeilen, welche als erstes die Zugehörigkeit zur Gruppe otp_free prüfen und dann den Google Authenticator starten – sofern der Nutzer KEIN Mitglied der Gruppe ist.

Für jeden einzelnen Nutzer muss jetzt noch der Befehl google-authenticator ausgeführt werden. Hierduch wird zum einen ein Secret generiert und zum anderen sogenannte “emergency scratch codes”. Hierbei handelt es sich um einmal Codes, die für den Notfall-Login sind, wenn man z.B. sein Smartphone verloren hat. Diese sollten daher an einem sicheren Ort verwahrt werden, damit man im Notfall darauf zurückgreifen kann.

Das Programm google-authenticator liefert auch eine URL mit, durch die via Google ein QR Code generiert werden kann. Diesen kann man dann direkt in der Google Authenticator App einscannen und muss nicht den Secret Key eingeben. Selbstverständlich mit dem Nachteil, dass die Daten erstmal an Google gesendet werden.

Nachdem nun der OpenSSH Server neugestartet wurde, sollte der Benutzer bei seinem nächsten Login nach dem “Verification Code” gefragt werden und erst Zugang erhalten, wenn der Verification Code stimmt.

UPDATE: Wenn ihr dem Tool “google-authenticator” die Option –qr-mode=ansi mitgebt, dann wird euch auf der Konsole ein entsprechender QR Code generiert, den ihr dann direkt mit dem Handy einscannen könnt. (Danke tbr)

/etc/pam.d/ssh Beispiel:

Der Spiegel, die Telekom, NetCologne, Stellar und die NSA

Im Spiegel Nummer 38 vom 15.09.2014 beschäftigen sich Andy Müller-Maguhn, Laura Poitras, Marcel Rosenbach und Michael Sontheimer auf den Seiten 78 bis 80 mit aktuellen Erkentnissen aus den Dokumenten von Edward Snowden. Basierend auf diesen aktuellen Erkentnissen sind unter anderem die Netze von NetCologne, der Deutschen Telekom AG und mehreren Betreibern von “Internet-via-Satelitt”-Platformen durch die NSA kompromittiert.

Continue reading

URL shortener now live

A few weeks ago i wrote a URL shortener for one of our customers. Now i’ve written a wordpress plugin for this service and the service is live now. It currently receives many new url’s per second and already has more than 500.000 shortened URLs in the backend, but it is still incredibly fast.

Job done, customer happy and perhaps they will release the small wordpress plugin into public and use it not only for their blog network :-)