Redio Blog

Google hat sich in letzter Zeit an Programmiersprachen nicht gerade mit Ruhm aus der Entwicklerszene bekleckert. So war das Web Toolkit in Java vielen zu langsam, Simple zu schwer und PHP wollte keiner.

Das heißt: Es musste wieder mal eine Sprache her, aber dieses mal besser eine Offline-Sprache. Und da ist sie: Sie hört auf den einfachen Namen “Go”, was für Spaß und Produktivität steht. Dabei wirbt Google selbst mit der Sicherheit einer C/C++-Kompilierten, der Dynamik und Offenheit von Python und der Kompatibilität, es auf jeden Webserver einsetzen zu können. Große Versprechungen vom großen Riesen also.

Dabei ist das Konzept ganz einfach: Man nimmt sich C, verbindet es mit C++, haut den Garbage Collector dazu und etwas von Python und fertig ist Go. Daneben kann man Import-Funktionen von C nutzen, hat aber auch gewisse Freiheiten, wie die Datentypen int, float oder struct. Der Umstieg von C++ sollte also Go-Programmierern kein großes Problem darstellen.

Und auch völlige Neuanfänger können sich einlesen, indem sie das mitgelieferte Tutorial durchgehen und die Häufigen Fragen (beides noch in Englisch) lesen. Dazu haben die Entwickler der Programmiersprache außerdem noch ein hübsches Video produziert:

[YouTube Direkt-Go]

Was meint ihr dazu? Ist Go für euch vielversprechend oder sagt es euch nicht zu? Kann es Konkurrenz machen?

Kennt ihr sicherlich, oder? Der Tag ist immer der selbe: Nach Hause kommen, essen, vor den PC setzen und erstmal Facebook, Twitter, Studi-Wasweiß-ichnochalles-Waviges öffnen, um Up-To-Date zu sein. Dann mal hier ein bisschen und da ein Kommentar. Ganz normal. Ihr surft im Web, programmiert noch hier rum, da rum und dann guckt ihr auf die Uhr und sagt “oh, es ist ja schon…. spät”. Twitter ist wie ausgefegt, nur noch die Bots unterhalten sich mit euch, und dann wisst ihr, dass es Zeit wird, den PC auszuschalten. Und mit dieser Geschichte entlasse ich euch in eine hoffentlich entspannte Offline-Nacht.

Ich muss gerade unglaubliches lesen, als ich in meinem Reader auf Netzpolitik klickte. “Datenleck bei SchülerVZ”. Man kann sich schon vorstellen, dass es nicht der erste Fall solcher Art ist und vieles unter den Tisch gekehrt wird.

Konkret geht es darum, dass mehr als eine Millionen Datensätze (Name, Alter, Wohnort, Interessen, Geschlecht, Profilbild usw.) gephist wurden. Durch Löcher im SchülerVZ-CMS. Dass SchülerVZ nicht aus vergangenen Pannen, wie bei StudiVZ oder MeinVZ, gelernt hat, ist wirklich bedauerlich.

Zurück zum Artikel von netzpolitik.org. Markus hat in der Verbraucherzentrale um Rat gefragt und ein Interview erhalten:

Die Betreiber sozialer Netzwerke sind in der Pflicht, Daten ihrer Mitglieder gegen unbefugten Zugriff zu schützen. Das aktuelle Beispiel zeigt, dass Benutzer sich nicht in Sicherheit wiegen lassen sollten: Netzwerke sind ein Teil des Internets und nicht von ihm getrennt. [...]

Kurz nach der Veröffentlichung auf netzpolitik.org hatte sich SchülerVZ selbst zu Wort gemeldet und lässt verlauten, dass man “die Datenschutzbehörden umgehend informiert und [...] rechtliche Schritte gegen Unbekannt einleiten” wird.

Übrigens stammen die Löcher von so genannten “Cross Site Request Forgery”, kurz XSRF, eine Unterart der XSS, der Cross Site Scripting-Attacken, wie sie auch mal bei Redio vorkamen. Mit diesen Lücken, so Insiderinformationen, ließen sich auch Accounts übernehmen und andere tolle Dinge tun, wie Accounts löschen oder Inhalte hochladen. Desweiteren soll eine kleine Lücke darin bestehen, dass Bilder nicht vom Server gelöscht werden, sondern nur der Link zum Bild. SchülerVZ streitet dies aber ab.

Mittlerweile soll sich die unbekannten Eindringlinge schon bei SchülerVZ gemeldet haben, um die Lücke zu beheben. Von eine Anzeige möchte SchülerVZ bei voller Kooperation absehen.

Aus aktuellem Anlass ein Überblick über das, was hier bei Redio an (personenbezogenen) Daten anfällt.

Der Webserver führt ausschließlich ein Logbuch für Fehler, es werden also nicht alle Zugriffe protokolliert, sondern nur solche, die einen Status ungleich 200 zurücklieferten. Eine typische Zeile sieht so aus und enthält die Zeit, IP-Adresse, Datei, Referer und, je nach Fehlertyp, noch andere Informationen:
[Fri Oct 16 22:29:38 2009] [error] [client *] File does not exist: /home/www-data/htdocs/e/example/www/example.php, referer: http://www.example.com
Speicherdauer: 14 Tage.

