Gentoo Sicherheitshandbuch

Inhalt:

• Sicherheit des Systems
  Verstärken verschiedener Teile des Systems um es sicherer zu machen.
  1. Pre-Installation Belange
     Warum ist Sicherheit ein wichtiger Teil für jeden Server-Administrator?
  2. Die Sicherheit straffen
     Straffen der Sicherheit während und nach der Installation.
  3. Protokollierung
     Gentoo Linux lässt Sie zwischen drei verschiedenen Protokollierdiensten wählen.
  4. Einbinden von Partitionen mit mount
     /etc/fstab liefert viele Sicherheitsoptionen.
  5. Benutzer/Gruppen Einschränkungen
     Kontrollieren Sie die Verwendung von Ressourcen.
  6. Dateibereichtigungen
     Sicheren Sie Ihre Dateien ab.
  7. PAM
     Pluggable Authentication Modules.
  8. TCP Wrapper
     Kontrollieren sie den Zugriff auf Dienste.
  9. Kernelsicherheit
     Sichern Sie Ihren Kernel ab.
  10. Dienste absichern
      Stellen Sie sicher, dass Ihre Daemons geschützt sind.
  11. Chrooten und virtuelle Server
      Isolieren Sie Ihre Server.
  12. Firewalls
      Filtern Sie Ihre Pakete.
  13. Aufspüren von Eindringlingen
      Eindringlinge ausfindig machen.
  14. Up-to-date bleiben
      Sicherstellen, dass Sie die aktuellesten Sicherheitsupdates haben.

A. Sicherheit des Systems

1. Pre-Installation Belange

1.a. Physische Sicherheit

Egal wie viele Sicherheitsmaßnahmen Sie integrieren, sie können leicht umgangen werden, wenn der Hacker direkten Zugriff auf Ihre Maschine hat. Nichtsdestotrotz können zumindest einige Maßnahmen ergriffen werden, um einen gewissen Grad an Sicherheit auch gegen Angreifer mit direktem Zugang zu erlangen. Den Computer in einen entsprechenden Schrank zu schließen, verhindert ein einfaches Steckerabziehen und stehlen. Auch das verschließen des Gehäuses ist eine gute Idee, damit niemand einfach mit der Festplatte davon laufen kann. Um das Booten von einem anderen Medium zu untersagen, was einfach alle Befugnisse und Login Beschränkungen aufheben würde, stellen Sie im BIOS die Festplatte als erstes Boot Device ein und setzen Sie ein BIOS Passwort. Auch ist es wichtig ein LILO oder GRUB Passwort festzulegen, um ein Booten in den Single-User Modus und somit einen kompletten Zugriff auf das System zu verhindern. Dieses wird detaillierter in Kapitel 3 unter Setzen eines GRUB Passworts und Setzen eines LILO Passworts .

1.b. Dämon/Dienst Planung

Beginnen Sie, indem Sie dokumentieren, welche Dienste auf der Maschine laufen sollten. Das wird Ihnen helfen ein besseres Partitionsschema für das System zu finden und Ihnen erlauben, Sicherheitsmaßnahmen besser zu planen. Natürlich ist dieses nicht nötig wenn die Maschine nur einem einfachen Zweck dienen soll, z.B. als Desktop oder dedizierte Firewall. In diesen Fällen sollten gar keine Dienste, außer vielleicht sshd, laufen.

Diese Liste kann auch zur Unterstützung der Systemadministration verwendet werden. Indem eine aktuelle Liste mit Versionsinformationen geführt wird, werden Sie es viel einfacher haben alles up to date zu halten, falls eine aus der Ferne nutzbare Sicherheitslücke in einem der Daemons entdeckt wird.

1.c. Partitions-Schemata

Regeln zur Partitionierung:

• Jedes Verzeichnis auf das ein Benutzer Schreibrechte haben muss ( z.B. /home, /tmp) sollte auf einer separaten Partition liegen und Disk-Quotas benutzen. Dies reduziert das Risiko, dass ein Benutzer das gesamte Dateisystem füllt. Portage benutzt /var/tmp für die Kompilierung, folglich muss diese Partition groß sein.
• Jedes Verzeichnis, in das nicht in der Distribution enthaltene Pakete installiert werden sollen, sollten auf einer separaten Partition liegen. Nach dem Filesystem Hierarchy Standard ist dies /opt oder /usr/local. Wenn diese separate Partitionen sind, bleiben Sie bei einer eventuellen Neuinstallation des Systems bestehen.
• Für zusätzliche Sicherheit können Sie statische Daten in eine eigene Partition verschieben und diese Partition nur lesbar einhängen. Wenn Sie wirklich übervorsichtig sind, dann könnten Sie statische Daten auch auf einem nur lesbaren Medium speichern - zum Beispiel einer CD-ROM.

1.d. Der Benutzer root

Der Benutzer 'root' ist der mächtigste Benutzer im System und sollte für nichts eingesetzt werden, es sei denn, es ist absolut notwendig. Wenn ein Angreifer root-Zugang erreicht, dann können Sie Ihrem System nicht mehr länger trauen - Sie haben dann keine andere Wahl, als neu zu installieren.

Goldene Regeln bezüglich 'root'

• Erstellen Sie immer einen Benutzer für die tägliche Arbeit. Wenn dieser Benutzer root-Zugang benötigt, dann fügen Sie diesen Benutzer zur Gruppe 'wheel' hinzu. Dies erlaubt einem normalen Benutzer per su zu 'root' zu wechseln.
• Lassen Sie X oder irgendeine andere Benutzeranwendung niemals als root laufen. Root sollte nur benutzt werden wenn es absolut notwendig ist. Sollte eine Sicherheitslücke in einem Programm existieren das als normaler Benutzer läuft, so kann ein Angreifer damit lediglich die Rechte des Benutzers erhalten; läuft die Anwendung hingegen als root, so erlangt der Angreifer auch root-Zugang.
• Benutzen Sie immer absolute Pfadangaben, wenn Sie als root angemeldet sind (oder verwenden Sie immer su -, was die Umgebungsvariablen des Benutzers durch die von root ersetzt, wenn Sie sich sicher sind, dass der PATH von root nur geschützte Verzeichnise wie /bin und /sbin enthält). Es ist möglich root auszutricksen und ihn dazu zu bringen eine andere Anwendung statt der, die eigentlich ausgeführt werden soll, auszuführen. Wenn der PATH von root sicher ist oder der root Benutzer nur absolute Pfade verwendet, können wir sicher sein, dass dies nicht geschehen wird.
• Wenn ein Benutzer nur ein paar Befehle, anstatt von allen, die root normalerweiser benutzen kann, als root ausführen muss, dann überlegen Sie, vielleicht auf sudo zurückzugreifen, aber seien Sie auch hierbei vorsichtig wem Sie Zugang gewähren.
• Verlassen Sie nie das Terminal, wenn Sie als root angemeldet sind.

Gentoo hat einen Standardschutz gegen normale Benutzer, die versuchen durch su root zu werden. Die Standardeinstellung von PAM verlangt, dass ein Benutzer in der Gruppe "wheel" sein muss, um su benutzen zu dürfen.

1.e. Sicherheitsrichtlinien

Es gibt verschiedene Gründe Sicherheitsrichtlinien für Ihr System/Ihre Systeme und Ihr Netzwerk zu entwerfen.

• Gute Sicherheitsrichtlinien erlauben es Ihnen, Sicherheit mehr als ein "System" zu behandeln statt als einfaches Durcheinander verschiedener Merkmale. Ohne Richtlinie zum Beispiel, könnte ein Administrator entscheiden, telnet abzuschalten, da es unverschlüsselte Passwörter überträgt, während er andererseits FTP-Zugang gewährt, obwohl es die selbe Schwäche besitzt. Eine gute Sicherheitsrichtlinie erlaubt es, lohnenswerte Maßnahmen von nicht lohnenswerten zu unterscheiden.
• Um Probleme zu diagnostizieren, Prüfungen durchzuführen und Eindringlinge zu finden, kann es nötig sein Netzwerkverkehr abzufangen, Einblick in Login- und Befehls-Logs und Home-Verzeichnise von Benutzern zu nehmen. Ohne dieses schriftlich darzulegen und Benutzer davon in Kenntnis zu setzen, können solche Dinge illegal sein und Sie in rechtliche Schwierigkeiten bringen.
• Entführte Benutzerzugänge sind eine der häufigsten Bedrohungen der Systemsicherheit. Die Hoffnung auf sicher Benutzerzugänge ist vergebens, wenn den Benutzern nicht erklärt wird, warum Sicherheit wichtig ist und wie sie sich entsprechend verhalten können (z.B. keine Passwörter auf Haftnotizen auf dem Schreibtisch aufbewahren).
• Ein gut dokumentiertes Netzwerk- und Systemlayout hilft sowohl Ihnen als auch ggf. den Untersuchenden der Strafverfolgungsbehörden beim nachspüren eines Eindringens und dem Aufspüren von Schwachstellen. Ein entsprechendes "issue" Banner, welches besagt, dass es sich bei Ihrem System um ein privates Netzwerk handelt und das jeglicher unautorisierter Zugriff untersagt ist, wird auch die Sicherstellung einer eventuellen strafrechtlichen Verfolgung des Eindringlings verbessern.

Der Bedarf an einer guten Sicherheitsrichtlinie ist jetzt hoffentlich mehr als klar.

Eine Richtlinie ist ein Dokument (oder mehrere Dokumente), das die Merkmale des Systems und des Netzwerk (z.B. welche Dienste werden angeboten), akzeptable/verbotene Benutzung, richtige Verhaltensweisen in Bezug auf Sicherheit, etc. darstellt. Alle Benutzer sollten auf diese Richtlinie aufmerksam gemacht und über Änderungen daran informiert werden. Weiterhin ist es wichtig, dass Sie sich die Zeit nehmen den Benutzern beim Verständnis der Richtlinie zu helfen, Ihnen zu erklären warum diese unterschrieben werden sollte und was geschieht, wenn Sie sich entgegen der Richtlinie verhalten (auch dieses sollte in der Sicherheitsrichtlinie enthalten sein). Dieses sollte auch mindestens einmal im Jahr wiederholt werden. Zum einen, da es Änderungen geben kann, aber auch um die Benutzer an die Richtlinie zu erinnern.

Eine Sicherheitsrichtlinie sollte mindestens die folgenden Punkte beinhalten:

• Akzeptable Anwendung
  • Bildschirmschoner
  • Behandlung von Kennworten
  • Herunterladen von Programmen
  • Wissen darüber, ob Benutzer überwacht werden
  • Benutzung von Antiviren-Software
• Behandlung von sensiblen Daten (jegliche schriftliche Form, Papier oder Digital)
  • Sauberer Schreibtisch und verschlossene, vertrauliche Informationen
  • PC herunterfahren vorm Verlassen
  • Benutzung von Verschlüsselung
  • Behandlung von Schlüsseln für vertraute Mitarbeiter
  • Behandlung von vertraulichem Material auf Reisen
• Behandlung der Computerausstattung auf Reisen
  • Behandlung des Laptops auf Reisen und bei Hotelaufenthalten

Verschiedene Benutzer könnten verschiedene Ebenen und Arten von Zugang benötigen, die Richtlinie kann daher entsprechend variieren.

Die Sicherheitsrichtlinie kann riesig werden und wichtige Informationen können leicht vergessen werden. Die Richtlinie für die IT-Abteilung kann Informationen enthalten, die gegenüber den normalen Benutzern als vertraulich gelten. Somit ist es sinnvoll, sie in kleinere Richtlinien aufzuteilen: Richtlinie für akzeptable Benutzung, Richtlinie für Passwörter, für E-Mail und für Fernzugriff.

Beispiele für Richtlinien können beim SANS Security Policy Project gefunden werden. Wenn Sie ein kleines Netzwerk haben und diese Richtlinie für zu groß halten, dann sollten Sie einen Blick auf das RFC2196 werfen, dass ein Sicherheitshandbuch darstellt.

2. Die Sicherheit straffen

2.a. USE Flags

Die make.conf-Datei enthält die benutzerdefinierten USE Flags und /etc/make.profile/make.defaults die Standard USE Flags für Gentoo Linux. Die wichtigen Flags für diesen Leitfaden sind pam (Pluggable Authentication Module), tcpd (TCP Wrapper) und ssl (Secure Socket Layer). Diese sind alle in den Standard USE Flags enthalten.

2.b. GRUB Passwortschutz

Grub unterstützt zwei verschiedene Wege zur Passwortkontrolle: Zum einen normalen Text und zum anderen md5+salt-Verschlüsselung.

timeout 5
password änderemich

Dies wird das Passwort änderemich hinzufügen; wenn kein Passwort eingegeben ist, wird die Standard-Boot-Einstellung verwendet.

Sollte ein md5-Passwort genommen werden, dann müssen Sie das Passwort ins Crypt-Format konvertieren, welches auch in /etc/shadow verwendet wird, für weitere Informationen siehe man crypt. Zum Beispiel könnte das verschlüsselte Passwort änderemich so aussehen: $1$Jd74x0$1s/sTlc8gJqqq.IOgsY3I.

Sie können das Passwort direkt in der GRUB Shell konvertieren:

#/sbin/grub

    GRUB  version 0.92  (640K lower / 3072K upper memory)

   [ Minimal BASH-like line editing is supported.  For the first word, TAB
     lists possible command completions.  Anywhere else TAB lists the possible
     completions of a device/filename. ]

grub> md5crypt

Password: ********
Typed changeme
Encrypted: $1$Jd74x0$1s/sTlc8gJqqq.IOgsY3I.

grub> quit

Dann kopieren Sie das Passwort und fügen es in /boot/grub/grub.conf ein.

timeout 5
password --md5 $1$Jd74x0$1s/sTlc8gJqqq.IOgsY3I.

Der Zeitablauf von 5 Sekunden wird sinnvoll, wenn das System fernbedient wird und bei einem Neustart ohne Tastatureingaben auskommen muss. Mehr Informationen über Grub-Passwörter können Sie bekommen, wenn Sie info grub ausführen.

2.c. LILO Passwortschutz

LILO unterstützt auch zwei Arten des Behandelns von Passwörtern: Global und per Image, beide in Klartext.

Das globale Passwort wird am Anfang der Konfigurationsdatei gesetzt und gilt für jedes Boot Image:

password=änderemich
restricted
delay=3

Das pro-Image Passwort wird so eingefügt:

image=/boot/bzImage
      read-only
      password=änderemich
      restricted

Wenn die restricted-Option nicht angegeben wurde, dann wird jedes Mal nach einem Passwort gefragt.

Um die Änderungen an lilo.conf zu übernehmen, müssen Sie /sbin/lilo ausführen.

2.d. Einschränkung der Konsolenbenutzung

Die Datei /etc/securetty erlaubt es Ihnen anzugeben an welchen tty (Terminal) Geräten root sich anmelden darf.

Wir empfehlen, dass Sie alle Zeilen bis auf vc/1 auskommentieren, wenn Sie devfs verwenden und alle Zeilen bis auf tty1 auskommentieren, wenn Sie udev verwenden. Dies stellt sicher, dass sich root nur einmal und nur an einem Terminal einloggen kann.

(Für devfs)
vc/1
(Für udev)
tty1

