Was läuft?

Auf einem Linux-Rechner laufen nicht nur Programme, die Sie als Benutzer bewusst über die Menüs oder Terminals starten. Viele Anwendungen erledigen ihre Aufgaben still und leise im Hintergrund, ohne dass Sie davon Wind bekommen. Sie räumen Log-Dateien auf (Logrotate), führen zu fixen Zeiten Befehle aus (Cron/Anacron) und mixen den Sound diverser Anwendungen (PulseAudio).

Bei diesen Diensten unterscheidet man zwischen rein lokalen Dienstprogrammen und Serverdiensten, die sich über das lokale Netzwerk oder gar das Internet ansprechen lassen. Lokale Dienste (im Englischen "Daemons") wie Cron oder Logrotate arbeiten so gut wie auf jedem Linux-System. Einmal installiert und eingerichtet, werkeln sie ohne Ihr Eingreifen im Hintergrund.

Dagegen stehen Serverdienste wie der SSH-Daemon, Web- oder FTP-Server aber auch Multimedia-Server wie PulseAudio in direktem Kontakt mit anderen Rechnern oder Programmen im Netzwerk. Sicherheitstechnisch sollten Sie diese im Auge behalten. Grundlos laufende Server – eventuell noch mangelhaft konfiguriert – bieten Angreifern eine Angriffsfläche, zudem gelangen Ihre Daten mitunter ungewollt an die Öffentlichkeit.

Grundsätzlich steckt im Client-Server-Modell jedoch die Möglichkeit, Aufgaben und Dienste lokal oder über ein Netzwerk zu verteilen. Dabei fordert der Client meist über das Netzwerk eine Aufgabe an, während der Server diese erledigt und das Ergebnis zurückschickt. Solchen Serverdiensten wollen wir etwas auf den Grund gehen.

Was lauscht bei mir?

Serverdienste laufen nicht nur in Rechenzentren und liefern Webseiten aus, sondern sie erledigen beliebige Aufgaben auf herkömmlichen Computern. Selbst Ihr Linux-System startet von Hause aus einige Programme, die als Serverdienste unbemerkt im Hintergrund arbeiten. Dabei benötigen sie nicht einmal ein Netzwerk: Fehlt dieses, "unterhalten" sich viele Anwendungen über die Loopback-Schnittstelle.

Fast jeder Computeranwender, der sich ein wenig mit Sicherheit im Internet beschäftigt, kennt vermutlich den Begriff "Netzwerkport". In Verbindung mit Personal Firewalls ranken sich vielfältige Legenden um diese Ports.

Generell nutzen Dienste in den heutigen Netzwerken meist die Transportprotokolle TCP und UDP. Beide verwenden durchnummerierte Ports, die von 1 bis 65535 (2^16) reichen. Im Gegensatz zu Clientanwendungen reagieren Serverdienste auf alle eingehenden Datenpakete, die sie auf dem Port empfangen, auf dem sie lauschen. Hier ist es wichtig, zwischen offenen Client- und Serverports zu unterscheiden.

Ein frisch aufgesetztes Ubuntu-System öffnet aufgrund der "Keine-offenen-Ports"-Regel [1] keine Ports in die angebundenen Netzwerke. Diese Regel macht das Einrichten einer Firewall auf einem Ubuntu-System meist überflüssig. Einfach zu merken: Wo nichts lauscht, gibt's auch keine Lauschangriffe. Mit der Uncomplicated Firewall (kurz UFW) installiert Ubuntu zwar auch ein einfach zu bedienendes Kommandozeilen-Frontend für Iptables, doch UFW ist von Hause aus nicht aktiv.

Sie können auf Ihrem Ubuntu-System selbst prüfen, welche Anwendungen permanent Server-Ports offen halten. Dazu rufen Sie über Zubehör | | | Terminal eine Kommandozeile auf und tippen

$ sudo netstat -tulpen

Laufen bereits aktive Serverdienste auf dem Rechner, sortieren Sie lokale IPv4-Dienste aus der Ergebnisliste heraus:

$ sudo netstat -tulpen | grep -v '127.0.0.1'

Bei einer frischen Ubuntu-Installation laufen lediglich der Druckdienst CUPS, der Avahi-Dienst (der Ressourcen im Netzwerk aufspürt) sowie der DHCP-Client, der bei der automatischen Konfiguration von Netzwerkkarten hilft (Abbildung 1).

