Tag: apache

bots aussperren per iptables

irgendwann haben mal irgendwelche drecks bots einen uralten webserver lahm gelegt.
an die robots.txt haben sie sich nicht gehalten und eigentlich sollte die seite von keiner suchmaschine gecrawled werden. also aussperren nach diesem muster:

for i in `cat /var/log/apache/*.log | grep YandexBot|cut -d" " -f1|sort|uniq`; do iptables -A INPUT -s $i -j DROP; done 

das parst die apache logs, filtert nach dem entsprechenden bot, und sperrt die genutzten ips.
quick and dirty 😉

apache2 “Negotiation: discovered file(s) matching request: None could be negotiated”

neulich… beim umzug einer fotogalerie auf einem anderen webserver kam neben der entsprechenden fehlermeldung im browser (file not found) diese fehlermeldung im error.log:

AH00687: Negotiation: discovered file(s) matching request: /var/www/htdocs/domain.tld/index (None could be negotiated)., referer: http://domain.tld/

nach etwas googlen war mir klar, dass das mit der option “MultiViews” zusammenhaengt.

die apache webseite weiss dazu:

The effect of MultiViews is as follows: if the server receives a request for /some/dir/foo, if /some/dir has MultiViews enabled, and /some/dir/foo does not exist, then the server reads the directory looking for files named foo.*, and effectively fakes up a type map which names all those files, assigning them the same media types and content-encodings it would have if the client had asked for one of them by name. It then chooses the best match to the client’s requirements.

heisst also… beim aufruf von “http://domain.tld/index” schaut der webserver, ob er eine datei “index” mit einer irgendeiner dateiendung findet. er haette eigentlich in diesem falle die vorhanden index.php finden und nehmen sollen…. hat er aber nicht. grund dafuer war, dass der webserver nicht wusste, was er mit der dateianedung “php” anfangen soll.

bei einem debian stretch wird der umgang mit den mimetypes mit dem apache modul “mime” geregelt. am anfang der datei /etc/apache2/mods-available/mime.conf steht geschrieben:



   TypesConfig points to the file containing the list of mappings from
   filename extension to MIME-type.
   #
   TypesConfig /etc/mime.types

also husch in der /etc/mime.types geschaut und gesehen, dass diese zeile auskommentiert ist:

# application/x-httpd-php      phtml pht php

kommentarzeichen davor weg, speichern, apache neu starten und gut.

wenn ich schon am protzen bin… das ssl gedoense…

fuer diese gibts seite auch vom “SSL Server Test” ein A+ ranking.

20160218_sslservertestaplus

wenn ich schon mal am protzen bin 😉

mod_pagespeed selektiv abschalten

wenn man mod_pagespeed verwendet, werden manche dateitypen “optimiert” und gecached. wenn man nun gerade am rumbasteln ist, werden aenderungen an stylesheets etc. nicht direkt wirksam. dann kann man mod_pagespeed einfach ausschalten, indem man eine “.htaccess” mit diesem inhalt anlegt bzw eine bestehende ergaenzt:


  ModPagespeed off

nur noch ssl bitte – HSTS aktivieren und prüfen

um HSTS zu aktivieren, muss man einfach in die .htaccess datei folgendes reinschreiben:


# HSTS (mod_headers is required) (15768000 seconds = 6 months)
Header always add Strict-Transport-Security "max-age=15768000"

falls der apache das headers modul noch nicht geladen hat, auf der commandline ausfuehren:

a2enmod headers

sofern das notwendig war, bitte den apache neu starten.

und dann einfach pruefen mit diesem befehl:

curl -si sd.vc | grep Strict

der output sollte so aussehen:

Strict-Transport-Security: max-age=15768000

uzr sicherheit, falls doch ein browser ankommt, der kein HSTS unterstuetzt noch diesen spruch in die .htaccess:


RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule .* https://ww.sd.vc%{REQUEST_URI} [last]

zusammen mit ein paar wichtigen einstellungen an den ciphers etc. (spaeter mehr dazu) gibt das beim Test von Qualys SSL Labs ein A+ ranking 🙂

20150618_aplus

damit die ganze seite dann nur noch ueber https geht, muss man in den einstellungen von wordpress (settings -> general) die url auch noch auf https anpassen:

20150618_wordpress_https

und da wordpress die dumme eigenheit hat, die eigenen urls (bilder, links) als absolute links abszuspeichern, muss man die auch noch aendern.

UPDATE wp_posts SET post_content = REPLACE(post_content,'http://ww.sd.vc','https://ww.sd.vc')

ausnahme fuer rewrite rule

wenn sich die url bzw. domain einer webseite aendern, aber weiterhin auf dem alten webpraesenz etwas z.b. in einem unterordner erreichbar sein soll, muss man diesen unterordner quasi “excluden”. mit der rewrite rule in der .htaccess geht das so:

RewriteEngine on
RewriteCond %{HTTP_HOST} !^www\.domain-alt\.tld$
RewriteCond %{REQUEST_URI} !\/ordner\/.*$    [NC]
RewriteRule ^(.*)$ http://www.domain-neu.tld/$1 [L,R=301]

fehler nach owncloud update: “zend_mm_heap corrupted”

nachdem ich heute meine owncloud installation auf 7.0.4 aktualisiert habe, gabs erstmal nur noch “500 Internal Server Error” 🙁

im apache error.log fand ich folgenden eintrag:

zend_mm_heap corrupted

und nach ein wenig googlen habe ich abhilfe gefunden:

after much trial and error, I found that if I increase the output_buffering= value in the php.ini file, this error goes away

