inetd
Um sich vor Eindringlingen aus dem Netz zu schützen, deaktivieren wir zunächst eine Reihe von Netzwerkdiensten, die nur in den seltensten Fällen benötigt werden, die aber standardmäßig aktiviert sind und dadurch zum Schlupfloch für Eindringlinge werden können.
Dazu erstellen wir zunächst eine Sicherungskopie der Datei /etc/inetd.conf, um sie anschließend mit einem Texeditor zu bearbeiten. Wir editieren diese Datei so, dass am Anfang jeder Zeile ein Kommentarzeichen "#" steht. So wird
time stream tcp nowait root internal
zu
#time stream tcp nowait root internal
Wenn wir alle Zeilen auskommentiert haben, speichern wir die Datei und veranlassen den Internet-Daemon inetd durch folgendes Kommando, seine Einstellungen neu einzulesen, um die Änderungen wirksam werden zu lassen:
rcinetd reload
Puristen werden das mit dem Befehl killproc -HUP /usr/sbin/inetd tun, aber da wir uns mit der Suse-Distribution beschäftigen, nutzen wir natürlich auch die kleinen Annehmlichkeiten derselben. Sollten später einzelne Dienste des inetd wieder benötigt werden, können diese einfach durch Entfernen des Kommentarzeichens am Anfang der entsprechenden Zeile und durch die erneute Eingabe des Befehls rcinetd reload wieder aktiviert werden.
Andere Dämonen
Als nächstes wenden wir uns anderen standardmäßig aktivierten Diensten, so genannten "Daemons" zu, die man nur in den seltensten Fällen benötigt, die aber die Sicherheit beeinträchtigen können. Damit diese beim nächsten Systemstart nicht mehr gestartet werden, entfernen wir jeweils aus den Verzeichnissen:
/etc/rc.d/rc3.d/
und
/etc/rc.d/rc5.d/
die Links namens S08portmap, S09nfs, S10atd, S10sendmail, diesmal ohne eine Sicherungskopie anzulegen.
Man geht dabei folgendermaßen vor:
rm S08portmap
rm S09nfs
und so weiter.
Sollten wir einen der Daemons wieder benötigen, so können die gelöschten Links in den Verzeichnissen mit den Befehlen:
ln – s ../portmap S08portmap
ln –s ../nfs S09nfs
ln –s ../atd S10atd
ln –s ../sendmail S10sendmail
ln –s ../nscd S11nscd
wieder anlegt werden. Die entsprechenden Daemons werden beim nächsten Systemstart wieder geladen.
SSH
Zu guter Letzt passen wir auch den "Secure-Shell"-Daemon und den Client an, damit beim etwaigen Netzwerkzugriff auf unseren Rechner keine unliebsamen Überraschungen drohen. Der Secure Shell Daemon bietet die Möglichkeit, sicher über das Netzwerk auf den eigenen Rechner zuzugreifen und eine Login Shell zu bekommen, so als säße man direkt vor dem Computer. Die Standardeinstellungen bedürfen jedoch der Anpassung, da einige der Optionen auf Bequemlichkeit und nicht auf Sicherheit ausgelegt sind. Man findet die Konfigurationsdateien für den Secure-Shell-Daemon und -Client im Verzeichnis
/etc/ssh/
Dort passen wir zunächst die Serverkonfiguration in der Datei
sshd_config
an, natürlich nicht ohne vorher eine Sicherungskopie der Datei zu erstellen.
Aus der Zeile
#Protocol 2,1
wird
Protocol 2
Damit verhindern wir, dass der Secure-Shell-Server Verbindung über die unsichere erste Protokollversion zulässt.
Aus PermitRootLogin yes
wird
PermitRootLogin no
Das lässt keine Netzwerklogins als Benutzer "root" mehr zu. Möchte man über das Netzwerk den Server konfigurieren, muss man sich zunächst als normaler Benutzer anmelden, um sich dann mit dem Befehl
su –
Superuser-Privilegien zu verschaffen. Das erhöht die Schwelle für Angreifer, da statt nur dem Passwort des root-Accounts zusätzlich das Passwort des Benutzeraccounts geknackt werden muss, um privilegiert auf das System zugreifen zu können.
Anschließend bearbeiten wir die Datei
ssh_config,
um unseren Secure-Shell-Client so sicher wie möglich zu konfigurieren. Die Grundeinstellungen sind hier recht sicher, allerdings verändern wir die Zeile
# Protocol 2,1
zu
Protocol 2,1
Damit weisen wir den Client an, immer zuerst eine Verbindung über Protokollversion 2 zu versuchen. Nur wenn das nicht funktioniert, wird Protokollversion 1 versucht. Um ganz auf der sicheren Seite zu sein, kann man auch hier Protokollversion 1 ganz verbieten, indem die Zeile auf
Protocol 2
geändert wird. Das macht allerdings eine Verbindung zu Servern unmöglich, die nur Protokollversion 1 beherrschen, was in gewachsenen Umgebungen durchaus häufiger vorkommt.
X11
Wenn auf dem Rechner, den wir konfigurieren, eine grafische Benutzeroberfläche gestartet wird, lauscht in der Standardkonfiguration der X-Server auf Port 6000 TCP auf Verbindungen aus dem Netzwerk. Da aber einige X-Applikationen diesen Port auch benötigen, wenn sie auf dem gleichen Rechner laufen wie der Server, sollten wir den X-Server nicht ohne diese Netzwerkunterstützung starten. Um trotzdem Unbefugte am Zugriff auf diesen sehr unsicheren Port zu hindern, bedienen wir uns der Suse-Firewall 2. Die lässt sich bequem per yast2 auch an der Konsole konfigurieren, ohne dass man in die Tiefen von iptables (Administrationstool für den Paketfilter des 2.4er-Kernel) vordringen müsste.
Wir starten das Administrationstool mit Eingabe des Befehls
yast2
Dort wählen wir den Punkt "Sicherheit Benutzer" und dann das Modul "Firewall" aus. Als externe Schnittstelle wählen wir das Netzwerk-Device, mit dem wir die Verbindung ins Internet herstellen. Bei analogen und DSL-Verbindungen könnte das zum Beispiel ppp0 sein, bei ISDN-Verbindungen ippp0. Im folgenden Dialog lässt man als einzigen Dienst "Secure Shell" zu. Im dritten Schritt muss "Alle laufenden Dienste schützen" aktiviert werden. Die Protokollierungsoptionen können ungeändert übernommen werden. Anschließend wird die Firewall mit den gewählten Einstellungen konfiguriert und gestartet. Damit haben wir unseren Rechner einer Grundabsicherung unterzogen und können uns guten Gewissens ins Internet wagen.
Trotz allem sollte man immer auf der Hut sein, wo man sich im Internet umschaut und welche Seiten und Dateien man abruft. Es entstehen ständig neue Gefahren und Leichtsinn kann auch die besten Vorkehrungen aushebeln. Um sich Ärger zu ersparen sollte man genau hinsehen, ob in dem Download-Dialog, den man gerade bestätigt, auch wirklich die Datei heruntergeladen werden soll, die man haben möchte. E-Mails von unbekannten Absendern löscht man, ohne sie zu öffnen und Anhänge von E-Mails und Dateien aus dem Internet sollten grundsätzlich einer Virenüberprüfung unterzogen werden. (kpl)