the it-madness

via http://strcat.de/blog/

Gerade ein sehr geiles Tool entdeckt, auch wenns ein Wenig spartanisch aussieht:

http://www.robhost.de/updian/

Ich bin nur mal gespannt wie´s reagiert, wenn von apt-get Abfragen verlangt werden?

Ein etwas seltsames Problem hatte ich vor kurzem bei einem Kundenprojekt:

Plötzlich schmeisst NGINX nur noch “Bad Gateway” Fehlermeldungen, der Apache (der eigentlich nur eine Drupal-Präsenz ausliefern soll) müllt das Logfile mit “segmentation faults” voll, und keiner weiss warum, bzw. wills gewesen sein. Nach ewigen hin und her stellte sich dann heraus, dass ein Designer CSS Dateien hochgeladen hatte, welche aber gar kein CSS sondern seltsames HTML enthielten. Der Drupal CSS Preprocessor dachte sich darauf hin dass er einfach ohne Fehlermeldung seinen Dienst quittieren muss… warum das Ganze in Segfaults endete werde ich warsch. niemals rausfinden…

Oha, heute meine erste abuse@ eMail bekommen…

Dumm nur dass auf diesem Server nur meine Webhosting Geschichten laufen, klassicher LAMP, nix p2p… wer lachen will liest weiter:

(continue reading…)

Echt praktisch, hab ich grad gebraucht, und kann ich mir sicher eh nicht merken:

python -m CGIHTTPServer #(für Python ab Version 2.4)
python -c “from SimpleHTTPServer import test; test()” #(vor V2.3)

Listet alle Dateien im aktuellen Verzeichnis auf, der Webserver ist unter IP:8000 erreichbar.

Vim (Vi improoved) kann sehr schönes syntax highlighting, einfach in der ~/.vimrc folgende Einträge machen:

syntax on
set background=dark

Das stellt das sh ein, und optimiert auf dunklen Hintergrund, bei mir immer wichtig da ich meistens in schwarzen Terminals arbeite.

Leider gibt nginx in der Standardconfig einen Fehler aus, wenn man probiert ein Verzeichnis wie folgt aufzurufen: http://www.adresse.de/forum. Ohne Trailling Slash kommt eine wirre Weiterleitung… Hier die Lösung, einfach in den “server {}” Block einfügen:

#code block added for trailing slash issue solving

server_name_in_redirect off;

optimize_server_names off;

dav_methods PUT DELETE MKCOL COPY MOVE;

dav_access group:rw all:r;

create_full_put_path on;

if (-d $request_filename) { rewrite ^(.*[^/])$ $1/ break; }

if ($request_method = MKCOL) { rewrite ^(.*[^/])$ $1/ break; }

#code block added for trailing slash issue solvingserver_name_in_redirect off;optimize_server_names off;dav_methods PUT DELETE MKCOL COPY MOVE;dav_access group:rw all:r;create_full_put_path on;if (-d $request_filename) { rewrite ^(.*[^/])$ $1/ break; }if ($request_method = MKCOL) { rewrite ^(.*[^/])$ $1/ break; }

#If Your problem will not solved from above code then use following code.

#here we are adding trailing slash end of Url

#if ($request_uri ~* “^[\w\-\/]+[^\/?]$”) {rewrite ^(.*)$ $scheme://$host$1/ permanent;}

Nach den ständigen DNS Query Versuchen (siehe einer der letzten Posts) war nach der Installation von fail2ban erstmal Ruhe. Die DNS Server laufen aber (weil eh nicht viel zu tun) virtuell als OpenVZ vServer, und hier gibts mit fail2ban auch gleich das erste Problem:

Unfortunately the first start of the new service turned out to blow up the memory usage by about 100 MB which is unacceptable regarding the tight resources of my virtual private server. As I found out, others had similar experience and switched to DenyHosts due to this issue. My experience with setting up Trac two weeks ago taught me that a Python application (like fain2ban) might consume a lot of memory only because of the relatively oversized default stack size on Linux.

The means to reduce the default stack size in Linux are widely known to be the limits.conf file and the ulimit command. But how to use those two in my situation? The solution turns out to be a one-liner on Debian Lenny: All I had to do was to append the ulimit command to my /etc/default/fail2ban file.

Hier gefunden: CLICK ME

Die Lösung ist recht einfach: in der /etc/default/fail2ban folgenden Eintrag machen, und den Dienst neu starten:

ulimit -s 256

Der Speicherverbrauch ist wirklich um den Faktor 10 zurückgegangen

Gerade so auf den Schreibtisch bekommen. Der ein oder andere wird schmunzeln müssen

Nachdem es immer mehr Hosts wurden, welche mit gefakten IP-Adressen meinen DNS Server genervt haben, bin ich irgendwie nicht mehr mit dem manuellen blocken per iptables nachgekommen. Ich habe deshalb auf dem DNS Server fail2ban installiert, welches das Logfile des Nameservers überwacht, und bei einer Überschreitung (der vorher eingestellten) Versuche per iptables automatisch für eine gewisse Zeit blockt, und mir eine eMail mit der IP und dem Whois-Query schickt:

fail2ban kann aber noch mehr: Es können für alle möglichen Dienste die Logfiles geprüft werden, um z.B. auch fehlgeschlagene SSH oder FTP Logins zu erkennen, und auch hier zu blocken.

Zum Nachlesen gibts hier was:  http://www.debian-administration.org/article/Blocking_a_DNS_DDOS_using_the_fail2ban_package