AA_lauf.jpg

© Ioannis Kounadeas, Fotolia

Diensten auf der Spur

Was läuft?

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.

Ähnliche Artikel

  • Eigene Dienste mit Upstart zünden
    Unter Ubuntu wacht der SysV-Init-Ersatz Upstart über die komplexen Vorgänge beim Systemstart. Mit dem richtigen Know-how fügen Sie bei Bedarf hier ein eigenes Startskript ein.
  • Systemstart
    Auf fast allen modernen Linux-Distributionen kümmert sich inzwischen Systemd um den Systemstart – und mehr. Wir erklären, wie die neue Schaltzentrale funktioniert.
  • Upstart und Systemd im Vergleich
    Upstart und Systemd – gleich zwei neue Ansätze konkurrieren um die Pole-Position beim Linux-Start. Wir unterziehen die Kandidaten einem konzeptionellen Vergleich.
  • Systemd als Schaltzentrale für das Linux-System
    Systemd polarisiert die Community – und hat zugleich das Zeug dazu, alte Gräben zu schließen und eine einheitliche Basis für Linux zu bilden.
  • Auch Debian ersetzt Sysvinit durch Upstart
    Das derzeitige Debian-Bootsystem Sysvinit soll wegen Unzuverlässigkeit schrittweise durch Upstart ersetzt werden, melden die Bootsystem-Maintainer auf der Entwickler-Announce-Mailingliste.
Kommentare

Infos zur Publikation

Ubuntu User ist bis Ausgabe 02/2013 vierteljährlich erschienen, aktuelle Artikel zu Ubuntu finden sich ab Ausgabe 04/2013 im LinuxUser.

Aktuelle Fragen

thema ändern
a b, 29.05.2016 16:34, 0 Antworten
Hallo Linuxer zuerst alle eine schönen Sonntag, bevor ich meine Frage stelle. Ich habe Ubuntu 1...
Ideenwettbewerb
G.-P. Möller, 28.05.2016 10:57, 0 Antworten
Liebe User, im Rahmen eines großen Forschungsprojekts am Lehrstuhl für Technologie- und Innova...
Welche Drucker sind Linux-mint kompatibel?
Johannes Nacke, 20.05.2016 07:32, 4 Antworten
Hallo Ihr Lieben, ich bitte um mitteilung welche Drucker Kompatibel sind mit Linux-Mint. LG Joh...
MS LifeCam HD-5000 an Debian
Kay Michael, 13.04.2016 22:55, 0 Antworten
Hallo, ich versuche die oben erwähnte Cam an einem Thin Client mit Debian zu betreiben. Linux...
Import von Evolution nach KMail erzeugt nur leere Ordner
Klaus-Christian Falkner, 06.04.2016 12:57, 3 Antworten
Hallo, da ich vor einiger Zeit von Ubuntu auf Kubuntu umgestiegen bin, würde ich gerne meine E...