3. Protokollierung

3.a. Einleitung

Zusätzliche Protokollierung sollte hinzugefügt werden, um Warnungen oder Fehler aufzuspüren, die auf einen momentanen oder bereits durchgeführten Angriff hinweisen könnten. Angreifer beobachten ein Netzwerk oder durchsuchen dies oft, bevor sie angreifen.

Es ist auch unersetzlich, dass die Protokolldateien einfach zu lesen und zu verwalten sind. Gentoo Linux gibt ihnen die Möglichkeit bei der Installation zwischen drei verschiedenen Protokollierungsprogrammen zu wählen.

3.b. Loggen: Syslogd

Syslogd ist das gängigste Protokollierungsprogramm für Linux und Unix. Es beinhaltet ein wenig Protokollrotation aber die Verwendung von /usr/sbin/logrotate in einem Cron Job (logrotate wird in /etc/logrotate.conf konfiguriert) könnte sich als leistungsfähiger heraustellen, denn logrotate hat viele Funktionen. Wie oft die Protokollrotation stattfinden sollte hängt von der Systembelastung ab.

Hierunter sehen Sie die Standard Konfiguration /syslog.conf mit einigen zusätzlichen Features. Wir haben die cron und tty Zeilen entkommentiert und einen Remote Logging Server hinzugefügt. Um die Sicherheit weiter zu erhöhen, können Sie Logs an zwei Orten schreiben lassen.

#  /etc/syslog.conf      Configuration file for syslogd.
#
#                       For more information see syslog.conf(5)
#                       manpage.
#                       This is from Debian, we are using it for now
#                       Daniel Robbins, 5/15/99

#
# Zuerst einige Standardprotokolldateien.
# Protokollierung nach Einrichtung.
#

auth,authpriv.*                 /var/log/auth.log
*.*;auth,authpriv.none          -/var/log/syslog
cron.*                         /var/log/cron.log
daemon.*                        -/var/log/daemon.log
kern.*                          -/var/log/kern.log
lpr.*                           -/var/log/lpr.log
mail.*                          /var/log/mail.log
user.*                          -/var/log/user.log
uucp.*                          -/var/log/uucp.log
local6.debug                    /var/log/imapd.log

#
# Protokollierung für das Mailsystem. Trennung erfolgt so,
# dass es einfach ist Skripte, zum parsen dieser Dateien, zu schreiben.
#
mail.info                       -/var/log/mail.info
mail.warn                       -/var/log/mail.warn
mail.err                        /var/log/mail.err

# Protokollierung für INN News Systeme
#
news.crit                       /var/log/news/news.crit
news.err                        /var/log/news/news.err
news.notice                     -/var/log/news/news.notice

#
# Einige `catch-all' Protokolldateien
#
*.=debug;\
        auth,authpriv.none;\
        news.none;mail.none     -/var/log/debug
*.=info;*.=notice;*.=warn;\
        auth,authpriv.none;\
        cron,daemon.none;\
        mail,news.none          -/var/log/messages

#
# Notfälle und Warnungen werden an alle eingeloggten Benutzer geschickt.
#
*.emerg                         *
*.=alert                        *

#
# Ich bevorzuge es Nachrichten auf der Konsole angezeigt zu bekommen, jedoch
# nur auf einer virtuellen Konsole die normalerweise ungenutzt ist.
#
daemon,mail.*;\
       news.=crit;news.=err;news.=notice;\
       *.=debug;*.=info;\
       *.=notice;*.=warn       /dev/tty8

#Einrichten eines entfernten Protokollierungsservers
*.*                        @logserver

# Die genannte Pipe /dev/xconsole ist für das `xconsole' Programm. Um es zu
# verwenden müssen Sie `xconsole' mit der `-file' Option aufrufen:
#
#    $ xconsole -file /dev/xconsole [...]
#
# Anmerkung: passen Sie die folgende Liste an oder Sie werden wahnsinning,
# sofern ihre Seite eine gewisse Größe hat...
#
#daemon.*,mail.*;\
#       news.crit;news.err;news.notice;\
#       *.=debug;*.=info;\
#       *.=notice;*.=warn       |/dev/xconsole

local2.*                --/var/log/ppp.log

Der Angreifer wird höchstwahrscheinlich versuchen seine Spuren zu verwischen, indem er Protokolldateien bearbeitet oder löscht. Sie können es für den Angreifer schwerer machen indem Sie das Protokoll an einen oder mehrere Protokollserver auf verschiedenen Maschinen schicken. Mehr Informationen über syslogd finden Sie durch Aufruf von man syslog.

3.c. Metalog

Metalog von Frank Dennis bietet nicht die Möglichkeit Protokolle an einen entfernten (remote) Server zu senden, aber es hat Vorteile im Bereich der Performance und der Protokollierungsflexibilität. Es kann nach Programmnamen, Dringlichkeit oder nach Einrichtung protokollieren (wie syslogd) und beinhaltet reguläre Ausdrucksübereinstimmung und die Möglichkeit Befehle auszuführen. Es ist sehr gut um Handeln zu können, wenn nötig.

Die Standard Konfiguration ist meistens ausreichend. Wenn Sie benachrichtigt werden wollen, wenn z.B. ein Anmeldevorgang fehlschlägt benutzen Sie eines der folgenden Skripte.

Für postfix:

#! /bin/sh
echo "$3" | mail -s "Warning (program : $2)" root

Für netqmail:

#!/bin/sh
echo "To: root
Subject:Failure (Warning: $2)
$3
" | /var/qmail/bin/qmail-inject -f root

Denken Sie daran das Skript mit /bin/chmod +x /usr/local/sbin/mail_pwd_failures.sh ausführbar zu machen.

Kommentieren Sie dann die Zeile unter "Password failures" in /etc/metalog/metalog.conf wie folgt aus:

command  = "/usr/local/sbin/mail_pwd_failures.sh"

3.d. Syslog-ng

Syslog-ng enthält einige derselben Funktionen wie Syslog und Metalog mit einem kleinen Unterschied. Es ermöglicht die Filterung von Nachrichten basierend auf Level und Inhalt (wie Metalog), bietet entferntes Protokollieren (wie syslog), kann Protokolle von syslogd verarbeiten (sogar Streams von Solaris), auf ein TTY ausgeben, Programme ausführen und auch als Protokollierungsserver dienen. Grundlegend ist dies das Beste aus beiden Protokollierern kombiniert mit einer erweiterten Konfiguration.

Eine klassische, leicht modifizierte Konfigurationsdatei:

options {
        chain_hostnames(no);

        # Die standardmäßige Aktion von syslog-ng ist es, alle 10
        # Minuten eine STATS-Zeile zu loggen. Das wird nach einer Weile recht
        # ekelig. Ändern Sie dies auf 12 Stunden, so dass Sie ein nettes
        # tägliches Update darüber erhalten, wie viele Nachrichten
        # syslog-ng entgangen sind (0).
        stats_freq(43200);
};

source src {
    unix-stream("/dev/log" max-connections(256));
    internal();
};

source kernsrc { file("/proc/kmsg"); };

# Ziele festlegen
destination authlog { file("/var/log/auth.log"); };
destination syslog { file("/var/log/syslog"); };
destination cron { file("/var/log/cron.log"); };
destination daemon { file("/var/log/daemon.log"); };
destination kern { file("/var/log/kern.log"); };
destination lpr { file("/var/log/lpr.log"); };
destination user { file("/var/log/user.log"); };
destination mail { file("/var/log/mail.log"); };

destination mailinfo { file("/var/log/mail.info"); };
destination mailwarn { file("/var/log/mail.warn"); };
destination mailerr { file("/var/log/mail.err"); };

destination newscrit { file("/var/log/news/news.crit"); };
destination newserr { file("/var/log/news/news.err"); };
destination newsnotice { file("/var/log/news/news.notice"); };

destination debug { file("/var/log/debug"); };
destination messages { file("/var/log/messages"); };
destination console { usertty("root"); };

# Standardmäßig werden alle Nachrichten nach tty12 protokolliert...
destination console_all { file("/dev/tty12"); };

# ...wenn Sie vorhaben /dev/console für Programme wie xconsole zu
# verwenden, können Sie die obige destination-Zeile, die sich auf /dev/tty12
# bezieht, auskommentieren und die unten stehende Zeile entkommentieren.
#destination console_all { file("/dev/console"); };

# create filters
filter f_authpriv { facility(auth, authpriv); };
filter f_syslog { not facility(authpriv, mail); };
filter f_cron { facility(cron); };
filter f_daemon { facility(daemon); };
filter f_kern { facility(kern); };
filter f_lpr { facility(lpr); };
filter f_mail { facility(mail); };
filter f_user { facility(user); };
filter f_debug { not facility(auth, authpriv, news, mail); };
filter f_messages { level(info..warn)
        and not facility(auth, authpriv, mail, news); };
filter f_emergency { level(emerg); };

filter f_info { level(info); };
filter f_notice { level(notice); };
filter f_warn { level(warn); };
filter f_crit { level(crit); };
filter f_err { level(err); };
filter f_failed { message("failed"); };
filter f_denied { message("denied"); };

# Filter und Ziele verbinden
log { source(src); filter(f_authpriv); destination(authlog); };
log { source(src); filter(f_syslog); destination(syslog); };
log { source(src); filter(f_cron); destination(cron); };
log { source(src); filter(f_daemon); destination(daemon); };
log { source(kernsrc); filter(f_kern); destination(kern); };
log { source(src); filter(f_lpr); destination(lpr); };
log { source(src); filter(f_mail); destination(mail); };
log { source(src); filter(f_user); destination(user); };
log { source(src); filter(f_mail); filter(f_info); destination(mailinfo); };
log { source(src); filter(f_mail); filter(f_warn); destination(mailwarn); };
log { source(src); filter(f_mail); filter(f_err); destination(mailerr); };

log { source(src); filter(f_debug); destination(debug); };
log { source(src); filter(f_messages); destination(messages); };
log { source(src); filter(f_emergency); destination(console); };

# Standard-Protokoll
log { source(src); destination(console_all); };

Syslog-ng ist sehr einfach zu konfigurieren, aber es ist auch sehr einfach etwas zu übersehen, da die Konfigurationsdatei riesig ist. Der Autor verspricht zudem noch einige zusätzliche Funktionen wie Verschlüsselung, Authentifizierung, Komprimierung und MAC (Mandatory Access Control) Kontrolle. Mit diesen Optionen wird es perfekt sein für Netzwerkprotokollierung, da der Angreifer die Protokolle nicht ausspionieren kann.

Syslog-ng hat auch noch einen anderen Vorteile - es muss nicht als root laufen!

3.e. Protokollanalyse mit Logcheck

Natürlich ist das Erstellen von Protokollen nur die halbe Miete. Ein Programm wie Logcheck kann die regelmäßige Analyse von Protokollen sehr vereinfachen. Logcheck ist ein Skript, zusammen mit einem Binary namens logtail, welches vom Cron aufgerufen wird und die Protokolle regelmäßig mit einer Liste verdächtiger Aktivitäten vergleicht; dann versendet es die Ausgabe per Mail an root.

Logcheck und logtail sind Teil des app-admin/logsentry Pakets.

Logcheck verwendet vier Dateien um wichtige Einträge von den unwichtigen zu filtern. Diese Dateien sind logcheck.hacking, welche Nachrichten bekannter Hackerangriffe enthält, logcheck.violations, mit den Signaturen von Sicherheitsverletzungen, logcheck.violations.ignore, welche Schlüsselwörter enthält, die vermutlich durch die violations Datei erkannt würden, so dass normale Einträge ignoriert werden können und logcheck.ignore, mit Einträgen, die ingnoriert werden sollen.

4. Einbinden von Partitionen mit mount

4.a. Partitionen mounten

Mountet man eine ext2, ext3 oder eine reiserfs Partition, so gibt es mehrere Optionen die man in /etc/fstab einfügen kann. Diese Optionen sind:

• nosuid - Ignoriert das SUID bit und behandelt es einfach wie eine normale Datei.
• noexec - Verhindert das Ausführen von Dateien von dieser Partition.
• nodev - Ignoriert Geräte.

Leider können diese Einstellungen leicht umgangen werden, indem man einen nicht-direkten Pfad ausführt. Jedoch kann das Setzen von /tmp auf noexec die Mehrzahl von Exploits aufhalten, welche derart gestaltet sind, dass sie direkt von /tmp ausgeführt werden.

/dev/sda1 /boot ext2 noauto,noatime 1 1
/dev/sda2 none swap sw 0 0
/dev/sda3 / reiserfs notail,noatime 0 0
/dev/sda4 /tmp reiserfs notail,noatime,nodev,nosuid,noexec 0 0
/dev/sda5 /var reiserfs notail,noatime,nodev 0 0
/dev/sda6 /home reiserfs notail,noatime,nodev,nosuid 0 0
/dev/cdroms/cdrom0 /mnt/cdrom iso9660 noauto,ro 0 0
proc /proc proc defaults 0 0

5. Benutzer/Gruppen Einschränkungen

5.a. /etc/security/limits.conf

Die Kontrolle von Ressourcenbegrenzungen kann sehr effektiv sein, wenn es darum geht eine lokale Denial of Service Attacke zu verhindern oder die maximal erlaubten Logins für eine Gruppe oder einen Benutzer zu handhaben. Jedoch werden zu strikte Einstellung das Systemverhalten behindern und werden in Programmfehlern resultieren. Stellen Sie daher sich, dass Sie die einzelnen Einstellungen vorher kontrollieren.

*    soft core 0
*    hard core 0
*    hard nproc 15
*    hard rss 10000
*    -    maxlogins 2
@dev hard core 100000
@dev soft nproc 20
@dev hard nproc 35
@dev -    maxlogins 10

Wenn Sie dabei sind den Wert von nproc oder maxlogins gleich 0 zu setzen, sollten Sie diesen Benutzer vielleicht lieber löschen. Das Beispiel oben setzt die Einstellungen für die Gruppe dev für Prozesse, Kerndateien und maxlogins. Der Rest erhält einen Standardwert.

5.b. /etc/limits

/etc/limits ist recht ähnlich zur Limit-Datei /etc/security/limits.conf. Der einzige Unterschied ist das Format und dass diese nur auf Benutzern oder Wild-Cards (aber keinen Gruppen) beruht. Werfen wir einen Blick auf die Konfiguration:

*   L2 C0 U15 R10000
kn L10 C100000 U35

Hier setzen wir die Standardeinstellungen und eine spezielle Einstellung für den Anwender kn. Limits sind ein Teil des sys-apps/shadow Paketes. Es ist nicht notwendig irgendwelche Beschränkungen in dieser Datei zu setzen, wenn Sie pam in /etc/make.conf aktiviert haben.

5.c. Quotas

Die Anwendung von Quotas auf einem Dateisystem beschränkt die Datenträgerverwendung je nach Gruppe oder Benutzer. Quotas werden im Kernel aktiviert und zu einem Mount Point in /etc/fstab hinzugefügt. Die Kernel-Option wird bei der Kernelkonfiguration unter File systems->Quota support aktiviert. Nehmen Sie die Einstellung vor, kompilieren Sie den Kernel neu und starten Sie mit diesem Ihren Computer neu.

