08.24
Gerade ein sehr geiles Tool entdeckt, auch wenns ein Wenig spartanisch aussieht:
Ich bin nur mal gespannt wie´s reagiert, wenn von apt-get Abfragen verlangt werden?
Gerade ein sehr geiles Tool entdeckt, auch wenns ein Wenig spartanisch aussieht:
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:
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 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; }#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
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
Mir ist gerade durch Zufall aufgefallen, dass auf meinem privaten DNS Server die Queries stark angestiegen sind:
Die Anfragen kommen so gut wie alle von dieser IP: 91.202.63.129 und mit folgendem Query: query: . IN NS +
Ich konnte mir da erstmal keinen Reim drauf machen, also hab ich die IP erstmal mit iptables geblockt (iptables -D INPUT -s 91.202.63.129 -j DROP), und mich dann mal an die Google gemacht. Daraufhin habe ich folgendes gefunden:
It’s a forged request asking you to participate in a DDoS thats been going on since last Wedensday, it’s best if you firewall off your replies to those IP’s so you don’t participate in harming the innocent victims.
Quelle: http://groups.google.com/group/comp.protocols.dns.bind/browse_thread/thread/5cd9084a0a43abcd/b81aec0be38a886f
Nunja, so ganz schlau werde ich daraus nicht, mal sehen was die Googlesuche noch so hergibt. Dank IP-Tables ist jetzt aber erstmal Ruhe.
Nachtrag:
“The problem seems to kick in for DNS servers that arent rejecting the queries. Someone is channeling ye ‘ole smurfing methods.
They’re requesting a list of all DNS root servers. If the server don’t reject the query, a 17 byte query becomes a 50k response (or something like that) to the spoofed address.”
Das würde natürlich den Sinn erklären, wenn man mit einer gefälschten Adresse einen Nameserver anfragt, einen selbst die Anfrage nur einen 17byte Request kostet, aber der “Empfänger” der Abfrage mit einer 50k Müllantwort belastet wird.