Linux Professional Institute Learning Logo.
Weiter zum Inhalt
  • Home
    • Alle Ressourcen
    • LPI Lernmaterialien
    • Mitmachen
    • Publishing Partner
    • Publishing Partner werden
    • Über uns
    • FAQ
    • Mitwirkende
    • Roadmap
    • Kontakt
  • LPI.org
110.2 Lektion 1
Thema 105: Shells und Shell-Skripte
105.1 Die Shell-Umgebung anpassen und verwenden
  • 105.1 Lektion 1
  • 105.1 Lektion 2
  • 105.1 Lektion 3
105.2 Einfache Skripte anpassen oder schreiben
  • 105.2 Lektion 1
  • 105.2 Lektion 2
Thema 106: Benutzerschnittstellen und Desktops
106.1 X11 installieren und konfigurieren
  • 106.1 Lektion 1
106.2 Grafische Desktops
  • 106.2 Lektion 1
106.3 Barrierefreiheit
  • 106.3 Lektion 1
Thema 107: Administrative Aufgaben
107.1 Benutzer- und Gruppenkonten und dazugehörige Systemdateien verwalten
  • 107.1 Lektion 1
  • 107.1 Lektion 2
107.2 Systemadministrationsaufgaben durch Einplanen von Jobs automatisieren
  • 107.2 Lektion 1
  • 107.2 Lektion 2
107.3 Lokalisierung und Internationalisierung
  • 107.3 Lektion 1
Thema 108: Grundlegende Systemdienste
108.1 Die Systemzeit verwalten
  • 108.1 Lektion 1
  • 108.1 Lektion 2
108.2 Systemprotokollierung
  • 108.2 Lektion 1
  • 108.2 Lektion 2
108.3 Grundlagen von Mail Transfer Agents (MTA)
  • 108.3 Lektion 1
108.4 Drucker und Druckvorgänge verwalten
  • 108.4 Lektion 1
Thema 109: Netzwerkgrundlagen
109.1 Grundlagen von Internetprotokollen
  • 109.1 Lektion 1
  • 109.1 Lektion 2
109.2 Persistente Netzwerkkonfiguration
  • 109.2 Lektion 1
  • 109.2 Lektion 2
109.3 Grundlegende Netzwerkfehlerbehebung
  • 109.3 Lektion 1
  • 109.3 Lektion 2
109.4 Clientseitiges DNS konfigurieren
  • 109.4 Lektion 1
Thema 110: Sicherheit
110.1 Administrationsaufgaben für Sicherheit durchführen
  • 110.1 Lektion 1
110.2 Einen Rechner absichern
  • 110.2 Lektion 1
110.3 Daten durch Verschlüsselung schützen
  • 110.3 Lektion 1
  • 110.3 Lektion 2
How to get certified
  1. Thema 110: Sicherheit
  2. 110.2 Einen Rechner absichern
  3. 110.2 Lektion 1

110.2 Lektion 1

Zertifikat:

LPIC-1

Version:

5.0

Thema:

110 Sicherheit

Lernziel:

110.2 Einen Rechner absichern

Lektion:

1 von 1

Einführung

In dieser Lektion behandeln wir vier grundlegende Konzepte zur Verbesserung der Hostsicherheit:

  1. Befehle und Konfigurationseinstellungen zur Verbesserung der Authentifizierungssicherheit mit Shadow-Passwörtern.

  2. Superdaemons, um auf eingehende Netzwerkverbindungen zu warten.

  3. Überprüfung der Netzwerkdienste auf unnötige Daemons.

  4. TCP-Wrapper als einfache Firewall.

Verbesserung der Authentifizierungssicherheit mit Shadow-Passwörtern

Die wichtigsten Account-Daten eines Benutzers sind in der Datei /etc/passwd gespeichert. Sie enthält sieben Felder: Anmeldename, Benutzerkennung, Gruppenkennung, Passwort, Kommentar (auch GECOS genannt), Heimatverzeichnis und schließlich die Standard-Shell. Um sich die Reihenfolge dieser Felder zu merken, hilft es, sich den Prozess der Anmeldung eines Benutzers vorzustellen: Zunächst geben Sie einen Anmeldenamen ein, den das System dann in eine Benutzer-ID (uid) und eine Gruppen-ID (gid) umwandelt. Im vierten Schritt wird ein Passwort abgefragt und im fünften der Kommentar nachgeschlagen — bevor im sechsten Schritt das Heimatverzeichnis des Benutzers und im siebten Schritt die Standard-Shell festgelegt werden.