Abbildung 1: Netstat zeigt sämtliche Anwendungen an, die zur Zeit geöffnete Ports anbieten. Das sind nach einer frischen Ubuntu-Installation nicht viele.

Keine dieser Anwendungen bietet Netzwerkdienste im Internet an. Die lokalen Adressen 127.0.0.1:631 und ::1:631 (::1 steht für localhost in einem IPv6-Netz) zeigen, dass der Druckdienst CUPS nur Daten von localhost empfängt. Der Port ist offen, damit Sie CUPS auf dem eigenen Rechner über das Webfrontend einrichten. Sagt Ihnen das jetzt nichts, geben Sie mal http://localhost:631 in die URL-Leiste des Browsers ein.

Avahi und der DHCP-Client öffnen hingegen Ports für andere IP-Adressen, allerdings verwirft der DHCP-Client alle Pakete, die nicht aus dem lokalen Netzwerk stammen (und somit die für lokale Netzwerke reservierten IP-Adressen verwenden). Ähnliches gilt für Avahi: Da der Dienst auf Broadcast-Nachrichten lauscht, verlässt auch hier nichts die Grenzen des eigenen Netzwerks.

Dienste starten/stoppen?

Lange Jahre diente SysVinit beim Booten als DAS Init-System von Linux. Doch das stoische, serielle Abarbeiten von Aufgaben verzögerte den Boot-Prozess zunehmend. Seit Ubuntu 6.10 übernahm nach und nach das von Canonical entwickelte Upstart das Zepter. Das startet Dienste parallel und Ereignis-basiert und ruft z. B. keinen Netzwerkdienst auf, wenn es noch kein Netzwerk findet. Das beschleunigt den Bootprozess und erleichtert den Umgang mit auswechselbarer Hardware.

Um die Dienste auf Ihrem System zu steuern, brauchen Sie das Terminal. Bekannte grafische Tools, um Dienste zu starten und zu stoppen wie den Boot-Up-Manager (kurz BUM) [2] oder Sysv-rc-conf [3] meiden Sie in aktuellen Ubuntu-Versionen besser, da sie (noch) nicht mit Upstart-Jobs zurecht kommen (Abbildung 2).

Abbildung 2: Die beiden Tools BUM und Sysv-rc-conf bieten zwar "grafische Oberflächen" zum Einrichten von Diensten, funktionieren aber nicht mehr korrekt.

Um Dienste zu starten und zu stoppen, müssen Sie ihre Namen kennen, die auch Netstat nicht immer richtig ausgibt. Eine Liste aller von Upstart kontrollierten Dienste zeigt Ihnen der Aufruf von initctl. Zusätzlich zum Namen verrät das "Init Daemon Control Tool" – so die Langfassung – den aktuellen Status sowie die Nummer eines Prozesses.

$ initctl list
alsa-mixer-save stop/waiting
avahi-daemon start/running, process 1402
ssh start/running, process 1341
[...]

Dementsprechend starten und beenden Sie Init-Jobs auch über Initctl. Die Syntax lautet:

$ sudo initctl [start/stop] ssh

Bleibt noch das Problem, dass Ubuntu klassische SysVinit- und neue Upstart-Skripte parallel nutzt. So steuert Upstart zum Beispiel den SSH-Server OpenSSH, aber nicht den Webserver Apache. Von daher führt initctl list Apache nicht als Dienst auf und liefert die Eingabe von sudo initctl stop apache2 nur eine Fehlermeldung.

Hier bietet es sich an, auf das SysVinit-Werkzeug service zurückzugreifen. Dieses arbeitet für den Benutzer völlig transparent mit beiden Skriptarten zusammen. Über sudo service [TAB][TAB] erhalten Sie eine Liste aller Dienste (egal ob SysVinit oder Upstart diese steuert). Anschließend erfahren Sie über den Befehl service dienstname, welche Anweisungen ein Dienst versteht. Für ssh sieht das dann so aus:

$ sudo service ssh
 * Usage: /etc/init.d/ssh {start|stop|reload|force-reload|restart|try-restart|status}

Danach steuern Sie den Dienst über sudo service ssh [start/stop/...]. Die Kurzform sudo [start/stop/...] ufw funktioniert hingegen nur für Upstart-Jobs.