Einträge zu 'Software' ↓

#!/usr/bin/perl

use strict;

Über die Jahre sammeln sich eine Menge Bookmarks an. Das Format beim Firefox 1 und 2 war ja nicht so das gelbe vom Ei. Wer dort mal mit ein paar Zeilen nach doppelten Einträgen sucht wird schnell verzeifeln. Aber wer nicht aufgibt schaut sich das dann doch hin und wieder einmal an, um endlich den schnellen Weg zu finden.

Nach dem Backup der aktuellen Bookmarks und einem ersten Blick mit less sieht es jetzt aber alles irgendwie anders aus. Was als erste aufgefallen ist, es sind keine Zeilenumbrüche vorhanden. Also schnell ein geziehlter Blick nach einem Anhaltspunkt, der auf einen Trenner hinweisen könnte. Mit dieser Erkenntniss dann ein paar Zeilen Perl in den VIM werfen und einfach mal durchlaufen lassen. Als Ergebniss wird die Anzahl der Einträge angezeigt. Etwas mehr als 2700 Zeile, das passt ganz gut.

Als nächstes wurde dann einmal geguckt wie die Struktur der neuen Bookmarkdatei jetzt ist. Es ist leicht zu erkennen, daß es Schlüsselwörter und Werte gibt. Also dann mal eben das Script um ein paar Zeilen erweitern und noch einmal laufen lassen. Es sieht jetzt schon mal besser aus als die früheren Versuche. Hier und da passt es noch nicht ganz, aber für ein 5 Minuten Script ist das Ergebniss schon mehr versprächend als früher.

Das wird weiter gestrickt und wenn es dann fertig ist hier erscheinen. So kann dann jeder schnell die Bookmarks von doppelten Einträgen bereinigen. Es gibt zwar unmengen Tools dafür, aber die meisten sind für Windows und/oder sie funktionieren nicht. Zum Glück wurden die Tools nur auf Backups losgelassen, denn so manches davon hat auch mal eben so die ganzen Bookmarks geschreddert.

Morgen dann weiter gucken und die ganzen Keys und Values in einen %hash werfen und einmal schütteln.

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.

Der Chris vom Ruhrpottforum und VDSL-News will seine Links zu Amazon über domain.tld/extern/amazon/suche/<SUCHWORT> umleiten. Hierfür hat er von mir folgende RewriteRule bekommen.

# Die Zeile ist hier mit dem \ umgebrochen wegen der Anzeigen.
RewriteRule ^extern/amazon/suche/(.*) \
http://www.amazon.de/s?ie=UTF8&tag=...-21&index=blended&\
link%5Fcode=qs&field-keywords=$1 [L]


Bei ihm funktioniert aber das Flag [P] nicht um die vdsl-news.de in der URL stehen zu lassen, daher nutzt er aktuell noch das Flag [L]. Wer das Flap [P] benutzen möchte sollte noch folgende RewriteRule einsetzen damit dann weitere Links von der Amazonseite aus funktionieren.

# Die Zeile ist hier mit dem \ umgebrochen wegen der Anzeigen.
RewriteRule ^gp/redirect.html/(.*) \ http://www.amazon.de/gp/redirect.html/$1 [L]


Chris plant auch noch zusätzlich neben seinem Info Blog zum Thema VDSL noch weitere Anlaufstellen zum Thema Bluray und HDTV. Dafür schon einmal viel Erfolg.

Beim testen der Rewrite Rules haben wir gerade als Suchbegriff Tiesto benutzt. Erstaunlich das sofort auf der Amazonseite nach dem testen bei mir Tiesto aufgetaucht ist im Amazon Partnerprogramm. Das zeigt einmal mehr wie sehr Amazon Profiles über die Besucher erstellt und sehr viele Daten speichert.

Update: Das Flag [P] sollte an dieser Stelle auch nicht benutzt werden. Denn damit kann Amazon den Link nicht richtig taggen und nicht auf die Amazon ID referenzieren.

Tomato is a small, lean and simple replacement firmware for Linksys’ WRT54G/GL/GS, Buffalo WHR-G54S/WHR-HP-G54 and other Broadcom-based routers. It features a new easy to use GUI, a new bandwidth usage monitor, more advanced QOS and access restrictions, enables new wireless features such as WDS and wireless client modes, raises the limits on maximum connections for P2P, allows you to run your custom scripts or telnet/ssh in and do all sorts of things like re-program the SES/AOSS button, adds wireless site survey to see your wifi neighbors, and more.

polarcloud.com/tomato

Nachdem Woopra nicht funktioniert mit Wordpress, da JavaScript in Wordpress nicht unterstützt wird in PlugIns, aus Sicherheitsgründen gibt es eine nette Alternative. Man hat zwar keinen Client wie bei Woopra, aber kann genau so alles online einsehen.

Nette Sache ist z.B. Spy. Damit kann man Live sehen, wer von wo kommt, aufwelcher Seite sich der Besucher aufhält und wie lange. Es läuft hier jetzt erst einmal einige Zeit mit um zusehen wie es funktioniert. Dann werden auch einmal ein paar Screenshots folgen.

Clicky Web analystics

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

chown www-data:www-data /var/lock/apache2

löst dieses Problem.

Fehler: undefined symbol: dav_hook_gather_propsets

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.

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.

Quelle: Heise.de