Moderne Systeme speichern das Passwort allerdings nicht mehr in der Datei /etc/passwd. Stattdessen enthält das Passwortfeld nur noch ein kleingeschriebenes x. Die Datei /etc/passwd muss für alle Benutzer lesbar sein. Daher ist es keine gute Idee, Passwörter dort zu hinterlegen. Das x zeigt an, dass das verschlüsselte (gehashte) Passwort stattdessen in der Datei /etc/shadow liegt, die nicht für alle Benutzer lesbar sein darf.

Passworteinstellungen konfigurieren Sie mit den Befehlen passwd und chage. Beide Befehle ändern im Folgenden den Eintrag für den Benutzer emma in der Datei /etc/shadow. Als Superuser setzen Sie das Passwort für den Benutzer emma so:

$ sudo passwd emma
New password:
Retype new password:
passwd: password updated successfully

Es folgt eine zweifache Aufforderung, das neue Passwort zu bestätigen.

Um die Ablaufzeit des Passworts und andere Einstellungen für den Benutzer emma aufzulisten, verwenden Sie:

$ sudo chage -l emma
Last password change					: Apr 27, 2020
Password expires					: never
Password inactive					: never
Account expires						: never
Minimum number of days between password change		: 0
Maximum number of days between password change		: 99999
Number of days of warning before password expires	: 7

Um zu verhindern, dass sich der Benutzer emma im System anmeldet, können Sie als Superuser ein Ablaufdatum für das Passwort festlegen, das vor dem aktuellen Datum liegt. Wäre das aktuelle Datum beispielsweise der 27.03.2020, könnten Sie das Passwort des Benutzers durch Verwendung eines älteren Datums ablaufen lassen:

$ sudo chage -E 2020-03-26 emma

Alternativ:

$ sudo passwd -l emma

Der Befehl passwd mit der Option -l sperrt das Konto vorübergehend. Um die Auswirkungen dieser Änderungen zu testen, versuchen Sie sich als emma anzumelden:

$ sudo login emma
Password:
Your account has expired; please contact your system administrator

Authentication failure

Um zu verhindern, dass sich alle Benutzer außer dem Root-Benutzer vorübergehend am System anmelden, erstellen Sie eine Datei namens /etc/nologin. Sie kann eine Nachricht an die Benutzer enthalten, warum sie sich vorübergehend nicht anmelden können (z.B. Benachrichtigungen über Systemwartungen). Für Details siehe man 5 nologin. Beachten Sie, dass es auch einen Befehl nologin gibt, der eine Anmeldung verhindert, wenn er als Standard-Shell für einen Benutzer gesetzt ist, zum Beispiel:

$ sudo usermod -s /sbin/nologin emma

Siehe man 8 nologin für weitere Einzelheiten.

Mit einem Superdaemon auf eingehende Netzwerkverbindungen lauschen

Netzwerkdienste wie Webserver, E-Mail-Server und Druckserver laufen in der Regel eigenständig, indem sie auf einem fest zugeordneten Netzwerkport lauschen. All diese Dienste werden nebeneinander ausgeführt. Auf klassischen Sys-V-init-basierten Systemen steuern Sie jeden dieser Dienste mit dem Befehl service — auf aktuellen systemd-basierten Systemen nutzen Sie dazu systemctl.

Früher hatten Computer deutlich weniger Ressourcen, so dass es kein guter Ansatz war, viele Dienste im Standalone-Modus gleichzeitig laufen zu lassen. Stattdessen lauschte ein so genannter Superdaemon auf eingehende Netzwerkverbindungen und startete bei Bedarf den entsprechenden Dienst. Diese Methode zum Aufbau von Netzverbidnungen nahm allerdings etwas mehr Zeit in Anspruch. Bekannte Superdaemons sind inetd und xinetd. Auf aktuellen Systemen, die auf systemd basieren, funktioniert die Unit systemd.socket ähnlich. In diesem Abschnitt werden wir mit xinetd Verbindungen zum sshd-Daemon abfangen und diesen Daemon auf Anfrage starten, um zu demonstrieren, wie Sie den Superdaemon nutzen.

