Network Security

Home

Network Services

Network Security
 Aktuelle Meldungen
 Eigene Advisories
 Archiv
 Suchmaschine
 Lösungen
 Dienstleistungen
 Systeme
   Windows NT/2000
   Unix (allgemein)
   Linux
 Internet-Dienste

Consulting

Workshops/Trainings

Wir über uns
 Kontakt


English Version

Alle Menüs

IPv6 website counter

AERAsec
Network Security
Systeme
Linux


Einige Hinweise für den sicheren Betrieb von Linux Systemen im Netzwerk:

Alle Hinweise ohne Gewähr! Sie sollten unbedingt vor der Installation auf einem Live-Systems an einem Entwicklungssystem getestet werden!

Die standardmäßige Installation einer Linux-Distribution resultiert meist nicht in einem sehr abgesicherten System. Deshalb hier einige Tipps, wie eine Linux Installation durch den Einsatz einfacher Mittel (Zeit und Tools) Linux sicherer gemacht werden kann.

Einfache Tipps zur Härtung des Systems:

  1. Einspielen aller Updates:

    • Meist ist seit der Pressung der CD einer Distribution bzw. des Download der Installationsdateien aus dem Internet etwas Zeit vergangen. Für einige der installierten Programme sind in der Zwischenzeit möglicherweise Sicherheitslücken bekannt geworden, die in neueren Versionen der Programme behoben sind. Deshalb ist dringend zu empfehlen (insbesondere bevor ein Server aus dem Internet erreichbar ist), alle verfügbaren Updates der betreffenden Linux Distibution zu installieren.
    • Red Hat Enterprise Linux Systeme können mit dem Tool up2date auf den aktuellen Stand gebracht werden. Dazu brauchen Sie einen "Subscription Contract" und müssen das System zuerst beim Red Hat Network registrieren:
      up2date --register
      Ein Update aller RPM Pakete auf die neueste Version geschieht dann mit:
      up2date --update
    • Die Distributionen Fedora und CentOS setzen für Online Updates das Programm yum ein. Ein Update aller betroffenen Pakete auf die neueste Version erfolgt als Benutzer Root mit:
      yum update
    • Bei Debian GNU/Linux können Sie Updates einfach mit den Kommandzeilen Utilities apt-get oder aptitude durchführen. Stellen Sie dazu sicher, dass in der Datei /etc/apt/sources.list ein entsprechender Eintrag für die installierte Debian Version (woody, sarge, etch, ...) eingetragen ist, z.B.:
      deb http://security.debian.org/ sarge/updates main
      Ein Update aller betroffenen Pakete wird dann, als Benutzer Root, wie folgt durchgeführt:
      apt-get update
      apt-get upgrade
    • Bei Suse Linux kann ein Paketupdate mit Yast durchgeführt werden.

  2. Einsatz von SecureSHell anstelle von Telnet-Daemon und R-Tools:

    • Der Einsatz Telnet als Zugang über das Netz und den R-Tools ist nur in den wenigsten Fällen notwendig:
      • Verwendung von X-Server auf Hosts, die kein X-Tunneln durch SSH unterstützen können.
      • Backup auf Bandlaufwerke via rmt (Remote Magnetic Tape) - Tunneln durch SSH ist möglich, allerdings wegen der Ver- und Entschlüsselung des Datenstroms nicht sehr performant. (gute Geschwindigkeit bei SSH bietet der "arcfour" Cipher)
    • Falls oben genannte Punkte nicht zum Einsatz kommen, kann der Telnet-Daemon deaktiviert werden und durch die Installation von z.B. OpenSSH ersetzt werden.
      • Eine Liste mit SSH- Clients für Microsoft Windows Systeme ist hier zu finden.
    • Für einige Anwendungsfälle kann SSH, mit dem sftp-server Subsystem, auch einen FTP Server ersetzen.

  3. Deaktivieren aller nicht benötigter Internetdienste:

    • Häufig sind in der Standardinstallation viel mehr Internetdienste aktiviert, als notwendig sind. Welche Dienste aktiv sind, zeigen die folgenden Kommando:
      • IPv4-Services: netstat -lnp --ip
      • IPv6-Services: netstat -lnp --inet6
    • Alle nicht benötigten Dienste können bzw. sollten abgeschaltet werden.
      • Bei einem direkt gestarteten Daemon durch Deaktivieren des Runlevel-Scripts (bei Red Hat Linux z.B. mit chkconfig service off.
      • Bei Programmen, die vom Superdaemon inetd gestarteten werden, durch Auskommentieren der entsprechenden Zeile in der Datei /etc/inetd.conf.
      • Bei Programmen, die vom Superdaemon xinetd gestarteten werden, durch Einfügen der Option disable=yes im jeweiligen Abschnitt in der Datei /etc/xinetd.conf bzw. in den entprechenden Dateien im Verzeichnis /etc/xinetd.d/.

  4. Deinstallation nicht benutzter Programme.

    • Jedes installierte Programm, welches nicht benötigt wird, stellt ein zusätzliches Sicherheitsrisiko dar, insbesondere, wenn das SUID (set user id on execution) oder SGID (set group id on execution) Bit gesetzt ist.
      Auflistung aller Dateien mit gesetztem SUID oder SGID Bit:
      find / -perm +06000 -type f -ls
    • Bei RPM ist es relativ einfach, ein Programmpaket zu deinstallieren, wenn man es nicht benötigt. Eventuell nicht beachtete Abhängigkeiten werden einem angezeigt. Man kann sich dann entscheiden, entweder das Paket auf die 'harte Tour' (--nodeps) oder gleich die Abhängigkeiten mit zu deinstallieren.

Hilfreiche "Schalter" im Linux-Kernel

Weitere Information finden sich im Quelltext des Kernels: /usr/src/linux/Documentation/networking/ip-sysctl.txt

"Schalter" Art Kernel-
version		 Aktivieren (evtl. Kernel neu kompilieren)
Syncookie Support gegen SYN-Flodding 2.2.x
2.4.x
2.6.x		 sysctl -w net.ipv4.tcp_syncookies=1
Limitierung der Rate an ausgesendeten speziellen ICMP-Paketen gegen DoS-Attacken 2.2.x sysctl -w net.ipv4.icmp_destunreach_rate=100
sysctl -w net.ipv4.icmp_echoreply_rate=100
sysctl -w net.ipv4.icmp_paramprob_rate=100
sysctl -w net.ipv4.icmp_timeexceed_rate=100
Limitiert hier auf 1 pro Sekunde
2.4.x
2.6.x		 sysctl -w net.ipv4.icmp_ratemask=6169
6169=0x1819
= 1<<ICMP_ECHOREPLY (0)
+ 1<<ICMP_DEST_UNREACH (3)
+ 1<<ICMP_SOURCE_QUENCH (4)
+ 1<<ICMP_TIME_EXCEEDED (11)
+ 1<<ICMP_PARAMETERPROB (12)
sysctl -w net.ipv4.icmp_ratelimit=100 (1/s)
oder
sysctl -w net.ipv4.icmp_ratelimit=10 (10/s)
Abschalten von ICMP echo-reply auf Broadcast-Adressen gegen Scanning und Smurf Angriffe 2.2.x
2.4.x
2.6.x		 sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=1
Abschalten von ICMP echo-reply generell gegen Scanning 2.2.x
2.4.x
2.6.x		 sysctl -w net.ipv4.icmp_echo_ignore_all=1
Verwerfen von IP-Paketen mit Source-Route-Option gegen Attacken 2.2.x
2.4.x
2.6.x		 sysctl -w net.ipv4.conf.*.accept_source_route=0
Verwerfen von ICMP redirect Paketen gegen Attacken 2.2.x
2.4.x
2.6.x		 sysctl -w net.ipv4.conf.*.accept_redirects=0
Defragmentiere eingehende IP-Pakete immer gegen Attacken 2.2.x sysctl -w net.ipv4.conf.*.ip_always_defrag=1
Loggen von allen Paketen mit unmöglichen IP-Adressen gegen Scanning 2.2.x
2.4.x
2.6.x		 sysctl -w net.ipv4.conf.*.log_martians=1
Abschalten des ICMP Address mask replies gegen Scanning frühere
2.2.x		 sysctl -w net.ipv4.ip_addrmask_agent=0
Deaktivieren von IPv4-forwarding schaltet Routing ab 2.2.x
2.4.x
2.6.x		 sysctl -w net.ipv4.ip_forward=0
Deaktivieren von IPv4-forwarding per Interface
(Entscheidung wird bei "incoming" getroffen!)		 schaltet Routing ab 2.2.x
2.4.x
2.6.x		 sysctl -w net.ipv4.conf.*.forwarding
Abschalten von TCP-Timestamps gegen (NMAP's) Uptime Detektion  (Info) 2.2.x
2.4.x
2.6.x		 sysctl -w net.ipv4.tcp_timestamps=0
Verlegen der Source Port Range für abgehende Verbindungen für sichere Regelsätze bei stateless Filter 2.2.x
2.4.x
2.6.x		 sysctl -w net.ipv4.ip_local_port_range="32768 60999"

Ersetzen von anfälligen Daemons

Achtung, vor dem Ersetzen bitte erst prüfen, ob die gewünschten (nötigen) Features auch weiterhin zur Verfügung stehen...

"Anfälliger" Daemon Ersatz Informationen zur Umstellung Einarbeitung Featureverlust
inetd xinetd andere Konfigurationssyntax leicht keiner
inetd ucspi-tcp anderes Konzept mittel keiner
BIND8/4 BIND9 Code wurde komplett neu geschrieben, aber nahezu gleiche Konfiguration wie BIND8 leicht keiner
BIND8/4 djbdns anderes Konzept mittel unterstützt keine ACLs
sendmail postfix andere Konfigurationssyntax und -dateien mittel kaum, je nach bisherigem Einsatzgebiet
sendmail qmail anderes Konzept, unterstützt nur das Maildir-Format (pro E-Mail eine Datei) nicht trivial bedingt, je nach bisherigem Einsatzgebiet und Einspielen von Patches
syslogd syslog-ng andere Konfigurationssyntax mittel keine, im Gegenteil: umfangreiche Filterbeschreibungssyntax
wu-ftpd proftpd andere Konfigurationssyntax einfach wenig (z.B. keine on-the-fly-compression), dafür viel mehr dedizierte Optionen, TLS optional möglich
wu-ftpd publicfile nur Kommanozeilenoption einfach nur anonymes FTP (in chroot-Umgebung) wird unterstützt
wu-ftpd vsftpd andere Konfigurationssyntax einfach

Schutzmaßnahmen durch den Kernel

Tool Kernel-
version		 Maßnahmen Installation
Openwall Project 2.2.x
2.4.x		 - Non-executable user stack area
- Restricted links in /tmp
- Restricted FIFOs in /tmp
- Restricted /proc
- ...		 Kernel patchen und kompilieren, in OWL (Openwall Linux) bereits integriert
PaX 2.2.x
2.4.x
2.6.x		 - Address space modification protection Kernel patchen und kompilieren, in grsecurity und RSBAC enthalten
ExecShield 2.4.x
2.6.x		 - Ascii Zone
- Address space randomization
- NX data pages		 Kernel patchen und kompilieren, in Red Hat Enterprise Linux und Fedora Core standardmäßig integriert

Zugriffskontrolle / Mandatory Access Control (MAC)

Tool Kernel-
version		 Maßnahmen Installation
AppArmor 2.6.x - obligatorische Kontrolle der Zugriffe von Programmen auf Resourcen Kernel patchen und kompilieren, Konfiguration, in Suse Linux 10.1 und SLES 10 standardmäßig integriert
grsecurity 2.4.x
2.6.x		 - rollenbasierte Zugriffskontrolle
- chroot Einschränkungen
- Auditing Features
- PaX integriert
- ...		 Kernel patchen und kompilieren, Konfiguration
LIDS 2.2.x
2.4.x
2.6.x		 - obligatorische Kontrolle der Zugriffe von Programmen auf Resourcen Kernel patchen und kompilieren, Konfiguration
RSBAC 2.4.x
2.6.x		 - Rule Set Based Access Control
- modulares Framework
- mehrere verschiedene Sicherheitsmodelle
- chroot Einschränkungen
- PaX integriert
- ...		 Kernel patchen und kompilieren, Konfiguration, in Adamantix standardmäßig integriert
SELinux 2.4.x
2.6.x		 - rollenbasierte Zugriffskontrolle
- Type Enforcement
- Multi Level Security
- Multi Category Security		 Kernel patchen und kompilieren, Konfiguration, in Red Hat Enterprise Linux und Fedora Core standardmäßig integriert

Schutz des Prozessstacks durch den Compiler

Tool GCC-
Version		 Maßnahmen Implementierung
StackGuard 2.x - Canary schützt Rückkehradressen Neukompilieren aller Applikationen mit gepatchtem GCC Compiler
Stack-Smashing Protector
(früher ProPolice)		 2.x
3.x
4.x		 - Canary schützt Rückkehradressen und Stack-Frame-Pointer
- Modifizierte Reihenfolge lokaler Variablen
- Kopien von Funktionsargumenten		 Neukompilieren aller Applikationen mit gepatchtem GCC Compiler (SSP ist in GCC 4.1 enthalten)