Dit kan door de volgende regel op te nemen in de configuratie:

CustomLog "|bin/rotatelogs /var/logs/access_log 5M" common

Dit specifieke voorbeeld zorgt ervoor dat de access_log geroteerd wordt op het moment dat deze 5mb groot is. Het mooie is, dat Apache gewoon door blijft draaien, de website blijft dus normaal bereikbaar! Belangrijk wel is dat het pad naar de logfile een absoluut pad moet zijn.

Iptables heeft hiervoor een module genaamd ipt_recent. Hiermee is het mogelijk om brute force aanvallen te blokkeren. De volgende commando’s zorgen voor alles:

# iptables --new-chain SSHSCAN
# iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSHSCAN
# iptables -A SSHSCAN -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
# iptables -A SSHSCAN -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 3 --rttl --name SSH -j DROP

Via het commando cat /proc/net/ipt_recent/SSH kunnen we zien wat er zoal wordt tegengehouden.

Onlangs kwam ik per toeval de term SNI tegen (Server Name Indication). Deze uitbreiding van TLS zorgt er voor dat SSL voor virtuele hosts mogelijk is door de host mee te sturen als onderdeel van het TLS pakket. Dit is vastgelegd in de RFC 3546.

Overigens staat dit los van TLS v1.1, dit is vastgelegd in RFC 2817. Voor SNI heeft Microsoft duidelijk gesteld dat het vanaf beta 2 in IE7 is opgenomen. Het complete lijstje met browsers die ondersteuning hebben voor SNI is:

• Firefox 2.0 en hoger
• IE 7 en hoger
• Opera 8.0 en hoger

Is alleen nog de vraag hoe de webservers hier mee omgaan. Voor Apache is er een nog experimentele uitbreiding genaamd mod_gnutls. In Lighttpd is vanaf versie 1.4 – met een kleine aanpassing – ondersteuning voor SNI aanwezig.

Allereerst moeten de oude statistieken verwijderd worden. Dit kan eenvoudig door het betreffende awstatsmmyyyy.[config].txt te verwijderen. Daarna dienen de statistieken voor september opnieuw opgebouwd te worden. Dit kan met een paar commando’s:

$ ./awstats.pl -update -config=www.zomaarroland.nl -LogFile=~/temp/log.txt > /dev/null
$ ./awstats_buildstaticpages.pl -awstatsprog=./awstats.pl -config=www.breinstein.tk -year=2008 -month=09 -dir=/var/www/webstats/200809 > /dev/null

De user-agent string van Chrome is als volgt:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.13 (KHTML, like Gecko) Chrome/0.X.Y.Z Safari/525.13.

Volgende stappen zijn nodig om Awstats aan te passen:

• icoon voor Chrome – download http://www.google.com/chrome/intl/en/images/chrome.png naar $AWSTATS/icon/browser/chrome.png
• aanpassingen in het bestand $AWSTATS/lib/browsers.pm

Open het bestand browssers.pm en zoek naar de tekst:

@BrowsersSearchIDOrder = (

Zoek vanaf dit punt naar de string

'safari',

En voeg voor deze regel een nieuwe regel toe:

'chrome',

Zoek vervolgens naar de tekst:

%BrowsersHashIDLib = (
# Common web browsers text

En voeg direct hierna een nieuwe regel toe:

'chrome','Chrome',

Zoek dan naar de tekst:

%BrowsersHashIcon = (
# Standard web browsers

En voeg direct hierna de regel toe:

'chrome','chrome',

Met deze aanpassingen is Awstats in staat om Chrome als browser te herkennen. Uiteraard geldt dit alleen voor de statistieken die vanaf nu worden aangemaakt.

Een oorzaak voor dit probleem heb ik niet kunnen vinden. Het modem krijgt een adsl signaal, de router krijgt een ip van het modem en alle pc’s krijgen een ip van de router. Ergens tussen de router en het modem gaat het mis. Voor mijn gevoel ligt het aan Tomato, want als ik die er tussen uithaal werkt het vlekkeloos. Het blijft alleen wel vreemd dat het een hele tijd goed gewerkt heeft en vanavond opeens niet meer.

Maar goed, de Linksys gaat voorlopig de kast in tot er wat meer tijd is om het probleem goed te onderzoeken.

roland@silvia:~/mozilla3$ grep -Rn htdocs .
./netwerk/streamconv/converters/parse-ftp/U-HellSoft.out:1:07-01-2002  11:49:00       <DIR>          htdocs
./netwerk/streamconv/converters/parse-ftp/U-HellSoft.in:10:d[RWCEMFA]  1 cyp           512 Jul 01 11:49 htdocs
./security/nss/cmd/certcgi/HOWTO.txt:64:assumed to be located in /var/www/htdocs, and the cgi-bin directory in

Terwijl ik dit schrijf bedenk ik me dat htdocs een standaard directory is. Nu heb ik in Apache2 dus overal wel een DocumentRoot ingesteld, ook voor de default, maar alleen in de configuratiebestanden van de virtual hosts. Er is nog een ander bestand: httpd.conf, nog een overblijfsel van Apache 1.3. Die is bij mij helemaal leeg. Bij wijze van test heb ik hier eens de DocumentRoot ingevuld met de waarde voor een directory die bestaat. En wat schetst mijn verbazing, de foutmelding blijft weg!

Nu is de vraag natuurlijk: is dit een tekortkoming van Apache of van Firefox? Echt gelukkig ben ik hier ook niet mee, want eigenlijk weet ik nog steeds niet waarom deze foutmelding verschijnt.

[Sun Jun 15 22:55:47 2008] [error] [client 127.0.0.1] File does not exist: /htdocs

In eerste instantie dacht ik dat in de configuratie van Apache een verkeerde verwijzing stond, of dat er ergens op de server een script een verkeerde verwijzing gebruikte. Eigelijk per toeval kwam ik er achter dat het niet aan de server, maar aan de browser ligt!

De foutmelding doet zich namelijk alleen voor op een phpBB3-forum met als browser Firefox, zowel versie 2.0.0.14 als 3.0rc3. Nu nog onderzoeken hoe het kan dat deze fout zich met Firefox voordoet en of het inderdaad alleen aan de browser ligt. Misschien is het ook wel een samenspel met de server waardoor dit zich voordoet?

Echter, blijft de vraag waarom de niet bestaande subdomeinen werden doorverwezen naar de default pagina. Dit heeft te maken met de dns. Voor de twee bewuste sites was in de dns een record opgenomen voor *.domein.nl. Inderdaad, een wildcard, in het verleden ooit ingesteld en verder nooit aandacht aan besteed. Omdat het nergens voor nodig is heb ik de entries verwijderd. Als alle dns servers weer up to date zijn is dit probleem dus ook weer uit de wereld!