Vor der Konfiguration des xinetd-Dienstes sind einige Vorbereitungen notwendig — egal ob Debian- oder Red Hat-basiertes System. Die folgenden Beispiele von einem Debian/GNU Linux 9.9 sollten auf jedem aktuellen Linux-System mit systemd funktionieren, ohne dass Änderungen notwendig sind. Stellen Sie zunächst sicher, dass die Pakete openssh-server und xinetd installiert sind. Überprüfen Sie nun, dass der SSH-Dienst aktiv ist:

$ systemctl status sshd
● ssh.service - OpenBSD Secure Shell server
   Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2020-04-27 09:33:48 EDT; 3h 11min ago
     Docs: man:sshd(8)
           man:sshd_config(5)
  Process: 430 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS)
 Main PID: 460 (sshd)
    Tasks: 1 (limit: 1119)
   Memory: 5.3M
   CGroup: /system.slice/ssh.service
           └─460 /usr/sbin/sshd -D

Vergewissern Sie sich auch, dass der SSH-Dienst auf seinem Standardnetzwerkport 22 lauscht:

# lsof -i :22
COMMAND  PID USER   FD   TYPE   DEVICE SIZE/OFF NODE NAME
sshd    1194 root    3u  IPv4 16053268      0t0  TCP *:ssh (LISTEN)
sshd    1194 root    4u  IPv6 16053270      0t0  TCP *:ssh (LISTEN)

Beenden Sie schließlich den SSH-Dienst wie folgt:

$ sudo systemctl stop sshd.service

Sollen diese Änderungen dauerhaft sein und einen Neustart überdauern, verwenden Sie systemctl disable sshd.service.

Nun erstellen Sie die xinetd-Konfigurationsdatei /etc/xinetd.d/ssh mit einigen Grundeinstellungen:

service ssh
{
	disable		= no
	socket_type	= stream
	protocol	= tcp
	wait		= no
	user		= root
	server		= /usr/sbin/sshd
	server_args 	= -i
	flags		= IPv4
	interface	= 192.168.178.1
}

Starten Sie den xinetd-Dienst neu:

$ sudo systemctl restart xinetd.service

Prüfen Sie, welcher Dienst jetzt auf eingehende SSH-Verbindungen lauscht:

$ sudo lsof -i :22
COMMAND   PID USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
xinetd  24098 root    5u  IPv4 7345141      0t0  TCP 192.168.178.1:ssh (LISTEN)

Wir sehen, dass der xinetd-Dienst die Kontrolle über den Zugriff auf Port 22 übernommen hat.

Hier einige weitere Details über die xinetd-Konfiguration. Die wichtigste Konfigurationsdatei ist /etc/xinetd.conf:

# Simple configuration file for xinetd
#
# Some defaults, and include /etc/xinetd.d/

defaults
{

# Please note that you need a log_type line to be able to use log_on_success
# and log_on_failure. The default is the following :
# log_type = SYSLOG daemon info

}

includedir /etc/xinetd.d

Neben den Standardeinstellungen gibt es nur eine Anweisung für ein Include-Verzeichnis. Darin können Sie für jeden Dienst, den xinetd verwalten soll, eine eigene Konfigurationsdatei anlegen. Wir haben dies oben für den SSH-Dienst bereits erledigt und die Datei /etc/xinetd.d/ssh genannt. Die Namen der Konfigurationsdateien sind frei wählbar, mit Ausnahme von Dateinamen, die einen Punkt (.) enthalten oder mit einer Tilde (~) enden. Es ist jedoch gängige Praxis, die Datei nach dem jeweiligen Dienst zu benennen.

Einige Konfigurationsdateien im Verzeichnis /etc/xinet.d/ stellt die Distribution bereit:

