man bedim len?

Wer ein für Admins etwas beunruhigendes Screenshot sehen möchte, schaut mal auf das Webworking-Blog:

Du willst es nicht sehen....

Ob ich mir jetzt Sorgen machen sollte?

Angeblich wurde das Webportal ideenreich.com (der selbsternannte "Dr. Web") von der HackBSD Crew gehackt.
Auf dem SelfHTML-Forum gibt es hierzu einen eigenen Thread (der allerdings eher etwas schadenfroh gerät):
dr.web offenbar gehackt


Unabhängig davon was man nun von Ideenreich.com persönlich halten mag, ist es immer blöd, wenn irgendwelche Scriptkiddies irgendwelche Tools in die Hände bekommen und destruktiv und ohne jeglichen Rest echter Hackerethic jede Website mit kaputten HTML-Code verschandeln.

Liebe Kiddies und liebe "HackBSD Crew", dies ist für euch gemacht worden:
Rock'n'Roll Assholes

Echte Hacker trifft das nicht.

Google, Microsoft und co. haben in letzter Zeit Patente auf Funktionen ihrer Suchmaschinen beantragt, die für Fachleute nicht gerade Themenfern sind.

Da ein Patent jedoch nicht genemigt werden kann, wenn dessen Inhalte und Techniken vorher öffentlich bekannt waren, hab ich auf meiner persönlichen Homepage ein patentwürdiges Konzept zu einer Doktorarbeit veröffentlicht.


http://www.aravaeth-onan.de/doc/Vortraege/PersoenlicheSuchmaschinen-22-11-2001.pdf

Das Konzept beschreibt in allgemeiner Weise, wie man das derzeitige Dilemma der zu vielen und für den Suchenenden unpassenden Suchmaschinenergebnisse personalisiert beheben kann.


Dieses Konzept wurde von mir bereits 2001 erstellt und auch in einem öffentlichen Vortrag an der Universität Erlangen-Nürnberg vorgestellt.
(Leider kam mir damals ein anderes interessantes Projekt dazwischen, so daß ich die Arbeit dann ruhen ließ.)
Teile des vorgestellten Konzeptes wurden auch bereits in Rahmen einer Studienarbeit gelöst.
Darin die automatische Kategoriesierung von Inhalten mit Hilfe von Testdokumenten. (TF-IDF-Algorithmus).

Das Projekt, das Konzept und die Techniken sind somit
wohlbekannt und öffentlich.

Durch die jetzige öffentliche Zugänglichkeit hoffe ich eine mögliche Patentierung durch Firmen, die gerne ein Blockierungsmonopol aufbauen möchten oder gerne Patentklagen zum Geldgewinn anstrengen, zu verhindern.
Zwar gibt es sicherlich Leute, die dies nicht jucken würde, und die es drauf ankommen ließen, aber im Zweifel kann "Prior Art" nachgewiesen werden :)

Wer dagegen Interesse hätte sich des Konzepts anzunehmen um es selbst voll umzusetzen oder gar Browsererweiterungen dazu zu schreiben, kann sich gern für Details mit mir in Verbindung setzen.

Die Webworker-Community Strohhalm präsen tiert sich ab heute in einem neuen, frischen Design und einer verbesserten Usability.

Zwar ist das Design noch nicht ganz barrierefrei und verwendet noch absolute Positionierungen, jedoch ist ein gewaltiger Schritt getan worden im Vergleich zum vorherigen Design.

(Ich darf hierbei übrigens nicht zu laut meckern, denn ich wurde schon recht früh gefragt ob ich mithelfen kann - hatte jedoch leider keine Zeit und hab sogar übersehen daß ich diesbezüglich eine Message in meiner Mailbox hatte. Sorry!! )

Was ich sehr gut finde ist, daß es möglich ist Userstyle-Sheets einzubringen (nicht nur über die Bowserfunktionen). Dadurch wird sich sicherlich, bei genügend aktiven Leutem ein an die Individualbedürfnisse angepasstes Layout entwickeln. Ganz ähnlich vielleicht wie beim CSSZengarden.

Ich bräuchte halt einen Jupitertag, wenn ich all das schaffen wollte, was ich gern machen und wo ich gern mehr mithelfen würde...

Aber dann gleich auch mal ein paar Zig-Tausend mal :)

Am letzten Wochenende kam es offenbar zu einer Referer-SPAM-Attacke auf einen gut besuchten Webauftritt den ich betreue.

(Da der Webserver dies einfach wegsteckte ohne zu murren, ist es mir erst jetzt beim Lesen der Statistik aufgefallen.)

Zwischen dem 22 und 24.7. hat ein Host 198032 Zugriffe auf eine Seite gemacht, wobei insgesamt 31.119.306 kB (29 GB) geladen wurden.

