Vortragsreihe Systemsicherheit unter Linux

Das Sicherheitstool COPS

1.) Einführung

Das Sicherheitstool COPS (Computer Oracle and Password System) ist dazu gedacht von cron aus täglich ausgeführt zu werden und ihre Systemdateien zu überprüfen und Sicherheitslöcher automatisch zu finden. COPS kennt verschiedene allgemeine und architekturabhängige Sicherheitslöcher. Leider kennt COPS keine Linux spezifischen Sicherheitslöcher, aber schließlich wissen wir, daß Linux keine Fehler hat. :-) COPS prüft die Konfigurationsfiles, was wie im vorliegenden Bericht zu Meldungen über Unsicherheiten führen kann, welche gar nicht vorhanden sind. (Im vorliegenden Fall wird ein Export von Filesystemen per NFS ohne jegliche Restriktionen erkannt, obwohl NFS gar nicht gestartet wurde.) Solche Meldungen deuten wie man sieht immer auf potentielle Probleme hin und sollten daher ebenfalls Beachtung finden. Einige Meldungen deuten auch nur auf scheinbare Probleme, wie z.B. die negative UID des Users nobody. Wie man sieht ist blindes Vertrauen in solche automatischen Tools nicht zu empfehlen. Trotzdem hoffe ich, daß mein Vortrag Sie überzeugen wird, daß COPS Ihnen die Arbeit erleichtern kann und eine wertvolle Hilfe ist, um Probleme Ihrer Systeme frühzeitig zu erkennen. Was kann COPS nun im einzelnen?

COPS kann seine Berichte auf Wunsch per Mail versenden. Dabei können die kompletten Berichte oder nur die Änderungen zum letzten Bericht versendet werden.
COPS prüft die Rechte der Gerätedateien, welche in /etc/fstab aufgeführt sind. Dabei wird auch /etc/exports mit überprüft.
COPS prüft bekannte architekturabhängige Sicherheitsprobleme.
COPS prüft bekannte allgemeine Sicherheitsprobleme.
COPS prüft die in der crontab aufgeführten Befehle und Dateien. (Schreibrechte)
COPS prüft die /etc/fstab sehr gründlich auf allgemeine und sicherheitsrelevante Fehler.
COPS kann optional Änderungen an Dateien durch CRC-Files aufdecken. Es wird empfohlen dieses Feature interaktiv zu nutzen.
COPS beinhaltet ein Tool namens Kuang, welches versucht auf indirektem Weg Zugang zum System zu erhalten.
COPS prüft den ftp-Server und den tftp-Server.
COPS bringt weitere nützliche Tools mit, wie zum Beispiel ein Tool zur Erzeugung von Berichten und zur interaktiven Prüfung von Accounts durch den Nutzer.

COPS ist erhältlich bei ftp.cert.org oder natürlich auch bei ftp.cert.dfn.de .

2.) Installation

COPS liegt in einer klassischen Variante aus Shell-Scripten und C-Programmen und in einer Perl-Variante vor. Die Perl-Variante besitzt einige Features noch nicht, ist aber auf spezielle Dinge wie zum Beispiel das Password-Shadow-System besser anzupassen. Die klassische Variante, welche ich getestet habe ist sehr elegant zu installieren und gibt auch ohne RPM zu der Hoffnung auf eine saubere Deinstallation Anlass.

Nun wollen wir aber beginnen und entpacken COPS in unserem Home-Verzeichnis als ganz normaler Nutzer. Anschließend wechseln wir in das neue Verzeichnis und sehen einige Dateien und ein paar Unterverzeichnisse, zu welchen ich später noch komme, und lesen die README-Dateien in der vorgegebenen Reihenfolge. Diese Reihenfolge ist davon abhängig, ob wir die klassische Variante oder die Perl-Variante installieren wollen. Als nächstes ändern wir im Makefile die allererste Makrodefinition (INSTALL_DIR) entsprechend unseres gewünschten Zielverzeichnises. Außerdem müssen wir noch die Konstante ARB_CONST in pass.c im Verzeichnis src (dort stehen die C-Quellen) etwas erhöhen. Nun führen wir (unabhängig von unserer gewälten Variante)