$ ls -l /etc/xinetd.d
total 52
-rw-r--r-- 1 root root 640 Feb  5  2018 chargen
-rw-r--r-- 1 root root 313 Feb  5  2018 chargen-udp
-rw-r--r-- 1 root root 502 Apr 11 10:18 daytime
-rw-r--r-- 1 root root 313 Feb  5  2018 daytime-udp
-rw-r--r-- 1 root root 391 Feb  5  2018 discard
-rw-r--r-- 1 root root 312 Feb  5  2018 discard-udp
-rw-r--r-- 1 root root 422 Feb  5  2018 echo
-rw-r--r-- 1 root root 304 Feb  5  2018 echo-udp
-rw-r--r-- 1 root root 312 Feb  5  2018 servers
-rw-r--r-- 1 root root 314 Feb  5  2018 services
-rw-r--r-- 1 root root 569 Feb  5  2018 time
-rw-r--r-- 1 root root 313 Feb  5  2018 time-udp

Diese Dateien dienen als Vorlagen für den seltenen Fall, dass Sie einige Legacy-Dienste wie daytime, eine sehr frühe Implementierung eines Zeitservers, einsetzen müssen. All diese Vorlagendateien enthalten die Direktive disable = yes.

Hier weitere Details zu den Direktiven in der Beispieldatei /etc/xinetd.d/ssh für ssh:

service ssh
{
	disable		= no
	socket_type	= stream
	protocol	= tcp
	wait		= no
	user		= root
	server		= /usr/sbin/sshd
	server_args 	= -i
	flags		= IPv4
	interface	= 192.168.178.1
}
service

Benennt den von xinetd kontrollierten Dienst. Setzen Sie entweder eine Portnummer (z.B. 22) oder den Namen, der der Portnummer in /etc/services zugeordnet ist (z.B. ssh).

{

Detaillierte Einstellungen beginnen mit einer öffnenden geschweiften Klammer.

disable

Um die Einstellungen zu aktivieren, setzen Sie diese Option auf no. Um die Einstellung vorübergehend zu deaktivieren, setzen Sie sie auf yes.

socket_type

Wählen Sie stream für TCP-Sockets oder dgram für UDP-Sockets — weitere sind möglich.

protocol

Wählen Sie TCP oder UDP.

wait

Für TCP-Verbindungen normalerweise auf no gesetzt.

user

Der gestartete Dienst gehört diesem Benutzer.

server

Vollständiger Pfad zu dem Dienst, den xinetd starten soll.

server_args

Weitere Optionen für den Dienst — wird er von einem Superserver gestartet, benötigen viele Dienste eine spezielle Option. Für SSH wäre dies die Option -i.

flags

Sie können IPv4, IPv6 und andere wählen.

interface

Die Netzwerkschnittstelle, die xinetd zu kontrollieren hat. Sie können auch die bind-Direktive wählen, die nur ein Synonym für interface ist.

}

Die Einstellungen schließen mit einer schließenden geschweiften Klammer.

Die Nachfolger der vom Superdaemon xinetd gestarteten Dienste sind systemd-Socket-Units. Deren Einrichtung ist unkompliziert, da es bereits eine vordefinierte systemd-Socket-Unit für SSH gibt. Stellen Sie dazu sicher, dass die Dienste xinetd und SSH nicht laufen.

Jetzt müssen Sie nur noch die SSH-Socket-Unit starten:

$ sudo systemctl start ssh.socket

Um zu überprüfen, welcher Dienst jetzt auf Port 22 lauscht, verwenden wir wieder lsof. Beachten Sie hier die Option -P, um die Portnummer statt des Dienstnamens in der Ausgabe anzuzeigen:

$ sudo lsof -i :22 -P
COMMAND PID USER   FD   TYPE   DEVICE SIZE/OFF NODE NAME
systemd   1 root   57u  IPv6 14730112      0t0  TCP *:22 (LISTEN)

Um diese Beispielsitzung abzuschließen, sollten Sie sich mit einem SSH-Client Ihrer Wahl auf Ihrem Server anmelden.

Tip

Falls systemctl start ssh.socket bei Ihrer Distribution nicht funktioniert, versuchen Sie systemctl start sshd.socket.

Dienste auf unnötige Daemons überprüfen

