:: handcode.de :: - Apache

Vortrag "Apache Konfiguration" online

nospam@example.com (Jens Giessmann) — Tue, 20 Jul 2010 09:02:36 +0200

Mein Vortrag "Apache Konfiguration" bei dem ich versucht habe zu vermitteln "Warum ein Apache tut was er tut und wie man ihn dazu bringt auch das zu tun was man will" beim Treffen der PHPUG Stuttgart am 14.07.2010 ist online.

Hier lang zum Vortrag.
(Navigieren in den slides mit Space,Pfeilen usw.)

Ein besonderen Dank auch noch mal an Harald Amelung vom Coworking0711 für die Möglichkeit jetzt dort unsere Vorträge halten zu können. Wir kommen gerne wieder!

Denic macht .de Domains platt

nospam@example.com (Jens Giessmann) — Wed, 12 May 2010 14:40:03 +0200

Aktuell hat es die DENIC wie auch immer geschafft, dass .de Domains praktisch weltweit nicht mehr auflösbar sind.

Also Finger weg von Services, nix restarten!
Solange ein Service z.B. ein Webserver die Domain-Auflösungen z.B. von NameVirtualHosts noch im Cache hat, läuft es immerhin noch.
Das wird bestimmt sehr lustig für uns arme Admins nach und nach alle möglichen Services mit komischen Effekten wieder zusammen zu flicken...

Wer zahlt das? Ich will nen Rettungsfond!

update: Die Denic hat die kaputten Nameserver wieder zusammen geflickt.
Passend dazu hier ein heise-Artikel vom Januar: "DNSsec könnte de-Zone lahmlegen".
Test war erfolgreich, lahmlegen klappt...

update: Auf denic gibt es jetzt auch eine offizielle Erklärung zum Ausfall...

Slides vom PHPUG Vortrag mod_rewrite online

nospam@example.com (Jens Giessmann) — Thu, 13 Mar 2008 10:55:21 +0100

Die Slides meines Vortrags gestern bei der PHPUG-Stuttgart sind online.

Thema: mod_rewrite

Zum Vortrag:
http://www.handcode.de/talks/phpug-php5-xml-xsl-200708/

PHP User Group Stuttgart Treffen, März 2008

nospam@example.com (Jens Giessmann) — Tue, 04 Mar 2008 09:06:26 +0100

Wie jeden 2. Mittwoch im Monat trifft sich die PHP User Group Stuttgart auch im März wieder zu einem Vortrag und anschliessendem gemütlichen Beisammensein.

Nächstes mal werde ich mal wieder einen Vortrag halten.

PHP-UG Stuttgart Treffen am 12.03.2008, 19:00

Vortrag:
----------------------------------------------------------------------
mod_rewrite, das Schweizer Taschenmesser der URL Manipulation.
----------------------------------------------------------------------

Mit dem Apache-Modul mod_rewrite ist es möglich, basierend auf einem Parser für reguläre Ausdrücke, angeforderte URLs anhand von Regeln "on the fly" umzuschreiben.

Themen des Vortrages sind:

Was ist mod_rewrite
Überblick über die Arbeitsweise von mod_rewrite
Beispiele für den Einsatz von mod_rewrite

Eingeladen ist wie immer jeder Interessierte, besonders PHPler aus Stuttgart.

Termin: Mittwoch, den 12. März 2008, 19.00 Uhr
Ort: Wirtschaftförderung Region Stuttgart, Friedrichsstr. 10, Stuttgart
Weitere Informationen wie immer auch auf auf http://www.phpugs.de

Referrer-Spam blocken mit Apache und mod_rewrite

nospam@example.com (Jens Giessmann) — Thu, 14 Jun 2007 21:07:00 +0200

Immer wieder werden Webserver mit Referrer-Spam Anfragen zugeballert, die wegen wechselnder IPs aber nicht so ohne weiteres in der Firewall geblockt werden können.
Der eigentliche Sinn eines solchen Angriffs besteht darin, in Referrer-Statistiken möglichst weit nach oben zu klettern.

Und wozu das?

Das primärer Ziel ist die Anzeige des Referrers als Link, z.B. auf Seiten, welche die Top-Referrer anzeigen, entweder um das Suchmaschinen-Ranking zu steigern, oder ganz banal, um Menschen auf die Seiten des Angreifers zu locken, damit diese dort irgendwelchen Kram kaufen. Nunja.
Ein weiteres Ziel des Angreifers ist möglicherweise auch, dass jemand, der auf den Link des Referrers klickt, sich auf den Zielseiten Schadprogramme, XSS Hacks (spannend wenn der User Admin-Rechte hat) oder ähnliche mehr oder weniger kreative Bösartigkeiten einfängt.
Daher ist auch beim Anschauen von Webserver-Stats (Webalizer o.ä.) Vorsicht geboten! Nicht einfach überall drauf klicken! Nur so als Hinweis ;-)

Richtig fies, wenn auch vom Angreifer meist unbeabsichtigt, wird so ein Angriff dann, wenn jede dieser Anfragen von einer komplexen, Resourcen hungrigen Web-Applikation (einem CMS,Blog o.ä. ) beantwortet werden muss und dadurch die Performance des gesamten Systems in den Keller geht.
Dann wird aus einem simplen Referrer-Spam-Angriff schnell eine DOS-Attacke.
Web-Spam-Filter innerhalb der Applikationen, wie sie inzwischen z.B. die meisten Blogs bieten, helfen hier leider gar nichts. Bis solche Filter aktiv werden, ist die meiste Rechenarbeit der Applikation schon passiert.
Filter innerhalb einer Applikation helfen nur dem Moderator die Kommentare und Trackbacks sauber zu halten.

