Eher durch Zufall sind wir darüber gestolpert, dass das bei den Mac-Usern in unserem Team sehr geschätzte Tool homebrew nun auch einen Linux-Port hat. Wer Homebrew also bereits auf seinem Mac einsetzt, muss sich nun nicht noch zusätzlich mit toast befassen, um Software zu installieren, die bei uns nicht out of the box oder in einer benötigten Version installiert ist.

In dem Zuge haben wir uns dann gedacht, dass es ja kaum schaden kann, das gleich mal bei uns im Wiki zu dokumentieren. Es sei aber noch darauf hingewiesen, dass wir Homebrew noch nicht als offizielles Uberspace-Feature betrachten und es daher noch nicht auf unseren Hosts bereitstellen. Die Installation gestaltet sich aber als recht einfach.

Wenn Lücken wie POODLE bekannt werden, herrscht bei uns schon fast soetwas wie Routine. Diejenigen von uns die sich um solche Dinge kümmern verabschieden sich von allen Plänen für den Nachmittag, den Abend, die Nacht, machen im Browser Tabs mit den üblichen IT-News-Seiten, den Homepages der von uns verwendeten Softwares und (zur zwischenzeitlichen Entspannung) mit Katzen- oder Hundecontent auf und dann heißt es Warten auf Details und Softwareupdates. Bei POODLE wurde schnell klar, dass es diesmal weniger um Updates geht, als vielmehr darum SSL 3.0 endlich abzuschalten. Das sollte bei einem 18 Jahre alten Protokoll, das bereits drei Nachfolger hat eigentlich überhaupt kein Problem sein. (Um ganz ehrlich zu sein: eigentlich ist es eine Schande, dass SSL 3.0 und TLS 1.0 nicht schon seit Jahren überall abgeschaltet werden können.) Gerade nach der BEAST-Lücke in TLS 1.0 haben viele Browser auch mit 10jähriger Verzögerung endlich angefangen neuere Standards wie TLS 1.1 oder 1.2 zu implementieren, da sollte doch einer Abschaltung von SSL 3.0 wirklich nichts mehr im Wege stehen. Oder?

Speziell an diesem Wochenende beobachten wir eine ungewöhnliche Häufung von Listings einiger unserer Hosts auf http://cbl.abuseat.org/. Die CBL ist keine Blacklist von Hosts, die wegen Spamming auffällig wären, sondern weil sie Malware hosten. Dass so etwas sporadisch mal passiert, bleibt nie ganz aus, aber die Häufung war schon sehr ungewöhnlich.

Speziell bei Shared Hosting ist das ein ziemliches Problem, denn wenn sich auf einem Host erstmal zig WordPress-, Joomla!- oder Drupal-Versionen befinden, die dutzendfach mit Themes und Plugins ausgestattet werden, ist es schon unwahrscheinlich genug, dass sich alle User ihrer Verantwortung bewusst sind, diese Systeme (die sie sich ja selbst installieren) auch aktuell zu halten, um jene möglichst frei von Einbrüchen zu halten.

Infos, wie die Versionen für den eigenen Account aktiviert werden können, finden sich im Wiki.

Die 5.3er-Serie ist mit 5.3.29 nebenbei offiziell end of life; wer die noch einsetzt, sollte sich schleunigst mal auf die Todo-Liste setzen, auf eine neuere Version zu migrieren. Auf neuen Hosts werden wir aller Voraussicht nach nur noch Versionen ab 5.4 aufwärts bereitstellen.

Wir experimentieren neuerdings mit fail2ban, um Bruteforce-Angriffe auf bestimmte Dienste abzufangen. Das Programm durchsucht Logs nach einem vorgegebenen Schema und kann, wenn dieses Schema mehr als x mal in Zeitraum y gefunden wurde, Aktionen durchführen, wie beispielsweise die IP-Adresse blockieren. Die Konfiguration ist auf allen unseren Hosts die gleiche, hier mal am Beispiel von crater:

[root@crater ~]# fail2ban-client status
Status
|- Number of jail:	6
`- Jail list:		apache-joomla-login, apache-wp-login, apache-auth, apache-friendica-load-prevention, ssh-iptables, wp-spam

Unsere Regeln

Das Prinzip ist immer das selbe. Da der Filter für die Wordpress-Loginmaske am meisten anschlägt, hier mal die dahinter liegende Konfiguration:

Ein frisches node.js ist auf allen Servern verteilt, weitere Informationen dazu wie gewohnt im Wiki

Die Symlinks unter /package/host/localhost sind angepasst:

nodejs -> nodejs-0
nodejs-0 -> nodejs-0.10
nodejs-0.10 -> nodejs-0.10.33

Wenn ihr also einen von den obigen Pfaden in eueren Scripten benutzt, reicht es, den Dienst einfach neu zu starten.

Schon den ganzen Tag gerüchtete es, dass im Laufe des 15. Oktober nach Heartbleed und Shellshock eine weitere Sicherheitslücke mit großem, Internet-weiten Ausmaß angekündigt wird. Inzwischen sind die Details dazu publik.

Wie bei vergangenen SSL-/TLS-bezogenen Angriffen (CRIME, BEAST, etc) hat dieser Angriffsvektor mit POODLE (Padding Oracle On Downgraded Legacy

Encryption) von Google ein durchaus aussprechbares und einprägsames Akronym als Namen erhalten - auch wenn POODLE sowohl ohne dedizierte Webseite als auch ohne ein dramatisches Logo auskommen musste.

Wir haben heute auf allen Host das python-3.4.1 verteilt. Weitere Informationen findet Ihr in unserem Wiki