RSS
 

Posts Tagged ‘server’

ERROR iptables -n -L INPUT | grep -q fail2ban-ssh returned 100

06 Jul

Und noch ein Eintrag aus der Rubrik “Fehlermeldungen verstehen” ;)

Nachdem ich einen neuen VServer mit ISPConfig3 aufgesetzt habe, habe ich mir zum ersten Mal genauer das fail2ban Logfile angesehen. fail2ban ist ein Tool das die Frequenz von Zugriffen auf den Server registriert und automatisch über die systemeigene Firewall mit iptables einzelne IP-Adressen sperrt wenn diese zu häufig zugreifen wollen. An sich eine schöne Erleichterung für den Sysadmin.

Nun aber zur Fehlermeldung:

ERROR iptables -n -L INPUT | grep -q fail2ban-ssh returned 100

Heißt so viel wie “iptables funktioniert nicht”. Ein einfacher Test gibt Aufschluss über den Hintergrund. Einfach in der Kommandozeile mal folgendes eingeben:

modprobe ip_tables

Wenn dann sowas hier kommt

FATAL: Could not load /lib/modules/2.6.36.4-vs2.3.0.36.39-netcup/modules.dep: No such file or directory

bedeutet das, dass iptables nicht geladen wurde und somit auch nicht zur Verfügung steht.

Wie man in der Fehlermeldung sieht, steht besagter Server bei Netcup. Hier soll es angeblich eine Möglichkeit geben dennoch auf iptables zuzugreifen. Ich werde das mal recherchieren und bei Erfolg hier nachtragen. Ansonsten scheint es aber üblich zu sein, dass man keinen Zugriff auf iptables auf einem VServer bekommt.

Weitere Quellen sagen jedoch ohnehin aus, dass fail2ban nicht unbedingt das beste Stück Software ist und gerne auch die Serversicherheit ein wenig runter schraubt. Ich kann das nicht bestätigen und lasse diese Aussage somit einfach mal im Raum stehen, würde mich aber über fachliche Kommentare dazu sehr freuen.

Meine Lösung:
Bisher hab ich noch keine. Ich werde mir mal ein hübsches Script überlegen, was die Zugriffe überwacht und mich dann entsprechend per Mail informiert oder sowas in der Richtung. Auch hier bin ich für jegliche Lösungsvorschläge dankbar.

[EDIT]
In den FAQ von Netcup steht, dass man den Support kontaktieren soll wenn man iptables freigeschaltet haben möchte. Dies habe ich eben getan und warte nun gespannt auf Antwort. Wär natürlich ne feine Sache wenn das klappen würde.

[EDIT 2]
Da hatte ich wohl was falsch verstanden. iptables steht prinzipiell nicht zur Verfügung. Netcup arbeitet aber bereits an einer eigenen API für das vservercontrollpanel. Dadurch wird es möglich sein, fail2ban direkt auf diese API zugreifen zu lassen.
Ein Kollege von mir hat sich jedoch die Arbeit gemacht und für die Übergangszeit ein Script geschrieben mit dem das jetzt schon ohne API funktioniert. Das Script gibts hier:
http://blog.n-durch-x.de/2011/07/fail2ban-auf-netcup-vservern/
Funktioniert bislang tadellos auf meinem Server. Somit klappts dann auch mit fail2ban ;)

 
4 Comments

Posted in Software

 

warning: database /etc/aliases.db is older than source file /etc/aliases

06 Jul

Wer diesen Fehler in seinen Error-Logs bekommt hat nicht wirklich ein Problem. Der Administrator des Servers oder irgendein Script haben die Datei /etc/aliases editiert. Damit die Änderungen aber systemweit übernommen werden, ist die Ausführung des folgenden Befehls von Nöten:

newaliases

Der Befehl gibt keine Rückmeldung wenn alles gut gelaufen ist. Und die Meldung sollte alsbald auch aus den Logfiles verschwunden sein.

 
No Comments

Posted in Software

 

HTTP-Head Serverinfos – Versionen ausblenden

14 Dez

Heute hatte ich im Rahmen einer TÜV-Prüfung inkl. Server-Check die Aufgabe, die bösen bösen Headerinformationen die ein Apache und PHP standardmäßig mitschicken wenn man den Header abfragt, zu deaktivieren. Nachdem ich selbst eine Weile danach gesucht hatte, wollte ich hier kurz das Ergebnis meiner Recherchen bekannt geben.

Nach der Änderung liefert der Server nur noch folgendes:
HTTP/1.1 200 OK
Date: Mon, 14 Dec 2009 17:41:23 GMT
Server: Apache
Connection: close
Content-Type: text/html; charset=UTF-8

Deaktivieren kann man das Ganze natürlich ganz einfach in den jeweiligen Configdateien. Für den Apache ist das die apache2.conf (bei Debian unter /etc/apache2/apache2.conf zu finden). Bei mir war es sogar in der Datei /etc/apache2/conf.d/security hinterlegt.

Hier ändert man einfach die beiden folgenden Parameter:

ServerTokens Prod

ServerSignature Off

Um jetzt auch noch das hübsche X-Powered-By von PHP zu deaktivieren geht man in die php.ini seiner Wahl. Bei mir unter Debian ist die Verantwortliche Datei hier zu finden:

/etc/php5/apache/php.ini

Hier sollte es die Option “expose_php” geben. Diese stellt man einfach auf “Off” und schon sind alle glücklich.

EDIT:
Ein guter Freund hat mich darauf aufmerksam gemacht, auch noch folgendes in der php.ini einzufügen:

; Add X-PHP-Originating-Script: that will include uid of the script followed by the filename
mail.add_x_header = Off

Offensichtlich werden da beim Mailversand Infos mitgeschickt die niemanden etwas angehen…
Jetzt sind wir wirklich glücklich ;)

 
2 Comments

Posted in Software