*Arrgh* Server gehackt: Wie gehts weiter?

[frankieboy]

Hallo Debs,

wider besseren Wissens habe ich auf meinem Server den Root-Zugang mit SSH erlaubt. Meiner naiven Einschätzung nach würde schon nichts passieren. Ist aber jetzt doch, der Server ist gehackt ;-( : Ganz konkret hat der Hacker eine Benutzer angelegt, im Benutzer-Verzeichnis eine Web-Site hinterlegt, den Mail-Server als Spam-Schleuder benutzt und dafür auch auf die MySql-Datenbank zugegriffen. Mehrere Hundert Ausgangs-Mails pro Minute haben das System schließlich lahm gelegt. Erst dadurch, daß nichts mehr ging, ist mir der Hacker-Angriff überhaupt erst aufgefallen.

Als erste Sofortmaßnahme habe ich den Mail-Server gestoppt und dann einen unmittelbaren Root-SSH-Zugriff untersagt. Dann habe ich noch einen neuen Benutzer angelegt, der sich jetzt als einziger mit SSH einloggen und dann mit "su" als Root weiterarbeiten darf. Dann habe ich noch den SSH-Port (> 1250) und natürlich das Root-Paßwort geändert.

Fürs erste scheinen die angerichteten Sauerreien behoben und mögliche Zugänge besser gesichert. Natürlich weiß ich nicht, was z.B. in den mehreren Tausend-Datenbankeinträgen verbrochen wurde. Nicht augeschlossen sind z.B. böswillige Änderungen von Einträgen. Ich kann das auch unmöglich alles kontrollieren ;-(

Wichtig ist mir, daß diese Strolche nicht weiterhin auf dem Server rumhacken und dafür würde ich mich über ein paar Ratschläge von Euch freuen.

1. Meine größte Befürchtung ist, daß noch irgendwelche Dateien/Programme auf dem Rechner hinterlegt sind, die durch "welchen-Auslöser-auch-immer" aktiviert werden und schlimmstenfalls die neuen Benutzer, Ports und Paßwörter auslesen und an die Hacker übermitteln. Dann wären alle Rettungsversuche umsonst. Muß ich davor Angst haben? Gibt es eine Möglichkeit, solche "Trojaner"/"U-Boote" aufzuspüren? Wie könnte ich ggf. danach suchen?

2. Welche weiteren Möglichkeiten habe ich, das System vor Einbrechern abzuschotten? Meine bisher ergriffenen Maßnahmen sind im zweiten Absatz notiert. Jedenfalls bin ich bin jetzt von der "Es-wird-schon-nichts-passieren"-Mentalität geheilt.

3. Und dann habe ich in Folge des jetzt verbotenen Root-Login noch ein ganz praktisches Problem: Bisher habe ich sämtliche Dateien immer mit "gftp" und Root/SSH hin- und her geschaufelt. Das ist bequem, geht jetzt aber ja nicht mehr. Ich kann mich zwar mit der der neuen Benutzerkennung via "gftp" und "ssh" einloggen, müßte dann aber als "Root" weitermachen. Gibt es eine Möglichkeit, "gftp" zum Benutzerwechsel zu überreden?

Viele Grüße sendet ein geschockter

Frank Dell

[nepos]

1. Meine größte Befürchtung ist, daß noch irgendwelche Dateien/Programme auf dem Rechner hinterlegt sind, die durch "welchen-Auslöser-auch-immer" aktiviert werden und schlimmstenfalls die neuen Benutzer, Ports und Paßwörter auslesen und an die Hacker übermitteln. Dann wären alle Rettungsversuche umsonst. Muß ich davor Angst haben? Gibt es eine Möglichkeit, solche "Trojaner"/"U-Boote" aufzuspüren? Wie könnte ich ggf. danach suchen?

rkhunter und chkrootkit wären zwei Tools, die für sowas gedacht sind. Allerdings wäre die sicherste Variante, den Server komplett neu aufzusetzen, denn auch die beiden genannten Tools sind nicht 100% sicher.

2. Welche weiteren Möglichkeiten habe ich, das System vor Einbrechern abzuschotten? Meine bisher ergriffenen Maßnahmen sind im zweiten Absatz notiert. Jedenfalls bin ich bin jetzt von der "Es-wird-schon-nichts-passieren"-Mentalität geheilt.

Schwer zu sagen. Root-Login per SSH nicht erlauben ist schon mal ein Schritt. SSH auf einem anderen Post als 22 schützt vor den meisten Skript-Kiddies. SSH-Login nur mit Passwort ganz deaktivieren und Authentisierung nur noch durch einen Key sichert das ganze noch mehr (es gäbe auch die Möglichkeit, nur für direkten Root-Login einen Key zu verlangen, siehe man sshd_config unter PermitRootLogin).
Daneben gibt es dann halt noch die üblichen Maßnahmen wie alle nicht benötigen Dienste abschalten und dergleichen. Es gibt auch noch eine HowTo zum Absichern von Debian. Einfach mal danach googeln.

3. Und dann habe ich in Folge des jetzt verbotenen Root-Login noch ein ganz praktisches Problem: Bisher habe ich sämtliche Dateien immer mit "gftp" und Root/SSH hin- und her geschaufelt. Das ist bequem, geht jetzt aber ja nicht mehr. Ich kann mich zwar mit der der neuen Benutzerkennung via "gftp" und "ssh" einloggen, müßte dann aber als "Root" weitermachen. Gibt es eine Möglichkeit, "gftp" zum Benutzerwechsel zu überreden?

gftp kenne ich selbst nicht, für scp/sftp könnte obiger Punkt Root-Login nur noch mit Key schon helfen. Vielleicht kann ja auch gftp mit sowas umgehen. Desweiteren gibt es auch die Möglichkeit, Logins per Key über SSH auf bestimmte Kommandos einzuschränken. Das benutzen wir hier z.B. um per rsync Dateien zu kopieren.

[Dirk U.]

Mir würde (ich habe nur sehr wenig Ahnung) erstmal nur einfallen, alles vom Server zu löschen und ein Backup einzuspielen, wo du sicher sein kannst, dass es sauber ist.

Damit wärst du zumindest auf der sicheren Seite, was evtl. hinterlegte Fremdprogramme angeht.

[armin]

Du wirst übrigens nicht drum herum kommen, den Server komplett neu aufzusetzen. Ansonsten kannst du dir nie wirklich sicher sein, dass dein Server wieder clean ist.

Die Frage ist aber trotzdem: Selbst wenn Root-Login per SSH erlaubt ist - wie ist der Einbrecher reingekommen? War dein Passwort zu kurz/einfach und wurde gecrackt?
Ansonsten könnte er halt immernoch über irgendeine andere Lücke hereinspaziert sein...

[Geier0815]

Das meiste haben dir die Anderen schon geschrieben, aber trotzdem der Hinweis: Setz die Kiste komplett neu auf!
Dein Daten hin- und herschaufeln solltest Du am Besten mit scp machen.

[Duff]

Aber normalerweise sollte doch ein Zugriff über ssh (auf welchem Port auch immer) sicher sein, wenn man ein enstsprechendes Passwort verwendet.

Wie soll man denn sonst auf den Rechner zugreifen (von zu Hause aus)?

[nepos]

Aber normalerweise sollte doch ein Zugriff über ssh (auf welchem Port auch immer) sicher sein, wenn man ein enstsprechendes Passwort verwendet.

Wie soll man denn sonst auf den Rechner zugreifen (von zu Hause aus)?

Sicher ist gar nichts. Ein gutes Passwort erhöht die Sicherheit wesentlich, aber 100% sicher ist das auch nie.
Genau aus dem Grund gibt es auch die Anmeldung per Key, was wesentlich sicherer ist. Hier muss der Eindringling ja erstmal den geheimen Schlüssel stehlen und benötigt dann auch noch die Passphrase zu diesem.

[armin]

Aber normalerweise sollte doch ein Zugriff über ssh (auf welchem Port auch immer) sicher sein, wenn man ein enstsprechendes Passwort verwendet.

Wie soll man denn sonst auf den Rechner zugreifen (von zu Hause aus)?

Man kann halt noch eine weitere Hürde einbauen, indem man den Root-Login nicht direkt erlaubt.
Man muss dann zwei Passwörter knacken, oder halt einen lokalen Exploit ausnutzen.

[goecke]

mit einem SSH-2 Schlüsselpaar mit RSA Verfahren

Passwörter lassen sich "schnell" durchpobieren / raten
Kryptographische Schlüssel (mit einer entsprechenden länge >= 1024 bits ..) sind
nicht zu erraten und schwer durch Brute-Force zu ermitteln.

Diesen schlüssel noch mit einem Passwort sichern, damit, wenn
die Datei in falsche Hände gerät weniger passieren kann.

man ssh-keygen
man ssh
man ssh-agent
man keychain

gruss
Johannes

[Clio]

Vielleicht hilft auch ein Blick hierauf weiter:

http://www.debian.org/doc/manuals/secur ... l#contents

[uljanow]

Mein Tip wäre, alle Dienste, die nicht öffentlich erreichbar sein sollen, nur über ein IPSEC-VPN erreichbar zu machen. So kann man z.B. auch bequem root-befehle per ssh absetzen.

[frankieboy]

Hallo Forum,

vielen Dank für die vielen Antworten. Da Ihr mir so fleißig Tipps gegeben habt, möchte ich Euch auch mitteilen, was ich jetzt unternommen haben um das System (halbwegs???) zu sichern. Ihr erkennt an meiner Aussage "halbwegs", daß ich mir mit den gleich beschriebenen Maßnahmen keinesfalls sicher bin, jetzt vor Hackern geschützt zu sein.

Diese Verunsicherung fängt schon damit an, daß ich jetzt erstmal darauf verzichtet habe, den Rechner komplett neu aufzusetzen, wie es ja einige von Euch empfohlen haben. Da ich aber keine blasse Idee habe, über welches andere "Loch" als den vorher naiv dümmlichen konfigurierten Root-SSH-Zugang der Einbruch erfolgen konnte, würde ich das System bis auf den SSH-Zugang identisch einrichten wie damals ... und vielleicht ein grundsätzliche Problem noch immer nicht beseitigt haben. Stattdessen werde ich jetzt sehr genau beobachten, was auf dem Rechner passiert und dann ggf. auch neu erkannte Löcher mit Eurer Hilfe stopfen wollen.

Um den SSH-Root-Zugang zu sichern, habe ich mich für die Variante mit dem Public-/Privatekey entschieden.Bei der Installation habe ich mich weitgehend an die Anleitung auf http://www.debianhowto.de/doku.php/de:howtos:woody:ssh gehalten. Den privaten Key habe ich auf meinem privaten PC, einem vertrauenswürdigem Zweit-PC und einem USB-Stick gesichert. Außerdem habe ich den Standard-Port abgeändert. Meine "gefühlte" Sicherheit bezüglich des SSH-Zuganges hat jetzt erstmal um einiges zugenommen.

Dieses Verfahren bietet aber nicht nur Vorteile. So ist es z.B. nicht möglich, "mal eben schnell" von einem x-belibigen PC Zugriff auf den Server zu nehmen. Man braucht schon den "Private Key" in der Nähe. Und selbst wenn das gegeben ist, sollte man die erforderlichen Befehle kennen. Auf meinem privaten PC habe ich das automatisiert, bei Fremd-PCs müßte ich mir vorher nochmal die Tutorials ansehen "wie war das doch gleich ...". Außerdem gibt es auch vor meinem privaten PC noch ganz praktische Probleme. So habe ich "gftp" noch immer nicht zur Zusammenarbeit mit dem "Private Key" bewegen können. Selbst die Installation von "keychain" hat daran nicht geändert. Wenn ich also mit gftp eine ssh-Verbindung herstellen möchte, scheitert das daran, daß "gftp" das Passwort für den "Private Key" haben möchte (das erkenne ich am angezeigten Login-Protokoll), ich dieses Passwort aber nirgend eingeben kann. Vielleicht weiß da noch jemand Abhilfe?

Viele Grüße

Frank Dell

[mythos180]

eine andere idee wäre fail2ban. das skript sperrt einfach die ip für eine gewisse zeit, wenn das passwort mehrmals (kann man einstellen) falsch eingegeben wird. damit ist ein bruteforce-angriff nahezu ausgeschlossen, wenn ein eingreiffer für 5 versuche 10 (oder mehr) minuten benötigt ^^.

mfg
mythos

[neuss]

Hallo,

Diese Verunsicherung fängt schon damit an, daß ich jetzt erstmal darauf verzichtet habe, den Rechner komplett neu aufzusetzen, wie es ja einige von Euch empfohlen haben.

Grober Fehler, Du musst das System neu aufsetzen. Es ist doch für dich garnicht abschätzbar, was der Eindringling gemacht hat. Absolute Grundregel ist, ein einmal gehacktes System neu zu installieren. Nur die plumpe Lücke zu schließen über die er reinkam bringt nichts, denn es ist wahrscheinlich, dass er sich sofort bessere Zugriffsmöglichkeiten geschaffen hat.
Also bitte, handle verantwortungsbewusst.

gruss neuss

[Simmel]

Grober Fehler, Du musst das System neu aufsetzen.

gruss neuss

In der Tat, da kommst du nicht drum herum. Ich würde aber gerne noch ein paar Sachen ergänzen die komischerweise nicht genannt worden sind, vll. weil man sie als zu alltäglich betrachtet?

Eine Firewall solltest du dir aufsetzen, möglicherweise sogar auf einem 2ten Rechner, irgendeine die Iptablesbasiert ist. Ich nehme da gerne immer http://www.ipcop.com, habe damit schon gute Erfahrung gemacht, easy zum Aufsetzen, Bedienung und Analyse gehen damit auch schonmal besser vonstatten (siehe SNORT, etc.).

Zusätzlich würde ich noch tripwire installieren und die erstellten Regeln auf einem anderen Rechner per CD gegenchecken lassen auf regelmäßiger Basis. Solltest du was installieren deinstallieren dann musst du allerdings die REgelen erweitern und/oder wieder eingrenzen und eine neue CD erstellen.

Mit Tripwire kann man, wenn man es richtig aufsetzt, einen Einbruch dokumentieren und weiss dann meist auch sofort, WO welche Datei WIE verändert worden ist. Also einen Einbruch verhindert es auch niht, wohl aber das dieser unbemerkt bleibt.

Was auch natürlich wichtig ist aber nicht genannt worden sit, sind die Updates, auch hier ist Regelmäßigkeit der Schlüssel. Und wenn es geht nimm Sarge sprich stable und nicht unstable/testing. Ggfs, benutze lieber ein APT-Pinning, um Pakete die notwendig sind aus unstable zu bekommen, das minimiert die Anzahl der Pakete die nicht unter der schützenden Hand des Updates stehen.

So wie ich sehe nimmst du mysql, da ist php meist nicht fern. Schreibst du selber Code, oder nimmst du vorgefertigten? Auch hier müssen immer Updates am Start sein, sobald es sie gibt. ISt deine php.ini wasserdicht (kann z.B. jmd deine /etc/passwd auslesen, sogar verändern?), schonmal an das mod php-cgi gedacht? Was ist mit mod_security vom Apachen, der solche Aktionen teilweise erkennt unterbindet und mitdokumentiert? Ist dein Mysql nur vom localhost erreichbar? UND UND UND............................

HTH,
Simmel

P.S.: Der Aufwand den man reinstecken kann ist enorm, mahc dir vorher Gedanken wie wichtig dir deine Daten sind und setze dementsprechend dein Konzept ein.

[Simmel]

Hier nochmal ein Auszug aus meinen zusammengezimmerten Howtos, dieser Schritt wird auch oft vergessen/übersehen/vernachlässigt.


Unnötige Dienste abschalten

Überprüfen wir erstmal was sonst noch auf dem Rechner an Diensten läuft.

Dazu benutzen wir einmal den Befehl

pstree

den Befehl

netstat -tap |grep LISTEN

und installieren den Portscanner nmap

apt-get install nmap

Führt nun einfach die Befehle pstree aus und netstat -tap |grep LISTEN

pstree sollte in etwa folgendes zurückgeben

hobbes:~# pstree
init─┬─atd
├─bash
├─cron
├─dhclient
├─events/0─┬─aio/0
│ ├─kblockd/0
│ ├─khelper
│ ├─2*[pdflush]
│ ├─xfsdatad/0
│ └─xfslogd/0
├─exim4
├─5*[getty]
├─inetd
├─khubd
├─2*[kjournald]
├─klogd
├─kseriod
├─ksoftirqd/0
├─kswapd0
├─sshd───sshd───bash───pstree
├─syslogd
├─xfsbufd
└─3*[xfssyncd]


der netstat Befehle in etwa dieses

hobbes:~# netstat -tap |grep LISTEN
tcp 0 0 localhost.localdom:smtp *:* LISTEN 2377/exim4
tcp6 0 0 *:ssh *:* LISTEN 2394/sshd

Der Portscanner sollte in etwa folgendes zeigen nmap localhost

hobbes:~# nmap localhost

Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2006-10-02 18:11 CEST
Interesting ports on localhost.localdomain (127.0.0.1):
(The 1661 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
22/tcp open ssh
25/tcp open smtp

Nmap finished: 1 IP address (1 host up) scanned in 0.293 seconds
hobbes:~#


Den Dienst ssh brauchen wir noch, den Dienst SMTP auch, allerdings werden wir den Telnet-Dienst vom inetd behalten, den Rest aber rauswerfen.

Erstmal der inetd, ich erkläre nicht was das Ding macht sondern beschreibe nur was man mit dem Ding macht, um Dienste die anfällig und total unnötig oder veraltet sind für den Betrieb abzuschalten.

einfach wie folgt folgende Befehl ausführen, diese Dienste sind veraltet, anfällig und nicht sinnvoll für unseren Heim-Server

hobbes:~# update-inetd --remove daytime
hobbes:~# update-inetd --remove time
hobbes:~# update-inetd --remove finger
hobbes:~# update-inetd --remove talk
hobbes:~# update-inetd --remove ntalk
hobbes:~# update-inetd --remove echo
hobbes:~# update-inetd --remove chargen
hobbes:~# update-inetd --remove rsh
hobbes:~# update-inetd --remove rlogin
hobbes:~# update-inetd --remove rcp
hobbes:~# update-inetd --remove discard

Den Telnet Dienst kann man später noch gebrauchen um diverse Dienste, wie z.B. Mail zu testen. Deswegen bleibt der drin, allerdings werden wir den Dienst einschränken, so das nur noch der Server selbst ihn benutzen kann, sprich localhost oder auch 127.0.0.1

in die /etc/hosts.allow schreiben wir folgendes

in.telnetd: 127.0.0.1

es wird erst die allow Datei abgearbeitet, danach die deny Datei. In Allow steht nur noch der localhost drin. Das heisst andere dürfen nicht zugreifen ausser localhost.

Danach führen wir lieber mal ein

hobbes:~# /etc/init.d/inetd reload

aus und testen mal, ob diese Anweisung auch wirklich funktioniert.

hobbes:/etc# telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.localdomain.
Escape character is '^]'.
220 localhost.localdomain ESMTP Exim 4.50 Mon, 02 Oct 2006 02:11:35 +0200

Also lokal vom Server klappt das, beenden mit quit.

Nun dann teste ich mal, ob die Regel auch wirklich klappt und mache mal einen Telnet vom M$-Rechner.

C:\Dokumente und Einstellungen\simmel>telnet 192.168.0.97 25
Verbindungsaufbau zu 192.168.0.97...Es konnte keine Verbindung mit dem Host herg
estellt werden, auf Port 25: Verbinden fehlgeschlagen

Klasse, geht nicht, wie gewünscht.

Nun noch den ollen inetd komplett ersetzen durch einen besseren Deamon apt-get install xinetd

Dieser arbeitet nun Ontop auf dem inetd, ist sicherer und hat mehr Funktionen.

[Pawel]

Äh, du - Simmel, sehr nette Liste nur leider mit einigen (Denk-)Fehlern. Aber ich fang mal ganz oben an:

Code: Alles auswählen

hobbes:~# netstat -tap |grep LISTEN
tcp 0 0 localhost.localdom:smtp *:* LISTEN 2377/exim4
tcp6 0 0 *:ssh *:* LISTEN 2394/sshd

Die zweite Zeile bedeutet, dass Exim auf Port 25 hört und zwar nur für localhost.

in die /etc/hosts.allow schreiben wir folgendes

in.telnetd: 127.0.0.1

Sehr loblich, aber aus der obrigen Liste und dem pstree geht hervor, dass kein Telnet Deamon läuft.

hobbes:/etc# telnet localhost 25 [funktioniert]
C:\Dokumente und Einstellungen\simmel>telnet 192.168.0.97 25[funktioniert nicht]

Dein Test mit dem Port 25 funktioniert nicht wegen der oben genannten Einschränkung.

Um das ganze mal aufzuklären, du brauchst kein telnetd um mit telnet Verbindungen aufzubauen. Genau so wenig wie man einen Webserver braucht um einen Browser zu benutzen.

[Tunix]

der netstat Befehle in etwa dieses

hobbes:~# netstat -tap |grep LISTEN
tcp 0 0 localhost.localdom:smtp *:* LISTEN 2377/exim4
tcp6 0 0 *:ssh *:* LISTEN 2394/sshd

Seltsame Logik... Du benutzt die Option -t, womit Du nur auf TCP prüfst. Dann benutzt Du noch -a, um Dir sowohl alle lauschenden als auch alle nicht lauschenden Sockets anzuzeigen, nur um nachher mit grep LISTEN nach den lauschenden Sockets zu filtern. Probiere es mal mit netstat -tulp, dass zeigt Dir alle lauschenden Sockets von TCP und UDP an. Wenn Du noch ein -n dazupackst, werden IPs und Ports nicht aufgelöst, dass geht schneller und ist hin und wieder übersichtlicher. Wie Pawel bereits andeutete, lässt sich exim4 nur von localhost aus ansprechen, andere Adressen werden verworfen.

Der Portscanner sollte in etwa folgendes zeigen nmap localhost

hobbes:~# nmap localhost

Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2006-10-02 18:11 CEST
Interesting ports on localhost.localdomain (127.0.0.1):
(The 1661 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
22/tcp open ssh
25/tcp open smtp

Nmap finished: 1 IP address (1 host up) scanned in 0.293 seconds

Ein nmap auf localhost findet den Mailserver natürlich. Ein nmap 192.168.0.97 auf derselben Kiste würde den SMTP-Server bereits nicht mehr anzeigen.

Den Telnet Dienst kann man später noch gebrauchen um diverse Dienste, wie z.B. Mail zu testen. Deswegen bleibt der drin, allerdings werden wir den Dienst einschränken, so das nur noch der Server selbst ihn benutzen kann, sprich localhost oder auch 127.0.0.1

Habe ich was verpasst? Wofür braucht man zum Mailserver-Testen einen Telnet-Server? Sowas macht man mit einem Telnet-Client und der macht bestimmt nicht Port 25 auf...

[frankieboy]

Hallo "Debs",

Diese Verunsicherung fängt schon damit an, daß ich jetzt erstmal darauf verzichtet habe, den Rechner komplett neu aufzusetzen, wie es ja einige von Euch empfohlen haben.

Grober Fehler, Du musst das System neu aufsetzen. Es ist doch für dich garnicht abschätzbar, was der Eindringling gemacht hat. Absolute Grundregel ist, ein einmal gehacktes System neu zu installieren. Nur die plumpe Lücke zu schließen über die er reinkam bringt nichts, denn es ist wahrscheinlich, dass er sich sofort bessere Zugriffsmöglichkeiten geschaffen hat.

Ach Mensch, das macht mich alles fertig. Wenn ich hier alle Eure Tips lese, weiß ich, daß ich gar nichts weiß. Und mit ziemlicher Sicherheit gibt es noch viel mehr, was ich sonst noch wissen sollte, woran ich aber nicht mal im Traum denke. Es erscheint mir schleierhaft, wie ich unter solchen Umständen jemals zu einem sicheren Serversystem kommen soll.

Aber gut, ich werde das System neu aufsetzen und möglichst viele Eurer Ratschläge beherzigen. Ob es was bringt? Nach diesen Erfahrungen bin ich da eher skeptisch?

Trotzdem vielen Dank für Hilfe.

Viele Grüße

Frank Dell

[456379]

Mit fail2ban kann man nicht in allen Fällen einen solchen Angriff sperren. In meiner Log- Datei habe ich einen solchen Versuch gesehen, der bei jedem Passwort eine andere IP verwendete.

Seitdem schalte ich SSH nur noch bei Bedarf ein.

[me_max]

Um deine Kiste mal von außen auf mögliche, weitere Lücken zu prüfen, würde ich einfach mal Nessus drüberlaufen lassen. Das Tool scannt alle Ports und gibt dir Informationen über mögliche Verwundbarkeit. Musst es von deinem Home-Rechner aus laufen lassen.
Das gibt es hier http://www.nessus.org/download/ oder im Debian-Repository.