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

[ESX 4]SSH für Root

Juli 23, 2009 at 4:17 pm (ESX) (, , , , , , , , )

da vmwares esx server in der standard konfiguration keinen root login via ssh erlaubt habe ich hier ein kleines workaround für euch:

ihr müsst als erstes die datei sshd_config mit einem texteditor wie z.B. nano bearbeiten:

nano /etc/ssh/sshd_config

dort müsst ihr die zeile

PermitRootLogin no

auf PermitRootLogin yes stellen. damit währe gewährleistet das ihr euch als root via ssh auf dem server anmelden könnt. unter umständen müsst ihr jedoch noch die firewall so umkonfigurieren, dass ssh bzw sshd zugelassen wird. dies erreicht ihr mit folgender eingabe:

esxcfg-firewall -e sshServer

esxcfg-firewall -e sshClient

viel spaß mit ssh und sftp:)

Permalink Schreibe einen Kommentar

X11-Forwarding via SSH

Mai 19, 2009 at 7:36 am (IT) (, , , , , , , , )

eigentlich ist die ganze geschichte ja keinen eigenen eintrag wert aber ich musste trotzdem einige recherchen anstellen um zu erfahren das der client auch X11-Forwarding erlauben muss. nichtmal im ubuntuusers.de wiki wird das erwähnt, deswegen auch hier ein kleiner eintrag über das richtige forwarding von X11 über ssh.

ich gehe davon aus das der ssh server unter ubuntu 8.04 läuft und der ssh client unter 9.04. jedoch stelle ich einfach mal die vermutung auf, dass es unter anderen distribution ähnlich funktioniert.

als erstes muessen wir das paket xauth auf dem server installieren:

sudo apt-get install xauth

jetzt muessen wir die datei sshd_config bearbeiten:

sudo nano /etc/ssh/sshd_config

dort gibt es die zeile:

X11Forwarding no

hier muessen wir einfach das no mit einem yes tauschen. nachdem wir das getan haben starten wir den ssh server nochmal neu:

sudo /etc/init.d/ssh restart

damit wäre die konfiguration am server abgeschlossen. als nächstes sollten wir auch auf dem client das X11 forwarding zu aktivieren. dafür muessen wir die datei ssh_config editieren:

sudo nano /etc/ssh/ssh_config

dort gibt es unter dem abschnitt „Host *“ die zeile „# ForwardX11 yes“. löscht einfach die raute und speichert die datei ab. nachdem das erledigt ist wird nur noch der ssh client neu gestaret mit sudo /etc/init.d/ssh restart.

jetzt ist es möglich eine ssh session mit X11 forwarding aufzubauen, dafür muss beim starten von ssh einfach nur der parameter X mitgegeben werden:

ssh -X user@host

Permalink 3 Kommentare