6. Bremer IT-Sicherheitstag

IT-Sicherheit – Auf dem Stand der Technik

Das Gesetz zur Erhöhung der Sicherheit informationstechnischer Systeme (ITSiG) und die Folgen

 Die Sicherheit von Informationen sowie der Schutz von Daten gewinnen immer mehr an Wichtigkeit. Das Gesetz zur Erhöhung der Sicherheit informationstechnischer Systeme (ITSiG) schreibt Betreibern von kritischen Infrastrukturen (KTITIS) sowie jedem Unternehmen, das eine Website unterhält vor, angemessene organisatorische und technische Vorkehrungen nach dem „Stand der Technik” (SdT) zum Schutz ihrer informationstechnischer Systemen hinsichtlich Verfügbarkeit, Integrität, Authentizität und Vertraulichkeit zu treffen. Dies stellt Unternehmen vor neue Herausforderungen und führt bei vielen, auf Grund des vom Gesetzgeber unbestimmten Rechtsbegriffs „Stands der Technik“, zu Unklarheit und Unsicherheit.
Auf dem 6. Bremer IT-Sicherheitstag geben Ihnen unsere Spezialisten Orientierung. Sie beleuchten das ITSiG, präzisieren anhand ausgewählter Szenarien den “Stand der Technik” und liefern Anregungen für die Umsetzung in der Praxis.

Wie kann man die Integrität der installierten Dateien auf einem Debiansystem leicht überprüfen?

Wenn man Monitoringtools wie tripwire oder rkhunter verwendet, um Veränderungen von installieren Dateien zu überwachen, hat man das Problem, dass die Tools nicht erkennen, ob die Dateien durch ein reguläres Paketupgrade verändert oder durch einen Unbefugten manipuliert wurden.

Wenn z.B. rkhunter meldet, dass die Datei /usr/bin/ldd verändert wurde, muss man manuell nachschauen, ob die Prüfsumme der Datei dem neusten Stand des Debianpaktes entspricht.

Es gibt ein Tool names debsums, der diese Aufgabe erleichtert. Die Installation erfolgt mit:

# apt-get install debsums

Nachdem das Tool installiert ist, kann man die Überprüfung auf Paket-Ebene durchführen:

# debsums file
/usr/bin/file OK
/usr/share/bug/file/control OK
/usr/share/bug/file/presubj OK
/usr/share/doc/file/README.Debian OK
/usr/share/doc/file/README.gz OK
/usr/share/doc/file/changelog.Debian.gz OK
/usr/share/doc/file/changelog.gz OK
/usr/share/doc/file/copyright OK
/usr/share/lintian/overrides/file OK
/usr/share/man/man1/file.1.gz OK

aber nicht auf Dateiebene:

# debsums /usr/bin/ldd
debsums: invalid package name ‚/usr/bin/ldd‘

Man muss zuerst herausfinden, zu welchem Paket die Datei /usr/bin/ldd gehört.

# dpkg -S /usr/bin/ldd
libc-bin: /usr/bin/ldd

Damit man die Suche nicht jedes ausführen muss, hab ich ein kleines Shellscript geschrieben, der die diese Aufgabe übernimmt und mit den Ergebnissen debsums aufruft:

#!/bin/bash
EC=0
PKGS=$(dpkg -S „$@“ | awk -F‘:‘ ‚{print $1}‘ | sed -e ’s/, /\n/g‘ | sort | uniq)
for i in $PKGS; do
debsums „$i“ | grep -v OK
dec=$PIPESTATUS
echo -n „=== Package ‚$i‘ : “
if [ $dec -eq 0 ]; then echo OK; else echo MODIFIED; EC=$dec; fi
done
exit $EC

In diesem Beispiel habe ich das Skipt check-inst.sh genannt. Die Nutzung ist einfach:

# ./check-inst.sh /usr/bin/ldd
=== Package ‚libc-bin‘ : OK

Man kann das Skript mit mehreren Dateinamen aufrufen:

# ./check-inst.sh /usr/bin/file /usr/bin/ldd
=== Package ‚file‘ : OK
=== Package ‚libc-bin‘ : OK

Wenn man keinen absoluten Pfad verwendet bekommt man Suchergebnisse von installierten Paketen:

# ./check-inst.sh apache2
=== Package ‚apache2‘ : OK
=== Package ‚apache2.2-bin‘ : OK
=== Package ‚apache2.2-common‘ : OK
=== Package ‚apache2-doc‘ : OK
=== Package ‚apache2-mpm-prefork‘ : OK
=== Package ‚apache2-suexec‘ : OK
=== Package ‚apache2-utils‘ : OK
=== Package ‚bash-completion‘ : OK
=== Package ‚libapache2-mod-fcgid‘ : OK
=== Package ‚libapache2-mod-php5‘ : OK
=== Package ‚libapache2-mod-ruby‘ : OK
=== Package ‚libapache2-mod-suphp‘ : OK

Wenn die Ergebnisse OK sind, kann man mit ruhigem Gewissen sein Monitoringtool auf den neuen Stand bringen. Z.B. bei rkhunter:

# rkhunter –propupd –update

Hier ist eine Beispielausgabe, die die vom Benutzer modifizierten Dateien anzeigt:

# ./check-inst.sh /usr/bin/pear
/usr/bin/pear FAILED
/usr/bin/peardev FAILED
/usr/bin/pecl FAILED

/usr/share/php/pearcmd.php FAILED
/usr/share/php/peclcmd.php FAILED
=== Package ‚php-pear‘ : MODIFIED

Das Skript gibt den ExitCode 0 zurück, wenn alle Überprüfungen erfolgreich waren, ansonsten den Fehlercode des erst fehlgeschlagener Überprüfung. Dies ist nützlich, wenn man zunächst nur an ExitCode interessiert ist und die Fehlergebnisse von einer Logdatei auslesen möchte.

Viel Spaß beim Ausprobieren
C.