Hierbei wurden jeweils 10 Attacken gefahren um mit zwischen 18600 bis 20500 Zugriffen jeweils auf die Webseite (innerhalb des Webbaumes) per Referer Information hochzupuschen. Dies ist in der Statistik auch dementsprechend erfolgreich. Die Plätze 3 bis 14 in den Refererinfos waren durch Links auf irgendwelche Pornosites belegt.


Ziel solcher Referer-SPAM-Attacken ist es, dafür zu sorgen, daß die in der Referer Information übertragene Website in Onlinestatistiken auftaucht.
Diese Statistiken wiederum könnten ja von Suchmaschinen gelesen werden. Die Suchmaschinen würden dann wiederum solche Seiten im Ranking hoch werten, da dann ja viele Links verweisen darauf verweisen.

Somit handelt es sich hier eindeutig um einen vorsätzlichen Missbrauch von IT-Systeme zu kommerziellen Zwecken.
Wäre eine deutsche Site beworben worden, hätte dies sicherlich eine Anzeige nach sich gezogen.

Leider ist Provider ein DSL-Zugangsanbieter in New York, so daß eine rechtliche Verfolgung in diesem Fall weitgehend sinnlos ist.
Ich vermute durch den Traffikverbrauch ist der Provider selbst schon gebeutelt und hat vielleicht selbst schon reagiert.

Dieser Art der Attacken ist leider in letzter Zeit ziemlich stark im kommen. Es gibt inzwischen eine Branche, die mit genau solchen Mitteln arbeitet um Geld zu verdienen.
Noch schlimmer: Im Gegensatz zu Mail-Spam ist diese Form der Werbung noch nicht genug verpönt und gesellschaftlich noch nicht gebranntmarkt.
Man schlage eine IT-Zeitung auf und man findet einige Angebote von "Suchmaschinenoptimierer".
Selbst der Heise-Verlag macht da motivierende mit, indem dieser
einen Wettbewerb der besten Suchmaschinenoptimierer ausgerufen hat.
(Vgl: Siehe im Netz: "Hommingberger Gepardenforelle").



Selbst wenn wir in unseren Statistiken diese Information weglassen werden wir -wie bei SPAM auch- weiter attackiert.
Eine andere Möglichkeit gibt es zwar auch, sie ist aber properitär und nur für eine Suchmaschine wirksam: Google bietet die Möglichkeit eines NONFollow-Tags an, mit der Links deklariert werden sollen, die nicht verfolgt werden sollen.

Eine Setzung solcher Tags wirkt sich damit gegen Referer-SPAMer dann sogar negativ aus.


Um die Gefahr durch RefererSPAM in Zukunft etwas einzugrenzen werde ich jedoch auf eine etwas abgewandelte automatische Reaktion setzen.

Folgende Anweisung findet sich nunmehr in einer .htaccess-Datei, die sich in den Statistik-Verzeichnissen befindet:

Meine Domain hab ich mal durch "example.com" ersetzt.

	RewriteEngine On
	RewriteCond %{HTTP_HOST} !example.com$ [OR]
	RewriteCond %{REMOTE_HOST} !example.com$ [NC]
	RewriteCond %{HTTP_REFERER} !example.com [NC]
	RewriteCond %{HTTP_REFERER} ^(.+)$ [NC]	
	RewriteRule ^(.*)$ %1 [R=301,L]

Das bedeutet folgendes:
Wenn derjenige, der auf einen Statistikseite geht eine Host abruft, welcher nicht mit example.com aufhört oder von dem Host kommt und die Refererinfoein Inhalt hat und der Inhalt nicht example.com enthält, dann wird der Zugriff zurückgeleitet auf die Seite die in der Refererinfo steht.

Also kurz gesagt: Ein Refererspamer wird auf die von ihm beworbene Seite umgeleitet und verursacht dann dort die Traffikkosten.

Diese Regelung funktioniert natürlich nur für Seiten innerhalb des Webauftritts. Auf keinen Fall sollte man das für die Startseite verwenden.
(Und wer keine Rechner im selben Netz hat braucht natürlich die ersten beiden RewriteConditions auch nicht.)

Für die Startseite slebst müsste man andere Lösungen machen.



Anderer Nachteil: Legitime Links von fremden Seiten, die von fremden Rechnern aufgerufen werden, werden ebenfalls umgeleitet.
Aber dieses Problem sollte man umgehen dadurch, daß man nicht auf innere Bereiche der Statistik linkt, sondern auf die dazugehörigen Startseiten des Webauftritts.