Aus Sicherheitsgründen und zur Kontrolle der Systemressourcen ist es wichtig, einen Überblick über laufende Dienste zu haben. Unnötige und ungenutzte Dienste sollten Sie abschalten. Wenn Sie zum Beispiel keine Webseiten ausliefern, ist es auch nicht notwendig, einen Webserver wie Apache oder nginx laufen zu lassen.

Auf Sys-V-init basierten Systemen prüfen Sie den Status aller Dienste wie folgt:

$ sudo service --status-all

Entscheiden Sie, ob alle in der Ausgabe aufgeführten Dienste notwendig ist, und deaktivieren Sie die überflüssigen mit (für Debian-basierte Systeme):

$ sudo update-rc.d SERVICE-NAME remove

Auf Red Hat-basierten Systemen lautet der Befehl:

$ sudo chkconfig SERVICE-NAME off

Auf modernen systemd-basierten Systemen listen Sie alle laufenden Dienste wie folgt auf:

$ systemctl list-units --state active --type service

Sie deaktivieren dann jede unnötige Service-Unit wie folgt:

$ sudo systemctl disable UNIT --now

Die Befehl stoppt den Dienst und entfernt ihn aus der Liste der Dienste, so dass er beim nächsten Systemstart nicht mehr gestartet wird.

Für einen Überblick über die lauschenden Netzwerkdienste steht auf älteren Systemen auch netstat zur Verfügung (sofern Sie das Paket net-tools installiert haben):

$ netstat -ltu
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 0.0.0.0:ssh             0.0.0.0:*               LISTEN
tcp        0      0 localhost:mysql         0.0.0.0:*               LISTEN
tcp6       0      0 [::]:http               [::]:*                  LISTEN
tcp6       0      0 [::]:ssh                [::]:*                  LISTEN
udp        0      0 0.0.0.0:bootpc          0.0.0.0:*

Auf modernen Systemen können Sie auch den entsprechenden Befehl ss (für “socket services”) verwenden:

$ ss -ltu
Netid      State         Recv-Q        Send-Q      Local Address:Port           Peer Address:Port
udp        UNCONN        0             0                 0.0.0.0:bootpc              0.0.0.0:*
tcp        LISTEN        0             128               0.0.0.0:ssh                 0.0.0.0:*
tcp        LISTEN        0             80              127.0.0.1:mysql               0.0.0.0:*
tcp        LISTEN        0             128                     *:http                      *:*
tcp        LISTEN        0             128                  [::]:ssh                    [::]:*

TCP-Wrapper als einfache Firewall

In Zeiten, als es noch keine Firewalls für Linux gab, wurden TCP-Wrapper verwendet, um Netzwerkverbindungen zu einem Host zu sichern. Heute gehorchen viele Programme den TCP-Wrappern nicht mehr. Neuere Red Hat basierte Distributionen (z.B. Fedora 29) unterstützen TCP-Wrapper gar nicht mehr. Um ältere Linux-Systeme mit TCP-Wrapper zu verwalten, sind einige Grundkenntnisse über diese spezielle Technologie allerdings hilfreich.

Wir wählen wieder den SSH-Dienst als Beispiel. Der Dienst auf unserem Beispielhost sollte nur vom lokalen Netz aus erreichbar sein. Zuerst prüfen wir, ob der SSH-Daemon die Bibliothek libwrap verwendet, die TCP-Wrapper unterstützt:

$ ldd /usr/sbin/sshd | grep "libwrap"
        libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0 (0x00007f91dbec0000)

Nun fügen wir die folgende Zeile in die Datei /etc/hosts.deny ein:

sshd: ALL

Schließlich konfigurieren wir in der Datei /etc/hosts.allow eine Ausnahme für SSH-Verbindungen aus dem lokalen Netz:

sshd: LOCAL

Die Änderungen werden sofort wirksam — es ist also nicht notwendig, einen Dienst neu zu starten. Prüfen Sie das Ergebnis mit einem ssh-Client.

