the it-madness

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

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.

Hier zum lesen erstmal eine Nachricht der DENIC auf golem.de:

Liebe Kolleginnen und Kollegen,

derzeit kommt es zu einem Fehlverhalten bei einigen .de-Nameservern. Wir sind aktuell dabei das Problem zu qualifizieren und werden Euch mit Statusmeldungen weiter informieren.

Business Services

DENIC eG
Kaiserstraße 75-77
60329 Frankfurt am Main
GERMANY

Liebe Grüße,

Cemil Degirmenci
Wavecon GmbH

und folgendes gabs bei Domainfactory zu lesen:

Derzeit lassen sich viele Domains die auf .de enden nicht auflösen. Unsere eigenen Nameserver funktionieren jedoch. Wir gehen derzeit von einem Problem auf Seiten des Betreibers der Top-Level-Domain “.de” aus und halten Sie an dieser Stelle auf dem Laufenden.

[Update 12.05.2010 14:13]
Der Verdacht hat sich erhärtet. Das Problem liegt also nicht in unserem Einflussbereich, wir hoffen auf eine schnelle Problemlösung seitens der DENIC und halten Sie an dieser Stelle auf dem Laufenden.

Aktuell liefern 4 der 6 DENIC-Nameserver-IPs auf Anfragen eine Antwort die signalisiert, dass es die Domain nicht gibt. (NXDOMAIN).

[Update 12.05.2010 14:21]
Aktuell sind alle 6 DENIC-Nameserver-IPs nicht mehr erreichbar. Das DENIC ist über das Problem informiert und arbeitet an der Lösung.

[Update 12.05.2010 14:49]
Wir haben gegen 14:35 unsere Mailserver angehalten um die Anzahl der Bounces (Nicht-Zustellbarkeits-Benachrichtigungen) zu minimieren. Derzeit nehmen wir auf unseren Postausgangsservern keine E-Mails an. Wir werden E-Mails erneut ausliefern sobald die .de-TLD wieder ordnungsgemäß funktioniert.

Derzeit sind wieder 2 von 6 DENIC-Nameservern aktiv. Die restlichen 4 Nameserver liefern aber immernoch fälschlicherweise “Domain nicht gefunden” aus.

Mehr muss man wohl nicht dazu sagen Ich habe auch erstmal alle empfangenden Mailgates (Spamschutz etc) angehalten, um die Bouces so gering wie möglich zu halten. Es wird zwar eh mit 450 (temporärer Fehler) abgewiesen wenn die Domain nicht gefunden wird, aber man weiss ja nie…

EDIT:  zumindest laut der Statusseite von domainfactory funktionieren wieder alle deutschen DNS-Rootserver. Da bin ich ja mal gespannt. Durch das caching der negativen Antworten kann es aber noch einige Zeit dauern bis wieder alles rund läuft.

Gestern hab ich´s dann doch gewagt, auf meinem Zweitrechner von Kubuntu 9.xx auf 10.04 LTS upzudaten. Vorher natürlich brav ein Backup gemacht (irgendwie steh´ ich auf Acronis, grins), und schon gings los mit den Problemen:

Nach dem Upgrade per GUI gabs natürlich auch einen neuen Kernel, nur, nach einem Neustart war´s dann erstmal vorbei mit KDE, weil ich gleich nach dem Start wieder auf der Konsole gelandet bin. Kein Problem soweit dachte ich mir, wie immer einfach mit dem NVidia Treiberinstaller drüberbügeln… Denkste: Er konnte den das Kernelmodul für den Treiber nicht kompilieren, und warf mir einen Haufen Fehlermeldungen um die Ohren. Nach etwas googeln bin ich dann aber doch noch auf die Lösung gekommen:

Nach dem Update auf 10.04 LTS wurden Module  automatisch geladen, welche den NVidia Treiber daran gehindert haben das Modul nvidia.ko zu erstellen. Abhilfe schafft nur, wenn man in der /etc/modprobe.d/blacklist.conf folgende Module blacklisted:

• blacklist vga16fb
• blacklist nouveau
• blacklist rivafb
• blacklist nvidiafb
• blacklist rivatv

Dann noch ein gemütliches “sudo apt-get –purge remove nvidia-*”.

Nach einem Neustart konnte ich dann den Treiberinstaller erneut anwerfen, welcher sich nur noch beschwerte dass er den alten Treiber nicht sauber deinstallieren kann, lief aber problemlos durch. Ein weiterer Neustart brachte wieder das gewohnte KDE zum Vorschein.

Bis auf eine neue Farbe der Taskleiste, und einen Haufen Pakete die er entfernt hat konnte ich aber noch keine grossen Vorteile von 10.04 feststellen

PS: Wer immer noch Probleme hat, das könnte daran liegen dass nouveau irgendwie noch geladen wird. Einfach rebooten, in Grub den Recovery Modus auswählen und “root shell”, hier ein “init 3″, und schon sollte es gehen den Treiber zu installieren. Hier geklapt: click me