Laut aktuelle Log ist diese Lösung erfolgreich.
Der Angreifer ist offenbar derzeit nämlich wieder dabei und nutzt dabei andere Provider. (Wahrscheinlich ist der andere
inzwischen Pleite wegen Traffikkosten).
Offenbar hat er es auch schon bemerkt und vermutet wohl, daß wir dieselben Möglichkeit nutzen wie viele andere auch, nämlich die Nutzung einer bekannten Liste von Hosts oder Refererinfos, die für Refererspam genutzt werden.
Beispielsweise so:

  RewriteEngine On
  RewriteCond %{HTTP_REFERER} ^http://(www\.)?.*adult(-|.).*$ [OR]
  RewriteCond %{HTTP_REFERER} ^http://(www\.)?.*anal(-|.).*$ [OR] 
  [...]

  RewriteCond %{HTTP_REFERER} ^http://(www\.)?.*tits(-|.).*$
  RewriteRule .* - [F,L]

Quelle: basquiat.de


Einen ähnlichen Ansatz macht Isotopp:
Kommentarspammer


Diese Varianten halte ich aber für den Dauerbetrieb für problematisch: Man müsste sich dann dauernd darum kümmern, seine Listen up-to-date zu halten. Dafür hat aber niemand Zeit.

Ich hoffe mal, das mein Ansatz etwas länger hält.
Aber auf Dauer wird er auch nicht helfen, da er einen Referer-SPAM-Atacke auf die Startseite nicht verhindert.

Dort jedoch könnte man einen anderen Ansatz machen:
Über ein Perlskirpt würde/werde ich die Zugriffe auf diese Startseite abrufen und für alle Zugriffe von mit Links von extern eine Zugriff ausführen auf die externe Seite.
Diese externe seite wird dann einfach nach einem Link auf unsere Site durchsucht.
Ist keiner vorhanden, wird diese Refererinfo und die genutzte IP einfach ne Weile lange geblockt oder mit einer Teergrube versehen.

Heute war auf den Plan: Videokonferenz mit den Webverantwortlichen der beiden BW-Unis zum Thema BITV.

Die beiden Bundeswehr-Unis sind ja, im Unterschied zu den normalen Landesunis, bereits verpflichtet sich an die BITV zu halten. Bis zum Ende des Jahres müssen sie ihre Webauftritte so anpassen, daß diese barrierefrei gemäß BITV sind.
Hier gibt es aber noch viel zu tun. Jedoch sind die Anfänge gesetzt und die Unterschiede zu normalen Unis sind eigentlich garnicht groß. Auch bei den BW-Unis gibt es fähige Programmierer, die schöne Dinge zaubern können und auch Webserver aufsetzen können.
Die Uni Hamburg setzt dabei auf ein eigenentwickeltes CMS auf Basis von PHP und die Münchener auf eine Lösung basierend auf Plone.

Zwar hat Hamburg die optisch umfangreichere Seite, jedoch hat diese noch einige Probleme mit der Darstellung auf alternativen Medien. Die Münchener haben dagegen eine eher spartanische Oberfläche. Und dem entsprechend weniger offensichtliche Probleme.

Erfreulich ist IMHO aber die Unverkrampftheit, wie gerade an den BW-Unis an die Sache rangegangen wird. Ein Dogmatismus in Bezug auf Corporate Design, wie man ihn bei einigen normalen Unis (bzw. dessen Pressestellen) erleben kann, ist dort nicht vorhanden.
Fazit: Die sind auf den besten Weg.

Linktipp zu dem Thema:
Breaking a Visual CAPTCHA

Dort findet sich eine Arbeit, die zeigt wie man mit Hilfe von Algorithmen Bilder analysieren kann, daß darin eingebrachte -vermeintlich nur menschen-lesbare- Dinge auch für
Computer erkennbar werden.

Letzte Änderung des Dokumentes: 15.12.2003 (!)

Die Rezepte die dort gegeben werden sind durchaus tauglich um daraus ein paar nette Programme zu machen.
Und dies nicht nur wenn man ein SPAMer ist, sondern auch für andere, sinnvollere Zwecke.

(Über: efa)

Oh man! Das ist echt unfassbar. So schlecht kann doch keiner programmieren, daß die dauernd wieder solche Bugs reinhauen.

Ein satirisches Beitrag beim Heise-Forum passt da echt gut:
The same horror again and again
18. Juli 2005 17:15
von "Schaulustiger":


Neulich vor der Kaffeemaschine bei einem Internet-Dienstleister um
die Ecke.