Beginnen Sie mit der Installation von Quotas mit emerge quota. Passen Sie Ihre /etc/fstab an und fügen Sie usrquota und grpquota zu den Partition, bei denen Sie die Festplattennutzung begrenzen wollen, wie im Beispiel unten, hinzu.

/dev/sda1 /boot ext2 noauto,noatime 1 1
/dev/sda2 none swap sw 0 0
/dev/sda3 / reiserfs notail,noatime 0 0
/dev/sda5 /var ext3 noatime,nodev,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv1 0 0
/dev/sda5 /var ext3 noatime,nodev,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv1 0 0
/dev/sda6 /home ext3 noatime,nodev,nosuid,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv1 0 0
/dev/sda7 /usr reiserfs notail,noatime,nodev,ro 0 0
/dev/cdroms/cdrom0 /mnt/cdrom iso9660 noauto,ro 0 0
proc /proc proc defaults 0 0

Auf jeder Partition auf der Sie Quotas aktiviert haben, erstellen Sie nun die Quota-Dateien (aquota.user und aquota.group) und setzen diese ins Root der Partition.

# touch /tmp/aquota.user
# touch /tmp/aquota.group
# chmod 600 /tmp/aquota.user
# chmod 600 /tmp/aquota.group

Dieser Schritt muss auf jeder Partition durchgeführt werden, auf der Quotas aktiviert wurden. Nachdem Sie die Quota-Dateien erstellt und konfiguriert haben, müssen Sie das quota Initskript dem boot Runlevel hinzufügen.

# rc-update add quota boot

Der Linux-Kernel überwacht die Quotanutzung des Systems. Wenn aus irgendeinem Grund die Quotadaten beschädigt werden oder Sie das Gefühl haben, dass die Daten nicht korrekt sind, müssen Sie das System im Single-User-Modus starten (oder zumindest sicherstellen, dass aktuell keine Daten auf das Dateisystem geschrieben werden) und quotacheck -avugm ausführen.

Nachdem Sie den Rechner neu gestartet haben, ist es an der Zeit, die Quotas für die Benutzer und Gruppen festzulegen. edquota -u kn wird den in $EDITOR festgelegten Editor starten (Standard ist nano), damit Sie die Quotas des Benutzers kn bearbeiten können. edquota -g wird genau dasselbe, allerdings für Gruppen machen.

Quotas for user kn:
/dev/sda4: blocks in use: 2594, limits (soft = 5000, hard = 6500)
         inodes in use: 356, limits (soft = 1000, hard = 1500)

Für weitere Informationen lesen Sie bitte man edquota oder das Quota Mini-Howto

5.d. /etc/login.defs

Wenn Ihre Sicherheitsrichtlinie besagt, dass die Anwender jede Woche ihr Passwort ändern sollen, dann setzen Sie die Variable PASS_MAX_DAYS auf 14 und PASS_WARN_AGE auf 7. Es wird außerdem empfohlen, dass Sie alternde Passwörter benutzen, da Brute-Force Angriffe jedes Passwort finden können, solange ihnen genügend Zeit zur Verfügung steht. Wir empfehlen außerdem, dass Sie LOG_OK_LOGINS auf yes setzen.

5.e. /etc/security/access.conf

Die access.conf Datei ist auch ein Teil des sys-libs/pam Paketes, welche eine Tabelle zur Login Zugangskontrolle anbietet. Die Tabelle wird benutzt, um zu kontrollieren, wer sich und wer sich nicht einloggen darf, basierend auf dem Benutzernamen, dem Gruppennamen oder dem Hostnamen von dem der Versuch gestartet wird. Normalerweise sind alle Anwender des Systems berechtigt sich anzumelden; aus diesem Grunde ist die Datei nur mit Kommentaren und Beispielen gefüllt. Je nachdem wie Sie Ihren Server oder Ihren Arbeitsplatzrechner schützen empfehlen wir die Datei so anzupassen, das niemand anderes als Sie selbst (also der Administrator) Zugang zur Konsole bekommt.

-:ALL EXCEPT wheel sync:console
-:wheel:ALL EXCEPT LOCAL .gentoo.org

Dies erstellt Loginzugriff, so dass Mitglieder von wheel sich lokal oder von der gentoo.org Domain aus einloggen können. Vielleicht ist es ein wenig zu paranoid, aber sicher ist sicher.

6. Dateibereichtigungen

6.a. Welt-lesbar

Normale Benutzer sollten zu Konfigurationsdateien oder Passwörtern keinen Zugang haben. Ein Angreifer kann Passwörter aus einer Datenbank oder von einer Webseite stehlen und verunstalten oder noch schlimmer: Daten löschen. Deswegen ist es notwendig, dass die Berechtigungen korrekt gesetzt sind. Wenn Sie sicher sind, dass eine Datei nur von root benutzt wird, geben Sie dieser die Berechtigung 0600 und ordnen Sie diese mit chown dem richtigen Benutzer zu.

6.b. Welt/Gruppen-schreibbar

# find / -type f \( -perm -2 -o -perm -20 \) -exec ls -lg {} \; 2>/dev/null >writable.txt
# find / -type d \( -perm -2 -o -perm -20 \) -exec ls -ldg {} \; 2>/dev/null >>writable.txt

Dies schafft eine riesige Datei mit Berechtigungen von allen Dateien, die entweder Schreibberechtigungen für alle oder eine Gruppe haben. Überprüfen Sie die Berechtigungen und eliminieren Sie die für alle schreibbaren Dateien durch das Ausführen von /bin/chmod o-w für die Dateien.

6.c. SUID/SGID Dateien

Dateien bei denen das SUID oder SGID Bit gesetzt ist, werden mit den Rechten des Benutzers bzw. der Gruppe ausgeführt, der diese Datei gehört. Normalerweise werden diese Bits bei Dateien verwendet, die als root ausgeführt werden müssen um ihren Zweck zu erfüllen. Diese Dateien können zu lokalen root Einbrüchen führen (falls Sie Sicherheitslücken enthalten). Dieses ist gefährlich, daher sollten Dateien mit gesetztem SUID/SGID Bit auf jeden Fall vermieden werden. Sollten Sie diese Dateien nicht verwenden, dann wenden Sie chmod 0 auf diese an oder unmergen das Paket welches diese Dateien mitgebracht hat (das zugehörige Paket können Sie mit equery finden; sollte es noch nicht installiert sein, dann geben Sie einfach emerge gentoolkit ein). Ansonsten schalten Sie das SUID Bit einfach mit chmod -s aus.

# find / -type f \( -perm -004000 -o -perm -002000 \) -exec ls -lg {} \; 2>/dev/null >suidfiles.txt

Dies erzeugt eine Datei mit einer Liste aller SUID/SGID Dateien.

/bin/su
/bin/ping
/bin/mount
/bin/umount
/var/qmail/bin/qmail-queue
/usr/bin/chfn
/usr/bin/chsh
/usr/bin/crontab
/usr/bin/chage
/usr/bin/expiry
/usr/bin/sperl5.6.1
/usr/bin/newgrp
/usr/bin/passwd
/usr/bin/gpasswd
/usr/bin/procmail
/usr/bin/suidperl
/usr/lib/misc/pt_chown
/usr/sbin/unix_chkpwd
/usr/sbin/traceroute
/usr/sbin/pwdb_chkpwd

Standardmäßig hat Gentoo Linux nicht viele SUID Dateien (allerdings hängt es davon ab, was Sie installiert haben), aber Sie könnten eine Liste wie die obige erhalten. Viele dieser Befehle sollten nicht von normalen Benutzern benutzt werden, sondern nur von root. Schalten Sie das suid bit bei ping, mount, umount, umount, chfn, chsh, newgrp, suidperl, pt_chown und traceroute aus. Sie tun dies mit dem Befehl chmod -s bei jeder einzelnen Datei. Entfernen Sie das Bit nicht von su, qmail-queue oder unix_chkpwd. Dies würde dazu führen, dass Sie nicht mehr su benutzen könnten und keine Mail empfangen würden. Durch Entfernen des Bits (wenn es sicher ist, dies zu tun) beseitigen Sie die Möglichkeit, dass ein normaler User (oder Angreifer) root-Zugriff durch eine dieser Dateien erlangen kann.

Die einzigen SUID Dateien die ich auf meinem System habe sind su, passwd, gpasswd, qmail-queue, unix_chkpwd und pwdb_chkpwd. Aber wenn Sie X benutzen, könnten Sie einige mehr haben, denn X benötigt diesen erweiterten Zugriff via SUID.

6.d. SUID/SGID Binärdateien und Hardlinks

Eine Datei wird nur als gelöscht angesehen, falls keine Links mehr auf sie zeigen. Dies mag nach einem merkwürdigen Konzept klingen, aber bedenken Sie, dass ein Dateiname wie /usr/bin/perl eigentlich nur ein Link auf einen Inode ist, wo die Daten gespeichert sind. Eine beliebige Zahl von Links kann auf eine Datei verweisen und solange noch einer existiert, existiert auch die Datei.

Wenn Ihre Benutzer Zugang zu einer Partition haben, die nicht mit nosuid oder noexec eingebunden sind (z. B. falls /tmp, /home, oder /var/tmp nicht auf unterschiedlichen Partitionen liegen), sollten Sie darauf achten, dass Benutzer keine Hardlinks auf SUID oder SGID Binaries erstellen, so dass Sie nach einem Update durch Portage immer noch Zugang zu alten Versionen haben.

Um herauszufinden wie viele Links eine Datei hat, kann der stat Befehl verwendet werden.

