Rechnerabsicherung durchführen

Wichtung: 3

Beschreibung: Die Kandidaten sollen in der Lage sein, eine Mindestabsicherung von Rechnern (Hosts) durchzuführen.

Wichtigste Wissensgebiete:
Konfiguration von syslog unter Sicherheitsaspekten.
Einrichtung und Verwaltung von Shadow-Passwörtern.
Einrichten eines E-Mail-Alias für root.
Nicht benutzte Netzwerkdienste abschalten.

Liste wichtiger Dateien, Verzeichnisse und Anwendungen:
/etc/xinetd.d/*
/etc/xinetd.conf
/etc/inet.d/*
/etc/inetd.conf
/etc/nologin
/etc/passwd
/etc/shadow
/etc/syslog.conf

Abschalten von nicht benötigten Netzwerkdienste

Mit den Programmen ps, top und netstat können die gestarteten Prozesse und Dienste auf einem System hervorragend angezeigt werden. Beispielsweise zeigt der Befehl "netstat -uta" laufende Dienste und Netzverbindungen an. Natürlich sollte man auch nur die Dienste starten, die letztendlich auch benötigt werden.

Stand-Alone- oder Inetd-basierte Dienste

Werden Dienste als Stand-Alone-Dienste betrieben, d.h. kein Superserver wie Xinetd verwaltet diesen Dienst, so werden diese über ein so genanntes Init-Skript in /etc/init.d/ gestartet. Somit kann man beispielsweise den Apache-Dienst verwalten: 

// Starten von Apache
/etc/init.d/apache2 start

// Stoppen von Apache
/etc/init.d/apache2 stop

// Neustarten von Apache
/etc/init.d/apache2 restart

// Apache lädt Konfigurationsdatei neu ein
/etc/init.d/apache2 reload

Anders sieht es aus, wenn Dienste über den Superserver Inetd gestartet werden. Dann laufen die einzelnen Dienste nicht als Stand-Alone-Server, sondern werden von Inetd "on-demand" gestartet. Somit muss man Inetd konfigurieren, welche Dienste Anfragen entgegennehmen dürfen. Die entsprechenden Konfigurationsdateien lauten /etc/xinetd.conf bzw. /etc/inetd.conf. Wie diese Konfigurationsdateien bearbeitet und Dienste dort aktiviert bzw. deaktiviert werden können, wurde bereits in dem Kapitel LPI 1.113.1 Konfiguration und Verwaltung von xinetd, inetd und den dazugehörigen Diensten erläutert.

nologin - Login durch User sperren

Wenn die Datei /etc/nologin exisistiert, wird der Login für alle Nutzer außer Root verweigert. Dieses gilt unter anderem für login, ssh, telnet, rlogin oder rsh. In dieser Datei kann der Systemverwalter noch angeben, warum die Login gesperrt ist.

Mail Alias für ROOT

In dem Kapitel 1.113.2 Betrieb und grundlegende Konfiguration eines Mail Transfer Agent (MTA) wurde beschrieben, wie man den Mailserver sendmail grundlegend konfiguriert.

Es ist sinnvoll, einen Mail-Alias für Root einzurichten, damit Mails an Root an einen richtigen Mail-Benutzeraccount weitergeleitet werden, beispielsweise um sich Logdateien nach Hause schicken zu lassen. Dazu muss man lediglich einen Eintrag in /etc/aliases setzen 

// Auszug /etc/aliases
root:  123@abc.de

syslogd Dämon - Systemlogger

Syslogd ist einer der weitverbreitesten Linux-Systemlogger. Syslog schreibt alle wichtigen Systemmeldungen in die entsprechenden Logdateien. Über bestimmte Systemaufrufe können Programme Meldungen abgeben, die von einem Systemlogger wie syslogd entgegengenommen und verarbeitet werden. syslogd wird in der Datei /etc/syslog.conf konfiguriert.

 

In der Konfigurationsdatei /etc/syslog.conf wird festgeschrieben, welche Meldungen wie geloggt werden sollen. Die Syntax lautet:

Herkunft.Priorität Aktion

Beispiel: Auszug aus der /etc/syslog.vonf 

# print most on tty10 and on the xconsole pipe
mail.*                          -/var/log/mail
mail.info                       -/var/log/mail.info
mail.warning                    -/var/log/mail.warn
mail.err                         /var/log/mail.err

Herkunft

kern = Kernelmeldungen
auth = Meldungen des System-Sicherheitsdienst, bsp. login
authpriv = Meldungen der internen Sicherheitsdienste
mail = Meldungen des Mail-Systems
news = Meldungen des News-Systems
uucp = Meldungen des UUCP-Systems
lpr = Meldungen des Druckerdaemons
cron = Meldungen des Cron-Daemons
syslog = Meldungen des syslog-Daemons
daemon = Meldungen aller Daemon-Prozesse
user = Meldungen vonAnwenderprogrammen

Priorität

emerg = Ehemals panic, letzte Meldung vorm Absturz
alert = Alarmierende Nachricht
crit = Kritische Situation
err = Fehlermeldungen aller Art
warn = Warnungen
notice = Dokumentation besonders bemerkenswerter Situationen im Rahmen des normalen Betriebs
info = Protokollierung
debug = Interne Programmzustände

Aktionen

In dem meisten Fällen werden die Ausgaben in einer Datei gespeichert. Dazu muss man lediglich den absoluten Pfadnamen angeben: 

// Alle Meldungen in der Datei messages speichern
*.*         /var/log/messages

Mehrere Fehler-/Meldungstypen können kombiniert werden. authpriv.none bedeutet, dass wichtige Informationen wie Passwörter in Klartext nicht ausgegeben werden. 

// Kernel-Warnungen, ALLE Errors auf Root-Shell ausgeben
kern.warn;*.err;authpriv.none   root

Manchmal ist es aber auch erforderlich, dass der Anwender oder Systemverwalter unmittelbar in der Shell benachrichtigt wird. Dazu wird die Meldung auf den Bildschirm ausgegeben: 

// Warnungen auf Shell der User 1, 2, 3 ausgeben
user.warn      user1,user2,user3

Normalerweise werden die Log-Dateien nach jeder Schreibaktion synchronisiert. Dieses kostet Ressourcen, die man einsparen kann (mit dem Risiko, dass nach einem Absturz des Systems Daten verloren gehen). Dieses kann man mit einem - unterbinden 

//Unterbinden der Synchronisation
*.*         -/var/log/messages

Meldungen können auch auf einem anderen Rechner im Netzwerk gespeichert werden. Damit der angesprochene Syslog-Daemon auf dem anderen Rechner auch die Meldungen annimmt, muß er mit der Kommandozeilenoption -r (remote) gestartet worden sein. 

// ALLE Meldung dem Rechner tux-server schicken
*.*          @tux-server