A: "Haste gelesen, eben bei Heise. Gibt mal wieder 'nen neuen Patch für phpBB."
B: "Hmm... jau... was is' es diesmal?"
A: "Der gute, alte Cookie-Klau."
B: "Ahja, wann war das noch? 2001 gab's das doch schon mal?"
A: "Kommt alles wieder. Gib mal die Milch."
B: "Manche lernen es nie. Der gute, alte Trick mit der Session-ID in der URL?"
A: "Scheint so. Wassen heute für ein Tag?"
B: "Mittwoch... moment... ja, Mittwoch. Montags finden Sie raus, was die Skriptkiddies am Wochenende für einen Exploit geschrieben haben, Dienstag ist der Fix da und Mittwoch steht's in den News."
A: "Mittwoch? Dann bist du heute mit dem Patchen bei phpBB dran."
B: "Schrott, ich wollte mal heute zeitig Heim. Ich hab doch schon Montag gepatcht..."
A: "Tjo, abgemacht ist abgemacht. Ich Dienstag, Donnerstag, Samstag."
B: "Ist schon gut! Schon gut! Kotzt mich halt nur ziemlich an, jedesmal wieder die Foren patchen zu müssen. Warum habt ihr überhaupt damals phpBB genommen?"
A: "Es hat jeder genommen. Es ist leicht zu installieren. Es kostet nichts."
B: "Aha...Noch Zucker da oder nur Süßstoff?"
A: "Und dem Chef haben die bunten Vorlagen gefallen."
B: "Und wer muss es ausbaden?"
A: "Mittwochs? Du."
B: "Bei dem einen Kunden neulich, Spielwaren Kröber, hatten wir nur FTP-Zugang. Wir haben 10 Webseiten mit Update-Anweisungen per Hand jeweils in die Dateien reingepatcht. Da war 2.0.4 drauf... von 2.0.4 auf 2.0.5 von 2.0.5 auf 2.0.6 von... bis 2.0.14 oder so...."
A: "Hehe, schöner Mist. Hatte den Kröber am Telefon, der war stocksauer, als er all die roten Seiten gesehen hat, auf denen nur noch 'You're owned' stand. Ich wusste auch erstmal nicht, was los war, bis ich auf Heise Security was über die Sicherheitslücke gelesen habe."
B: "Hey, du weisst doch... Als Admin musst du IMMER wissen, was die Kunden auf ihren Servern installieren. Die sollten ein Feature einrichten, daß man bei einem neuen phpBB-Exploit direkt 'ne SMS kriegt."
A: "Man könnte den Kunden auch eine geladene Waffe in die Hand drücken und uns dafür verantwortlich machen, wenn es Tote gibt."
B: "Bei einige Kunden könnte ich echt dafür verantwortlich sein, wenn die tot gefunden werden..."
A: "Falling Down noch vor dem ersten, gepatchten Forum? Spar dir das für Karnickelzucht-ruhrpott.de nachher auf."
B: "Klasse, das Prestige-Objekt vom Chef. Darf ja nix kosten!"
A: "Tjo, der Kaffee hier ist zwar auch umsonst, aber wenn ich nach jeder Tasse einen Tag lang Magenbeschwerden hätte, würde ich - ehrlich gesagt - lieber dafür zahlen."
B: "So is' es. Ich geh' mal patchen."
A: "Viel Spaß."

Endlich haben wir eine flottere Solariskiste bekommen, die unsere betagten alten Server ersetzen sollen.

Aber ich denke, meine Frust wegen der Geschwindigkeit wurde durch die Enttäuschung über die vorhandenen Editoren ausgetauscht: Gerade eben ist mir zum wiederholten Mal ein Editor abgecrasht.

• jEdit - stürzte mir ab, als ich 5 Files gleichzeitig offen hatte. Ausserdem finde ich die Oberfläche blöd.
• kEdit - gibt es nur, wenn der Admin kde installiert hat. Ist gut konfigurierbar. Crasht aber, wenn man eine Datei unter einem neuen Namen speichern will, dabei aber den vorhandenen Dateinamen ändern will und dann die Del- oder die Insert-Taste betätigt.
• gedit (Standard vorgegeben als "Text Editor" unter Launch->Apps->Assess.->"Text Editor"). Ähnlich konfigurierbar wie kedit, aber ein weniger Funktionen. Dafür hat es eine größere Auswahl an vorgegebenen Sprachen bei Highligtning. Die man dafür aber um so weniger anpassen kann (Bei Perl nur etwa 8 verschiedene Farbfunktionen). gedit crashte mir gerade eben ab, als ich nur 3 Files gleichzeitig offen hatte, unetr einer mir unklaren Situation.

Das einzige was anscheinend wirklich zuverlässig als Texteditor unter Solaris zu nutzen ist, ohne das man Angst wegen Datenverlust haben muss, ist offenbar der simple dtpad oder einfach vi/vim.


So langsam sterben meine ehemals euphorischen guten Gefühle für Solaris.

Derzeit bin ich Strohwitwer und darf daher abends selbst sehen, wo ich (respektive mein Magen) bleib.

Da macht dieser Artikel doppelt Hunger:
How to style a restaurant menu with CSS

Zum einen wegen den CSS-Trick, der eigentlich klar war, aber auf den ich auch noch nicht gekommen bin.
Zum anderen aber wegen der Beispielumsetzung der italienischen Speisekarte.


Hm... Hol ich mir jetzt ne Pizza oder mach ich mir Tortellini ?


(via Perun)