gestern Nacht habe ich einen per Luks + LVM verschlüsselten Dedi aufgesetzt. Dabei wird das System so konfiguriert, dass vor dem Boot Dropbear (SSH-Server) gestartet wird und man dann das Passwort zum Entschlüsseln der Festplatte eingeben kann.

Die automatisch erstellen SSH-Keys von Dropbear sind jedoch nicht passwortgeschützt. Dies lässt sich aber ganz einfach ändern.

Existiert beim ersten Ausführen von

update-initramfs -u

die Datei „/etc/initramfs-tools/root/.ssh/authorized_keys“ noch nicht, so werden einen Reihe von SSH-Keys durch DropBear erzeugt. Diese sind aber leider nicht mit einem Passwort versehen und außerdem nur 1024 bit stark.

Möchte man nun nachträglich ein Passwort setzen, so ruft man einfach ssh-keygen auf:

ssh-keygen -p -f /etc/initramfs-tools/root/.ssh/id_rsa

Man wird nun nach einem Passwort gefragt. Fertig :)

~ Sebastian

Honeypot – Virtuelle Umgebung

Kippo arbeitet dabei in einer virtuellen Umgebung in der kaum Befehle ausführbar sind. Genauer gesagt, führen Kommands wie „mount“, „dmesg“ usw. nur zur Ausgabe eines lustigen Satzes. Der einzige Befehl, welcher „korrekt“ simuliert wird „wget“. (Es ist nicht wget, sondern eine Nachimplementierung in Python) Alle vom Angreifer heruntergeladenen Dateien werden in einem gesonderten Verzeichnis gesammelt, sodass man sich diese später genau anschauen kann. Versucht der Angreifer eine heruntergeladene Datei auszuführen, passiert nichts und er bekommt nur einen lustigen Satz zu lesen.

Alle Befehle, welche vom Angreifer ausgeführt werden, werden in einer Logdatei gespeichert, welche man sich später beliebig oft anschauen kann. Das sieht dann in etwa so aus:

Die Installation von Kippo

Das ganze Projekt basiert u.a. auf Python. Es müssen folgende Pakete installiert werden:

> sudo apt-get install git build-essential python-dev libmysqlclient-dev python-virtualenv python-pip unzip

Als nächstes legen wir einen unprivilegierten Benutzer für Kippo an:

> sudo useradd -m -s /bin/bash kippo
> sudo su kippo

Der nächste Schritt besteht darin, eine virtuelle Umgebung zu erstellen und in diese hineinzuwechseln:

> virtualenv env
> . ./env/bin/activate

In dieser virtuellen Umgebung können wir dann noch weitere Python-Pakete installieren:

> pip install twisted
> pip install pyasn1
> pip install pycrypto

Anschließend loggen wir uns aus der virtuellen Umgebung aus und klonen das Kippo-Respository:

> deactivate
> git clone https://github.com/desaster/kippo.git
> cd kippo

Damit ist die Installation von Kippo abgeschlossen.

Die Konfiguration

Kippo konfigurieren

Als nächstes muss man die Kippo noch etwas konfigurieren. Das Projekt liefert eine Basiskonfiguration mit, die man übernehmen kann:

> cp kippo.cfg.dist kippo.cfg
> vim kippo.cfg

Folgende Zeilen sollte man anpassen:

• ssh_port = 22222 (Einen Port >1024 auswählen)
• hostname (Einen passenden Hostnamen festlegen)
• textlog (Beide Zeilen auskommentieren)

Die Standardlogindaten sind folgende:

• root:12345

Weitere Passwörter hinzufügen

Ich habe meinem Honeypot noch 10.000 weitere Passwörter hinzugefügt:

wget http://xato.net/files/10k%20most%20common.zip
unzip 10k\ most\ common.zip
rm 10k\ most\ common.zip
cat 10k\ most\ common.txt | while read pw; do echo "root:0:$pw" >> data/userdb.txt done

Weitere Benutzer kann man entsprechend hinzufügen. Einfach „root“ durch den gewünschten Benutzernamen ersetzen.

Dateisystem aktualisieren

Optional kann man noch das virtuelle Dateisystem aktualisieren. Dazu muss man sich Rootrechte besorgen (am besten den Benutzer kippo vorher ausloggen) und ein Script ausführen:

exit
sudo su 
cd /home/kippo/kippo
mv fs.pickle fs.pickle.bak
./utils/createfs.py | tee -a fs.pickle
chown kippo:kippo fs.pickle
exit

SSH Port anpassen

Damit Kippo später den SSH-Server spielen kann, müssen wir den eigentlichen SSH-Server auf einen anderen Port umsiedeln. Dazu bearbeitet man am Besten die /etc/ssh/sshd_config und setzt dort den Port z.B. auf „122“.

sed -i -e "s/Port 22/Port 122/g" /etc/ssh/sshd_config
sudo /etc/init.d/ssh restart

Wichtig: Nicht vergessen in der Firewall den neuen Port freizuschalten!

Wenn man sich zum Server verbinden möchte, dann muss man dem SSH-Programm mit dem Switch „-p“ mitteilen, zu welchem Port es gehen soll:

ssh -p 122 user@host

Port-Forwarding

