Anleitung zum Absichern von Debian

Transcription

Anleitung zum Absichern von Debian
Javier Fernández-Sanguino Peña <jfs@computer.org>
2.5 (beta) 28 diciembre 2003Sat, 17 Aug 2002 12:23:36 +0200
Zusammenfassung
Dieses Dokument berscheibt den Prozess eine Debian-Standard-Installation abzusichern
und abzuhärten. Es deckt die alltägliche Arbeit, ein sichere Netz-Umgebung mit Debian
GNU/Linux zu schaffen ab, und gibt zusätzlich Informationen über verfügbare SicherheitsTools und die Arbeit des Debian Sicherheit-Teams.
Copyright Hinweis
Copyright © 2002 Javier Fernández-Sanguino Peña
Copyright © 2001 Alexander Reelsen, Javier Fernández-Sanguino Peña
Copyright © 2000 Alexander Reelsen
Dieses Dokument unterliegt der GNU Free Documentation License. Es wird in der Hofnung,
dass es sich als nützlich erweisen könnte, aber OHNE JEDE GEWÄHRLEISTUNG.
i
Inhaltsverzeichnis
1
Introduction
1
1.1
Herunterladen dieser Anleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.2
Organisatorisches / Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.3
Vorwissen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.4
Dinge, die noch geschrieben werden müssen (FIXME/TODO) . . . . . . . . . . .
3
1.5
Changelog/History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
1.5.1
Version 2.5 (august 2002) . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
1.5.2
Version 2.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
1.5.3
Version 2.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
1.5.4
Version 2.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
1.5.5
Version 2.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
1.5.6
Version 2.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
1.5.7
Version 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
1.5.8
Version 1.99 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.5.9
Version 1.98 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.5.10 Version 1.97 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.5.11 Version 1.96 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.5.12 Version 1.95 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.5.13 Version 1.94 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.5.14 Version 1.93 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.5.15 Version 1.92 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.5.16 Version 1.91 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.5.17 Version 1.9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
INHALTSVERZEICHNIS
ii
1.5.18 Version 1.8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.5.19 Version 1.7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.5.20 Version 1.6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.5.21 Version 1.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.5.22 Version 1.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.5.23 Version 1.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.5.24 Version 1.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.5.25 Version 1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.5.26 Version 1.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.6
2
3
Danksagung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Bevor Sie beginnen . . .
17
2.1
Für was möchten Sie dieses System benutzen? . . . . . . . . . . . . . . . . . . . . 17
2.2
Seien Sie Wachsam gegenüber generellen Sicherheitsproblemen! . . . . . . . . . . 17
2.3
Wie geht Debian mit der Sicherheit um? . . . . . . . . . . . . . . . . . . . . . . . . 20
Vor und während der Installation
23
3.1
Setzen Sie ein Passwort im BIOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2
Partitionieren des Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.1
Wählen Sie ein intelligentes Partitions-Schemata . . . . . . . . . . . . . . . 23
3.3
Gehen Sie nicht ins Nezt, bevor Sie nicht bereit sind . . . . . . . . . . . . . . . . . 25
3.4
Setzen Sie ein Passwort für root . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.5
Aktivieren sie “shadow passwords” und “MD5 passwords” . . . . . . . . . . . . 26
3.6
lassen Sie so wenig Services wie möglich laufen . . . . . . . . . . . . . . . . . . . 26
3.7
3.6.1
Daemon-Services abschalten . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.6.2
Abschalten von inetd-Servicen . . . . . . . . . . . . . . . . . . . . . . . . . 28
Installieren Sie möglichst wenig Software, nur die benötigte . . . . . . . . . . . . 28
3.7.1
3.8
Entfernen von Perl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Lesen Sie Debians Sicherheits-Mailinglisten . . . . . . . . . . . . . . . . . . . . . . 31
INHALTSVERZEICHNIS
iii
4
33
Nach der Installation
4.1
Änderungen im BIOS (noch einmal) . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2
Ein Passwort für LILO oder GRUB einstellen . . . . . . . . . . . . . . . . . . . . . 34
4.3
Entfernen des root Promptes aus dem Kernel . . . . . . . . . . . . . . . . . . . . . 35
4.4
Booten von Diskette verbieten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.5
einschränkender Konsolen zugang . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.6
Systemneustart auf der Konsole einschränken . . . . . . . . . . . . . . . . . . . . 37
4.7
Partitionen auf die richtige Art einbinden . . . . . . . . . . . . . . . . . . . . . . . 37
4.7.1
/tmp noexec setzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.7.2
Setzen von /usr auf nur-lesen . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.8
Ausführen von Sicherheitsupdates . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.9
Den Benutzern einen Sicheren Zugang bereitstellen . . . . . . . . . . . . . . . . . 40
4.9.1
User Authentifizierung: PAM . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.9.2
Resourcen-Nutzung limitieren: Die limits.conf Datei . . . . . . . . . . . . 43
4.9.3
User Login Actionen: Editieren von /etc/login.defs . . . . . . . . . . . . . 43
4.9.4
ftp Einschränken: Editieren von /etc/ftpusers . . . . . . . . . . . . . . . . 44
4.9.5
su benutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.9.6
sudo benutzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.9.7
verweigern von administrativen Fernzugriff . . . . . . . . . . . . . . . . . 45
4.9.8
Nutzer einschränken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.9.9
prüfen der Nutzer von Hand . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.9.10 Komplettieren von Nutzer Überwachung . . . . . . . . . . . . . . . . . . . 49
4.9.11 Nutzer Profil nachprüfen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.9.12 umasks der Nutzer einstellen . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.9.13 Nutzer Sicht/Zugriff limitieren . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.10 Die Nutzung von tcpwrappers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.11 Die Wichtigkeit von Logs und Alarmen . . . . . . . . . . . . . . . . . . . . . . . . 52
4.11.1 Nutzen und anpassen von logcheck . . . . . . . . . . . . . . . . . . . . . . 52
4.11.2 Konfigurieren, wohin Alarmmeldungen geschickt werden sollen . . . . . 53
4.11.3 Nutzen eines loghosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.11.4 Zugriffsrechte auf Log-Dateien . . . . . . . . . . . . . . . . . . . . . . . . . 55
INHALTSVERZEICHNIS
iv
4.12 Benutzen von chroot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.12.1 Kernel configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.12.2 Konfigurieren der Netzwerk-Fähigkeiten des Kernels . . . . . . . . . . . . 56
4.12.3 Konfigurieren der Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.13 Den Kernel patchen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.14 Schutz vor Speicher-Überläufen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.15 sichere Datei-Übertragungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.16 Dateisystem Einschränken und konrollieren . . . . . . . . . . . . . . . . . . . . . . 61
4.16.1 Benutzung von Quotas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.16.2 chattr/lsattr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.16.3 Prüfen der Integrität des Dateisystems . . . . . . . . . . . . . . . . . . . . . 63
4.16.4 Aufsetzen von setuid-Check . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.17 Einen Schnappschuss des Systems erstellen . . . . . . . . . . . . . . . . . . . . . . 64
4.18 Andere Empfehlungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.18.1 Benutzen Sie keine Software, die von svgalib abhängt . . . . . . . . . . . . 65
5
Absichern von Servicem die auf Ihrem System laufen
67
5.1
Absichern der Secure-Shell (ssh) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.2
Absicher von Squid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.3
Absichern von FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.4
Zugriff auf das X-Window-System absichern . . . . . . . . . . . . . . . . . . . . . 71
5.4.1
Überprüfen Ihres Display-Managers . . . . . . . . . . . . . . . . . . . . . . 72
5.5
Absichern des Drucker-Zugriffs (Die lpd und lprng Sache) . . . . . . . . . . . . . 72
5.6
Absichern des Mail-Daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.7
sicherer Empfang von Mails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.8
Sichern von BIND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.9
5.8.1
Ändern von BIND User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5.8.2
Chrooten des Name-Server . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Absichern von Apache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.10 Absichern von finger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.11 Allgemeine chroot und suid Paranoia . . . . . . . . . . . . . . . . . . . . . . . . . 83
INHALTSVERZEICHNIS
v
5.12 Allgemeine Klartextpasswort Paranoia . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.13 NIS deaktivieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.14 Abschalten von RPC-Servicen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.15 Hinzufügen von Firewall Fähigkeiten . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.15.1 Firewallen des lokalen Systems . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.15.2 Schützen andere Systeme durch eine Firewall . . . . . . . . . . . . . . . . 85
5.15.3 Konfigurieren der Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
6
7
8
9
Automatishen Abhärten eines Debian Systems
89
6.1
Harden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.2
Bastille Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Paket signierung unter Debian
93
7.1
Der vorgeschlagene Plan zur Prüfung von Paket Signierungen . . . . . . . . . . . 93
7.2
Alternative Einzel-Paket-Signierungs Schemata . . . . . . . . . . . . . . . . . . . . 94
7.3
Prüfen veröffentlichter Pakaete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Sicherheits Tools in Debian
101
8.1
Tools zur Fern-Prüfung der Verwundbarkeit . . . . . . . . . . . . . . . . . . . . . 101
8.2
Netzwerk-Scan Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
8.3
Interne Prüfungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
8.4
Testen von Quellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
8.5
Virtual Private Networks (virtuelle, private Netzwerke) . . . . . . . . . . . . . . . 103
8.6
Öffentliche Schlüssel Infrastrukturen (Public Key Infraestructure (PKI)) . . . . . . 104
8.7
SSL Infrastruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
8.8
Anti-Viren Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Vor einer Komprimitierung
9.1
107
Aufsetzen einer Eindringlingserkennung . . . . . . . . . . . . . . . . . . . . . . . 107
9.1.1
Netzwerk basierende Eindringlings Erkennung . . . . . . . . . . . . . . . 107
9.1.2
Host basierende Erkennung . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
9.2
nützliche Kernel-Patches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
9.3
Vermeiden von Root-Kits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
INHALTSVERZEICHNIS
9.4
vi
9.3.1
LKM - Ladbare Kernel-Module . . . . . . . . . . . . . . . . . . . . . . . . . 109
9.3.2
Erkennen von Root-Kits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
geniale/paranoide Ideen — was Sie tun können . . . . . . . . . . . . . . . . . . . 111
9.4.1
Aufstellen eines Honigtopfes (honeypot) . . . . . . . . . . . . . . . . . . . 113
10 Nach einer Komprimitierung
115
10.1 Allgemeines Verhalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
10.2 Anlegen von Sicherheitskopien Ihres Systems . . . . . . . . . . . . . . . . . . . . . 115
10.3 forensische Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
11 Frequently asked Questions (FAQ)
117
11.1 Sicherheit im Debian Betriebssystem . . . . . . . . . . . . . . . . . . . . . . . . . . 117
11.1.1 Ist Debian sicherer als X? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
11.1.2 In bugtray gibt es viele Debian-Fehler. Heisst das, es ist sehr gefährdet? . 117
11.1.3 Hat Debian irgendein Zertifikat für Sicherheit? . . . . . . . . . . . . . . . . 118
11.1.4 Gibt es irgendein Absicherungsprogramm für Debian? . . . . . . . . . . . 118
11.1.5 Ich möchte eine XYZ-Service laufen lassen. Welchen sollte ich benutzen? . 118
11.1.6 Wie mach ich den Service XYZ unter Debian sicherer? . . . . . . . . . . . 119
11.1.7 Sind alle Debian Pakete sicher? . . . . . . . . . . . . . . . . . . . . . . . . . 119
11.1.8 Betriebssystem User und Gruppen . . . . . . . . . . . . . . . . . . . . . . . 119
11.1.9 Fragen über Services und offene Ports . . . . . . . . . . . . . . . . . . . . . 123
11.1.10 Allgemeine Sicherheits Fragen . . . . . . . . . . . . . . . . . . . . . . . . . 124
11.1.11 Ich möchte meinen Usern einen Service anbieten, Ihnen aber keinen
Shell-Account geben. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
11.2 Mein System ist angreifbar (sicher?) . . . . . . . . . . . . . . . . . . . . . . . . . . 126
11.2.1 Ich habe in meinen Logs einen Angriff gesen: Bin ich kompromitiert? . . . 126
11.2.2 Ich habe in meinen Logs merkwürdige “MARK”-Einträge gefunden, bin
ich kompromitiert? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
11.2.3 Ich habe User gefunden, die laut meinen Logs su benutzen: Bin ich kompromitiert? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
11.2.4 Ich bin Opfer eines Einbruchs - was soll ich jetzt tun? . . . . . . . . . . . . 127
11.2.5 Wie kann ich Angriffe aufsprüren? . . . . . . . . . . . . . . . . . . . . . . . 127
11.2.6 Das Programm X ist in Debian angreifbar - was soll ich machen? . . . . . 128
INHALTSVERZEICHNIS
vii
11.2.7 Laut der Versions-Nummer eines Paketes, läuft bei mir immernoch eine
angreifbare Version! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
11.2.8 spezielle Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
11.3 Fragen über Debians Sicherheitsteam . . . . . . . . . . . . . . . . . . . . . . . . . . 128
11.3.1 Was ist ein Debian Sicherheitsgutachten (Debian Security Advisory, DSA) 128
11.3.2 Die digitale Signatur eines Debian Gutachtens kann nicht korrekt verifiziert werden! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
11.3.3 Wie werden Sicherheits-Ereignisse in Debian behandelt? . . . . . . . . . . 129
11.3.4 Wieviel Zeit wird Debian brauchen, um die Angriffsmöglichkeit XXXX
zu reparieren? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
11.3.5 Wie wird Sicherheit für testing und unstable gehandhabt? . . . . . . 130
11.3.6 Warum gibt es keine offiziellen Spiegel für security.debian.org? . . . . . . 130
11.3.7 Ich habe DSA 100 und DSA 102 gesehen, wo ist aber DSA 101? . . . . . . 130
11.3.8 Wie kann ich das Sicherheits-Team erreichen? . . . . . . . . . . . . . . . . 130
11.3.9 Was ist der Unterschied zwischen security@debian.org und debiansecurity@lists.debian.org? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
11.3.10 Wie kann ich Debians Sicherheit-Team unterstützen? . . . . . . . . . . . . 131
11.3.11 Aus wem setzt sich das Sicherheits-Team zusammen? . . . . . . . . . . . . 131
11.3.12 Prüft Debians Sicherheit Team jedes Paket in Debian? . . . . . . . . . . . . 131
11.3.13 Ich habe eine ältere Version von Debian. Wird sie in Bezug auf Sicherheit
noch unterstützt? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
A Der Abhärtungsprozess Schritt für Schritt
133
B Konfigurations Checkliste
137
C Aufsetzen eines autonomen IDS
141
D Aufsetzen einer Überbrückenden Firewall (bridge Firewall)
147
D.1 Eine Bridge mit NAT- und Firewall-Fähigkeiten . . . . . . . . . . . . . . . . . . . 148
D.2 Eine Bridge mit Firewall Fähigkeiten . . . . . . . . . . . . . . . . . . . . . . . . . . 149
D.3 grundlegende Iptables-Regeln . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
E Beispiel Skript, um die standard Installation von Bind zu ändern
153
F Sicherheits-Update geschützt durch eine Firewall
159
INHALTSVERZEICHNIS
viii
1
Kapitel 1
Introduction
Wenn etwas über Sicherheit schreibt, ist es eines der schwierigsten Dinge, dass jeder Fall einzigartig ist. Sie müssen zwei Dinge beachten: Die Gefahr aus der Umgebung und das Bedürfniss
an Sicherheit ihrer Seite, ihres Hosts oder ihres Netzwerkes. So unterscheiden sich zum Beispiel
die Sicherheitsbedürfnisse eines Heimanwenders kompltett von denen Sicherheitsbedürfnisses des Netzwerkes einer Bank. Während die Hauptgefahr eines Heimanwender von “SciptKiddies” ausgeht, muss sich das Netzwerk einer Bank um direkte Angriffe sorgen. Zusätzlich muss eine Bank die Daten ihrer Kunden mit mathematischer Präzission beschützen. Um
es kurz zu machen: Jeder Nutzer muss selbst zwischen Benutzerfreundlichkeit und Sicherheit/Paranoia abwägen.
Beachten sie bitte, dass diese Anleitung nur Software-Themen behandelt. Die beste Software
der Welt kann sie nicht schützen, wenn jemand direkten Zugang zu ihrem Rechner hat. Sie können ihn unter ihren Schreibtisch stellen, oder sie können ihn in einem starken Bunker mit einer
ganzen Armee davor stellen. Trotzdem kann der Rechner unter ihrem Schreibtisch weitaus
sicherer sein - von der Software-Seite aus gesehen - als der eingebunkerte, wenn ihr Schreibtischrechner richtig konfiguriert ist und die Software des eingebunkerten Rechners voller Sicherheitslöcher ist. Sie müssen beide Möglichkeiten betrachten.
Dieses Dokument gibt ihne lediglich eine kleine Überblick, was sie tun können, um die Sicherheit ihres Debian GNU/Linux Systems zu ergöhen. Wenn sie bereits andere Dokumente über
Sicherheit unter Linux gelesen haben, werden sie feststellen, dass es einige Überscheidungen
geben wird. Wie auch immer: Dieses Dokument versucht nicht die ultimative Informationsquelle zu sein, es versucht nur die gleichen Informationen so zu adaptieren, dass sie gut
auf ein Debian GNU/Linux System passen. Unterschiedliche Distributionen erledigen manche
Dinge auf unterschiedliche Art (zum Beispiel der Aufruf von Daemons); hier finden sie Material, dass zu Debians Prozeduren und Tools passt.
Wenn sie Kommentare, Ergänzungen oder andere Anregunden haben, mailen sie sie bitte
an Javier Fernández-Sanguino (mailto:jfs@computer.org) (oder jfs@debian.org) und sie
werden in diese Anleitung eingearbeitet werden.
Bei Fehlern in dieser Übersetzung wenden sie sich bitte Alexander Schmehl (mailto:
schmehl@cs.uni-frankfurt.de)
Kapitel 1. Introduction
1.1
2
Herunterladen dieser Anleitung
Sie können sich die neuste Version der "Anleitung zum Absichern von Debian"
beim Debian Documentation Project (http://www.debian.org/doc/manuals/
securing-debian-howto/) herunterladen oder anschauen. Sie können auch gerne die
unterschiedlichen Versionen im CVS server (http://cvs.debian.org/ddp/manuals.
sgml/securing-howto/?cvsroot=debian-doc) durchforsten.
Sie können ausserdem eine reine Text-Version (http://www.debian.org/doc/manuals/
securing-debian-howto/securing-debian-howto.txt) von der Seite des Debian
Dokumentations Projektes bekommen. Andere Formate, wie zum Beispiel PDF, stehen (noch)
nicht zur Verfügung, sie können aber das Paket harden-doc (http://packages.debian.
org/harden-doc), in welchem das gleiche Dokument in den Formaten HTML, txt und PDF
enthalten ist, herunterladen und installieren.
1.2
Organisatorisches / Feedback
Nun kommt der offizielle Teil. Derzeit sind die meisten Teile dieser Anleitung noch von mir
(Alexander Reelsen) geschrieben, aber meiner Meinung nach sollte dies nicht so bleiben. Ich
wuchs mit Freier Software auf und lebe mit ihr, sie ist ein Teil meiner alltäglichen Arbeiten und
ich denke auch von ihrer. Ich ermutige jedermann mir Feedback, Tips für Ergänzungen oder
andere Vorschläge, die sie haben könnten, zuzuschicken.
Wenn sie denken, dass sie eine bestimmte Sektion oder Abschnitt besser pflegen können, dann
schreiben sie dem Dokumenten-Betreuer, und sie dürfen es gerne erledigen. Insbesondere,
wenn sie eine Stellen finden, die mit "FIXME" markiert wurde - was bedeutet, dass der Autor noch nicht die Zeit hatte oder sich noch Wissen über das Thema aneignen muss - schicken
sie ihm sofort eine Mail.
Für diese Anleitung ist es natürlich äusserts wichtig, dass sie weiter gepflegt und auf dem
neusten Stand gehalten wird. Auch sie können ihren Teil dazu beitragen. Bitte unterstützen sie
uns.
1.3
Vorwissen
Die Installation von Debian GNU/Linux ist nicht wirklich schwer, und sie sollten in der Lage
gewesen sein, es zu installieren. Wenn sie ihnen andere Linux Distributionen, Unixe oder die
grundsätzlichen Sicherheitskonzepte ein wenig vertraut sind, wird ihnen leichter fallen, diese
Anleitung zu verstehen, da nicht auf jedes winzige Detail eingegangen werden kann (oder
dies wäre ein Buch geworden, und keine Anleitung). Wenn sie jedoch mit diesen Dingen noch
nicht so vertraut sind, sollten sie vielleicht einen Blick in die ‘Seien Sie Wachsam gegenüber
generellen Sicherheitsproblemen!’ auf Seite 17 für tiefer gehende Informationen werfen.
1.4
3
Dinge, die noch geschrieben werden müssen (FIXME/TODO)
• Informationen, wie man unter Debian GNU/Linux eine Firewall aufsetzt. Der Firewalls
betreffende Abschnitt orientiert sich derzeit an Einzelplatz-Systemem (die keine anderen
System schützen müssen); auch auf das Testen des Setups eingehen
• Wie man eine Proxy-Firewall unter Debian GNU/Linux aufsetzt, unter angabe, welche
Pakete Proxy-Services anbieten (zum Beispiel xfwp, xproxy, ftp-proxy, redir,
smtpd, nntp-cache, dnrd, jftpgw,oops,pnsd, perdition,transproxy, tsocks).
Sollte zu einer Anleitung mit weiteren Informations verweisen. Erwähnenswert dass
zorp (noch) nicht Teil von Debian ist, aber es ist eine Proxy-Firewall (und der Programmautor stellt Debian-Pakete zur Verfügung)
• Informationen über die Service-Konfiguration mit file-rc
• Alle Referenzen und URLs prüfen und die nicht mehr Vorhanden aktualisieren oder entfernen
• Informationen über vorhandenen Ersatz (unter Debian) für häufig eingesetzte Server, die
bei eingeschränktem Funktionsumfang, nützlich sind. Beispiele:
– lokaler lpr mit cups (Paket)?
– remote lrp mit lpr
– bind mit dnrd/maradns
– apache mit dhttpd/thttpd/wn (tux?)
– exim/sendmail mit ssmtpd/smtpd/postfix
– squid mit tinyproxy
– ftpd mit oftpd/vsftp
– ...
• Mehr Informationen über die Sicherheits relevanten Patches des Kernels unter Debian,
einschliesslich den unten aufgeführten und insbesondere wie man diese Patches unter
einem Debian System benutzt.
– Eindringlings Erkennung (Linux Intrusion Detection lids-2.2.19)
– Linux Trustees (im Paket trustees)
– NSA Enhanced Linux (http://www.coker.com.au/selinux/)
– kernel-patch-2.2.18-openwall
kernel-patch-2.2.18-openwall)
(http://packages.debian.org/
– kernel-patch-2.2.19-harden
– Linux capabilities (im Paket lcap
– kernel-patch-freeswan,kernel-patch-int
4
• Details, wie man unnötige Services übers Netzwerk deaktiviert (abgesehen von inetd),
dies ist teilweise Teil des abhärtungs Prozesses, könnte aber etwas ausgeweitet werden.
• Informationen über Passwort-Rotation, was sehr nah an grundsätzliche Regeln (Policies)
herankommt
• Policies, und die Aufklärung der Nutzer über die Policy
• Mehr über tcpwrapper, und wrapper im allgemeinen?
• hosts.equiv und andere wichtige Sicherheitslöcher
• Angelegenheiten von Datei Freigabe, wie Samva und NFS?
• suidmanager/dpkg-statoverrides.
• lpr und lprng.
• Abschalten der gnome IP-Dinge.
• Erwähnen
von
pam_chroot
(siehe
http://http://lists.debian.org/
debian-security/2002/debian-security-200205/msg00011.html)
und
seine Nützlichkeit um Nutzer einzuschränlen. Einfphrende Informationen in
Verbindung mit http://online.securityfocus.com/infocus/1575. Pdmenu
ist zum Beispiel bereits unter Debian verfügbar (while as flash is not).
• Darüber reden, Services zu chroot’en, mehr Informationen dazu unter http:
//www.linuxfocus.org/English/January2002/aritcle225.shtml, http:
//www.networkdweebs.com/chroot.html und http://www.linuxsecurity.
com/feature_stories/feature_story-99.html
• Programme erwähnen die Chroot Einbettungen (chroot jails) machen. Compartment
und chrootuid warten noch in incoming. Einige andere (makejail, jailer) könnten ebenfalls eingeführt werden.
• Die Informationen von Karl Hegbloom regarding über das einbetten (chrooting)
von Bind 9 (siehe http://people.pdxlinux.org/~karlheg/Secure_Bind9_
uHOWTO/Secure_Bind_9_uHOWTO.xhtml) hinzufügen.
• Die Informationen von Pedro Zornenon über das chrooten von Bind 8, aber leider nur für
potato :(, see http://people.debian.org/~pzn/howto/chroot-bind.sh.txt
(include the whole script?).
• Mehr Informationen über Software zur Analyse von Protokoll-Dateien (log-Dateien, logs;
zum Beispiel logcheck und logcolorise) and logcolorise).
• "fortgeschrittenes" Routing (Traffic-Regelungen sind Sicherheitsrelevant)
• Zugang über ssh so einschränken, dass man nur bestimmte Kommandos ausführen kann
• Die Benutzung von dpkg-statoverride.
5
• sichere Wege, mehreren Nutzern den Zugriff auf CD-Brenner zu erlauben
• sichere Wege, um Sound zusammen mit einem Displey über ein Netzwerk zu leiten (so
dass die Sounds einen X Clients über die Hardware eines X Servers abgespielt werden)
• Abscihern von Web-Browsern
• Aufsetzen von ftp über ssh
• Die Benutzung von verschlüsselten Loopback-Dateisystemen
• Verschlüsselung eines ganzen Dateisystems
• Steganographie-Tools
• Aufsetzen eines PKA für eine Organisation
• LDAP benutzen zur Verwaltung der User. Es gibt eine HOWTO zu ldap+kerberos für
Debian auf www.bayour.com von Turbo Fredrikson.
1.5
1.5.1
Changelog/History
Version 2.5 (august 2002)
Changes by Javier Fernández-Sanguino Peña (me). There were many things waiting on my
inbox (as far back as february) to be included, so I’m going to tag this the back from honeymoon
release :)
• Added some information on how to setup the Xscreensaver to lock automatically the
screen after the configured timeout.
• Add a note related to the utilities you should not install in the system. Including a note regarding Perl and why it cannot be easily removed in Debian. The idea came after reading
Intersect’s documents regarding Linux hardening.
• Added information on lvm and journaling filesystems, ext3 recommended. The information there might be too generic, however.
• Added a link to the online text version (check).
• Added some more stuff to the information on firewalling the local system triggered by a
comment made by Hubert Chan in the mailing list.
• Added more information on PAM limits and pointers to Kurt Seifried’s documents (related to a post by him to bugtraq on April 4th 2002 answering a person that had “discovered” a vulnerability in Debian GNU/Linux related to resource starvation)
• As suggested by Julián Muñoz, provided more information on the default Debian umask
and what a user can access if he has been given a shell in the system (scary, huh?)
6
• Included a note in the BIOS password section due to a comment from from Andreas
Wohlfeld.
• Included patches provided by Alfred E. Heggestad fixing many of the typos still present
in the document.
• Added a pointer to the changelog in the Credits section since most people who contribute
are listed here (and not there)
• Added a few more notes to the chattr section and a new section after installation talking
about system snapshots. Both ideas were contributed by Kurt Pomeroy.
• Added a new section after installation just to remember users to change the boot-up
sequence.
• Added some more TODO items provided by Korn Andras.
• Added a pointer to the NIST’s guidelines on how to secure DNS provided by Daniel
Quinlan.
• Added a small paragraph regarding Debian’s SSL certificates infraestructure.
• Added Daniel Quinlan’s suggestions regarding ssh authentication and exim’s relay configuration.
• Added more information regarding securing bind including changes suggested by
Daniel Quinlan and an appendix with a scrip to make some of the changes commented on that section.
• Added a pointer to another item regarding Bind chrooting (needs to be merged)
• Added a one liner contributed by Cristian Ionescu-Idbohrn to retrieve packages with
tcpwrappers support.
• Added a little bit more info on Debian’s default PAM setup.
• Included a FAQ question about using PAM to give services w/o shell accounts.
• Moved two FAQ items to another section and added a new FAQ regarding attack detection (and compromised systems).
• Included information on how to setup a bridge firewall (including a sample Appendix).
Thanks go to Francois Bayar who sent me this on march.
• Added a FAQ regarding the syslogd’s MARK heartbeat from a question answered by
Noah Meyerhans and Alain Tesio on December 2001.
• Included information on buffer overflow protection as well as some information on kernel patches.
• Added more information (and reorganised) the firewall section. Updated the information
regarding the iptables package and the firewall generators available.
7
• Reorganized the information regarding logchecking, moved logcheck information from
host intrusion detection to that section.
• Added some information on how to prepare a static package for bind for chrooting
(untested).
• Added a FAQ item (could be expanded with some of the recomendations from the
debian-security list regarding some specific servers/services).
• Added some information on RPC services (and when it’s necessary).
• Added some more information on capabilities (and what lcap does). Is there any good
documentation on this? I haven’t found any on my 2.4 kernel.
• Fixed some typos.
1.5.2
Version 2.4
Changes by Javier Fernández-Sanguino Peña.
• Rewritten part of the BIOS section.
1.5.3
Version 2.3
• Wrapped most file locations with the file tag.
• Fixed typo noticed by Edi Stojicevi.
• Slightly changed the remote audit tools section.
• Added some todo items.
• Added more information regarding printers and cups config file (taken from a thread on
debian-security).
• Added a patch submitted by Jesus Climent regarding access of valid system users to
Proftpd when configured as anonymous server.
• Small change on partition schemes for the special case of mail servers.
• Added Hacking Linux Exposed to the books section.
• Fixed directory typo noticed by Eduardo Pérez Ureta.
• Fixed /etc/ssh typo in checklist noticed by Edi Stojicevi.
1.5.4
8
Version 2.3
• Fixed location of dpkg conffile.
• Remove Alexander from contact information.
• Added alternate mail address.
• Fixed Alexander mail address (even if commented out).
• Fixed location of release keys (thanks to Pedro Zorzenon for pointing this out).
1.5.5
Version 2.2
• Fixed typos, thanks to Jamin W. Collins.
• Added
a
reference
to
APT::ExtractTemplate config).
apt-extracttemplate
manpage
(documents
the
• Added section about restricted SSH. Information based on that posted by Mark Janssen,
Christian G. Warden and Emmanuel Lacour on the debian-security mailing list.
• Added information on anti-virus software.
• Added a FAQ: su logs due to the cron running as root.
1.5.6
Version 2.1
• Changed FIXME from lshell thanks to Oohara Yuuma.
• Added package to sXid and removed comment since it *is* available.
• Fixed a number of typos discovered by Oohara Yuuma.
• ACID is now available in Debian (in the acidlab package) thanks to Oohara Yuuma for
noticing.
• Fixed LinuxSecurity links (thanks to Dave Wreski for telling).
1.5.7
9
Version 2.0
Changes by Javier Fernández-Sanguino Peña. I wanted to change to 2.0 when all the FIXMEs
were, er, fixed but I run out of 1.9X numbers :(
• Converted the HOWTO into a Manual (now I can properly say RTFM)
• Added more information regarding tcp wrappers and Debian (now many services are
compiled with support for them so it’s no longer an inetd issue).
• Clarified the information on disabling services to make it more consistent (rpc info still
referred to update-rc.d)
• Added small note on lprng.
• Added some more info on compromised servers (still very rough)
• Fixed typos reported by Mark Bucciarelli.
• Added some more steps in password recovery to cover the cases when the admin has set
paranoid-mode=on.
• Added some information to set paranoid-mode=on when login in console.
• New paragraph to introduce service configuration.
• Reorganised the After installation section so it is more broken up into several issues and
it’s easier to read.
• Written information on howto setup firewalls with the standard Debian 3.0 setup (iptables package).
• Small paragraph explaining why installing connected to the Internet is not a good idea
and how to avoid this using Debian tools.
• Small paragraph on timely patching referencing to IEEE paper.
• Appendix on how to setup a Debian snort box, based on what Vladimir sent to the
debian-security mailing list (September 3rd 2001)
• Information on how logcheck is setup in Debian and how it can be used to setup HIDS.
• Information on user accounting and profile analysis.
• Included apt.conf configuration for read-only /usr copied from Olaf Meeuwissen’s post
to the debian-security mailing list
• New section on VPN with some pointers and the packages available in Debian (needs
content on how to setup the VPNs and Debian-specific issues), based on Jaroslaw Tabor’s
and Samuli Suonpaa’s post to debian-security.
• Small note regarding some programs to automatically build chroot jails
10
• New FAQ item regarding identd based on a discussion in the debian-security mailing list
(February 2002, started by Johannes Weiss).
• New FAQ item regarding inetd based on a discussion in the debian-security mailing list
(February 2002).
• Introduced note on rcconf in the “disabling services” section.
• Varied the approach regarding LKM, thanks to Philipe Gaspar
• Added pointers to CERT documents and Counterpane resources
1.5.8
Version 1.99
• Added a new FAQ item regarding time to fix security vulnerabilities.
• Reorganised FAQ sections.
• Started writing a section regarding firewalling in Debian GNU/Linux (could be broadened a bit)
• Fixed typos sent by Matt Kraai
• Fixed DNS information
• Added information on whisker and nbtscan to the auditing section.
• Fixed some wrong URLs
1.5.9
Version 1.98
• Added a new section regarding auditing using Debian GNU/Linux.
• Added info regarding finger daemon taken from the security mailing list.
1.5.10
Version 1.97
• Fixed link for Linux Trustees
• Fixed typos (patches from Oohara Yuuma and Pedro Zorzenon)
1.5.11
Version 1.96
• Reorganized service installation and removal and added some new notes.
• Added some notes regarding using integrity checkers as intrusion detection tools.
• Added a chapter regarding package signatures.
1.5.12
Version 1.95
• Added notes regarding Squid security sent by Philipe Gaspar.
• Fixed rootkit links thanks to Philipe Gaspar.
1.5.13
Version 1.94
• Added some notes regarding Apache and Lpr/lpng.
• Added some information regarding noexec and read-only partitions.
• Rewritten how can users help in Debian security issues (FAQ item).
1.5.14
Version 1.93
• Fixed location of mail program.
• Added some new items to the FAQ.
1.5.15
Version 1.92
• Added a small section on how Debian handles security
• Clarified MD5 passwords (thanks to ‘rocky’)
• Added some more information regarding harden-X from Stephen van Egmond
• Added some new items to the FAQ
11
1.5.16
12
Version 1.91
• Added some forensics information sent by Yotam Rubin.
• Added information on how to build a honeynet using Debian GNU/Linux.
• Added some more TODOS.
• Fixed more typos (thanks Yotam!)
1.5.17
Version 1.9
• Added patch to fix misspellings and some new information (contributed by Yotam Rubin)
• Added references to other online (and offline) documentation both in a section (see ‘Seien
Sie Wachsam gegenüber generellen Sicherheitsproblemen!’ auf Seite 17) by itself and inline in some sections.
• Added some information on configuring Bind options to restrict access to the DNS server.
• Added information on how to automatically harden a Debian system (regarding the
harden package and bastille).
• Removed some done TODOs and added some new ones.
1.5.18
Version 1.8
• Added the default user/group list provided by Joey Hess to the debian-security mailing
list.
• Added information on LKM root-kits (‘LKM - Ladbare Kernel-Module’ auf Seite 109)
contributed by Philipe Gaspar.
• Added information on Proftp contributed by Emmanuel Lacour.
• Recovered the checklist Appendix from Era Eriksson.
• Added some new TODO items and removed other fixed ones.
• Manually included Era’s patches since they were not all included in the previous version.
1.5.19
13
Version 1.7
Changes by Era Eriksson.
• Typo fixes and wording changes
• Minor changes to tags in order to keep on removing the tt tags and substitute them for
prgn/package tags.
1.5.20
Version 1.6
• Added pointer to document as published in the DDP (should supersede the original in
the near future)
• Started a mini-FAQ (should be expanded) with some questions recovered from my mailbox.
• Added general information to consider while securing.
• Added a paragraph regarding local (incoming) mail delivery.
• Added some pointers to more information.
• Added information regarding the printing service.
• Added a security hardening checklist.
• Reorganized NIS and RPC information.
• Added some notes taken while reading this document on my new Visor :)
• Fixed some badly formatted lines.
• Fixed some typos.
• Added a Genius/Paranoia idea contributed by Gaby Schilders.
1.5.21
Version 1.5
Changes by Josip Rodin and Javier Fernández-Sanguino Peña.
• Added paragraphs related to BIND and some FIXMEs.
1.5.22
14
Version 1.4
• Small setuid check paragraph
• Various minor cleanups
• Found out how to use sgml2txt -f for the txt version
1.5.23
Version 1.3
• Added a security update after installation paragraph
• Added a proftpd paragraph
• This time really wrote something about XDM, sorry for last time
1.5.24
Version 1.2
• Lots of grammar corrections by James Treacy, new XDM paragraph
1.5.25
Version 1.1
• Typo fixes, miscellaneous additions
1.5.26
Version 1.0
• Initial release
1.6
Danksagung
• Alexander Reelsen schrieb die ursprüngliche Version.
• Javier Fernández-Sanguino fügte der orginal Version einiges an Informationen hinzu.
• Robert van der Meulen stellte den Abschnitt über Quota und viele seiner guten Ideen zur
Verfügung.
• Ethan Benson korrigierte den PAM-Abschnitt und hatte einige gute Ideen.
• Dariusz Puchalak trug Information zu verschiedenen Kapiteln bei.
• Gaby Schilders trug eine nette Genius/Paranoia Idee bei.
• Era Eriksson gab dem ganzen an vielen Stellen den sprachlichen Feinschliff und trug zur
Checkliste im Anhang bei.
15
• Philipe Gaspar schrieb die LKM-Informationen.
• Yotam Rubin trug sowohl Korrekturen für viele Tippfehler bei als auch Informationen
über die Versionen von Bind und md5-Passwörter.
• All den Leuten, die Verbesserungen Vorschlugen, die (letzten Endes) eingeflossen sind
(siege ‘Changelog/History’ auf Seite 5).
• (Alexander) All den Leuten, die mich ermutigten diese HOWTO zu schreiben (die später
zu einer ganzen Anleitung wurde).
• Dem ganzen Debian Projekt.
16
17
Kapitel 2
Bevor Sie beginnen . . .
2.1
Für was möchten Sie dieses System benutzen?
Das Absichern von Debian ist nicht viel anders, als das Absichern von irgendeinem anderen
System; um es richtig zu machen, müssen Sie zunächst entscheiden, was Sie damit machen
möchten. Anschliessend müssen Sie sich klarmachen, dass die folgenden Schritte sorgfälltig
ausführen mü:ssen, um ein wirklich sicheres System zu bekommen.
Sie werden feststellen, dass diese Anleitung von der Pike auf geschrieben ist - Sie werden
die Informationen zu einer Aufgabe die sie vor während und nach der Debian Installation
ausführen sollten in der entsprechenden Reihenfolge lesen. Die einzelnen einzelnen Aufgaben
können wie folgt beschrieben werden:
• Entscheiden Sie, welche Services sie benötigen, und beschränken Sie Ihr System auf selbige. Dies schliesst das Deaktivieren / Deinstallieren von nicht benötigten Servicen und
das installieren von Firewall-ähnlichen Filtern oder TCP-Wrapper ein.
• Einschränken der Nutzer und Zugriffsrechte auf Ihrem System.
• Abhärten der angeboteten Services derart, dass der Einfluss auf Ihr System im Falle einer
Komprimitierung möglichst gerung ist.
• Benutzen Sie die passenden Tools, um Sicher zu stellen, dass ein unautorisierter Zugriff
auf Ihr System entdeckt wird, so dass Sie geeignete Massnahmen ergreifen können.
2.2
Seien Sie Wachsam gegenüber generellen Sicherheitsproblemen!
Diese Anleitung geht (normalerweise) nicht auf Details ein, warum bestimmte Sache als Sicherheitsrisiko betrachtet werden. Vielleicht möchten Sie aber ein mehr Hintergrundwissen über
generelle Unix- und (bestimmte) Linux-Sicherheit. Nehmen Sie sich dei Zeit, um Sicherheits
Kapitel 2. Bevor Sie beginnen . . .
18
relevante Dokumente zu lesen, um Entscheidungen informiert treffen zu können, wenn Sie
eine Auswahl treffen müssen. Debian GNU/Linux basiert auf dem Linux-Kernel, so dass
viele Informationen über Linux, und sogar über andere Distributionen und allgemeine UNIXSicherehit, auch hierauf zutreffen (sogar wenn sich die benutzten Werkzeuge oder die verfügbaren PRogramme unterscheiden).
Ein Paar nützliche Dokumente sind: <– TODO: Gibt es davon Uebersetzungen? –>
• Die
Linux
Security
HOWTO
(http://www.linuxdoc.org/HOWTO/
Security-HOWTO.html) (auch unterLinuxSecurity (http://www.linuxsecurity.
com/docs/LDP/Security-HOWTO.html) verfügbar) ist eine der besten Referenzen
über allgemeine Linux-Sicherheit.
• Die Security Quick-Start HOWTO for Linux (http://www.linuxsecurity.com/
docs/LDP/Security-Quickstart-HOWTO/) ist ein sehr guter Anfang, für unerfahrene Nutzer (sowohl von Linux als auch zum Theme Sicherheit)
• Die Linux Security Administrator’s Guide (http://seifried.org/lasg/) (wird
unter Debian durch das Paket lasg zur Verfügung gestellt) ist eine komplette Anleitung,
die alle Sicherheitsangelegenheiten zu Linux behandelt, von Sicherehit im Kernel bis hin
zu VPNs. Es ist ein wenig veraltet (seit 1999 nicht mehr aktualisiert) und wurde durch die
Linux Security Knowledge Base (http://seifried.org/lskb) ersetzt. Dieses Dokument stellt Debian Ihnen mit dem Paket lskb zur Verfügung.
• Kurt Seifried’s Securing Linux Step by Step (http://seifried.org/security/os/
linux/20020324-securing-linux-step-by-step.html).
• In Securing and Optimizing Linux: RedHat Edition (http://www.linuxdoc.org/
links/p_books.html#securing_linux) finden Sie eine Dokumentation ähnlich zu
dieser bezogen auf RedHat. Manche behandelten Sachen sind nicht Distributions spezifisch, passen also auch auf Debian.
• IntersectAlliance hat einige Dokumente veröffentlicht, die als Referenz benutzt werden
können, wie man einen Linux-Server (und seine Services) abhärtet. Diese Dokumente
sind auf ihrer Seite (http://www.intersectalliance.com/projects/index.
html) verfügbar.
• Für Netzwerk-Administratoren ist die Securing your Domain HOWTO (http://www.
linuxsecurity.com/docs/LDP/Securing-Domain-HOWTO/) eine gutes Handbuch, wie man sein Netzwerk absichert.
• Wenn Sie die Programme, die Sie benutzen möchten (oder die Sie neu schreiben wollen),
bezüglich Sicherheit auswerten wollen, sollten Sie die Secure Programs HOWTO (http:
//www.linuxdoc.org/HOWTO/Secure-Programs-HOWTO.html) durchlesen.
• Wenn Sie es in Betracht ziehen, eien Firewall zu installieren, sollten Sie die Firewall HOWTO (http://www.linuxdoc.org/HOWTO/Firewall-HOWTO.html) und
die IPCHAINS HOWTO (http://www.linuxdoc.org/HOWTO/IPCHAINS-HOWTO.
html) (bei Kerneln vor Version 2.4) lesen.
19
• Schliesslich ist die Linux Security RefenceCard (http://www.linuxsecurity.com/
docs/QuickRefCard.pdf) eine gute Kartei, um in Sachen Sicherheit auf dem aktuellen Stand zu bleiben.
In jedem Fall gibt es mehr Informationen über die Services (NFS, NIS, SMB. . . ) in den vielen
HOWTOs, die sie beim Linuxdoc Project (http://www.linuxdoc.org/) finden. Manche
dieser Dokumente gehen auf die Sicherheitsaspekte von bestimmten Services ein. Gehen Sie
Sicher, dass auch hierrauf einen Blick werfen.
Die HOWTO-Dokumente des Linux Dokomentation Projektes sind unter Debian GNU/Linux
duch Installation des Paketes doc-linux-text (Text-Version) oder doc-linux-html
(HTML-Version) verfügbar. Nach der Installation sind diese Dokumente in den Verezichnissen
/usr/share/doc/HOWTO/en-txt beziehungsweise /usr/share/doc/HOWTO/en-html
vorhanden.
Andere empfohlene Linux Bücher:
• Maximum Linux Security : A Hacker’s Guide to Protecting Your Linux Server and Network. Anonymous. Paperback - 829 pages. Sams Publishing. ISBN: 0672313413. July 1999.
• Linux Security By John S. Flowers. New Riders; ISBN: 0735700354. March 1999
• Hacking Linux Exposed (http://www.linux.org/books/ISBN_0072127732.
html) By Brian Hatch. McGraw-Hill Higher Education. ISBN 0072127732. April, 2001
Andere Bücher (auch über allgemeine Aspekte von Sicherheit unter Unix, nicht nur Linux
spezifisch):
• Practical Unix and Internet Security (2nd Edition) (http://www.ora.com/catalog/
puis/noframes.html) Garfinkel, Simpson, and Spafford, Gene; O’Reilly Associates;
ISBN 0-56592-148-8; 1004pp; 1996.
• Firewalls and Internet Security Cheswick, William R. and Bellovin, Steven M.; AddisonWesley; 1994; ISBN 0-201-63357-4; 320pp.
Some useful Web sites to keep uptodate regarding security:
• NIST Security Guidelines (http://csrc.nist.gov/fasp/index.html).
• Security Focus (http://www.securityfocus.com) the server that hosts the Bugtraq
vulnerability database and list, and provides general security information, news and reports.
• Linux Security (http://www.linuxsecurity.com/). General information regarding
Linux security (tools, news. . . ). Most useful is the main documentation (http://www.
linuxsecurity.com/resources/documentation-1.html) page.
• Linux firewall and security site (http://www.linux-firewall-tools.com/
linux/). General information regarding Linux firewalls and tools to control and administrate them.
2.3
20
Wie geht Debian mit der Sicherheit um?
Um einen allgemeinen Überblick über die Sicherheit unter Debian GNU/Linux sollten Sie zur
Kenntnis nehmen, was Debian tut, um ein sicheres System zu gewährleisten.
• Debians Probleme werden immer öffentlich behandelt, sogar wenn sie die Sicherheit betreffen. Wie der Debian Gesellschafter Vertrag (http://www.debian.org/social_
contract) sagt: Wir werden Probleme nicht verbergen Wir werden unsere Fehlerdatenbank für
alle Zeiten öffentlich betreiben. Fehlermeldungen, die von Anwendern online abgeschickt werden,
werden augenblicklich für andere sichtbar. Aspekte der Sicherheit werden öggentlich auf der
debian-security Mailing-Liste diskutiert. Debians Sicherheit Gutachten werden über eine
öffentliche Mailing-Liste gesendet (sowohl innerhalb als auch ausserhalb) und auf einem
öfentlichen Server veröffentlicht.
• Debian verfolgt Sicherheitsangelegenheiten sehr aufmerksam. Das Sicherheits-Team
prüft viele Sicherheits relevante Quellen, die wichtigste davon Bugtraq (http://www.
securityfocus.com/cgi-bin/vulns.pl), während sie Pakete mit SicherheitsProblemen suchen, die ein Teil von Debian sein können.
• Sicherheits-Updates geniessen höchste Priorität. Wenn ein Sicherheits Problem in einem
Debian Paket erscheint, wird ein Sicherheits-Update so schnell wie möglich vorbereotet
und für die stabile und instabile Release, einschliesslich aller Architecturen, veröffentlicht.
• Alle Informationen über Sicherheit sind an einer zentralen Stelle zu finden: http://
security.debian.org/.
• Debian versucht immer die gesamte Sicherheit seiner Distribution zu verbessern,
beispielsweise durch eine automatische Paket Signierungs- und VerifikationsMechanismen.
• Debian versucht eine nützliche Zahl von Sicherheits relevanten Werkzeugen für SystemAdministratoren und zur Überwachung zur verfügung zu stellen. Entwickler versuchen
diese Werkzeuge fest mit der Distribution zu verbinden, um sie angepasster für zur
Durchsetzung lokaler Sicherheits-Regelungen zu machen. Diese Werkzeuge schliessen
folgendes mit ein: Prüfer der Integrität, allgemeine Prüfungs Werkzeuge, Werkzeuge
zum abhärten, Werkzeuge für Firewalls, Eindringling-Erkennungs-Tools, und vieles andere.
• Paket-Betreuer sind sich der Sicherheits-Probleme bewusst. Dies führt oft zu EINER “voreingestellt sicheren” Installation von Servicen, die Sie manchmal in ihrer normalen Benutzung etwas einschränken. Dennoch versucht Debian Sicherheitsaspekte und einfache
Administration abzuwägen, zum Beispiel werden Services nicht deaktiviert installiert,
wie es bei den Distributionen der BSD-Familie üblich ist. Auf jedem Fall sind spezielle
Sicherheits-Aspekte, wie zum Beispiele setuid-Programme, sind Teil der Debian Policy
(http://www.debian.org/doc/debian-policy/).
21
This same document tries to enforce, as well a better distribution security-wise, by publishing
security information specific to Debian which complements other information-security documents related to the tools used by Debian or the operating system itself (see ‘Seien Sie Wachsam
gegenüber generellen Sicherheitsproblemen!’ auf Seite 17.
22
23
Kapitel 3
Vor und während der Installation
3.1
Setzen Sie ein Passwort im BIOS
Bevor Sie irgendein Betriebssystem auf Ihrem Computer installieren, setzen Sie ein Passwort
im BIOS. Nach der Installation (sobald Sie von der Festplatte booten können) sollten Sie zurück
ins BIOS gehen, und die Boot-Reihenfolge ändern, so dass sie nicht von Diskette, CDROM
oder sonstigen Geräten booten können, von denen dies nicht gehen sollte. Andernfalls benötigt
ein Cracker nur physischen Zugang und eien Bootdiskete um Zugriff auf Ihr ganzes System
zugreifen zu können.
Das Abschalten von booten ohne Passwort ist sogar noch besser! Dies kann sehr effektiv sein,
wenn Sie einen Server laufen lassen, da er nicht sehr oft neu gebootet werden wird. Der
Nachteil dieser Taktik ist, dass das Neustarten einen menschlichen Eingriff benötigt, was zu
Problemen führen kann, wenn die Maschinen nicht leicht zugänglich ist.
Beachten Sie: Viele BIOSe haben wohl bekannte Master-Passwörter, und es gibt sogar Applikationen, um Passwörter aus dem BIOS wieder zu gewinnen. Folglich können Sie sich nicht auf
diese Massnahme verlassen, um den Zugriff auf das Systems abzusichern.
3.2
3.2.1
Partitionieren des Systems
Wählen Sie ein intelligentes Partitions-Schemata
Was ein Inteligentes Partiotions-Schemata ist, hängt davon ab, wie die Maschine benutzt wird.
Eine gute Faustregel ist, mit Ihren Partitionen eher grosszügig zu sein und die folgenden Faktoren zu berücksichtigen:
• Jeder Verzeichnissbaum, auf den ein Nutzer Schreibzugriff hat, wie zum Beispiel /home
und /tmp sollte auf einer separaten Partition liegen. Dies reduziert das Risiko eines DoS
durch einen Nutzer, indem er Ihren “/”-Mountpoint auffüllt und so das gesamte System
unbenutzbar macht. (Eigentlich ist das so nicht ganz richtig, da immer etwas Platz für
den Superuser root reserviert wird, den ein normaler Nutzer nicht belegen kann.)
Kapitel 3. Vor und während der Installation
24
• Auch sollte jeder Verzeichnisbaum, der schwanken kann, zum Beispiel /var (insbesondere /var/log) eine seperate Partition bekommen. Auf einem Debian System sollten
Sie /var ein wenig grösser als normal erstellen, da herunter geladene Pakete (der Zwischenspeicher von apt) unter /var/cache/apt/archives gespeichert wird.
• Jeder Teil, in dem Sie nicht-Distributions-Software installieren wolle, soltle eine separate
Partition sein. Nach dem File Hierarchy Standard wären dies /opt oder /usr/local.
Wenn diese separate Partitionen sind, werden Sie nicht gelöscht, wenn Sie einmal Ihr
Debian neu installieren (müssen).
• Vom Standpunkt der Sicherheit aus ist es sinnvoll zu versuchen, statische Daten auf seine
eigene Daten zu verschieben, und diese Partition dann ohne Schreibzugriff einzuhängen
(mounten). Oder noch besser: Legen Sie diese Daten auf ein nicht beschreibbares Medium
ab. Lesen Sie weiter unten für weitere Details.
Im Falle eines Mailservers ist es wichtig eine seperate Partition für den Mail-Pool. NichtLokale Nutzer können (wissentlich oder unwissentlich) den Mail-Pool (/var/mail oder /var
/spool/mail überfüllen. Wenn der Poll eine separate Partition ist, wird diese Situation das
System nicht in einen unnutzbaren Zustand führen. Anderenfalls (wenn das Pool-Verezichniss
denselben Platz belegt, wie /var) hat das System ein schwerwiegendes Problem: ProtokollEinträge (log’s) können nicht erstellt werden, Pakete können nicht installiert werden, und es
könnten sogar ein paar Programme Probleme mit dem Starten haben (wenn sie /var/run
benutzen).
Ausserdem sollten Sie für Partitionen, deren Platzbedarf Sie noch nicht abschätzen können,
Logical Volume Manager (lvm-common und die benötigten ausführbaren Programme (binaries), entweder lvm10, lvm6, oder lvm5) installieren. Durch benutzen von lvm können Sie
Datenträger-Gruppen erstellen, die mehrere physische Datenträger erweitern.
Auswahl eines passenden Dateisystems
Während der Partitionierung des Systems müssen Sie sich ebenfalls entscheiden, welche
Dateisysteme Sie benutzen möchten. Als standard Dateisystem wird während der Debian Installation für Linux Partitionen ext2 ausgewählt. Dennoch ist es ratsam, auf ein “journaling filesystem” (ein Dateisystem, dass Änderungen mitprotokolliert) zu wechseln, wie zum
Beispiel ext3, reiserfs, jfs oder xfs. Dadurch verkleinern Sie Probleme, die durch einen
Absturz des Systems
• Auf Laptops auf allen Dateisystemen. Auf diese Art reduzieren Sie die Wahrscheinlichkeit eines Datenverlustes, wenn beispielsweise unerwartet Ihr Akku leer wird oder
das System aufgrund einer Hardware-Sache neu booten (eine irgendwie komische XKonfiguration zum Beispiel) mussten.
• Auf Produktiv-Systemen, die grosse Mengen von Daten Speichern (zum Beispiel MailServer, FTP-Server, Netzwerk Dateisystemen. . . ) ist es empfohlen, ein journaling Filesystem auf diesen Partitionen einzusetzen. Wenn ein System-Crash auftritt, benötigt der
25
Server so weniger Zeit, um das Dateisystem wieder herzustellen und durchzu prüfen,
und Sie verringern die Wahrscheinlichkeit eines Datenverlustes.
Lassen wir mal die Betrachtung der Leistung von journaling Filesystemen beiseite (da sich
dies oft zu quasi religioösen Glaubenskriegen ausartet). Im Regelfall ist es besser, das ext3
Dateisystem zu benutzen. Der Grund dafür ist die Abwärtskompatibilität zu ext2, so können
Sie, wenn es Probleme mit dem Journal gibt, dieses einfach abschalten, und haben immernoch
ein funktionierendes Dateisystem. Ausserdem können Sie, wenn Sie das System mal mit einer
Boot-Diskette (oder CDROM) wiederherstellen müssen, keinen speziellen Kernel benutzen.
Wenn es sich um einen 2.4er Kernel handelt, ist Unterstützung für etx3 bereits vorhanden,
wenn es sich um einen 2.2er Kernel handelt, können Sie trotzdem Ihr Dateisystem booten, auch
wenn Sie die journaling-Fähigkeiten einbüssen. Wenn Sie ein anderes journaling Filesystem
benutzen werden Sie feststellen, dass Ihnen eine Widerherstellung nicht möglich ist, bis Sie
einen 2.4er Kernel, mit den benötigten Modulen einkompiliert, haben. Wenn Sie mit einem
2.2er Kernel der Rettungs-Diskette festhängen, kann es sich als ziemlich schwer erweisen, auf
reiserfs pder xfs zuzugreifen.
In jedem Fall könnten mit ext3 weniger Daten-Verluste auftreten, da es auch Datei-Daten
protokolliert, während lediglich Meta-Daten protokollieren, siehe auch http://lwn.net/
2001/0802/a/ext3-modes.php3.
3.3
Gehen Sie nicht ins Nezt, bevor Sie nicht bereit sind
Das Sytem, das Sie installieren wollen, sollten Sie nicht sofort währen der Installation mit dem
Internet verbinden. Dies hörrt sich vielleicht doof an, wird aber gewöhnlich so getan. Da das
System Services installieren und sofort installieren wird, können Sie, wenn das System mit
dem Internet verbunden ist und sie nicht geeignet konfiguriert sind, Ihr System für Angriffe
öffnen.
Ausserdem sollten Sie beachten, dass Services neuere Sicherheits-Löcher haben lönnte, die
noch nicht in den Paketen, die Sie zur Installation benutzen, korrigiert worden sind. Dies ist
für gewöhnlich dann der Fall, wenn Sie von älteren Medien (wie CD-ROMs) installieren. In
diesem Fall wäre Ihr System bereits kompromitiert, bevor Sie mit der Installation fertig sind!
Da die Debian Installation und Upgrades über das Internet durchgeführt werden können,
denken Sie vielleicht, es ist eine gute Idee, dies gleich während der Installation zu nutzen.
Wenn das System direct mit dem Internet Verbunden ist (und nicht von einer Firwall oder
NAT beschützt wird), ist es besser ohne Internet Verbindung zu installieren und Lokale-PaketSpiegel (Mirror) sowohl von den Paket-Quellen als auch von den Sicherheits-Updates. Sie können einen Paket-Mirror aufsetzen, indem Sie ein anderes System nutzen, dass mit dem Internet
verbunden ist und Debian-Spezifische Tools (wenn es sich um ein Debian System handelt) wie
apt-move oder apt-proxy oder andere der üblichen Werkzeuge zum spiegel benutzen, um
ein Archiv für das zu installierende System zur Verfügung zu stellen. Wenn Sie dies nicht
tun können, sollten Sie Firewall-Regeln aufsetzen, die den Zugriff auf Ihr System eingrenzen,
währen Sie das Update durchführen (siehe id=“fw-security-update”>).
3.4
26
Setzen Sie ein Passwort für root
Das Setzen eines guten Root-Passworts ist die wichtigiste, grundlegende Anforderung an ein
sicheres System.
3.5
Aktivieren sie “shadow passwords” und “MD5 passwords”
Am Ende der Installation werden Sie gefragt werden, ob “shadow passwords” eingeschaltet
werden sollen. Beantworten Sie diese Frage mit “yes”, dann werden Passwörter in der Datei
/etc/shadow. Nur Root und die Gruppe shadow haben lese Zugriff auf diese Datei, so ist es
keinem Nutzer möglich, sich eine Kopie dieser Datei zu erstellen, um einen Passwort-Cracker
auf sie laufen zu lassen. Sie können mit dem Befehl shadowconfig jederseit zwischen “shadow passwords” und normalen Passwörtern wechseln. Desweiteren werden Sie während der
Installation gefragt, ob Sie mit MD5 gehashte Passwörter benutzen möchten. Dies ist im allgemeinen eine gute Idee, da es längere Passwörter und bessere Verschlüsselung erlaubt.
Mehr über “shadow passwords” lesen Sie unter Shadow Password (http://www.
linuxdoc.org/HOWTO/Shadow-Password-HOWTO.html)
(/usr/share/doc/HOWTO
/en-txt/Shadow-Password.txt.gz).
3.6
lassen Sie so wenig Services wie möglich laufen
Service sind Programme wie FTP- und Web-Server. Da sie eingehende Verbindungen, die den
Service anfordernm entgegen nehmen und ihnen zuhören müssen, können sich externe Computer mit Ihrem verbinden. Services sind manchmal verwundbar (zum Beispiel durch eine bestimmte Attacke kompromitierbar) und sind dadurch ein Sicherheits Risiko.
Sie sollten keine Services installieren, die Sie nicht unbedingt auf der Machine brauchen. Jeder Installierter Service könnte neue, vielleicht nicht auf der Hand liegende (oder bekannte)
Sicherheits-Löcher auf Ihrem Computer.
Wie Sie vielleicht schon wissen, ist ein bestimmter Service, den Sie installieren, ist er standardmässig aktiviert. In der der default Debian Installation, ohne jeden installierten Service,
sind die Fussspuren der laufenden Services sind ziemlich gering und noch geringer, wenn
man nur von Servicen spricht, die zu einem Netzwerk hin angeboten werden. Die Fussspuren
von Debian 2.1 waren nicht so tief wie die von Debian 2.2 (ein paar inetd-Services wurden
standard-mässig eingeschaltet) und in Debian 2.2 sind die rpc-Portmapper nach der Installation eingeschaltet. Rpc ist standardmässig installiert, da er für vueke Services benötigt wird.
Er kann sehr leicht entfernt werden, sehen sie ‘Daemon-Services abschalten’ auf der nächsten
Seite, um zu erfahren, wie man Ihn abschaltet.
Wenn Sie einen neuen Netzwerk nutzenden Service (daemon) auf Ihrem Debian GNU/Linux
System instalieren, kann er auf zwei Arten eingeschaltet werden: Durch den inetd Superdaemon (was heisst: Eine Zeile wird /etc/inetd.conf hinzugefügt) oder durch ein alleinstehendes Programm, dass sich selbst an die Netzwerk-Schnittstelle bindet. Alleinstehende
27
Programme werden durch /etc/init.d kontrolliert, diese werden beim starten durch den
SysV-Mechanismus (oder einen alternativen= gestartet, indem die symbolischen Verknüpfungen (Links) in /etc/rc?.d/* benutzt werden (Mehr Informationen wie dies geschieht finden
Sie in /usr/share/doc/sysvinit/README.runlevels.gz).
Wenn Sie trotzdem Services installieren wollen, diese aber selten benutzen, entfernen Sie sie
mittels den update-Befehlen, wie ’update-inetd’ und ’update-rc.d’.
3.6.1
Daemon-Services abschalten
Das Abschalten eines Daemon-Service ist sehr einfach. Es gibt verschiedene Methoden:
• Entferned der Links von /etc/rc${runlevel}.d/ oder umbenennen der Links (so
dass sie nicht mit einem ’S’ anfangen)
• Umbenennen der Skript-Dateien (/etc/init.d/_service_name_), zum Beispiel in
/etc/init.d/OFF._service_name_
• Entfernen des Ausführbar-Bis (execution bit, x-bit) von der Datei /etc/init.d
/_service_name_
• Editieren der Datei /etc/init.d/_service_name_, so dass sich das Skript sofort
beendet.
Sie können die Links manuell aus /etc/rc${runlevel}.d/ entfernen oder Sie benutzen
update-rc.d (siehe auch update-rc.d(8)). So können sie zum Beispiel einen Service in
den multi-User Runleveln abschalten:
update-rc.d stop XX 2 3 4 5 .
Bitte beachten Sie, dass wenn Sie nicht file-rc benutzen, update-rc.d -f _service_
remove nicht korrekt arbeiten wird, da alle Verknüpfungen entfernt werden, nach einer reinstallation oder einem Upgrade dieses Paketes werden diese Verknüpfungen neu angelegt
(was Sie vermutlich nicht wollen). Wenn Sie denken, dass dies wenig intuitiv ist, liegen Sie
wohl richtig (siehe Bug 67095 (http://bugs.debian.org/67095)). Aus der Handbuchseite:
If any files /etc/rcrunlevel.d/[SK]??name already exist then
update-rc.d does nothing. This is so that the system administrator
can rearrange the links, provided that they leave at least one
link remaining, without having their configuration overwritten.
Wenn Sie file-rc benutzen, werden alle Informatione über das Starten von Services durch
eine gemeinsame Konfigurations-Datei verarbeitet und werden sogar nach der Deinstallation
eines Services von dem System beibehalten.
28
Sie können das TUI (Text User Interface, textuelle Benutzeroberfläche) des Paketes rcconf
benutzen, um all diese Änderungen einfach zu erledigen (rcconf arbeitet sohwohl mit file-rc
als auch mit normallen System V Runleveln).
Andere (nicht empfohlene) Methoden zum abschalten eines Services sind: chmod 644
/etc/init.d/daemon (aber das erzeugt eine Fehlermeldung beim booten) oder das ändern des /etc/init.d/daemon-Skriptes (hinzufügen von exit 0 als allererste Zeile oder
auskommentieren des start-stop-daemon Teils). Da es sich bei allen init.d-Dateien um
Konfigurations-Dateien handel, werden Sie bei einem Upgrade nicht überschrieben.
Leider können Sie, im Gegensatz zu anderen (UNIX) Betriebssystemen, Services unter Debian nicht abschalten, indem Sie die Dateien unter /etc/default/_servicename_ modifizieren.
FIXME: Add more information on handling daemons using file-rc
3.6.2
Abschalten von inetd-Servicen
Abschalten sollten Sie alle nicht benötigten Services, wie zum Beispiel echo, chargen, discard,
daytime, time, talk, ntalk und die r-Services (rsh, rlogin und rcp), die als SEHR unsicher gelten
(benutzen Sie stattdessen ssh). Nachdem Sie diese abgeschaltet haben, sollten Sie überprüfen,
ob Sie überhaupt den inetd-Daemon brauchen. Viele Leute ziehen es vor einzelne Daemonen
zu benutzen, anstatt einen Service über inetd aufzurufen. Wenn Sie dann immernoch einen
inetd-Service laufen lassen wollen, wechseln Sie zu einem konfigurierbarerem inet-Daemon,
wie xinietd oder lrinetd.
Sie können Services abschalten, indem Sie direkt /etc/inetd.conf editieren, aber Debian
stellt Ihnen eine besseren Weg zur Verfügung das zu tun: update-inetd (was die Services
auf eine Art auskommentiert, so dass sie leicht wieder eingeschaltet werden können). Sie können den telnet daemon sehr leicht mit dem folgenden Kommando abschalten, so dass die
Konfigurations-Dateien angepasst und der Daemon neu gestartet wird:
/usr/sbin/update-inetd --disable telnet
Wenn Sie Services lauschen lassen wollen, aber Sie nicht auf alle IP-Adressen Ihres Hosts hören
sollen, möchten Sie vielleicht eine undokumentierte Fähigkeit von inetd benutzen. Oder Sie
benutzen einen anderen inetd-Daemon wie xinetd.
3.7
Installieren Sie möglichst wenig Software, nur die benötigte
Debian kommt mit sehr viel Software, zum Beispiel kommt die Release Debian 3.0 woody auf
7 CD-ROMs, mit tausenden von Software Paketen. Bei so viel Software, und sogar wenn Sie
die Installation auf das Basis-System reduzieren 1 könnten Sie auf Abwege geraten und mehr
1
Unter Debian Woody ist das Basis-System etwa 40MB gross. Probieren Sie folgendes:
29
installieren als Sie wirklich benötigen. 2
Da Sie you bereits wissen, was Sie mit Ihrem System machen wollen (oder etwa nicht?) sollten
Sie nur Software installieren, die Sie wirklich zum arbeiten benötigen. Jedes unnötige Tool,
dass Sie installieren könnte von einem Nutzer, der Ihr System kompromitieren will genutzt
werden, oder von einem externen Eindringling, der Shell-Zugriff bekommen hat (oder der
Code von ausserhalb durch einen ausnutzbaren Service ausführen kann).
Zum Beispiel kann das Vorhandensein von Entwickler-Tolls (einem C-Compiler) oder Interpretern (wie Perl - sehen Sie weter unten -, python, tcl..) einem Angreifer helfen, dass System
weiter zu kompromitieren:
• dem Angreifer erlauben Privilegien auszuweiten. Es ist zum Beispiel leichter eine Lokale
Sichereheitslücke des Systems auszunutzen, wenn man einen Debugger und Compiler
zur verfügung hat, um den eigenen Exploit (Programm, dass eine Sicherheitslücke ausnutzt) zu kompilieren und zu testen.
• dem Angreifer Tools zur Verfügung stellen, die ihm helfen können, das kompromitierte
Syste als Basis für Angriffe auf andere Systeme zu benutzen. 3
Natürlich kann ein Eindringling mit lokalem Shell-Zugriff seine eigenen Tolls herunterladen
und ausfphren, und sogar die Shell selbst kann benutzt werden, um komplexere Programme
zu schreiben. Das entfernen unnötiger Programme wird also nicht helfen, das Problem zu verhindern, aber das Problem wird dadurch ein wenig schwerer für den Angreifer (und manchmal wird er in dieser Situation aufgeben und sich ein leichteres Ziel suchen). Wenn Sie also
auf einem produktivem System Tools lassen, die benutzt werden können, um andere Systeme
anzugreifen (siehe ‘Tools zur Fern-Prüfung der Verwundbarkeit’ auf Seite 101), müssen Sie
auch davon ausgehen, dass ein Angreifer sie benutzen wird.
3.7.1
Entfernen von Perl
Sie müssen Berücksichtigen, dass sich das Entfernen von perl von einem Debian-System als
nicht so einfach erweisen könnte (in der Tat kann es ziemlich schwer sein), da es von vielen Dienstprogeammen des Systems benutzt wird. perl-base hat ausserdem Priority: required (und
dass sagt eigentlich schon alles). Es ist aber trotzdem machbar, Sie müssen nur bedenken, dass
$ size=0 $ for i in ‘grep -A 1 -B 1 "^Section: base"/var/lib/dpkg/available
| grep -A 2 "^Priority: requiredgrep "Înstalled-Sizecut -d : -f 2 ‘; do
size=$(($size+$i)); done $ echo $size 34234
2
Unter Debian Woody ist das Basis-System etwa 40MB gross. Probieren Sie folgendes:
$ size=0 $ for i in ‘grep -A 1 -B 1 "^Section: base"/var/lib/dpkg/available
| grep -A 2 "^Priority: requiredgrep "Înstalled-Sizecut -d : -f 2 ‘; do
size=$(($size+$i)); done $ echo $size 34234
3
Viele “intrusions” (Eindringen auf fremde Systeme) werden eher gemacht, um an die Resourcen für illegitime
Aktitiväten zu kommen (denial of service Attacken, Spam, geheime FTP-Server , dns Verunreinigung. . . ), als nur
um irgendwelche vertraulichen Daten auf dem kompromitierten System zu kommen.
30
Sie auf diesem System keine Perl-Anwendung mehr laufen lassen können, und Sie müssen
auch das Paket-Managment-System hereinlegen, damit es weiterhin denkt, dass perl-base
installiert ist, auch wenn es das nicht mehr ist. 4
Welche Dienstprogramme benutzen Perl? Sie können es selbst herausfinden:
$ for i in /bin/* /sbin/* /usr/bin/* /usr/sbin/*; do [ -f $i ] && {
type=‘file $i | grep -il perl‘; [ -n "$type" ] && echo $i; }; done
Diese Liste schliesst die Folgenden Dienstprogramme mit der Priorität required oder important
mit ein:
• /usr/bin/chkdupexe aus dem Paket util-linux.
• /usr/bin/replay aus dem Paket bsdutils.
• /usr/sbin/cleanup-info aus dem Paket dpkg.
• /usr/sbin/dpkg-divert aus dem Paket dpkg.
• /usr/sbin/dpkg-statoverride aus dem Paket dpkg.
• /usr/sbin/install-info aus dem Paket dpkg.
• /usr/sbin/update-alternatives aus dem Paket dpkg.
• /usr/sbin/update-rc.d aus dem Paket sysvinit.
• /usr/bin/grog aus dem Paket groff-base.
• /usr/sbin/adduser aus dem Paket adduser.
• /usr/sbin/debconf-show aus dem Paket debconf.
• /usr/sbin/deluser aus dem Paket adduser.
• /usr/sbin/dpkg-preconfigure aus dem Paket debconf.
• /usr/sbin/dpkg-reconfigure aus dem Paket debconf.
• /usr/sbin/exigrep aus dem Paket exim.
• /usr/sbin/eximconfig aus dem Paket exim.
• /usr/sbin/eximstats aus dem Paket exim.
• /usr/sbin/exim-upgrade-to-r3 aus dem Paket exim.
• /usr/sbin/exiqsumm aus dem Paket exim.
• /usr/sbin/keytab-lilo aus dem Paket lilo.
4
Sie können (auf einem anderen System) eine Paket-Attrappe mit equivs erstellen.
31
• /usr/sbin/liloconfig aus dem Paket lilo.
• /usr/sbin/lilo_find_mbr aus dem Paket lilo.
• /usr/sbin/syslogd-listfiles aus dem Paket sysklogd.
• /usr/sbin/syslog-facility aus dem Paket sysklogd.
• /usr/sbin/update-inetd aus dem Paket netbase.
Also, ohne Perl udn solange Sie diese Dienstprogramme nicht in einem Shell-Skript
neuschreiben, werden Sie wahrscheinlich keine Pakete mehr verwalten klnnen (und so das
System nicht upgraden können, und das ist keine gute Idee).
Wenn Sie sich dazu entschlossen haben, Perl aus dem Debian-Basis-System zu entfernen und
ein wenig Freizeit haben, schicken Sie uns doch Bug-Reports zu den aufgezählten Paketen, die
(als ein Patch) einen Ersatz dieser Dienstprogramme als Shell-Skript enthält.
3.8
Lesen Sie Debians Sicherheits-Mailinglisten
Es ist niemals falsch einen Blick entweder in die debian-security-announce Mailing-Liste, wo
Sicherheitsgutachten und Problemlösungen durch das Debian-Team für Sicherheit bekannt
gemacht werden, oder auf die debian-security@lists.debian.org Liste, wo Sie an den Diskussionen zu allen Sicherheits relevanten Dinge teilnehmen könen, zu werfen.
Um wichtige Warnungen zu Sicherheits-Update zu erhalten, senden Sie
eine
Email
an
debian-security-announce-request@lists.debian.org
(mailto:
debian-security-announce-request@lists.debian.org)
mit
dem
Wort
“subscribe” in der Betreff-Zeile. Sie können diese moderierte Email-Liste unter
http://www.debian.org/MailingLists/subscribe über das Web abonnieren.
Diese Mailingliste hat ein sehr geringes Aufkommen, und indem Sie sie abonnieren, werden Sie sofort über Sicherheits-Updates der Debian-Distribution informiert. Dies erlaubt Ihnen sehr schnell neue Pakete mit Sicherheits-Fixes herunterzuladen, was sehr wichtig ist, um
ein sicheres System zu verwalten (Siehe ‘Ausführen von Sicherheitsupdates’ auf Seite 39 für
weitere Details, wie Sie dies machen)
32
33
Kapitel 4
Nach der Installation
Wenn das System installiert ist, können sie es noch weiter absichern, indem sie einige der in
diesem Kapitel beschriebenen Schritte ausführen. Natürlich hängt dies vor allem von ihrem
Setup up, aber um physischen Zugriff zu verhindern. sollten sie ‘Änderungen im BIOS (noch
einmal)’ auf dieser Seite, ‘Ein Passwort für LILO oder GRUB einstellen’ auf der nächsten Seite,
‘Entfernen des root Promptes aus dem Kernel’ auf Seite 35, ‘Booten von Diskette verbieten’ auf
Seite 35, ‘einschränkender Konsolen zugang’ auf Seite 36, und ‘Systemneustart auf der Konsole
einschränken’ auf Seite 37 lesen.
Bevor sie sich mit einem Netzwerk verbinden, insbesondere wenn es sich um ein öffentliches
Netzwerk handelt, sollten sie wenigstens ein securezty update (siehe ‘Ausführen von Sicherheitsupdates’ auf Seite 39) durchführen. Optional können sie sie sich einen Snapshot ihres
Systems machen (siehe ‘Einen Schnappschuss des Systems erstellen’ auf Seite 64).
4.1
Änderungen im BIOS (noch einmal)
Erinnern sie sich an ‘Setzen Sie ein Passwort im BIOS’ auf Seite 23? Nun, jetzt sollten sie, nachdem sie nicht mehr von austauschbaren Datenträgern booten müssen, die standard BIOS Einstellung so umändern, dass es auschliesslich von der Festplatte bootet. Gehen sie sicher, dass
sie ihr BIOS Passwort nicht verlieren, oder sie werden, im Falle eines Festplattenfehlers, nicht
mehr ins BIOS zurückkehren können, um die Einstellung wieder zu ändern, so dass sie ihr
System wiederherstellen können, indem sie zum Beispiel eine CD-ROM benutzen.
Eine andere, weniger sicher, aber bequemere Möglichkeit ist es, das BIOS so einzustellen, dass
es von von der Festplatte bootet, und nur falls dies fehlschlägt versucht von austauschbaren
Datenträgern zu booten. Übrigens wird dies oft so gemacht, weil nur wenige ein BIOS Passwort benutzen, dass oft zu leicht vergessen wird.
Kapitel 4. Nach der Installation
4.2
34
Ein Passwort für LILO oder GRUB einstellen
Jeder kann sehr einfach eine roor Shell auf ihrem System bekommen, indem er einfach
“<Name-ihres-Bootimages> init=/bin/sh” am Bootprompt eingibt. Nachdem die Passwörter
geändert und das System neu gestartet wurde, hat die Person uneingeschränkten Root Zugang
and kann alles auf ihrem System machen, das sie will. Nach dieser Prozedur haben sie keinen
Root Zugang mehr zu ihrem System, weil sie das Root Passwort nicht kennen.
Um sicher zu stellen, dass dies nicht passieren kann, sollten sie den boot loader mit einem Passwort schützen. Sie können zwischem einem globalen Passwort und Passwörtern für bestimmte
Images wählen.
Für LILO müssen sie die Konfigurationsdatei /etc/lilo.conf editieren und eine “password” und “restricted” Zeile, wie im folgenden Beispiel, einfügen:
image=/boot/2.2.14-vmlinuz
label=Linux
read-only
password=hackmich
restricted
Haben sie dies getan, rufen sie lilo auf. Wenn sie die “restricted” Zeile weglassen, wird lilo
immmer nach dem Passwort fragen, egal ob LILO parameter übergeben wurden oder nicht.
Die vorgabe Zugriffsrechte auf /etc/lilo.conf erlauben root das lesen und schreiben, und
der Gruppe von lilo.conf, ebenfalls root, das Lesen.
Wenn sie GRUB anstelle von LILO verwenden, editieren sie /boot/grub/menu.lst und fügen die folgenden zwei Zeilen am Anfang an (dabei ersetzen sie natürlich ’hackmich’ mit dem
vorgesehenen Passwort). Dies verhindert, dass Benutzer die Booteinträge verändern können.
’timeout 3’ legt eine Wartedauer von 3 Sekunden fest, bevor grub den Standard Eintrag bootet.
timeout 3
password hackmich
Um die Integrität ihres Passwortes zusätzlich abzusichern, sollten sie ihr Passwort verschlüsselt ablegen. Das Utility grub-md5-crypt generierd ein gehashtes Passwort, das kompatibel
mit grub’s Verschlüsselungsalgorithmus (md5) ist. Um grub mitzuteilen, dass verschlüsselte
Passwörter benutzt werden, benutzen sie die folgende Anweisung:
timeout 3
password --md5 $1$arPydhOM$bIgEKjMW5kxeEuvE1Rah4/
Der –md5 Parameter wurde hinzugefügt, um bei grub einen md5 Authentifizierungsprozess
zu erzwingen. Das angegeben Passwort ist die md5 verschlüsselte Version von hackmich. Es
ist vorzuziehen md5- statt Klartextpasswörter zu verwenden. Weitere Informationen über grub
Passwörter können sie im grub-doc Packet finden.
4.3
35
Entfernen des root Promptes aus dem Kernel
Linux 2.4 Kernel bieten kurz nach dem Laden des cramfs einen Weg Zugriff auf eine Root Shell
zu bekommen, also während das System bootet. Es erscheint eine Meldung, die dem Administrator erlaubt, eine auszuführende Shell mit Root Privilegien zu betreten, diese Shell kann dazu
benutzt werden, manuell Module zu laden, falls die automatische Erkennung fehlschlägt. Dies
ist das standard Verhalten bei initrd’s Linuxrc. Die folgende Meldung wird erscheinen:
Press ENTER to obtain a shell (waits 5 seconds)
Um dieses Verhalten zu entfernen, müssen sie /etc/mkinitrd/mkinitrd.conf editieren
und den Eintrag
# DELAY Anzahl Sekunden, die das linuxrc Skript warten soll,
# um den Nutzer eingriffe zu erlauben, befor das System hochgefahren
# wird
DELAY=0
setzen.
Generieren sie ihr ramdisk image anschliessend neu. Dies können sie zum Beispiel so tun:
# cd /boot
# mkinitrd -o initrd.img-2.4.18-k7 /lib/modules/2.4.18-k7
oder machen sie (vorzugsweise):
# dpkg-reconfigure kernel-image-2.4.x-yz
Beachten sie, dass Debian 3.0 woody den Benutzern erlaubt 2.4er Kernel zu installieren (indem
sie flavors wählen), aber der standard Kernel ist 2.2 (von einigen Architekturen abgesehen, auf
die der Kenel 2.2 nicht portiert wurde). Wenn sie dies als Bug ansehen, beachten sie Bug 145244
(http://bugs.debian.org/145244) bevor sie ihn einsenden.
4.4
Booten von Diskette verbieten
Der standard MBR von Debian vor Version 2.2 verhielt sich nicht wie ein normaler Master Boot
Record und lies eine Methode offen, einfach in ein System einzubrechen:
• Drücken sie während des Bootens shift, und der MBR prompt erscheint
• Drücken sie dann F, und ihr System wird von Diskette booten. Dies kann man ausnutzen,
um root Privilegien auf dem System zu erlangen.
36
Dieses Verhalten können sie ändern, indem sie
lilo -b /dev/hda
eingeben.
Nun ist LILO in den MBR geschoben worden. Dies können sie auch erreichen, indem sie
“boot=/dev/hda” zu lilo.conf hinzufügen. Es gibt noch eine Möglichkeit, die den MBR komplett abschalten wird:
install-mbr -i n /dev/hda
Auf der anderen Seite, könnte diese “Hintertür”, die viele Leute nicht kennen, ihnen einmal
die Haut retten, wenn sie in grosse Schwierigkeiten mit ihren Installations aus irgendwelchen
Gründen geraten.
FIXME überprüfen, ob das für 2.2 wirklich stimmt, oder war es 2.1? INFO: Die Boot Disketten
von Debian 2.2 installieren KEINEN mbr, sondern nur LILO
4.5
einschränkender Konsolen zugang
Manche Sicherheits Policies könntem Administratoren dazu zwingen, sich erst als als User
mit ihrem Passwort auf dem System einzulogen, und dann Superuser zu werden (mit su
oder sudo). Solche eine Policy ist in Debian in der Datei /etc/login.defs oder /etc
/securetty (falls sie PAM verwenden) implementiert. In:
• login.defs, ändern sie die CONSOLE Variable, die eine Datei oder eine Liste von Terminals definiert, an denen sich root einloggen darf
• securetty entfernen sie oder fügen sie Terminals hinzu, bei denen Root Zugriff erhalten darf
Wenn sie PAM benutzen können sie auch andere Änderungen am Login Prozess, die auch
Einschränkungen für einzelne Benutzer oder Gruppen zu bestimmten Zeiten enthalten können, durch konfigurieren der Datei /etc/pam.d/login vornehmen. Eine interessante Eigenschaft, die man auch abschalten kann, ist die Möglichkeit, sich mit einem leeren Passwort (null
Passwort) einzulogen. Diese Eigenschaft kann eingeschränkt werden, indem sie nullok aus der
Zeile
auth
entfernen.
required
pam_unix.so nullok
4.6
37
Systemneustart auf der Konsole einschränken
Wenn an ihr System eine Tastatur angeschlossen ist, kann jeder (ja wirklich jeder) ihr System
neu starten, ohne sich in ihr System einlogen zu müssen. Dies könnte oder könnte nicht gegen
ihre Sicherheits Richtlinie verstoßen. Wenn sie dies einschränken wollen, müssen sie in /etc
/inittab prüfen, ob die Zeile, die enthält, dass ctrlaltdel shutdown aufruft, den -a
Schalter enthält (vergessen sie nicht, init q auszuführen, nachdem sie diese Datei irgendwie
verändert haben). Der standardmässig enthält Debian diesen Schalter:
ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now
Jetzt müssen sie, um es manchen Benutzern zu erlauben, ihr System neu zu starten, eine Datei
/etc/shutdown.allow erstellen, wie es in der Manual Seite shutdown(8) beschreibt. Dort
müssen die Namen der Benutzer, die das System neu booten dürfen, aufgeführt sein. Wenn der
drei Finger Salut (auch bekannt als Strg+Alt+Entf ) ausgeführt wird, wird geprüft, ob irgendeiner der Benutzer, die in der Datei aufgelistet sind, eingeloggt sind. Wenn es keiner von ihnen
ist, wird shutdown das System nicht neu starten.
4.7
Partitionen auf die richtige Art einbinden
Wenn sie eine ext2 Partition einbinden, können sie verschiedene Optionen mit dem mountBefehl oder in /etc/fstab verwenden. Dies zum Beispiel, ist mein fstab Eintrag für meine
/tmp Partition:
/dev/hda7
/tmp
ext2
defaults,nosuid,noexec,nodev
0
2
Sie sehen den Unterschied in der Spalte mit den Optionen. Die Option nosuid ignoriert alle
setuid und setgid Bits komplett, während noexec das ausführen irgendwelcher Programme
unterhalb des mount Points verbietet und nodev Geräte ignoriert. Das hört sich toll an, aber
es
• ist nur auf ext2 Dateisysteme anwendbar
• kann leicht umgangen werden
Die noexec option, die verhindert, dass Binaries ausgeführt werden können, lässte sich leicht
umgehen:
alex@joker:/tmp# mount | grep tmp
/dev/hda7 on /tmp type ext2 (rw,noexec,nosuid,nodev)
alex@joker:/tmp# ./date
bash: ./date: Permission denied
alex@joker:/tmp# /lib/ld-linux.so.2 ./date
Sun Dec 3 17:49:23 CET 2000
38
Wie auch immer, viele Skriptkiddies haben Exploits, die versuchen eine ausführbare Datei in
/tmp zu erstellen. Wenn sie keine Ahnung haben, werden sie in dieser Grube hängenbleiben.
Mit anderen Worten: Ein Benutzer kann nicht dazu getrickts werden, einen ausführbaren Trojaner in /tmp auszuführen, zum Beispiel indem er zufällig /tmp in seine Suchpfad aufnimmt.
Seien sie auch gewarnt, dass manche Skripts darauf aufbauen, dass /tmp ausführbare Rechte
hat. Bemerkenswerter weise hatte (oder hat?) Debconf Probleme bei dieser Sache, weitere Informationen enthält Bug 116448 (http://bugs.debian.org/116448).
Nachfolgend ist ein gründlichereres Beispiel. Dazu: /var könnte auch noexec enthalten, aber
manche Software, wie zum Beispiel Smartlist, behält seine Programme unterhalb von /var.
Das selbe gillt für die nosuid Option.
/dev/sda6
/dev/sda12
/dev/sda7
/dev/sda8
/dev/sda9
/dev/sda10
/dev/sda11
/dev/sda13
/dev/fd0
/dev/fd0
/dev/hda
4.7.1
/usr
/usr/share
/var
/tmp
/var/tmp
/var/log
/var/account
/home
/mnt/fd0
/mnt/floppy
/mnt/cdrom
ext2
ext2
ext2
ext2
ext2
ext2
ext2
ext2
ext2
vfat
iso9660
defaults,ro,nodev
0
2
defaults,ro,nodev,nosuid
0
defaults,nodev,usrquota,grpquota
defaults,nodev,nosuid,noexec,usrquota,
defaults,nodev,nosuid,noexec,usrquota,
defaults,nodev,nosuid,noexec
0
defaults,nodev,nosuid,noexec
0
rw,nosuid,nodev,exec,auto,nouser,async
defaults,users,nodev,nosuid,noexec
defaults,users,nodev.nosuid,noexec
ro,users,nodev.nosuid,noexec
/tmp noexec setzen
Seien sie vorsichtig, wenn sie /tmp noexec setzen und neue software installieren wollen, da
manche Software es während der Installation benutzt. Apt ist ein solches Programm (siehe
http://bugs.debian.org/116448), wenn nicht APT::ExtractTemplates::TempDir
(siehe apt-extracttemplates(1)) passend konfiguriert wurde. Sie können diese Variable
in /etc/apt/apt.conf auf ein anderes Verzeichnis als /tmp mit exec Privilegien setzen.
Was noexec betrifft, seien sie sich bitte bewusst, dass es ihnen nicht sehr viel Sicherheit bietet.
Regarding noexec, please be aware that it might not offer you that much security. Berücksichtigen sie dies:
$ cp /bin/date /tmp
$ /tmp/date
(wird aufgrund des noexec nicht ausgeführt)
$/lib/ld-linux.so.2 /tmp/date
(funktioniert, da date nicht direkt ausgeführt wird)
4.7.2
Setzen von /usr auf nur-lesen
Wenn sie auf /usr nur lesenden Zugriff erlauben, werden sie nicht in der Lage sein, neue
Pakete auf ihrem Debian GNU/Linux System installieren können. Sie werden es erst wieder
39
mit Schreibzugriff neumounten müssen, die Pakete installieren, und dann wieder read-only
mounten. Die neuste Version von apt (in Debian 3.0 ’woody’) kann konfiguriert werden Befehle
vor und nach dem installiern von Paketen auszuführen, also möchten sie es vielleicht passend
konfigurieren.
To do this modify /etc/apt/apt.conf and add:
DPkg
{
Pre-Invoke { "mount /usr -o remount,rw" };
Post-Invoke { "mount /usr -o remount,ro" };
};
Beachten sie sie, dass das Post-Invoke mit einer “/usr busy” Fehlermeldung scheitern wird.
Dies passiert vorwiegend, wenn sie eine Datei während des Updates benutzen. Ärgerlich,
aber kein grosses Problem. Gehen sie einfach sicher, dass sie nicht länger benutzt werden,
und führen sie das Post-Invoke manuell aus.
4.8
Ausführen von Sicherheitsupdates
Sobald neue Sicherheitslöcher in einem Paket entdeckt wurden reparieren sie Debian PaketBetreuer und ursprüngliche Autoren im allgemein innerhalb von Tagen oder sogar Stunden.
Nachdem das Loch gestopft wurde, werden neue Pakete unter http://security.debian.
org bereit gestellt.
Wenn sie eine Debian Release installieren müssen sie berücksichtigen, dass es, seitdem der
Releas gemacht wurde, Sicherheitsupdates geben könnte, nachdem entdeckt wurde, dass ein
bestimmtes Paket verwundbar ist. Ebenso könnte es kleinere Releases gegeben haben (es gab
acht kleinere Releases von Debian 2.2 potato), die diese Paktet-Updates enthalten.
Sie müssen sich das Erstellungsdatum ihres CD Sets (wenn sie ein solches benutzen) notieren,
und auf der Sicherheitsseite prüfen, ob es Sicherheits-Updates gegeben hat. Wenn es solche
gibt, und sie sie die Pakete nicht von der Sicherheits-Seite herunterladen können (Ihr System
ist noch nicht mit dem Internet verbunden, oder?), könnten sie es in erwähgung ziehen (falls
sie nicht, beispielsweise durch eine Firewall, geschützt sind), Firewall-Regeln zu aktivieren,
so dass ihr System ausschliesslich mit securety-debian.org Verbindung aufnehmen kann und
dann ein update Ausführen. Eine Beispiel-Konfiguration finden sie unter ‘Sicherheits-Update
geschützt durch eine Firewall’ auf Seite 159.
Um ihr System upzudaten, fügen sie die folgende Zeile in ihre /etc/apt/sources.list,
und sie werden Sicherheits-Updates automatisch erhalten, wann immer sie ihr System updaten.
deb http://security.debian.org/debian-security stable/updates main contrib non
40
Die meisten Leute, die nicht in einem Land leben, das den import oder die Nutzung starker
Kryptographie verbietet, sollte auch diese Zeile hinzufügen:
deb http://security.debian.org/debian-non-US stable/non-US main contrib non-fr
Wenn sie möchten, können sie ebenfalls eine deb-src Zeile hinzufügen. Weitere Details finden
sie unter apt(8).
Sie sollten regelmässig Sicherheits-Updates durchführen, die meisten Sicherheitsprobleme resultieren aus bekannten Sicherheitslücken heraus, die nicht rechtzeitig gestopft wurden, wie
auch http://www.cs.umd.edu/~waa/vulnerability.html name=“paper by Bill Arbaugh”> (vorgetrafen auf dem 2001 IEEE Symposium on Security and Privacy) erklärt.
FIXME: Add info on how the signature of packages is done so that this can be done automatically through a cron job (big warning: DNS spoofing).
4.9
4.9.1
Den Benutzern einen Sicheren Zugang bereitstellen
User Authentifizierung: PAM
PAM (Pluggable Authentication Modules) erlauben dem System Administrator auszuwählen,
wie eine Anwendung, Benutzer authentifiziert. Beachten sie, dass PAM nichts machen kann,
solange die Anwendung nicht mit Unterstützung für PAM kompiliert wurde. Die meisten Anwendungen, die mit Debian 2.2 geliefert werden, habend diese Unterstützung eingebaut. Weiterhin hatte Debian keine Unterstützung für PAM vor Version 2.2. Die derzeitige StandardKonfiguration für jedweden PAM benutzenden Service, ist es, UNIX Authentifizierung
zu emulieren (lessen sie /usr/share/doc/libpam0g/Debian-PAM-MiniPolicy.gz um
mehr darüber zu erfahren, wie PAM Services unter Debian arbeiten sollten).
Jede Anwendung mit PAM Unterstützung bietet eine Konfiguratiosn Datei unter /etc/pam.d
/ in welche sie ihr Verhalten einstellen können:
• welches Verfahren zur Authentifizierung benutzt wird.
• welches Verfahren innerhalb einer Sitzung benutzt wird.
• wie Passwörter überprüft werden.
Die folgende Beschreibung ist weit davon entfernt komplett zu sein, für weitere Informationen möchten sie vielleicht The Linux-PAM System Administrator’s Guide (http://
www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam.html) (auf der PAM
Hauptseite (http://www.kernel.org/pub/linux/libs/pam/)), diese Dokumentation
ist auch in dem Paket libpam-doc enthalten.
PAM bieten ihnen die Möglichkeit durch mehrere Authentifizierungs Schritte auf einmal zu
gehen, ohne das der Benutzer es weiß. Sie können gegen eine Berkeley Datenbank und gegen
41
die normale passwd Datei authentifizieren, und der Benutzer kann sich nur einloggen, wenn er
beide Male korrekt authentifiziert wurde. Sie können viel einschränken mit PAM, genauso wie
sie ihr System weit öffnen können. Seien sie also vorsichtig. Eine typische Konfigurationszeile
hat ein Kontrollfeld als sein zweites Element. Generell sollte es auch “requisite” gesetzt werden, so wird ein login Feger erzeugt, wenn eines der Module versagt.
Die erste Sache, die ich gerne mache, ist es, MD5 Unterstützung zu den PAM Anwendungen
hinzuzufügen, da dies gegen lexikalische Attacken hilft (da Passwörter länger sein können,
wenn sie MD5 benutzen). Die folgenden zwei Zeilen sollten sie in allen Dateien unterhalb von
/etc/pam.d/ zufügen die Zugriff auf ihre Maschine gewähren, wie zum Beispiel login und
ssh.
# Gehen sie sicher, dass sie libpam-cracklib zuerst installiert haben,
# sonst werden sie sich nicht einloggen koennen
password
required
pam_cracklib.so retry=3 minlen=12 difok=3
password
required
pam_unix.so use_authtok nullok md5
Also, was macht diese Beschwörungsformel nun genau? Die erste Zeile lädt das cracklib PAM
Modul, welches einen Passwort-Sicherheits-check bereitstellt; es fragt nach einem neuen Passwort mit einem Minimum von 12 Zeichen, einer Differenz von mindestens 3 Zeichen zum alten
Passwort, und erlaubt 3 Versuche. Die zweite Zeile führt das standard authentifizierungs Modul mit MD5 Passwörtern ein und erlaubt Passwörter mit einer Länge von Null. Die use_authtok
Direktive ist notwendig, um das Passwort von dem vorherigen Modul übergeben zu bekommen.
Um sicher zu stellen, dass sich der Benutzer root nur von lokalen Terminals einloggen kann,
sollten sie die folgende Zeile in /etc/pam.d/login eingefügt werden:
auth
requisite
pam_securetty.so
Nun sollten sie alle Terminals, von denen sich der Benutzer Root einloggen können sollte,
in /etc/security/acces.conf eintragen. Nicht zuletzt sollten sie die folgende Zeile aktivieren, wenn sie ihrem Benutzern Limits setzen wollen:
session
required
pam_limits.so
Dies schränkt die System die ein User nutzen darf ein (siehe unter in ‘Resourcen-Nutzung
limitieren: Die limits.conf Datei’ auf Seite 43). Sie können zum beispiel die Anzahl der Logins,
die man haben kann, einschänken (für eine Gruppe von Nutzern oder Systemweit), die Anzahl
der Prozesse, den belegten Speicher. . .
Editieren sie nun /etc/pam.d/passwd und ändern sie die erste Zeile. Si sollten die Option
“md5” zufügen, um MD5-Passwörter zu benitzen, ändern sie die minimale Passwort-Länge
von 4 auf 6 (oder mehr) und setzen sie eine Maximallänge, wenn sie möchten. Die resultierende
Zeile wird in etwa so aussehen:
password
required
42
pam_unix.so nullok obscure min=6 max=11 md5
Wenn sie su schützen möchten, so dass nur manche Leute es benutzen können, um root auf
ihrem System zu werden, müssen sie eine neue Gruppe “wheel” zu ihrem System hinzufügen
(das ist der sauberste Weg, da keine Datei solche Gruppenrechte bisher benutzt). Fügen sie
root und die anderen Benutzer, die zu root suen können sollen, zu dieser Gruppe. Fügen sie
anschliessend die folgene Zeile zu /etc/pam.d/su/ hinzu:
auth
requisite
pam_wheel.so group=wheel debug
Dies stellt sicher, dass nur Personen aus der Gruppe wheel su benutzen können, um root zu
werden. Andere Benutzer wird es nicht möglich sein, root zu werden. Tatsächlich werden sie
eine ablehnende Nachricht bekommen, wenn sie versuchen root zu werden.
Wenn sie es nur bestimmten Nutzern erlauben wollen, sich bei einem PAM Service zu authentifizieren, ist dies sehr leicht zu erreichen, indem sie Dateien benutzen, in denen die Nutzer, denen es erlaubt ist sich einzulogen (oder nicht), gespeichert sind. Stellen sie sich vor, sie möchten
lediglich dem Nutzer ’ref’ erlauben, sich via ssh einzuloggen. Sie schreiben in also in eine Datei
/etc/ssh-users-allowed und schreiben das folgende in /ect/pam.d/ssh:
auth
required
pam_listfile.so item=user sense=allow file=/etc/sshuse
Zuletzt, aber nicht am unwichtigsten, erstellen sie /etc/pam.d/other mit den folgenden
Zeilen:
auth
auth
auth
auth
account
account
account
password
password
password
session
session
session
required
required
required
required
required
required
required
required
required
required
required
required
required
pam_securetty.so
pam_unix_auth.so
pam_warn.so
pam_deny.so
pam_unix_acct.so
pam_warn.so
pam_deny.so
pam_unix_passwd.so
pam_warn.so
pam_deny.so
pam_unix_session.so
pam_warn.so
pam_deny.so
Diese Zeilen stellen für alle Anwendungen, die PAM unterstützen, eine gute StandardKonfiguration dar (Zugriff wird standardmässig verweigert).
4.9.2
43
Resourcen-Nutzung limitieren: Die limits.conf Datei
Sie sollten sich wirklich ernsthaft mit dieser Datei beschäfftigen. Hier können sie ihren
Benutzern Resourcen-Limits definieren. Wenn sie PAM benutzen, wird die Date /etc
/limits.conf ignoriert und sie sollten /etc/security/limits.conf stattdessen benutzen.
Wenn sie die Resourcen Nutzung nicht einschränken, kann jeder Nutzer mit einem einer gültigen Shell auf ihrem System (or sogar ein Einbrecher, der das System durch einen Service
kompomotierte) so viel CPU, Speicher, Stack etc. benutzen, wie das System zur verfügung
stellen kann. Dieses Problem der Resourcen Überbeanspruchung kann nur mit der Nutzung von
PAM gelöst werden. Beachten sie, dass es einen Weg gibt, Resourcen Limits zu manchen Shells
hinzuzufügen (zum Beispiel hat bash ulimit, siehe bash(1)), aber da nicht alle die gleichen
Limits zur verfügung stellen und da der Nutzer seine Shell ändern kann (siehe chsh(1)), ist
es besser, die Limits in den PAM Modulen zu plazieren.
Für mehr Informationen hierzu lesen sie:
• PAM
configuration
article
sam0009a/0009a.htm).
(http://www.samag.com/documents/s=1161/
• Seifried’s Securing Linux Step by Step (http://seifried.org/security/os/
linux/20020324-securing-linux-step-by-step.html) in dem Limiting users
overview Abschnitt.
• LASG (http://seifried.org/lasg/users/) in dem Limiting and monitoring users
Abschnitt.
FIXME: Get a good limits.conf up here
4.9.3
User Login Actionen: Editieren von /etc/login.defs
Der nächste Schritt ist es, die grundlegende Konfiguration und die Actionen bei User Login zu
editieren.
FAIL_DELAY
10
Diese Variable sollte auf einen höheren Wert gesetzt werden, um es schwerer zu machen, mittels Brute Force (roher Gewalt, sturres Durchprobieren, Anm. d. Übers.) auf einem Terminal
einzuloggen. Wenn ein falsches Passwort eingegeben wird, muss der potentielle Angreifer
(aber auch der normale Benutzer!) 10 Sekunden warten, um einen neuen login Prompt zu
bekommen, was auf die Dauer viel Zeit kostet, wenn sie Passwörter durchtesten. Beachten sie
jedoch die Tatsache, dass diese Einstellung nutzlost ist, wenn sie ein anderes Programm als
getty benutzen, wie zum Beispiel mingetty.
FAILLOG_ENAB
yes
44
Wenn sie diese Variable einschalten werden fehlgeschlagene Logins protokoliert. Es ist wichtig
hier auf dem laufendem zu bleiben, um jemanden zu fassen, der eine Brute Force Attacke
versucht.
LOG_UNKFAIL_ENAB
yes
Wenn sie die Varible “FAILLOG_ENAB” auf yes gesetzt haben, dann sollten sie auch diese
Variable auf yes setzen. Dies wird auch unbekannte Nutzernamen protokolieren. Wenn sie dies
tun, gehen sie auch sicher, dass die Protokolle sinnvolle Zugriffsrechte haben (Zum Beispiel
640, mit einer angemessenen Gruppenzugehörigkeit, wie adm), weil Nutzer oft versehentlich
ihr Passwort als Usernamen eingeben und dies anderen nicht zugänglich machen wollen.
SYSLOG_SU_ENAB
yes
Dies schaltet das Mitprotokollieren von su Versuchen im Syslog ein. Sehr wichtig auf ernsthaften Maschinen, aber beachten sie, dass dies auch die Privatsphähre verletzen kann.
SYSLOG_SG_ENAB
yes
Dasgleiche wie bei SYSLOG_SU_ENAB, jedoch für das Programm sg.
MD5_CRYPT_ENAB
yes
Wie bereits erklärt, reduzieren MD5-Summen-Passwörter grossartig das Problem lexikalischer Attacken, da sie längere Passwörter benutzen können. Wenn sie slink benutzen, lesen sie
die Dokumentation zu MD5 bevor sie diese Option einschalten. Ansonsten wird dies in PAM
gesetzt.
PASS_MAX_LEN
50
Wenn sie MD5-Passwörter in ihrer PAM Konfiguration aktiviert haben, dann sollten sie diese
Variable auf denselben Wert setzen, den sie dort benutzt haben.
4.9.4
ftp Einschränken: Editieren von /etc/ftpusers
Die Datei /etc/ftpusers enthält eine Liste von allen Nutzern, denen es nicht erlaubt ist, sich
auf dem host mit ftp einzuloggen. Benutzen sie diese Datei nur, wenn sie wirklicht ftp erlauben
wollen (wozu im allgemmeinen nicht geraten wird, da es Klartext Passwörter benutzt). Wenn
ihr ftp Daemon PAM unterstützt, können sie dies ebenfalls benutzen, um Nutzern bestimmte
Services zu erlauben oder zu verbieten.
FIXME (BUG): Is it a bug that the default ftpusers in Debian does not include all the administrative users (in base-passwd).
4.9.5
45
su benutzen
Wenn es wirklich benötigt wird, dass Nutzer Super User auf ihrem System werden, zum
Beispiel um Pakete zu installieren oder neue Benutzer anzulegen, können sie das Programm
su benutzen, um ihre Identität zu wechseln. Sie sollten jeden Login als Nutzer Root vermeiden
und stattdessen ddas Programm su benutzen. Eigentlich ist es die betste Lösung su zu entfernen, und zu sudo zu wechseln, da es mehr Möglichkeiten bietet als su. Wie auch immer, su
ist allgemeiner und wird auf vielen Unices benutzt.
4.9.6
sudo benutzen
Das sudo erlaubt es dem Benutzer, ein definiertes Kommando unter einer anderen NutzerIdentität auszuführen, sogar als Root. Wenn der Nutzer zu /etc/sudoers hinzugefüft ist
und sich korrekt authentifiziert ist er in der Lage, Kommandos, die in /etc/sudoers definiert
wurde. Sicherheitsverletzungen, wie ein inkorrektes Passwort oder der Versuch ein Programm
auszuführen, für das ihre Rechte nicht ausreichen, werden protokolliert und an root gemailt.
4.9.7
verweigern von administrativen Fernzugriff
Sie sollten /etc/security/access.conf ebenfalls so modifizieren, dass ein administrativer Login aus der Ferne nicht erlaubt ist. Auf diese Weise müssen die Nutzer das Programm
su (oder sudo) benutzen, so dass es immer eine prüfbare Spur gibt, wann immer ein Nutzer
administrative Möglichkeiten nutzen möchte.
Sie müssen die folgende Zeile zu ihrer /etc/security/access.conf hinzufügen, die Debians Standard-Konfigurations Datei hat ein Beispiel auskommentiert:
-:wheel:ALL EXCEPT LOCAL
4.9.8
Nutzer einschränken
Manchmal werden sie vielleicht denken, dass sie einen Nutzer auf ihrem System erstellen
müssen, um einen bestimmten Service (pop3 Email Server oder ftp) anzubieten. Bevor sie dies
tun, erinnern sie sich zuerst darad, dass die PAM Implementierung in Debian GNU/Linux ihnen erlaubt, Nutzer mit einer breiten Auswahl von externen Verzeichnisdiensten (radius, ldap,
etc.) zu bestätigen. Dies wird vom libpam Paket bewerkstelligt.
Wenn sie einen Nutzer anlegen müssen, und auf ihr System aus der Ferne zugegeriffen werden
kann, beachten sie, dass es Nutzern möglich sein wird, sich einzuloggen. Sie können dies behebeben, indem sie diesen Nutzer eine Null (/dev/null) als Shell (sie müsste in /etc/shells
gelistet sein) zuweisen. Wenn sie den Nutzern erlauben wollen, auf das System zuzugreifen,
aber ihre Bewegungen einschränken wollen, können sie /bin/rbash benutzen, als ob sie die
-r Option der Bash (RESTRICTED SHELL, siehe bash(1)) verwendet hätten. Beachten sie
46
bitte, dass sogar mit einer restricted Shell ein Nutzer, ein Nutzer, der auf ein interaktives Programm zugreifen kann (dass es ihm erlauben würde, eine subshell auszuführen), diese Limitierung der Shell umgehen kann.
Debian bietet zur Zeit in seiner unstable Release (und wird es vielleicht der nächste stable
Release hinzufügen) das pam_chroot Modul. Eine Alternative hierzu ist es, den Service, der
einen Fern-Login anbietet (ssh, telnet), in einer chroot-Umgebung laufen zu lassen.
Wenn sie einschränken wollen, wann ein Nutzer auf das System zugreifen kann, müssen sie
/etc/security/access.conf an ihre Bedürfnisse anpassen.
ssh für Nutzer einschränken
Debian’s sshd wird ihnen nicht erlauben, die Bewegungen eines Nutzer durch den Server
einzuschränken, da er die Chroot Funktionalität, die das kommerzielle Programm (sshd2) hat
(benutzen sie ’ChrootGroups’ oder ’ChrootUsers’, siehe dazu sshd2_config(5)). Wie auch
immer, es gibt einen Patch, der ihnen erlaubt dies zu tun, den Patch erhalten sie von Bug
Report 139047 (http://bugs.debian.org/139047) oder von http://www.cag.lcs.
mit.edu/~raoul/ (und er wird wohl in der Zukunft auf das OpenSSH Paket angewendet
werden). Emanuel Lacour hat ssh Paktete mit diesen Fähigkeiten unter http://debian.
home-dn.net/woody/ssh/, allerdings wird empfohlen durch die Compilierungs-Schritte
zu gehen. Eine Beschreibung von den notwendigen Schritten finden sie unter http://mail.
incredimail.com/howto/openssh/ (so ziemlich alles trifft dort auch auf Debian zu, auch
wenn von RedHat 7.2 die rede ist). Nachdem sie den Patch angewendet haben, müssen sie
die /etc/passwd anpassen, indem sie das Heimat-Verzeichnis des Nutzers ändern (in den
speziellen /./ Token).
joeuser:x:1099:1099:Joe Random User:/home/joe/./:/bin/bash
Dies wird beides einschränken, sowohl remote Zugriff auf die Shell als auch remote Copy über
einen ssh Kanal.
Gehen sie sicher, dass sie alle benötigten Binaries in den Chroot-Pfaden für den Nutzer haben.
Diese Dateien sollte Root besiutzen, um Einmischungen durch den Nutzer zu verhinern (zum
Beispiel die chrooted Sandbox zu verlassen). Ein Beispiel könnte so aussehen:
./bin:
total 660
drwxr-xr-x
drwxr-xr-x
-r-xr-xr-x
-r-xr-xr-x
-r-xr-xr-x
-rwxr-xr-x
-r-xr-xr-x
-r-xr-xr-x
2
8
1
1
1
1
1
1
root
guest
root
root
root
root
root
root
root
guest
root
root
root
root
root
root
4096
4096
531160
43916
16684
23960
9916
24780
Mar
Mar
Feb
Nov
Nov
Mar
Jul
Nov
18
15
6
29
29
18
26
29
13:36
16:53
22:36
13:19
13:19
13:36
2001
13:19
.
..
bash
ls
mkdir
more
pwd
rm
47
lrwxrwxrwx
1 root
root
./etc:
total 24
drwxr-xr-x
drwxr-xr-x
-rw-r--r--rw-r--r--rw-r--r--rw-r--r--
2
8
1
1
1
1
root
guest
root
root
root
root
4096
4096
54
428
44
52
Mar
Mar
Mar
Mar
Mar
Mar
15
15
15
15
15
15
16:13
16:53
13:23
15:56
15:53
13:23
.
..
group
hosts
passwd
shells
root
guest
root
root
root
root
root
root
root
4096
4096
92511
1170812
20900
9436
248132
71332
34144
Mar
Mar
Mar
Mar
Mar
Mar
Mar
Mar
Mar
18
15
15
15
15
15
15
15
15
13:37
16:53
12:49
12:49
13:01
12:49
12:48
13:00
16:10
.
..
ld-linux.so.2
libc.so.6
libcrypt.so.1
libdl.so.2
libncurses.so.5
libnsl.so.1
root
root
root
root
root
29420
105498
25596
7760
24328
Mar
Mar
Mar
Mar
Mar
15
15
15
15
15
12:57
12:51
12:51
12:59
12:57
libpam.so.0
libpthread.so.0
librt.so.1
libutil.so.1
libwrap.so.0
4096
4096
4096
4096
Mar
Mar
Mar
Mar
15
15
15
15
13:00
16:53
15:55
15:37
.
..
bin
lib
4096
4096
10332
13052
25432
43768
218456
9692
Mar
Mar
Mar
Mar
Mar
Mar
Mar
Mar
15
15
15
15
15
15
15
15
15:55
13:00
15:55
13:13
12:40
15:15
12:40
13:17
.
..
env
id
scp
sftp
ssh
tty
root
guest
root
root
root
root
./lib:
total 1848
drwxr-xr-x
2 root
drwxr-xr-x
8 guest
-rwxr-xr-x
1 root
-rwxr-xr-x
1 root
-rw-r--r-1 root
-rw-r--r-1 root
-rw-r--r-1 root
-rw-r--r-1 root
-rw-r--r-1 root
libnss_files.so.2
-rw-r--r-1 root
-rw-r--r-1 root
-rw-r--r-1 root
-rw-r--r-1 root
-rw-r--r-1 root
./usr:
total 16
drwxr-xr-x
drwxr-xr-x
drwxr-xr-x
drwxr-xr-x
4
8
2
2
root
guest
root
root
root
guest
root
root
./usr/bin:
total 340
drwxr-xr-x
drwxr-xr-x
-rwxr-xr-x
-rwxr-xr-x
-r-xr-xr-x
-rwxr-xr-x
-r-sr-xr-x
-rwxr-xr-x
2
4
1
1
1
1
1
1
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
root
4 Mar 30 16:29 sh -> bash
./usr/lib:
total 852
drwxr-xr-x
2 root
drwxr-xr-x
4 root
-rw-r--r-1 root
libcrypto.so.0.9.6
-rw-r--r-1 root
-rwxr-xr-x
1 root
4.9.9
48
root
root
root
4096 Mar 15 15:37 .
4096 Mar 15 13:00 ..
771088 Mar 15 13:01
root
root
54548 Mar 15 13:00 libz.so.1
23096 Mar 15 15:37 sftp-server
prüfen der Nutzer von Hand
Wenn sie paranoid sind, dann möchten sie den Nutzern vielleicht eine definierte .profile
aufzwingen, das die Environments so setzt, dass sie die Überwachungsmöglichkeiten der Shell
nicht entfernen können (Kommandos werden auf $HISTFILE ausgegeben). Die .profile
könnte so gesetzt werden:
HISTFILE=/home/_user_/.bash_history
HISTSIZE=100000000000000000
HISTFILESIZE=10000000000000000
set -o HISTFILE
set -o HISTSIZE
set -o HISTFILESIZE
export HISTFILE HISTSIZE HISTFILESIZE
Beachten sie: Das -o-Attribut erlaubt nur lesenden Zugriff auf die Variable.
Damit dies funktioniert darf der Nutzer .profile oder .bash_history nicht modifizieren,
aber er muss ersteres lesen und letzteres schreiben können. Sie können dies leicht tun, indem
sie die Dateien und das Verzeichnis, indem sich diese Dateien befinden, so dass sie einem anderen Benutzer gehören (root), und For this to work the user cannot modify the .profile,
und der Gruppe des Nutzers auf die History-Datei Schreibzugriff gewähren. Eine andere
Möglichkeit ist es, dass Programm chattr zu benutzen.
Wenn sie wirklich paranoid sind und jedes Kommando des Nutzers protokollieren wollen,
könnten sie den Quellcode der Bash nehmen, ihn ändern und sie alles, das der Nutzer
eingibt in einer anderen Datei ausgibt. Oder sie lassen ttysnoop konstant jedes neue tty
überwachen und die Ausgaben in einer Datei ausgeben. Ein anderes nützliches Programm
ist Snoopy (http://sourceforge.net/project/?group_id=2091). Dies ist ein für den
Nutzer transparentes Programm, dass sich als eine Bibliothek zwischen hängt, und eine Hülle
um execve() Aufrufe bildet, jedes ausgeführte Kommando wird im syslogd aufgezeichnet,
indem die authpriv-Möglichkeit benutzt wird (üblicherweise wird dies unter /var/log
/auth.log gespeichert).
Beachten sie, dass sie hierfür nicht das script Kommando benutzen können, da sies nicht als
Shell funktionert (auch nicht, wenn sie es zu /etc/shells hinzufügen).
4.9.10
49
Komplettieren von Nutzer Überwachung
Die vorherigen Beispiele sind ein einfacher Weg, um Nutzer Überwachung zu konfigurieren,
eignet sich aber nicht unbedingt für komplexe Systeme. Sollte dies der Fall sein, schauen
sie sich das Paket acct, die accounting Utilities, an. Diese werden alle Kommandos, die ein
Nutzer oder ein Prozess auf dem System ausführt, auf die Kosten von Plattenplatz aufzeichnen.
Wenn sie diese ’Buchführung’ aktivieren, werden alle Informationen über Prozesse und Nutzer
unter /var/account/ gehalten. Das Accounting-Paket schließt Werkzeuge (sa und ac) zur
Analyse dieser Daten ein.
4.9.11
Nutzer Profil nachprüfen
Wenn sie sehen wollen, was Nutzer normalerweise tun, wenn sie sich verbinden, können sie
die wtmp Datenbank benutzen, die alle Login-Informationen enthält. Diese Datei kann mit
verschiedenen Werkzeugen weiterverarbeitet werden, unter ihnen sac, das ein Profil für jeden
Nutzer ausgeben kann, dass zeigt, in welchem Zeitfenster sie sich für gewöhnlich auf dem
System einloggen.
Für den Fall, dass sie accounting aktiviert haben, können sie auch die mitgelieferten
Werkzeuge verwenden, um festzustellen, wann Nutzer auf das System zugreifen und was sie
ausführen.
4.9.12
umasks der Nutzer einstellen
Abhängig von ihrer Richtlinien möchten sie vielleicht ändern, wie Nutzer Informationen teilen
können, was die Standardrechte von neu erstellten Dateien sind. Dies ändern sie, indem sie
eine passende umask f¨r alle Nutzer einstellen. Sie können sie UMASK-Einstellung in /etc
/limits.conf, /etc/profile, /etc/csh.cshrc, /etc/csh.login, /etc/zshrc und
wahrscheinlich auch noch andere (abhängig von den Shells, die sie auf ihrem System installiert haben). Von all diesen hat die zuletzt geladene Vorrang: PAM’s limits.conf, die standard
System Konfiguration für die Shell des Nutzers, die Shell des Nutzers (sein ~/.profile), ~
/.bash_profile. . . )
Debian’s default umask Einsztellung is 022, d.h., dass Dateien (und Verzeichnisse) von Nutzer
aus der Gruppe und jedem anderen Nutzer des Systems lesbar und zugreifbar sind. Wenn dies
zu grosszügig für ihr System ist, müssen sie die umask Einstellung für alle Shells (und für
PAM) ändern. Vergessen sie nicht die Dateien unter /etc/skel/ anzupassen, da dort die die
Standards für Nutzer werden, wenn sie mit dem adduser Kommando erstellt werden.
Beachten sie, dass ein Nutzer immernoch seine umask Einstellung abändern kann, wenn sie es
möchten, um sie grosszügiger oder einschränkender zu machen.
4.9.13
50
Nutzer Sicht/Zugriff limitieren
FIXME: Content needed. Tell of consequences of changing packages permissiones when upgrading (and admin this paranoid should chroot his users BTW).
Wenn sie einem Nutzer Zugriff auf das System mit einer Shell gewähren müssen, bedenken
sie es vorsichtig. Ein Nutzer kann normalerweise, wenn er nicht in eine streng abgeschirmte
Umgebung (wie chroot) gesetzt wird, ziemlich viel Informationen von ihrem System sammeln, darunter:
• Din paar Konfigurationsdateien unter /etc. Jedoch werden Debian’s Standard Rechte
auf sensitive Dateien (die zum Beispiel Passwörter enthalten könnten) den Zugriff auf
kritische Informationen verhindern. Um zu sehen, auf welche Dateien nur der root
Nutzer zugreifen kann, führen sie zum Beispiel find /etc -type f -a -perm 600
-a -uid 0 als superuser aus.
• Ihre installierten Pakete, entweder durch ansehen der Paket-Datenbank, des /usr
/share/doc Verzeichnisses oder durch raten, indem man die Binaries und Bibliotheken
durchsieht, die auf ihrem System installiert sind.
• Ein paar Protokolle unter /var/log. Beachten sie, das auf einige Protokolle nu root und
die adm Gruppe zugreifen kann (versuchen sie find /var/log -type f -a -perm
640) und manche sind sogar ausschliesslich für root verfügbar (versuchen sie some logfiles at /var/log. Note also that some find /var/log -type f -a -perm 600
-a -uid 0).
Was kann ein Nutzer von ihrem System sehen? Wahrscheinlich ziemlich viele Sachen, versuchen sie mal folgendes (und jetzt tief durchatmen):
find / -type f -a -perm +006 2>/dev/null
find / -type d -a -perm +007 2>/dev/null
Was sie sehen ist eine Liste von allen Dateien, die ein Nutzer einsehen, und die Verzeichnisse,
auf die er Zugriff hat.
4.10
Die Nutzung von tcpwrappers
TCP-Wrapper (Schurtzumschläge für TCP) wurden entwickelt, als es noch keine echten PaketFilter gab, aber Zugsngskontrollen notwendig waren. Ein TCP-Wrapper erlaubt ihnen, einem
Host oder einer Domain einen Service zu erlauben oder zu verweigern und default-mässig
Zugriff zu erlauben oder zu verweigern. Wenn sie mehr Informationen haben möchten, sehen
sie sich hosts_access(5) an.
Viele der unter Debian installierten Services
51
• werden entweder durch den TCP-Wrapper service (tcpd) aufgerufen
• oder wurden mit libwrapper (Bibltiothek für TCP-Wrapper) Unterstützung kompiliert
Einerseits werde manche Services, einschliesslich telnet, ftp, netbios, swat und finger in
/etc/inetd.conf konfiguriert. Sie sehen es daran, dass die Konfigurations-Datei zuerst
/usr/sbin/tcpd aufruft. Andererseits, selbst wenn ein Service nicht über den inetdSuperdaemon ausgeführt wird, kann es in jedem Fall, den TCP-Wrapper-Regeln unterworfen werden, indem man die Unterstützung dafür einkompiliert. Services, die unter Debian
mit TCP-Wrappern compiliert wurden, schliessen ssh, portmap, in.talk, roc.statd, rpc.mountd,
gdm, oaf (der GNOME-Aktivierungs daemon), nessus und viele andere ein.
Um herauszufinden, welche Pakete TCP-Wrapper benutzen, versuchen sie folgendes:
$ apt-cache showpkg libwrap0 | egrep ’^[[:space:]]’ | sort -u | \
sed ’s/,libwrap0$//;s/^[[:space:]]\+//’
Beachten sie bitte folgendes, wenn sie tcpchk laufen lassen: Sie können Services, die gegen
dei Wrapper-Bibliothek kompiliert wurden, der host.deny oder host.allow Datei hinzufügen, aber aber tcpchk wird sie warnen, dass er sie nicht finden kann, da er sie in /etc
/inetd.conf sucht (die Manual-Seite ist an dieser Stelle nicht sehr genau).
Jetzt kommt ein kleiner Trick, und vielleicht die kleinste Alarmanlage zur Erkennung von Eindringlingen: Im allgemeinen sollten sie eine anständige Firewall als erste und TCP-Wrapper
als zweite Verteidigungslinie haben. Der Trick besteht nun darin ein SPAWN 1 Kommando in
/etc/hosts.deny einzutragen, das immer dann eine Mail an root schickt, wenn der Wrapper eines abgewiesenden Services ausgelöst wurde:
ALL: ALL: SPAWN ( \
echo -e "\n\
TCP Wrappers\: Verbindungsaufbau abgelehnt\n\
By\: $(uname -n)\n\
Prozess\: %d (pid %p)\n\
Nutzer\: %u\n\
Host\: %c\n\
Datum\: $(date)\n\
" | /usr/bin/mail -s "Verbinung zu %d blockiert" root) &
Beachten Sie: Das obige Beispiel kann sehr leicht geDoSet (Denial of Service, Verbindungsaufbau abgelehnt) werden, indem man versucht, sehr viele Verbindungen in kurzer Zeit
aufzubauen. Viele Emails bedeuten viel Datei-Aktivitöt, lediglich erreicht durch das Senden
von ein paar Paketen.
1
Vermeiden Sie den Fall hier, da spawn nicht funktionieren wird
4.11
52
Die Wichtigkeit von Logs und Alarmen
Wie Logs (Protokolldateien) und Alarme in einem sicheren System behandelt werden ist eine
wichtige Angelegenheit. Es ist leicht zu verstehen, dass selbst wenn ein System angeblich perfekt konfiguriert und zu 99% sicher ist, es immer noch 1% Restrisiko gibt, für die keine Sichereheitsmaßnamen greifen. Als erstes gillt es, Angriffe auf diese 1% zu erkennen und als zweites
Alarm auszuölösen, oder das System ist in keinster Weise sicher.
Debian GNU/Linux stellt Tools zur Verfügung, die die Analyse von Log-Dateien übernehmen,
am beachtenswertesten logcheck oder loganalysis (beide Pakete werden ein wenig Anpassung benötigen, um unnötige Dinge aus den Reports zu entfernen). Wenn sich das System
in der Nähe befindet, könnte es nützlich sein, das System-Log auf einer virtuellen Konsole
auszugeben. Die ist nützlich, da Sie so (auch von weiter weg oder im vorbeigehen) sehen
können, ob sich das System richtig verhält. Debians /etc/syslog.conf kommt mit einer
kommentierten Standard-Konfiguration. Um diese Ausgabe einzuschalten, unkommentieren
Sie die entsprechenden Zeilen und starten syslog neu (/etc/init.d/syslogd restart):
daemon,mail.*;\
news.=crit;news.=err;news.=notice;\
*.=debug;*.=info;\
*.=notice;*.=warn
/dev/tty8
Es gibt da noch einiges über Log-Analyse, das hier nicht behandelt werden kann. Eine gute
Quelle für weiter Informationen ist Counterpane’s Log Analysis Resources (http://www.
counterpane.com/log-analysis.html). In jedem Fall sind selbst automatische Tools
dem besten Tool nicht gewachsen: Ihrem Gehirn.
4.11.1
Nutzen und anpassen von logcheck
Das Programm logcheck ist in Debian in zwei Pakete aufgeteilt: logcheck (das HauptProgramm) und logcheck-database (eine Datenbank regulärer Ausdrücke für das Programm). Der Standard unter Debian (unter /etc/cron.d/logcheck) ist, dass logcheck
jeweils um 14:00 Uhr und nach jedem Neustart ausgeführt wird.
Dieses Tool kann sehr nützlich sein, wenn es geeignet angepasst wurde, um den Administrator zu alarmieren, wenn etwas ungewöhnliches auf dem System passiert. Logcheck
kann vollständig angepasst werden, so dass es Mails über Ereignisse aus den Logs sendet,
die Ihrer Aufmerksamkeit bedürfen. Die Standard-Installation umfasst Profile zum ignorieren von Ereignissen und Regelwidrigkeiten für drei unterschiedliche Setups (Workstation,
Server und paranoid). Das Debian-Paket umfasst eine Konfigurations-Datei /etc/logcheck
/logcheck.conf, die vom Program eingelesen wird, die definiert, an welchen Nutzer die
Testergebnisse geschickt werden sollen. Es stellt ausserdem einen Weg für Pakete zur Verfügung, um neue Regeln in den Verzeichnissen zu realisieren: /etc/logcheck/hacking.d
/_packagename_, /etc/logcheck/violations.d/_packagename_, /etc/logcheck
/violations.ignore.d/_packagename_,
/etc/logcheck/ignore.d.paranoid
53
/_packagename_, /etc/logcheck/ignore.d.server/_packagename_, und /etc
/logcheck/ignore.d.workstation/_packagename_. Leider benutzen das noch nicht
viele Pakete. Wenn Sie ein Regelwerk entwickelt haben, dass für andere Nutzer nützlich sein
könnte, senden Sie bitte einen Bug-Report für das ensprechende Paket (als ein wishlist-Bug).
Mehr Informationen finden Sie unter /usr/share/doc/logcheck/README.Debian.
Der beste Weg logcheck zu konfigurieren ist es, es einfach zu installieren (Sie werden
gefragt werden, an welchen Nutzer die Mail-Reports geschickt werden soll, und ob aus
den Einträgen im Syslog wird ein /etc/logcheck/logcheck.logfiles generiert werden soll). Wenn Sie andere Logfiles hinzufügen möchten, ändern Sie einfach /etc/logcheck
/logcheck.logfiles indem Sie sie hinzufügen. Die Paket-Abhängigkeiten werden dafür
sorgen, dass logcheck-database auch installiert wird. Während der Installation werden Sie gefragt, welches Sicherheits-Niveau benötigt wird: workstation, server oder paranoid. Dadurch wird /etc/logcheck/ignore.d (durch einen symbolischen Link) auf die
richtigen Verzeichnisse zeigen. Um dies zu ändern führen Sie dpkg-reconfigure -plow
logcheck-database aus. Erstellen Sie dann eine Datei /etc/ignore.d/local; diese
Datei enthält alle Regeln, Meldungen auszuschliessen, die nicht gemeldet werden sollen.
Lassen Sie es für den Anfang leer (ein einfaches cp /dev/null /etc/ignore.d/local
sollte reichen).
Wenn Sie dies einmal geschafft haben, sollten Sie die nächtsen Tage/Wochen/Monate die
verschickten Mails prüfen, ob Sie Meldungen geschickt bekommen, die Sie nicht erhalten
wollen. Fügen Sie dann einen entsprechenden regulären Ausdruck (siehe regex(7)) zu /etc
/ignore.d/local. Die ist ein andauernder Tuning-Pozess. Wenn nur noch relevante Meldungen verschickt werden, können Sie davon ausgehen, dass dieser Prozess beendet ist.
Beachten Sie, dass Logcheck Ihnen keine Mail schickt, wenn es nichts relevantes auf Ihrem
System findet, selbst wenn es läuft (so bekommen Sie höchstens eine Mail pro Woche, wenn
Sie Glück haben).
4.11.2
Konfigurieren, wohin Alarmmeldungen geschickt werden sollen
Debian kommt mit einer Standard-Konfiguration für Syslog (in /etc/syslog.conf), so dass Meldungen je nach System in die passenden Dateien geschrieben werden. Das sollte Ihnen bereits
bekannt sein, werfen Sie einen Blick auf die Datei syslog.conf und deren Dokumentation,
falls nicht. Wenn Sie ein sicheres System pflegen wollen, sollten Ihnen bekannt sein, wohin
Log-Meldungen geschickt werden, so dass Sie nicht unbeachtet bleiben.
Zum Beispiel ist es für viele produktiv Systeme sinnvoll Meldungen auch auf der Konsole
auszugeben, aber bei vielen solcher Systeme ist es sehr wichtig, auch eine neue Maschine zu
nehmen, die für die anderen als ein Loghost fungieren wird (d.h. sie empfängt die Logs aller
anderen Systeme).
Sie sollten auch an Mails für Root denken, da viele Sicherheits-Kontrollen (wie snort) ihre
Alarme an die mailbos von root senden. Diese Mailbos zeigt normalerweise an den ersten
Nutzer, der auf dem System erstellt wurde (prüfen Sie dazu /etc/aliases). Sorgen Sie dafür,
dass roots Mails irgendwo hin geschickt wird, wo sie auch gelesen werden (entweder lokal
oder ferngesteuert).
54
Es gibt noch andere Accounts besonderer Funktion und andere Aliase auf Ihrem System. Auf
einem kleinen System ist es wohl am einfachtes, sicherzustellen, dass alle Alias auf den RootAccount zeigen, und dass Mails an root in das persönliche Postfach des System-Administrator
weiter geleitet werden.
FIXME: it would be interesting to tell how a Debian system can send/receive SNMP traps
related to security problems (jfs). Check: snmptraglogd, snmp and snmpd.
4.11.3
Nutzen eines loghosts
Ein Loghost ist ein host der die syslog-Daten über ein Netzwerk sammelt. Wenn eine Ihrer
Maschinen gecracked wird, kann der Eindringling seine Spuren nicht verwischen, solange
er den Loghost nicht ebenfalls gecracked hat. Demzufolge muss der Loghost also besonders
sicher sein. Aus einer Maschinen einen Loghost zu machen ist relativ einfach: Starten Sie den
syslogd einfach mit ’syslogd -r’, und ein neuer Loghost ist geboren. Um dies unter Debian
permanent zu machen, editieren Sie /etc/init.d/sysklogd und änder Sie die Zeile
SYSLOGD=""
in
SYSLOGD="-r"
Als nächstes konfigurieren Sie die anderen Machinen, ihre Daten an den Loghost zu senden.
Fügen Sie einen Eintrag, ähnlich dem folgenden zu der /etc/syslog.conf hinzu:
facility.level
@Ihr_Loghost
Schauen Sie in die Dokumentation um zu erfahren, wodurch Sie facility und level ersetzen können (Sie sollten nicht wörtlich übernommen werden). Wenn Sie alles fern mitloggen wollen,
schreiben sie einfach:
*.*
@Ihr_Loghost
in Ihre syslog.conf. Sowohl lokal als auch entfernt mitzuloggen ist die beste Lösung (ein
Angreifer könnte davon ausgehen, dass er seine Spuren verwischt hat, nachdem er die lokale
Logdatei gelöscht hat). Sehen Sie für weitere Informationen die Handbuch-Seiten syslog(3),
syslogd(8) und syslog.conf(5).
4.11.4
55
Zugriffsrechte auf Log-Dateien
Es ist nicht nur wichtig zu entscheiden, wie Warnungen genutzt werden, sondern auch, wer
hierauf zugriff hat, d.h. wer Log-Dateien (fall Sie nicht einen Log-Host verwenden) lesen
oder verändern kann. Sichereheits-Alarme, die ein Attacker verändern oder abschalten kann,
sind im Falle eines Eindringens nicht viel wert. Ausserdem sollten Sie berücksichtigen, dass
Log-Dateien einem Eindringling sehr viel Informationen über Ihr System enthüllen kann und
welche normalen (und annormalen) Operationen er ausführen kann, wenn er darauf Zugriff
hat.
Ein Paar Zugriffsrechte auf Log-Dateien sind nach der Installation nicht gerade perfekt (aber
das hängt natürlich von Ihrer lokalen Sicherheits-Policy ab). Zuerst einmal müssen /var/log
/lastlog und /var/log/faillog nicht für normalen Nutzer lesbar sein. In der lastlogDatei können Sie sehen, wer sich zuletzt eingeloggt hat, und in faillog eine Zusammenfassung
fehlgeschlagener Logins. Der Author empfiehlt beides auf 660 zu chmod’en. Werfen Sie einen
kurzen Blick auf Ihre Log-Dateien, und entscheiden Sie sehr vorsichtig, welche Log-Dateien sie
les- oder schreibbar für einen Nutzer mit einer anderen UID als 0 und einer anderen Gruppe
als ’adm’ oder ’root’ machen. Sie können dies sehr leicht auf Ihrem System überprüfen:
# find /var/log -type f -exec ls -l {} \; | cut -c 17-35 |sort -u
(zeigt zu welchen Nutzern /var/log gehört)
# find /var/log -type f -exec ls -l {} \; | cut -c 26-34 |sort -u
(zeigt zu welchen Gruppen /var/log gehört)
# find /var/log -perm +004
(zeigt, welche Dateien von jedem Nutzer gelesen werden können)
# find /var/log \! -group root \! -group adm -exec ls -ld {} \;
(zeigt, welche Dateien zu anderen Gruppen als root oder adm gehört)
Um anzupassen, wie neue Log-Dateien erstellt werden, müssen Sie wahrscheinlich das Programm anpassen, dass sie erstellt. Wenn die Log-Dateien rotiert werden, können Sie das Verhalten bei der Erstellung und Rotation anpassen.
4.12
Benutzen von chroot
chroot chroot ist eine der mächtigsten Möglichkeiten einen Daemon, einen Nutzer oder
einen anderen Service einzuschränken. Stellen Sie sich einfach ein Gefängnis um Ihr Ziel vor,
aus dem Ihr Ziel nicht ausbrechen kann (Normalerweise, aber es gibt immernoch ein paar Bedinungen, unter denen es erlaubt es, aus einem solchen Gefängnis auszubrechen). Wenn Sie
einem Nutzer nicht trauen können Sie ihm eine Change-Root-Umgebung erstellen. Dies kann
zwar einiges an Platten-Platz verbrauchen, da Sie alles benötigte Ausführbare in das Geföngnis kopieren müssen, ebenso wie alle Bibliotheken. Sogar wenn der Nutzer etwas boshaftes
anstellt, ist der Schadensrahmen auf das Gefängnis beschränkt.
Ein gutes Beispiel für diesen Fall ist es, wenn Sie nicht mit /etc/passwd authentifizieren,
sondern stattdessen LDAP oder MySQL verwenden. So benötigt Ihr ftp-Daemon lediglich ein
56
Binary und vielleicht ein paar Bibliotheken. Ein ge-chroot-ete Umgebung wäre eine exzellente
Sicherheits-Umgegung; wenn ein neuer Exploit für diesen ftp-Daemon bekannt wird kann ein
Angreifer nur die Nutzer-ID (User-ID, UID) des internen ftp-Daemon-Nutzers ausnutzen und
nichts anderes.
Natürlich kann auch die Sicherheit ander Daemonen von einem solchen Arrangement profitieren.
Seien Sie jedoch vorgewarnt, dass man auch aus einem chroot-Gefängnis ausbrechen kann,
wenn der Nutzer, der es laufen lässt der Superuser ist. Also ist es notwendig, dass Sie den
Service als nicht privilegierter Nutzer laufen lassen. Indem Sie die Umgebung einschränken,
schränken Sie die für alle les- / ausführbaren Dateien, auf die das System Zugriff hat, und so
verkleinern Sie die Möglichkeit einer Ausweitung der System-Privilegien indem lokale Verwundbarkeiten der Systemsicherheit ausgenutzt werden. Aber sogar in dieser Situation können Sie nicht wirklich sicher sein, dass es für einen cleveren Angreifer keinen Weg gibt, irgendwie aus dem Gefängnis auszubrechen. Es ist eine zusätzliche Sicherheitsmassnahme nur
Server-Programme zu benutzen, die einen gewisse Reputation in Sachen Sicherheit haben. Sogar die kleinste Lücke, wie eine offene Behandlung von Dateien kann von einem geschickten
Angreifer genutzt werden, um in das System einzubrechen. Schliesslich wurde chroot nicht
als Sicherheits-Werkzeug designed, sondern als Test-Werkzeug.
Eine zusätzliche Anmerkung: BIND (Berkeley Internet Name Domain) ist standardmässig
unter Debian nicht ge-chroot-et. Tatsächlich ist dies bei keinem Daemon der Fall.
Es gibt übrigens Software (derzeit nicht unter Debian, aber in der Zukunft sollte sie paketiert
sein), die helfen Kann, eine chroot-Umgebung einzurichten. Zum Beispiel kann makejail mit
sehr kleinen Konfigurations-Dateien chroot-Gefängnisse erstellen und aktualisieren. Es versucht ausserdem alle für den Daemon benötigten Dateien zu erraten und in dem Gefängis
zu installieren. Mehr Informationen finden Sie unter http://www.floc.net/makejail/.
Jailer ist ein ähnliches Werkzeug, dass Sie unter http://www.balabit.hu/downloads/
jailer/ erhalten.
Für das erstellen von chroots (oder Gefänsnissen) ist ausserden deb.pl, ein Skript das die
Abhängigkeiten ein oder mehrerer Dateien analysiert.
4.12.1
Kernel configuration
4.12.2
Konfigurieren der Netzwerk-Fähigkeiten des Kernels
FIXME: Content missing
Viele Fähigkeiten des Kernels können im laufenden Betrieb verändert werden, indem man
etwas in das /proc-Datei-System echo-t oder indem man sysctl benutzt. Geben Sie sysctl
-A ein, um zu sehen, was Sie konfigurieren können und wie die Optionen hierfür sind. Nur in
selten Fällen müssen Sie hier etwas verstellen, aber Sie können auf diese Art auch die Sicherheit
erhöhen.
net/ipv4/icmp_echo_ignore_broadcasts = 1
57
Dies ist ein «Windows Emulator», weil es sich wie Windows bei Rundrufen (Broadcast-Ping)
verhält, wenn es auf 1 gesetzt wird. Anderenfalls macht es gar nichts.
net/ipv4/icmp_echo_ignore_all = 0
Wenn Sie kein ICMP auf Ihrer Firewall blockieren wollen, schalten Sie dies ein.
net/ipv4/tcp_syncookies = 1
Diese Option ist ein zweischneidiges Schwert. Auf der einen Seite schützt es Ihr System gegen
überfluten von syn-Paketen, auf der anderen Seite verletzt es definierte Standards (RFCs).
Diese Option ist recht dumm , da es die Gegenseite ebenso flutet wie Sie, so dass die Gegenseite auch beschäfftigt ist. Wenn Sie diese Option ändern wollen, können Sie es auch in /etc
/network/options ändern, indem Sie syncookies=yes setzten.
/proc/sys/net/ipv4/conf/all/log_martians = 1
Packete mit unmöglichen Adressen (erzeugt durch falsche Routen) in Ihrem Netzwerk werden
protokolliert.
Hier ist ein Beispiel wie man dies und andere nützliche Sachen setzen kann. Sie sollten diese
Informationen zu einem Skript /etc/network/interface-secure (der Name kommt aus
einem Beispiel) hinzufügen , und es durch /etc/network/interfaces wie nachfolgend
gezeigt aufrufen lassen:
auto eth0
iface eth0 inet static
address xxx.xxx.xxx.xxx
netmask 255.255.255.xxx
broadcast xxx.xxx.xxx.xxx
gateway xxx.xxx.xxx.xxx
pre-up /etc/network/interface-secure
# Skript-Name: /etc/network/interface-secure
# Modifiziert das normale Verhalten um uns gegen manche TCP/IP Attacken
# und Manipulationen zu schützen
#
# beigetragen von Dariusz Puchalak
#
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
# Rundruf-Antwort-Schutz
# einscahlten
echo 0 > /proc/sys/net/ipv4/ip_forward
# ip-Weiterleutung abschalten
echo 1 > /proc/sys/net/ipv4/tcp_syncookies # TCP-Syn-Cookie Schutz einschalten
58
echo 1 >/proc/sys/net/ipv4/conf/all/log_martians
# Packete mit unmöglichen
# Adressen logen, seien Sie
# hiermit auf ausgelasteten
# Webservern vorsichtig
echo 1 > /proc/sys/net/ipv4/ip_always_defrag
# Defragmentierungs-Schutz
# immer einschalten
echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
# Schutz vor schlechten
# Fehlermeldungen einschalten
# Jetzt kommt Schutz vor ip-Spoofing
for f in /proc/sys/net/ipv4/conf/*/rp_filter; do
echo 1 > $f
done
# und schliesslich noch ein paar andere Sachen:
# Akzeptieren von umgeleitetet ICMP abschalten
for f in /proc/sys/net/ipv4/conf/*/accept_redirects; do
echo 0 > $f
done
for f in /proc/sys/net/ipv4/conf/*/send_redirects; do
echo 0 > $f
done
# Abschalten von Source Routed Packets
for f in /proc/sys/net/ipv4/conf/*/accept_source_route; do
echo 0 > $f
done
# Logen von gespooften Paketen, Source Routed Paketen und Redirect
# Paketen
for f in /proc/sys/net/ipv4/conf/*/log_martians; do
echo 1 > $f
done
4.12.3
Konfigurieren der Firewall
Um die Möglichkeiten einer Firewall zu haben, um entweder das lokale System oder andere
dahinter zu beschützen, muss der Kernel mit Firewall-Unterstützung compiliert worden sein.
Der standard Debian 2.2 Kernel (also der Kernel-Version 2.2) stellt die Paket-Filter-Firewall
ipchains zur Verfügung, der Debian 3.0 Standard Kernel (Version 2.4) stellt die stateful
Oaket-Filter iptables (netfilter) Firewall zur Verfügung. Ältere Debian Distributionen wür-
59
den einen passenden Kernel-Patch (Debian 2.1 nutzte Kernel 2.0.34) benötigen.
In jedem Fall ist es recht einfach einen anderen, als den von Debian installierten Kernelzu
benutzen. Sie finden vor-compilierte Kernel als Pakete, die Sie leicht auf Ihrem Debian System
installieren können. Sie können auch die Kernel-Quellen downloaden, indem Sie das Paket
kernel-source-X installieren, und Ihren eigens angepassten Kernel compilieren, indem Sie
make-kpkg benutzen.
Auf das Aufsetzen einer Firewall unter Debian wird unter ‘Hinzufügen von Firewall Fähigkeiten’ auf Seite 84 ausführlich eingegangen.
4.13
Den Kernel patchen
FIXME: More content
Debian GNU/Linux stell verschiedene Patches für den Linux-Kernel zur Vergügung, die die
Sicherheit erhöhen:
• Linux Eindringling-Erkennung (Linux Intrusion Detection, im Paket lids-2.2.19)
• Linux Capabilities (im Paket lcap)
• Linux Trustees (im Paket trustees)
• NSA Enhanced Linux (im Paket selinux, auch verfügbar von der Seite des PaketBetreuers (http://www.coker.com.au/selinux/))
• kernel-patch-2.2.18-openwall (http://packages.debian.org/kernel-patch-2.
2.18-openwall).
• kernel-patch-2.2.19-harden
• Kernel-Unterstützung von IPSEC (im Paket kernel-patch-freeswan)
• kernel-patch-int
Wie auch immer, einige Patches werden von Debian noch nicht zur Verfügung gestellt. Wenn
Sie denken, dass manche von Ihnen hinzugefügt werden sollten, fragen Sie auf Work Needing
and Prospective Packages (http://wnpp.debian.org) nach ihnen. Ein paar von Ihnen sind:
• PaX patch (http://pageexec.virtualave.net/)
• HAP patch (http://www.theaimsgroup.com/~hlein/hap-linux/)
• Stealth patch (http://www.energymech.net/madcamel/fm/)
4.14
60
Schutz vor Speicher-Überläufen
Speicher-Überlauf werde die Attacken über Software genannt, die unzureichende Überprüfung von Eingabegrenzen (ein häufiger Programmierfehler) ausnutzen, um durch ProgrammEingaben Befehle auf der Maschine auszuführen. Diese Attacken über Server, die auf
Verbindungen warten, oder über lokal installierte Software, die einem Nutzer grössere Privilegien gewährt (setuid oder setgid) kann zu einem kompromitierten System führen.
Es gibt hauptsächlich vier Methoden, um sich gegen Speicher-Überläufe zu schützen:
• patchen des Kernels, um Ausführen des Stapel-Speichers zu verhindern
• Nutzung einer Bibliothek wie libsafe, um verwundbare Funktionen zu überschreiben
und ordentliche Prüfungen einzuführen (Informationen wie man libsafe installiert finden
Sie hier (http://www.Linux-Sec.net/harden/libsafe.uhow2.txt)).
• Neucompilieren des Quellcodes, um vernünftige Prüfungen einzuführen, um Überläufe
zu berhinden, in dem man zum Beispiel stackguard benutzt.
• Nutzen von Werkzeugen um Stellen im Quellcode zu finden, die derart verwundbar
sind, und reparieren derselben.
Debian GNU/Linux liefert bis einschliesslich der Release 3.0 lediglich Software um die erste und die letzte dieser Methoden zu implementieren (Kernel-Patch und Werkzeuge um
mögliche Speicher-Überläufe zu finden). Zur Nutzung dieser Werkzeuge zum aufsprühren
von Speicher-Überläufen benötigen Sie in jedem Fall Programmier-Erfahrung, um den
Quellcode zu reparieren (und neu zu compilieren). Debian stell beispielsweise bfbtester
(einen Überlauf-Tester, der Programe per brute-force (durchtesten aller Möglichkeiten) auf
Kommado-Zeile und Umgebungs-Variablen durchtestet) und njamd zur Verfügung.
Was Kernel-Patches (beschrieben im Abschnitt ‘Den Kernel patchen’ auf der vorherigen Seite) betrifft, so stellt der Openwall-Patch Schutz gegen Speicher-Überläufe in 2.2er
Linux-Kerneln zur verfügung, während Sie für 2.4er Kernel den Grsecureity-Patch (im
Paket kernel-patch-2.4-grsecurity enthält neben vielen anderen Sachen (ACLs,
Zufälligkeiten im Netzwerk, und es zu erschweren das Betriebssystem zu erraten)
auch den Openwall-Patch, siehe features (http://www.grsecurity.net/features.
htm)) oder die Linux-Sicherheits-Module (in den Paketen kernel-patch-2.4-lsm und
kernel-patch-2.5-lsm) benutzen müssen.
Seien Sie in jedem Fall gewarnt, dass selbst diese Problemumgehungen nicht vor SpeicherÜberläufen schützen lännen, da es wiederum Möglichkeiten gibt diese zu umgehen, wie es
in Ausgabe 58 (http://packetstorm.linuxsecurity.com/mag/phrack/phrack58.
tar.gz) des phrack-Magazins beschrieben wurde.
4.15
61
sichere Datei-Übertragungen
Während der normalen System-Administration müssen Sie immer mal wieder Dateien auf
Ihr System spielen oder von diesem holen. Auf sichere Art und Weise Dateien von einem
Host zu einem anderen zu wird duch die Benutzung des Paketes sshd erreicht. Eine andere
Möglichkeit ist die Nutzung von ftpd-ssl, einem ftp-Server der Secure Socket Layer benutzt,
um transmissionen zu verschlüsseln.
Jede dieser Methoden benötigt natürlich einen speziellen Client. Debian stellt Ihnen solche
zur Verfügung, zum Beispiel enthält das Paket ssh das Programm scp. Es arbeitet wie rcp
aber komplett verschlüsselt, so dass die bösen Jungs nocht nicht einmal herausbekommen können, WAS Sie kopieren. Wie es den Server gibt, so gibt es natürlich auch ein ftp-ssl ClientPaket. Sie können Clients für diese Software sogar für andere (nicht-UNIXoide) Betriebssysteme finden. putty und winscp stellen eine secure-copy-Implementierung für jede Version
von Microsoft-Betriebssystemen zur Verfügung.
4.16
Dateisystem Einschränken und konrollieren
4.16.1
Benutzung von Quotas
Es ist wichtig eine gute Quota-Regelung zu haben, da es die Nutzer daran hindert, die Festplatten zu füllen.
Sie können zwei Arten von Quota-Systemen benutzen: Nutzer-Quota und Gruppen-Quota.
Wie Sie sicher denken können, limitiert User-Quota den Plattenplatz, den ein Nutzer belegen
kann, und Gruppen-Quota macht dasselbe für ganze Gruppen. Beachten Sie dies, wenn Sie die
Grössen der Quotas festlegen.
Es ein paar wichtige Punkte, über die Sie nachdenken sollten, wenn Sie ein Quota-System
aufsetzen:
• Halten Sie die Quotas klein genug, so dass die Nutzer Ihre Festplatte nicht aufzehren
können.
• Halten Sie die Quotas gross genug, so dass Nutzer sich nicht beschweren oder dass Ihr
Mail-Quota Sie daran hindert nach eine Weile Mails anzunehmen.
• Nutzen Sie Quotas auf allen Bereichen, die Nutzer beschreiben können, auf /home ebenso wie auf /tmp.
Auf jeder Partition/jedem Verzeichniss, auf dass Nutzer Schreibzugriff haben, sollten quotiert
sein. Finden Sie diese Partitionen udn Verzeichnisse und schätzen Sie eine sinnvolle QuotaGrösse, die Nutzbarkeit und Sicherheit kombiniert.
So, nun wollen Sie Quotas benutzen. Zuerst müssen Sie prüfen, ob Ihr Kernel Quota unterstützt. Wenn nicht müssen Sie ihn neu compilieren. Prüfen Sie anschliessen, ob das Paket
quota isntalliert ist. Wenn nicht, installieren Sie es.
62
Um Quota für die entsprechenden Dateisysteme einzuschalten müssen Sie nur die Einstellung defaults in Ihrer Datei /etc/fstab zu defaults,usrquota ändern. Wenn Sie
Gruppen-Quotas benötigen, ersetzen sie usrquota durch grpquota. Sie können auch beides verwenden. Erstellen Sie dann lere Dateien quota.user und quota.group in den
Hauptverzeichnissen der Dateisysteme, auf denen Sie quotas einführen möchten (d.h. touch
/home/quota.user /home/quota.group für das Dateisystem /home).
Starten Sie quota neu, indem Sie ein /etc/init.d/quota stop;/etc/init.d/quota
start ausführen. Nun sollte quota laufen, und die Grössen können festgelegt werden.
Bearbeiten der Quotas eines bestimmten Nutzer (sagen wir mal “ref”) wir mit edquota -u
ref gemacht. Gruppen-Quotas können mit edquota -g <group> geändert werden. Setzen
Sie dann die weiche und die harte Grenze und/oder inode-Quotas, wenn Sie es benötigen.
Mehr Informationen über Quotas finden Sie in der Manual-Seite von quota, und der quota
Mini-Howto (/usr/share/doc/HOWTO/en-html/mini/Quota.html).
Sie könnten auch lshell mögen, oder auch nicht, da es den FHS verletzt. Beachten Sie ausserdem dass pam_limits.so diegleiche Funktionalität zur Verfügung stellen kann und das lshell
Paket zur Zeit verwaist (http://bugs.debian.org/93894) ist.
4.16.2
chattr/lsattr
Diesen beiden Befehle sind sehr nützlich, aber Sie arbeiten nur auf ext2 Dateisystemen. Mit
’lsattr’ können Sie die Attributen einer Datei anzeigen lassen und mit ’chattr’ können Sie sie
ändern. Beachten Sie, dass Attribute nicht dasselbe sind, wie Zugriffsrechte. Es gibt viele Attribute, aber nur die wichtigsten, die die Sicherheit erhöhen, werden hier erwähnt. Es gibt zwei
Kennzeichnungen (flags), die nur der Superuser setzen kann.
Zunächst gibt es das ’a’ Flag. Wenn dieses bei einer Datei gesetzt ist, dann kann an diese Datei
nur angehängt werden. Dieses Attribut ist für einige Dateien in /var/log/ nützlich, beachten
Sie aber, dass durch Log-Rotations-Skripte Dateien manchmal verschoben werden.
Das zweite Flag ist das ’i’-Flag, kurz für immutable also unveränderlich. Wenn Sie eine Datei so
behandeln, kann Sie weder modifiziert, noch gelöscht, noch umbenannt werden, oder verlinkt
werden. Wenn Sie nicht möchten, dass Nutzer einen Blick auf Ihre Konfigurations-Dateien
werfen können, setzen Sie dieses Flag, und entfernen Sie die Lesbarkeit. Zusätzlich bietet es
Ihnen etwas mehr Sicherheit gegen Eindringlinge, da ein Cracker dadurch verwirrt werden
könnte, wenn er eine Datei nicht verschieben kann. Dennoch sollten Sie nicht davon ausgehen,
dass ein Cracker von Blindheit geschlagen ist, immerhin ist er in Ihr System eingedrungen.
Zusätzlich können Sie die Programme chattr und lsattr von Ihrem System entfernen, so
dass ein Eindringling mit root-Zugang diese Attribute nicht verändern (oder auflisten) kann.
Da Sie Teil von e2fsprogs sind und dieses die Priorität required hat, können Sie das Paket
nicht einfach entfernen. Sie können jedoch diese beiden Applikationen (und wahrscheinlich
noch andere) einfach läschen. Kopieren Sie sie vorher auf einen auswechselbaren Datenträger
(Diskette?) zusammen mit ihrem md5-Summen.
Ein Eindringling auf ihrem System müsste so erst eigene Kopien dieser Programme herunterladen (wahrscheinlich sogar selbst compilieren), so dass Sie etwas mehr Zeit bekommen, den
63
Angriff zu erkennen und die Komprimitierungen rückgängig zu machen, bevor das gesamte
System überrannt wird.
FIXME: This is a bug that could be reported, are any of the binaries provided by the program
useful in production systems? If not, and since the libraries are needed by many packages a
new package e2fsprogs-utils could be included with less than Required priority.
Vergessen Sie nicht: chattr und lsattr sind nur für das Dateisystem ext verfügbar.
4.16.3
Prüfen der Integrität des Dateisystems
Sind Sie sicher, dass /bin/login auf Ihrer Festplatte immernoch dasselbe Programm ist, dass
Sie vor ein paar Monaten installiert haben? Was wenn es sich um eine gehackte Version handelt, die eingegebene Passwörter in einer versteckten Datei ablegt oder Sie als Klartext im
ganzen Internet herummailt?
Die einzige Methode einen gewissen Schutz dafür zu haben ist es die Dateien jede(n)
Stunde/Tag/Monat (ich ziehe täglich vor) zu prüfen, indem man deren aktuelle und alte md5Summe vergleicht. Zwei unterschiedliche Dateien können keine gleichen md5-Summen haben
(Die md5-Summe umfasst 128 Bits, so ist die Wahrscheinlichkeit, dass zwei unterschiedliche
Dateien eine gleiche md5-Summe haben eta 1 zu 3,4e3803), so sind Sie sicher, solange niemand
den Algorithmus gehackt hat, der die md5-Summen auf Ihrer Maschine erstellt. Dies ist, nunja, extrem schwer und sehr unwahrscheinlich. Sie sollten diese Überprüfung Ihrer Programme
als sehr wichtig ansehen. Weit verbreitete Tools hierfür sind sXid, AIDE (Advanced Intrusion
Detection Environment, fortgeschrittene Eindringlings Erkennungs Umgebung), TripWire
(non-free; die neue Version wird GPL lizensiert), integrit und samhain.
Das installieren von debsums wird Ihnen helfen, die Integrität des Dateisystems zu überprüfen, indem Sie die md5-Summen jeder Datei gegen die md5-Summe aus dem DebianArchiv-Paket vergleichen. Seien Sie aber gewarnt, dass diese Dateien sehr leicht geändert werden können.
Weiterhin können Sie locate durch slocate ersetzen. slocate ist eine um Sicherheit erweiterte Version von GNU locate. Wenn Sie slocate benutzen, sieht ein Benutzer nur Dateien, auf
die er auch zugriff hat, während Sie alle Dateien und Verzeichnisse des gesamten Systems
ausschliessen können.
FIXME: put references to the snapshot taken after installation.
FIXME: Add a note regarding packages not providing debsums for all apps installed (not
mandatory).
4.16.4
Aufsetzen von setuid-Check
Debian liefert einen täglich ausgeführten Cron-Job /etc/cron.daily/standard. Dieser
Cron-Job führt das Skript /usr/sbin/checksecurity, das Informationen über Änderungen sichert.
64
Damit dieser Check ausgeführt wird, müssen Sie in /etc/checksecurity.conf
CHECKSECURITY_DISABLE=“FALSE” setzen. Dies ist bereits der Standardwert, so dass diese
Option bereits aktiviert sein sollte, solange Sie nichts geändert haben.
Das Standard-Verhalten sendet diese Informationen nicht an den Superuser, stattdessen hält
es eine tägliche Kopie dieser Änderungen unter /var/log/setuid.changes. Sie sollten CHECKSECURITY_EMAIL (in /etc/checksecurity.conf) auf ’root’ setzen, damit
diese Informationen an ihn gemailt werden. Sehen Sie auch checksecurity(8) für weitere
Konfigurations-Informationen.
4.17
Einen Schnappschuss des Systems erstellen
Bevor Sie das System in eine produktive Umgebung stellen, können Sie einen Schnappschuss
des gesamten Systems machen. Diesen Schnappschuss können Sie im Falle einer Kompromitierung (siehe ‘Nach einer Komprimitierung’ auf Seite 115) benutzen. Sie sollten so einen
Schnappschuss immer dann erneuern, wenn Sie das System upgraden, insbesondere wenn Sie
auf eine neue Debian Release upgraden.
Hierfür können Sie beschreibbare, austauschbare Datenträger benutzen, die Sie schreibschützen können. Dies kann eine Diskette sein (die nach der Benutzung schreibgeschützt wird)
oder eine CD in einem CD-ROM Laufwerk (sie können auch wieder beschreibbare CD-ROMs
benutzen, so können Sie sogar alte Sicherheitskopien Ihrer md5-Summen behalten).
Das folgende Skript erstellt einen solchen Schnappschuss:
#!/bin/bash
/bin/mount /dev/fd0 /mnt/floppy
/bin/cp /usr/bin/md5sum /mnt/floppy
echo "Erstelle md5 Datenbank"
>/mnt/floppy/md5checksums.txt
for dir in /bin/ /sbin/ /usr/bin/ /usr/sbin/ /lib/ /usr/lib/
do
find $dir -type f | xargs /usr/bin/md5sum >>/mnt/floppy/md5checksums-lib.tx
done
/bin/umout /dev/fd0
echo "md5 Datenbank (nach der Installation) erstellt"
Beachten Sie, dass das Programm md5sum auch auf der Diskette gesichert wird, so dass Sie
es später benutzen können, um die anderen Programme Ihres Systems zu prüfen (gesetz dem
Fall das md5sum einen Trojaner enthält).
Dieser Schnappschuss enthält nicht die Dateien unterhalb von /var/lib/dpkg/info, wo
md5-Summen installierter Pakete enthalten sind (die Dateien enden mit .md5sums). Sie können diese Informationen zusätzlich kopieren, aber Sie sollten folgendes beachten:
65
• die md5sums der Debian Pakete enthalten alle md5-Summen der Dateien, die ein Paket
enthält, so dass die Datenbank viel grösser wird (5 MB statt 600 KB auf einem Debian
GNU/Linux System mit graphischen Subsystem und etwa 2.5 GB Software installiert).
• nicht alle Debian Pakete stellen md5-Summen der installierten Dateien zur Verfügung,
da es (derzeit) nicht der Policy nicht verlangt wird.
Sobald der Schnappschuss erstellt wurde sollten Sie sicherstellen, dass das entsprechende
Medium schreibgeschützt ist. Sie können dann eine Sicherheitskopie erstellen, oder es jede
Nacht benutzen, um die md5-Summen Ihres Systems gegen Ihren Schnappschuss vergleichen.
4.18
Andere Empfehlungen
4.18.1
Benutzen Sie keine Software, die von svgalib abhängt
SVGAlib ist ganz nett für Konsolen-Liebhaber wie mich, aber in der Vergangenheit wurde
mehrfach gezeigt, dass es ziemlich unsicher ist. Exploits durch zgv wurden veröffentlicht, und
es war einfach root zu werden. Versuchen Sie die Nutzung von SVGAlib Programmen wann
immer nur möglich zu verhindern.
66
67
Kapitel 5
Absichern von Servicem die auf Ihrem
System laufen
Services können auf zwei Arten abgesichert werden:
• sie so einstellen, dass auf sie nur von Zugangspunkten (Interfaces) auf sie zugegriffen
werden kann, von denen es nötig ist.
• sie so konfigurieren, dass sie nur von legitimierten Nutzer auf autorisierte Art und Weise
benutzt werden können.
Einschränken der Services, so dass auf Sie nur von bestimmten Orten zugegriffen werden
kann, kann durch Zugriffs-Beschränkungen auf Kernel-Ebene (durch eine Firewall) passieren.
Konfigurieren Sie sie, so dass sie nur auf ein bestimmtes Interface horchen (einige Services bieten diese Fähigkeiten vielleicht nicht) oder durch eine andere Methode, zum Beispiel kann der
Linux vserver Patch (für 2.4.16) dazu benutzt werden, Prozesse auf ein bestimmtes Interface
zu binden.
Was die Services angeht, die von inetd aufgerufen werden (telnet, ftp, finger, pop3. . . ), so ist
es nichts Wert, dass inetd nicht so konfiguriert werden kann, dass er nur auf ein bestimmtes
Interface reagiert. Wie auch immer, sein Ersatz, der xinetd Meta-Daemon kennt ein bind für
diesen zweck. Lesen Sie dazu bitte xinetd.conf(5).
service nntp
{
socket_type
protocol
wait
user
group
server
server_args
=
=
=
=
=
=
=
stream
tcp
no
news
news
/usr/bin/env
POSTING_OK=1 PATH=/usr/sbin/:/usr/bin:/sbin/:/bin
Kapitel 5. Absichern von Servicem die auf Ihrem System laufen
68
+/usr/sbin/snntpd logger -p news.info
bind
= 127.0.0.1
}
Die folgenden Abschnitte gehen detailierter darauf ein, wie bestimmte Services abhängig von
der beabsichtigten Benutzung passend konfiguriert werden.
5.1
Absichern der Secure-Shell (ssh)
Wenn Sie immernoch telnet statt ssh benutzen sollten Sie dieses Handbuch kurz beiseite legen,
und dies ändern. Ssh sollte anstelle von telnet für alle Fern-Logins benutzt werden. In einer
Zeit, in der es leicht ist, Internet-Verkehr mit zu schnüffeln und an klartext Passwörter heranzukommen, sollten Sie lediglich Protokolle verwenden, die Kryptographie benutzen. Also,
führen Sie sofort ein apt-get install ssh auf Ihren System aus.
Ermuntern Sie alle Nutzer Ihres Systems ssh anstelle von telnet zu benutzen, oder noch
bessern: Deinstallieren sie telnet/telnetd. Zusätzlich sollten Sie es vermeiden, sich mit ssh
als root einzuloggen und lieber andere Methoden benutzen, um root zu werden. Wie zum
Beispiel su oder sudo. Schliesslich sollte Sie noch die Datei /etc/ssh/sshd_config für
mehr Sicherheit modifizieren:
• ListenAddress 192.168.0.1
Lassen Sie ssh nur auf ein bestimmtes Interface hören, falls Sie mehrere Netzwerkkarten
haben (und ssh nicht auf allen verfügbar sein soll) oder Sie in Zukunft eine neue Netzwerkkarte einbauen werden (und keine ssh-Verbindungen auf ihr erlauben wollen).
• PermitRootLogin No
Versuchen wo immer möglich keinen Login als Root zu erlauben. Wenn nun jemand
Root werden will, benötigt er zwei logins, und dass Root-Passwort kann nicht so leicht
ausgetestet werden.
• Listen 666
Verändern Sie den Listen-Port, so dass ein Eindringling nicht wirklich sicher sein kann,
ob ein sshd-Daemon läuft (aber beachten Sie, dass dies lediglich “Sicherheit durch Verschleierung” ist).
• PermitEmptyPasswords no
Leer Passwörter verspotten jegliche System-Sicherheit.
• AllowUsers alex ref
Erlauben Sie nur bestimmten Users sich vie ssh auf der Maschine einzuloggen.
• AllowGroups wheel admin
69
Erlauben Sie nur bestimmten Gruppen-Mitgliedern sich via ssh auf der Maschine einzuloggen. AllowGroups und AllowUsers haben entsprechende Direktiven um den Zugang
zu der Maschine zu verwehren. Es wird nicht überraschen, dass es sich hierbei um
“DenyUsers” und “DenyGroups” handelt.
• PasswordAuthentication yes
Es ist Ihre Wahl, was Sie hier eintragen. Es ist sicherer Zugriff nur Nutzern zu erlauben,
die ssh-Schlüssel in der ~/.ssh/authorized_keys haben. Wenn Sie dies wollen, setzen Sie
dies auf “no”.
• Schalten Sie jedwede Art der Authentifizierung ab, die Sie nicht wirklich benötigen, zum Beispiel RhostsRSAAuthentication, HostbasedAuthenticatio,
KerberosAuthentication oder RhostsAuthentication. Sie sollten sie abschalten, auch wenn sie es standardmässig bereits sind (Siehe dazu die Handbuch-Seite
sshd_config(5)).
Abschliessend beachten Sie bitte, dass diese Direktiven von einer OpenSSH KonfigurationsDatei sind. Derzeit gibt es drei weitverbreitete SSH-Daemonen: ssh1, ssh2 und OpenSSH von
den OpenBSD Leuten. Ssh1 war der erste verfügbare ssh-Daemon und er ist noch der weit
verbreiteste (Gerüchten zufolge, gibt es sogar eine Windows-Version). Ssh2 hat gegebüber ssh2
Vorteile, abgesehen davon, dass er unter einen unfreien Lizens veröffentlicht wurde. OpenSSH
ist ein wirklich freier ssh-Daemon, der sowohl ssh1 als auch ssh2 unterstützt. OpenSSH ist die
Version, die installiert wird, wenn Sie auf Debian das Paket ’ssh’ auswählen.
Mehr Informationen wie Sie SSH mit Unterstützung für PAM aufsetzen finden sie hier:
security mailing list archives (http://lists.debian.org/debian-security/2001/
debian-security-200111/msg00395.html).
5.2
Absicher von Squid
Squid ist eine der verbreitesten Proxy/Cache Server, und es gibt ein paar Sicherheitsaspekte, die Sie beachten sollten. Squid’s standard Konfiguration lehnt alle Abfragen von Nutzern
ab.Sie sollten Squid so konfigurieren, dass er Zugriffe von vertrauenswürdigen Nutzern,
Computern oder Netzwerken erlaubt, indem Sie eine Zugriffs-Kontroll-Liste (ACL, Acces
Control List) on /etc/squid.conf. Mehr Informationen, wie Sie ACLs definieren, finden
Sie in der Squid User’s Guide (http://squid-docs.sourceforge.net/latest/html/
book1.htm).
Ebenso kann bei ungeeigneter Konfiguration vorkommen, dass jemand eine Mail über Squid
weiterleitet, da die Protokolle HTTP und SMTP ein ähnliches Design habven. Squid’s standard
Konfiguration verweigert Zugriffe auf Port 25. Wenn Sie Verbindungen an Port 25 erlauben
wollen, fügen Sie ihn einfach in der Safe_ports-Liste hinzu. Aber dies ist NICHT empfohlen.
Passendes Aufsetzen und Konfigurieren des Proxy/Cache-Servers ist nur ein Teil des Absichern Ihrer Seite. Eine andere notwendige Aufgabe ist es, Squid’s Log-Dateien zu analysieren,
um sicher zu gehen, dass alles so arbeitet, wie es sollte. Es gibt ein paar Pakete in Debian
70
GNU/Linux, die einem Administrator hierbei helfen können. Die folgenden Pakete sind in
Woody (Debian 3.0) verfügbar:
• calamaris - Log analyzer for Squid or Oops proxy log files.
• modlogan - A modular logfile analyzer.
• sarg - Squid Analysis Report Generator.
FIXME: Add more information about security on Squid Accelerator Mode
5.3
Absichern von FTP
Wenn Sie wirklich FTP benutzen müssen (ohne Ihn mit sslwrap zu umhüllen oder innerhalb
eines SSL- oder SSH-Tunnels), sollten Sie ftp in das Heimatverzeichnis des FTP-Nutzer chrooten, so dass ein Nutzer nichts anderes sehen kann, als sein Verzeichniss. Anderfalls können
sie Ihr Dateisystem durchlaufen, als hätten Sie Shell-Zugriff. Sie können die folgende Zeile in
Ihre proftpd.conf im globalen Abschnitt hinzufügen, um die chroot-Fähigkeiten zu nutzen:
DefaultRoot ~
Starten Sie proftpd neu, indem Sie /etc/init.d/proftpd restart eingebe, und prüfen
Sie, ob Sie noch aus ihrem Heimatverzeichnis heraus kommen können.
Um Proftp-DoS Attacken durch ../../../ zu verhinden, fügen Sie die folgende Zeile Ihrer /etc
/proftpd.conf hinzu: DenyFilter \*.*/
Vergessen Sie nicht, dass FTP Logind und athentifizierungs Passwort als Klartext sendet
(dies ist kein Problem, wenn Sie einen anonymen, öffentlichen Dienst anbieten) und es gibt
bessere Alternativen in Debian hierzu. Zum Beispiel sftp (aus dem Paket ssh). Es gibt
natürlich auch freue Implentierungen von SSH für andere Betriebssysteme, zum Beispiel putty (http://www.chiark.greenend.org.uk/~sgtatham/putty/) oder cygwin (http:
//www.cygwin.com).
Wenn Sie dennoch einen FTP Server verwalten wollen, während Sie den Nutzern Zugriff via
SSH gewähren, könnten Sie auf ein typisches Problem tressen. Nutzer die innerhalb eines
mit SSH abesicherten Systems auf einen anonymen FTP-Server zugreifen wollen, können versuchen Sich auf dem FTP server einzuloggen. Während der Zugriff verweigert werden wird,
wird das Passwort trotzdem als Klartext über das Netz gesendet. Um dies zu verhindern hat
der ProFTPd Entwickler TJ Saunders einen Patch erstellt, der verhindert, dass Nutzer dem
anonymen FTP-Server mit gültigen SSH-Zugangsdaten schicken. Mehr Informationen und der
Patch sind finden Sie unter; ProFTPD Patches (http://www.castaglia.org/proftpd/
#Patches).
5.4
71
Zugriff auf das X-Window-System absichern
Heutzutage werden X-Terminals bei mehr und mehr Firmen benutzt, so dass ein Server für
viele Arbeitsplätze zuständig ist. Dies kann gefährlich sein, weil Sie dem Datei-Server erlauben
müssen sich mit den X-Clients zu verbinden (X Server aus Sicht von X. X vertauscht die Definition von Client und Server). Wenn Sie dem (sehr schlechten) Vorschlag von vielen Dokumentationen folgen, geben Sie auf Ihrer Maschine xhost + ein. Dies erlaubt jedem X-Client
sich mit Ihrem System zu verbinden. Für etwas bessere Sicherheit, sollten Sie stattdessen das
Kommando xhost +Rechnername verwenden, um den Zugriff auf Bestimmte Rechner zu
begrenzen.
Allerdings ist es eine viel sicherere Lösung, ssh zu benutzen, um X zu tunneln und die gesamte
Sitzung zu verschlüsseln. Dies kann automatisch geschehen, wenn Sie sich auf eine andere
Maschine ssh-en. Sie müssen es nur in der /etc/ssh/ssh_config einschalten, indem Sie
X11Forwarding auf yes setzen. In den zeiten von SSH sollten Sie die xhost-basierte Zugriffskontrolle komplett über Bord werfen.
Zur besten Sicherheit, wenn Sie keinen X-Zugriff von anderen Maschinen benötigen, ist es, die
Bindung auf Port 6000 abzuschalten, indem Sie einfach folgendes eingeben:
$ startx -- -nolisten tcp
Dies ist das Standard-Verhalten unter Xfree 4.1.0 (der Xserver aus Debian 3.0). Wenn Sie
Xfree 3.3.6 laufen lassen (d.h. wenn Sie Debian 2.2 benutzen) können Sie /etc/X11/xinit
/xserverrcc editieren, damit Sie etwas erhalten wie:
#!/bin/sh
exec /usr/bin/X11/X -dpi 100 -nolisten tcp
Wenn Sie XDM benutzen, setzen Sie in /etc/X11/xdm/Xservers auf :0 local
/usr/bin/X11/X vt7 -dpi 100 -nolisten tcp. Wenn Sie Gdm benutzen, stellen Sie
sicher, dass die Option -nolisten tcp in der /etc/gdm/gdm.conf gesetzt ist (was in der
standardmässig unter Debian der Fall sein sollte), wie hier:
[server-Standard]
name=Standard Server
command=/usr/bin/X11/X -nolisten tcp
Sie können ausserdem die standard Zeitgrenze für xscreensaver Sperrungen setzen.
Auch wenn der Nutzern sie aufheben kann, sollten Sie Konfigurationsdatei /etc/X11
/app-defaults/XScreenSaver editieren, und die lock-Zeile von
*lock:
False
(das ist der standardwert unter Debian) auf
*lock:
72
True
ändern.
FIXME: add information on how to disable the screensavers which show the user desktop
(which might have sensitive information).
Lesen Sie mehr zur Sicherheit von X Window in XWindow-User-HOWTO (http:
//www.linuxdoc.org/HOWTO/XWindow-User-HOWTO.html)
(/usr/share/doc
/HOWTO/en-txt/XWindow-User-HOWTO.txt.gz).
FIXME: Add info on thread of debian-security on how to change config files of XFree 3.3.6 to
do this.
5.4.1
Überprüfen Ihres Display-Managers
Wenn Sie einen Display-Manager lediglichen zur lokalen Nutzung (um einen schönen graphischen Login zu haben) haben wollen, gehen Sie sicher, dass der XDMCP (X Display Manager
Control Protocol) Krempel abgeschaltet ist. Unter XDM können Sie dies mit der folgenden
Zeile in /etc/X11/xdm/xdm-config:
DisplayManager.requestPort:
0
Normalerweise sind unter Debian alle Display-Manager so konfiguriert, dass sie standardmässig keine XDMCP-Services starten.
5.5
Absichern des Drucker-Zugriffs (Die lpd und lprng Sache)
Stellen Sie sich vor, Sie kommen zur Arbeit, und der Drucker spuckt entlose Mengen von Papier aus, weil jemand Ihren Drucker-Daemon DoS-et. Unangenehm, oder?
In jeder Unix Druck-Architektur muss es einen Weg geben, um die Daten des Client auf
den Druck-Server zu bekommen. Traditionell machen dies lpr und lp so, dass das ClientKommando die Daten in das Spool-Verzeichnis kopiert oder symlinkt (weshalb diese Programme normalerweise SUID oder SGID sind).
Um jede Gefahr zu vermeiden sollen Sie Ihren Druck-Server besonders sicher halten. Dies
heisst, dass Sie Ihren Druck-Service so konfigurieren müssen, dass er nur Aufträge von vertauenswürdigen Rechnern annimmt. Hierzu müssen Sie die Rechner, von denen Sie Druckaufträge entgegennehmen möchten in die Datei /etc/hosts.lpd ein.
Allerdings akzeptier der lpr-Daemon auch wenn Sie dies getan haben Verbindungen auf
Port 515 auf jeder Schnittstelle. Sie sollten sich überlegen, ob Sie Verbindungen von Netzwerken/Rechner, die nicht drucken dürfen, mittels Firewall abblocken wollen (Der lpr-Daemon
kann nicht so konfiguriert werden, dass er nur auf eine bestimmte IP-Adresse hört.)
73
Sie sollten Lprng gegenüber lpr vorziehen, da er so konfiguriert werden kann, dass er Zugangkontrolle über IP kann. Und Sie können spezifizieren, auf welche Schnittstelle er sich
binden soll (wenn auch etwas sonderbar).
Wenn Sie Ihren Drucker nur Lokal auf ihrem System benutzen, werden Sie ihn nicht über Netzwerk teilen wollen. Sie sollten dann überlegen ein anderes Druck-System, wie zum Beispiel
das aus dem Paket cups oder PDQ (http://pdq.sourceforge.net/), das auf den Zugriffsrechten des Gerätes /dev/lp0 beruht, einzusetzen.
Bei cups werden die Druckaufträge mit dem http-Protokoll zum Server übertragen. Dadurch
muss der Client nicht über spezielle Privilegien verfügen, aber der Server muss auf irgendeinen Port hören.
Wie auch immer: Wenn Sie cups nur Lokal benutzen möchten, können Sie es So konfigurieren,
dass er nur auf die lokale Schleife (loopback interface) hört, indem Sie folgendes in Ihrer /etc
/cups/cupsd.conf ändern:
Listen 127.0.0.1:631
Es gibt noch andere Sicherheits-Optionen in diese Konfigurations-Datei, wie zum Beispiel
das Erlauben oder Verweigern von Netzwerken oder Rechnern. Wenn Sie sie allerdings nicht
benötigen, belassen Sie es am besten dabei, einfach nur den Port, auf den gehört wird,
einzuschränken. Cups liefert auch Dokumentation über den HTTP-Port. Wen Sie diese potentiell nützlichen Informationen einen Angreifer ausserhalb nicht enthüllen wollen (und der
Port offen ist), fügen Sie ausserdem folgendes hinzu:
<Location />
Order Deny,Allow
Deny From All
Allow From 127.0.0.1
</Locationi>
Die Konfigurations-Datei kann auch so angepasset werden, dass zusätzliche Fähigkeiten, einschliessliche SSL- und TLS-Zertifikate oder Verschlüsselung, möglich werden. Die Handbücher finden Sie unter http://localhost:631/ oder http://cups.org.
FIXME: Add more content (the article on Amateur Fortress Building (http://www.
rootprompt.org) provides some very interesting views).
FIXME: Check if PDG is available in Debian, and if so, suggest this as the preferred printing
system.
FIXME: Check if Farmer/Wietse has a replacement for printer daemon and if it’s available in
Debian.
5.6
74
Absichern des Mail-Daemon
Wenn Ihr Server kein Mail-System ist, müssen Sie wirklich keinen Mail-Daemon haben, der
auf eingehende Verbindungen reagiert, aber Sie wollen lokale Mails ausliefern, damit beispielsweise Mails an den Root-User von irgendwelchen Alarm-System erhalten.
Um dies auf einem Debian System zu erreichen, entfernen Sie den smtp-Daemon auf dem
inetd:
$ update-inetd --disable smtp
und konfigurieren Sie den Mailer-Daemon so, dass er nur auf die Lokale Schleife achtet. In
exim (dem standard Mail Transport Agent (MTA) unter Debian) tun Sie dies, indem Sie die in
der Datei /etc/exim.conf die Zeile
local_interfaces = "127.0.0.1"
Hinzufügen.
Starten Sie beide Daemonen neu (inetd und exim) und exim wird lediglich auf den Socket
127.0.0.1:25 reagieren. Seien Sie vorsichtig und deaktivieren Sie erst inetd, oder exim wird nicht
neu starten, da ider inetd bereits eingehende Verbindungen behandelt.
Bei postfix editeren Sie /etc/postfix/main.conf:
inet_interfaces = localhost
Wenn Mails lediglich lokal entgegennehmen wollen ist dieses Herangehen besser als MailerDaemon in einen tcp-Wrapper zu hüllen oder Firewall-Regeln einzufügen, die den Zugang für
alle limitieren sollen. Wenn Sie jedoch auch auf andere Schnittstellen reagieren müssen sollten
Sie überlegen, ihn vom inetd aufrufen zu lassen und einen tcp-Wrapper einzusetzen, so dass
eingehende Verbindungen gegen /etc/hosts.allow und /etc/hosts.deny geprüft werden. Ausserdem werden Sie von unautorisierte Zugriffsversuche gegen Ihren Mail-Daemon
durch angemessenes Protokollieren gewarnt werden wollen.
In jedem Fall können Sie Mail-Relais-Versuche auf SMTP-Level ablehnen, indem Sie die /etc
/exim/exim.conf abändern, damit Sie folgendes enthält:
receiver_verify = true
Auch wenn Ihr Mail-Server keine mails relayen wird ist diese Konfiguration für den Relay-Test
auf http://www.abuse.net/relay.html nötig, um festzustellen, dass Ihr Server nicht
Relais-fähig ist.
5.7
75
sicherer Empfang von Mails
Das lesen und empfangen von Mails ist das gebräuchlichste Klartext-Protokoll. Wenn Sie POP3
oder IMAP benutzen, um Ihre Mails zu erhalten, senden Sie ein Klartext-Passwort über das
gesamte Netz, so dass ziemlich jeder Ihre Mails von nun an lesen kann. Benutzen Sie statt
dessen SSL (Secure Sockets Layer) um Ihre Mails zu empfangen. Wenn Sie einen Shell-Account
auf dem Rechner, der als POP oder IMAP-Server agiert, haben, ist die andere alternative ssh.
Hier ist eine beispielhafte fetchmailrc um dies zu zeigen:
poll mein-imap-mailserver.org via "localhost"
with proto IMAP port 1236
user "ref" there with password "hackmich" is alex here warnings 3600
folders
.Mail/debian
preconnect ’ssh -f -P -C -L 1236:my-imap-mailserver.org:143 -l ref
mein-imap-mailserver.org sleep 15 </dev/null > /dev/null’
Die wichtige Zeile ist die preconnect-Zeile. Sie startet eine ssh-Verbindung und erstellt den
notwendigen Tunnel, duch den automatisch alle Verbindungen zum lokalen Port 1236 verschlüsselt an den IMAP-Mail-Server weitergeleitet werden. Eine andere Möglichkeit wäre es
fetchmail mit SSL-Unterstützung zu benutzen.
Wenn Sie verschlüsselte Mail-Services wie POP oder IMAP anbieten möchten, apt-get
install stunnel und starten Sie Ihren Daemon auf diese Weise:
stunnel -p /etc/ssl/certs/stunnel.pem -d pop3s -l /usr/sbin/popd
Dieses Kommando umhüllt den angegeben Daemon (-l) an den Port (-d) und nutzt ein bestimmtes Zertifikat (-p).
5.8
Sichern von BIND
Es gibt verschiedene Dinge mit denen Sie sich auseinandersetzen sollen, um einen DomainServer-Daemon abzusichern, die ähnlich zu den Überlegungen sind, wie man einen anderen
Service absichert:
• Konfigurieren Sie den Daemon selbst so dass er von aussen nicht missbraucht werden
kann. Dies schliesst das einschränken von Abfragen durch Clients ein: Zonen-Transfers
und rekursive Abfragen.
• Einschränken des Zugriffs auf des Daemon auf den Server selbst, so dass dem Schaden
auf das System im Falle eines Einbruchs Grenzen gesetzt sind. Hierzu gehört auch, den
Daemon als nicht-privilegierten User laufen zu lassen und ihn zu chrooten.
76
Sie sollten einige Informationen, die von aussen abgefragt werden können, zurückhalten, so
dass man nicht wertvolle Informationen über Ihre Organisation, die Sie nicht herausgeben
wollen, abfragen kann. Dies schliesst die folgenden Optionen mit ein: allow-transfer, allowquery, allow-recursive und version. Sie können dies in dem global Abschnitt tun (so wird es
auf alle Zonen angewandt) oder jeweils pro Zone. Dies ist im Paket bind-doc dokumentiert, sobald das Paket installiert ist können Sie hierzu mehr in /usr/share/doc/bind/html
/index.html lesen.
Stellen Sie sich vor, Ihr Server ist mit dem Internet und ihrem internen Neztwerk (Ihre interne IP ist 192.168.1.2) verbunden . Sie möchten keinen Service im Internet anbieten und
DNS-Abfragen lediglich ihren internen Host erlauben. Sie sollten dies einschränken, indem
Sie folgendes in ihre /etc/bind/named.conf aufnehmen:
options {
allow-query { 192.168.1/24; } ;
allow-transfer { none; } ;
allow-recursive { 192.168.1/24; } ;
listen-on { 192.168.1.2; } ;
forward { only; } ;
forwarders { A.B.C.D; } ;
};
Die liste-on Option bewirkt, dass sich DNS nur auf die Schnittstelle bindet, die internen Zugang hat, aber, sogar wenn diese Schnittstelle verbindung zum Internet hat (zum Beispiel weil
Sie NAT benutzen), werden Abfragen nur akzeptiert, wenn Sie von internen Hosts kommen.
Wenn das System mehrere Schnittstellen hat und Sie kein listen-on gesetzt haben, könnten zwar
nur interne Nutzer Abfragen starten, aber, da der Port für Angreifer von aussen ansprechbar ist, könnten Sie versuchen den DNS abzustürzen (oder durch Speicher-Überlauf-Attacken
auszunutzen). Sie könnten ihn sogar dazu bringen, lediglich auf 127.0.0.1 zu hören, wenn Sie
den DN-Service nicht für ein anderes System anbieten wollen.
Der version.bind Eintrag in der chaos class enthält die Version des derzeit laufenden BindProzesses. Diese Information wird oft von automatischen Scannern und bösartigen Individuen
dazu verwendet, heraus zu finden, ob ein Bind für eine bestimmt Atacke verwundbar ist. Indem Sie falsche oder gar keine Informationen im version.bind Eintrag zur Verfügung stellen,
minimieren Sie die Wahrscheinlichkeit, dass jemand Ihren Server aufgrund der publizierten
Version attackieren wird. Um Ihre eigene Version anzugeben, benutzen Sie die version Direktive in der folgenden Art:
options {
... verschiedene andere Optionen ...
version "Nicht verfuegbar.";
};
Das ändern des version.bind Eintrages schützt eigentlich nicht gegen Attacken, aber Sie könntes es als sinnvolle Schutzvorrichtung ansehen.
Eine beispielhafte named.conf Konfigurations-Datei könnte so aussehen:
acl internal {
127.0.0.1/32;
10.0.0.0/8;
aa.bb.cc.dd;
};
// localhost
// intern
// eth0 IP
acl friendly {
ee.ff.gg.hh;
aa.bb.cc.dd;
127.0.0.1/32;
10.0.0.0/8;
};
//
//
//
//
77
slave DNS
eth0 IP
localhost
intern
options {
directory "/var/cache/bind";
allow-query { internal; };
allow-recursive { internal; };
allow-transfer { none; };
};
// Ab hier bis zur meineseite.bogus Zone
// ist alles im Grunde die unveränderte Debian Standard Einstellung
logging {
category lame-servers { null; };
category cname { null; };
};
zone "." {
type hint;
file "/etc/bind/db.root";
};
zone "localhost" {
type master;
file "/etc/bind/db.local";
};
zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};
type master;
};
78
type master;
};
// Zone, die ich selbst hinzugefuegt habe
zone "meineseite.bogus" {
type master;
file "/etc/bind/named.meineseite";
allow-query { any; };
allow-transfer { friendly; };
};
Bitte prüfen Sie (erneut) die Debian Fehler Datenbank bezüglich Bind, insbesondere Bug
#94760 (regarding ACLs on zone transfers) (http://bugs.debian.org/94760). Fühlen Sie
sich ruhig ermutigt zu diesem Bug beizutragen, wenn Sie glauben, Sie können nützliceh Informationen beitragen.
5.8.1
Ändern von BIND User
Bezüglich der beschränkung von BINDs Privilegien müssen Sie beachten, dass wenn Sie BIND
als nicht-root User laufen lassen, BIND neue Netzwerk-Schnittstellen entdecken kann. Zum
Beispiel, wenn Sie eine PCMCIA-Karte in ihr Notebook stecken. Lesen Sie README.Debian in
Ihrer Dokumentation (/usr/share/doc/bind/README.Debian) für mehr Informationen
hierzu. Es gab in letzter Zeit Sicherheits-Probleme mit BIND, so dass es nützlich ist, den User
zu wechseln, wenn es möglich ist. Wie werden die Schritte, die dazu nötig sind, detailiert listen,
wenn Sie dies automatisch machen lassen wollen, probieren Sie das Skript in ‘Beispiel Skript,
um die standard Installation von Bind zu ändern’ auf Seite 153 aus.
Um BIND als ein anderer User laufen zu lassen müssen Sie zunächst einen separaten User und
eine separate Gruppe dafür erstellen (es ist keine gute Idee für alle Services, die sie nicht als root
laufen lasse, den User nobody und die Gruppe nogroup zu benutezn). In diesem Beispiel wird
der User und die Gruppe named benutzt. Sie können diese anlegen, indem Sie die folgenden
Kommandos eingeben:
addgroup named
adduser --system --home /home/named --no-create-home --ingroup named \
--disabled-password --disabled-login named
Beachten Sie, dass der User named sehr eingeschränlt ist. Wenn Sie - aus welchen Gründen
auch immer - ein weniger eingeschränktes Setup haben möchten, benutzen Sie:
adduser --system --ingroup named named
79
Editieren Sie nun /etc/init.d/bind mit Ihrem Lieblings-Editor und änder Sie die Zeile,
die mit
start-stop-daemon --start
anfängt zu:
start-stop-daemon --start --quiet --exec /usr/sbin/named -- -g named -u named
Ausserdem müssen Sie, um zu verhindern, dass irgendetwas als root läuft, die reload-Zeile
auskommentieren:
reload)
/usr/sbin/ndc reload
und in folgendes ändern:
reload)
$0 stop
sleep 1
$0 start
Beachten Sie: Abhängig von Ihrer Debian Version, müssen Sie vielleicht auch die restartZeile ändern. Dies wurde in der Version 1:8.3.1-2 von Debians BIND-Paket repariert.
Alles was Sie jetzt noch tun müssen, ist bind durch ’/etc/init.d/bind restart’ neu zu starten,
und dann Ihr Syslog auf zwei Einträge. wie die folgenden, prüfen:
Sep
Sep
4 15:11:08 nexus named[13439]: group = named
4 15:11:08 nexus named[13439]: user = named
Voilá! Ihr named läft nicht mehr als root. Wenn Sie mehr Informationen darüber lesen wollen,
warum BIND normalerweise nicht als nicht-root User auf Debian Systemen läuft, sehen Sie
bitte in der Fehlerdatenbank zu Bind nach, insbesondere Bug #50013: bind should not run
as root (http://bugs.debian.org/50013) und Bug #132582: Default install is potentially insecure (http://bugs.debian.org/132582), Bug #53550 (http://bugs.debian.
org/53550), Bug #128120 (http://bugs.debian.org/52745), und Bug #128120 (http:
//bugs.debian.org/128129). Fühlen sie sich ruhig dazu ermuntert, etwas zu den Fehlermeldungen beizutragen, wenn Sie denken, Sie können nützliche Informationen beitragen.
5.8.2
80
Chrooten des Name-Server
Um die grösstmögliche BIND Sicherheit zu erreichen, müssen Sie nun ein Chroot-Käfig (siehe
‘Benutzen von chroot’ auf Seite 55) um Ihren Daemon herum bauen. Es gibt da einen sehr einfachen Weg dies zu erreichen: Die -t Option (siehe die Handbuchseite named(8)). Dies wird
Bind selbst in ein bestimmtes Verzeichniss chrooten lassen, ohne dass Sie einen eigenen ChrootKäfig aussetzen müssen, oder sich sorgen um dynamische Bibliotheken machen müssen. Die
einzigen Dateien, die Sie in diesem Chroot-Käfig benötigen, sind:
dev/null
etc/bind/
- sollte die named.conf und alle Server-Zonen enthalten
sbin/named-xfer - wenn Sie Namen transferieren
var/run/named/ - sollte die pid und den Cache des Name-server (falls es
ihn gibt) enthalten. Dieses Verzeichniss muss für
den named-User schreibbar sein.
var/log/named
- Wenn Sie in einer Datei protokollieren, muss dies
für den names User schreibbar sein.
dev/log
- syslogd sollte hierrauf hören, wenn named so
konfiguriert ist, dass er hierrüber protokolliert.
Damit Ihr Bind Daemon vernünftig läuft, braucht er bestimmt Zugriffsrechte auch die
named-Dateien. Dies ist eine einfache Angelegenheit, da die Konfigurations-Dateie immer in
/etc/named/ liegen. Beachten Sie, dass er lediglich lese-Zugriff benötigt, es sei denn, es handelt sich um einen sekundären oder zwischenspeichernden Name-Server. Wenn dies der fall
ist, müssen Sie ihm lese- und schreibzugriff auf die notwendigen Zonen gewähren (so dass
Zonen-Transfers vom primären Server funktionieren).
Mehr Informationen über das Chrooten von Bind finden Sie unter Chroot-BIND-HOWTO
(http://www.linuxdoc.org/HOWTO/Chroot-BIND-HOWTO.html) (betrifft Bind 9) und
Chroot-BIND8-HOWTO (http://www.linuxdoc.org/HOWTO/Chroot-BIND8-HOWTO.
html) (betrifft Bind 8). Diese Dokumente sollten auch nach der Installations des
Paketes doc-linux-text (Text-Version) oder doc-linux-html (HTML-Version) verfügbar sein. Ein anderes nützliches Dokument ist http://www.psionic.com/papers/dns/
dns-linux.
Wenn Sie für Bind 8.2.3 (aus Debian potato) einen kompletten Chroot-Käfig ausetzen (d.h. Sie
benutzen nicht nur -t) , stellen Sie sicher, dass Sie die folgenden Zeilen benutzen:
dev/log - syslogd sollte hierrauf hören
dev/null
etc/bind/named.conf
etc/localtime
etc/group - mit einer einzigen Zeile: "named:x:GID:"
etc/ld.so.cache - mit ldconfig erstellt
lib/ld-2.1.3.so
lib/libc-2.1.3.so
81
lib/ld-linux.so.2 - symbolischer Lin auf ld-2.1.3.so
lib/libc.so.6 - symbolischer Lin auf libc-2.1.3.so
sbin/ldconfig - kann gelöscht werden, nachdem Chroot aufgesetzt wurde
sbin/named-xfer - wenn Sie Namen transferieren
var/run/
Sorgen Sie auch dafür, dass syslogd auf $CHROOT/dev/log achtet, so dass der Name-Server
seine syslog-Einträge in das lokale System Protokoll schreiben lassen kann.
Wenn Sie Probleme mit dynamischen Bibliotheken vermeiden wollen, können Sie Bind statisch
compilieren. Sie können hierzu apt-get mit der source Option benutzen. Es kann sogar die
Pakete herunterladen, die Sie zum Compilieren benötigen. Sie müssten etwas ähnlich wie das
hier tun:
$ apt-get --download-only source bind build-dep bind
$ cd bind-8.2.5-2
(ändern Sie das Makefile.in , so dass CFLAGS die Option ’-static’
beinhaltet befor die @CFLOAGS@ Definition von autoconf verwendet wird)
$ dpkg-buildpackage -rfakeroot
$ cd ..
$ dpkg -i bind-8.2.5-2*deb
Nach der Installation werden Sie die Dateien im chroot-Gefängniss verschieben müssen 1 . Sie
können die init.d Skripte in /etc/init.d lassen, so dass das System automatisch den
Name Server starten wird, aber editieren Sie sie in dem Sie bei den start-stop-daemon
Aufrufen in diesen Skripts --chroot /location_of_chroot hinzufügen.
FIXME, merge info from http://people.debian.org/~pzn/howto/chroot-bind.
sh.txt, http://people.pdxlinux.org/~karlheg/ (Bind9 on Debian), http:
//www.cryptio.net/~ferlatte/config/
(Debian-specific),
http://www.
psionic.com/papers/whitep01.html, http://csrc.nist.gov/fasp/FASPDocs/
NISTSecuringDNS.htm and http://www.acmebw.com/papers/securing.pdf.
5.9
Absichern von Apache
FIXME: Add content.
Sie können den Zugriff auf Ihren Apache Server einschränken, wenn Sie ihn nur intern benutzen wollen (zum Beispiel zu Test Zwecken, oder um auf die doc-central Archive zuzugreifen, etc.) und nicht wollen, dass von aussen auf ihn zugegriffen werden kann. Um dies
zu tun benutzen Sie die Listen oder BindAddress Direktiven in der Datei /etc/apache
/http.conf.
Benutzen von Listen:
1
es sei denn, Sie benutzen die instdir Option, wenn Sie dpkg aufrufen, aber dann wird das chroot-Gefängniss
etwas komplizierter
82
Listen 127.0.0.1:80
Benutzen von BindAddress:
BindAddress 127.0.0.1
Starten Sie anschliessen den Apache mit /etc/init.d/apache restart neu, und Sie werden sehen, dass er nur auf die lokale Schleife achtet.
In jedem Fall solten Sie, wenn Sie nicht die ganze Funktionalität die Apache zur Verfügung
stellt benutzen wollen, mal einen Blick auf die anderen Web-Server aus Debian werfen, zum
Beispiel dhttpd.
Die Apache Documentation (http://httpd.apache.org/docs/misc/security_
tips.html) stellt viele Informationen zu Sicherheitsmassnahmen, die Sie auf einem Apache
Webserver anwenden können, bereit (die gleichen Informationen erhalten Sie unter Debian
auch durch das Paket apache-doc).
5.10
Absichern von finger
Wenn Sie einen Finger-Service laufen lassen wollen, fragen Sie sich bitte zuerst, ob Sie ihn
das auch tun müssen. Wenn Sie müssen, werden Sie feststellen, dass Debian viele FingerDaemonen zur Verfügung stellt (hier die Ausgabe von apt-cache search fingerd):
• cfingerd - Configurable finger daemon
• efingerd - Ein weiterer Unix-finger-Dämon mit anpassbarer Ausgabe
• ffingerd - Ein sicherer finger Daemon
• fingerd - Remote-User Informationsserver
• xfingerd - BSD-ähnlicher finger daemon mit qmail Unterstützung
ffingerd ist der empfohlene finger Daemon, wenn Sie vorhaben, einen öffentlichen Service
anzubieten. In jedem Fall sind Sie dazu angespornt, ihn über inetd, xinetd oder tcpserver
laufend aufzusetzen: Schränken Sie die Anzahl der Prozesse die gleichzeitig laufen dürfen
ein, schränken Sie den Zugriff auf den Finger-Daemon von bestimmten Hosts ein (indem sie
tcp-wrapper benutzen) und lassen Sei ihn nur auf die Schnittstellen achten, auf die er achten
muss.
5.11
83
Allgemeine chroot und suid Paranoia
Wahrscheinlich ist es nur fair zu sagen, dass die Kompexität von BIND der Grund dafür ist,
warum er in den letzten Jahren so oft für Attacken verwundbar war.
Dies trifft auch auf andere Programme mit Komplexen Funktionen und grösserer Nutzergemeinde zu, einschliesslich sendmail und einige ftp-Daemonen (z.B. WUftpd). (Natürlich kann
auch ein Programm ohne viele Funktionen, das seine Nutzer nicht zufriedenstellt, unsicher
sein, abgesehen dass es nutzlos ist.)
In jedem Fall sollten Sie, wenn Sie diese laufen lassen, ähnliche Arragements für Sie in Erwägung ziehen — entziehen von root-Privilegien, einsperren in ein chroot-Gefängniss — oder
ersetzen durch ein sichereres Äquivalent.
5.12
Allgemeine Klartextpasswort Paranoia
Sie sollten versuchen, jeden Netzwerk Service, der seine Passworte als Klartext über das Netz
sendet oder empfängt, wie zum Beispiel FTP/Telnet/NIS/RPC, vermeiden. Der empfiehlt jedem ssh anstelle von telnet und ftp zu verwenden.
Vergessen Sie jedoch nicht, dass die Migration von telnet zu ssh die Sicherheit in keinster Weise
erhöt, wenn Sie weiterhin klartext Protokolle verwenden. Am besten wäre es ftp, telnet, pop,
imap und http zu entfernen und durch Ihre entsprechenden verschlüsselten Services zu ersetzen. Sie sollten in Erwägung ziehen von diesen Services zu Ihren SSL-Versionen zu wechseln:
ftp-ssl, telnet-ssl, pop-ssl, https . . .
Die meisten der oben aufgelisteten Tips gelten für jedes Unixoide-System (Sie werden sie in
jedem anderen Sicherheits-Relevanten Dokument, das sie jemals lesen, wiederfinden, wenn es
sich auf Linux und andere Unices bezieht).
5.13
NIS deaktivieren
Sie sollten, wenn möglich, nicht NIS, den Network Information Service, benutzen, da er das
teilen von Passworten erlaubt. Dies kann sehr unsicher sein, wenn Ihr Setup kaputt geht.
Wenn Sie Passwörter zwischen verschiedenen Maschinen teilen müssen, sollten Sie andere
alternativen in Erwägung ziehen. Zum Beispiel können Sie einen LDAP Server aufsetzen,
und PAM auf Ihren System so konfigurieren, dass es den LDAP Server zur User Authentifizierung kontaktiert. Sie finden ein detailiertes Setup in der LDAP-HOWTO (http:
//www.linuxdoc.org/HOWTO/LDAP-HOWTO.html) (/usr/share/doc/HOWTO/en-txt
/LDAP-HOWTO.txt.gz).
Lesen Sie mehr zu Sicherheit und NIS in der NIS-HOWTO (http://www.linuxdoc.org/
HOWTO/NIS-HOWTO.html) (/usr/share/doc/HOWTO/en-txt/NIS-HOWTO.txt.gz).
FIXME (jfs): Add info on how to setup this in Debian
5.14
84
Abschalten von RPC-Servicen
Sie sollten RPC wannimmer nur möglich abschalten, dass ist dann der Fall, wenn Sie ihn
nicht benötigen. 2 Es sind viele Sicherheits-Löcher sowohl für den Portmapper-Service als
auch für RPC-basierende Services bekannt und könnten sehr leicht ausgenutzt werden. Andererseits können NFS-Service in manchen netzwerken sehr wichtig sein, also versuchen Sie
in Ihrem Netzwerk die Balance zwischen Sicherheit und Nutzbarkeit zu waren. Einige DDoS
(distributed denial of service) Angriffe benutzen rpc-Löcher, um in das System einzudringen und als sogennanter Agent/Handler zu fungieren. Lesen Sie mehr zu Sicherheit in NFS
in NFS-HOWTO (http://www.linuxdoc.org/HOWTO/NFS-HOWTO.html) (/usr/share
/doc/HOWTO/en-txt/NFS-HOWTO.txt.gz).
Das Abschalten von Portmap ist relativ einfach. Es gibt aber verschiedene Methoden. Die einfachste is es auf einem Debian 3.0 System einfach das Paket portmap zu deinstallieren. Wenn
Sie eine eine andere Version laufen haben, werden Sie den Service, wie in ‘Daemon-Services
abschalten’ auf Seite 27 beschrieben, abschalten müssen, dies liegt daran, dass das Programm
Teil des Pakets net-base (das nicht deinstalliert werden kann, ohne das System kaputt zu
machen) sein kann.
Dies entfernt in der Tat jeden symbolischen Link der etwas mit Portmap zu tun hat unterhalb von /etc/rc${runlevel}.d/, was Sie auch manuell erledigen können. Eine andere
Möglichkeit ist chmod 644 /etc/init.d/portmap, das erzeugt aber eine Fehlermeldung
während des Bootens. Sie können auch den start-stop-daemon Teil im /etc/init.d
/portmap Shell-Skript auskommentieren.
5.15
Hinzufügen von Firewall Fähigkeiten
Das Debian GNU/Linux Betriebssystem hat die eingebauten Fähigkeiten des Linux Kernels.
Dies heisst, dass Sie, wenn Sie ein Potato (Debian 2.2) System installiert haben (mit dem default Kernel 2.2) werden Sie ipchains Firewall-Unterstützung im Kernel haben. Sie müssen
dann das Paket ipchains installieren, was (durch seine Priorität) sicherlich bereits der Fall
ist. Wenn Sie ein Woody-System (Debian 3.0) installiert haben (mit dem standard 2.4er Kernel)
unterstützt der Kernel Ihr iptables (neftfilter). Der Hauptunterschied zwischen ipchains
und iptables ist, dass letzeres auf stateful packet inspection (zustandsbehaftete Paket Untersuchung), so dass Ihnen sicherere (und einfacher zu wartende) Filter-Konfigurationen zur Verfügung stehen.
5.15.1
Firewallen des lokalen Systems
Sie können eine Firewall dazu benutzen, den Zugriff auf Ihr lokales System und sogar die
Kommunikation von ihm nach aus absicher. Firewall-Regeln lönnen dazu benutzt werden,
2
Sie werden es wahrscheinlich brauchen, wenn Sie NFS (Network FileSystem) oder NIS (Network Information
System) oder andere RPC-basierende Services benutzen.
85
Prozesse, die nicht vernünftigt konfiguriert werden können, zu schützen, aber nicht um Services für Netzwerke, IP-Adressen, etc. zur Verfügung zu stellen.
Dieser Schritt ist aber hauptsächlich deshalb als letztes in dieser Anleitung, weil es viel besser
ist, sich nicht alleine auf die Fähigkeiten der Firewall zu verlassen, um ein System zu schützen.
Die Sicherheit eines Systems setzt sich auf mehreren Ebenen zusammen; eine Firewall sollte
die letzte sein, wenn alle Services abgehärtet worden sind. Sie können sich sicherleich leicht eine Konfiguration vorstellen, bei der ein System lediglich von einere ingebauten Firewall geschützt, und der Admistrator glückseelige Administrator die Firewall-Regeln aus irgendwelchen Gründen (Probleme mit dem Setup, Verdruss, Denkfehler) entfernt. Dieses System wäre weit geöffnet für Angriffe, wenn es keine andere Schutzmassnahmen auf dem System
gibt.
Andererseits können Firewall-Regeln auf dem lokalem System dafür sorgen, dass böse Dinge
nicht passieren. Sogar wenn die bereitgestellten Services sicher konfiguriert sind, kann eine
Firewall vor Misskonfigurationen oder frisch installierten Services, die noch nicht passend
konfiguriert sind, schützen. Ausserdem wird eine enge Konfiguration nach Hause telefonierende
Trojaner am Funktionieren hindern, es sei denn, der Firewall-Code wurde entfernt. Beachten
Sie, dass ein Eindringling keinen Superuser-Zugriff benötigt, um fernkontrollierbaren Trojaner zu installieren (da das erlaubt ist, sich an Ports zu binden, wenn es sich nicht um einen
privilegierten Port handelt und die Fähigkeiten noch vorhanden sind).
Demzufolge wäre ein passendes Firewall-Setup, eines mit einer default deny policy (also alles
ablehnt, dass nicht ausdrücklich erlaubt ist), und weiterhin:
• eingehende Verbindungen werden nur zu lokalen Servicen von erlaubten Maschinen gestatten
• ausgehende Verbindungen werden nur von Servicen erlaubt, die auf Ihrem System benutzt werden (DNS, Web-Surfen, pop, email, . . . ) 3
• die forward-Regel verbietet alles (es sei denn, Sie beschützen andere System, siehe unten)
• alle anderen eingehenden und ausgehenden Verbindungen werden abgelehnt.
5.15.2
Schützen andere Systeme durch eine Firewall
Eine Debian Firewall kann auch so installiert werden, dass Sie, mit Firewall-Regeln, Systeme
hinter ihr beschützt, indem es die Angriffsfläche zum Internet hin einschränkt. Die Firewall
kann so konfiguriert werden, dass sie verhindert dass System von ausserhalb des lokalen Netzwerks Zugriff auf nicht öffentliche Services (Ports) verhindert. Zum Beispiel muss auf einem
Mail-Server lediglich Port 25 (auf den der Mail-Service aufsetzt) von aussen zugänglich sein.
Eine Firewall kann so konfiguriert werden, dass sogar wenn es öffentlich zugängliche Services
gibt, direkt gesendete Pakete verwirft (dies nennt man filtern).
3
Im Gegensatz zu anderen persönlichen Firewalls für andere Betriebssysteme, stellt Debian GNU/Linux (noch)
nicht eine Firewall-Erstellungs-Schnittstele zur Verfügung, die Regeln erstellen können, die einzelne Prozesse oder
User einschränken. Jedoch kann der iptables-Code so konfiguriert werden, dass er dies kann (siehe dazu das “owner” Modul in der Manualseite iptables(8) manpage)
86
Sie können eine Debian GNU/Linux Maschine sogar so konfigurieren, dass er als BridgeFirewall (überbrückender Schutzwall) fungiert, d.h. eine filternde Firewall, die komplett transparent zum gesamten Netzwerk erscheint, und ohne IP-Adresse auskommt, und daher nicht
direkt attackiert werden kann. Abhängig von dem installierten Kernel müssen Sie vielleicht
den bridge-Firewall Patch installieren, und dann 802.1d Ethernet Bridging in der Kernel Konfiguration und der neuen Option netfilter ( firewalling ) suport auswählen. Sehen Sie dazu ‘Aufsetzen einer Überbrückenden Firewall (bridge Firewall)’ auf Seite 147, um zu erfahren, wie man
dies auf einem Debian GNU/Linux System aufsetzt.
5.15.3
Konfigurieren der Firewall
Natürlich hängt die Konfiguration einer Firewall immer vom System und dem Netzwerk
abhängig. Ein Administrator muss vorher das Netzwerk Layout und die Systeme, die er
beschützen will, kennen, und ob andere netzwerkspezifischen Erwägungen (wie NAT oder
Routing) berücksichtigt werden müssen. Seien vorsichtig, wenn Sie Ihre Firewall konfigurieren. Wie Laurence J. Lane im iptables Paket sagt:
The tools can easily be misused, causing enormous amounts of grief by completely cripple network access
to a computer system. It is not terribly uncommon for a remote system administrator to accidentally lock
himself out of a system hundreds or thousands of miles away. One can even manage to lock himself out
of a computer who’s keyboard is under his fingers. Please, use due caution.
Vergessen Sie nicht: Das einfache installieren von iptables (oder älterem Firewall Coe) gibt
Ihnen keine Sicherehit, es stellt lediglich die Software zur Verfügung. Um eine Firewall zu
haben, müssen Sie sie konfigurieren.
Wenn Sie nicht viel über Firewalls wissen, lesen Sie die Firewalling-HOWTO, die Sie im Paket
doc-linux-text finden (andere Formate gibt es auch). Sehen Sie auch ‘Seien Sie Wachsam
gegenüber generellen Sicherheitsproblemen!’ auf Seite 17 für weitere (allgemeinere) Verweise.
Machen Sie’s auf die Debian Art
Wenn Sie Debian 3.0 benutzen, werden Sie feststellen, dass Sie bereits das Paket iptables
installiert haben. Dies ist die Unterstützung für die Netfilter-Implementation in 2.4.4+ Keneln.
Da das System nach der Installation aber keine Firewall-Regeln kennen kann (Firewall-Regeln
sind zu System spezifisch), müssen Sie die iptables einschalten. Wie auch immer: Die Skripte
wurden so konfiguriert, dass der Administrator Firewall-Regeln aufsetzen kann und die initSkripte Sie dann lernen können und so immer als das Setup der Firewall fungieren.
Hierzu müssen Sie folgendes tun:
• Konfigurieren Sie das Paket so, dass es mit dem System gestartet wird. Bei neueren Versionen (sei 1.2.6a-1) werden Sie während der Installation hiernach gefragt. Sie können es
hinterher wieder mit dpkg-reconfigure -plow iptables ändern. Wichtig: Bei älteren Versionen geschah dies noch durch editieren von /etc/default/iptables, so
dass die Variable enable_iptables_initd auf true gesetzt wird.
87
• Erstellen Sie Ihr ein Firewall-Setup mit iptables, benutzen Sie dazu die Kommandozeile
(siehe iptables(8)) oder ander der Tolls aus Debians Firewall-Paket (siehe ‘Nutzen
von Firewall-Paketen’ auf dieser Seite). Sie müssen einen Satz von Firewall-Regeln erstellen die benutzt werden sollen, wenn die Firewall aktiv ist und einen anderen, wenn
die Firewall inaktiv (dies können auch nur leere Regeln sein) ist.
• Sicher Sie die erstellten Regeln mit den Skripts /etc/init.d/iptables
save_active und /etc/init.d/iptables save_inactive.
Sobald dies geschehen ist, ist Ihr Firewall-Setup im Verezichnis /var/lib/iptables/ gespeichert und wird beim System-Boot ausgeführt (oder wenn das initd Skript mit start und stop
gestartet wird). Beachten Sie, dass standard Einstellung unter Debian vorsehen, den FirewallCode in den Multiuser Runleveln (2 bis 5) sehr früh (10) zu starten. Ausserdem wird er im
singleuser Runlevel (1) gestoppt. Ändern Sie dies, wenn es nicht Ihren lokalen Richtlinien
entspricht.
Wenn Sie keine Ahnung haben, wie Sie Ihre Firewall-Rules manuell aufsetzen sollen, sehen Sie in der Packet Filtering HOWTO und NAT HOWTO aus dem Paket iptables, zu
browsen unter /usr/share/doc/iptables/html/. Zudem stellt die Konfigurationsdatei
/etc/default/iptables noch weitere Informationen zu diesem Paket zur Verfügung.
Nutzen von Firewall-Paketen
Das manuelle Aufsetzen einer Firewall kann für neue (und manchmal auch für erfahrene) Administratoren kompliziert sein. Hierfür hat die Freie-Software Gemeinschaft eine grosse Zahl
von Tools erstellt, die zur einfachen Konfiguration einer Lokalen Firewall benutzt werden können. Seien Sie vorgewarnt, dass einige Dieser Tools sich mehr auf lokalen Schutz konzentrieren
(auch personal firewall genannt), während andere vielseitiger, und lönnen dazu benutzt werden,
komplexere Regelwerke zum Schutz ganzer Netzwerke zu erstellen.
Einige Programme, die unter Debian zum aufsetzen von Firewall-Regeln benutzt werden können, sind:
• firestarter
• knetfilter
• fwbuilder
• shorewall
• mason, das basierend auf dem Netzwerk-Verkehr, denn Ihr System “sieht”, FirewallRegeln vorschlagen kann
• bastille (among the hardening steps that can make new versions of bastille is the
possibility of adding firewall rules to the system to be executed on startup)
• ferm
88
• fwctl
• easyfw
• firewall-easy
• ipac-ng
• gfcc
• lokkit oder gnome-lokkit
Die Pakete gfcc,firestarter und knetfilter sind graphische Administrations-Schnittstellen die
entweder GNOME (die ersten beiden) oder KDE (das letzte) benutzen, die eher Nutzer orientiert sind (z.B. für Heimanwender) als die andere Pakete in der Liste, die sich eher an Administratioren richten.
Seien Sie vorgewarnt, dass manche der zuvor skizzierten Pakete eigene Firewall-Skripte einführen, die beim System-Start ausgeführt werden sollen, die zweifelsohne mit dem allgemeinen Setup (wenn es erfolgte) mit unerwünschten Nebeneffekten kollidieren wird. Das
Firewall-Skript, das zuletzt ausgeführt wird, wird das das System konfigueren (was Sie so
vielleicht nicht vorhatten). Sehen Sie hierzu in der Paket-Dokumentation nach und benutzen
Sie nur eines dieser Setups. Allgemeiner: Andere Programme, die helfen die Firewall-Regeln
aufzusetzen, können anderen Konfigurations-Dateien beissen.
FIXME: Add more info regarding this packages
FIXME: Check Information on Debian firewalling and what/how does it change from other
distributions.
FIXME: Where should the custom firewalling code be enabled (common FAQ in debianfirewall?)
89
Kapitel 6
Automatishen Abhärten eines Debian
Systems
Nachdem Sie nun all die Informationen aus den vorherigen Kapiteln gelesen haben, fragen
Sie sich vielleicht: “Ich habe sehr Ding zu erledigen um mein System abzusichen; könnte man
das nicht automatisieren?” Die Antwort ist: “Ja, aber seien Sie vorsichtig mit automatischen
Tools.” Manche Leute denken, dass ein Absicherungstool nicht die Notwendigkeit für gute
Systemadministration abschafft. Legen Sie sich also nicht selbst herein, indem Sie denken, dass
Sie all die Prozesse automatisieren könnten, und sich alle betreffenden Angelegenheiten von
selbst erledigen würden. Sicherheit ist ein andauernder Prozess, an dem der Administrator
teilnehmem muss und nicht wegbleiben kann, damit irgendwelche Tools die Arbeit erledigen,
weil kein einzelnes Tool mit den möglichen regelkonformen Sicherheits-Implementierungen,
all den Attacken und all den Umgebungen bewältigen kann.
Seit Woody (Debian 3.0) gibt es zwei unterschiedliche Pakete, die nützlich für die Erhöhung
der Sicherheit sind. Das Paket harden versucht auf Basis der Paket-Abhängigkeiten schnell
wertvolle Sicherheits-Pakete zu installieren und Pakete mit Mängeln zu entfernen. Die Konfiguration der Pakete muss der Administrator erledigen. Das Paket bastille implementiert
gegebene Sicherheits-Regeln für das lokale System bassierend auf einer vorhergehenden Konfiguration durch den Administrator (Sie können auch mit einfache Ja/Nein Fragen durch die
Konfiguration geführt werden).
6.1
Harden
Das Paket harden versucht es einfacher zu machen Rechner, die gute Sicherehit benötigen,
zu installieren und zu administrieren. Dieses Paket sollte von Leuten benutzt werden, die
eine schnelle Hilfe zur Erhöhing System-Sicherheit haben wollen. Hierzu entfernt es Pakete
mit bekannten Mängeln, einschliesslich (aber nicht beschränkt auf); Pakete mit bekannten
Sicherheits-Fehlern (zum Beispiel Speicher-Überläufe), Pakete die Klartext-Passwörter verwenden, fehlende Zuganskontrolle, usw. Es installiert ausserdem automatisch einige Tools,
die die Sicherheit auf unterschiedliche Art und Weise erhöhen: Werkzeuge zur Eindrin-
Kapitel 6. Automatishen Abhärten eines Debian Systems
90
glingserkennung, Tools zur Sicherheits-Analyse, und mehr. harden installiert die folgenden
virtuellen Pakete (d.H. sie enthalten nichts, hängen aber von anderen Paketen ab).
• harden-tools: Tools, die die System-Sicherheit erhöhen (Integritäts-Überprüfer, Eindringlingserkennung, Kernel-Patches. . . )
• harden-doc: Stellt diese und andere Sicherheits-relevanten Dokumente zur Verfügung
• harden-environment: Hilft eine abgesicherte Umgebung zu konfigurieren (derzeit
leer)
• harden-servers: entfernt Server, die aus irgendeinem Grund als unsicher gelten
• harden-clients: entfernt Clients, die aus irgendeinem Grund als unsicher gelten
• harden-remoteflaws: Entfernt Pakete mit bekannten Sicherheits-Lücken, die von
einem entfernten Angreifer genutzt werden können, um das System zu komprimitieren
(benutzt versionierte Conflicts:)
• harden-localflaws: Entfernt Pakete mit bekannten Sicherheits-Lücken, die von
einem lokalen Angreifer genutzt werden können, um das System zu komprimitieren (benutzt versionierte Conflicts:)
• harden-remoteaudit: Tools um Systeme aus der ferne zu überprüfen
Seien Sie wachsam, wenn Sie Software installiert haben, die Sie brauchen (und aus bestimmten
Gründen nicht deinstalliert haben wollen) und Sie Aufgrund des Conflicts nicht mit einem der
oben aufgeführten Pakete installiert werden kann. In diesem Fall können Sie harden nicht
vollständig nutzen.
Die harden Pakete machen eigentlich gar nichts. Zumindest nicht direkt. Sie haben jedoch
absichtliche Paket-Konflikte mit bekannten, unsicheren Paketen. Auf diese Art wird die PaketVerwaltung von Debian die Installation von diesen Paketen nicht erlauben. Wenn Sie zum
Beispiel bei installiertem harden-servers versuchen, mit apt einen telnet-Daemon zu installieren, werden Sie folgendes sehen:
# apt-get install telnetd
The following packages will be REMOVED:
harden-servers
The following NEW packages will be installed:
telnetd
Do you want to continue (Y/n)
Dies sollte im Kopf des Administrators eine Alarmsirene auslösen, so dass er seine Aktion
überdenken kann.
6.2
91
Bastille Linux
Bastille Linux (http://www.bastille-linux.org) ist ein automatisches Abhärtungs
Tools, das ursprünglich für die RedHat und Mandrake Linux Distributionen gedacht war. Wie
auch immer: Das Paket bastille aus Debian (seit Woody) ist angepasst, um dieselbe Funktionalität unter Debian GNU/Linux Systemen zur Verfügung zu stellen.
Bastille kann mit verschiedenen Oberflächen bedient werden (Alle sind in ihrer eigenen
Handbuch-Seite dokumentiert), die dem Administrator erlauben:
• Schritt für Schritt Fragen zur erwünschten Sicherheit Ihres Systems beantworten (siehe
InteractiveBastille(8))
• standard Einstellungen zur Sicherheit (zwischen Lau, moderat und paranoid) in
einem bestimmten Setup (Server oder Arbeitsplatzrechner) zu benutzen, und Bastille
entscheiden zu lassen, welche Sicherheits-Regelungen eingeführt werden sollen (siehe
BastilleChooser(8))
• eine vorgefertigte Konfigurations Datei (von Bastille oder von einem Administator
geliefert) zu nehmen und eine vorgegeben Sicherheits-Regelung zu benutzen (siehe
AutomatedBastille(8))
92
93
Kapitel 7
Paket signierung unter Debian
Dieses Kapitel könnte auch mit “Wie man sein Debian GNU/Linux System sicher upgraded/updated” überschrieben werden, und es verdient hauptsächlich deshalb ein eigenes Kapitel, weil es in kein anderes passt.
Derzeit (Stand Dezember 2001) stellt Debian keine signierten Pakete für die Distribution zur
Verfügung und der Woody Release (3.0) wird diese Fähigkeiten nicht integrieren. Es gibt eine
Lösung für signierte Pakete, die - hoffentlich - in der nächsten release (sarge) integriert wird.
7.1
Der vorgeschlagene Plan zur Prüfung von Paket Signierungen
Der derzeitige (unimplementierte) Plan zur Prüfung von Paket Signaturen mit apt ist:
• Die Release-Datei enthält die md5-Summe von Packages.gz (die die md5-Sumemn der
Pakete enthält) und wird signiert. Die Signatur stammt aus einer vertrauenswürdigen
Quelle.
• Diese signierte Release-Datei wird beim “apt-get update” herunter geladen und auf der
Festplatte mit Packages.gz gespeichert.
• Wenn ein Paket installiert werden soll, wird es zuerst herunter geladen, und dann wird
die md5-Summe erstellt.
• Die signierte Release-Datei wird überprüft (ob die Signature okay ist) und doe md5Sumem der Packages.gz Datei extraiert. Die md5-Summe der Pakcages.gz-Datei wird
erstellt und geprüft, und - wenn Sie übereinstimmt - wird die md5-Summe des herunter
geladenen Paketes aus ihr extraiert.#
• Wenn die md5-Summe des heruntergeladenen Paketes die gleiche ist, wie in der
Packages.gz-Datei, wird das Paket installiert, andernfalls wird der Administrator
alarmiert, und das Paket wird im Zwischenspeicher gehalten (so dass der Administrator entscheiden kann, ob es installiert werden soll, oder nicht). Wenn das Paket nicht in
Kapitel 7. Paket signierung unter Debian
94
Packages.gz enthalten ist und der Administrator das System so konfiguriert hat, dass nur
geprüfte Pakete installiert werden können, wird das Paket ebenfalls nicht installiert.
Durch diese Kette von md5-Summen ist apt in der Lage, zu verifizieren, dass ein Paket aus
einer bestimmten Release stammt. Dies ist zwar unflexibler als jedes Paket einzeln zu signieren,
kann aber auch mit den unten aufgeführten Plänen kombiniert werden.
Die Signierung von Paketen wurde innerhalb des Debian Projektes ausführlich diskutiert.
Mehr Informationen hierzu finden Sie unter http://www.debian.org/News/weekly/
2001/8/ und http://www.debian.org/News/weekly/2000/11/.
7.2
Alternative Einzel-Paket-Signierungs Schemata
Dieses zusätzliche Schemata jedes paket einzeln zu signieren erlaubt es, Pakete zu prüfen,
selbst wenn sie nicht mehr in irgendeiner Packages-Datei erwähnt werden, und auch Pakete
von Dritten, für die es keine Packages-Datei gibt, können unter Debian installiert werden.
Dieses Paket-Signierungs Schemata kann durch debsig-verify und debsigs implementiert werden. Diese beiden Pakete können in der .deb-Datei selbst eingebettete Signaturen erstellen und prüfen. Debian hat bereits jetzt die Möglichkeiten dies zu tun, aber das Regelwerk
und die Werkzeuge hierfür werden erst nach dem Woody Release eingeführt (um den ReleaseZyklus nicht zu verlangsamen).
Beachten Sie: Derzeit wird enthält /etc/dpkg/dpkg.cfg derzeit standardmässig die Option
“no-debsig”.
7.3
Prüfen veröffentlichter Pakaete
Für den Fall, dass Sie nun zusätzliche Sicherheits Prüfungen einführen wollen, können Sie das
folgende Skript von Anthony Towns benutzen. Dieses Skript kann automatisch neue Sicherheits Checks durchführen, damit ein Nutzer sicher gehen kann, dass die Software, die er/sie
herunterlädt, die gleiche ist, wie die, die von Debian bereitgestellt wird. This stops Debian
developers from hacking into someone’s system without the accountability provided by uploading to the main archive, or mirrors mirroring something almost, but not quite like Debian,
or mirrors providing out of date copies of unstable with known security problems.
Dieser Beispiel-Code, umbenannt nach apt-release-check, sollte auf die folgende Art benutzt werden: used in the following way:
# apt-get update
# apt-release-check
(... Ergebnisse ...)
# apt-get dist-upgrade
Zuerst müssen Sie jedoch:
95
• Holen Sie sich den Schlüssel, den die Archiv-Software verwendet, um Release-Dateien zu
signieren, http://ftp-master.debian.org/ziyi_key_2002.asc und fügen Sie
ihn ~/.gnupg/trustedkeys.gpg hinzu (was standardmässig von von gpgv benutzt
wird)
• Entfernen Sie alle Zeilen aus /etc/apt/sources.list, die nicht die “dists”-Struktur
benutezn, oder ändern Sie das Skript, so dass es mit denen auch funktioniert
• Ignorieren Sie die Tatsache, dass Sicherheits-Updates von Debian keine signierten
Release-Dateien haben, und das Sources-Dateien (noch) keine richtigen Prüfsummen in
der Release-Datei anbieten.
• Bereiten Sie sich darauf vor, zu prüfen, dass die richtigen sources durch den richtigen
Schlüssel signiert wurden.
#!/bin/bash
# This script is copyright (c) 2001, Anthony Towns
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
rm -rf /tmp/apt-release-check
mkdir /tmp/apt-release-check || exit 1
cd /tmp/apt-release-check
>OK
>MISSING
>NOCHECK
>BAD
arch=‘dpkg --print-installation-architecture‘
am_root () {
[ ‘id -u‘ -eq 0 ]
}
get_md5sumsize () {
cat "$1" | awk ’/^MD5Sum:/,/^SHA1:/’ |
MYARG="$2" perl -ne ’@f = split /\s+/; if ($f[3] eq $ENV{"MYARG"}) {
}
96
checkit () {
local FILE="$1"
local LOOKUP="$2"
Y="‘get_md5sumsize Release "$LOOKUP"‘"
Y="‘echo "$Y" | sed ’s/^ *//;s/ */ /g’‘"
if [ ! -e "/var/lib/apt/lists/$FILE" ]; then
if [ "$Y" = "" ]; then
# No file, but not needed anyway
echo "OK"
return
fi
echo "$FILE" >>MISSING
echo "MISSING $Y"
return
fi
if [ "$Y" = "" ]; then
echo "$FILE" >>NOCHECK
echo "NOCHECK"
return
fi
X="‘md5sum < /var/lib/apt/lists/$FILE‘ ‘wc -c < /var/lib/apt/lists/$FI
X="‘echo "$X" | sed ’s/^ *//;s/ */ /g’‘"
if [ "$X" != "$Y" ]; then
echo "$FILE" >>BAD
echo "BAD"
return
fi
echo "$FILE" >>OK
echo "OK"
}
echo
echo "Checking sources in /etc/apt/sources.list:"
echo "~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~"
echo
(echo "You should take care to ensure that the distributions you’re downloadin
echo "are the ones you think you are downloading, and that they are as up to"
echo "date as you would expect (testing and unstable should be no more than"
echo "two or three days out of date, stable-updates no more than a few weeks"
echo "or a month)."
) | fmt
echo
cat /etc/apt/sources.list |
97
sed ’s/^ *//’ | grep ’^[^#]’ |
while read ty url dist comps; do
if [ "${url%%:*}" = "http" -o "${url%%:*}" = "ftp" ]; then
baseurl="${url#*://}"
else
continue
fi
echo "Source: ${ty} ${url} ${dist} ${comps}"
rm -f Release Release.gpg
wget -q -O Release "${url}/dists/${dist}/Release"
if ! grep -q ’^’ Release; then
echo " * NO TOP-LEVEL Release FILE"
else
origline=‘sed -n ’s/Ôrigin: *//p’ Release | head -1‘
lablline=‘sed -n ’s/^Label: *//p’ Release | head -1‘
suitline=‘sed -n ’s/^Suite: *//p’ Release | head -1‘
codeline=‘sed -n ’s/^Codename: *//p’ Release | head -1‘
dateline=‘grep "^Date:" Release | head -1‘
dscrline=‘grep "^Description:" Release | head -1‘
echo " o Origin: $origline/$lablline"
echo " o Suite: $suitline/$codeline"
echo " o $dateline"
echo " o $dscrline"
if [ "${dist%%/*}" != "$suitline" -a "${dist%%/*}" != "$codeli
echo " * WARNING: asked for $dist, got $suitline/$cod
fi
wget -q -O Release.gpg "${url}/dists/${dist}/Release.gpg"
sigline="‘gpgv --status-fd 3 Release.gpg Release 3>&1 >/dev/nu
if [ "$sigline" ]; then
echo " o Signed by: $sigline"
else
echo " * NO VALID SIGNATURE"
>Release
fi
fi
okaycomps=""
for comp in $comps; do
if [ "$ty" = "deb" ]; then
X=$(checkit "‘echo "${baseurl}/dists/${dist}/${comp}/b
Y=$(checkit "‘echo "${baseurl}/dists/${dist}/${comp}/b
if [ "$X $Y" = "OK OK" ]; then
okaycomps="$okaycomps $comp"
98
else
echo "
* PROBLEMS WITH $comp ($X, $Y)"
fi
elif [ "$ty" = "deb-src" ]; then
X=$(checkit "‘echo "${baseurl}/dists/${dist}/${comp}/s
Y=$(checkit "‘echo "${baseurl}/dists/${dist}/${comp}/s
if [ "$X $Y" = "OK OK" ]; then
okaycomps="$okaycomps $comp"
else
echo " * PROBLEMS WITH component $comp ($X, $
fi
fi
done
[ "$okaycomps" = "" ] || echo "
echo
o Okay:$okaycomps"
done
echo "Results"
echo "~~~~~~~"
echo
allokay=true
diff <(cat BAD MISSING NOCHECK OK | sort) <(cd /var/lib/apt/lists && find . -t
if grep -q ^ UNVALIDATED; then
allokay=false
(echo "The following files in /var/lib/apt/lists have not been validated."
echo "This could turn out to be a harmless indication that this script"
echo "is buggy or out of date, or it could let trojaned packages get onto"
echo "your system."
) | fmt
echo
sed ’s/^/
/’ < UNVALIDATED
echo
fi
if grep -q ^ BAD; then
allokay=false
(echo "The contents of the following files in /var/lib/apt/lists does not"
echo "match what was expected. This may mean these sources are out of date
echo "that the archive is having problems, or that someone is actively"
echo "using your mirror to distribute trojans."
if am_root; then
99
echo "The files have been renamed to have the extension .FAILED and"
echo "will be ignored by apt."
cat BAD | while read a; do
mv /var/lib/apt/lists/$a /var/lib/apt/lists/${a}.FAILED
done
fi) | fmt
echo
sed ’s/^/
/’ < BAD
echo
fi
if grep -q ^ MISSING; then
allokay=false
(echo "The following files from /var/lib/apt/lists were missing. This"
echo "may cause you to miss out on updates to some vulnerable packages."
) | fmt
echo
sed ’s/^/
/’ < MISSING
echo
fi
if grep -q ^ NOCHECK; then
allokay=false
(echo "The contents of the following files in /var/lib/apt/lists could not
echo "be validated due to the lack of a signed Release file, or the lack"
echo "of an appropriate entry in a signed Release file. This probably"
echo "means that the maintainers of these sources are slack, but may mean"
echo "these sources are being actively used to distribute trojans."
if am_root; then
echo "The files have been renamed to have the extension .FAILED and"
echo "will be ignored by apt."
cat NOCHECK | while read a; do
mv /var/lib/apt/lists/$a /var/lib/apt/lists/${a}.FAILED
done
fi) | fmt
echo
sed ’s/^/
/’ < NOCHECK
echo
fi
if $allokay; then
echo ’Everything seems okay!’
echo
fi
rm -rf /tmp/apt-release-check
100
101
Kapitel 8
Sicherheits Tools in Debian
FIXME: More content needed.
Debian stellt ausserdem einige Sicherheits Tools zur Verfügung, die eine Debian Maschine
passend zu Test-Zwecken erweitern. Manche von Ihnen werden zur Verfügung gestellt, wenn
Sie das Paket harden-remoteaudit installieren.
8.1
Tools zur Fern-Prüfung der Verwundbarkeit
Die Werkzeuge um Fern-Prüfungen der Verwundbarkeit durchzuführen unter Debian sind:
• nessus
• raccess
• whisker
• nikto (whisker Ersatz)
• bass (non-free)
• satan (non-free)
Das weitaus vollständigste und aktuellste Tool ist nessus, welcehs aus einem Client
(nessus), als graphische Benutzungsschnittstelle, und einem Server (nessusd), der die programmierten Attacken startet, besteht. Nessus kennt verschiedene Fern-Verwundbarkeiten für
einige Systeme, einschliesslich Netzwerk Geräten, FTP-Servern, WWW-Server, usw. Die letzte
Releases sind sogar in der Lage, eine Web-Seite zu analysieren und zu versuchen, interaktive
Inhalte, die zu einem Angriff genutzt werden können, zu entdecken. Es gibt auch Java und
Win32 Clients (die nicht in Debian enthalten sind), die benutzt werden können, den Server zu
kontrollieren.
Kapitel 8. Sicherheits Tools in Debian
102
Whisker ist ein Web-Basierender Gefährungs-Abschätzungs Scanner, der auch einige antiIDS Taktiken kennt (die meisten davon sind keine Anti-IDS Taktiken mehr). Es ist einer der
besten cgi-Scanner verfügbar, der WWW-Server erkennen und nur bestimmte Angriffe gegen
Ihn starten kann. Die Datenbank die zum scannen benutzt wird, kann sehr leicht geändert
werden, um neue Informationen einzufügen.
Bass (Bulk Auditing Security Scanner) und Satan (Security Auditing Tool for Analysing Networks) müssen eher als “Beweis des Konzeptes” Programme gesehen werden, statt als Tools,
die Sie während einer Prüfung nutzen sollten. Beide sind eher veraltet und werden nicht
auf dem aktuellen Stand gehalten. Wie auch immer: SATAN war das erste Tool, dass eine
Gefahrenabschätzung auf eine einfache Art (GUI) zur Verfügung stellte, und Bass ist immer
noch ein hoch performantes Prüf-Werkzeug.
8.2
Netzwerk-Scan Tools
Debian bietet Ihnen einige Tools zum scannen von Hosts (aber nicht zur Gefahrenabschätzung). Diese Tools sind werden in manchen Fällen von Gefahrenabschätzungs-Scanner
zu einem ersten “Angriff” gegen entfernte Rechner genutzt, um festzustellen, welche Services
angeboten werden. Debian bietet derzeit:
• nmap
• xprobe
• queso
• knocker
• hping2
• isic
• icmpush
• nbtscan
Während queso und xprobe lediglich aus der Ferne das Betriebssystem erkennen können
(indem Sie TCP/IP Fingerabdrücke benutzen), machen nmap und knocker beides: Das Betriebssystem erkennen und die Ports eines entfernt stehenden Rechners scannen. Andererseits
können hping2 und icmpush für ICMP Angriffs Techniken benutzt werden.
Speziell für Netbios Netzwerke entworfen kann nbtscan benutzt werden, um IP-Netzwerke
zu scannen und diverse Informationen von SMB Servern zu ermitteln, einschliesslich: Usernamen, Netzwerknamen, MAC-Adressen. . .
8.3
103
Interne Prüfungen
Derzeit kann man lediglich das tiger Tool benutzt werden, um interne Prüfungen (auch
“white box” genannt) eines Rechners vorzunehmen, um festzustellen, ob das Dateisystem
richtig aufgesetzt ist, welche Prozesse auf dem Rechner horchen, usw.
8.4
Testen von Quellcode
Debian bietet zwei Pakete, die C/C++ Quellcode prüfen und Programmierfehler, die zu
möglichen Sicherheits-Mängeln führen können, findet:
• flawfinder
• rats
8.5
Virtual Private Networks (virtuelle, private Netzwerke)
FIXME: Content needed
Debian bietet einige Pakete, die zum aufsetzen von verschlüsselten, virtuellen, privaten Netzwerken benutzt werden können:
• vtun
• tunnelv
• cipe
• vpnd
• tinc
• secvpn
• pptp
• freeswan
Das FreeSWAN Paket ist wahrscheinlich die beste Wahl, da es mit so ziemlich allen zusammenarbeiten kann, dass das IP security protocol (IPsec RFC 2411) benutzt, aber die anderen Pakete
können Ihnen helfen, auf die Schnelle einen Tunnel aufzusetzen. PPTP iste in Microsoft Protokoll für VPN. Es wird unter Linux unterstützt, aber es einige schwere Sicherheits Probleme
sind bekannt.
Für mehr Informationen lesen Sie VPN-Masquerade HOWTO (http://www.linuxdoc.
org/HOWTO/VPN-Masquerade-HOWTO.html) (über IPsec und PPTP) VPN HOWTO
104
(http://www.linuxdoc.org/HOWTO/VPN-HOWTO.html) (über PPP über SSH), und Cipe
mini-HOWTO (http://www.linuxdoc.org/HOWTO/mini/Cipe+Masq.html), PPP and
SSH mini-HOWTO (http://www.linuxdoc.org/HOWTO/mini/ppp-ssh/index.html).
8.6
Öffentliche Schlüssel Infrastrukturen (Public Key Infraestructure (PKI))
Wenn Sie über eine PKI nachdenken, sehen Sie sich mit einer breiten Pallete von Tools konfrontiert:
• Eine Zertifikat Autorität (CA), die Zertifikate ausgeben und unter einer bestimmten Hierarchie arbeiten kann
• Ein Verzeichnis. dass die öffentlichen Zertifikate enthält
• Eine Datenbank, um die Zertifikat Widerrufe zu verwalten
• Geräte, die mit der CA zusammenarbeiten, um smarcards/usb Token/wasauchimmer
zu erzeugen, um Zertifikate sicher zu speichern
• Applikationen, die von einer CA ausgegeben Zertifikate benutzen können, um verschlüsselte Kommikation zu etablieren, und bestimmte Zertifikate gegen Widerruflisten prüfen
können (zur authentifikation und full Single Sign On solutions)
• Eine Zeitstempel Autorität, um Dokumente digital zu signieren
• Eine Verwaltungs-Konsole, von der aus dies alles vernünftig benutzt werden kann (Erstellung von Zertifikaten, Kontrollieren von Widerruflisten, usw. . . )
Sie können einige Software aus Debian GNU/Linux hierfür benutzen, einschliesslich openSSL
(zur Zertifikat Erstellung), OpenLDAP (für ein Verzeichnis um die Zertifikate zu speichern), gnupg und freeswan (mit X.509 Unterstützung). Jedoch stellt dieses Betriebssystem (zur
Woody Release 3.0) keine der frei verfügbaren Certificate Authorities wie zum Beispiel pyCA
OpenCA (http://www.openca.org) oder die CA Beispiele von OpenSSL zur Verfügung.
Für mehr Informationen lesen Sie Open PKI book (http://ospkibook.sourceforge.
net/).
8.7
SSL Infrastruktur
Debian stellt einige SSL-Zertifikate innerhalb der Distribution zur Verfügung, so dass Sie sie
lokal installieren können. SSL Zertifikate werden in ca-certificates weiter verteilt. Diese
Paket stellt eine zentrale Sammelstelle für Zertifikate dar, die an Debian übermittelt und vom
Paket Verwalter gebilligt (das heisst, verifiziert) wurden.
FIXME: read debian-devel to see if there was something added to this.
8.8
105
Anti-Viren Tools
Es gibt nicht sehr viele Anti-Viren Tools in Debian, wahrscheinlich weil GNU/Linux User
zur Zeit nicht so sehr von Viren belästigt werden. Es gab dennoch Würmer und Viren für
GNU/Linux, auch wenn es (bisher) keinen Virus gab, der sich im freien weit über irgendeine
Debian Distribution verbreitet hat. In jedem Fall möchten Administratoren vielleich Anti-Viren
Gateways aufbauen, oder sich selbst gegen Viren schützen.
Debian bietet derzeit die folgenden Tools zum erstellen von Anti-Viren Umgebungen:
• sanitizer (http://packages.debian.org/sanitizer), ein Tool, das dazu benutzt
werden Emails von Procmail zu filtern und Viren zu entfernen
• amavis-postfix (http://packages.debian.org/amavis-postfix), ein Skript, das
eine Schnittstelle vom Mail-Transport-Agent zu einem oder mehreren Viren-Scannern
anbieten (dieses Paket enthält die Postfix Version).
Wie Sie sehen enthält Debian selbst derzeit keine Anti-Viren Software. Es gibt jedoch
freie Anti-Viren Projekte, die (in der Zukunft) in Debian einfliessen könnten: openantivirus (http://sourceforge.net/projects/openantivirus/) und jvirus (http://
sourceforge.net/projects/jvirus/) (dies ist weniger Wahrscheinlich, da es komplett auf Java basiert) Ausserdem wird Debian nie kommerzielle Anti-Viren Software enthalten, wie die folgende: Panda Antivirus (http://www.pandasoftware.com/
com/linux/linux.asp), NAI Netshield (uvscan) (http://www.nai.com/naicommon/
buy-try/try/products-evals.asp), Sophos Sweep (http://www.sophos.com/),
TrendMicro Interscan (http://www.antivirus.com/products/), RAV (http://www.
ravantivirus.com). . . . Mehr Links finden Sie unter Linux anti-virus software mini-FAQ
(http://www.computer-networking.de/~link/security/av-linux_e.txt).
Mehr Informationen über das Ausetzen eines Viren Erkennungs Systems finden Sie in dem
Artikel von Dave Jones Building an E-mail Virus Detection System for Your Network (http:
//www.linuxjournal.com/article.php?sid=4882).
106
107
Kapitel 9
Vor einer Komprimitierung
9.1
Aufsetzen einer Eindringlingserkennung
Debian enthält verschiedene Tools zur Erkennung von Eindringlingen, die Sie vielleicht dazu
benutzen wollen, Ihr lokales System zu verteidigen (wenn Sie wirklich paranoid sind oder Ihr
System wirklich kritische ist) or um andere Systeme im gleichen Netzwerk zu verteidigen.
Beachten Sie immer, dass Sie, um Ihre System-Sicherheit mit einerm dieser Tools wirklich
zu verbessern, einen Alarm-und-Antwort-Mechanismus brauchen, also benutzen Sie keinen
Eindringlings-Erkennung, wenn Sie niemanden akarmieren werden (d.H. verschwenden Sie
nicht Ihre Zeit damit, Dinge zu konfigurieren, die Sie später nicht benutzen werden).
Die meisten Eindringlings Erkennungs Tolls werden entweder auf Syslog protokollieren oder
Emails, über einen bestimmten erkannten Angriff, an den Root-User senden (die meisten können umkonfiguriert werden, um stattdessen einem anderen User Emails zu schicken). Ein Administrator muss sie passend konfigurieren, so dass falsche Positivmeldungen keinen Alarme
auslösen, und so diesen Alarmen die notwendige Aufmerksamkeit geschenkt wird. Alarme
können auf einen laufenden Angriff hindeuten und wären - sagen wir mal einen Tag - später
nicht mehr nützlich, da der Angriff dann bereits erfolgreich beendet worden sein kann. Stellen
Sie also sicher, dass es eine passende Regelung über die Behandlung von Alarmen gibt, und
das technische Masnahmen zur Handhabung statt finden.
Eine Interessante Quelle für Information ist CERT’s Intrusion Detection Checklist (http://
www.cert.org/tech_tips/intruder_detection_checklist.html)
9.1.1
Netzwerk basierende Eindringlings Erkennung
Snort ist ein flexibler Packet Schnüffler oder logger, der Angriffe durch nutzen einer AngriffsSignatur-Bibliothek erkennt. Es erkennt eine breite Pallete von Angriffen und Tests, wie zum
Beispiel Speicher-Überläufe, stealth Port scans, CGI Angriffe, SMB Tests und vieles mehr. Dies
iste in Tool, das auf jedem Router installiert werden sollte, um ein Auge auf Ihrem Netzwerk
zu haben. Installieren Sie es einfach mit apt-get install snort, folgen Sie den Fragen
und beobachten Sie die logs.
Kapitel 9. Vor einer Komprimitierung
108
Debians Snort kommt mit vielen eingeschalteten Sicherheits Checks, die Sie vielleicht haben
möchten, jedoch sollten Sie das Setup anpassen, um bestimmte Services auf Ihrem System zu
berücksichten. Sie möchten vielleicht auch zusätzliche Teste speziell für Ihre Services nutzen.
Sie können snort sowohl dazu benutzen, eine Netzwerk-Eindringlings-Erkennung für viele
Hosts in Ihrem Netzwerk zu etablieren, als auch um Angriffe gegen Ihren eigenen Host zu
erkennen.
Es gibt noch andere Tools, die dazu benutzt werden können, Netzwerk Angriffe zu erkennen
(sogar einfacherere). Portsentry ist ein anderes interessantes Paket, dass Sie warnen kann,
wenn jemand Ihre Seite scannt. Andere Tools, wie ippl oder iplogger erkennen ausserdem
bestimmte IP (TCP und ICMP) Angriffe, auch wenn sie keine fortgeschrittenen Techniken zur
Erkennung von Netzwerk Angriffen haben (was snort kann).
Sie können jedes dieser Tools mit dem idswakeup Programm testen. Hierbei handelt es sich
um einen Falsch-Positv Generator, der NIDS mit einer Auswahl der üblichen unter Debian
verfügbaren Angriffs-Signaturen alarmiert.
9.1.2
Host basierende Erkennung
Tiger ist ein bewährtes Eindringlings Erkennungs Toools, dass seit der Woody Distribution
auf Debian portiert wurde. Tiger bietet Tests von allgemein üblichen Dingen, in bezug auf Einbrüche, Tests der Passwort-Stärje, Dateisystem Probleme, kommunizierende Prozesse. . . . Die
Debian Version umfasst neue, Debian spezifische Tests: md5-Summen von vorhandenen binaries, und Test auf installierte und verwundbare Pakete. Die standard Installation lässt tiger
jeden Tag einmal laufen und einen Report erstellen, der an den Superuser geschickt wird. Die
erstellten Reports können Informationen zu einer geglückten Komprimitierung geben.
Protokoll-Analyse Tools, wie zum Beispiel logcheck können zusätzliche benutzt werden,
wenn sie angepasst wurden, um Eindring-Versuche zu erkennen. Siehe ‘Nutzen und anpassen
von logcheck’ auf Seite 52.
Ausserdem kann jeder der Dateisystem-Integritäts-Checker (siehe ‘Prüfen der Integrität des
Dateisystems’ auf Seite 63) können sehr nützlich sein, um Anomalien in einer abgesicherten
Umgebung zu erkennen. Ein erfolgreicher Eindringling wird mit höchster Sicherheit Dateien
auf dem lokalen Dateisystem veröndern, um die lokalen Sicherheits Regelungen zu umgehen,
Trojaner zu installieren, eigene User zu erstellen. . . solche Sachen können mit ihnen erkannt
werden.
9.2
nützliche Kernel-Patches
FIXME: This section needs to cover how these specific patches can be installed in Debian using
the kernel-2.x.x-patch-XXX packages.
Es gibt einige Kernel-Patches, die die System-Sicherheit signifikant erhöhen. Hier sind einige
davon aufgezählt:
109
• OpenWall Patch von Solar Designer. Sinnvoll für Einschränkungen auf Kernel-Ebene,
zum Beispiel bei Links, FIFOs in /tmp, Einschränkungen von /proc, die Behandlung
spezieller Datei Deskriptoren, nicht-ausführbarer Teil des User-Stack und noch mehr.
Homepage: http://www.openwall.com/linux/
• LIDS — Linux intrusion detection system von Huagang Xie & Philippe Biondi. Dieser Patch
macht es einfacher, ein sicheres Linux System zu erstellen. Sie können jeden Prozess
einschränken, ihm bestimmte Rechte zum lesen und Schreiben von Dateien gewägren,
oder die Fähigkeit Dateien zu lesen ganz entfernen. Weiterhin können Sie bestimmte
einem Prozess auf Ressourcen beschränken. Auch wenn er sich noch in der Beta-Phase
befindet, ist er fast schon ein Muss für den paranoiden System-Administrator. Homepage: http://www.lids.org
• POSIX Access Control Lists (ACLs) for Linux Dieser Patch führt Listen zur Zugangs Konrtolle (Access Control Lists (ACLs)), eine fortgeschrittene Methoden die Zugriffe auf
Dateien zu beschränken, in den Linux Kernel ein. Homepage: http://acl.bestbits.
at/
• Linux trustees Dieser Patch bringt ein anständig erweitertes Rechte-System für Ihrem Linux Kernel. All die Objekte werden im Kernel-Speicher abgelegt, was eine schnelles nachschlagen aller Zugriffsrechte erlaubt. Homepage: http://trustees.sourceforge.
net/
• International kernel patch Dies ist ein Kryptographie-Patch für den Kernel, demzufolge
müssen Sie die jeweiligen Richtlinien des Landes über Verschlüsselung beachten. Er stellt
die grundlegenden Funktionen für verschlüsselte Dateisysteme zur Verfügung. Homepage: http://www.kerneli.org
• SubDomain Eine Kernel Erweiterung um sicherere und einfacher bedienbare ChrootUmgebungen aufzusetzen. Sie können alle Dateien, die ein gechrooteter Service benlötigt, manuell angeben, und müssen so die Services nicht statisch compilieren. Homepage: http://www.immunix.org/subdomain.html
• UserIPAcct Eigentlich nicht wirklich Sicherheits relevant erlaubt dieser Patch es Ihnen, Quotas für den Traffic auf Ihrem Server pro User einzuführen. Zusätzlich können Sie Statistiken über den Traffic eines Users erstellen. Homepage: http://ramses.
smeyers.be/useripacct.
• FreeS/WAN Wenn Sie unter Linux IPSec benutzen wollen, benötigen Sie diesen Patch. Sie
können dann leicht VPNs erstellen, sogar zu Windows-Machinen, da IPSec ein gemeinsamer Standard ist. Homepage: http://www.freeswan.org
9.3
9.3.1
Vermeiden von Root-Kits
LKM - Ladbare Kernel-Module
LKM (Loadable Kernel Modules) sind Dateien, die nachladbare Teile des Kernels enthalten.
Sie werden dynamisch in den Kernel geladen und führen bestimmte Aufgaben aus. Unter
110
GNU/Linux werden sie dazu benutzt, die funktionalität des Kernels zu erweitern. Wenn Sie
LKMs benutzen, geniesen Sie einige Vorteile. Wie wir gesehen haben können Sie dynamisch
nachgeladen werden, ohne dass der Kernel neu compiliert werden muss, Sie können bestimmte Geräte-Treiber (oder Dateisysteme) und Treiber für andere Hardware, wie Sound- oder
Netzwerkkarten, enthalten. Aber manche Cracker können LKMs für Root-Kits (knark oder
adore) benutzen, um auf GNU/Linux Systemen Hintertüren zu installieren.
LKM Root-Kits können Prozesse, Dateien, Verzeichnisse und sogar Verbindungen verstecken,
ohne den Quellcode irgendeines Binaries verändern zu müssen. Zum Beispiel kann ps Prozess
Informationen aus /proc beziehen, ein bösartiges LKW kann den Kernel untergraben, so dass
er einen bestimmten Prozess vor dem procfs veheimlicht. So kann noch nicht einmal eine selbsterstellte, unangetastete Kopie des ps Binary alle Prozess Informationen korrekt auflisten.
9.3.2
Erkennen von Root-Kits
Die Sucharbeit kann einfach und schmerzloss sein, oder schwierig und ermüdend, ganz abhängig von der Massnahme, die Sie benutzen. Es gibt zwei Verteidigungsmassnahmen zur
Sicherheit bei LKMs, die proaktive, und die reaktive.
Proaktive Verteidigung
Der Vorteil dieser Verteidigung ist, dass hier verhindert wird, dass einige LKM Root-Kits dem
System schaden. Die meist genutzte proaktive Verteidigung ist es, das Ziel zuerst zu erreichen,
also ein LKM zu laden, das dazu da ist, das System vor Schaden durch ein bösswilliges LKM
zu schützen. Eine andere Massnahme ist es, dem Kernel Fähigkeiten zu entziehen, und so
das System sicherer zu machen. Zum Beispiel können Sie dem Kernel die Fähigkeit entziehen,
Kernel-Module zu laden oder zu entfernen.
Sie können auf Debian Systeme einige Pakete finden, die Proaktive-Tools enthaölten:
• kernel-patch-2.4-lsm - LSM ist das Linux Security Modules framework
• lcap - Eine Benutzerfreundliche Schnittstelle, um dem Kernel Fähigkeiten zu entziehen
(Kernel-basierte Zugriffs-Kontrolle), um das System sicherer zu machen. Führen Sie
lcap CAP_SYS_MODULE 1 aus, um sogar als Root-User keine Module mehr laden zu
können. 2
1
Es gibt über 28 Fähigkeiten einschliesslich: CAP_BSET, CAP_CHOWN, CAP_FOWNER, CAP_FSETID,
CAP_FS_MASK,
CAP_FULL_SET,
CAP_INIT_EFF_SET,
CAP_INIT_INH_SET,
CAP_IPC_LOCK,
CAP_IPC_OWNER, CAP_KILL, CAP_LEASE, CAP_LINUX_IMMUTABLE, CAP_MKNOD, CAP_NET_ADMIN,
CAP_NET_BIND_SERVICE, CAP_NET_RAW, CAP_SETGID, CAP_SETPCAP, CAP_SETUID, CAP_SYS_ADMIN,
CAP_SYS_BOOT, CAP_SYS_CHROOT, CAP_SYS_MODULE, CAP_SYS_NICE, CAP_SYS_PACCT, CAP_SYS_PTRACE,
CAP_SYS_RAWIO, CAP_SYS_RESOURCE, CAP_SYS_TIME, and CAP_SYS_TTY_CONFIG. Alle können aktiviert
oder deaktiviert werden, um Ihren Kernel abzusichern.
2
Um dies tun zu können, müssen Sie nicht lcap installieren, aber es ist so einfacher, als mit der Hand /proc
/sys/kernel/cap-bound anzupassen.
111
Wenn Sie diese vielen Möglichkeiten auf Ihrem GNU/Linux System nicht brauche, möchten
Sie vielleicht die Unterstützung für ladbare Module während der Kernel Konfiguration abschalten. So werden LKM Root-Kits vermieden, aber Sie können nicht mehr modulare Kernel
benutzen. Beachten Sie auch, dass durchd as abschalten der nachladbaren Module der Kernel
überladen werden kann. Manchmal ist dies nicht notwendig.
Um die Unterstützung für nachladbare Module abzuschalten, setzen Sie einfach CONFIG_MODULES=n in .config.
Reaktive Verteidigung
Der Vorteil reaktiver Verteidigung ist, dass is die System Resourcen weniger überlädt. Sie funktioniert durch vergleichen Tabelle für System-Aufrufe mit einer bekanntermassen sauberen
Kopie in einer Date (System.map). Der augenscheinliche Nachteil ist, dass der Systemadministrator erst davon erfährt, wenn das System bereits kompromitiert wurde.
Die Entdeckung von Root-Kits vollbringt unter Debian chkrootkit. Das Programm Chkrootkit (http://www.chkrootkit.org) prüft Anzeichen von Root-Kits auf dem lokalen
System, und stellt fest ob der Computer mit einem Root-Kit infiziert ist.
Sie können auch KSTAT (http://www.s0ftpj.org/en/site.html) (Kernel Security
Therapy Anti Trolls) von S0ftproject group benutzen. KSTAT prüft den Bereich des KernelSpeichers (/dev/kmem) auf Informationen über den Ziel Host, einschliesslich der Installation
von ladbaren Kernel-Modulen.
FIXME: Add info on how to compile the kernel w/o lkm support?
9.4
geniale/paranoide Ideen — was Sie tun können
Dies ist wahrscheinlich der instabilste und lustigste Abschnitt, da ich hoffe, dass manche der
“Wow, das klingt verrückt” Ideen realisiert werden. Nachfolgend einer Liste von ein paar Ideen
— abhängig von Ihrem Standpunkt aus können Sie sie für genial, paranoid, verrückt oder
sicher halten — um Ihre Sicherheit schnell zu erhöhen. Unbeschädigt werden Sie sie aber nicht
überstehen.
• Mit PAM herumspielen. Wie in einem phrack 56 Artikel geschrieben: Das schöne an PAM
ist, dass “Ihrer Fantasie keine Grenzen gesetzt sind.” Das stimmt. Stellen Sie sich vor,
Root kann sich nur mit einen Fingerabdruck, oder Augenscan oder einer Kryptocard
einloggen (Warum habe ich hier nur “oder” und nicht “und” gesagt?) and not AND
here?).
• Faschistisches Logging. Ich würde sagen, dass alles, was wir bisher über Logging besprochen haben, unter “weiches Loggen” fällt. Wenn Sie echtes Logging betreiben
wollen, besorgen Sie sich einen Drucker mit Endlos-Papier, und loggen Sie alles dauerhaft, indem Sie es drucken. Hört sich lustig an, ist aber zuverlässig und kann nicht entfernt werden.
112
• CD Distribution. Diese Idee ist sehr leicht zu realisieren und bewirkt ganz gute Sicherheit. Erstellen Sie eine abgesicherte Debian Distribution, mit passenden Firewall-Regeln,
erstellen Sie ein ISO-Image und brennen Sie es auf CD. Machen Sie die CD bootbar. Dies
ist eine nur lesbare Distribution mit etwa 600 MB Platz für Services, und es ist unmöglich
für einen Eindringling Schreibzugriff auf dieses System zu erhalten. Stellen Sie lediglich
Sicher, dass alle Daten, die geschrieben werden sollen, über Netz gesichert werden. So
kann der Eindringling jedenfalls nicht die Firewall-Regeln oder Routing-Einträge ändern, oder eigene Daemonen starten (natürlich kann er es, aber booten Sie neu, und er
muss sich erneut in Ihr System hacken, um die Änderungen vorzunehmen).
• Schalten Sie die Modul-Fähigkeiten des Kernels ab. Wenn Sie die Nutzung von KernelModulen während der Kernel-Kompilierung abschalten, werden viele Kernel basierende
Hintertüren nicht einsetzbar, da die meisten von ihnen darauf basieren, ein modifiziertes
Kernel Modul zu installieren.
• Loggen über ein serielles Kabel (von Gaby Schilders). So lange Server immernoch serielle
Schnittstellen haben: Stellen Sie sich vor, Sie hätten eien Maschine als Log-Maschine, vom
Netz abgeschnitten. In der Mitte einen Multiplexer für serielle Schnittstellen (zyklisch
oder so). Jetzt sollen alle Ihre Server über ihre seriellen Schnittstellen loggen. Einfach
nur hinschreiben. Die Log-Maschine akzeptiert nur einfachen Text als Eingabe auf seiner seriellen Schnittstelle und schreibt es lediglich in eine Log-Datei. Schliessen Sie einen
CD- oder DVD-Brenner an. Wenn die Log-Datei 600MB erreicht wird sie auf CD-ROM
geschrieben. Wenn es jetzt nur noch CD-Brenner mit automatischem Medien-Wechsel
gäbe. . . Nicht so dauerhaft gespeichert wie ein Ausdruck, aber man kann grössere Mengen hanghaben, und die CDs nehmen nicht so viel Platz weg.
• Setzen Sie den ganzen Kram auf “immutable” (der Tips-HOWTO von Jim Dennis entnommen). Gerade nachdem Sie Ihr System installiert und konfiguriert haben, gehen
Sie durch /bin, /sbin/, /usr/bin, /usr/sbin und /usr/lib (und ein paar andere
von den üblichen Verdächtigen) und gehen Sie freizügig mit chattr +i command um.
Machen Sie dies auch mit den Kernel Dateien. Nun mkdir /etc/.dist/, und kopieren
Sie alles von /etc/ an abwärts dort hinein (ich mach das in zwei Schitten, indem ich
ein /tmp/etcdist.tar benutze um Rekursionen zu verweiden). (Optional können Sie
auch einfach nur ein /etc/.dist.tar.gz erstellen) – und markieren sie alles als “immutable”.
Der Grund für all dies ist den Schaden zu begrenzen, den Sie anrichten können, wenn
Sie als root eingeloggt sind. Sie können keine Dateien mit einer fehlgeleiteten Umleitung
überschreiben, und Sie werden Ihr System nicht durch ein fehlplaziertes Leerzeichen
im rm -fr Kommando unbenutzbar machen (Sie können aber Ihren Daten immernoch
einigen Schaden zufügen — aber Ihre Bibliotheken und Programme sind sicherer).
Dies macht auch verschiedene Sicherheits- und Denial-of-Service Exploits entweder unmöglich oder weitaus schwieriger (da viele von Ihnen darauf beruhen, Dateien durch
die Aktionen von SUID Programmen, die isn’t providing an arbitrary shell command, zu
überschreiben).
Die einzige Unbequemlichkeit dabei ist es, wenn sie irgendetwas bauen und ein make
install auf verschiedene System-Binaries machen. Auf der anderen Seite verhindert
113
dies auch das make install Dateien überschreibt. Wenn Sie vergessen, das Makefile
zu lesen und die Datein, die überschrieben werden sollen mit chattr -i zu behandeln (und
die Verezichnisse, in denen Sie neue Dateien erstellen wollen) - schlägt das make fehl, Sie
müssen nur das chattr Kommando ausführen und make neu aufrufen. Sie können diese
Gelegenheit gleich dazu benutzen, Ihre alten bin’s, libs oder was-auch-immer in ein .oldVerzeichniss zu sichern, oder unzubennenen, oder sie zu taren, oder sowas.
Beachten Sie, dass dies Sie auch daran hindert, die Pakete Ihres Systems upzugraden.
Da die Dateien aus den Paketen nicht überschrieben werden können. Also möchten
Sie veilleicht einen Mechanismus, der das immutable-Flag auf allen Dateien deaktiviert,
bevor Sie ein apt-get update ausführen.
9.4.1
Aufstellen eines Honigtopfes (honeypot)
FIXME: More Content specific to Debian needed.
Wenn Sie wollen (und es implementieren können und ihm Zeit widmen können) können
Sie einen vollen Honeypot mit einem Debian GNU/Linux System aufsetzen. Sie haben alle
benötigten Werkzeuge, um einen allumfassendes Honeynet aufzubauen (d.h. das Netzwerk,
der Honeypot ist lediglich ein falsche Server): Die Firewall, das Netzwerk EindringlingsErkennungssystem, und den falschen Server. Seien Sie aber vorsichtig, Sie müssen ziemlich
sicher sein, dass Sie rechtzeitig alarmiert werden (siehe ‘Die Wichtigkeit von Logs und Alarmen’ auf Seite 52), so dass sie geeignete Massnahmen einleiten können und die Komprimitierung sobald Sie genug gesehen haben beenden können.
• Die Notwendige Firewall-Technologie (durch den Linux-Kernel verfügbar)
• syslog-ng um die Logs des Honeypot zu dem fern-Syslog einer Server-Maschine zu
schicken.
• snort um allen eingehenden Netzwerk Verkehr auf den Honeypot mitzuscheiden und
Angriffe zu erkennen
• osh das Sie dazu benutzen können, um eine eingeschränkte Shell mit Protokoll zu bauen
(siehe den Artikel von Lance Spitzner weiter unten)
• Natürlich alle Server die Ihnen einfallen für die falschen Server des Honeypots (aber
sichern Sie nicht den Honeypot).
• und falsche Services, verfügbar duch dtk, wenn Sie das Honeynet auch als
Eindringlings-Erkennungs-Service benutzen wollen.
• Integritäts Prüfer (siehe ‘Prüfen der Integrität des Dateisystems’ auf Seite 63) und The
Coroner’s Toolkit (tct) um nach dem Angriff eine Analyse durchzuführen.
Sie können mehr über das aufstellen von Honeypots in Lanze Spitzners exzellentem Artikel To Build a Honeypot (http://www.net-security.org/text/articles/
spitzner/honeypot.shtml) (aus der Know your Enemy Serie) oder David Raikow’s
114
Building your own honeypot (http://www.zdnetindia.com/techzone/resources/
security/stories/7601.htm) lesen. Ausserdem ist das Honeynet Project (http://
project.honeynet.org/) dem Aufstellen von Honeypots und der Analyse von Angriffen auf Sie gewidmet. Dort gibt es wertvolle Informationen über das aufsetzen von Honeypots
und die Analyse der Resultate eines Angriffs (sehen Sie sich den Contest an).
115
Kapitel 10
Nach einer Komprimitierung
10.1
Allgemeines Verhalten
Wenn Sie während eines Angriffs physisch present sind, wird es sich nicht dauerhaft nachteilig
auf Ihre Geschäffte auswirken, wenn Sie einfach das Kabel aus der Netzwerkkarte ziehen, bis
Sie herausbekommen, was der Eindringling tat und die Kiste gesichert wurde. Das Netzwerk
auf der untersten Ebenen abzuschalten ist der einzig sichere Weg, um den Angreifer daran zu
hindern, den Rechner zu komprimitieren (Phillip Hofmeisters weiser Ratschlag).
Wenn Sie eine Komprimitierung wirklich schnell reparieren wollen, sollten Sie den komprimitierten Rechner aus dem Netzwerk entfernen, und das Betriebssystem von Grund auf neu
Installieren. Dies könnte natürlich gar nichts bewirken, wenn Sie nicht wissen, wie der Eindringling root-Rechte bekommen hat. In diesem Fall müssen Sie alles prüfen: firewall, Datei
Integrität, Logdateien des Loghost und so weiter. Weitere Informationen was Sie nach einem
Einbruch tun sollten, finden Sie unteer Sans’ Incident Handling Guide (http://www.sans.
org/y2k/DDoS.htm) oder CERT’s Steps for Recovering from a UNIX or NT System Compromise (http://www.cert.org/tech_tips/root_compromise.html).
10.2
Anlegen von Sicherheitskopien Ihres Systems
Vergessen Sie nicht, dass wenn Sie sicher sind, dass das System komprimitiert wurde, Sie weder der installierten Software noch irgendwelchen Informationen, die es an Sie liefert, vertrauen
können. Applikationen könnten von einem Trojaner befallen sein, Kernel Module könnten installiert worden sein, usw.
Das beste das Sie machen können ist eine komplette Sicherheitskopie Ihres Dateisystems
(durch dd) nachdem Sie von einem sicheren Medium gebootet haben. Debian GNU/Linux
CDs können hierzu benutzt werden, da Sie auf Konsole zwei eine Shell anbieten, nachdem die
Installation gestartet ist (mit Alt+2 und Enter aktivieren Sie sie). Die Shell kann zum anlegen
der Sicherheitskopie woanders hin (vielleicht über einen Netzwerk File-Server über NFS/FTP)
benutzt werden, zur Analyse während das System offline ist (oder zu Reinstallation).
Kapitel 10. Nach einer Komprimitierung
116
Wenn Sie sicher sind, dass es sich lediglich um ein trojanisiertes Kernel-Modul handelt, versuchen Sie das Kernel-Image von der CD im rescue Modus zu laden. Stellen Sie ausserdem
sicher, dass Sie im single Modus starten, so dass auch nach dem Kernel keine weiteren trojanisierten Prozesse gestartet werden.
10.3
forensische Analyse
Wenn Sie mehr Informationen sammeln wollen, enthält das Paket tct (The Coroner’s Toolkit
von Dan Farmer und Wietse Venema) Werkzeuge für eine “post mortem” Analyse des Systems. tct erlaubt es dem Benutzer Informationen über gelöschte Dateien, laufende Prozesse
und mehr zu sammeln. Sehen Sie bitte für weiter Informationen in die mitgelieferte Dokumentation.
Forensische Analysen sollten immer auf eine Sicherheitskopie der Daten angewendet werden,
niemals auf die Daten selbst, da Sie durch diese Analyse beeinflusst werden können.
FIXME: This paragraph will hopefully provide more information about forensics in a Debian
system in the coming future.
FIXME: talk on how to do a debsums on a stable system with the md5sums on CD and with
the recovered filesystem restored on a separate partition.
117
Kapitel 11
Frequently asked Questions (FAQ)
Dieses Kapitel führt Sie in ein paar der am häufigsten gestellten Fragen in der SecurityMailing-Liste ein. Sie sollten sie lesen, bevor Sie dort etwas posten, oder die Leute werden
Ihnen lediglich “RTFM!” sagen.
11.1
Sicherheit im Debian Betriebssystem
11.1.1
Ist Debian sicherer als X?
Ein System ist so sicher, wie der Administrator fähig ist, es sicher zu machen. Debian versucht Services auf eine standardmässig sicher-Art zu installieren, und wird nicht versuchen so
paranoid wie andere Betriebssysteme zu sein, die Services auf eine standardmässig abgeschaltetArt installieren. In jedem Fall muss der System-Administrator die Sicherheit des System den
lokalen Sicherheits-Regeln anpassen.
11.1.2
In bugtray gibt es viele Debian-Fehler. Heisst das, es ist sehr gefährdet?
Debian enthält wirklich viele Pakete und unterschiedliche Software, wahrscheinlich sogar
mehr, als mit manch einem propietären Betriebssystem geliefert wird. Die heisst, dass es mehr
potentielle Sicherheits-Angelegenheiten geben kann, als bei einem System mit weniger Software.
Wie auch immer: Es gibt viele Sicherheits-Gutachten in Zusammenhang mit Quell-Code Überprüfungen von grösseren Software-Komponenten, die Debian enthält. Wann immer eine solche
Überprüfung eine grössere Lücke findet, wird er repariert und ein Sicherheitsgutachten wird
al Listen wie bugtraq geschickt.
Fehler, die in der Debian Distribution vorhanden sind, betreffen normalerweise auch andere Lieferanten und andere Distributionen. Prüfen Sie einfach einfach den “Debian specific: yes/no” Eintrag am Anfang jedes Sicherheitsgutachten (DSA, Debian Security Advisory).
Kapitel 11. Frequently asked Questions (FAQ)
118
Wenn dort “yes” steht, betrifft es nur Debian, wenn dort “no” steht, betrifft es wahrscheinlich
auch andere Distributionen.
Debian enthält wirklich viele Pakete, und heutzutage gibt es viele Gruppen die nach
Sicherheits-Problemen in Software suchen (warum auch immer).
11.1.3
Hat Debian irgendein Zertifikat für Sicherheit?
Kurze Antwort: Nein.
Lange Antwort: Zertifikate kosten Geld und niemand hat Resourcen dazu bestimmt, die Debian GNU/Linux Distributionen auf irgendeiner Stufe, beispielsweise der Common Criteria,
zu zertifizieren. Wenn Sie daran interessiert sind, eine zertifizierte GNU/Linux Distribution
zu haben, stellen Sie uns die Resourcen zur Verfügung, um dies Möglich zu machen.
11.1.4
Gibt es irgendein Absicherungsprogramm für Debian?
Ja. Bastille Linux (http://www.bastille-linux.org), ursprünglich an anderen Linux
Distributionen (RedHat und Mandrake) orientiert funktioniert es derzeit auch mit Debian. Es
sind Massnahmen eingeleitet, um die entsprechenden Änderungen auch der ursprünglichen
Version zugute kommen zu lassen. In jedem Fall heisst das Debian-Paket natürlich bastille.
Manche Leute glauben jedoch, dass ein Absicherungsprogramm nicht die Notwendigkeit einer
guten Administration eliminiert.
11.1.5
Ich möchte eine XYZ-Service laufen lassen. Welchen sollte ich benutzen?
Einer der Vorteile von Debian, der die meisten neuen Administratoren verwirren könnte, ist,
dass es eine grosse Zahl von Software, die den gleichen Service anbietet (DNS-Server, MailServer, FTP-Server, Web-Server. . . ) enthält. Wenn Sie wissen wollen, welchen Server Sie installieren sollten, gibt es keine allgemeingültige Antwort. Es hängt wirklich von den benötigten
Fähigkeiten und der benötigten Sicherheit (was eventuell ausbalanciert werden muss) ab.
Dinge, die Sie prüfen sollten:
• Wird es noch vom ursprünglichen Autor gepflegt? (Wann war die letzte Release?)
• Ist er ausgereift? (Die Versions-Nummer sagt nichts aus, versuchen Sie seine Geschichte
nachzuvollziehen)
• Ist er von Fehler durchsetzt? Gab es Sicherheitsgutachten über ihn?
• Stellt er die ganze Funktionalität, die Sie benötigen, zur verfügung? Stellt er mehr zur
Verfügung, als Sie wirklich brauchen? more than you really need?
11.1.6
119
Wie mach ich den Service XYZ unter Debian sicherer?
Sie werden in diesem Dokument Informationen über das Absichern von einigen Servicen
(FTP, Bind) unter Debian GNU/Linux finden. Für Services die hier nicht abgedeckt werden,
prüfen Sie die Programm Dokumentation, oder allgemeine Linux Informationen. Die meisten
Sicherheits-Hinweise für Unix-Systeme sind auch auf Debian anwendbar. So ist das Absichern von Service X unter Debian meistens wie das absichern des Service unter einer anderen
Linux-Distribution (oder Unix, was das betrifft).
11.1.7
Sind alle Debian Pakete sicher?
Das Sicherheits-Team von Debian kann nicht alle Pakete aus Debian auf potentielle SicherheitsLücken hin analysieren, da es einfach nicht genug Resourcen gibt, um allen Quellcode zu
prüfen. Dennoch profitiert Debian von den Quellcode-Prüfungen durch den ursprünglichen
Entwickler oder durch ander Projekte, wie das Linux Kernel Security Audit Project (http:
//kernel-audit.sourceforge.net/) oder das Linux Security-Audit Project (http://
www.lsap.org/).
Tatsächlich könnte ein Debian Developer in einem Paket einen Trojaner verbreiten, und es gibt
keine Möglichkeit das nachzuprüfen. Sogar wenn sie in Debian eingeführt würden, wäre es unmöglich alle möglichen Situationen, in der der Trojaner ausgeführt werden würde, abzudecken.
Dies fällt unter die no guarantees Lizens-Klausel. In jedem Fall können Debian User insofern
Vertrauen fassen, dass der stabile Quellcode eine breite Prüfung hinter sich hat und die meisten Probleme durch Benutzung endeckt worden wären. Es ist in jedem Fall nicht empfohlen
ungetestete Software auf einem wertvollen System zu installeren (wenn Sie nicht die notwendige Code-Prüfung vornehmen können). Und in jedem Fall kann, wenn es zu in die Distribution
eingeführten Sicherheits-Problemen käme, könnte der Prozess zu ihrer Aufnahme (der digitale
Unterschriften benutzt) sicherstelen, dass das Problem letzendlich zu dem Developer zurückgeführt werden kann. Und das Debian Project hat diese Angelegenheiten nie auf die leichte
Schulter genommen.
11.1.8
Betriebssystem User und Gruppen
Sind alle System User notwendig?
Ja und nein. Debian kommt mit einigen für bestimmte Services vordefinierten Usern (ids < 99,
beschrieben in der Debian Policy (http://www.debian.org/doc/debian-policy/)). So
wird das installieren eines neuen Service einfach (das sie dann bereits als ein passender User
laufen). Wenn Sie nicht vorhaben neue Services zu installieren, können Sie die User, denen
keine Dateien gehören und die keine Services auf Ihrem System laufen lassen, entfernen.
Sie können leicht User finden, denen keine Dateien gehören, indem Sie das folgenen Kommando ausführen (stellen Sie sicher, dass Sie es als root ausführen, da ein gemeiner User nicht
genug Zugriffsrechte haben könnte, um ein paar sensitive Verezichnisse zu durchsuchen):
120
cut -f 1 -d : /etc/passwd |
while read i; do find / -user "$i" | grep -q . && echo "$i"; done
Diese User kommen aus dem Paket base-passwd. Sie finden Informationen über die Behandlung dieser User unter Debian in der Dokumentation des Pakets.
Hier folgt nun eine Liste der standard User (mit ihren entsprechenden Gruppen):
• root: Root ist (typischerweise) der Superuser.
• daemon: Ein paar unpriviligierte Daemonen, die ein ein paar Dateien auf die Festplatte
schreiben müssen, laufen als daemon.daemon (portmatp, atd, wahrscheinlich noch andere). Daemonen, die keine eigenen Dateien besitzen mpüssen, können stattdessen als
nobody.nogroup laufen, und komplexere oder Sicherheits-bewusste Daemonen laufen
als eigenständige User. Der daemon User ist wahrscheinlich auch praktisch für lokale
installierte Daemons.
• bin: aus historischen Gründen beibehalten.
• sys: das gleiche wie bei bin. Jedoch gehören /dev/vcs* und /var/spool/cups der
Gruppe sys.
• sync: Die Shell des User syns ist /bin/sync. Wenn das Passwort auf etwas leicht zu
ratendes gesetzt wurde (sum Beispiel “”), kann so jeder das System von der Konsole aus
syncen, auch wenn er keinen Account auf dem System hat.
• games: Viele Spiele sind sgid games, so dass sie ihre Highscores-Dateien schreiben können. Dies wird in der Policy erklärt.
• man: Das Programm man läuft (manchmal) als User man, damit es Cat-Pages nach /var
/cache/man schreiben kann.
• lp: Wird von Druck-Daemonen benutzt.
• mail: Mailboxen unter /var/mail gehören der Gruppe mail, wie in der Policy erklärt
wird. Der User und die Gruppe werden zu verschiedenen anderen Zwecken benutzt und
für verschiedenen MTAs.
• news: Verschiedene News-Server und andere ähnliche Programme (zum Beispiel suck)
benutzen den User und die Gruppe news auf unterschiedliche Weise. Dateien im newsSpool gehören häufig dem User und der Gruppe news. Programme wie inews, die benutzt werden können, um news zu posten, sind normalerweise sgid news.
• uucp: Der uucp User und die uucp Gruppe werdem vom UUCP Subsystem benutzt. Ihnen gehören Spool- und Konfigurations-Dateien. User in der uucp-Gruppe können uucico aufrufen.
• proxy: Wie Daemon wird dieser User und diese Gruppe von manchen Daemonen (insbesondere Proxy-Daemonen) die keinen spezielle User-ID haben und eigene Dateien besitzen müssen. Zum Beispiel wird die Gruppe proxy von pdnsd benutzt, und squid läuft
als User proxy.
121
• majordom: Majordomo hat auf Debian Systemen aus historischen Gründen eine statisch
zugewiesene User-ID.Sie wird auf neuen Systemen nicht installiert.
• postgres: Postgresql Datenbanken gehören diesem User und dieser Gruppe. Alle
Dateien in /var/lib/postgresql gehören diesem User, um anständige Sicherheit zu
gewährleisten.
• www-data: Ein paar Web-Browser laufen als www-data. Web-Inhalte sollten *nicht*
diesem user gehören, oder ein kompromitierter Web-Server wäre in der Lage eine WebSeite zu überschreiben. Daten, die der Web-Server schreibt, einschliesslich Log-Dateien,
gehören www-data.
• backup: So können Backup/Wiederherstellungs Zuständigkeiten lokal an irgendjemanden ohne volle Root-Zugriffe delegiert werden.
• operator: operator ist historisch (und praktisch) der einzige ’user’ Account, der sich ferneinloggen kann, und nicht von NIS/NFS abhängt.
• list: Mailing-Listen-Archive und Daten gehören diesem User und dieser Gruppe. Manche
Mailing-Listen-Programme laufen auch unter diesem User.
• irc: Wird von irc-Daemonen benutzt. Ein statisch zugewiesener User wird nur wegen
eines bugs in ircd benötigt – es setuid sich selbst auf eine bestimmte User-ID beim start.
• gnats.
• nobody, nogroup: Daemonen die keine eigenen Dateien haben laufen als User nobody
und Gruppe nogroup. Demzufolge sollten keine Dateien auf dem gesammten System
diesem User oder zu dieser Gruppe gehören.
Andere Gruppe, die keinen assozierten User haben:
• adm: Die Gruppe adm wird zu Monitor-Zwecken benutzt. Mitglieder dieser Gruppe können viele Dateien in /var/log lesen und die xconsole benutzen. /var/log war früher
einmal /usr/adm (und später /var/adm), daher der Name dieser Gruppe.
• tty: tty-Geräte gehären dieser Gruppe. write und wall benutzen dies, damit sie auf die
ttys anderer Leute schreiben können.
• disk: Roh-Zugriff auf Festplatten. Meistens äquivalent zu Root-Zugriff.
• kmem: /dev/kmem und ähnliche Dateien sind von dieser Gruppe lesbar. Dies ist
grösstenteils ein BSD-Relikt, aber jedes Programm, dass lese Zugriff auf den SystemSpeicher braucht, kann so sgid kmem gemacht werden.
• dialout: Voller und direkter Zugriff auf serielle Schnittstellen. Mitglieder dieser Gruppen
können Modems rekonfigurieren, sich irgendwo einwählen, usw.
• dip: Der Gruppenname steht für “Dialup IP”. In der Gruppe dip zu sein erlaubt Ihnen
Tools wie ppp, dip, wvdial usw. zu benutzen. Die User dieser Gruppe können das Madem nicht konfigurieren, Sie können lediglich Programme aufrufen, die sie benutzen.
122
• fax: Erlaubt es den Mitgliedern Fax-Software zu benutzen um Faxe zu senden und zu
empfangen.
• voice: Voicemail, nützlich für Systeme, die Modems als Anrufbeantworter benutzen.
• cdrom: Diese Gruppe kann dazu benutzt werden, einer bestimmen Menge von User Zugriff auf CDROM-Laufwerke zu geben.
• floppy: Diese Gruppe kann dazu benutzt werden, einer bestimmen Menge von User Zugriff auf Disketten-Laufwerke zu geben.
• tape: Diese Gruppe kann dazu benutzt werden, einer bestimmen Menge von User Zugriff
auf Band-Laufwerke zu geben.
• sudo: Mitglieder dieser Gruppe müssen ihr Passwort eingeben, wenn sie sudo benutzen.
Siehe /usr/share/doc/sudo/OPTIONS.
• audio: Diese Gruppe kann dazu benutzt werden, einer bestimmen Menge von User Zugriff auf jedes Audio-Gerät zu geben.
• src: Dieser Gruppe gehören die Quell-Code, einschliesslich der Dateien in /usr/src. Sie
kann benutzt werden, um einem bestimmten User die Möglichkeit zu bieten, Quell-Code
des Systems zu verwalten.
• shadow: /etc/shadow ist von dieser Gruppe lesbar. Einige Programme, die auf diese
Datei zugreifen müssen, sind sgid shadow.
• utmp: Diese Gruppe kann nach /var/run/utmp und ähnlichen Dateien schreiben. Programme, die darin schreiben können müssen, sind sgid utmp.
• video: Diese Gruppe kann dazu benutzt werden, einer bestimmen Menge von User Zugriff auf ein Vidio-Gerät zu geben.
• staff: Erlaubt Usern lokale Modifikationen zu dem System hinzuzufügen (/usr/local,
/home), ohne dass sie Root-Privilegien bräuchten. Vergleichen Sie mit “adm”, die sich
mehr auf beobachten/absichern bezieht.
• users: Während Debian Systeme standardmässig das User-Gruppen-System (jeder User
hat seine eigene Gruppe) benutzen, ziehen es manche vor, ein traditionelleres Gruppen
System zu benutzen. In diesem System ist jeder User Mitglied der Gruppe “users”.
Was ist der Unterschied zwischen der adm und der staff Gruppe?
’adm’ sind Administratoren und ist meistens nützlich, um ihne zu erlauben, Log-Dateien
zu lesen, ohne su benutzen zu müssen. ’staff’ ist mehr bei den Helpdesk/junior Sysadmins
Leuten nützlich, und gibt ihnen die Möglichkeit, Dinge in /usr/local zu erledigen und
Verzeichnisse in /home anzulegen.
11.1.9
123
Fragen über Services und offene Ports
Warum werden Services während der Installation aktiviert?
Das ist der Annäherung an das Problem auf der einen Seite Sicherheits-Bewusst und auf der
anderen Seite benutzerfreundlich zu sein. Anders als OpenBSD, dass alle Services abschaltet, bis sie vom administrator aktiviert werden, aktiviert Debian GNU/Linux alle installierten
Services, bis sie abgeschaltet werden (siehe dazu ‘Daemon-Services abschalten’ auf Seite 27).
Immerhin haben Sie den Service installiert, oder?
Es gab einige Diskussionen auf Debian Mailing-Listen (sowohl auf debian-devel als auch auf
debian-security), darüber was das standard Setup sein sollte. Jedoch gab es bisher (10. März
2002) keinen Konsens, wie dies behandelt werden sollte.
Kann ich inetd entfernen?
Inetd ist nich leicht zu entfernen, da netbase von dem Paket abhängt, das Inetd enthält
(netkit-inetd). Wenn Sie es entfernen wollen, können Sie es entwerder abschalten (siehe
‘Daemon-Services abschalten’ auf Seite 27) oder das Paket entfernen, indem Sie das Paket
equivs benutzen.
Warum muss ich Port 111 offen haben?
Port 111 ist sunrpcs Portmapper und wird standardmässig bei allen Basis-Installationen eines
Debian Systems, da es keine Möglichkeit gibt, herauszubekommen, wann das Programm eines
Users RPC gebrauchen könnte, um korrekt zu arbeiten. In jedem Fall wird es meistens von NFS
benutzt. Wenn Sie kein NFS benutzen, entfernen Sie es, wie in ‘Abschalten von RPC-Servicen’
auf Seite 84 erklärt.
Wozu ist der identd (Port 113) da?
Identd wird von Administratoren benutzt, um anderen Systemen, die wissen wollen, wer für
eine bestimmte Verbindung verantwortlich ist, zusätzliche Informationen zu einer Userid zur
Verfügung zu stellen. Beachtenswert schliesst dies mail, FTP und IRC Server ein, jedoch kann
es auch dazu benutzt werden, um den User ihrer Systeme zurückzuverfolgen, der einen Angriff gestartet hat.
Es gab ausführliche Diskussionen hierrüber (siehe in den Mailing List Archiven
(http://lists.debian.org/debian-security/2001/debian-security-200108/
msg00297.html). Grundsätzlich gillt: Wenn Sie nicht wissen, was und wozu es ist, aktivieren
Sie es nicht. Aber wenn Sie es firewallen, bitte: Nehmen Sie eine reject-Regel und keine
deny-Regel, oder Kommunikation könnte bis zu einer Zeitüberschreitung hängen (siehe reject
or deny issues (http://logi.cc/linux/reject_or_deny.php3)).
124
Ich habe festgestellt, dass ich den folgenden Port (XYZ) offen habe. Kann ich ihn schliessen?
Natürlich können Sie. Die Ports die Sie offen lassen hängen von Ihrem Regelwerk bezüglich öffentlich zugänglichen Services ab. Prüfen Sie, ob Sie durch inetd (siehe ‘Abschalten von inetdServicen’ auf Seite 28) geöffnet sind, oder durch ein anderes installiertes Paket und leiten Sie
passende Massnahmen ein (konfigurieren von inetd, entfernen des Pakets, vermeiden dass der
Service beim booten gestartet wird. . . )
Ich habe einen Service von /etc/services entfernt, funktioniert das?
Nein, /etc/services zieht einfach nur eine Verbindung zwischen einem virtuellen Namen und einer Port Nummer. Das Entfernen eines Namens wird (meistens) nicht verhindern,
dass ein Service gestartet wird. Manche Daemonen starten vielleicht nicht, wenn Sie /etc
/services ändern, aber das ist nicht die Norm, und es ist nicht der empfohlene Weg einen
Service abzuschalten, siehe ‘Daemon-Services abschalten’ auf Seite 27.
11.1.10
Allgemeine Sicherheits Fragen
Ich habe meine Passwort vergessen und kann auf das System nicht mehr zugreifen!!
Die Schritte, die nötig sind, damit Sie wider Zugriff erhalten, hängen davon ab, ob Sie die
vorgeschlagene Prozedur zum Absichern von Lilo und dem Bios durchgeführt haben oder
nicht.
Wenn Sie beides eingeschränkt haben, müssen Sie im BIOS erlauben, von anderen Medien als
der Festplatte zu booten, bevor Sie weitermachen können. Wenn Sie auch Ihr BIOS-Passwort
vergessen haben, müssen Sie Ihr Gehäuse öfnen, und die Batterie des Bios entfernen.
Wenn Sie von CD-ROM oder Diskette booten können, können Sie:
• von eine Rescue-Disk booten und den Kernel starten
• auf eine virtuelle Konsole wechseln (Alt+F2)
• Die Partition mounten, auf der sich Ihr / befindet
• editieren Sie (die Debian 2.2 Rescue-Disk kommt mit ae, Debian 3.0 kommt mit
nano-tiny, der vi etwas ähnelt) die Datei /etc/shadow und ändern Sie die Zeile:
root:asdfjl290341274075:XXXX:X:XXXX:X::: (X=irgendeien Ziffer)
nach:
root::XXXX:X:XXXX:X:::
125
Dies entfernt das Root-Passwort. Sie können das System starten und sich beim login: Prompt
als Root mit einem leeren Passwort einloggen. Dies funktioniert, es sei denn, Sie haben Ihr
System etwas sicherer eingestellt, d.h. User mit leeren Passwort dürfen sich nicht einloggen
und Root kann sich nicht auf einer Konsole einloggen.
Wenn Sie diese Massnahmen getroffen haben, müssen Sie im singe-Modus starten. Wenn Sie
LILO eingeschränkt haben, müssen LILO erneut ausfrühren, nachdem Sie das Root-Passwort
zurückgesetzt haben. Das ist trickreich, da Ihre /etc/lilo.conf nicht gefunden iwrd, und
Ihr /-Dateisystem eine ramdisk und keine echte Festplatte ist.
Sobald LILO nicht mehr eingeschränkt ist, können Sie:
• Drücken Sie Alt, Shift oder Control, gerade befor das BIOS fertig wird, Sie sollten einen
LILO-Prompt erhalten.
• Geben Sie ’linux single’, ’linux init=/bin/sh’ oder ’linux 1’ am Prompt ein.
• Sie werden einen Shell-Prompt im Single-User-Modus bekommen (Sie werden nach dem
Passwort gefragt werden, aber das kennen Sie jetzt ja)
• Binden Sie die /-Partition im schreib/lese Modus neu ein:
mount -o remount,rw /
• Ändern Sie das Superuser Password mit passwd (da Sie der Superuser sind, werden Sie
nicht nach Ihrem alten Passwort gefragt werden).
11.1.11
Ich möchte meinen Usern einen Service anbieten, Ihnen aber keinen ShellAccount geben.
Wenn Sie einen zum Beispiel einen POP-Service anbieten wollen, müssen Sie nicht für jeden zugreifenden User einen Account anlegen. Am besten setzen Sie hierzu eine Verezichnis-basierte
Authentifizierung durch einen externen Service (wie Radius, LDAP oder eine SQL-Datenbank)
auf. Installieren Sie einfach die gewünschte PAM-Bibliothek (libpam-radius-auth,
libpam-ldap, libpam-pgsql oder libpam-mysql), lesen Sie die Dokumentation (Einsteiger sehen bitte unter ‘User Authentifizierung: PAM’ auf Seite 40 nach), und konfigurieren
Sie den PAM-nutzenden Service, so dass er Ihr Backend benutzt. Dies tun Sie, indem Sie die
dem Service entsprechedne Datei unter /etc/pam.d/ editieren, und die folgendende Zeile
von
auth
required
pam_unix_auth.so shadow nullok use_first_pass
beispielsweise nach ldap ändern:
auth
required
pam_ldap.so
126
Im Fall von LDAP-Verzeichnissen, liefern manche Services LDAP-Schemata mit, die Sie ihrem
Verzeichnis hinzufügen können, um LDAP-Authentifizierung mit Ihnen zu benutzen. Wenn
Sie relationale Datenbanken benutzen, gibt es einen nützlichen Trick: Benutzen Sie die where
Klausel, wenn Sie die PAM-Module konfigurieren. Wenn Sie beispielsweise eine Datenbank
mit der folgenden Tabelle haben:
(user_id,user_name,realname,shell,password,uid,gid,homedir,sys,pop,imap,ftp)
Können Sie die letzen (bool’schen) Werte dazu benutzen, denn Zugriff auf die verschiedenen
Services entweder zu erlauben oder zu verbieten, indem Sie einfach die folgenden Zeilen in
die Dateien hinzufügen:
• /etc/pam.d/imap:where=imap=1.
• /etc/pam.d/qpopper:where=pop=1.
• /etc/nss-mysql*.conf:users.where_clause = user.sys = 1;.
• /etc/proftpd.conf:SQLWhereClause “ftp=1”.
11.2
Mein System ist angreifbar (sicher?)
11.2.1
Ich habe in meinen Logs einen Angriff gesen: Bin ich kompromitiert?
Ein Hinweis auf einen Angriff heistt nicht notwendigerweise, dass Sie gehackt worden sind.
Sie sollten die üblichen Schritte einleiten, um festzustellen, ob das System kompromitiert
wurde (siehe ‘Nach einer Komprimitierung’ auf Seite 115). Beachten Sie auch, dass manchmal
die Tatsache, dass Sie einen Angriff in den Logs sehen, heissen kann, dass sie hierfür angreifbar
sind (ein bestimmter Angreifer könnte übrigens auch andere Angriffe, als die, die Sie gesehen
haben, durchgeführt haben).
11.2.2
Ich habe in meinen Logs merkwürdige “MARK”-Einträge gefunden, bin ich
kompromitiert?
Wenn Ihr System keine hohe Last (und Services) hat, finden Sie vielleicht die folgenden Zeilen
in Ihren System-Logs:
Dec 30 07:33:36 debian -- MARK -Dec 30 07:53:36 debian -- MARK -Dec 30 08:13:36 debian -- MARK -Dies zeigt keine Art der Komprimitierung, und User, die von einer Debian release wechseln,
werden es merkwürdig finden. Es ist in der Tat ein ein Indiz dafür, dass syslogd vernünftig
läuft. Aus syslogd(8):
127
-m interval
The syslogd logs a mark timestamp regularly.
The
default interval between two -- MARK -- lines is 20
minutes. This can be changed with this option.
Setting the interval to zero turns it off entirely.
-m interval
Der Syslogd protokolliert regelmässig einen
Zeitstempel. Der voreingestellte Abstand zwischen zwei -MARK -- Zeilen ist 20 Minuten. Er kann mit dieser Option
geändert werden. Setzen Sie den Abstand auf null, um
die Zeitstempel komplett abzuschalten.
11.2.3
Ich habe User gefunden, die laut meinen Logs su benutzen: Bin ich kompromitiert?
Sie könnten in Ihren Logs Zeilen wie die folgenden finden:
Apr
Apr
1 09:25:01 server su[30315]: + ??? root-nobody
1 09:25:01 server PAM_unix[30315]: (su) session opened for user nobody b
Seien Sie nicht besorgt, und prüfen Sie, ob dies durch eine Job durch Cron entsteht (normalerweise /etc/cron.daily/find oder logrotate):
$ grep 25 /etc/crontab
25 6
* * *
root
test -e /usr/sbin/anacron || run-parts --report
/etc/cron.daily
$ grep nobody /etc/cron.daily/*
find:cd / && updatedb --localuser=nobody 2>/dev/null
11.2.4
Ich bin Opfer eines Einbruchs - was soll ich jetzt tun?
Lesen Sie dieses Dokument und leiten Sie passenden, hier dargestellten massnahmen ein.
Wenn Sie Hilfe benötigen, können Sie auf der debian-security@lists.debian.org Liste Rat suche,
wie Sie Ihr System wiederherstellen/patchen.
11.2.5
Wie kann ich Angriffe aufsprüren?
Durch durchgehen der Logs (wenn Sie nicht geändert wurden), benutzen eines EindringlingErkennungs-Systems (siehe ‘Aufsetzen einer Eindringlingserkennung’ auf Seite 107),
traceroute, whois und ähnliche Tools (einschliesslich forensiche Analyse) können einen
Angriff zu seiner Ursprung zurückverfolgen. Wie Sie auf diese Informationen reagieren hängt
ausschliesslich von Ihren Sicherheits-Regeln ab, und was Sie als Angriff betrachten. Ist ein einfacher Scan ein Angriff? Ist das Prüfen auf eine Verwundbarkeit ein Angriff?
11.2.6
128
Das Programm X ist in Debian angreifbar - was soll ich machen?
Nehmen Sie sich einen Augenblick Zeit, um zu schauen, ob die Angriffsmöglichkeit in
öffentlichen Sicherheits-Mailinglisten (wie Bugtraq) oder anderen Foren bekannt gemacht
wurde. Das Debian-Sicherheits-Team hält sich bei diesen Listen auf dem laufenden, also könnten ihnen dieses Problem bereits bekannt sein. Leiten Sie keine weiteren Massnahmen ein,
wenn Sie schon ein Sicherheits-Gutachten auf http://security.debian.org sehen.
Wenn Sie nichts finden, senden Sie bitte eine Mail mit einer möglichst detailierten Beschreibung des Angriffspunktes (Code, der dies bestätigt ist auch okay) adn security@debian.org.
Dadurch erreichen Sie das Sicherheits-Team.
11.2.7
Laut der Versions-Nummer eines Paketes, läuft bei mir immernoch eine angreifbare Version!
Anstatt auf neue Releases zu aktualisieren, führen wir Sicherheits-Korrekturen auf die Version zurück, die in der stabilen Version enthalten war. Der Grund dafür ist, dass wir sicher
gehen wollen, dass eine stabile Release so wenig wie möglich verändert wird. So werden sich
Dinge nicht unerwartet ändern oder kaputt gehen, als Resultat einer Sicherheits-Korrektur. Sie
können prüfen, ob Sie eine sichere Version eines Paketes benutzen, indem Sie das Changelog
des Paketes durchsehen, oder indem Sie die exakte Versions Nummer (Ursprüngliche Version
-slash- Debian Release) mit der Nummer aus dem Debian Sicherheits-Gutachten vergleichen.
11.2.8
spezielle Software
Proftpd ist für einen “Denial of Service”-Angriff anfällig.
Fügen Sie DenyFilter \*.*/ Ihrer Konfigurations Datei hinzu. Mehr Informationen entnehmen Sie http://www.proftpd.org/critbugs.html.
11.3
Fragen über Debians Sicherheitsteam
11.3.1
Was ist ein Debian Sicherheitsgutachten (Debian Security Advisory, DSA)
Dies sind von Debians Sicherheits Team (siehe Unten) gesendete Informationen über die Verfügbarkeit der Korrektur einer sicherheitsrelevanten Verwundbarkeit für das Debian Betriebs
System. Digital unterschriebene DSAs werden auf eine öffentliche Mailing-Liste gesendet und
auf Debians Web-Seite veröffentlicht (sowohl auf der Hauptseite als auch unter Sicherheitsinformationen (http://www.debian.org/security/)).
DSAs enthalten Informationen über beeinträchtigte Pakete, den entdeckten Fehler und wie
man aktualisierte Pakete bekommt (und ihre md5-Summen).
11.3.2
129
Die digitale Signatur eines Debian Gutachtens kann nicht korrekt verifiziert werden!
Dies ist wahrscheinlich ein Problem an Ihrem Ende. Die debian-security-announce Liste hat
einen Filter vorgeschaltet, der nur Nachrichten durchlässt, die eine korrekte Signatur von
einem Mitglied des Sicherheits Teams enthält.
Wahrscheinlich verändert irgendeine Mail-Software an Ihrem Ende ein wenig und ruiniert
damit die Unterschrift. Stellen Sie sicher, dass Ihre Software keine MIME-Codierung oder Decodierung, oder Tabulatur/Leerzeichen konvertierung durchführt.
Bekannte Schuldige sind fetchmal (mit eingeschalteter mimedecode Option) und formail
(lediglich von procmail 3.14)
11.3.3
Wie werden Sicherheits-Ereignisse in Debian behandelt?
Sobald das Sicherheits-Team eine Notiz über einen Vorfall erhält, prüfen ihn ein oder mehrere
Mitglieder nach, und erwägen, ob Debian/stable angreifbar ist, oder nicht. Wenn unser System angreifbar ist, wird an einer Korrektur für das Problem gearbeitet. Der Paket-Verwalter
wird ebenfalls kontaktiert, wenn er nicht bereits selbst das Sicherheits-Team kontaktiert hat.
Schliesslich wird die Korrektur getestet und ein neues Paket vorbereitet, die dann auf allen
stabilen Architekturen compiliert wird, die dann anschliessend hoch geladen werden. Nachdem all dies getan ist, wird ein Debian Sicherheits Gutachten (DSA) an die öffentliche Mailing
Liste geschickt.
11.3.4
Wieviel Zeit wird Debian brauchen, um die Angriffsmöglichkeit XXXX zu
reparieren?
Eine Analyse der Zeiten, die Debians Sicherheits-Team benötigt, um ein Gutachten zu veröffentlichen und reparierte Pakete zu produzieren nachdem eine Angriffsmöglichkeit bekannt
wird, zeigt, dass es nicht so lange dauert, die Angriffmöglichkeiten in der stabilen Distribution
zu reparieren.
Ein Report in der debian-security Mail-Liste (http://lists.debian.org/
debian-security/2001/debian-security-200112/msg00257.html) zeigt, dass
im Jahr 2001 Debians Sicherheitsteam durchschnittlich 35 Tage benötigte, um eine sicherheitsrelevante Angriffmöglichkeit zu reparieren. Über 50% der Angriffspunkte wurden jedoch
innerhalb eines Zeitrahmens von 10 Tagen beseitigt, und über 15% von ihnen wirden noch am
gleichen Tag repariert.
Dennoch tendieren Leute, die diese Frage stellen, zu vergessen, dass:
• DSAs nicht verschickt werden bis:
– Pakete für alle von Debian unterstützten Architekturen verfügbar sind (dies braucht
etwas Zeit, wenn es Sich um Pakete handelt, die Teil des System-Kerns sind, beson-
130
ders wenn man die Anzahl der in der stabilen Release unterstützten Architekturen
berüksichtigt).
– Neue Pakete gründlich getestet wurden, um sicher zu stellen, dass keine neuen
Fehler eingeführt werden
• Pakete verfügbar sein können, bevor das DSA verschickt wird (in der incomingWarteschlange oder auf den Spiegeln).
• Debian ein Projekt auf freiwilligen Basis ist.
• Es eine “keine Garantie” Klausel gibt, die Teil der Lizens ist, der Debian unterliegt.
11.3.5
Wie wird Sicherheit für testing und unstable gehandhabt?
Die kurze Antwort ist: Gar nicht. Testing und unstable unterliegem einem rapoden Fluss,
und das Sicherheits-Team hat nicht die benötigten Resourcen, die notwendig wären, um diese
richtig zu betreuen. Wenn Sie einen sicheren (und stabilen) Server haben möchten, sind Sie
stark dazu ermutigt, bei stable zu bleiben.
Aber tatsächlich wird unstable normalerweise relativ schnell repariert, da Sicherheitsupdates
für die aktuelle Version durch den ursprünglichen Autor schnell verfügbar sind (während andere Versionen, wie die in stable, normalerweise einen zurück portiert werden müssen).
11.3.6
Warum gibt es keine offiziellen Spiegel für security.debian.org?
Der Zweck von security.debian.org ist es, Sicherheits-Updates möglichst schnell und einfach zur Verfügung zu stellen. Spiegel würden zusätzliche Komplexität einführen, die nicht
benötigt ist, und nur Frustration erzeugt, wenn Sie nicht aktuell gehalten werden.
11.3.7
Ich habe DSA 100 und DSA 102 gesehen, wo ist aber DSA 101?
Verschiedene Distributoren (zumeist von GNU/Linux, aber auch von BSD-Derivaten) koordinieren Sicherheits-Gutachten für verschiedene Vorfälle und haben vereinbart, einen bestimmten Zeitplan einzuhalten, so dass alle Distributoren in der Lage sind, richtig zu prüfen,
ob Sie betroffen sind (oder nicht) und entsprechende Updates erstellen können.
Das Sicherheits-Team von Debian behält in solchen Fällen die Nummer, bevor das Gutachten
freigegeben wird, und so kann es zeitweise passieren, dass die ein andere Nummer fehlt.
11.3.8
Wie kann ich das Sicherheits-Team erreichen?
Sicherheits Informationen können an security@debian.org geschickt werden, damit es von
allen Debian Entwicklern gelesen wird. Wenn Sie sensitive Informationen haben, benutzen
sie bitte team@security.debian.org, damit es nur vom Security-Team gelesen wird. Wenn Sie
es wünschen, kann die Email auch mit dem Debian Security Contact Key (Key-Id 363CCD95)
verschlüsselt werden.
11.3.9
131
Was ist der Unterschied zwischen security@debian.org und debiansecurity@lists.debian.org?
Wenn Sie eine Nachricht an security@debian.org schicken, wird diese an die Developer Mailingliste geschickte (debian-private), die alle Debian Entwickler aboniert haben. Nachrichten an diese Liste werden vertraulich behandelt (d.h. nicht auf einer öffentlichen Webseite
archiviert). debian-security@lists.debian.org ist eine öffentliche Mail-Liste, offen für jeden, der
sie abonieren möchte, und es gibt ein auf den Web-Seiten ein durchsuchbares Archiv.
11.3.10
Wie kann ich Debians Sicherheit-Team unterstützen?
• Indem Sie zu diesem Dokument beitragen, FIXMEs bearbeiten oder neuen Inhalt beisteuern. Dokumentation ist wichtig und reduziert die Überlast durch beantworten allgemeiner Fragen. Übersetzen dieses Dokuments in andere Sprachen ist auch ein grossartiger Beitrag (Anm.d. Übersetzers: Fehlerbereinigen in der Übersetzung auch).
• Indem Sie Apllikationen paketieren, die nützlich ist, um dir Sicherheit eines Debian Systems zu erhöhen / zu prüfen. Wenn Sie kein Entwickler sind, reichen Sie einen WNPP
bug (http://www.debian.org/devel/wnpp/) ein, und fragen Sie nach Software,
von der Sie glauben, dass Sie nützlich wäre, die aber noch nicht zur Verfügung steht.
• Testen Sie Applikationen in Debian oder helfen Sie Sicherheits-Lücken zu schliessen und
teilen Sie Probleme security@debian.org mit. Anderer Projekte Arbeit, wie das Linux Kernel Security Audit Project (http://kernel-audit.sourceforge.net/) oder das
Linux Security-Audit Project (http://www.lsap.org/) erhöhen auch die Sicherheits
von Debian GNU/Linux, da Beitraäge dort, letzten Endes auch hier helfen.
Prüfen Sie bitte in jedem Fall nach, bevor Sie etwas an security@debian.org melden. Wenn
Sie Patches beifügen können, würde das den Prozess natürlich beschleunigen. Leiten Sie nicht
einfach bugtraq Mails weiter, da Sie bereits empfangen werden. Es ist aber eine gute Idee,
zusätzliche Informationen zu schicken.
11.3.11
Aus wem setzt sich das Sicherheits-Team zusammen?
Debians Sicherheit Team besteht derzeit aus fünf Mitgliedern und zwei Sekretären. Das Sicherheits Team lädt Personen selbst ein, beizutreten.
11.3.12
Prüft Debians Sicherheit Team jedes Paket in Debian?
Nein, weder prüft Debians Sicherheit Team jedes neue Paket noch gibt es einen automatischen
(lintian) Test, um böshafte neue Pakete zu entdecken, da solche Dinge praktisch unmöglich
automatisch zu erkennen sind. Paket-Verwalter sind jedoch voll und ganz verantwortlich für
die Software, die in Debian eingeführt wird, und keine Software wird eingeführt, die nicht
zuerst von einem autorisierten Entwickler signiert worden sind. Sie sind dafür verantwortlich
die Software, die sie verwalten, zu analysieren und auf Sicherheit zu achten.
11.3.13
132
Ich habe eine ältere Version von Debian. Wird sie in Bezug auf Sicherheit
noch unterstützt?
Leider nein. Debians Sicherheit-Team kann nicht leider nicht sowohl die stabile Release (inoffiziell also auch unstable) als auch ältere Releases unterstützen. Sie können jedoch SicherheitsUpdates für einen begrenzten Zeitraum (normalerweise mehrere Monate), nachdem eine neue
Debian Distribution veröffentlicht wurde, erwarten.
133
Anhang A
Der Abhärtungsprozess Schritt für
Schritt
Eine Prozedur ist immer nützlich, da Sie Ihnen erlaubt, den gesamten Prozess des Abhärtens
eines Systems zu betrachten und Ihnen erlaubt Entscheidungen zu treffen. Ein möglicher
Versuch für eine solche Prozedur für Debian 2.2 GNU/Linux ist unten aufgeführt. Es ist
eine Nach-Installations Prozedur. Eine Checkliste von Massnahmen, die sie schritt für Schritt
während der Konfiguration durchführen finden Sie unter ‘Konfigurations Checkliste’ auf
Seite 137. Ausserdem ist diese Prozedur (im Augenblick) eher am Absichern von Netzwerk
Servicen orientiert.
• Führen Sie eine Installation auf dem System durch (beachten Sie dabei die Informationen
dieser HowTo bezügliche Partitionierung). Nach der Basis-Installation nehmen Sie eine
angepasste Installation vor, wählen Sie keine Task-Pakete aus, aber aktivieren Sie shadow
passwords.
• Gehen Sie durch dselect und entfernen Sie alle nicht benötigten aber ausgewählten
Pakete bevor sie [I]nstallation wählen. Lassen Sie nur absolut notwendige Software auf
dem Server.
• Aktualisieren Sie alle Software von den aktuellen Paketen auf security.debian.org wie
bereits unter ‘Ausführen von Sicherheitsupdates’ auf Seite 39 beschrieben.
• Implementieren Sie die in dieser Anleitung vorgeschlagenen Massnahmen über User
Quota, Login Definitionen und Lilo.
• Um das abhärten aller Services vorzubereiten, machen Sie eine Liste von allen Servicen,
die derzeit auf Ihrem System arbeiten.
$ ps -aux
$ netstat -pn -l -A inet
# /usr/sbin/lsof -i | grep LISTEN
Kapitel A. Der Abhärtungsprozess Schritt für Schritt
134
Damit das dritte Kommando funktionier werden Sie lsof-2.2 installieren müssen (uns
es als root laufen lassen). Beachten Sie, dass lsof das Wort LISTEN passend zu Ihrer
Lokalisation übersetzen kann.
• Um unnötige Services zu entfernen, stellen Sie zunächst fest, wie er gestartet wird, und
welches Paket ihn zur Verfügung stellt. Sie können dies ganz einfach machen, indem
Sie das Programm prüfen, dass auf einen Socket achtet. Das nachfolgende Beispiel wird
Ihnen zeigen, wie man diese Tolls und dpkg dazu benutzt:
#!/bin/sh
# FIXME: Dies ist nur schnelle und einfache zusammengehackt, und sollte
# durch einen robusteren Skript-Schnipsel ersetzt werden
for i in ‘sudo lsof -i | grep LISTEN | cut -d " " -f 1 |sort -u‘ ; do
pack=‘dpkg -S $i |grep bin |cut -f 1 -d : | uniq‘
echo "Service $i ist durch $pack installiert";
init=‘dpkg -L $pack |grep init.d/ ‘
if [ ! -z "$init" ]; then
echo "und wird durch $init gestartet"
fi
done
• Wenn Sie ungewünschte Services finden, entfernen Sie das Paket (mit dpkg -purge)
oder, wenn er nützlich ist aber nicht beim Starten aktiviert werden soll, benutzen Sie
update-rc.d (siehe ‘Daemon-Services abschalten’ auf Seite 27), um den ihn aus dem
Start-Prozess zu entfernen.
• Für inetd Services (durch den Superdaemon gestartet) können Sie einfach dei aktivierten
Services prüfen, zum Beispiel mit:
$ grep -v "^#" /etc/inetd.conf | sort -u
und deaktivieren Sie diejenigen, die Sie nicht benötigen, indem Sie die Zeile auskommentieren, das Paket entfernen, oder indem Sie update-inetd benutzen.
• Wenn Sie Services eingehüllt haben (und /usr/sbin/tcpd benutzen) prüfen Sie, ob
/etc/hosts.allow und /etc/hosts.deny passend zu Ihrer Service-Regelung konfiguriert sind.
• Wenn möglich, und abhängig von jedem Service, möchten Sie vielleicht die Services
limitieren, wenn Sie mehrere externe Schnittstellen benutzen, damit sie nur auf eines
davon achten. Wenn Sie zum Beispiel internen FTP-Zugriff erlauben, lassen Sie den FTPDaemon nur auf diese Schnittstelle achten, nicht auf alle (d.h. 0.0.0.0:21).
• Booten Sie die Maschine neu, oder wechseln Sie in den Single-User Modus und zurück
in den Multi-User Modus mit:
135
$ init 1
(....)
$ init 2
• Prüfen Sie die nun angebotenen Services und wiederholen Sie die letzten Schritte falls
nötig.
• Installieren Sie jetzt die benötigten Services, falls es noch nicht geschehen ist, und konfigurieren Sie sie passend.
• Prüfen Sie, welche User benutzt werden, um angebotenen Services zu starten, zum
Biespiel mit:
$ for i in ‘/usr/sbin/lsof -i |grep LISTEN |cut -d " " -f 1 |sort -u‘;
user=‘ps -ef |grep $i |grep -v grep |cut -f 1 -d " "‘ ; echo "Service $
laeuft als Benutzer $user"; done
und überlegen Sie, ob Sie diese Services zu einem bestimmten User / einer bestimmten
Gruppe ändern wollen und Sie vielleicht auch in eine chroot-Umgebung packer wollen,
um die Sicherheit zu erhöhen. Sie können dies tun, indem Sie die /etc/init.d
Skripte ändern, die den Service starten. Die meisten Services benutzen unter Debian
start-stop-daemon, so dass Sie einfach die –change-uid und –chroot Optionen benutzen können, um diese Services aufzusetzen. Das einpacken eines Services in eine
Chroot-Umgebung würde den Rahmen dieses Dokumentes sprengen, aber ein paar warnende Worte sind nötig: Sie werden wahrscheinlich alle Dateien, die durch das Paket des
Services installiert wurden, unter Benutzung von dpkg -L und der Pakete, von denen es
abhängt, in die Chroot-Umgebung legen müssen.
• Wiederholen Sie die oberen Schritte, um zu prüfen, ob nur die gewünschten Services
laufen und ob sie unter der gewünschten User/Gruppen Kombination laufen.
• Testen Sie die installieren Services, um zu festzustellen, ob Sie wie erwartet arbeiten.
• Checken Sie das System, indem Sie einen Verwundbarkeits-Abschätzungs-Scanner (zum
Beispiel nessus) benutzen, um Angriffmöglichkeiten (Fehlkonfigurationen, alte oder
nicht benötigte Services) zu finden.
• Installieren Sie Netzwerk-Eindringlings-Massnahmen
Massnahmen (wie snort und logsentry).
und
Host-Eindringlings-
• Wiederholen Sie den Netzwerk-Scan und prüfen Sie, ob das Eindringslings-ErkennungsSystem funktioniert.
Dir richtig Paranoiden überlegen sich auch das folgende:
• fügen Sie dem Systen Firewall Fähigkeiten hinzu, die eingehende Verbindungen nur
zu angebotenen Services erlauben und ausgehende Verbindungen auf authorisierte
beschränkt.
136
• Überprüfen Sie erneut die Installation auf Angriffspunkte mit einem Netzwerk Scanner.
• Prüfen Sie ausgehende Verbindungen vom System zu Hosts ausserhalb mit einem
Netzwerk-Scanner, um sicherzustellen, dass ungewollte Verbindungen keinen Weg nach
draussen finden.
FIXME: this procedure considers service hardening but not system hardening at the user level,
include information regarding checking user permissions, setuid files and freezing changes in
the system using the ext2 filesystem.
137
Anhang B
Konfigurations Checkliste
Dieser Anhang Anhang wiederholt kurz Punkte aus anderen Abschnitten dieser Anleitung
in einem verdichteten Checklisten Format. Er ist als schnelle Zusammenfassung für Leute
gedacht, die bereits diese Anleitung gelesen haben. Es gibt auch andere Checklisten, Kurt
Seifried hat eine basierend auf dem Kurs Securing Linux Step by Step (http://seifried.
org/security/os/linux/20020324-securing-linux-step-by-step.html) aufgesetzt.
FIXME: This is based on v1.4 of the manual and might need to be updated.
• Schränkgen Sie physischen Zugriff und Boot-Fähigkeiten ein.
– Setzen Sie ein BIOS-Passwort
– Schalten Sie das Booten von Diskette, CD-ROM, . . . ab
– Setzen Sie ein LILO bzw. GRUB Passwort (/etc/lilo.conf bzw. /boot/grub
/menu.lst); prüfen Sie, dass die LILO oder GRUB Konfigurationen nicht einsehbar ist
– Verhindern Sie die Hintertür des Bootens von Diskette durch den MBR, indem Sie
den MBR überschreiben (vielleicht nicht?)
• Parttionierung
– Separieren Sie User-schreibbare Daten, nicht-System Daten und sich ständig ändernde Laufzeit Daten auf ihre eigenen Partitionen
– Setzen Sie nosuid,noexec,nodev Mount-Optionen in die /etc/fstab bei ext2Partitionen, wie zum Beispiel /tmp.
• Passwort-Hygiene und Login-Sicherheit
– Setzen Sie ein gutes Root-Passwort
– Benutzen Sie Shadow- und MD5-Passwords
Kapitel B. Konfigurations Checkliste
138
– Installieren und benutzen Sie PAM
* Fügen Sie PAM MD5 Support hinzu, und stellen Sie sicher (allgemein
gesprochen) dass die Einträge in den /etc/pam.d/ Dateien, die Zugriff auf
die Maschine gewähren, das zweite Feld in der pam.d-Datei auf “requisite”
oder “required” gesetzt haben.
* Ändern Sie /etc/pam.d/login, so dass es nur lokale Root-Logins erlaubt.
* Markieren Sie ausserdem authorisierte ttys in /etc/security
/access.conf und setzen Sie diese Datei überhaupt so auf, dass RootLogins so weit wie möglich eingeschränkt werden.
* Fügen Sie pam_limits.sp hinzu, wenn Sie pro User Einschränkungen
vornehmen wollen.
* Ändern Sie /etc/pam.d/passwd: Setzen Sie die minimum Länge von Passworten hoch (vielleicht sechs Zeichen) und schalten Sie md5 ein.
Wenn
Sie es wünschen, fügen Sie /etc/group die Gruppe wheel hinzu; fügen
*
Sie /etc/pam.d/su pam_whell.so group=wheel hinzu.
* For angepasste pro-User Kontrollen, benutzen Sie pam_listfile.so Einträge, wo
es passt.
* Erstellen Sie eine Datei /etc/pam.d/other und setzen Sie sie mit strenger
Sicherheit auf.
– Setzen Sie in /etc/security/limits.conf Schranken (beachten Sie, dass /etc
/limits nicht benutzt wird, wenn Sie PAM benutzen).
– Festigen Sie /etc/login.defs; wenn Sie MD5 und/oder PAM einschalten
machen Sie auch hier ebenfalls die gleichbedeutenden Änderungen.
– Schalten Sie root FTP-Zugriff in /etc/ftpusers ab.
– Schalten Sie Root-Login übers Netzwerk ab; benutzen Sie su(1) oder sudo(1)
(überlegen Sie die Installation von sudo).
– Benutzen Sie PAM, um zusätzliche Auflagen auf Logins zu ermöglichen.
• Andere Lokale Sicherheits Sachen:
– Kernel Tweaks (siehe ‘Konfigurieren der Netzwerk-Fähigkeiten des Kernels’ auf
Seite 56)
– Kernel Patches (siehe ‘nützliche Kernel-Patches’ auf Seite 108)
– Festigen der Zugriffsrechte auf Log-Dateien (/var/log/{last,fail}log,
Apache Logs)
– Verifizieren Sie, dass in /etc/checksecurity.conf setuid Checks eingeschaltet
sind.
– Überlegen Sie sich, an Log-Dateien nur anhängen zu lassen (append-only) und
Konfigurations-Dateien unveränderbar (immutable) zu machen, indem Sie chattr
benutzen (nur ext2 Dateisystem)
– Setzen Sie Datei-Integritäts-Test aus (siehe ‘Prüfen der Integrität des Dateisystems’
auf Seite 63). Installieren Sie debsums.
139
– Überlegen Sie, locate durch slocate zu ersetzen.
– Alles auf einem lokalen Drucker mitloggen?
– Brennen Ihrer Konfiguration auf eine bootbare CD und hier von booten?
– Abschalten von Kernel-Modulen?
• Beschränken von Netzwerk Zugriff
– Installieren und konfigurieren Sie ssh (Vorschlag: PermitRootLogin No in /etc
/ssh/sshd_config, PermitEmptyPasswords No; beachten Sie auch die anderen
Vorschläge im Text).
– Überlegen Sie, ob Sie telnetd abschalten (in /etc/inetd.conf, benutzen Sie
update-inetd --disable (oder schalten Sie inetd ganz ab, oder benutzen Sie
einen Ersatz wie xinetd oder rlinetd)) oder entfernen.
– Schalten Sie andere überflüssig Netzwerk Services ab; mail, ftp, DNS, www usw.
sollten nicht laufen, wenn Sie sie nicht brauchen und nicht regelmässig überwachen.
– Bei den Servicen, die Sie brauchen, installieren Sie nicht die weitverbreitesten Programme, sondern schauen Sie für sicherere Versionen, die Debian liefert (oder aus
anderen Quellen). Was auch immer Sie schliesslich benutzen: Gehen Sie sicher, dass
Sie die Risiken verstanden haben.
– Setzen Sie Chroot-Umgebungen für äusswärtige User und Daemonen auf
– Konfigurieren Sie Firewall und tcp-Wrapper (d.h. hosts_access(5)); beachten
Sie den Trick für /etc/hosts.deny im Text.
– Wenn Sie FTP laufen lassen, setzen Sie den ftpd-Server so auf, dass er immer als
chroot im Heimat-Verzeichnis des Users läuft.
– Wenn Sie X laufen lasen, schalten Sie xhost authentifizierung ab und benutzen Sie
stattdessen ssh; oder noch besser. Ignorieren Sie weitergeleitete X komplett, wenn
Sie können (hinzufügen von -nolisten tcp zu der X Kommando-Zeile und schalten
Sie XDMCP in /etc/X11/xdm/xdm-config ab, indem Sie den requestPort auf 0
setzen)
– Schalten Sie Zugriff von Ausserhalb auf den Drucker ab
– Tunneln Sie alle IMAP Oder POP Sitzungen durch SSL oder SSH; installieren Sie
stunnel, wenn Sie diesen Service anderen Mail-Usern anbieten wollen
– Setzen Sie einen Log-Host auf, und konfigurieren Sie andere Maschinen, ihre Logs
an diesen Host zu senden (/etc/syslog.conf)
– Sichern Sie BIND, Sendmail und andere komplexe Daemonen (starten in einer
chroot-Umgebung; starten als nicht-Root pseudo-User)
– Installieren Sie snort oder ein ähnliches Überwachungs Tools)
– Verzichten Sie, falls möglich, auf NIS Und RPC (abschalten von portmap).
• Policy Angelegenheiten
140
– Klären Sie die User über das Warum und Wie Ihrer Regelungen auf. Wenn Sie etwas
verboten haben, dass auf anderen Systemen normalerweise verfügbar ist, stellen Sie
Dokumentation bereit, die erklärt, wie man gleiche Resultate erreicht, indem man
andere, sichere Mittel anwendet.
– Verbieten Sie die Nutzung von Protokollen, die Klartext Passwörtet benutzen (telnet, rsh und Freunde, ftp, imap, pop, http, . . . ).
– Verbieten Sie Programme, die SVGAlib benutzen.
– Benutzen Sie Disk-Quotas.
• Bleiben Sie über Sicherheits Angelegenheiten informiert
– Abonieren Sie sicherheits relevante Mailing-Listen
– Abonieren Sie sicherheits Updates – fügen Sie /etc/apt/sources.list einen
Eintrag (oder Einträge) für http://security.debian.org/debian-security
– Erinnern Sie sich auch regelmässig apt-get update ; apt-get upgrade
(vielleicht per Cron-Job?) wie unter ‘Ausführen von Sicherheitsupdates’ auf Seite 39
beschrieben laufen zu lassen.
141
Anhang C
Aufsetzen eines autonomen IDS
Sie können sehr leicht eine Debian-Box als eigenständiges Eindringlings-Erkennungs-System
(Intrusion Detection System, IDS) aufsetzen, wen Sie snort benutzen.
Ein paar Richtlinien:
• Installieren Sie ein Debian Basis-System ohne zusätzliche Pakete.
• Laden Sie notwendige Pakete (siehe die Liste der installierten Pakete weiter unten)
manuell herunter und installieren Sie sie (mit dpkg)
• Laden Sie ACID (Analysis Console for Intrusion Databases, Analyse Konsole für Eindringling Datenbanken) herunter und installieren Sie es
ACID wird derzeit mit acidlab für Debian paketiert, und stellt eine graphische WWW
Schnittstelle zur Ausgabe von Snort zur verfügung. Es kann von http://www.cert.
org/kb/acid/, http://acidlab.sourceforge.net oder http://www.andrew.cmu.
edu/~rdanyliw/snort/ heruntergeladen werden. Sie möchten vielleicht die Snort
Statistics HOWTO (http://www.linuxdoc.org/HOWTO/Snort-Statistics-HOWTO/
index.html) lesen.
Dieses System sollte mit wenigstens Zwei Netzwerk-Schnittstellen ausgestatten sein: Eine mit
dem Verwaltungs-LAN verbunden (um die Resultate abzufragen und das System zu verwalten), und eines ohne ip-Adresse, das an mit dem zu beobachtenden Netzwerk-Segment verbunden ist.
Sie können normalerweise nicht die standard Debian Datei /etc/network/interfaces benutzen, um die Netzwerk-Karten zu konfigurieren, da ifup und ifdown mehr Informationen
erwarten, als benötigt werden. Benutzen Sie einfach ifconfig ethX up.
Abgesehen von der standard Debian installation benötigen Sie Apache, MySQL und PHP4
damit ACID funktioniert. Laden Sie die Pakete herunter (Beachten Sie: Die Versionen können
abhängig von der verwendeten Debian Distribution variieren, diese sind von Debian Woody
September 2001):
Kapitel C. Aufsetzen eines autonomen IDS
ACID-0.9.5b9.tar.gz
adduser_3.39_all.deb
apache-common_1.3.20-1_i386.deb
apache_1.3.20-1_i386.deb
debconf_0.9.77_all.deb
dialog_0.9a-20010527-1_i386.deb
fileutils_4.1-2_i386.deb
klogd_1.4.1-2_i386.deb
libbz2-1.0_1.0.1-10_i386.deb
libc6_2.2.3-6_i386.deb
libdb2_2.7.7-8_i386.deb
libdbd-mysql-perl_1.2216-2_i386.deb
libdbi-perl_1.18-1_i386.deb
libexpat1_1.95.1-5_i386.deb
libgdbmg1_1.7.3-27_i386.deb
libmm11_1.1.3-4_i386.deb
libmysqlclient10_3.23.39-3_i386.deb
libncurses5_5.2.20010318-2_i386.deb
libpcap0_0.6.2-1_i386.deb
libpcre3_3.4-1_i386.deb
libreadline4_4.2-3_i386.deb
libstdc++2.10-glibc2.2_2.95.4-0.010703_i386.deb
logrotate_3.5.4-2_i386.deb
mime-support_3.11-1_all.deb
mysql-client_3.23.39-3_i386.deb
mysql-common_3.23.39-3.1_all.deb
mysql-server_3.23.39-3_i386.deb
perl-base_5.6.1-5_i386.deb
perl-modules_5.6.1-5_all.deb
perl_5.6.1-5_i386.deb
php4-mysql_4.0.6-4_i386.deb
php4_4.0.6-1_i386.deb
php4_4.0.6-4_i386.deb
snort_1.7-9_i386.deb
sysklogd_1.4.1-2_i386.deb
zlib1g_1.1.3-15_i386.deb
Installierte Pakete (dpkg -l):
ii
ii
ii
ii
ii
ii
adduser
ae
apache
apache-common
apt
base-config
3.39
962-26
1.3.20-1
1.3.20-1
0.3.19
0.33.2
142
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
base-files
base-passwd
bash
bsdutils
console-data
console-tools
console-toolscron
debconf
debianutils
dialog
diff
dpkg
e2fsprogs
elvis-tiny
fbset
fdflush
fdutils
fileutils
findutils
ftp
gettext-base
grep
gzip
hostname
isapnptools
joe
klogd
ldso
libbz2-1.0
libc6
libdb2
libdbd-mysql-p
libdbi-perl
libexpat1
libgdbmg1
libmm11
libmysqlclient
libncurses5
libnewt0
libpam-modules
libpam-runtime
libpam0g
libpcap0
libpcre3
libpopt0
2.2.0
3.1.10
2.03-6
2.10f-5.1
1999.08.29-11.
0.2.3-10.3
0.2.3-10.3
3.0pl1-57.2
0.9.77
1.13.3
0.9a-200105272.7-21
1.6.15
1.18-3.0
1.4-11
2.1-6
1.0.1-5
5.3-3
4.1-2
4.1-40
0.10-3.1
0.10.35-13
2.4.2-1
1.2.4-33
2.07
1.21-2
2.8-15.2
1.4.1-2
1.9.11-9
1.0.1-10
2.2.3-6
2.7.7-8
1.2216-2
1.18-1
1.95.1-5
1.7.3-27
1.1.3-4
3.23.39-3
5.2.20010318-2
0.50-7
0.72-9
0.72-9
0.72-9
0.6.2-1
3.4-1
1.4-1.1
143
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
ii
libreadline4
libssl09
libstdc++2.10
libstdc++2.10libwrap0
lilo
locales
login
makedev
mawk
mbr
mime-support
modutils
mount
mysql-client
mysql-common
mysql-server
ncurses-base
ncurses-bin
netbase
passwd
pciutils
perl
perl-base
perl-modules
php4
php4-mysql
ppp
pppconfig
procps
psmisc
pump
sed
setserial
shellutils
slang1
snort
ssh
sysklogd
syslinux
sysvinit
tar
tasksel
tcpd
telnet
textutils
4.2-3
0.9.4-5
2.95.2-13
2.95.4-0.01070
7.6-4
21.4.3-2
2.1.3-18
19990827-20
2.3.1-46.2
1.3.3-5
1.1.2-1
3.11-1
2.3.11-13.1
2.10f-5.1
3.23.39-3
3.23.39-3.1
3.23.39-3
5.0-6.0potato1
5.0-6.0potato1
3.18-4
19990827-20
2.1.2-2
5.6.1-5
5.6.1-5
5.6.1-5
4.0.6-4
4.0.6-4
2.3.11-1.4
2.0.5
2.0.6-5
19-2
0.7.3-2
3.02-5
2.17-16
2.0-7
1.3.9-1
1.7-9
1.2.3-9.3
1.4.1-2
1.48-2
2.78-4
1.13.17-2
1.0-10
7.6-4
0.16-4potato.1
2.0-2
144
ii
ii
ii
update
util-linux
zlib1g
2.11-1
2.10f-5.1
1.1.3-15
145
146
147
Anhang D
Aufsetzen einer Überbrückenden
Firewall (bridge Firewall)
Diese Informationen trug Francois Bayart bei, um User zu helfen, eine Linux Bridge / Firewall
mit 2.4.x Kernel und iptables aufzusetzen. Es wird lediglich noch der Bridge-Firewall-Patch
benötigt, den Sie auf der sourceforge download page (http://bridge.sourceforge.
net/download.html) finden.
Wenn Sie zum Beispiel einen 2.4.18er Kernel benutzen, müsen Sie den entsprechenden patch (http://bridge.sourceforge.net/devel/bridge-nf/bridge-nf-0.0.
6-against-2.4.18.diff) herunterladen und anschliessend auf die installierten KernelQuellen anwenden:
Zipowz:/usr/src# apt-get install kernel-source-2.4.18
Zipowz:/usr/src# cd kernel-source-2.4.18
Zipowz:/usr/src/kernel-source-2.4.18# patch -p1 < ../bridge-nf-0.0.6-against-2
patching file include/linux/netfilter.h
patching file include/linux/netfilter_ipv4.h
patching file include/linux/skbuff.h
patching file net/bridge/br.c
patching file net/bridge/br_forward.c
patching file net/bridge/br_input.c
patching file net/bridge/br_netfilter.c
patching file net/bridge/br_private.h
patching file net/bridge/Makefile
patching file net/Config.in
patching file net/core/netfilter.c
patching file net/core/skbuff.c
patching file net/ipv4/ip_output.c
patching file net/ipv4/netfilter/ip_tables.c
patching file net/ipv4/netfilter/ipt_LOG.c
Kapitel D. Aufsetzen einer Überbrückenden Firewall (bridge Firewall)
148
Jetzt rufen Sie die Kernel-Konfiguration auf (mit Ihrer lieblings Methode: make menuconfig,
make xconfig, . . . ). Aktivieren Sie diese Optionen unter Networking option:
[*] Network packet filtering (replaces ipchains)
[ ]
Network packet filtering debugging (NEW)
<*> 802.1d Ethernet Bridging
[*]
netfilter (firewalling) support (NEW)
Passen Sie auf, dass Sie dieses hier deaktiviert haben, wenn Sie Firewall-Regeln anwenden
wollen, oder iptables funktioniert nicht.
[ ]
Network packet filtering debugging (NEW)
Anschliessend müssen Sie die korrekten Optionen im Abschnitt IP: Netfilter Configurationsetzen. Dann kompilieren und installieren Sie den Kernel. Wenn Sie dies auf die Debian
Art machen wollen, installieren Sie kernel-package und benutzen Sie make-kpkg um
ein neues Debian Paket zu erstellen, das Sie auf Ihrem Server installieren können (oder auf
einem anderen System benutzen können). Sobald der neue Kernel kompiliert und installiert
ist, müssen Sie die bridge-utils installieren.
Jetzt können Sie zwei verschiedene Konfigurationen betrachten, die Ihnen zeigen, wie sie das
konfigurieren können, sobald diese Schritte erledigt sind. Beide Konfigurationen sind mit einer
Netzwerk-Karte und den notwendigen Kommandos zur konfiguration der Bridge aufgeführt.
D.1
Eine Bridge mit NAT- und Firewall-Fähigkeiten
Die erste benutzt eine Bridge als Firewall mit Network Address Translation (NAT), die einen
Server und interne LAN-Clienten schützt.
Internet ----- router ( 62.3.3.25 ) ----- bridge ( 62.3.3.26 gw 62.3.3.25 / 19
|
|
|---- WWW-Server ( 62.3.3.27 gw 62
|
|
LAN --- Zipowz ( 192.168.0.2 gw 192
Diese Kommandos zeigen, wie die Bridge konfiguriert werden kann:
# So wird die Schnittstelle br0 erstellt:
/usr/sbin/brctl addbr br0
# Hinzufügen der Ethernet-Schnittstellen, die die Bridge benutzen
149
# soll
/usr/sbin/brctl addif br0 eth0
# Die Schnittstellen einfach starten
/sbin/ifconfig eth0 0.0.0.0
#
#
#
#
#
#
Konfigurieren der Ethernet-Bridge
Die Bridge wird korrekt und unsichtbar (transparente Firewall) sein.
In einem traceroute ist Sie versteckt, und Sie behalten Ihr echtes
Gateway auf Ihren anderen Computern. Jetzt können Sie ein Gateway
auf Ihrer Bridge konfigurieren und es auf Ihren anderen Computern als
neues Gateway einsetzen
/sbin/ifconfig br0 62.3.3.26 netmask 255.255.255.248 broadcast 62.3.3.32
# Ich habe benutze diese internen IPs für mein NAT
ip addr add 192.168.0.1/24 dev br0
/sbin/route add default gw 62.3.3.25
D.2
Eine Bridge mit Firewall Fähigkeiten
Dieses System ist als transparente Firewall für ein LAN mit öffentlichen IP-Addressen aufgesetzt.
Internet ----- router ( 62.3.3.25 ) ----- bridge ( 62.3.3.26 )
|
|
|---- WWW Server ( 62.3.3.28 gw 62
|
|
|---- Mail Server ( 62.3.3.27 gw 6
Diese Kommandos zeigen, wie die Bridge konfiguriert werden kann:
# So wird die Schnittstelle br0 erstellt:
/usr/sbin/brctl addbr br0
# Hinzufügen der Ethernet-Schnittstellen, die die Bridge benutzen
# soll
150
# Die Schnittstellen einfach starten
#
#
#
#
#
#
Konfigurieren der Ethernet-Bridge
Die Bridge wird korrekt und unsichtbar (transparente Firewall) sein.
In einem traceroute ist Sie versteckt, und Sie behalten Ihr echtes
Gateway auf Ihren anderen Computern. Jetzt können Sie ein Gateway
auf Ihrer Bridge konfigurieren und es auf Ihren anderen Computern als
neues Gateway einsetzen
/sbin/ifconfig br0 62.3.3.26 netmask 255.255.255.248 broadcast 62.3.3.32
Wenn Sie traceroute auf den Linux-Mail-Server schicken, sehen Sie die Bridge nicht, wenn Sie
mit ssh auf die Bridge zugreifen wollen, müssen Sie ein Gateway haben, oder erst auf einen
anderen Server, wie den “Mail Server”, zugreifen um dann über die interne Netzwerkkarte
auf die Bridge zuzugreifen.
D.3
grundlegende Iptables-Regeln
Dies ist ein Beispiel für grundlegende Regeln, die für beide Beispiele benutzt werden könnten:
iptables
iptables
iptables
iptables
#
#
#
#
#
#
-F
-P
-A
-A
FORWARD
FORWARD DROP
FORWARD -s 0.0.0.0/0.0.0.0 -d 0.0.0.0/0.0.0.0 -m state --state INV
FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
Zwei lustige Regeln, aber nicht bei klassischen Iptables. Sorry ...
Limit ICMP
iptables -A FORWARD -p icmp -m limit --limit 4/s -j ACCEPT
Uebereinstimmende Strings, eine gute, einfache Methode, um Viren sehr
schnell abzublocken
iptables -I FORWARD -j DROP -p tcp -s 0.0.0.0/0 -m string --string "cmd.exe"
# Abblocken aller MySQL Verbindingen, nur um ganz sicher zu gehen
iptables -A FORWARD -p tcp -s 0/0 -d 62.3.3.0/24 --dport 3306 -j DROP
# Regeln für den Linux Mail Server
#
# Erlaube FTP-DATA ( 20 ) , FTP ( 21 ) , SSH ( 22 )
iptables -A FORWARD -p tcp -s 0.0.0.0/0 -d 62.3.3.27/32 --dport 20:22 -j ACCEP
151
# Dem Mail-Server erlauben, sich mit der Aussenwelt zu verbinden
# Beachten Sie: Dies ist *nicht* fuer die vorherigen Verbindungen
# notwendig (Erinnern Sie sich: stateful filtering) und koennte entfernt
# werden:
iptables -A FORWARD -p tcp -s 62.3.3.27/32 -d 0/0 -j ACCEPT
# Regeln fuer den WWW-Server
#
# Erlaube HTTP ( 80 ) Verbindungen mit dem WWW-server
iptables -A FORWARD -p tcp -s 0.0.0.0/0 -d 62.3.3.28/32 --dport 80 -j ACCEPT
# Erlaube HTTPS ( 443 ) Verbindungen mit dem WWW-server
iptables -A FORWARD -p tcp -s 0.0.0.0/0 -d 62.3.3.28/32 --dport 443 -j ACCEPT
# Dem WWW-Server erlauben, sich mit der Aussenwelt zu verbinden
# Beachten Sie: Dies ist *nicht* fuer die vorherigen Verbindungen
# notwendig (Erinnern Sie sich: stateful filtering) und koennte entfernt
# werden:
iptables -A FORWARD -p tcp -s 62.3.3.28/32 -d 0/0 -j ACCEPT
152
153
Anhang E
Beispiel Skript, um die standard
Installation von Bind zu ändern
Dieses Skript automatisiert die Prozedur, die standard Installation des Name-Server zu ändern,
so dass er nicht als Superuser läuft. Benutzen Sie es vorsichtig, da es nicht ausreichend getestet
wurde. Dieses Skript wird auch den User und die Gruppe für den Name-Server erstellen.
#!/bin/sh
# Change the default Debian bind configuration to have it run
# with a non-root user and group.
#
# WARN: This script has not been tested throughly, please
# verify the changes made to the INITD script
# (c) 2002 Javier Fernandez-Sanguino Peña
#
#
This program is free software; you can redistribute it and/or modify
#
it under the terms of the GNU General Public License as published by
#
the Free Software Foundation; either version 1, or (at your option)
#
any later version.
#
#
This program is distributed in the hope that it will be useful,
#
but WITHOUT ANY WARRANTY; without even the implied warranty of
#
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
#
GNU General Public License for more details.
#
#
Please see the file ‘COPYING’ for the complete copyright notice.
#
restore() {
# Just in case, restore the system if the changes fail
echo "WARN: Restoring to the previous setup since I’m unable to properly chan
Kapitel E. Beispiel Skript, um die standard Installation von Bind zu ändern
154
echo "WARN: Please check the $INITDERR script."
mv $INITD $INITDERR
cp $INITDBAK $INITD
}
USER=named
GROUP=named
INITD=/etc/init.d/bind
INITDBAK=$INITD.preuserchange
INITDERR=$INITD.changeerror
START="start-stop-daemon --start --quiet --exec /usr/sbin/named -- -g $GROUP AWKS="awk ’ /start-stop-daemon --start/ { print \"$START\"; noprint = 1; }; /\
[ ‘id -u‘ -ne 0 ] && {
echo "This program must be run by the root user"
exit 1
}
RUNUSER=‘ps -eo user,fname |grep named |cut -f 1 -d " "‘
if [ "$RUNUSER" = "$USER" ]
then
echo "WARN: The name server running daemon is already running as $USER"
echo "ERR: This script will not many any changes to your setup."
exit 1
fi
if [ ! -f $INITD ]
then
echo "ERR: This system does not have $INITD (which this script tries
RUNNING=‘ps -eo fname |grep named‘
[ -z "$RUNNING" ] && \
echo "ERR: In fact the name server daemon is not even running (is it ins
echo "ERR: No changes will be made to your system"
exit 1
fi
# Check if named group exists
if [ -z "‘grep $GROUP /etc/group‘" ]
then
echo "Creating group $GROUP:"
addgroup $GROUP
else
echo "WARN: Group $GROUP already exists. Will not create it"
fi
# Same for the user
155
if [ -z "‘grep $USER /etc/passwd‘" ]
then
echo "Creating user $USER:"
adduser --system --home /home/$USER \
--no-create-home --ingroup $GROUP \
--disabled-password --disabled-login $USER
else
echo "WARN: The user $USER already exists. Will not create it"
fi
# Change the init.d script
# First make a backup (check that there is not already
# one there first)
if [ ! -f $INITDBAK ]
then
cp $INITD $INITDBAK
fi
# Then use it to change it
cat $INITDBAK |
eval $AWKS > $INITD
echo "WARN: The script $INITD has been changed, trying to test the changes."
echo "Restarting the named daemon (check for errors here)."
$INITD restart
if [ $? -ne 0 ]
then
echo "ERR: Failed to restart the daemon."
restore
exit 1
fi
RUNNING=‘ps -eo fname |grep named‘
if [ -z "$RUNNING" ]
then
echo "ERR: Named is not running, probably due to a problem with the changes.
restore
exit 1
fi
# Check if it’s running as expected
RUNUSER=‘ps -eo user,fname |grep named |cut -f 1 -d " "‘
if [ "$RUNUSER" = "$USER" ]
156
then
echo "All has gone well, named seems to be running now as $USER."
else
echo "ERR: The script failed to automatically change the system."
echo "ERR: Named is currently running as $RUNUSER."
restore
exit 1
fi
exit 0
Dieses Skript, angesetzt auf Woodys (Degbian 3.0) angepassten Bind wird die folgenede initdDatei erstellen, nachdem der User und die Gruppe “named” erstellt wurde:
#!/bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin
test -x /usr/sbin/named || exit 0
start () {
echo -n "Starting domain name service: named"
start-stop-daemon --start --quiet \
--pidfile /var/run/named.pid --exec /usr/sbin/named
echo "."
}
stop () {
echo -n "Stopping domain name service: named"
# --exec doesn’t catch daemons running deleted instances of named,
# as in an upgrade. Fortunately, --pidfile is only going to hit
# things from the pidfile.
start-stop-daemon --stop --quiet \
--pidfile /var/run/named.pid --name named
echo "."
}
case "$1" in
start)
start
;;
stop)
stop
;;
157
restart|force-reload)
stop
sleep 2
start
;;
reload)
/usr/sbin/ndc reload
;;
*)
echo "Usage: /etc/init.d/bind {start|stop|reload|restart|force-reload}" >&2
exit 1
;;
esac
exit 0
158
159
Anhang F
Sicherheits-Update geschützt durch
eine Firewall
Nachdem Sie eine standard Installation auf ein System gebracht haben, könnten immernoch
Sicherheits-Lücken vorhanden sein, falls dem so ist könnte es Updates von Debian für die
Release geben. Jedoch können Sie die Pakete jedoch nicht auf einem anderen System herunterladen können (oder security.debian.org zu lokalen Zwecken spiegeln können), müssen Sie es
mit dem Internet verbinden, um ein Sicherheits Update zu durchzuführen.
Wenn Sie sich jedoch mit dem Internet verbinden, setzen Sie sich selbst aus. Wenn einer
Ihrer lokalen Services angreifbar ist, könnten Sie kompromitiert werden, noch bevor das Update beendet ist! Sie mögen dies paranoid finden, aber eine Analyse vom Honeynet Project
(http://www.honeynet.org) zeigt tatsächlich, dass ein System in weniger als drei Tagen
kompromitiert werden sogar, sogar wenn das System gar nicht der Öffentlichkeit bekannt ist
(d.h. nicht in DNS-Einträgen auftaucht).
Wenn Sie ein update auf dem System durchführen, das nicht von einem externen System (einer
Firewall) geschützt ist, können Sie trotzdem eine lokale Firewall so konfigurieren, dass Sie nur
das Sicherheits-Update selbst erlaubt. Schauen Sie sich das Beispiel untern an, um zu sehen,
wie die lokalen Firewall Fähigkeiten aufgesetzt werden, um ein eingeschränktes Setup zu erreichen, in dem nur Verbindungen zu security.debian.org erlaubt werden, während der Rest
geloggt wird.
FIXME: add IP address for security.debian.org (since otherwise you need DNS up to work) on
/etc/hosts.
FIXME: test this setup to see if it works properly
FIXME: this will only work with http urls since ftp might need the ip_conntrack_ftp module,
or use passive mode.
# iptables -F
# iptables -L
Chain INPUT (policy ACCEPT)
Kapitel F. Sicherheits-Update geschützt durch eine Firewall
target
prot opt source
Chain FORWARD (policy ACCEPT)
target
prot opt source
160
destination
destination
Chain OUTPUT (policy ACCEPT)
target
prot opt source
destination
# iptables -P INPUT DROP
# iptables -P FORWARD DROP
# iptables -P OUTPUT DROP
# iptables -A OUTPUT -d security.debian.org -p 80 -j ACCEPT
# iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# iptables -A INPUT -p icmp -j ACCEPT
# iptables -A INPUT -j LOG
# iptables -A OUTPUT -j LOG
# iptables -L
Chain INPUT (policy DROP)
target
prot opt source
destination
ACCEPT
all -- 0.0.0.0/0
0.0.0.0/0
state RELATED,ESTA
ACCEPT
icmp -- 0.0.0.0/0
0.0.0.0/0
LOG
all -- anywhere
anywhere
LOG level warning
Chain FORWARD (policy DROP)
target
prot opt source
destination
Chain OUTPUT (policy DROP)
target
prot opt source
ACCEPT
80
-- anywhere
LOG
all -- anywhere
destination
security.debian.org
anywhere
LOG level warning

Anleitung zum Absichern von Debian

Transcription

Similar documents

Anleitung zum Absichern von Debian

Anleitung zum Absichern von Debian

Versionshinweise - Fedora Documentation

Gefährliches Google – Suche nach sensiblen Daten

Gentoo installation in Kurzform

Urine OFF - Tierbude Nalbach

Ausgabe 2

tecchannel 3/2006 - Udo Matthias Munz