In den letzten Tagen, schon eher Wochen war es hier recht still. Der Grund ist die Last des Servers gewesen. Da ein Bekannter von mir einen schlecht programmierten Chat benutzt war die Last auf der Datenbank und dem Webserver teilweise sehr hoch. Dadurch konnten ein paar Seiten nicht mehr ausgeliefert werden. Damit meine Seiten erreichbar bleiben habe ich einfach schnell alle hinter einen Loadbalancer gepackt, der diese Seite z.B. auf drei Webserver verteilt. Die Datenbank wurde auf eine zweite MySQL geschoben und alle Webserver benutzen jetzt für diese Seite die neue Datenbank über eine VPN Verbindung.
Das geht aktuell noch sehr gut, sollten die Besucherzahlen weiter so steigen wird auch hier die nächste Lösung zum Einsatz kommen. Diese wird aber aktuell noch getestet, damit nachher nichts schief läuft.
Das nächste Problem war dann mit der Verteilung auf die verschiedenen Server die Uploads beim Wordpress und anderen. Diese werden nur auf dem Server abgelegt, auf dem ein Upload ausgeführt wurde. So sind diese Dateien auf den anderen Servern nicht vorhanden. Dazu wird jetzt regelmässig zwischen den einzelnen Servern synchronisiert. Das übernimmt Unison, da es sehr gut mit SSH funktioniert.
Bei einem anderen Thema wird aktuell an Lastverteilten Front-, Backends und Proxys gebastelt. Der Grund ist Google Analytics, GetClicky usw. die Trackingdaten auf Ihren Servern speichern. Jetzt wird das alle komplett selbst gemacht. Alle Daten werden bei mir gespeichert, nichts mehr an andere Anbieter übertragen. Denn es könnte immer mal sein, das Daten an dritte weitergegeben werden, ein Anbieter stellt seinen Dienst ein oder der Dienst wird kostenpflichtig. Wenn auch nur zum Teil kostenpflichtig, fehlen dann vielleicht dann im kostenlosen Teil die Daten die am wichtigsten sind.
Weitere Argumente gegen einen externen Dienstleister sind Ausfälle bei diesem. Als beim letzten mal Google ausgefallen ist (DNS/Domainklau) waren alle Seiten, die Google Analytics einsetzen nicht mehr erreichbar oder sehr eingeschränkt nutzbar. Es kam immer zu Timeouts beim einbinden des Google Codes und Seiten wurde nur halb oder sogar überhaupt nicht mehr angezeigt. Schlimmer als ein Ausfall ist aber ein erfolgreicher Hack der Google Server. Sollte das einmal passieren könnten Angreifer die Hälfte aller Internetseiten weltweit umleiten auf eigene Seiten.
Damit die eigenen Statistiksoftware stabil und zuverlässig erreichbar ist, ist sie auch hinter einem Loadbalancer, die jeweiligen Frontends sind aber so abgespeckt, das sie nicht mehr viel, bis auf eine Funktion Scriptseitig ausführen können. Sie rufen die angeforderten Inhalte auf den Backends ab, die jeweils wieder nur einen Teil der Aufgaben übernehmen. Ein paar können PHP, die anderen wiederum können z.B. nur Perl. Das ganze setzt sich somit wie folgt zusammen.
2 Loadbalancer
Je Loadblancer 4 Frontends
Je Frontend 4 PHP und 4 Perl Backends
Die Frontends haben nur die Funktion die Anfragen für die Backends so verarbeiten damit diese mit den richtigen Parametern gefüttert werden. Sollte jetzt jemand z.B. versuchen und auch noch Erfolg haben PHP- oder Perlscripte dazu zu benutzen um externen Code auf dem Webserver abzulegen ist es zwar toll für den Angreifer. Problem ist nur das er im weiteren Verlauf überhaupt nicht auf sein zuvor abgelegtes Script zugreifen kann. Es wurde, wenn es jemand überhaupt schaffen sollte, auf einem der Backends ausgeführt. Diese sind aber überhaupt nicht vom Internet aus erreichbar. Auch nicht über angehängte Parameter könnte man den Frontendserver dazu zubewegen diese weiter durch zureichen. Dazu kommt noch, der Angreifer weiss gar nicht das er auf dahinter liegende Server zugreift und schon gar nicht auf welchen er landet.
Was weiter oben schon angesprochen wurde ist hierbei kein Problem, wenn eine Anfrage sehr langsam oder gar nicht von einem Backend beantwortet werden kann. Bei den ersten Tests war es schon erstaunlich wie schnell die Seiten aufgebaut wurden, auch wenn die entsprechenden Backends komplett abgeschaltet waren. Der Rest der Seite wurde von den anderen geliefert und prompt vom Browser dargestellt.
Zusätzlich wird noch die MySQL-Datenbank in Zukunft mit primary und secondarys betrieben um die lesenden Zugriffe auf mehrere Server besser zuverteilen. Schreibend wird auf den primary zugegriffen, lesend über einen MySQL-Proxy auf allen, je nach dem wie die Last auf den einzelnen Datenbankservern aktuell ist.
Der aktuelle Traffic ist pro Stunde bei ca. 500 - 700 MB, kommt dabei dann dazu das z.B. das Chatsystem wieder einmal amok rennt, wurde es ab und zu einmal eng für die anderen Seiten auf dem Server. Durch die Veränderungen ist es egal, wenn etwas passiert. Sollte ein Server überhaupt nicht mehr erreichbar sein sind noch genug andere vorhanden um die Anfragen zu verarbeiten. Einer der Nebeneffekte ist auch, man kann einzelne Server aus der Verteilung nehmen und auf Testdomains benutzen um mit der Live Konfiguration testen zu können. Klappt alles mit diesem Server nimmt man noch mehr aus der Verteilung, macht die Änderungen auf diesen auch und tauscht die neu konfigurierten Server mit den aktuell genutzten aus. Man muss dann nur noch die restlichen Server umkonfigurieren und anschliessend wieder mit in die Verteilung nehmen. Die User merken nichts davon und es ist auch wesentlich weniger Stress. Man weiß das man in Ruhe auch einmal einen Fehler machen kann.
Dev0 (Thomas) benutzt in seinem Chat für die Goodies Websnapr um Screenshots zuerstellen. Seit gerade gibt es das auch hier für Links auf andere Seiten. So werden für Heise.de, Instant-thinking und was sonst noch verlinkt wird mit einem Screenshot als Vorschau angezeigt.
websnapr lets you capture screenshots of (almost) any web page. Allow your visitors to instantly visualize any web page before clicking. Increase site traffic, click-through rate and site stickiness.
Das passende Wordpress PlugIn gibt es bei andufo.com. Wie immer einfach in den Plugin Ordner kopieren und im Adminpanel aktivieren.
Das Original ist von Oliver Guhr und findet man hier, sehr amüsant und ist zwar teilweise sehr überspitzt aber trifft bei den einzelnen Punkten genau zu.
Was würde passieren wenn man ein Bauprojekt so angeht wie ein Softwareprojekt?
Das Projekt ist der Bau eines Einfamilienhauses mit zwei Stockwerken und Keller mit einer Grundfläche von 100 Quadratmetern. Als Baumaterial werden Ziegelsteine verwendet. Der Architekt kalkuliert wie folgt: Das letzte Bauvorhaben (eine Doppelgarage) hatte eine Grundfläche von 25 Quadratmetern. Verbraucht wurden 1000 Ziegel. Die Baukosten betrugen 10000 Mark, was einen Preis von zehn Mark pro Ziegel bedeutet. Das neue Haus hat die vierfache Grundfläche und die doppelte Höhe - dies bedeutet 8000 Ziegel oder 80000 Mark Baukosten.
Das Angebot von 80000 Mark erhält den Zuschlag, und der Bau beginnt. Da die Maurerkolonne ausgelastet sein will, wird beschlossen, immer nur ein Zimmer zu konstruieren und gleich anschließend zu bauen. Das hat den Vorteil, dass die Planungs- und die Ausführungsgruppe immer ausgelastet sind. Weiter wird beschlossen, mit den einfachsten Sachen anzufangen, um möglichst schnell in die Bauphase einsteigen zu können. Das Schlafzimmer scheint dafür am besten geeignet zu sein.
Zugriff per WebDav ist mit dem DAV Modul im Apache schnell eingerichtet. Der Zugriff ist auch leicht einzuschränken mit AuthUserFile und mit AuthGroupFile kann sogar einzelnen User Lesen und Schreiben erlaubt werden.
Apache Konfiguration:
Hier ist das DocumentRoot auf /path/to/webdav/data ausserhalb des Root gesetzt, welches für die Homepage benutzt wird. Es kann auch innerhalb des Verzeichnisses liegen in de auch die Homepage liegt. Will man aber nicht das irgendwelche ScriptKiddies oder Leute, die nichts im WebDav zusuchen haben, fern halten sollte man es einfach auf eine Subdomain legen. Es ist zwar alles mit Benutzername und Passwort geschützt, was der User nicht weiß macht ihn nicht heiss. Ist es gewünscht das sich das WebDav Daten Verzeichnis doch in der “normalen” WebRoot der Homepage befindet ist hier einfach ein Alias zu setzen und Directory anzupassen:
Alias /webdav/ /srv/www/html/wedav/
Directory /srv/www/html
Die Pfade zu dem AuthUserFile und AuthGroupFile sind dann auch anzupassen.
Hier die oben erwähnte Konfiguration ausserhalb des DocumentRoots der Internetseite:
<Directory /path/to/webdav/data>
DAV on
Options +Indexes
AllowOverride AuthConfig
AuthType Basic
AuthName “WebDAV Verzeichnis”
AuthUserFile /path/to/webdav/.htpasswd
AuthGroupFile “/path/to/webdav/.htgroups”
<LimitExcept OPTIONS>
Require valid-user
</LimitExcept>
<Limit COPY DELETE LOCK MKCOL MOVE POST PUT UNLOCK>
Require group rw
</Limit>
</Directory>
Die Gruppe “rw” bekommt dann die Rechte “COPY DELETE LOCK MKCOL MOVE POST PUT UNLOCK” über die Datei .htgroups. Alle Benutzer werden wie gewohnt in die .htaccess eingetragen. Die User, die per WebDav das Verzeichnis beschreiben dürfen kommen in die Datei .htgroups zu “rw: …” die restlichen User zum Eintrage “ro: …”. Die Datei ist wie folgt aufgebaut:
rw: admin1 admin2 user1 user2
ro: gast1 userA userB
Anschliessend noch ein Apache reload und man kann den Zugriff auf die WebDav-Freigabe testen.
Fehler beim Zugriff
Sollte der Zugriff im Browser oder über den Windowsexplorer/Apple Finder nicht klappen, könnten im Logfile des Apache Webserver folgende Einträge sein:
[Fri Aug 17 16:17:49 2007] [error] [client xxx.xxx.xxx.xxx] The locks could not be queried for verification against a possible “If:” header. [500, #0]
[Fri Aug 17 16:17:49 2007] [error] [client xxx.xxx.xxx.xxx] Could not open the lock database. [500, #400]
[Fri Aug 17 16:17:49 2007] [error] [client xxx.xxx.xxx.xxx] (21)Is a directory: Could not open property database. [500, #1]
Ursache ist, dass das Verzeichnis /var/lock/apache2 nur für root schreibbar war. Somit kann Apache, der als “www-data” arbeitet, das Lock für WebDAV nicht anlegen. Ein
Sollte dieser Fehler auftauchen, nachdem man den Apache2-Webserver neu starten will, muss man das Modul “dav” zusätzlich aktivieren: Der Fehler liegt in der Abhängigkeit, welche nicht richtig aufgelöst werden kann.
sudo a2enmod dav
Danach sollte der Webserver ohne Probleme starten.
Erkennen lassen sich die Spam-Injektionen an unterschiedlichen Merkmalen. Bei einer Ende März gestarteten Injektions-Welle landeten zusätzliche Spam-Seiten in einem neu angelegten Unterverzeichnis wp-content/1. Google gibt inzwischen über 40.000 Treffer für die verräterische Pfad-Angabe an; Ende März waren es noch knapp 4.000.
Eine weitere Welle, von der auch die Blogs von ZDnet.com betroffen gewesen sein sollen, macht sich im Seitenquellcode mit einer langen Link-Liste am Seitenbeginn bemerkbar, die mit der Satzanweisung <font style=’position: absolute;overflow: hidden;height: 0;width: 0′> vor dem Leser versteckt wird. Vereinzelt berichten Blogger auch davon, dass diverse Dateien ihrer geknackten Wordpress-Installationen einen zusätzlichen IFRAME enthalten, der auf eine externe Webseite verweist.
Die unbekannten Angreifer nutzen wahrscheinlich unter Anderem eine XMLRPC-Schwachstelle, die Wordpress 2.3.2 und die Vorgängerversionen betreffen. Vereinzelt berichten Wordpress-Admins, dass sich das Spam-Problem auch nach dem Upgrade auf eine nicht verwundbare, aktuelle Version wie 2.3.3 oder 2.5 fortsetzt, was jedoch auf eine Inkonsistenz beim Update der Wordpress-Datenbank zurückzuführen sei. Nach einem erzwungenen Datenbank-Update sei das Problem aber bei einem Betroffenen verschwunden.
Wer ein selbstinstalliertes Wordpress-Blog betreibt, sollte – sofern nicht bereits geschehen – umgehend auf eine aktuelle Version umsteigen und diese künftig aktuell halten. Ist es schon zu einer Spam-Injektion gekommen, ist ein Backup der Wordpress-Datenbank mit nachfolgender Neuinstallation ratsam. Anschließend sollte man im Admin-Backend noch die Nutzerliste nach Fake-Accounts durchsuchen und diese gegebenenfalls löschen.
Beim schreiben und verlinken ist mit schon das erste aufgefallen. Wenn ein Text markiert wird und im Editor auf den Button “verlinken” klickt, wird das voreingefügte http:// nicht beim reinkopieren mit CTRL+v nicht gelöscht. Ist eine Kleinigkeit, die man mit einem kurzem Schift+Apple+Linkspfeiltaste gefolgt von einem Backspace beheben kann oder bei gelegenheit wird das einfach mal gefixed.
Ansonten war das Update problemlos.
Das aktuelle Wordpress ist immer mit der Version angelegt. Die aktuelle Version war 2.3 im Ordner wp23 und gelinkt worden, so das /wp/ auf wp23 zeigte. Die neue Version im latest.tar.gz wird entpackt nach /wordpress/. Daher wird folgendes gemacht: Datenbank sichern, Verzeichnis sichern, Verzeichnis nach /wordpress/ kopieren, Update in diese Verzeichnis eingespielt, umbenannt nach wp25, Link gelöscht und neuen Link auf die neue Version angelegt. Dann nur noch das Adminpanel aufrufen und Datenbankupdate machen lassen und aufräumen.
mysqldump -B <WP-DB> -u <USER> -p > wp23.sql
tar czf wp23.tar.gz wp23
cp -R wp wordpress
tar xzf latest.tar.gz; mv wordpress wp25
rm wp
ln -s wp25 wp
mv wp23.sql wp23.tar.gz ../backups
Das war es dann auch mit dem Update auf eine neue Version. Die ganzen Platzhalter wie WP-DP, USER und die Versionnummern kann man auch so leicht in ein Script schreiben welches dann ein update schnell automatisch erledigt. Da die alte Versionen jederzeit noch vorhanden sind muss bei grösseren Problemen einfach nur die Datenbank eingespielt werden, der Link geändert werden und schon kann man erst einmal die alte Version weiter benutzen und hat erst einmal Zeit sich im Internet zu informieren wieso ein Upgrade nicht geklappt hat. Oder man macht erst einmal in einer Paralellnstallation einen neuen Upgradeversuch.
Die neue Wordpress Version ist seit ein paar tagen online und heute wird sie dann eauch endlich installiert. Erst einmal wird alles gesichert damit auch nicht schief geht und bei Problemen schnell ein Rollback gemacht werden kann.
Sollte also nachher etwas nicht richtig funktionieren wird gerade das Update eingespielt.
Nachdem ich jetzt doch von einigen Leuten weiß, die meinen greylisting-Filter bei sich einsetzen, kann ich das auch grade mal hier announcen… Es gibt davon eine neue Version. Es gibt einen ziemlichen Bruch, es wird jetzt MySQL anstelle von SQLite als Backend benutzt. Das liegt daran, dass ich vor habe, eine selektive Whitelist (»Mails an diese Adresse bitte in den nächsten 10 Minuten nicht greylisten«) für unsere Kunden zu ermöglichen. Dazu muss es eine gemeinsame Datenbank für das webinterface und das greylisting geben, was hiermit geschehen ist.
Das hört sich sehr interessant an mit der Anbindung an die DB.
Es gibt davon eine neue Version. Es gibt einen ziemlichen Bruch, es wird jetzt MySQL anstelle von SQLite als Backend benutzt. Das liegt daran, dass ich vor habe, eine selektive Whitelist (»Mails an diese Adresse bitte in den nächsten 10 Minuten nicht greylisten«) für unsere Kunden zu ermöglichen. Dazu muss es eine gemeinsame Datenbank für das webinterface und das greylisting geben, was hiermit geschehen ist.