make man
gzip docs/*.1
mv docs/*.1.gz /usr/man/man1/
su

chown root /usr/man/man1/*
chgrp root /usr/man/man1/*
chmod a+r /usr/man/man1/*
logout

Je nach Variante führen wir nun aus: Bei der Perl-Variante

cd perl
reconfig

Und nun muß das COPS-Perl-Script angepasst werden. (README.pl) Da COPS noch kein Shadow-Password-System kennt muß pass.pl umgeschrieben werden! (Option P funktioniert noch nicht für pass.pl) Eventuell lässt sich aber die pass.c Variante hier einschleusen. (Vorher bitte übersetzen.)

Bei der klassischen Variante führen wir

reconfig
make

aus und ändern im Script cops die Variablen

MMAIL=(NO/YES)  # Wollen wir die Berichte per Mail erhalten?
LANGUAGE=german # Funktioniert wohl noch nicht so ganz.
ONLY_DIFF=YES   # Nur die Änderungen zum letzten Bericht per Mail versenden?
RUN_SUID=YES    # Programme die unter SUID laufen finden?
BIT_BUCKET=/dev/null # Wohin mit Fehlern während des COPS-Laufes? 
VERBUCKET=/dev/null  # Wohin mit dem blah blah?
SECURE=/usr/foo/bar  # Das COPS-Verzeichnis
SECURE_USERS="foo@bar.edu" # Unsere Mailadresse

Es ist nicht zu empfehlen die Mails über den als sicher bekannten Bereich hinauszuschicken. (Also das eigene System, die eigene Abteilung oder die eigene Organisation, denn wer hat gesagt, das nicht irgendjemand unsere Mail liest oder auf COPS Berichte hin untersucht.)

Da unsere /etc/passwd auf Grund des Password-Shadow-System keine Passwörter mehr enthält, fügen wir dem Aufruf von pass die Optionen

-w /pfad/zum/woerter/buch/woerter.buch -P /etc/shadow zu.

Da /etc/shadow natürlich kein GECOS-Feld enthält kann hier kein Abgleich erfolgen, ob Wörter aus diesem Feld als Passwort verwendet wurden. Hier müsste mit Hilfe eines Scriptes die /etc/passwd vor dem COPS-Lauf kopiert und die Passwörter aus der /etc/shadow in das kopierte File übertragen werden. (umask 077 setzen!) COPS kann beim Passwort cracken zwar nicht mit CRACK mithalten, ist aber nicht schlecht. Von hinten geschriebene Wörter, Passwörter mit Sonderzeichen oder eine Wortkombination aus Wörtern in .plan kann COPS aber nicht finden. Außerdem scheint der bei COPS dem Programm pass.chk zu Grunde liegende Algorithmus nicht so effektiv zu sein, wie bei CRACK.

Beim kuang Aufruf entscheiden wir uns für die klassische oder die kuang.pl Variante, welche mehr Features bieten soll. (Achtung dann muß

cd perl
reconfig

nachgeholt werden und später muß kuang.pl per Hand in das Zielverzeichnis übertragen werden.)

crc.chk lassen wir besser auskommentiert. Wenn wir suid.chk von den "#" befreihen sollten wir es auch einschalten! (siehe weiter oben)

Nun installieren wir COPS:

su
make install

Und wir testen:

/pfad/zum/cops/verzeichnis/cops &

COPS legt seine Berichte unter /pfad/zum/cops/verzeichnis/hostname ab, was in den Filesystemstandart nicht so ganz hineinpasst. Deshalb verschieben wir diese Verzeichnisse an einen geeigneten Ort unter /var und setzten einen Link dorthin. Der Inhalt eines solchen Verzeichnises sieht dann in etwa wie folgt aus:

total 6
-rw-------   1 root     root          617 Oct  1 17:24 1997_Oct_1
-rw-------   1 root     root          691 Oct  5 18:40 1997_Oct_5
-rw-------   1 root     root          744 Oct  6 03:58 1997_Oct_6
-rw-------   1 root     root         1155 Oct  7 01:30 1997_Oct_7
-rw-------   1 root     root          618 Sep 30 01:32 1997_Sep_30

3.) Erweiterungen

Soweit zu COPS in der Grundkonfiguration. Da COPS aus verschiedenen einzelnen Scripten und C-Tools besteht läßt es sich leicht an die eigenen Bedürfnisse anpassen. Die soll im folgenden an einem Beispiel gezeigt werden. Zuvor soll jedoch noch auf die verschiedenen Unterverzeichnisse, welche wir in dem durch das Entpacken des Tar-Files erzeugten COPS-Verzeichnis finden, eingegangen werden.

Unter docs liegen die Manual-Pages, welche wir ja schon übersetzt und in das Verzeichnis /usr/man/man1 geschoben haben. Das unter src die C-Quellen liegen dürfte auch keine Überraschung sein, genausowenig wie die Perl-Version, welche natürlich unter Perl liegt. Warum jedoch unter extensions diverse Texte zu finden sind bleibt unverständlich. Unter dem Verzeichnis carp finden wir das gleichnamige Programm (COPS Analysis and Report Programm) welches uns sehr schöne Übersichten über unsere Systeme zeigt.

COPS warning summary

hostname      rep date     crn dev ftp grp hme is pass msc pwd rc root usr kng
===============================================================================
walhall       1997_Oct_7  |   | 2 | 2 |   | 1 |   | 2 |   | 2 |   |   |   |   |

Besonders geeignet ist das Tool also, wenn wir mehrere Systeme mit COPS überwachen. (Hier ist eventuell auch ein Grund zu sehen, warum die Berichte unter dem COPS-Verzeichnis abgelegt werden und nicht unter einem Verzeichnis unter /var.) Sehr schön ist auch die Möglichkeit der Umwandlung unserer ASCII-Berichte in Postscript-Files mit

carp2ps carpbericht

Bevor wir jedoch diese schönen Berichte erhalten müssen wir die richtigen Pfade in carp und carp2ps eintragen. Carp muß immer aus seinem Heimatverzeichnis heraus gestartet werden. Zu beachten ist jedoch, daß carp diese Berichte nur erzeugen kann, wenn cops mit der Option -v gestartet wurde.

Im Verzeichnis checkacct befindet sich ein Tool, welches allen Usern zugänglich gemacht werden sollte. Eventuell kann dieses Tool auch für alle User in /etc/profile eingebunden werden. Checkacct findet GROBE Fehler in der persönlichen Konfiguration. Hier sind besonders die Files $HOME/.[a-z]* zu nennen. Das Tool arbeitet interaktiv und ist auch recht geschwätzig, WENN es einen Fehler findet. Die Behebung des Fehlers erfolgt allerdings ohne Rückfrage an den Nutzer. Um das Tool zu installieren editieren wir das File sysV.m4 (es sind wieder die richtigen Pfade auf unserem System gesucht) und setzen einen Link default.m4 auf dieses File. Außerdem muß noch DESTDIR im Makefile mit dem Namen unseres gewünschten Zielverzeichnises versehen werden.

Unter extra_src finden sich noch einige Tools, die nicht auf jedem System notwendig sind. Ihnen allen gemeinsam ist, daß es Shell-Scripten sind und daher in jedem vor der Anwendung die Pfade korrekt zu setzen sind.

Am Beispiel des dort vorhandenen Tools mail.chk möchte ich nun zeigen, wie einfach es ist cops zu erweitern. Zunächst schieben wir das Tool (nachdem wir die Pfade korrekt gesetzt haben) in das COPS-Verzeichnis (ich erinnere wieder einmal an die umask 077). Nun müssen wir im COPS-Script die Variable SECURE_PROGRAMMS um mail.chk erweitern:

SECURE_PROGRAMS="root.chk dev.chk is_able.chk group.chk \
                 home.chk rc.chk passwd.chk pass.chk misc.chk ftp.chk \
                 cron.chk user.chk init_kuang kuang addto \
                 clearfiles filewriters members is_able bug.chk"

Nachdem wir die folgenden Zeilen in das COPS-Script nach bug.chk eintragen haben sind wir schon fertig.

#
# Bug.chk?  New stuff...
if $TEST -n "$verbose" ; then
        $ECHO "**** bug.chk ****" >> $VERBUCKET ; fi
$SECURE/bug.chk         >>      $RESULT 2>> $BIT_BUCKET

if $TEST -n "$verbose" ; then
        $ECHO "**** mail.chk ****" >> $VERBUCKET ; fi
$SECURE/mail.chk                >>      $RESULT 2>> $BIT_BUCKET

Wie man sieht ist es eigentlich nur eine Abschreibeübung welche zum größten Teil auch noch der Editor für uns erledigt. Zum Schluss möchte ich noch einen Beispielreport von COPS zeigen, bei welchem auch die Ausgaben durch die Erweiterung um das mail.chk Tool schon enthalten sind:

ATTENTION:
Security Report for Tue Oct 7 07:16:24 CEST 1997
from host walhall


**** root.chk ****
**** dev.chk ****
Warning!  NFS file system  exported with no restrictions!
Warning!  NFS file system  exported with no restrictions!
Warning!  NFS file system  exported with no restrictions!
Warning!  NFS file system  exported with no restrictions!
**** is_able.chk ****
**** rc.chk ****
**** cron.chk ****
**** group.chk ****
**** home.chk ****
Warning!  User nobody's home directory /tmp is mode 01777!
Warning!  User wwwrun's home directory /tmp is mode 01777!
**** passwd.chk ****
Warning!  Password file, line 13, negative user id: 
	nobody:x:-2:-2:nobody:/tmp:/bin/false
**** user.chk ****
**** misc.chk ****
**** ftp.chk ****
Warning! Home directory for ftp doesn't exist!
**** pass.chk ****
Warning!  Password Problem: null passwd:	test1	shell: 
Warning!  Password Problem: Guessed:	coadmin	shell:  passwd: Wirtschaft
**** kuang ****
**** bug.chk ****
**** mail.chk ****
Warning: problem files in /var/spool/mail:
-rw-------   1 503      mail            0 Mar 12  1997 hacker
-rw-r--r--   1 jan      mail            0 Aug 23  1996 jan
-rw-------   1 test1    mail            0 Mar 17  1997 player
-rw-------   1 test1    mail            0 Dec 31  1996 test
-rw-------   1 503      users           0 Oct  5 18:23 test5
-rw-------   1 test4    mail            0 Mar 17  1997 user_abc

Die Fehlermeldungen über NFS kommen dadurch zustande, daß COPS sich für die Konfigurationsfiles interessiert und nicht dafür, ob der Dienst wirklich läuft. Bei den übrigen Fehlermeldungen habe ich natürlich etwas nachgeholfen.

Was nun noch bleibt ist der Eintrag von COPS in die crontab. Achtung! Wenn COPS mehr als einmal pro Tag aufgerufen wird wird der jeweils letzte Bericht des Tages überschrieben.

Nicht kommerzielle Nutzung frei.