hmm… gesagt – getan… funktioniert. nun muss ich nur noch weiter suchen und den hintergrund verstehen 😉

DIY werbeblocker

wo wir gerade bei werbung waren… werbeblocker in browsern sind ja eh doof, weil da teilweise auch eine riesige geldmaschine dahinter steht. (also nicht bei der werbung, sondern auch bei den werbeblockern!)

hier eine kurze beschreibung, wie ich mir einen rudimentaeren werbeblocker selbst gebastelt habe. und da ich von natuer aus neugierig bin, wollte ich auch ein bischen statistik haben, was mir das ganze bringt.

als erstes brauchen wir eine liste bekannter urls der anbieter von werbung. es gibt eine android app, welche eine solche liste bzw mehrere listen aus dem netz zieht und diese kumuliert in die hosts datei des geraetes rein kopiert. die hostnamen der “ad-server” werden dann einfach auf localhost (127.0.0.1) umgeleitet und die anfragen landen so im nirvana, weshalb keine werbung angezeigt wird. praktischerweise stehen die urls der gepflegten listen auch als kommentar drin:

# http://adaway.org/hosts.txt
# http://hosts-file.net/ad_servers.asp
# http://pgl.yoyo.org/adservers/serverlist.php?hostformat=hosts&showintro=0&mimetype=plaintext
# http://winhelp2002.mvps.org/hosts.txt

diese laedt man sich einfach runter und fügt sie ans ende seiner eigenen hosts datei an. wo die hosts datei bei welchem betreibssystem liegt, sagt euch wikipedia. theoretisch funktioniert das nun schon. praktisch ist diese liste schon immer beim erscheinen veraltet und muss staendig aktualisiert und ergaenzt werden. deshalb sollte man sich fuer diese arbeit ein scriptchen bauen und regelmaessig laufen lassen. (todo fuer die zukunft: die hosts des dsl routers damit fuettern, damit man das nicht fuer jedes geraet im lan machen muss.)

wie schon erwaehnt wollte ich auch wissen, was da denn ueberhaupt ablaeuft, was wie und wie oft “geblockt”. dazu habe ich die eintraege in der hosts nicht auf 127.0.0.1 umgeleitet, sondern auf die ip eines webservers bei mir im lokalen netz. dieser liefert nur eine leere seite zurueck und schreibt mir die aufrufe in eine logdatei.

das erledigt ein kleines php skriptchen, welches ich als index.php abgespeichert habe:


damit auch alles “funktioniert”, was nach dem hostnamen in aufruf einer url steht und nicht vom webserver mit einem “not found” quittiert wird, werden alle anfragen per .htaccess datei auf die zuvor erstellt datei index.php umgeleitet. um zu verhindern, dass die index.php in einer schleife auf sich selbst umgeleitet wird, muss man sie “excluden”. selbiges macht man mit dem logfile, damit man es sich auch im browser anschauen kann.

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_URI} !index.php
RewriteCond %{REQUEST_URI} !adblock.log
RewriteRule .* index.php [R=307,L]

voila… 10 minuten arbeit mit testen. ein wenig finetuning kann man natuerlich noch machen. vielleicht poste ich nochmal was.

und was hats gebracht? beim morgendlichen stöbern in den news des tages, die man so bei ner tasse kaffe liest, wurden mir in 15 minuten ganze 358 (!!!!) werbeeinblendungen NICHT angezeigt. wenn man sich diese zahl anschaut – liebe webseitenbetreiber – da wundert ihr euch, dass menschen werbeblocker benutzen? so viel werbung kann man in 15 minuten gar nicht verarbeiten.

20140822_werbeblockerder focus online hats dann aber doch gemerkt, obwohl ich im browser keinen werbeblocker installiert habe. da muss ich nochmal ein bischen forschen, wie die das machen und wie man das umgehen kann.

eine idee fuer einen werbe blocker im browser waere doch, dass die werbung zwar geladen, aber nicht angezeigt wird. so muessten die bloeden webseitenbetreiber nicht mehr rumnoehlen, dass ihnen die werbeeinnahmen (von den einblendungen) floeten gehen und die besucher waeren gluecklich. die paar leute, die es auf der welt gibt, die wirklich werbung anklicken, haben und wollen sicher auch keinen werbeblocker.

to be continued… 🙂

wheezy, apache2, nscd und die startreihenfolge

in debian ist mittlerweile im header jedes init scriptes eine LSB section zu finden. damit koennen u.a. die abhaengigkeiten zwischen den verschiedenen diensten abgebildet werden.

ich hatte einen fall, in dem die user eines webservers in einer mydsql datenbank stehen und der start des apache nach einem reboot fehlschlaegt, wenn nscd noch nicht gestartet ist. in diesem falle sieht die quick and dirty loesung so aus, dass muss ein “nscd” ans ende der “Required-Start”-Zeile haengt… in der datei /etc/init.d/apache2 …also so:

(scrollen zum zeilenende)

#!/bin/sh
### BEGIN INIT INFO
# Provides:          apache2
# Required-Start:    $local_fs $remote_fs $network $syslog $named nscd
# Required-Stop:     $local_fs $remote_fs $network $syslog $named nscd
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# X-Interactive:     true
# Short-Description: Start/stop apache2 web server
### END INIT INFO

danach muss man noch diesen befehl ausfuehren:

update-rc.d apache2 defaults

und beim naechsten reboot ist alles gut 😉

apache autschn?

das bedeutet bestimmt nix gutes…

Bildschirmfoto 2013-06-14 um 10.00.37