AA_lauf.jpg

© Ioannis Kounadeas, Fotolia

Was läuft?

Diensten auf der Spur

15.02.2011
Welche Dienste laufen auf Ihrem System? Welche davon lauschen auf Besucher aus dem Internet/LAN? Müssen Web-, SSH- oder FTP-Server permanent auf einem Desktop oder Laptop laufen? Fragen über Fragen, wir suchen Antworten.

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.

Autostart von Diensten verhindern

In manchen Fällen wollen Sie nicht, dass installierte Dienste automatisch starten. Entwickeln Sie zum Beispiel ab und an Webseiten, läuft auf Ihrem Rechner vermutlich ein Webserver, Änderungen an den Seiten direkt zu testen. Doch müssen fremde Nutzer Ihren Webserver auch auf einer Konferenz über das WLAN des Veranstalters erreichen? Eher nicht! Den Dienst indes jedes Mal beim Hochfahren des Rechners von Hand zu beenden, klappt vermutlich auch nicht.

Sie könnten jetzt natürlich mit Firewall-Regeln den Zugang zum Webserver blockieren, oder ihn so konfigurieren, dass sich die Seiten nur über ein Passwort abrufen lassen (Stichwort: .htaccess [4]). Besser wäre es jedoch, wenn Netzwerkdienste nur dann laufen, wenn Sie diese auch brauchen.

Um einen Upstart-Dienst vom Start abzuhalten, bearbeiten Sie einfach die Job-Definition für den Dienst. Diese landet jeweils in einer Datei im Verzeichnis /etc/init/. Im Fall eines SSH-Servers wäre dies zum Beispiel die Datei ssh.conf. Öffnen Sie diese in einem Editor, finden Sie stets eine start-Zeile, die bestimmt, bei welchem Ereignis Upstart den Job ausführt. Kommentieren Sie diese Zeile aus, fällt das Startereignis weg und Sie rufen den Dienst fortan manuell auf. Im Beispiel sähe dies aus wie in Listing 1.

Listing 1

# ssh - OpenBSD Secure Shell server
# The OpenSSH server provides secure shell access to the system.
description     "OpenSSH server"
#start on filesystem
stop on runlevel S
[...]

Bei Upstart-Skripten verhindern Sie den automatischen Start also recht einfach. Schwieriger wird es bei SysVinit-Skripten, die Sie im Verzeichnis /etc/init.d/ vorfinden. Von dort aus verlinkt Ubuntu die Dienste in die Runlevel des Systems, damit diese – je nach Status – automatisch starten oder stoppen. Das Ver- und Entknüpfen mit den Runleveln erledigt der Befehl update-rc.d zwar relativ zuverlässig, doch die Einstellung hält nur bis zum nächsten Update des betroffenen Dienstes (Abbildung 3). Wollen Sie den Befehl nicht bei jedem Systemstart (automatisch) aufrufen, verwenden Sie ein grafisches Tool für die Aufgabe.

Abbildung 3: Über den Befehl "update-rc.d" lassen sich einzelne Dienste vom Starten ausnehmen. Erhält der Dienst ein Upgrade, stellt das jedoch die Startreihenfolge wieder her.

Das bislang einzige grafische Frontend für die Verwaltung von Upstart- und SysVinit-Jobs ist das Programm Jobs-admin [5] (Abbildung 4). Seit Ubuntu 10.10 installieren Sie es direkt aus den Paketquellen, für Nutzer von Ubuntu 10.04 gibt es ein PPA [6].

Abbildung 4: Jobs-admin ist das bisher einzige grafische Tool zur Konfiguration von Runleveln für die Dienste.

Über Jobs-admin starten und stoppen Sie Dienste oder verhindern, dass Ubuntu diese automatisch aufruft. Manche Dienste – etwa SSH – konfigurieren Sie über Jobs-admin sogar. Für SSH erlauben und verbieten Sie etwa die Anmeldung über Passwörter oder als Benutzer root.

Insgesamt sollten Sie jedoch Vorsicht walten lassen: Da Ubuntu keine vollkommen sinnlosen Dienste installiert, sollten Sie Dienste nur entfernen, die Sie definitiv nicht benötigen (etwa den Bluetooth-Dienst, wenn Sie keinen Bluetooth-Adapter besitzen). Stellen Sie zu viele Dienste ab, funktionieren unter Umständen gewisse Automatismen nicht mehr.

Glossar

Loopback-Schnittstelle

Das Internet Protocol (IP) beinhaltet in seiner Spezifikation speziell reservierte IP-Adressen für ein Loopback. Sämtliche Pakete, die ein Programm an diese Adressen sendet, landen wieder auf demselben Computer. Der bekannte Domainname für die Loopback-Schnittstelle lautet localhost.

Broadcast

Per Rundruf (engl. "Broadcast") sendet ein Rechner in einem lokalen Netzwerk Datenpakete an alle anderen Rechner. Das geschieht üblicherweise, wenn der Sender die Adresse des Empfängers der Nachricht noch nicht kennt. So verkündet etwa ein DHCP-Server im LAN seine Existenz via Broadcast. Andere Computer, die dem Netzwerk beitreten wollen, melden sich bei ihm und erhalten eine IP-Adresse. Handelsübliche DSL-Router leiten Broadcasts nicht in das Internet weiter.

Init-System

Init-Prozess (kurz für initiieren) heißt unter Linux der erste, direkt vom Kernel gestartete, Prozess des Systems. Von ihm ausgehend ruft Linux beim Booten dann alle weiteren Dienste und Programme auf.

Runlevel

Der SysVinit-Prozess durchläuft beim Booten verschiedene Zustände (Runlevel). In jedem Runlevel starten und stoppen Prozesse in einer vordefinierten Reihenfolge. Im Gegensatz zu Debian mit seinen fünf Runleveln (plus Shutdown, Single-User und Reboot) nutzt Ubuntu jedoch nur die Runlevel 1 und 2 für den Recovery-Modus und den Mehrbenutzerbetrieb.

Infos

[1] Die "Keine-offenen-Ports"-Policy von Ubuntu: https://wiki.ubuntu.com/Security/Features#ports

[2] Der grafische Boot-Up-Manager: http://www.marzocca.net/linux/bum.html

[3] Das Konsolenwerkzeug Sysv-rc-conf: http://sysv-rc-conf.sourceforge.net

[4] Ausführungen zu ".htaccess": http://aktuell.de.selfhtml.org/artikel/server/htaccess/

[5] Jobs-admin zum Steuern von Upstart: https://launchpad.net/jobsadmin

[6] PPA zur Installation von Jobs-admin: https://launchpad.net/~jpeddicord/+archive/jobs

Der Autor

Christoph Langner arbeitet für die PTV AG Karlsruhe in Karlsruhe im Bereich des Testmanagements und ist seit Jahren im Bereich der Open-Source-Software aktiv. Sie finden sein Blog rund um GNU/Linux auf http://linuxundich.de

LinuxCommunity kaufen

Einzelne Ausgabe
 

Ähnliche Artikel

Kommentare