Es muss also geblockt werden BEVOR die Anfragen bis zur Applikation durchkommen.

Eine einfache aber wirkungsvolle, wenn auch manuelle und daher mühsame Variante ist es, Filter mit RewriteRules zu setzen.

"Referrer-Spam blocken mit Apache und mod_rewrite" vollständig lesen

Spam-Blocker im Apache mit SetEnvIfNoCase (Fake:WordPress/2.1-alpha3)

nospam@example.com (Jens Giessmann) — Fri, 27 Apr 2007 08:30:00 +0200

Zur Zeit werde ich hier mal wieder mit nervigen Fake-Trackbacks zugeballert.
Klar, die kann man moderieren, und dann löschen, nervt trotzdem.

Was tun?

Blocken anhand der IPs ist meist nicht möglich, die wechselt in der Regel ständig.

Wenn man die Fakes/den Spam aber zum Beispiel anhand des selben (Fake) User-Agent festmachen kann, ist es recht einfach möglich diese im Apache zu blocken. Natürlich nur, wenn man Zugriff auf die Apache-Conf hat oder zumindest .htaccess Dateien anlegen darf. Wenn nicht -> Provider wechseln ;-)

Hier ein aktuelles Beispiel:
Fake-Trackbacks mit dem immer gleichen User-Agent "-- WordPress/2.1-alpha3". Prima, damit werden nicht wirklich viele "liebe User" unterwegs sein.

Eine entspr. Regel in der Apache-Conf sieht dann wie folgt aus:

CODE:

SetEnvIfNoCase User-Agent "-- WordPress/2\.1-alpha3" spammer=1

Order allow,deny
Deny from env=spammer
Allow from all

Mit der direktive SetEnvIfNoCase wird der User-Agent mit der RegEx verglichen und im Erfolgsfall die ENV-Variable spammer auf 1 gesetzt.

Dann bekommen alle Anfragen die als "spammer" geflagged sind, nur noch ein HTTP 403 Status Code (Forbidden).

Man kann solch ein Regelwerk beliebig erweitern und neue Merkmale hinzufügen.

Klar kann es sein, das man mit solchen Filter-Regeln auch False-Positives erzeugt, eine Prüfung auf User-Agent Mozilla wäre sicher keine gute Idee ;-)

Da man solche Regeln in <Directory>, <Location> und <Files> Blöcken definieren kann, muss man ja auch nicht immer die kompletten Seiten sperren. Das Blog-Verzeichnis oder die URL zum Trackback-Eintrag reicht ja.

Falls sich wer hier auf handcode.de zu Unrecht "ausgeschlossen" fühlt, soll sich bitte direkt bei mir melden.

Referer oder Referrer?

nospam@example.com (Jens Giessmann) — Thu, 29 Mar 2007 23:24:00 +0200

... oder wenn ein Fehler zum Standard wird.

Wie schreibt sich das denn nun richtig? Referer oder Referrer? Je nach dem wo man nachschaut, bzw. in welchem Kontext es benutztwird, wird es mal so, mal so geschrieben.

Die korrekte Schreibweise für das englische Wort ist "Referrer" (engl. to refer, verweisen).

Der HTTP-Request-Header schreibt sich aber 'Referer'.

GET / HTTP/1.1
Host: www.example.com
Referer: http://www.example.org/

Wie kommt's?

In den ersten Versionen des RFC 1945 zu 'Hypertext Transfer Protocol -- HTTP/1.0' von 1996 hatte sich versehentlich die falsche Schreibweise 'Referer' eingeschlichen.

Im Januar 1997 im RFC 2068 zu 'Hypertext Transfer Protocol -- HTTP/1.1' ist diese, an sich falsche Schreibweise dann endgültig zum Standard für HTTP erhoben worden.

14.37 Referer

The Referer[sic] request-header field allows the client to specify,
for the server's benefit, the address (URI) of the resource from
which the Request-URI was obtained (the "referrer", although the
header field is misspelled.)...

Leider ist es aber auch mit diesem Standard so wie mit den meisten:
Es halten sich nicht alle dran.

PHP verwendet die HTTP übliche Schreibweise:

$_SERVER["HTTP_REFERER"]

In Javascript zum Beispiel wird aber die englische Schreibweise verwendet:

document.referrer

Warum kann denn nicht mal irgendwas einfach einfach sein...

RewriteRules für temporäre Tests

nospam@example.com (Jens Giessmann) — Wed, 28 Feb 2007 12:38:27 +0100

Da ich das selber immer mal wieder brauche, hier mal eine Kurz-Doku dazu:

Aufgabe:

Eine WebApp/Site soll getestet werden.
Fuer die Testphase sollen aber gleichzeitig alle Anfragen die nicht aus dem eigenen Netz kommen auf eine Baustellenseite umgeleitet werden.

Lösung:
RewriteRules mit einer Bedingung auf die Client-IP

CODE:

RewriteEngine On
# Die Baustellen-Seite selber einfach ausliefern
RewriteRule ^/baustelle.html - [L]
# Alles was NICHT aus dem eigenen Netz (192.0.2.*) kommt....
RewriteCond %{REMOTE_ADDR} !^192\.0\.2\..*
# ... umleiten auf die Baustellenseite
RewriteRule ^.* http://www.example.org/baustelle.html [L,R]