Da Kippo auf dem Port „22222“ lauscht, müssen wir einen Portforward mittels Iptables einrichten.

sudo iptables -t nat -A PREROUTING -p tcp --dport 22 -j REDIRECT --to-port 22222

Wir brauchen diese Regel, da unprivilegierte Nutzer nur Ports >1024 belegen dürfen. Wir möchten Kippo natürlich nicht mit Rootrechten laufen lassen ;)

Kippo starten

Es gibt zwei Möglichkeiten Kippo zu starten. Allgemein kann es ein paar Sekunden dauern, bis Kippo hochgefahren ist.

Im Vordergrund

Man aktiviert die virtuelle Umgebung und führt dann Kippo aus.

> . ./env/bin/activate
(env)$ twistd -n -y kippo/kippo.tac

Diese Variante ist gut zum Debuggen.

Im Hintergrund

Dazu ruft man einfach die „start.sh“ auf und Übergibt den Pfad zur virtuellen Umgebung:

~/kippo> . ../env/bin/activate
~/kippo>./start.sh ../env

Logs anschauen

Zum Anschauen der Hackangriffe, sucht man erstmal die verschiedenen Logs heraus:

kippo@host:~/kippo$ ls log/tty/
20141016-215452-5117.log 20141017-154123-1028.log 20141017-154811-967.log 20141017-161823-1127.log

Nun ruft man das Playback-Tool auf:

./utils/playlog.py log/tty/20141016-215452-5117.log

Fazit

Ich werde den Honeypot mal eine Weile laufen lassen und falls interessante Ergebnisse hängen bleiben, dann werde ich darüber natürlich bloggen.

~ Sebastian

in diesem Blogpost geht es um folgendes Problem: Ein Freund von mir brauchte etwas Speicherplatz auf einem Server. Per SSHFS wollte ich ihm diesen zur Verfügung stellen, jedoch ohne ihm gleichzeitig Shellzugriff auf den Server geben zu müssen.

Die Lösung

Das gewünschte Problem lässt sich jedoch ganz einfach lösen.

Man vergewissert sich zunächst, dass man in der /etc/ssh/sshd_config folgende Zeilen stehen hat:

Subsystem sftp /usr/lib/openssh/sftp-server

Der Pfad kann gegebenenfalls abweichen. Nichtsdestotrotz kopiert man sich die Pfadangabe und fügt diesen als valide Shell hinzu:

sudo su
echo '/usr/lib/openssh/sftp-server' >> /etc/shells

Wenn man danach für seinen Freund einen neuen Benutzer anlegt, so gibt man einfach sftp-server als die Shell an:

sudo useradd -m -s /usr/lib/openssh/sftp-server sshfsacc

Nun wird statt der eigentlichen Shell das SFTP-Programm ausgeführt.  Der Benutzer kann also SSHFS nutzen, jedoch keine anderen SHELL-Kommandos ausführen.

~Sebastian

ich hab in letzter Zeit doch etwas häufiger eine nette Email von Fail2Ban bezüglich dem SSH-Port erhalten. Dabei kam es u.a. vor, dass alle 10 Minuten derselbe Angreifer gebannt wurde. Durch einen kleinen Fehler bei den Kommentaren in der Konfigurationsdatei wurde die falsche Bantime verwendet.

Es gibt nämlich 2 verschiedene Kommentarzeichen in der Fail2ban-Konfigurationsdatei.

Einmal das einfache Rautezeichen:

#Ich bin eine Kommentarzeile

Dieses kommentiert eine ganze Zeile aus, egal wo es in dieser steht. Zum Beispiel ist die folgende Zeile ebenfalls ein Kommentar:

Das ist doch komisch! # Warum nicht?

Da ich mit großen Zahlen nicht unbedingt arbeiten kann, sah die BanTime Einstellung bei mir so aus:

bantime  = 86400 #1 Tag

Das führt leider dazu, das Fail2Ban diese Zeile ignoriert und daher seine 10 minütige bantime nutzt. Hätte man mal ins /var/log/fail2ban.log geschaut wäre das einem auch aufgefallen…

2014-04-10 12:59:02,036 fail2ban.filter [25385]: INFO    Set maxRetry = 1
2014-04-10 12:59:02,037 fail2ban.filter [25385]: INFO    Set findtime = 600
2014-04-10 12:59:02,038 fail2ban.actions[25385]: INFO    Set banTime = 600
2014-04-10 12:59:02,132 fail2ban.jail   [25385]: INFO    Jail 'ssh' started

Richtig lautet es daher so hier:

bantime  = 86400 ;1 Tag

Das Semikolon ist das Kommentarzeichen, welches ab Erscheinen den Rest der Zeile auskommentiert. Also das, was man eigentlich vom „#“-Zeichen erwartet hätte.

Nun ja, jetzt sind wir schlauer :)

~Sebastian

Man muss lediglich zwei Zeilen in seine ~/.ssh/config eintragen:

    ServerAliveInterval 150
    ServerAliveCountMax 2

Der erste Parameter weist den SSH-Client an die Verbindung nach 150 Sekunden zu „erneuern“, um dem Timeout zu entgehen. Das wird dann maximal 2 Mal (zweiter Parameter) probiert. Scheitern diese zwei Versuche, so wird die Verbindung geschlossen.

~ Sebastian