Geführte Übungen

  1. Wie schalten Sie das zuvor gesperrte Konto emma wieder frei?

  2. Das Konto emma hat aktuell ein Verfallsdatum. Wie setzen Sie das Verfallsdatum auf “nie”?

  3. Der Dienst CUPS, der Druckaufträge verarbeitet, wird auf Ihrem Server nicht benötigt. Wie deaktivieren Sie den Dienst dauerhaft? Wie überprüfen Sie, dass der entsprechende Port nicht mehr aktiv ist?

  4. Sie haben den Webserver nginx installiert. Wie überprüfen Sie, ob nginx TCP-Wrapper unterstützt?

Offene Übungen

  1. Prüfen Sie, ob die Existenz der Datei /etc/nologin die Anmeldung des Benutzers root verhindert.

  2. Verhindert das Vorhandensein der Datei /etc/nologin passwortlose Anmeldungen mit SSH-Schlüsseln?

  3. Was passiert beim Login, wenn die Datei /etc/nologin nur die Textzeile login is currently not possible enthält?

  4. Erhält der normale Benutzer emma Informationen über den Benutzer root in der Datei /etc/passwd, z.B. mit dem Befehl grep root /etc/passwd?

  5. Erhält der normale Benutzer emma Informationen über sein eigenes gehashtes Passwort in der Datei /etc/shadow, z.B. mit dem Befehl grep emma /etc/shadow?

  6. Mit welchen Schritten aktivieren Sie den alten Dienst daytime und prüfen, ob xinetd ihn verwaltet? Dies ist nur eine Übung, die Sie nicht in einer Produktionsumgebung ausführen sollten!

Zusammenfassung

In dieser Lektion haben Sie gelernt:

  1. In welcher Datei Passwörter gespeichert werden sowie einige Einstellungen zur Passwortsicherheit, z.B. die Ablaufzeit.

  2. Der Zweck des Superdaemons xinetd, wie Sie ihn zum Laufen bringen und wie er den sshd-Dienst bei Bedarf startet.

  3. Wie sie überprüfen, welche Netzwerkdienste laufen und wie Sie unnötige Dienste deaktivieren.

  4. Wie Sie TCP-Wrapper als einfache Firewall einsetzen.

Folgende Befehle haben wir genutzt:

chage

Ändert das Alter des Passworts eines Benutzers.

chkconfig

Ein klassischer Befehl — ursprünglich auf Red Hat-basierten Systemen — über den Sie festlegen, ob ein Dienst beim Booten gestartet werden soll oder nicht.

netstat

Ein klassisches Dienstprogramm (jetzt im Paket net-tools), das Daemons, die auf Netzwerkports auf einem System zugreifen, und deren Nutzung anzeigt.

nologin

Ein Befehl, mit dem Sie statt über die Shell eines Benutzers verhindern, dass er sich anmeldet.

passwd

Erstellt oder ändert das Passwort eines Benutzers.

service

Ältere Methode, um den Status eines Daemons zu kontrollieren, z.B. Stopp oder Start eines Dienstes.

ss

Das moderne Pendant zu netstat, das auch mehr Informationen über die verschiedenen Sockets anzeigt, die auf dem System verwendet werden.

systemctl

Der Befehl, mit dem Sie verschiedene Aspekte der Dienste und Sockets auf einem Rechner mit systemd steuern.

update-rc.d

Ein klassischer Befehl (ähnlich chkconfig), der den Start eines Systems beim Booten auf Debian-basierten Distributionen aktiviert oder deaktiviert.

xinetd

Ein Superdaemon, der den Zugriff auf einen Netzwerkdienst bei Bedarf kontrolliert, so dass ein Dienst inaktiv bleibt, bis er tatsächlich zur Ausführung einer Aufgabe aufgerufen wird.