$ stat /bin/su
  File: `/bin/su'
  Size: 29350           Blocks: 64         IO Block: 131072 regular file
Device: 900h/2304d      Inode: 2057419     Links: 1
Access: (4711/-rws--x--x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2005-02-07 01:59:35.000000000 +0000
Modify: 2004-11-04 01:46:17.000000000 +0000
Change: 2004-11-04 01:46:17.000000000 +0000

Um SUID und GUID Dateien mit mehreren Links zu finden, kann find verwendet werden.

$ find / -type f \( -perm -004000 -o -perm -002000 \) -links +1 -ls

7. PAM

7.a. PAM

PAM ist eine Sammlung von gemeinsam genutzten Bibliotheken, die eine Alternative für Authentifizierungen von Benutzern in Programmen darstellen. Das pam USE flag ist standardmäßig gesetzt. Die PAM Einstellungen von Gentoo Linux sind relativ angemessen, aber es gibt immer Platz für Verbesserungen. Zunächst installieren wir cracklib.

# emerge cracklib

auth     required pam_unix.so shadow nullok
account  required pam_unix.so
password required pam_cracklib.so difok=3 retry=3 minlen=8 dcredit=-2 ocredit=-2
password required pam_unix.so md5 use_authtok
session  required pam_unix.so

Dies fügt die cracklib hinzu, welche sicherstellt, dass der Benutzer eine minimale Passwortlänge von acht Zeichen benutzt, bestehend aus mindestens zwei Zahlen und zwei sonstigen Zeichen, weiterhin müssen mindestens drei Zeichen anders sein als beim letzten Passwort. Dies zwingt den Benutzer ein gutes Passwort zu wählen (Passwortrichtlinien). In der Dokumentation von PAM finden Sie weitere Optionen.

auth     required pam_unix.so nullok
auth     required pam_shells.so
auth     required pam_nologin.so
auth     required pam_env.so
account  required pam_unix.so
password required pam_cracklib.so difok=3 retry=3 minlen=8 dcredit=-2 ocredit=-2 use_authtok
password required pam_unix.so shadow md5
session  required pam_unix.so
session  required pam_limits.so

Jeder andere Dienst der nicht mit einer PAM Datei in /etc/pam.d konfiguriert ist wird die Regeln in /etc/pam.d/other benutzen. Die Standardeinstellungen sind auf deny gesetzt, so wie es sein sollte. Jedoch habe ich gerne viele Protokolle und deswegen habe ich pam_warn.so hinzugefügt. Die letzte Konfiguration ist pam_limits welche von /etc/security/limits.conf kontrolliert wird. Mehr zu diesen Einstellungen im Abschitt über /etc/security/limits.conf.

auth     required pam_deny.so
auth     required pam_warn.so
account  required pam_deny.so
account  required pam_warn.so
password required pam_deny.so
password required pam_warn.so
session  required pam_deny.so
session  required pam_warn.so

8. TCP Wrapper

8.a. TCP Wrapper

Dies ist ein Weg um den Zugang zu Diensten zu kontrollieren, die normalerweise von inetd ausgeführt werden (welches Gentoo nicht hat), aber es kann auch von inetd und anderen Diensten benutzt werden.

ALL:PARANOID

ALL: LOCAL @wheel
time: LOCAL, .gentoo.org

Wie Sie sehen können ist das Format sehr ähnlich dem in /etc/security/access.conf. Tcpd unterstützt einen spezifischen Dienst; es überlappt sich nicht mit /etc/security/access.conf. Diese Einstellungen gelten nur für Dienste, die TCP-Wrapper benutzen.

Es ist auch möglich Befehle auszuführen wenn auf einen Dienst zugegriffen wird (kann benutzt werden wenn Weiterleitung für Benutzer die sich einwählen aktiviert wird) aber es nicht empfohlen, da Menschen dazu neigen mehr Probleme zu schaffen als Sie versuchen zu beheben. Ein Beispiel könnte sein, dass Sie ein Skript konfigurieren jedes mal eine E-Mail zu senden wenn jemand die deny-Regel trifft, aber ein Angreifer könnte so eine DoS Attacke ausführen indem er weiter darauf zugreift. Dies schafft viel I/O und viele E-Mails, tun Sie es daher nicht! Lesen Sie man 5 hosts_access für weitere Informationen.

9. Kernelsicherheit

9.a. Entfernen von Funktionen

Eine grundlegende Regel ist die Entfernung von allem was Sie nicht brauchen. Das schafft einen kleinen Kernel und entfernt auch die Verwundbarkeiten die in Treibern oder anderen Funktionen liegen können.

Ziehen Sie auch in Betracht Unterstützung für das Laden von Modulen (loadable module support) auszuschalten. Auch wenn es möglich ist sogenannte Rootkits ohne diese Eigenschaft hinzuzufügen, wird es doch schwerer für den normalen Angreifer Rootkits über Kernelmodule zu installieren.

9.b. Das proc Dateisystem

Viele Parameter des Kernels können durch das /proc Dateisystem oder durch die Benutzung von sysctl verändert werden.

Um Kernelparameter und -variablen dynamisch zu ändern, muss CONFIG_SYSCTL in Ihrem Kernel definiert sein. Dies ist voreingestellt im Standard 2.4 Kernel.

# /bin/echo "0" > /proc/sys/net/ipv4/ip_forward

Stellen Sie sicher, dass IP Forwarding deaktiviert ist. Dieses benötigen wir lediglich bei einem Rechner in mehreren Netzen. Es ist anzuraten, diese Einstellung vor allen anderen vorzunehmen, weil hiermit auch andere (de)aktiviert werden.

# /bin/echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_all

Dies veranlasst den Kernel alle ping Pakete (auch bekannt als ICMP Typ 0 Pakete) zu ignorieren). Der Grund hierfür ist, dass IP Pakete, welche ICMP Nachrichten beinhalten auch andere Informationen beinhalten können als Sie denken. Administratoren benutzen ping als Diagnosewerkzeug und beschweren sich oft, wenn es deaktiviert ist; es gibt aber für einen Außenseiter keinen Grund in der Lage sein zu müssen, pings zu verwenden. Nichtsdestotrotz ist es manchmal nützlich intern ping benutzen zu können, dann können Sie ICMP Typ 0 Pakete in der Firewall deaktivieren (und es dadurch lokalen Administratoren erlauben ping zu verwenden).

# /bin/echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

Dies deaktiviert das Antworten auf ICMP Broadcasts und verhindern sog. Smurf-Angriffe. Diese verwenden eine ICMP Typ 0 (ping) Nachricht, welche an die Broadcast-Adresse eines Netzwerks gesendet wird, wobei der Angreifer typischerweise die Ursprungsadresse verschleiert. Sämtliche Rechner des Netzes werden nun auf diese Nachricht antworten und dabei den Computer der in Wirklichkeit die gefälschte Ursprungsadresse besitzt überfluten.

# /bin/echo "0" > /proc/sys/net/ipv4/conf/all/accept_source_route

Akzeptieren Sie keine Pakete mit quellbasierendem Routing. Angreifer können quellbasierendes Routen benutzen um Datenverkehr zu erzeugen, der vorgibt aus dem Netzwerk zu kommen, jedoch eigentlich über seinen Ursprungspfad zurück geroutet wird. Quellbasierendes Routing wird selten für legitime Zwecke eingesetzt, daher ist es sicher dies zu deaktivieren.

# /bin/echo "0" > /proc/sys/net/ipv4/conf/all/accept_redirects

Akzeptieren Sie keine ICMP Umleitungspakete. Diese können zur Veränderung der Routing Tables verwendet werden, möglicherweise mit einem böswilligen Ziel.

# /bin/echo "1" > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses

Schalten Sie den Schutz gegen gefälschte Fehlermeldungen ein.

# for i in /proc/sys/net/ipv4/conf/*; do
        /bin/echo "1" > $i/rp_filter
done

Stellen Sie reverse Pfadfilterung an. Dies hilft durch automatisches Ablehnen von Quelladressen, die nicht mit dem Netzwerkinterface übereinstimmen, sicherzustellen, dass Pakete legitime Quelladressen benutzen. Dies hat Sicherheitsvorteile, da es IP Spoofing verhindert. Wir müssen es für alle net/ipv4/conf/* aktivieren, da sonst die Validierung der Quelle nicht voll funktionsfähig ist.

# /bin/echo "1" > /proc/sys/net/ipv4/conf/all/log_martians

Protokollieren von Paketen die gespoofed sind, quellbasierendes Routing verwenden oder Umleitungen sind.

Alle diese Einstellungen werden zurückgesetzt, wenn die Maschine neu gestartet wird. Daher schlage ich vor, dass Sie jene in /etc/sysctl.conf eintragen. Diese Datei wird vom /ect/init.d/bootmisc Init-Skript ausgelesen.

Die Syntax für /etc/sysctl.conf ist recht gradlinig. Entfernen Sie das /proc/sys/ von den eben angesprochenen Pfadnamen und ersetzen Sie / mit .:

(Manuell durch echo):
/bin/echo "0" > /proc/sys/net/ipv4/ip_forward

(Automatisch in sysctl.conf:)
net.ipv4.ip_forward = 0

9.c. Grsecurity

Der Patch von Grsecurity ist Standard in den sys-kernel/hardened-sources, aber per Voreinstellung deaktiviert. Konfigurieren Sie Ihren Kernel wie gewohnt und konfigurieren Sie dann die Grsecurity-Optionen. Eine ausführliche Erläuterung zu den verfügbaren Grsecurity-Optionen ist auf der Seite des Gentoo Hardened Projekt verfügbar.

Die aktuellen hardened-sources enthalten die 2.* Version von Grsecurity. Für weitere Informationen zu diesem verbessertem Patchsatz konsultieren Sie bitte die Dokumentation auf der Grsecurity Homepage.

9.d. Kerneli

Kerneli ist ein Patch der Verschlüsselung zum existierenden Kernel hinzufügt. Durch Patchen des Kernel erhalten Sie neue Optionen wie: Kryptographische Chiffrierung, Zusammenfassungsalgorithmen und Kryptographische-Schleifenfilter.

9.e. Andere Kernel Patches

• Das OpenWall Projekt
• Linux Intrusion Detection System
• Rule Set Based Access Control
• NSA's security enhanced kernel
• Wolk

Und es gibt wahrscheinlich viele weitere.

10. Dienste absichern

10.a. Apache

Apache kommt mit einer recht gut eingestellten Konfigurationsdatei, aber auch hier müssen wir einige Dinge verbessern, wie z.B. Apache an eine Adresse binden und verhindern, dass es keine Informationen preisgibt. Folgende Optionen sollten Sie in der Konfigurationsdatei anpassen:

Wenn Sie ssl in Ihrer /etc/make.conf vor der Installation von Apache nicht deaktiviert hatten, dann sollten Sie Zugang zu einem SSL-fähigen Server haben. Sie finden Beispielkonfigurationsdateien in /etc/apache2/vhosts.d. Die sind funktionierende Beispiele und am besten überprüft man diese oder deaktiviert sie.

Es ist wichtig Ihre Konfiguration(en) so zu definieren dass dass sie auf eine bestimmte IP hören (anstatt auf allen auf Ihrem System verfügbaren IP-Adressen). Zum Beispiel für die Datei 00_default_vhost.conf:

# Lassen Sie ihn auf Ihre IP hören
Listen 127.0.0.1

Wir empfehlen außerdem dass Sie die Anzeige von Informationen über Ihre Apache-Installation an die Welt deaktivieren. Standardmäßig wird die Konfiguration Serverversion und virtuellen Hostnamen zu vom Server generierten Seiten hinzufügen. Um die zu deaktivieren, setzen Sie die Variable ServerSignature auf Off:

ServerSignature Off

Apache wird mit --enable-shared=max und --enable-module=all kompiliert. Dies wird von standardmäßig alle Module aktivieren, sodass Sie alle Module in der LoadModule-Sektion (also LoadModule und AddModule) in der Hauptkonfigurationsdatei /etc/apache2/httpd.conf auskommentieren müssen, die Sie nicht benötigen. Starten Sie den Dienst neu, indem Sie /etc/init.d/apache2 restart ausführen.

Die Dokumentation gibt es auf http://www.apache.org.

10.b. Bind

Dokumentation zu Bind finden Sie beim Internet Software Konsortium. Das "BIND 9 Administrator Reference Manual" ist auch in doc/arm verfügbar.

Die neueren BIND Ebuilds unterstützen chrooten von vorneherein. Folgen Sie nach dem emergen von bind diesen simplen Anweisungen:

# emerge --config bind

(Bevor Sie diesen Befehl ausführen, möchten Sie vielleicht das chroot
Verzeichnis in /etc/conf.d/named ändern. Ansonsten wird /chroot/dns verwendet.)

10.c. Djbdns

Djbdns ist eine DNS Implementierung auf deren Sicherheit der Autor bereit ist Geld zu wetten. Sie unterscheidet sich grundlegend von Bind 9, ist aber einen Versuch wert. Weitere Informationen finden sich auf http://www.djbdns.org.

10.d. FTP

Das Benutzen von FTP (File Transfer Protocol) ist im Allgemeinen eine schlechte Idee. Es benutzt unverschlüsselte Daten (Passwörter werden also als Klartext gesendet), lauscht auf zwei Ports (normalerweise 20 und 21), und anonyme Logins sind das, wonach Angreifer gerne suchen (um Warez zu verteilen). Da das FTP-Protokoll einige Sicherheitslücken enthält, benutzen Sie bitte alternativ sftpd oder HTTP. Wenn dies nicht möglich sein sollte, dann sichern Sie Ihre Dienste so gut wie nur möglich ab und bereiten Sie sich vor.

10.e. Mysql

Wenn nur lokale Anwendungen auf die mysql Datenbank zugreifen, dann entkommentieren Sie die folgende Zeile in /etc/mysql/my.cnf.

skip-networking

Dann deaktivieren wir die Verwendung des Befehls LOAD DATA LOCAL INFILE, um ein nicht autorisiertes Lesen von lokalen Dateien zu verhindern. Dies ist relevant wenn neue SQL Injection Schwachstellen in PHP Applikationen gefunden werden.

set-variable=local-infile=0

Als nächstes müssen wir die Beispielsdatenbank (test) entfernen und alle Accounts, außer dem lokalen root Account.

mysql> drop database test;
mysql> use mysql;
mysql> delete from db;
mysql> delete from user where not (host="localhost" and user="root");
mysql> flush privileges;

10.f. Proftpd

Proftpd hatte mehrere Sicherheitsprobleme, aber es hat den Anschein als seien die meisten repariert worden. Nichtsdestotrotz empfiehlt sich die Aktivierung einiger weiterer Verbesserungen:

ServerName "Mein FTP Daemon"
#Ident des Servers nicht anzeigen
ServerIdent on "Hau ab!"

#Vereinfacht es virtuelle Benutzer anzulegen
RequireValidShell off

#Benutzen Sie eine alternative Passwort- und Gruppendatei (passwd benutzt das Crypt-Format)
AuthUserFile "/etc/proftpd/passwd"
AuthGroupFile "/etc/proftpd/group"

# Berechtigungen
Umask 077

# Timeouts und Beschränkungen
MaxInstances 30
MaxClients 10 "Nur 10 Verbindungen erlaubt"
MaxClientsPerHost 1 "Sie sind schon eingeloggt"
MaxClientsPerUser 1 "Sie sind schon eingeloggt"
TimeoutStalled 10
TimeoutNoTransfer 20
TimeoutLogin 20

#jeden "chrooten"
DefaultRoot ~

#nicht als root laufen lassen
User  nobody
Group nogroup

#Jeden Transfer protokollieren
TransferLog /var/log/transferlog

#Probleme mit Zeichenersetzung
DenyFilter \*.*/

Dokumentation findet man auf http://www.proftpd.org.

10.g. Pure-ftpd

Pure-ftpd ist ein Zweig des ursprünglichen trollftpd. Es wurde von Frank Dennis aus Funktionalitäts- und Sicherheitsgründen modifiziert.

Benutzen Sie virtuelle Server (niemals System Accounts) indem Sie die AUTH Option aktivieren. Setzen Sie diese auf -lpuredb:/etc/pureftpd.pdb und erstellen Sie Ihre Benutzer mit Hilfe von /usr/bin/pure-pw.

AUTH="-lpuredb:/etc/pureftpd.pdb"

## Misc. Others ##
MISC_OTHER="-A -E -X -U 177:077 -d -4 -L100:5 -I 15"

Konfigurieren Sie Ihre MISC_OTHER Einstellung um anonymen Zugriff zu verwehren (-E), chrooten Sie jeden (-A), verhindern Sie, dass Benutzer Dateien lesen/schreiben können, welche mit einem "." (Punkt) beginnen (-X), maximale Idle Zeit (-I), beschränken Sie Rekursion (-L) und verwenden Sie eine sinnvolle umask Einstellung.

Dokumentation kann auf http://www.pureftpd.org gefunden werden.

10.h. Vsftpd

Vsftpd (kurz für "very secure ftp", also "sehr sicheres FTP") ist ein kleiner FTP-Dämon der mit einer vernünftigen Standardkonfiguration versehen ist. Er ist einfach und besitzt nicht so viele Möglichkeiten wie pureftp und proftp.

anonymous_enable=NO
local_enable=YES

#nur-lesen
write_enable=NO

#aktivieren der Protokollierung aller Transfers
xferlog_std_format=YES

idle_session_timeout=20
data_connection_timeout=20
nopriv_user=nobody

chroot_list_enable=YES
chroot_list_file=/etc/vsftpd/chrootlist

ls_recurse_enable=NO

Wie Sie sehen können, gibt es bei diesem Dienst keine Möglichkeit individuelle Rechte zu verwenden, wenn es aber um anonyme Einstellungen geht ist er recht gut. Manchmal kann es hilfreich sein einen anonymen FTP Server zu haben (z.B. zur Verbreitung von Open Source) und dann leistet vsftpd hervorragende Arbeit.

10.i. Netqmail

Netqmail wird oft als ein sehr sicherer Mail-Server angesehen. Er wurde mit Sicherheit (und Paranoia) im Hinterkopf geschrieben. Standardmäßig erlaubt er kein Relaying und hatte seit 1996 kein Sicherheitsloch. Starten Sie einfach emerge netqmail und konfigurieren Sie ihn dann!

10.j. Samba

Samba ist ein Protokoll um Dateien mit Microsoft/Novell Netzwerken auszutauschen und sollte nicht über das Internet verwendet werden. Nichtsdestotrotz muss es gesichert werden.

[global]
  #An ein Interface binden
  interfaces = eth0 10.0.0.1/32

  #Sicherstellen, dass verschlüsselte Passwörter verwendet werden
  encrypt passwords = yes
  directory security mask = 0700

  #Traffic von 10.0.0.* erlauben
  hosts allow = 10.0.0.

  #Aktiviert Benutzerauthentifizierung
  #(verwenden Sie nicht den share Modus)
  security = user

  #Verweigern von privilegierten Accounts
  invalid users = root @wheel

  #Maximalgröße die smb für ein Share anzeigt (ist kein Limit)
  max disk size = 102400

  #Die Passwortrichtlinie aufrecht erhalten
  min password length = 8
  null passwords = no

  #PAM verwenden (Wenn Support hinzugefügt)
  obey pam restrictions = yes
  pam password change = yes

Stellen Sie sicher, dass die Berechtigungenfür jedes Share korrekt gesetzt sind und denken Sie daran die Dokumentation zu lesen.

Starten Sie den Server nun neu und fügen Sie den Benutzer hinzu, der Zugriff auf diesen Dienst haben sollte. Dies geschieht durch /usr/bin/smbpasswd mit dem Parameter -a.

10.k. ssh

Die einzige Absicherung, die OpenSSH benötigt, ist die Aktivierung von stärkerer Authentifizierung, basierend auf der Public-Key Verschlüsselung. Viel zu viele Seiten (wie http://www.sourceforge.net, http://www.php.net und http://www.apache.org) haben unter unautorisiertem Eindringen in Ihre Systeme gelitten, wegen schlechten oder öffentlich gewordenen Passwörtern.

#Nur Version 2 aktivieren
Protocol 2

#Anmeldung als root deaktivieren, Benutzer müssen su verwenden um root zu erlangen
PermitRootLogin no

#Public Key Authentifizierung aktivieren
PubkeyAuthentication yes
AuthorizedKeysFile      .ssh/authorized_keys

#Deaktivieren von .rhost und normaler Passwortauthentifizierung
HostbasedAuthentication no
PasswordAuthentication no
PermitEmptyPasswords no

#Nur Benutzern aus der wheel oder admin Gruppe den Zugang erlauben
AllowGroups wheel admin

#In diesen Gruppen nur folgende Benutzer zulassen
#Das @<Domainname> ist optional, aber ersetzt die
#ältere AllowHosts Direktive
AllowUsers kn@gentoo.org bs@gentoo.org

#Protokollierung
SyslogFacility AUTH
LogLevel INFO

(Ändern Sie dies auf Ihre Adresse)
ListenAddress 127.0.0.1

Stellen Sie auch sicher, dass Sie nicht UsePAM yes in Ihrer Konfigurationsdatei gesetzt haben, da so der Mechanismus zur Authentifizierung durch öffentliche Schlüssel überschreiben wird. Sie können aber auch PasswordAuthentication oder ChallengeResponseAuthentication deaktivieren. Weitere Informationen über diese Optionen finden Sie in der manual-Seite von sshd_config.

Nun ist alles, was Ihre Benutzer noch tun müssen, mit folgendem Befehl (auf der Maschine von der Sie sich einloggen wollen) einen Schlüssel zu erstellen:

# /usr/bin/ssh-keygen -t dsa

Eine Passphrase eintippen.

Generierung des öffentlichen/privaten dsa Schlüsselpaares.
Geben Sie den Dateinamen ein unter dem der Schlüssel gespeichert wird (/home/kn/.ssh/id_rsa):[Enter drücken]
Verzeichnis erstellt '/home/kn/.ssh'.
Passphrase eingeben (leer für keine Passphrase): [Passphrase eingeben]
Dieselbe Passphrase erneut eingeben: [Erneut Passphrase eingeben]
Ihre Identifikation wurde in /home/kn/.ssh/id_dsa gespeichert.
Ihr öffentlicher Schlüssel wurde in /home/kn/.ssh/id_dsa.pub gespeichert.
Der Fingerabdruck des Schlüssels ist:
07:24:a9:12:7f:83:7e:af:b8:1f:89:a3:48:29:e2:a4 kn@knielsen

Dies fügt zwei Dateien, mit den Namen id_dsa und id_dsa.pub, zu Ihrem ~/.ssh/ Verzeichnis hinzu. Die Datei id_dsa ist Ihr privater Schlüssel und sollte von allen Personen, außer Ihnen, ferngehalten werden. Die andere Datei id_dsa.pub soll an jeden Server verteilt werden zu dem Sie Zugriff haben. Fügen Sie den Schlüssel in das home Verzeichnis des Benutzers in ~/.ssh/authorized_keys ein und der Benutzer sollte die Möglichkeit haben sich einzuloggen:

$ scp id_dsa.pub anderer-Host:/var/tmp/aktueller-Hostname.pub
$ ssh anderer-Host
password:
$ cat /var/tmp/aktueller-Hostname.pub >> ~/.ssh/authorized_keys

Ihre Benutzer sollten diesen privaten Schlüssel gut verwahren. Packen Sie ihn auf ein Medium, dass Sie immer mit sich tragen oder lassen Sie ihn auf ihrer Workstation (fügen Sie dies in die Passwortrichtlinien ein).

Mehr über OpenSSH finden Sie auf der Webseite.

10.l. Benutzung von xinetd

xinetd ist ein Ersatz für inetd (welchen Gentoo nicht hat), den Internet-Dienst-Daemon. Er unterstützt Zugriffskontrolle basierend auf den Adressen der entfernten Hosts und dem Zeitpunkt des Zugriffs. Es beinhaltet auch ausführliche Protokollfähigkeiten, inklusive Serverstartzeit, Adresse des entfernten Hosts, entfernter Benutzername, Serverlaufzeit und angeforderte Abläufe.

Wie bei allen anderen Diensten ist es wichtig eine gute Standardkonfiguration zu haben. Da xinetd aber von root ausgeführt wird und Protokolle unterstützt, deren Funktionsweise Sie möglicherweise nicht verstehen, raten wir Ihnen, es nicht zu benutzen. Wenn Sie es aber dennoch benutzen wollen, fügen Sie so mehr Sicherheit hinzu:

# emerge xinetd tcp-wrappers

Ergänzen Sie die Konfigurationsdatei um:

defaults
{
 only_from = localhost
 instances = 10
 log_type = SYSLOG authpriv info
 log_on_success = HOST PID
 log_on_failure = HOST
 cps = 25 30
}

# Dies konfiguriert pserver (cvs) durch xinetd mit den folgenden Einstellungen:
# maximal 10 Instanzen (10 Verbindungen gleichzeitig)
# Begrenzung von pserver auf tcp
# benutzen des Benutzer-cvs um diesen Dienst laufen zu lassen
# Anbinden der Schnittstelle an nur 1 IP
# Zulassen von Zugriff von 10.0.0.*
# Begrenzung der Zeit in der Entwickler auf das cvs
# zugreifen können von 08Uhr bis 17Uhr
# Benutzung von tcpd wrappers (Zugriffskontrolle kontrolliert durch
# /etc/hosts.allow und /etc/hosts.deny)
# max_load ist an der Maschine auf 1.0 gesetzt
# Das disable (sperren) Flag steht auf nein, aber ich bevorzuge es zu
# haben, für den Fall dass es gesperrt sein sollte.
service cvspserver
{
 socket_type = stream
 protocol = tcp
 instances = 10
 protocol = tcp
 wait = no
 user = cvs
 bind = 10.0.0.2
 only_from = 10.0.0.0
 access_times = 8:00-17:00
 server = /usr/sbin/tcpd
 server_args = /usr/bin/cvs --allow-root=/mnt/cvsdisk/cvsroot pserver
 max_load = 1.0
 log_on_failure += RECORD
 disable = no
}

Für weitere Information lesen Sie bitte man 5 xinetd.conf.

10.m. X

Standardmäßig ist Xorg konfiguriert als Xserver zu arbeiten. Dies kann gefährlich sein, denn X verwendet unverschlüsselte TCP Verbindungen und wartet auf xclients.

Wenn Sie aber Ihre Workstation als Xserver verwenden müssen, dann seien Sie vorsichtig mit dem /usr/X11R6/bin/xhost Befehl. Dieser Befehl erlaubt es Clients von anderen Hosts sich zu verbinden und Ihre Display zu benutzen. Dies kann hilfreich sein, wenn Sie eine X Anwendung von einem anderen Rechner benötigen und der einzige Weg über das Netzwerk führt, dies kann jedoch auch durch einen Angreifer ausgenutzt werden. Die Syntax lautet /usr/X11R6/bin/xhost +hostname

Eine sichere Lösung ist dieses Feature komplett zu deaktivieren, indem man X mit startx -- -nolisten tcp startet oder es permanent in der Konfiguration deaktiviert.

defaultserverargs="-nolisten tcp"

Um sicherzustellen, dass startx nicht überschrieben wird, wenn eine neue Version von Xorg mit emerge installiert wird, müssen Sie es schützen. Fügen Sie die folgende Zeile zu /etc/make.conf hinzu:

CONFIG_PROTECT_MASK="/usr/X11R6/bin/startx"

Wenn Sie einen graphischen Loginmanager verwenden, müssen Sie die Sache anders angehen.

Für gdm (Gnome Display Manager)

[server-Standard]
command=/usr/X11R6/bin/X -nolisten tcp

Für xdm (X Display Manager) und kdm (Kde Display Manager)

:0 local /usr/bin/X11/X -nolisten tcp

11. Chrooten und virtuelle Server

11.a. Chrooten

Einen Dienst zu chrooten stellt eine Möglichkeit dar einen Dienst (oder Benutzer) auf für ihn vorgesehene Ressourcen zu beschränken und zu verhindern, dass er Zugang zu Bereichen (oder Informationen) erlangt, die zu einem unberechtigten Besitz von root-Rechten führen könnte. Indem man einen Dienst als ein anderer Benutzer als root laufen lässt (nobody, apache, named) kann ein Angreifer nur auf Dateien, mit den Berechtigungen des Benutzers, zugreifen. Dies bedeutet, dass ein Angreifer nie root Zugang erlangen kann, selbst wenn der entsprechende Dienst eine Sicherheitslücke hätte.

Einige Dienste wie zum Beispiel pure-ftpd und bind haben eingebaute Fähigkeiten für chroot, andere Dienste bieten dies nicht. Wenn der Dienst es anbietet, dann benutzen Sie es, andernfalls müssen Sie in die Materie einsteigen und einen eigenen Benutzer erstellen. Lassen Sie es uns nun versuchen und eine eigene chroot-Umgebung aufbauen. Um einen Einstieg zu finden und zu sehen wie chroot arbeitet versuchen wir es zuerst mit bash (als einfachen Einstieg ins Lernen).

Erstellen Sie das /chroot Verzeichnis mittels mkdir /chroot. Nun müssen wir herausfinden, mit welche dynamischen Bibliotheken bash kompiliert wurde (wenn es mit -static kompiliert wurde, dann ist dieser Schritt nicht nötig).

Der folgende Befehl wird eine Liste der von bash benutzten Bibliotheken ausgeben.

# ldd /bin/bash
  libncurses.so.5 => /lib/libncurses.so.5 (0x4001b000)
  libdl.so.2 => /lib/libdl.so.2 (0x40060000)
  libc.so.6 => /lib/libc.so.6 (0x40063000)
  /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

Nun erstellen wir die Umgebung für bash.

# mkdir /chroot/bash
# mkdir /chroot/bash/bin
# mkdir /chroot/bash/lib

Nun kopieren wir die von bash benutzten Dateien (/lib) in das chrootete lib und kopieren den bash Befehl n das Verzeichnis /bin im chroot. Dies wird dieselbe Umgebung erstellen - nur eben mit weniger Funktionalität. Versuchen Sie nach dem kopieren: chroot /chroot/bash /bin/bash. Wenn Sie ein Prompt bekommen, dass als aktuelles Verzeichnis / angibt, dann hat alles funktioniert. Wenn nicht, wird ordnungsgemäß eine Fehlermeldung erscheinen, welche die fehlende Datei angibt. Manche dynamischen Bibliotheken bauen aufeinander auf.

Sie werden feststellen, dass innerhalb der chroot-Umgebung nichts anderes als echo funktioniert. Dies ist deshalb so, weil wir keine anderen Befehle in unserer chroot-Umgebung haben und echo ein in bash eingebauter Befehl ist.

Dies ist in etwa der Weg den Sie gehen würden, um einen "ge-chrooteten" Dienst zu erstellen. Der einzige Unterschied ist, dass Dienste manchmal auf Geräten und Konfigurationsdateien in /etc basieren. Kopieren Sie diese einfach in die chroot-Umgebung (Geräte können mit cp -a kopiert werden) und editieren Sie das Init-Skript so dass es die chroot-Umgebung vor der Ausführung verwendet. Es kann schwierig sein herauszufinden, welche Konfigurationsdateien und Geräte ein Dienst benutzt. Dies ist der Punkt, an dem strace nützlich wird. Starten Sie den Dienst mit /usr/bin/strace bash und suchen Sie nach open, read, stat und vielleicht noch connect. Dies wird Ihnen Aufschluss darüber geben, welche Dateien Sie kopieren müssen. Aber in den meisten Fällen kopieren Sie einfach die passwd-datei (editieren sie die Kopie und entfernen Sie die Benutzer, die mit dem Dienst nichts zu tun haben), /dev/zero, /dev/log und /dev/random.

11.b. User Mode Linux

Ein weiterer Weg eine besser gesicherte Umgebung zu erstellen besteht darin, eine virtuelle Maschine zu verwenden. Eine virtuelle Maschine ist, wie der Name schon sagt, ein Prozess der auf dem wirklichen Betriebssystem läuft und eine Hardware- und Betriebssystemumgebung vorspiegelt, welche eine eigene Maschine zu sein scheint. Der Sicherheitsgewinn hierbei ist, dass bei einer Kompromittierung der virtuellen Maschine lediglich diese betroffen ist und nicht die übergeordnete Installation.

Für weitere Informationen zum Aufsetzen von User Mode Linux können Sie den User Mode Linux Guide (englisch) zu Rate ziehen.

12. Firewalls

12.a. Eine Firewall

Oftmals wird eine Firewall als die ultimative Sicherheitsmaßnahme bezeichnet - was aber falsch ist. In den meisten Fällen kann eine falsch konfigurierte Firewall ein System sogar noch unsicherer machen, als es ohne eine Firewall wäre. Eine Firewall ist auch Software und sollte genau so wie jeder andere Dienst behandelt werden, denn auch hier können Bugs vorhanden sein.

Also denken Sie nach, bevor Sie eine Firewall in Betrieb nehmen! Brauchen Sie wirklich eine? Wenn Sie der Meinung sind, dass Sie eine brauchen, dann verfassen Sie eine Richtlinie wie sie funktionieren sollte, welcher Art sie sein soll und wer sie betreiben sollte. Aber lesen Sie zuerst diesen Leitfaden.

Firewalls werden für folgende zwei Zwecke verwendet:

• Um Benutzer (Würmer/Angreifer) draußen zu halten
• Um Benutzer (Angestellte/Kinder) drinnen zu halten

Es gibt im Allgemeinen drei Arten von Firewalls:

• Paketfilter
• Circuit Relay
• Applikationsgateway

Eine Firewall sollte auf einer dedizierten Maschine ohne weitere Dienste laufen (und wenn, dann höchstens noch sshd) und so abgesichert werden, wie dieser Leitfaden es vorschlägt.

12.b. Paketfilter

Jeglicher Netzwerkverkehr basiert auf Paketen. Große Datenmengen werden in kleinere Pakete zerlegt (da diese einfacher zu handhaben sind) und bei der Ankunft am Ziel wieder zusammengesetzt. Jedes Paket enthält im Header Informationen darüber wie es wohin transportiert werden soll. Und genau diese Informationen macht sich eine Firewall mit Paketfilter zu nutze. Filtern basiert auf:

• Erlauben oder verbieten von Paketen entsprechend der Quell-/Ziel-IP-Adresse
• Erlauben oder verbieten von Paketen entsprechend des Quell-/Ziel-Ports
• Erlauben oder verbieten von Paketen entsprechend dem verwendeten Protokoll
• Erlauben oder verbieten von Paketen entsprechend von bestimmten Einstellungen im Protokoll

Mit anderen Worten, diese Filterung basiert auf den Daten im Header eines Pakets und nicht auf dessen Inhalt.

Schwächen:

• Adressinformationen in einem Paket könnten eine vom Sender gefälschte IP-Adresse beinhalten (oder wie wir sagen: vom Sender gespoofed sein).
• Daten oder Anfragen im erlaubten Paket könnten ungewollte Daten enthalten die ein Angreifer zu seinen Zwecken benutzen könnte, um z.B. Schwächen in den Diensten oder hinter der Firewall auszunutzen.
• Normalerweise kann ein Fehler die Firewall unbrauchbar machen

Vorteile:

• Einfach und schnell zu implementieren
• Kann Warnungen zu möglichen Angriffen liefern, bevor diese stattfinden (z.B. erkennen von Portscans).
• Gut geeignet um SYN-Attacken zu stoppen

Beispiele für freie Paketfilter unter Linux:

• iptables
• ipchains
• SmoothWall

12.c. Circuit Relay

Circuit Level Gateways sind Firewalls, die Verbindungen validieren bevor die Erlaubnis für den Datenaustausch erteilt wird. Dies bedeutet, dass Pakete nicht nur aufgrund des Inhalts des Paket-Headers erlaubt oder verboten werden, sondern auch geprüft wird, ob die Verbindung an beiden Enden gültig entsprechend konfigurierbarer Regeln ist, bevor eine Sitzung geöffnet und Datenaustausch erlaubt wird. Filtern basiert auf:

• Quell-/Zieladresse
• Quell-/Zielport
• Zeitraum
• Protokoll
• Nutzer
• Passwort

Jeglicher Verkehr wird validiert, überwacht und ungewollter Verkehr verboten.

Schwächen:

• Operiert auf der Transportebene und kann unter Umständen grundlegende Veränderungen in der Programmierung der Programme, die normalerweise die Transportfunktionen regeln, erfordern.

12.d. Applikationsgateway

Das Gateway auf der Applikationsebene ist ein Proxy für Anwendungen, die Daten mit einem entfernenten System im Auftrag der Clients austauscht. Es wird sicher vor der Öffentlichkeit hinter einer DMZ (De-Militarized Zone, demilitarisierte Zone: der Abschnitt eines privaten Netzwerkes, welches durch die Firewall sichtbar ist), oder einer Firewall die keine Verbindung von der Außenwelt erlaubt, geschützt. Filterung basiert auf:

• Erlauben oder verbieten basierend auf Herkunfts/Ziel IP-Adresse
• Basiert auf dem Paketinhalt
• Dateizugriff abhängig von Dateityp oder -erweiterung beschränken

Vorteile:

• Dateien können zwischengespeichert werden - das erhöht die Netzwerkleistung
• Detaillierte Protokollierung aller Verbindungen
• Skaliert gut (manche Proxy-Server können die zwischengespeicherten Daten teilen)
• Kein direkter Zugriff von Außen
• Kann den Paketinhalt sogar "on the fly" modifizieren

Schwächen:

• Die Konfiguration ist Komplex

Applikationsgateways werden als die sicherste Lösung angesehen, da sie nicht als root laufen müssen und die Hosts dahinter aus dem Internet nicht erreichbar sind.

Beispiel eines freien Applikationsgateways:

• Squid

12.e. Iptables

Um iptables zu verwenden, muss es im Kernel aktiviert werden. Ich habe sie als Module hinzugefügt (das Kommando iptables wird diese wenn benötigt laden) und den Kernel neu kompiliert (aber Sie möchten iptables eventuell einkompilieren, wenn Sie ladbare Kernelmodule, wie oben diskutiert, deaktivieren wollen). Für mehr Informationen, wie Sie Ihren Kernel für iptables konfigurieren, lesen Sie Iptables Tutorial Chapter 5: Preparations. Nachdem Sie den Kernel neu kompiliert haben (oder während der Kernel kompiliert wird) müssen Sie den iptables Befehl hinzufügen. Führen Sie einfach nur emerge iptables aus und alles sollte funktionieren.

Probieren Sie nun bitte ob alles funktioniert, indem Sie iptables -L ausführen. Wenn dies fehlschlägt, dann stimmt etwas nicht und Sie müssen die Konfiguration nochmals überprüfen.

Iptables ist der neue und extrem verbesserte Paketfilter in Linux 2.4.x. Es ist der Nachfolger von ipchains aus dem Linux 2.2.x Kernel. Eine der großen Verbesserungen ist, dass iptables nun in der Lage ist "stateful" Paketfilterung durchzuführen. Mit "stateful" Paketfilterung ist es möglich jede etablierte TCP-Verbindung im Auge zu behalten.

Eine TCP Verbindung besteht aus einer Serie von Paketen die Informationen über die Quelladresse, die Zieladresse, den Quell- und Zielport enthält, sowie eine Sequenznummer, welche das verlustfreie Zusammensetzen der Daten ermöglicht. TCP ist im Gegensatz zu UDP ein verbindungsorientiertes Protokoll, UDP stützt sich nicht auf die Verbindung.

Bei der Prüfung der Header der TCP Pakete kann ein "stateful" Paketfilter bestimmen, ob ein empfangenes TCP Paket zur einer bestehenden Verbindung gehört oder nicht und das Paket entweder akzeptieren oder verwerfen.

Mit einem "stateless" Paketfilter is es möglich, dem Paketfilter Pakete durch die Manipulation des TCP Paket Header unterzuschieben, die eigentlich verworfen werden sollten. Dies kann durch das manipulieren des SYN Flag oder anderer Flags im TCP Header erreicht werden, so dass ein böswilliges Paket wie ein Teil einer bestehenden Verbindung aussehen würde (da der Paketfilter selbst keine Überwachung der Verbindungen durchführt). Mit "stateful" Paketfiltern ist es möglich solche Pakete zu verwerfen, da Sie keiner bestehenden Verbindung zuzuordnen sind. Damit wird auch die Möglichkeit von "stealth scans" verhindert; dies ist ein Typ von Portscan, bei dem der Scanner Pakete mit Flags versendet, deren Protokollierung von einer Firewall viel unwahrscheinlicher ist, als bei gewöhnlichen SYN Paketen.

Iptables bietet einige weitere Möglichkeiten wie zum Beispiel NAT (Network Address Translation) und Wiederholungsbegrenzung (rate limiting). Letzteres ist extrem nützlich, wenn man versucht bestimmte DoS (Denial of Service) Angriffe, wie auch einen SYN-Angriff, zu verhindern.

Eine TCP-Verbindung wird durch einen sogenannten Drei-Wege-Handschlag aufgebaut. Wenn eine TCP Verbindung etabliert wird, sendet die Client-Seite ein Paket mit einem SYN Flag an den Server. Wenn die Server-Seite das SYN-Paket empfängt, antwortet sie dem Client mit einem SYN+ACK Paket. Wenn das SYN+ACK vom Client empfangen wurde, erkennt dieser wiederum mit einem dritten ACK-Paket die Verbindung an.

Ein SYN-Angriff geschieht, wenn nur ein SYN-Paket gesendet wird, aber die Antwort auf das SYN+ACK Paket ausbleibt. Der Client kann ein Paket mit einer gefälschten IP-Adresse senden, da es keine Antwort benötigt. Der Server wird beim Empfang eines SYN Paket einen Eintrag in die Warteschleife halb-geöffneter Verbindungen machen und dann auf das finalen ACK warten, bevor der Eintrag gelöscht wird. Die Warteschleife fasst nur eine begrenzte Anzahl von Einträgen, wenn alle Plätze belegt sind können keine neuen Verbindungen aufgebaut werden. Wenn das ACK nicht innerhalb eines begrenzten Zeitraums beim Server ankommt wird der Eintrag automatisch aus der Warteschleife getilgt. Die Timeout Einstellungen variieren, liegen aber generell im Bereich von 30 bis 60 Sekunden oder sogar mehr. Die Clientseite initiiert den Angriff durch das Aussenden einer größtmöglichen Zahl von SYN Paketen mit verschiedenen Quell IP-Adressen. Dadurch wird die Liste halb-geöffneter Verbindungen schnell gefüllt, so dass andere Clients davon abgehalten werden eine legitime Verbindung zu diesem Server aufzubauen.

Hier wird das Ratenlimit besonders hilfreich. Es ist möglich die Anzahl von SYN-Pakten von einer bestimmten Quelle zu begrenzen, aber durch Gebrauch von -m limit --limit 1/s begrenzt dies das Limit der SYN-Pakete für eins pro Quelle und daher begrenzt die SYN-Flut auf unsere Ressourcen.

Jetzt einiger praktischer Kram!

Wenn iptables in den Kernel geladen wird, hat es fünf Aufhänger an die Sie Ihre Regeln hängen können. Sie heißen INPUT, OUTPUT, FORWARD, PREROUTING und POSTROUTING. Diese Listen nennt man Ketten, da sie per zugefügter Regel funktionieren und überprüfen die Regeln eine nach der anderen in der Reihenfolge wie sie hinzugefügt wurden. Wenn eine Regel auf ein Paket nicht zutrifft wird es an die nächste Regel in der Kette weitergeleitet.

Sie können Regeln direkt in die fünf Hauptketten setzen oder Ketten erstellen und diese als Regel zu einer existierenden Kette hinzufügen. Iptables unterstützt die folgenden Optionen.

Zuerst werden wir versuchen alle ICMP-Pakete an unsere Maschine zu blocken - nur um uns mit iptables vertraut zu machen.

# iptables -A INPUT -p icmp -j DROP

Zuerst legen wir die Kette fest, an die es angehängt werden soll, dann das Protokoll und schließlich das Ziel. Das Ziel kann eine vom Benutzer spezifierte Regel oder eines der speziellen Ziele ACCEPT, DROP, REJECT, LOG, QUEUE, MASQUERADE sein. In diesem Fall benutzen wir DROP, welches das Paket ohne irgendeine Antwort an den Client fallen lässt.

Versuchen Sie nun ein ping localhost. Es wird nicht möglich sein eine Antwort zu bekommen, da das komplette ICMP-Protokoll eingehend geblockt wird. Es wird auch nicht möglich sein, andere Maschinen zu pingen, da die ICMP-Antwortpakete nicht mehr von den anderen Rechnern in unseren Rechner kommen können. Leeren Sie die Kette nun um ICMP wieder zum Laufen zu bekommen.

# iptables -F

Nun sehen wir uns die "stateful" Paketfilterung in iptables an. Wenn wir eine Prüfung bezüglich des Verbindungszustandes an eth0 haben wollen, könnten wir dies folgendermaßen aktivieren:

# iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

Dies wird in der INPUT-Kette alle Pakete, die zu einer bereits bestehenden oder einer verwandten Verbindung gehören, akzeptieren. Man könnte auch jedes Paket, dass nicht in der Zustandstabelle abgedeckt wurde, fallen lassen, indem man iptables -A INPUT -i eth0 -m state --state INVALID -j DROP direkt davor aufruft. Dies aktiviert die "stateful" Paketfilterung in iptables indem es die Erweiterung "state" lädt. Wenn Sie nun anderen erlauben wollen sich mit Ihrer Maschine zu verbinden, dann könnten Sie das --state NEW Flag benutzen. Iptables enthält einige unterschiedliche Module für unterschiedliche Anwendungszwecke. Einige dieser Module sind:

Lassen Sie uns nun eine benutzerdefinierte Kette erstellen und in einer der existierenden Ketten einbetten:

(Neue Kette mit einer Regel erstellen)
# iptables -X mychain
# iptables -N mychain
# iptables -A mychain -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
(Die Standardrichtlinie sagt, dass jeglicher ausgehender Verkehr erlaubt ist, aber eingehender verboten.)
# iptables -P OUTPUT ACCEPT
# iptables -P INPUT DROP
(Schließlich hinzufügen zur INPUT-Kette)
# iptables -A INPUT -j mychain

Indem man die Regel in die INPUT-Kette einpasst bekommt man die Richtlinie: Alles darf raus, aber alles reinkommende wird verworfen ("gedroppt").

Man findet Dokumentation in der Netfilter/iptables Dokumentation.

Schauen wir uns nun ein komplettes Beispiel an. In diesem Falle sagt meine Firewall-/Gateway-Richtlinie:

• Verbindungen zur Firewall wird nur über SSH erlaubt (Port 22)
• Das lokale Netz soll Zugriff auf HTTP, HTTPS und SSH haben (DNS sollte auch erlaubt sein)
• ICMP-Verkehr könnte kritische Daten enthalten und sollte deswegen nicht erlaubt sein. Natürlich muss gewisser ICMP-Verkehr erlaubt sein.
• Portscans sollten erkannt und aufgezeichnet werden
• SYN-Angriffe sollten abgewehrt werden
• Jeglicher anderer Verkehr sollte blockiert und aufgezeichnet werden

#!/sbin/runscript
IPTABLES=/sbin/iptables
IPTABLESSAVE=/sbin/iptables-save
IPTABLESRESTORE=/sbin/iptables-restore
FIREWALL=/etc/firewall.rules
DNS1=212.242.40.3
DNS2=212.242.40.51
#inside
IIP=10.0.0.2
IINTERFACE=eth0
LOCAL_NETWORK=10.0.0.0/24
#outside
OIP=217.157.156.144
OINTERFACE=eth1

opts="${opts} showstatus panic save restore showoptions rules"

depend() {
  need net
}

rules() {
  stop
  ebegin "Setze interne Regeln"

  einfo "Setze Standardregel auf fallenlassen"
  $IPTABLES -P FORWARD DROP
  $IPTABLES -P INPUT   DROP
  $IPTABLES -P OUTPUT  DROP

  #Standardregel
  einfo "Erstelle Zustands-Kette"
  $IPTABLES -N allowed-connection
  $IPTABLES -F allowed-connection
  $IPTABLES -A allowed-connection -m state --state ESTABLISHED,RELATED -j ACCEPT
  $IPTABLES -A allowed-connection -i $IINTERFACE -m limit -j LOG --log-prefix \
      "Bad packet from ${IINTERFACE}:"
  $IPTABLES -A allowed-connection -j DROP

  #ICMP Verkehr
  einfo "Erstelle ICMP-Kette"
  $IPTABLES -N icmp_allowed
  $IPTABLES -F icmp_allowed
  $IPTABLES -A icmp_allowed -m state --state NEW -p icmp --icmp-type \
      time-exceeded -j ACCEPT
  $IPTABLES -A icmp_allowed -m state --state NEW -p icmp --icmp-type \
      destination-unreachable -j ACCEPT
  $IPTABLES -A icmp_allowed -p icmp -j LOG --log-prefix "Bad ICMP traffic:"
  $IPTABLES -A icmp_allowed -p icmp -j DROP

  #Eingehender Verkehr
  einfo "Erstelle Kette für eingehenden SSH-Verkehr"
  $IPTABLES -N allow-ssh-traffic-in
  $IPTABLES -F allow-ssh-traffic-in
  #Flood-Schutz
  $IPTABLES -A allow-ssh-traffic-in -m limit --limit 1/second -p tcp --tcp-flags \
      ALL RST --dport ssh -j ACCEPT
  $IPTABLES -A allow-ssh-traffic-in -m limit --limit 1/second -p tcp --tcp-flags \
      ALL FIN --dport ssh -j ACCEPT
  $IPTABLES -A allow-ssh-traffic-in -m limit --limit 1/second -p tcp --tcp-flags \
      ALL SYN --dport ssh -j ACCEPT
  $IPTABLES -A allow-ssh-traffic-in -m state --state RELATED,ESTABLISHED -p tcp --dport ssh -j ACCEPT

  #Ausgehender Verkehr
  einfo "Erstelle Kette für ausgehenden SSH-Verkehr"
  $IPTABLES -N allow-ssh-traffic-out
  $IPTABLES -F allow-ssh-traffic-out
  $IPTABLES -A allow-ssh-traffic-out -p tcp --dport ssh -j ACCEPT

  einfo "Erstelle Kette für ausgehenden DNS-Verkehr"
  $IPTABLES -N allow-dns-traffic-out
  $IPTABLES -F allow-dns-traffic-out
  $IPTABLES -A allow-dns-traffic-out -p udp -d $DNS1 --dport domain \
      -j ACCEPT
  $IPTABLES -A allow-dns-traffic-out -p udp -d $DNS2 --dport domain \
     -j ACCEPT

  einfo "Erstelle Kette für ausgehenden http/https Verkehr"
  $IPTABLES -N allow-www-traffic-out
  $IPTABLES -F allow-www-traffic-out
  $IPTABLES -A allow-www-traffic-out -p tcp --dport www -j ACCEPT
  $IPTABLES -A allow-www-traffic-out -p tcp --dport https -j ACCEPT

  #Portscanner fangen
  einfo "Erstelle Portscan-Erkennungs-Kette"
  $IPTABLES -N check-flags
  $IPTABLES -F check-flags
  $IPTABLES -A check-flags -p tcp --tcp-flags ALL FIN,URG,PSH -m limit \
      --limit 5/minute -j LOG --log-level alert --log-prefix "NMAP-XMAS:"
  $IPTABLES -A check-flags -p tcp --tcp-flags ALL FIN,URG,PSH -j DROP
  $IPTABLES -A check-flags -p tcp --tcp-flags ALL ALL -m limit --limit \
      5/minute -j LOG --log-level 1 --log-prefix "XMAS:"
  $IPTABLES -A check-flags -p tcp --tcp-flags ALL ALL -j DROP
  $IPTABLES -A check-flags -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG \
      -m limit --limit 5/minute -j LOG --log-level 1 --log-prefix "XMAS-PSH:"
  $IPTABLES -A check-flags -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP
  $IPTABLES -A check-flags -p tcp --tcp-flags ALL NONE -m limit \
      --limit 5/minute -j LOG --log-level 1 --log-prefix "NULL_SCAN:"
  $IPTABLES -A check-flags -p tcp --tcp-flags ALL NONE -j DROP
  $IPTABLES -A check-flags -p tcp --tcp-flags SYN,RST SYN,RST -m limit \
      --limit 5/minute -j LOG --log-level 5 --log-prefix "SYN/RST:"
  $IPTABLES -A check-flags -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
  $IPTABLES -A check-flags -p tcp --tcp-flags SYN,FIN SYN,FIN -m limit \
      --limit 5/minute -j LOG --log-level 5 --log-prefix "SYN/FIN:"
  $IPTABLES -A check-flags -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP

  # Ungültige Zustände in den Ketten einpassen
  einfo "Passe Ketten in INPUT an"
  $IPTABLES -A INPUT -m state --state INVALID -j DROP
  $IPTABLES -A INPUT -p icmp -j icmp_allowed
  $IPTABLES -A INPUT -j check-flags
  $IPTABLES -A INPUT -i lo -j ACCEPT
  $IPTABLES -A INPUT -j allow-ssh-traffic-in
  $IPTABLES -A INPUT -j allowed-connection

  einfo "Passe Ketten in FORWARD an"
  $IPTABLES -A FORWARD -m state --state INVALID -j DROP
  $IPTABLES -A FORWARD -p icmp -j icmp_allowed
  $IPTABLES -A FORWARD -j check-flags
  $IPTABLES -A FORWARD -o lo -j ACCEPT
  $IPTABLES -A FORWARD -j allow-ssh-traffic-in
  $IPTABLES -A FORWARD -j allow-www-traffic-out
  $IPTABLES -A FORWARD -j allowed-connection

  einfo "Passe Ketten in OUTPUT an"
  $IPTABLES -A OUTPUT -m state --state INVALID -j DROP
  $IPTABLES -A OUTPUT -p icmp -j icmp_allowed
  $IPTABLES -A OUTPUT -j check-flags
  $IPTABLES -A OUTPUT -o lo -j ACCEPT
  $IPTABLES -A OUTPUT -j allow-ssh-traffic-out
  $IPTABLES -A OUTPUT -j allow-dns-traffic-out
  $IPTABLES -A OUTPUT -j allow-www-traffic-out
  $IPTABLES -A OUTPUT -j allowed-connection

  #erlaube den Clients über NAT (Network Address Translation) zu routen
  $IPTABLES -t nat -A POSTROUTING -o $OINTERFACE -j MASQUERADE
  eend $?
}

start() {
  ebegin "Starte firewall"
  if [ -e "${FIREWALL}" ]; then
    restore
  else
    einfo "${FIREWALL} existiert nicht. Benutze Standardregeln."
    rules
  fi
  eend $?
}

stop() {
  ebegin "Halte Firewall an"
  $IPTABLES -F
  $IPTABLES -t nat -F
  $IPTABLES -X
  $IPTABLES -P FORWARD ACCEPT
  $IPTABLES -P INPUT   ACCEPT
  $IPTABLES -P OUTPUT  ACCEPT
  eend $?
}

showstatus() {
  ebegin "Status"
  $IPTABLES -L -n -v --line-numbers
  einfo "NAT status"
  $IPTABLES -L -n -v --line-numbers -t nat
  eend $?
}

panic() {
  ebegin "Setze Panikregeln"
  $IPTABLES -F
  $IPTABLES -X
  $IPTABLES -t nat -F
  $IPTABLES -P FORWARD DROP
  $IPTABLES -P INPUT   DROP
  $IPTABLES -P OUTPUT  DROP
  $IPTABLES -A INPUT -i lo -j ACCEPT
  $IPTABLES -A OUTPUT -o lo -j ACCEPT
  eend $?
}

save() {
  ebegin "Sichere Firewallregeln"
  $IPTABLESSAVE > $FIREWALL
  eend $?
}

restore() {
  ebegin "Stelle Firewallregeln wieder her"
  $IPTABLESRESTORE < $FIREWALL
  eend $?
}

restart() {
  svc_stop; svc_start
}

showoptions() {
  echo "Usage: $0 {start|save|restore|panic|stop|restart|showstatus}"
  echo "start)      wird die Standardeinstellung wieder herstellen oder andernfalls zu Regeln zwingen"
  echo "stop)       alle Regeln löschen und alles akzeptieren"
  echo "rules)      Einstellungen der neuen regeln erzwingen"
  echo "save)       speichert die Regeln in ${FIREWALL}"
  echo "restore)    stellt die Regeln von ${FIREWALL} wieder her"
  echo "showstatus) Status anzeigen"
}

Einige Ratschläge für das Erstellen einer Firewall:

1. Erstellen Sie die Richtlinie für die Firewall, bevor Sie diese implementieren.
2. Halten Sie diese einfach
3. Erlangen Sie Wissen über die Protokolle (lesen Sie das passende RFC (Request For Comments))
4. Denken Sie daran, dass eine Firewall ein weiteres Softwarepaket ist, welches als root ausgeführt wird.
5. Testen Sie die Firewall

Wenn Sie denken, dass iptables schwer zu verstehen sind oder es zu lange dauert eine sinnvolle Firewall zu erstellen, dann könnten Sie auch Shorewall benutzen. Es benutzt im Grunde genommen iptables um Firewallregeln zu erstellen, aber es konzentriert sich auf Regeln und nicht auf spezielle Protokolle.

12.f. Squid

Squid ist ein sehr leistungsstarker Proxy Server. Er kann Datenverkehr basierend auf Zeitpunkt, regulären Ausdrücken für Pfad/URI, Quell- und Zieladresse (IP), Domäne, Browser, dem authentifizierten Benutzernamen, MIME-Typ und Port (Protokoll) filtern. Wahrscheinlich habe ich einige Funktionen vergessen, aber es ist schwer die gesamte Liste abzudecken.

Im folgenden Beispiel habe ich einen Banner Filter hinzugefügt, anstatt eines Filters basierend auf pornographischen Seiten. Der Grund dafür ist, dass Gentoo.org nicht als eine pornographische Seite aufgelistet werden sollte. Außerdem will ich meine Zeit nicht damit verbringen einige "gute" Seiten für Sie zu finden.

In diesem Fall diktiert meine Richtlinie:

• Surfen (HTTP/HTTPS) ist während der Arbeitszeiten erlaubt (Mo-Fr 8-17 und Sa 8-13), wenn Angestellte länger da sind, sollten sie arbeiten und nicht surfen.
• Das Herunterladen von Dateien ist nicht erlaubt (.exe, .com, .arj, .zip, .asf, .avi, .mpg, .mpeg etc.)
• Banner sind unerwünscht, daher werden sie herausgefiltert und mit einem transparenten GIF ersetzt (hier können Sie kreativ werden!).
• Jede andere ein- oder ausgehende Verbindung mit dem Internet ist nicht erlaubt.

Dies wird in vier einfachen Schritten implementiert.

# Anbinden an eine IP und einen Port
http_port 10.0.2.1:3128

# Standardkonfiguration
hierarchy_stoplist cgi-bin ?
acl QUERY urlpath_regex cgi-bin \?
no_cache deny QUERY

# Hinzufügen von grundlegenden Listen der Zugriffskontrolle
acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255

# Hinzufügen wer auf diesen Proxy Server zugreifen kann
acl localnet src 10.0.0.0/255.255.0.0

# Und welche Ports
acl SSL_ports port 443
acl Safe_ports port 80
acl Safe_ports port 443
acl purge method PURGE

# Hinzufügen von Listen zur Zugriffskontrolle basierend
# auf regelmäßigen Ausdrücken innerhalb von URLs
acl archives urlpath_regex "/etc/squid/files.acl"
acl url_ads url_regex "/etc/squid/banner-ads.acl"

# Hinzufügen von Listen zur Zugriffskontrolle basierend
# auf Datum und Uhrzeit
acl restricted_weekdays time MTWHF 8:00-17:00
acl restricted_weekends time A 8:00-13:00

acl CONNECT method CONNECT

# Erlauben von Managmentzugriff von Localhost
http_access allow manager localhost
http_access deny manager

# Nur Purge Anfragen von Localhost erlauben
http_access allow purge localhost
http_access deny purge

# Verweigern von Anfragen an unbekannte Ports
http_access deny !Safe_ports

# Verweigern von CONNECT an alle außer SSL Ports
http_access deny CONNECT !SSL_ports

# Meine eigenen Regeln

# Hinzufügen einer Seite zur Darstellung,
# wenn ein Banner entfernt wurde
deny_info NOTE_ADS_FILTERED url_ads

# Dann diese verweigern
http_access deny url_ads

# Verweigern aller Archive
http_access deny archives

# Begrenzung des Zugriffs auf Arbeitszeiten
http_access allow localnet restricted_weekdays
http_access allow localnet restricted_weekends

# Verweigern von allem anderen
http_access deny all

Fügen Sie als nächstes alle Dateitypen ein, von denen Sie nicht wollen, dass Ihre Benutzer sie herunterladen können. Ich habe zip, viv, exe, mp3, rar, ace, avi, mov, mpg, mpeg, au, ra, arj, tar, gz und z Dateien gewählt.

\.[Zz][Ii][pP]$
\.[Vv][Ii][Vv].*
\.[Ee][Xx][Ee]$
\.[Mm][Pp]3$
\.[Rr][Aa][Rr]$
\.[Aa][Cc][Ee]$
\.[Aa][Ss][Ff]$
\.[Aa][Vv][Ii]$
\.[Mm][Oo][Vv]$
\.[Mm][Pp][Gg]$
\.[Mm][Pp][Ee][Gg]$
\.[Aa][Uu]$
\.[Rr][Aa]$
\.[Aa][Rr][Jj]$
\.[Tt][Aa][Rr]$
\.[Gg][Zz]$
\.[Zz]$

Als nächstes fügen wir die regulären Ausdrücke um Banner zu identifizieren ein. Sie werden wahrscheinlich viel kreativer sein als ich:

/adv/.*\.gif$
/[Aa]ds/.*\.gif$
/[Aa]d[Pp]ix/
/[Aa]d[Ss]erver
/[Aa][Dd]/.*\.[GgJj][IiPp][FfGg]$
/[Bb]annerads/
/adbanner.*\.[GgJj][IiPp][FfGg]$
/images/ad/
/reklame/
/RealMedia/ads/.*
^http://www\.submit-it.*
^http://www\.eads.*
^http://ads\.
^http://ad\.
^http://ads02\.
^http://adaver.*\.
^http://adforce\.
adbot\.com
/ads/.*\.gif.*
_ad\..*cgi
/Banners/
/SmartBanner/
/Ads/Media/Images/
^http://static\.wired\.com/advertising/
^http://*\.dejanews\.com/ads/
^http://adfu\.blockstackers\.com/
^http://ads2\.zdnet\.com/adverts
^http://www2\.burstnet\.com/gifs/
^http://www.\.valueclick\.com/cgi-bin/cycle
^http://www\.altavista\.com/av/gifs/ie_horiz\.gif

Nun der letzte Teil: Wir wollen diese Datei anzeigen, wenn das Banner entfernt wird. Es ist im Prinzip eine halbe HTML Datei mit einem 4x4 transparenten GIF Bild.

<HTML>
<HEAD>
<META HTTP-EQUIV="REFRESH" CONTENT="0; URL=http://localhost/images/4x4.gif">
<TITLE>FEHLER: Die angeforderte URL konnte nicht angezeigt werden</TITLE>
</HEAD>
<BODY>
<H1>Anzeige gefiltert!</H1>

Wie Sie sehen können hat Squid eine Vielzahl von Möglichkeiten und ist sehr effektiv zum Filtern und als Proxy. Es kann sogar alternative Squid Proxies benutzen um an sehr große Netzwerke angepasst zu werden. Die Konfiguration, die ich hier aufgelistet habe ist hauptsächlich für kleine Netzwerke mit 1-20 Benutzern geeignet.

Jedoch die Kombination von Paketfilterung (iptables) und dem Applikationsgateway (squid) ist wahrscheinlich die beste Lösung, selbst wenn Squid selber an einem sicheren Ort stationiert ist und niemand von außerhalb darauf zugreifen kann, müssen wir uns weiterhin um Angriffe von Innen Gedanken machen.

Nun müssen Sie den Proxy Server in die Einstellungen des Browsers Ihrer Benutzer einbinden. Das Gateway verhindert, dass die Benutzer jeglichen Kontakt mit der Außenwelt haben, solange sie nicht den Proxy benutzen.

Es kann auch transparent geschehen, indem man iptables benutzt um den gesamten ausgehenden Datenverkehr an einen Squid Proxy weiterzuleiten. Dies kann erreicht werden, indem man eine Weiterleitungs/Prerouting Regel für das Gateway hinzufügt:

# iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to proxyhost:3128
# iptables -t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to proxyhost:3128

12.g. Gelernte Lektionen

Wir lernten, dass:

1. Eine Firewall kann ein Risiko in sich sein. Eine schlecht konfigurierte Firewall ist schlechter als überhaupt keine.
2. Wie man ein grundlegendes Gateway und einen transparenten Proxy erstellt.
3. Der Schlüssel zu einer guten Firewall ist es, die Protokolle zu kennen, die Sie zulassen wollen.
4. Dass IP-Traffic nicht immer legitime Daten beinhaltet, z.B. ein ICMP Paket mit böswilliger Nutzlast.
5. Wie man SYN Angriffen vorbeugt
6. Filtern von HTTP-Traffic indem man anstößige Bilder und das Herunterladen von Viren verhindert.
7. Kombinieren von Paketfiltern und Applikationsgateways geben eine bessere Kontrolle.

Nun, wenn Sie wirklich müssen, erstellen Sie sich eine Firewall, die ihre Bedürfnisse deckt.

13. Aufspüren von Eindringlingen

13.a. AIDE (Advanced Intrusion Detection Environment)

Aide ist ein Host-basierendes Eindringlingserkennungssystem (HIDS, Host-based Intrusion Detection System), eine kostenlose Alternative zu Tripwire (falls Sie bereits mit Tripwire vertraut sind, sollten Sie keine Schwierigkeiten haben die Konfigurationsdateien für Aide zu erlernen). HIDS werden zu Entdeckung von Änderungen an wichtigen Systemkonfigurations- und Binärdateien verwendet. In der Regel, indem sie einen kryptographischen Hash-Wert für jede der zu prüfenden Dateien erstellen und diesen an einem sicheren Ort speichern. In regelmäßigen Abständen (z.B. täglich) werden die als "gut" bekannten Werte mit denen der derzeitigen Kopien der Dateien verglichen, um herauszufinden, ob die Datei geändert wurde. HIDS sind eine gute Methode um unerlaubte Änderungen am System zu entdecken, aber es braucht ein wenig Arbeit sie ordentlich einzurichten und gut zu verwenden.

Die Konfigurationsdatei basiert auf regulären Ausdrücken, Makros und Regeln für Dateien und Verzeichnisse. Wir haben die folgenden Makros:

Diese Makros sind sehr praktisch, wenn Sie mehr als ein Gentoo System haben und auf allen Aide benutzen wollen. Aber nicht alle Maschinen haben dieselben Dienste oder gar Benutzer.

Als nächstes haben wir Gruppen von Flags um Überprüfungen an Dateien und Ordnern durchzuführen. Diese sind eine Kombination aus Berechtigungen, Dateieigenschaften und kryptographischen Hashes/Prüfsummen.

Und wenn Aide mit mhash-Unterstützung kompiliert ist, hat es noch einige weitere Funktionen:

Nun können Sie Ihre eigenen auf den oben genannten Flags basierenden Regeln definieren, indem Sie diese folgendermaßen kombinieren:

All=R+a+sha1+rmd160
Norm=s+n+b+md5+sha1+rmd160

Das letzte was wir tun müssen um unsere eigene Konfigurationsdatei zu erstellen ist zu schauen wie man diese Regeln einer Datei oder einem Verzeichnis hinzufügt. Um eine Regel einzugeben, kombinieren Sie Datei oder Verzeichnis und die Regel. AIDE wird alle Dateien rekursiv hinzufügen, es sei denn Sie spezifizieren eine alternative Regel.

Lassen Sie uns also ein vollständiges Beispiel betrachten:

@@ifndef TOPDIR
@@define TOPDIR /
@@endif

@@ifndef AIDEDIR
@@define AIDEDIR /etc/aide
@@endif

@@ifhost smbserv
@@define smbactive
@@endif

# Der Ort der Datenbank die gelesen werden soll.
database=file:@@{AIDEDIR}/aide.db

# Der Ort der Datenbank, die erstellt werden soll.
database_out=file:aide.db.new

verbose=20
report_url=stdout

# Regeldefinition
All=R+a+sha1+rmd160
Norm=s+n+b+md5+sha1+rmd160

@@{TOPDIR} Norm
!@@{TOPDIR}etc/aide
!@@{TOPDIR}dev
!@@{TOPDIR}media
!@@{TOPDIR}mnt
!@@{TOPDIR}proc
!@@{TOPDIR}root
!@@{TOPDIR}sys
!@@{TOPDIR}tmp
!@@{TOPDIR}var/log
!@@{TOPDIR}var/run
!@@{TOPDIR}usr/portage
@@ifdef smbactive
!@@{TOPDIR}etc/smb/private/secrets.tdb
@@endif
=@@{TOPDIR}home Norm

Im obigen Beispiel definieren wir einige Makros, die angeben wo das topdir beginnt und wo das AIDE Verzeichnis ist. AIDE überprüft die /etc/aide/aide.db Datei wenn die Integrität einer Datei überprüft wird. Jedoch wenn ein Update vorgenommen wird oder eine neue Datei erstellt wird, speichert es die Informationen in /etc/aide/aide.db.new. Dies geschieht, damit die ursprünglich Datenbankdatei nicht automatisch überschrieben wird. Die Option report_URL ist eine noch nicht implementierte Funktion, die wirklich noch keine Bedeutung hat.Die Absicht des Autoren war es, dass es möglich wäre eine Email zu senden oder vielleicht sogar ein Skript auszuführen.

Das AIDE Ebuild enthält seit neuestem eine funktionierende Standardkonfigurationsdatei, ein Hilfsskript und ein Crontab-Skript. Das Hilfsskript erledigt eine Vielzahl von Aufgaben für Sie und stellt ein Interface bereit, dass etwas Skript-freundlicher ist. Um alle verfügbaren Optionen zu betrachten, geben Sie einfach aide --help ein. Alles was benötigt wird um loszulegen ist aide -i und das Crontab-Skript sollte die Datenbank aufspüren und je nach Bedarf täglich Mails versenden. Wir empfehlen, dass Sie sich mit der /etc/aide/aide.conf Datei vertraut machen und sicherstellen, dass dort korrekt wiedergespiegelt wird, was sich auf Ihrem Rechner befindet.

Nun gibt es einige Probleme damit die Datenbankdateien lokal zu speichern, denn der Angreifer wird (wenn er weiß, dass Aide installiert ist) höchstwahrscheinlich versuchen die Datenbankdatei zu verändern, ein Update der Datenbankdatei durchzuführen oder /usr/bin/aide zu verändern. Deswegen sollten Sie eine CD oder anderes Medium erstellen auf das Sie eine Kopie der Datenbankdatei und der Aide Binärdateien ablegen.

Weitere Informationen gibt es auf der AIDE Projektseite.

13.b. Snort

Snort ist ein "Network Intrusion Detection System" (NIDS). Benutzen Sie zur Installation und Konfiguration die folgenden Beispiele.

PIDFILE=/var/run/snort_eth0.pid
MODE="full"
NETWORK="10.0.0.0/24"
LOGDIR="/var/log/snort"
CONF=/etc/snort/snort.conf
SNORT_OPTS="-D -s -u snort -dev -l $LOGDIR -h $NETWORK -c $CONF"

(Schritt 1)
var HOME_NET 10.0.0.0/24
var EXTERNAL_NET any
var SMTP $HOME_NET
var HTTP_SERVERS $HOME_NET
var SQL_SERVERS $HOME_NET
var DNS_SERVERS [10.0.0.2/32,212.242.40.51/32]
var RULE_PATH ./

(Schritt 2)
preprocessor frag2
preprocessor stream4: detect_scans detect_state_problems detect_scans disable_evasion_alerts
preprocessor stream4_reassemble: ports all
preprocessor http_decode: 80 8080 unicode iis_alt_unicode double_encode iis_flip_slash full_whitespace
preprocessor rpc_decode: 111 32771
preprocessor bo: -nobrute
preprocessor telnet_decode

(Schritt 3)
include classification.config

(Schritt 4)
include $RULE_PATH/bad-traffic.rules
include $RULE_PATH/exploit.rules
include $RULE_PATH/scan.rules
include $RULE_PATH/finger.rules
include $RULE_PATH/ftp.rules
include $RULE_PATH/telnet.rules
include $RULE_PATH/smtp.rules
include $RULE_PATH/rpc.rules
include $RULE_PATH/rservices.rules
include $RULE_PATH/dos.rules
include $RULE_PATH/ddos.rules
include $RULE_PATH/dns.rules
include $RULE_PATH/tftp.rules
include $RULE_PATH/web-cgi.rules
include $RULE_PATH/web-coldfusion.rules
include $RULE_PATH/web-iis.rules
include $RULE_PATH/web-frontpage.rules
include $RULE_PATH/web-misc.rules
include $RULE_PATH/web-attacks.rules
include $RULE_PATH/sql.rules
include $RULE_PATH/x11.rules
include $RULE_PATH/icmp.rules
include $RULE_PATH/netbios.rules
include $RULE_PATH/misc.rules
include $RULE_PATH/attack-responses.rules
include $RULE_PATH/backdoor.rules
include $RULE_PATH/shellcode.rules
include $RULE_PATH/policy.rules
include $RULE_PATH/porn.rules
include $RULE_PATH/info.rules
include $RULE_PATH/icmp-info.rules
include $RULE_PATH/virus.rules
# include $RULE_PATH/experimental.rules
include $RULE_PATH/local.rules

config classification: not-suspicious,Not Suspicious Traffic,3
config classification: unknown,Unknown Traffic,3
config classification: bad-unknown,Potentially Bad Traffic, 2
config classification: attempted-recon,Attempted Information Leak,2
config classification: successful-recon-limited,Information Leak,2
config classification: successful-recon-largescale,Large Scale Information Leak,2
config classification: attempted-dos,Attempted Denial of Service,2
config classification: successful-dos,Denial of Service,2
config classification: attempted-user,Attempted User Privilege Gain,1
config classification: unsuccessful-user,Unsuccessful User Privilege Gain,1
config classification: successful-user,Successful User Privilege Gain,1
config classification: attempted-admin,Attempted Administrator Privilege Gain,1
config classification: successful-admin,Successful Administrator Privilege Gain,1

# NEW CLASSIFICATIONS
config classification: rpc-portmap-decode,Decode of an RPC Query,2
config classification: shellcode-detect,Executable code was detected,1
config classification: string-detect,A suspicious string was detected,3
config classification: suspicious-filename-detect,A suspicious filename was detected,2
config classification: suspicious-login,An attempted login using a suspicious username was detected,2
config classification: system-call-detect,A system call was detected,2
config classification: tcp-connection,A TCP connection was detected,4
config classification: trojan-activity,A Network Trojan was detected, 1
config classification: unusual-client-port-connection,A client was using an unusual port,2
config classification: network-scan,Detection of a Network Scan,3
config classification: denial-of-service,Detection of a Denial of Service Attack,2
config classification: non-standard-protocol,Detection of a non-standard protocol or event,2
config classification: protocol-command-decode,Generic Protocol Command Decode,3
config classification: web-application-activity,access to a potentially vulnerable web application,2
config classification: web-application-attack,Web Application Attack,1
config classification: misc-activity,Misc activity,3
config classification: misc-attack,Misc Attack,2
config classification: icmp-event,Generic ICMP event,3
config classification: kickass-porn,SCORE! Get the lotion!,1

Weitere Informationen gibt es auf der Snort Webseite.

13.c. Auffinden von böswilliger Software mit chkrootkit

HIDS wie AIDE sind sehr gut, um Änderungen am System zu bemerken, aber es schadet nie, eine weitere Verteidigungslinie zu haben. chkrootkit ist ein Werkzeug, welches typische Systemdateien auf die Anwesenheit von Rootkits untersucht -- Programme welche entworfen wurden, um das Vorgehen eines Eindringlings zu verstecken und seinen Zugriff aufrecht zu erhalten. Es durchsucht Ihr System auch nach Spuren von Keyloggern und anderer sog. Malware (Schadsoftware). Auch wenn chkrootkit (und Alternativen wie rkhunter) sinnvolle Werkzeuge zur Systempflege und zum Aufspüren eines Eindringlings nach einem Angriff sind, so können sie doch nicht garantieren, dass das System sicher ist.

Die beste Art um mit chkrootkit einen Eindringling aufzuspüren ist es das Programm routinemäßig von cron ausführen zu lassen. Zu Beginn wird mit emerge app-forensics/chkrootkit installiert. chkrootkit kann in der Kommandozeile mit demselben Namen, oder durch cron mit einen Eintrag wie folgt, ausgeführt werden:

0 3 * * * /usr/sbin/chkrootkit

14. Up-to-date bleiben

14.a. Up-to-Date bleiben

Sowie Sie Ihr System erfolgreich installiert haben und sichergestellt haben, dass Sie ein gutes Sicherheitslevel erreicht haben, sind Sie trotzdem noch nicht fertig. Sicherheit ist ein fortschreitender Prozess. Die überwiegende Mehrheit von Einbrüchen stammt von bekannten Sicherheitslücken in nicht gepatchten Systemen. Der wohl wichtigste Schritt zu mehr Sicherheit ist es, dass System up-to-date zu halten.

Wenn Sie eine aktuelle Version von portage installiert haben, dann können Sie zuerst ihren Portage Baum mit emerge --sync synchronisieren und dann den Befehl glsa-check --list ausführen, um zu sehen ob Ihr System in Hinsicht auf Sicherheit aktuell ist. glsa-check ist ein Teil von app-portage/gentoolkit.

# glsa-check -l
WARNUNG: Dieses Tool ist komplett neu und noch nicht ausgiebig getestet.
Daher sollte es nicht in Produktionssystem verwendet werden. Es ist
größtenteils ein Testprogramm für das neue GLSA Release und
Veröffentlichungssystem. Seine Funktionalität wird zu einem späteren
Zeitpunkt in emerge und equery eingewoben werden.
Bitte lesen Sie http://www.gentoo.org/proj/en/portage/glsa-integration.xml
bevor Sie dieses Tool verwenden UND bevor sei ein Bug melden.

[A] means this GLSA was already applied,
[U] means the system is not affected and
[N] indicates that the system might be affected.

200406-03 [N] sitecopy: Multiple vulnerabilities in included libneon ( net-misc/sitecopy )
200406-04 [U] Mailman: Member password disclosure vulnerability ( net-mail/mailman )
.......

Alle Zeilen mit einem [A] und einem [U] können mit ziemlicher Sicherheit ignoriert werden, da das System von diesem GLSA nicht beeinträchtigt wird.

(Überprüfen ob Ihr System von den GLSAs betroffen ist)
# glsa-check -t all
WARNING: This tool is completely new and not very tested, so it should not be
used on production systems. It's mainly a test tool for the new GLSA release
and distribution system, it's functionality will later be merged into emerge
and equery.
Please read http://www.gentoo.org/proj/en/portage/glsa-integration.xml
before using this tool AND before reporting a bug.

This system is affected by the following GLSA:
200504-06
200510-08
200506-14
200501-35
200508-12
200507-16

(Sehen welche Pakete mit emerge installiert werden sollen)
# glsa-check -p $(glsa-check -t all)
     (verkürzte Ausgabe)
Checking GLSA 200504-06
The following updates will be performed for this GLSA:
     app-arch/sharutils-4.2.1-r11 (4.2.1-r10)

     **********************************************************************

     Checking GLSA 200510-08
     The following updates will be performed for this GLSA:
          media-libs/xine-lib-1.1.0-r5 (1.1.0-r4)

(Anwenden benötigter Korrekturen)
# glsa-check -f $(glsa-check -t all)

Wenn Sie einen mometan laufenden Dienst aktualisiert haben, sollten Sie nicht vergessen, diesen neu zu starten.

Ihren Kernel Up-to-date zu halten wird auch empfohlen.

Wenn Sie jedes mal eine Email erhalten möchten wenn ein GLSA herausgegeben wird, dann melden Sie sich für die gentoo-announce Mailingliste an. Instruktionen zum Anmelden und eine größere Menge anderer Mailinglisten finden Sie unter der Gentoo Linux Mailinglistenübersicht.

Eine andere gute Quelle für Sicherheitsinformationen ist die Bugtraq Mailingliste.

Die Inhalte dieses Dokuments sind, sofern nicht explizit anders genannt, unter der Creative Commons - Namensnennung / Weitergabe Lizenz lizenziert. Die Gentoo Name and Logo Usage Guidelines treffen zu.