Fail2ban | SSH Absichern Teil 2

September 30, 2010 at 5:45 pm (IT) (, , , , , , )

Wie bereits angekündigt hier noch der zweite Teil zum Thema SSH-Sicherheit:

FAIL2BAN

Fail2Ban ist ein Dienst der Log-Files von anderen Diensten nach BruteForce Attacken durchforstet. Hat eine entdeckt wird die Angreifer IP mittels IP-Tables blockiert. Das tolle an FAIL2BAN ist das eine ganze Reihe von Diensten überwachen kann und mithilfe von RRDTool ist sogar eine grafische Auswertung der Ban Statistik möglich. Ausserdem ist es dazu in der Lage E-Mails an den Administrator zu verschicken. Heute werde ich nur auf die konfiguration der Überwachung des SSHD Dienstes eingehen.

Fail2Ban ist in für viele Distributionen als Package verfügbar:

http://www.fail2ban.org/wiki/index.php/Downloads

Unter Debian Lenny langt ein einfaches

apt-get install fail2ban

um Fail2Ban zu installieren. Als erstes sollte man die Konfigurationsdatei von Fail2Ban erstellen. Hierfür wird eine Kopie der mitgelieferten jail.conf angelegt:

cp /etc/init.d/fail2ban/jail.conf /etc/fail2ban/jail.local

Die Datei jail.local wird nun zur Konfiguration von Fail2Ban verwendet und hat Vorrang gegenüber der jail.conf.

Das Tolle ist das der SSHD-Dienst schon von vorneherein aktiviert ist, sodass man nur noch ein paar kleine Anpassungen in der jail.conf vornehmen muss:

ignoreip = 111.222.333.444 (Hier können bestimmte IP’s eingetragen auf die die Regeln von Fail2Ban nicht angewendet werden   sollen) 
bantime = 600
(Zeit in Sekunden die eine IP gebant ist)
maxretry = 3
(Anzahl der Wiederholung einer falschen Passwort eingabe bis Ban ausgeteilt wird)

Danach nocheinmal Fail2Ban mit /etc/init.d/fail2ban restart neustarten. Das Logfile von Fail2Ban findet ihr unter /var/log/fail2ban.log
Demnächst mehr zu Fail2Ban!

Permalink Schreibe einen Kommentar

SSH absichern Teil I

September 30, 2010 at 5:00 pm (IT) (, , , , , , )

SSH ist DAS protokoll für die sichere Administration von entfernten Unix/Linux rechnern. Leider gibt es jedoch genug „Script-Kiddys“ im Netz die immer wieder versuchen mittels Bruteforce in SSH-Systeme einzudringen. Das Problem ist hierbei das diese Bruteforce Attacken eine Menge Rechenleistung kosten, sodass der Server ständig Performance an die SSH-Authentifikation abgibt. Mithilfe der folgenden kleinen Tricks kann man seinen SSH-Zugang weitesgehend absichern und falls man sich für eine Blacklist entscheidet sogar die Performance kosten für die Abwehr von Bruteforce Attacken senken. Innerhalb der datei /etc/ssh/sshd_config wird die konfiguration des SSH-Servers vorgenommen weshalb die folgenden Optionen, sofern nicht anders beschrieben innerhalb dieser Datei vorgenommen werden. Ich gehe davon aus das bereits ein SSH User angelegt ist, der keine root Rechte hat. Ich habe den gleichen User auf dem Server angelegt mit dem ich auch unter meiner Workstation arbeite, weswegen ich im weiteren davon ausgehe das ihr ähnlich verfahrt. Desweiteren solltet ihr auch mit
cp /etc/ssh/sshd_config /etc/ssh/sshd_config_backup ein Backup der Orginal Datei anlegen;)

1. Kein Root Login zulassen

Wenn man die Option

PermitRootLogin no

setzt ist es nicht mehr möglich mithilfe des root Accounts eine SSH Verbindung zu dem Server aufzubauen. Das hat den Vorteil das ein Angreifer sich nicht sofort mit vollen Rechten im System bewegen kann.

2. Listen Port ändern

Der SSH-Server „horcht“ normalerweise den Port 22 auf Anfragen ab wesewegen die häufigsten Bruteforce Attacken auch auf eben diesen Port abzielen. Es ist jedoch möglich diesen zu ändern mithilfe der Option:

Port 12345

3. Nutzung von SSH Version 2

Mithilfe der Option

Protocol 2

zwingt man den SSH Server die Verbindungen nur in der Version 2 aufzubauen. So umgeht man die Schwächen von Version 1. Selbstverständlich muss der Client zwingenderweise auch SSH 2 beherschen.

4. Einschräkung der User Zugänge

Da ja auf den meisten Unix/Linux Systemen mehre Benutzer angelegt sind macht es durchaus sinn bestimmte User und/oder Gruppen vom SSH Zugang auszusperren. Dies ist mithilfe der folgenden Optionen möglich:

AllowUsers USERNAME
AllowGroups GROUPNAME
DenyUsers USERNAME
DenyGroups GROUPNAME

allow erlaubt Usern und Gruppen das Verbinden deny verbietet es.

5. Authentifizierung ändern

Um die maximale Sicherheit mit SSH zu erlangen ist es notwendig die Authentifizierung von SSH auf PubKeyAuthentication zu ändern.

PubkeyAuthentication yes

Jetzt sollten wir den Speicherort für die keyfiles definieren:

AuthorizedKeysFile %h/.ssh/authorized_keys

Damit werden alle keyfiles des jeweiligen Benutzers in ~/.ssh/authorized_keys gespeichert.

Mit /etc/init.d/sshd restart starten wir den SSH Server neu. Als nächstes sollten wir auf dem Client den Privaten Schlüssel für den Zugriff generieren:

ssh-keygen -t rsa

ich empfehle hier unbedingt eine Passphrase anzugeben. Jetzt müssen wir den öffentlichen Schlüssel auf den Server mittels ssh-copy-id kopieren:

ssh-copy-id -i ~/.ssh/id_rsa.pub „-p 12345 user@server“

Nach einem weiteren restart des SSH Servers wird die Authentifizierung mittels Pub- und Privatkey  durchgeführt.

5. Anmeldung via Passwort verbieten

Bis jetzt war es noch weiterhin möglich sich via Passwort an dem Server anzumelden. Dies sollten wir nun noch deaktivieren:

PasswordAuthentication no
UsePAM no

Damit wäre unser SSH-Server erstmal gut abgesichert, sodass Script-Kiddys keine Chance mehr haben. Im nächsten Teil dieser Anleitung werde ich erklären wie es möglich ist mittels fail2ban Bruteforce Attacken erfolgreich abzublocken.

Permalink Schreibe einen Kommentar