Lösungen zu den geführten Übungen

  1. Wie schalten Sie das zuvor gesperrte Konto emma wieder frei?

    Der Superuser führt passwd -u emma aus, um das Konto zu entsperren.

  2. Das Konto emma hat aktuell ein Verfallsdatum. Wie setzen Sie das Verfallsdatum auf "`nie`?

    Der Superuser führt chage -E -1 emma aus, um das Verfallsdatum auf “nie” zu setzen. Diese Einstellung überprüfen Sie mit chage -l emma.

  3. Der Dienst CUPS, der Druckaufträge verarbeitet, wird auf Ihrem Server nicht benötigt. Wie deaktivieren Sie den Dienst dauerhaft? Wie überprüfen Sie, dass der entsprechende Port nicht mehr aktiv ist?

    Als Superuser folgenden Befehl ausführen:

    systemctl disable cups.service --now

    Nun wie folgt die Inaktivität überprüfen:

    netstat -l | grep ":ipp "` or `ss -l | grep ":ipp "
  4. Sie haben den Webserver nginx installiert. Wie überprüfen Sie, ob nginx TCP-Wrapper unterstützt?

    Der Befehl

    ldd /usr/sbin/nginx | grep "libwrap"

    zeigt einen Eintrag an, wenn nginx TCP-Wrapper unterstützt.

Lösungen zu den offenen Übungen

  1. Prüfen Sie, ob die Existenz der Datei /etc/nologin die Anmeldung des Benutzers root verhindert?

    Der Benutzer root kann sich weiterhin anmelden.

  2. Verhindert das Vorhandensein der Datei /etc/nologin passwortlose Anmeldungen mit SSH-Schlüsseln?

    Ja, auch passwortlose Anmeldungen werden verhindert.

  3. Was passiert beim Login, wenn die Datei /etc/nologin nur die Textzeile login is currently not possible enthält?

    Es erscheint die Meldung login is currently not possible, und eine Anmeldung wird verhindert.

  4. Erhält der normale Benutzer emma Informationen über den Benutzer root in der Datei /etc/passwd, z.B. mit dem Befehl grep root /etc/passwd?

    Ja, denn alle Benutzer haben Leserechte für diese Datei.

  5. Erhält der normale Benutzer emma Informationen über sein eigenes gehashtes Passwort in der Datei /etc/shadow, z.B. mit dem Befehl grep emma /etc/shadow?

    Nein, denn normale Benutzer haben keine Leseberechtigung für diese Datei.

  6. Mit welchen Schritten aktivieren Sie den alten Dienst daytime und prüfen, ob xinetd ihn verwaltet? Dies ist nur eine Übung, die Sie nicht in einer Produktionsumgebung ausführen sollten!

    Zuerst ändern Sie die Datei /etc/xinetd.d/daytime und setzen die Direktive disable = no. Danach starten Sie den xinetd-Dienst neu: systemctl restart xinetd.service (oder service xinetd restart auf Systemen mit SyS-V-Init). Jetzt prüfen Sie, ob es funktioniert: nc localhost daytime. Anstelle von nc können Sie auch netcat verwenden.

Linux Professional Insitute Inc. Alle Rechte vorbehalten. Besuchen Sie die LPI Learning Website: https://learning.lpi.org
Dieses Werk steht unter der Lizenz Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International.

Linux Professional Insitute Inc. Alle Rechte vorbehalten. Besuchen Sie die LPI Learning Website: https://learning.lpi.org
Dieses Werk steht unter der Lizenz Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International.

LPI ist eine Non-Profit-Organisation.

© 2023 Linux Professional Institute (LPI) ist eine globale Organisation für Zertifizierungsstandards und zur Karriereplanung für Open-Source-Profis. Mit mehr als 200.000 Zertifikatsinhabern ist es die weltweit erste und größte herstellerneutrale Linux- und Open-Source-Zertifizierungsstelle. LPI verfügt über zertifizierte Fachleute in über 180 Ländern, bietet Prüfungen in mehreren Sprachen an und hat Hunderte von Trainingspartnern.

Unser Ziel ist es, wirtschaftliche und kreative Möglichkeiten für alle zu ermöglichen, indem wir Open-Source-Wissens- und Kompetenzzertifizierungen allgemein zugänglich machen.

  • LinkedIn
  • flogo-RGB-HEX-Blk-58 Facebook
  • Twitter
  • Kontaktieren Sie uns
  • Datenschutz und Cookie-Richtlinien

Haben Sie einen Fehler entdeckt oder möchten Sie helfen, diese Seite zu verbessern? Lassen Sie es uns wissen.

© 1999–2023 The Linux Professional Institute Inc. Alle Rechte vorbehalten.