Auch jeder Versand von Mails wird protokolliert. Gespeichert werden hier Skriptpfad plus Zeile des mail()-Aufrufs und alle E-Mail-Header:
mail() on [/home/www-data/htdocs/e/example/www/emailer.php:212]: To: ...
Speicherdauer: 14 Tage.

Der FTP-Server (das betrifft die wenigsten) speichert alle Verbindungsversuche und alle Aktionen mit Zeit, IP-Adresse und Benutzername:
Thu Oct 15 17:20:21 2009 [pid *] CONNECT: Client "*"
Thu Oct 15 17:20:23 2009 [pid *] [anonymous] FAIL LOGIN: Client "*"
Speicherdauer: 30 Tage.

Das HVS protokolliert diverse “wichtige” Aktionen wie zum Beispiel “Account erstellt”, “Account gelöscht”, “Neues Passwort angefordert”, diverse von Administratoren ausführbare Aktionen, sowie Meldungen von Verwaltungsskripten. Was genau gespeichert wird hängt recht stark vom Meldungstyp ab (Benutzername/-ID, E-Mail-Adresse, Datum des letzten Login, “Onetime-ID”, …), Zeit und Benutzername (falls angemeldet) werden aber immer gespeichert, nicht jedoch die IP-Adresse.
Speicherdauer: Zurzeit unbegrenzt. Es ist aber geplant die Daten nach etwas mehr als einem Monat zu löschen.

Außerdem wird nachts ein Backup der Redio-Datenbank (nicht der Benutzerdatenbanken!) erstellt. Darin befinden sich natürlich alle Daten, die das HVS erhebt (Nutzerdaten wie E-Mail-Adresse und Accountname, aber auch Domains und Datenbanknamen/-passwörter).
Speicherdauer: 14 Tage.

… ist auf Redio gut, aber nicht überall.

Wenn mehrere Seitenbetreiber das selbe Verzeichnis benutzen, in dem sie Sessions speichern wird es problematisch. Zumindest wenn jeder auch noch Leserechte in dem Verzeichnis hat oder zumindest die Dateien auflisten darf.

Denn die heißen meistens sess_$sid  und wenn man $sid hat, hat man die Session, kann sie auslesen, verändern usw …

YouTube Direktbrowser

Nach dem kleinen Schock von gestern habe ich nochmal ein wenig genauer nachgesehen:

Es gibt im Moment 1980+2347 = 4327 Benutzer (jeweils lexu + azure). 522+430 = 952 (22,0%) davon haben 0(!) Bytes auf ihrem Webspace (der Webspace ist also leer). 567+499 = 1066 (24,6%) sind mit < 1KB dabei, 568+890 = 1458 (33,6%) haben weniger als 1 MB, 1382+1572 = 2954 (68,2%) weniger als 10 MB und 1947+2300 = 4247 (98,1%) weniger als 100 MB auf ihrem Webspace gepeichert. Datenbanken sind hier aber nicht eingerechnet.

Das heißt im Klartext: Jeder vierte im Moment existierende Account ist “unbenutzt”, wenn man unbenutzt als “weniger als 1 KB belegt” definiert.

…wäre ich fast vom Stuhl gefallen. Der Grund:

400(!) Nutzer weniger. Das ist an sich kein Fehler, denn es waren alles Nutzer, die sich — selbst nach Aufforderung per E-Mail — vor mehr als 6 Monaten eingeloggt hatten und damit als “inaktiv” markiert wurden. Aber ein bisschen viel ist es schon…

Der Umbau ist komplett. Beide Server, azure gestern und lexu heute morgen, sind auf ein leicht modifiziertes mod_fcgid umgestellt worden. Modifiziert in der Hinsicht, dass die PHP-Authentifizierung wieder funktioniert und dass nicht für jeden vHost neue Worker gespawnt werden. Alles natürlich in der Hoffnung, dass die Umstellung die Probleme der Vergangenheit löst — so ganz sicher ist man sich da vorher aber nie…

Seit einiger Zeit beobachte ich dieses Phänomen nun schon: Plötzlich — wie aus dem Nichts — werden von FastCGI/PHP keine Anfragen mehr bearbeitet. Es gibt nur noch einen Timeout und den damit verbundenen “Internen Serverfehler”. So auch heute wieder zwischen 12:20 und 13:00 Uhr.

Typische Log-Einträge sind dann:

[error] FastCGI: comm with (dynamic) server "/usr/local/fcgi-bin/fcgi-php-user" aborted: (first read) idle timeout (30 sec)
[error] FastCGI: incomplete headers (0 bytes) received from server "/usr/local/fcgi-bin/fcgi-php-user"

oder auch

[error] (4)Interrupted system call: FastCGI: comm with server "/usr/local/fcgi-bin/fcgi-php-user" aborted: select() failed
[error] FastCGI: incomplete headers (0 bytes) received from server "/usr/local/fcgi-bin/fcgi-php-user"

Letztere Meldung lässt sich angeblich durch ein Update von mod_fastcgi beheben. Das wird wohl auch für Redio mal fällig.

Update: Ich sehe gerade, dass die Apache Foundation die Rechte an mod_fcgid übernommen hat und das Modul aktiv weiterentwickelt. Das wäre sicherlich die bessere Alternative, als weiterhin auf mod_fastcgi zu setzen, das schon mehr als eine Jahr kein Update mehr erfahren hat.