Heute wurde von Matthias die CA inkl. Clientcerterstellung fertig gemacht und anschliessend konnte ich die Konfiguration der Servers fertig machen. Danach war der erste Client an der Reihe, was wie zu erwarten recht zügig erledigt war. Der zweite Server war schnell mit eingebunden. Nach dem das Routing und Firewall umkonfiguriert waren klappten dann auch von allen Maschinen die Verbindungen zu allen anderen.

Anschliessend meldete Nagios einen meiner Server mit einer hohen Load und Probleme mit einem der Gateways. Irgendwo rannte da der Apache und MySQL Amok. Nach welzen von 1.4 Gig MySQL Log war der Übeltäter schnell gefunden. Es war mal wieder das Joomla von einem Bekannten, der die Seiten der Pfadfinder aus Essen-Schonnebeck auf diesem Server hat.

Nach dem das erledigt war kam dann einmal etwas spassiges zum Tagesprogramm dazu. Tatjana sendet mir einen Link zu einem Chat den ein alter Bekannter programmiert hat. Als ich den Link angeklickt hatte habe ich erst einmal nicht bemerkt was passiert ist. Ich bin nicht so der Chatter, ICQ, IRC usw. ist ja normal, das braucht man da schön täglich. Aber das Chatten im Browser ist schon ein paar Jahre her und man schaut dann jetzt also mal wieder in so einen Chat rein.

Erst nachdem ich ein “Moin” in den Chat geworfen habe und nach ein paar Sekunden danach, bemerke ich was da eigentlich passiert ist. Tatjana schickt mir diesen Link. Die SessionID im Link habe ich bestimmt gesehen, sie war mir aber nicht bewusst geworden. Gerade weil man seit Jahren wissen sollte was bei solchen Sachen schief geht.

Nach dem anklicken des Link kam ein Login mit meinen Zugangsdaten. Ich war schon mal kurz drin um etwas zu testen und die Zugangsdaten kannte mein Browser noch. Also steht mein Name und das Passwort in den beiden Feldern schon drin. Also rein in den Chat und schreibe das “Moin”.

Was ist jetzt aber passiert? Ich schreibe, da die SessionID im Link steht mit dem Nick von Tatjana. Aber auch alles andere ist von Tatjana. Ich habe Ihre komplette Session übernommen und könnte, wenn so etwas bei anderen grossen Portalen wie Ebay (naja, da geht so etwas mit mehr Aufwand auch), Arcor (Hatte genau das hier beschriebene Problem 2005), StudiVZ, Youtube usw. passieren würde, kann man alle Daten des übernommen Profils lesen, verändern und viel schlimmer, man kann mit solchen Daten auch sehr viel mehr Sachen anstellen.

Ich habe mir dann überlegt wie leicht es wohl sein würde an die SessionIDs der anderen zu kommen. Erste Überlegung war ein Bild in den Chat zu posten, das hätte ich erst einmal zusammen bauen müssen. Das Bild würde dann von jedem User bzw. desen Browser geladen und hätte ein paar Zeilen Code inne, die die SessionIDs der einzelnen User auf einem meiner Server speichern. So viel Aufwand wollte ich dann aber nicht betreiben, es sollte ja einfach meine Neugier befriedigt werden, da ich wissen wollte was man in diesem Chat so alles anstellen könnte, wenn man nicht, wie ich, das Interesse hat solche Probleme aufzudecken, sondern die Accountdaten haben will um damit dann zu etwas zubestellen, Passwörter zubekommen, E-Mailadressen usw.

Man kennt das Chat Volk, also mache ich es mir einfach. Ich gehe auf einen Server öffne ein Webserver Logfile und schmeiss einfach eine URL als Link in das Chatfenster. Wie zu erwarten wird auf den Link geklickt und ich erhalte ohne Aufwand alle SessionIDs. Anschliessend ausloggen und Cookie gelöscht ruf ich den Direktlink zum Chatfenster wieder auf und bin wieder drin mit einem der angemeldeten User.

Nachdem ich den Admin informiert hatte, immer mehr den Eindruck bekam er wollte es nicht wissen und es kann ja nicht sein das Tatjana den Link mit Session weiter gibt wurde es mir dann doch etwas zu bunt. Da baut jemand etwas zusammen und macht einen groben Fehler. Jemand macht ihn auf das Problem aufmerksam und will dann helfen damit er das Problem in den Griff bekommt. Und dann so eine Reaktion. Okay er will es nicht wahrhaben, kann ja gar nicht sein meint er. Ich schreibe ihm ich einfach mal in seinen Chat ich habe da eine komplette Anleitung wie der das mit der Session richtig machen muss. Poste den Link und siehe da er klickt. Danach habe ich dann mal seine Session übernommen. Er war dann wohl etwas angepisst, streitet aber immer noch ab, daß es ein Problem gibt.

Dann soll er halt so weiter machen. Sollte der Chat viele User haben wird schon irgend jemand mal daher kommen der genau das Problem erkennt, aber nicht aus Interesse und um Sicherheitspobleme aufzuzeigen, sodern um Mist zubauen. Spätestens dann, wenn großes Chaos ausbricht wird man sich halt selbst in den Hinterntreten.

So ist das, nach Feierabend etwas OpenVPN und Server Konfiguration zum basteln, anschliessend noch Spaß haben mit Sicherheitslücken in einem Chatsystem.

So macht das Leben eines Linuxadmins nach der Arbeit richtig Spaß.