Wenn man einen Server betreibt, dann legt man normalerweise auch Wert auf Sicherheit (wenn nicht, dann diesen Abschnitt einfach überspringen). Hier zeige ich einige Mittel und Wege auf einen Server sicherer zu machen. Die Liste ist sicherlich nicht komplett und wird es wohl auch nie werden und selbst wenn ihr alles unternehmt, was ich hier aufführe, kann euer System immer noch gehackt werden – totale Sicherheit gibt es nicht – also schiebt die Schuld nicht auf mich, wenn euer System gehackt wurde. Und vor allem: installiert euer System komplett neu, wenn ihr gehackt wurdet!

Verzeichnisse härten

Das /tmp-Verzeichnis ist oft ein Einfalltor für Angreifer, deshalb werden wir dieses nun absichern. Zusätzlich wollen wir auch die Verzeichnisse /var und /home besser schützen, … sowie / bei Fehlern read-only mounten:

/etc/fstab:

proc /proc proc defaults 0 0
none /dev/pts devpts gid=5,mode=620 0 0
/dev/md0 /boot ext2 defaults 0 0
# /dev/md1 belongs to LVM volume group 'vg0'
/dev/vg0/root  /  ext3  defaults,errors=remount-ro 0 1
/dev/vg0/swap  swap  swap  defaults 0 0
/dev/vg0/tmp  /tmp  ext3  rw,noexec,nosuid,nodev 0 0
/dev/vg0/home  /home  ext3  rw,nosuid,nodev 0 2
/dev/vg0/var  /var  ext3  rw,nosuid,nodev 0 2

Quelle: http://www.cromwell-intl.com/security/linux-hardening.html

sshd absichern

Voraussetzung dafür diesen Abschnitt zu implementieren ist, dass es neben root noch mindestens einen anderen Benutzer gibt, denn im folgenden wird root das direkte Anmelden über ssh verboten. Dies erschwert es einem Angreifer root-Rechte zu erlangen, da er erst das Passwort eines Benutzers knacken muss und dann zusätzlich noch das root-Passwort (oder aber er macht es sich einfach und benutzt einfach einen Exploit um sich root-Rechte zu verschaffen). Zudem kann man so immer über “/var/log/auth.log” herausfinden, wer sich als root angemeldet hat.

Als erstes erstellen wir eine Gruppe “sshusers”. Nur Benutzer, die dieser Gruppe angehören, dürfen sich auch am ssh-Server anmelden:

addgroup --system sshusers

Danach fügen wir unseren nicht-root Benutzer dieser Gruppe hinzu:

adduser <Benutzername> sshusers

Nun meine sshd_config:

# Package generated configuration file
# See the sshd(8) manpage for details
 
# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
ListenAddress 78.46.92.6
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes
 
# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768
 
# Logging
SyslogFacility AUTH
LogLevel VERBOSE
 
# Authentication:
LoginGraceTime 30
AllowGroups sshusers
PermitRootLogin no
StrictModes yes
 
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile      %h/.ssh/authorized_keys
 
# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes
 
# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no
 
# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no
 
# Change to no to disable tunnelled clear text passwords
#PasswordAuthentication yes
 
# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
 
# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
 
X11Forwarding no
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no
 
#MaxStartups 10:30:60
Banner /etc/issue.net
 
# Allow client to pass locale environment variables
AcceptEnv LANG LC_*
 
Subsystem sftp /usr/lib/openssh/sftp-server
 
UsePAM yes

Wer auf “security by obscurity” steht, kann auch noch den ssh-Port auf einen nicht Standardport verlegen. Im Grunde genommen bringt es nichts – außer vielleicht Verstimmungen bei den Benutzern, da die Benutzerfreundlichkeit stark leidet und die Tipparbeit steigt – da jeder Portscan, z.b. mit nmap, den ssh-Port preisgibt. Natürlich kann man auf der anderen Seite auch argumentieren, dass primitive DoS-Skripts nur den Standardport ausprobieren und das Umlegen des ssh-Ports doch einen gewissen Schutz bietet.
Zusätzlich kann man noch fail2ban installieren, um sich vor DoS-Attacken über ssh (und auch über viele andere Dienste) zu schützen. Dies wird in einem späteren Abschnitt behandelt und stellt meiner Meinung nach die bessere Alternative zu einem nicht-Standardport dar.

Quellen:

http://root-support.com/blog/?p=183
http://aymanh.com/tips-to-secure-linux-workstation
http://www.pro-linux.de/work/rootserver/teil2.html

forkbombs

Eine forkbomb ist ein DoS-Angriff, bei dem sehr viele Prozesse gestartet werden. So viele, dass der komplette Arbeitsspeicher vollgeschrieben wird und das System somit unbenutzbar wird. Ein Beispiel für eine forkbomb wäre (ACHTUNG: Nicht auf einem Produktivsystem ausführen!):

 :(){ :|:& };:

Um diese Art eines Angriffs (zumindest teilweise) zu verhindern, ändern wir die Datei “/etc/security/limits.conf” dahingehend ab, dass jeder Nutzer der Gruppe “users” (in denen all unsere Konsolennutzer Mitglied sind) maximal 150 Prozesse starten darf:

/etc/security/limits.conf:

@users          soft    nproc  100
@users          hard    nproc  150

Quelle:
http://wiki.craz1.homelinux.com/index.php/Linux:Security:Forkbomb
http://aymanh.com/tips-to-secure-linux-workstation

rkhunter

Dieses Tool dient dem Aufspüren von rootkits. Es hat eine Datenbank mit Signaturen, welche wöchentlich aktualisiert wird und überprüfen täglich über einen cronjob, ob das System potentiell infiziert ist. Wird eine Infizierung/Gefahr festgestellt, verschickt rkhunter eine E-Mail.
Neben rkhunter gibts es auch noch chkrootkit, falls jemand will kann er zusätzlich auch noch dieses Tool installieren.

aptitude install rkhunter chkrootkit

Editieren der Datei “/etc/rkhunter.conf” (hier werden nur die Zeilen angezeigt, die geändert wurden):

DISABLE_TESTS="suspscan deleted_files packet_cap_apps"
ALLOWHIDDENDIR=/etc/.java

/etc/default/rkhunter: (auch nur geänderte Zeilen):

DB_UPDATE_EMAIL="yes"

Diese Einstellungen nehmen einen erweiterten Test für versteckte Prozesse zu den Standardtests auf und nehmen das Verzeichnis “/etc/.java” auf die Whitelist mit auf, damit rkhunter sich nicht bei jedem Scan beschwert, dass er eine verdächtige Datei gefunden hat, nur weil Java installiert ist. Darüber hinaus bekommt man wöchentlich eine E-Mail über die Ergebnisse des Datenbank-Updates.

bastille

Bastille ist ein Tool, welches das Härten eines Systems drastisch vereinfacht. Bastille führt den Nutzer über eine Textberfläche durch verschiedene Fragen und anhand der Antworten des Benutzers wird das System am Schluss verändert. Das Besondere dabei ist, dass bastille alle Aktionen genau und ausführlich erklärt und man die Aktionen auch selbst ausführen kann, anstatt bastille die Ausführung zu überlassen. Bastille wird aktiv von vielen großen Firmen entwickelt und sollte eigentlich zu den Standardwerkzeugen eines jeden verantwortungsbewussten Linux-Administrators gehören, da es viel Arbeit abnimmt und auf Dinge aufmerksam macht, die man sonst evtl. übersieht.

aptitude install bastille

Da das bastille Paket in lenny von Haus aus nicht kompatibel mit lenny ist, muss die Konfigurationsdateien von bastille ändern werden, um bastille vorzugaukeln, dass es kompatibel mit lenny wäre (siehe hier und hier):

/usr/lib/Bastille/API.pm:

sub get_supported_OS_list () {
  my @list = ( "DB2.2", "DB3.0", "DB3.1", "DB4.0", "DB5.0",

/usr/lib/Bastille/IOLoader.pm:

 my $supported_versions = 'DB2.2 DB3.0 DB3.1      DB4.0 DB5.0';

Die Fragen von bastille nach bestem Wissen und Gewissen beantworten und das System so seinen Wünschen nach anpassen.
Bastille legt ein ausführliches Log über die Änderungen an und bietet die Möglichkeit die vorgenommenen Änderungen später wieder rückgängig zu machen.

Quelle:
http://linux.com/feature/118353

/etc/passwd

In diesem Abschnitt geht es darum, die Shells von Systembenutzern auf “/bin/false” bzw. “/bin/nologin” umzustellen, denn die meisten Serverdienste brauchen keinen Konsolenzugriff und stellen in der Standardeinstellung eine gewisse Sicherheitsgefahr dar. Welche Diensten ohne Konsole zurechtkommen, muss man recherchieren oder ausprobieren. Nachdem man einen neuen Serverdienst installiert hat, bietet es sich an diese Datei erneut zu überprüfen und die Konsole der Benutzer ggf. zu ändern.

Beispielhaft zwei Zeilen, wie soetwas aussehen könnte:

man:x:6:12:man:/var/cache/man:/bin/false
mail:x:8:8:mail:/var/mail:/bin/false

fail2ban

Fail2ban ist eine effektive Waffe gegen DoS-Angriffe jedweder Art – und nicht nur das: man kann auch gescheiterte Authentifizierungsversuche über PAM oder Overflow-Angriffe auf Apache eindämmen. Es bringt schon viele vordefinierte Filter (jails), z.B. für ssh und apache, mit und lässt sich zusätzlich über selbstgeschriebene jails erweitern. Es ist über die Datei “/etc/fail2ban/jail.local” anpassbar. Man sollte die Datei “/etc/fail2ban/jail.conf” nicht selbst verändern. Das stellt sicher, dass bei einem Update auch immer die neuesten Regeln und Anpassungen verwendet werden. Über jail.local lässt sich jede Einstellung in jail.conf überschreiben. Bitte genau abwägen, welche jails man aktiviert und welche nicht (falls postfix nicht auf dem Server nicht installiert ist, ist es unsinnig den jail dafür zu aktivieren).

cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

/etc/fail2ban/jail.local:

# Fail2Ban jail.local file
[DEFAULT]
 
ignoreip = 127.0.0.1
bantime  = 600
maxretry = 3
 
backend = polling
destemail = root
 
#
# ACTIONS
#
 
banaction = iptables-multiport
mta = sendmail
protocol = tcp
action = %(action_mwl)s
 
#
# JAILS
#
 
[ssh]
enabled = true
port    = ssh
filter  = sshd
logpath  = /var/log/auth.log
 
[ssh-ddos]
enabled = true
port    = ssh
filter  = sshd-ddos
logpath  = /var/log/auth.log
 
[pam-generic]
enabled = true
filter  = pam-generic
port = all
banaction = iptables-allports
port     = anyport
logpath  = /var/log/auth.log
 
[xinetd-fail]
enabled   = false
filter    = xinetd-fail
port      = all
banaction = iptables-multiport-log
logpath   = /var/log/daemon.log
maxretry  = 2
 
#
# HTTP servers
#
 
[apache]
enabled = true
port    = http,https
filter  = apache-auth
logpath = /var/log/apache*/*error.log
 
[apache-noscript]
enabled = true
port    = http,https
filter  = apache-noscript
logpath = /var/log/apache*/*error.log
 
[apache-overflows]
enabled = true
port    = http,https
filter  = apache-overflows
logpath = /var/log/apache*/*error.log
maxretry = 2
 
#
# Mail servers
#
 
[postfix]
enabled  = true
port     = smtp,ssmtp
filter   = postfix
logpath  = /var/log/mail.log
 
[sasl]
enabled  = true
port     = smtp,ssmtp,imap2,imap3,imaps,pop3,pop3s
filter   = sasl
logpath  = /var/log/mail.log

Quellen:
http://debianclusters.cs.uni.edu/index.php/Fail2Ban:_Preventing_Brute_Force_SSH
http://debaday.debian.net/2007/04/29/fail2ban-an-enemy-of-script-kiddies/

Intrusion Detection System

IDS-Systeme wie tripwire, aide oder fcheck helfen Manipulationen an Dateien festzustellen. Um das bewerkstelligen zu können, wird anfänglich eine Datenbank erstellt mit Hash-Werten der zu überwachenden Ordner und dann werden die Werte regelmäßig überprüft. Stimmen die Hash-Werte nicht mehr überein, wird man per E-Mail benachrichtigt. Der große Nachteil ist natürlich, dass man die Datenbank immer aktuell halten muss und z.B. nach jeden “aptitude update/install/purge/…” ist dies der Fall. Die große Frage ist: Zu welchem Zeitpunkt es interessant ist ein IDS aufzusetzen. Wenn man einen Server ganz neu hat, ändern sich fast täglich Konfigurationsdateien oder es werden neue Pakete installiert, zu einem späteren Zeitpunkt läuft man Gefahr, dass ein Angreifer schon Programme/Konfigurationsdateien ausgetauscht hat und dann ist das IDS bereits nutzlos.
Dieser Abschnitt wird zu einem späteren Zeitpunkt mit Inhalt gefüllt.

iptables

Früher oder später sollte man sich darüber Gedanken machen, ob man eine Firewall/Paketfilter einsetzen will oder nicht, bzw. ob es überhaupt Sinn macht.
Diese Sektion wird zu einem späteren Zeitpunk um Vorschläge für eine kleine Firewall-Konfiguration, bzw. über den Aufbau von iptables-Regeln erweitert.

Netzwerkscanner

Um von außen zu überprüfen, ob der Server sicher ist, kann man Tools wie nmap oder nessus einsetzen. nmap dient dabei dazu offene Ports aufzuspüren, damit man diese ggf. schließen kann. nessus hingegen überprüft, ob der Server anfällig für bestimmte Exploits ist, z.B. anhand der Versionsnummer eines Dienstes. Um es allgemeiner auszudrücken: nessus ist ein Vulnerability (Schwachstellen)-Scanner.

nmap -A -T4 <Serveradresse>

Die Bedienung von nessus ist etwas umfangreicher und an dieser Stelle sei deshalb auf google verwiesen und es wird zum Ausprobieren ermuntert.
Des Weiteren sollte man einen Blick auf netstat werfen. Mit diesem Tool kann man lokal auf dem Server herausfinden, welche Ports geöffnet sind und welcher Dienst sich hinter welchem Port versteckt.
Beispielhafter Aufruf:

netstat -tulpen

Weitere Möglichkeiten sich zu schützen

Dies sind nur einige grundlegende Schritte, die man unternehmen kann, um einen Server abzusichern. Die Liste ist keineswegs vollständig und erhebt auch nicht den Anspruch darauf. Falls jemand weitere Wege kennt, einen Server abzusichern, dann bitte ich um einen Kommentar, bzw. um eine E-Mail und ich werde dieses Howto erweitern.
Empfehlenswert ist natürlich auch das Eintragen in Mailinglisten zum Thema Sicherheit und sich allgemein über sicherheitsrelevante Themen auf dem Laufenden zu halten. Ein weiterer Schritt, um Schwachstellen zu vermeiden ist es, das System immer aktuell zu halten. Das Paketmanagement macht es einem unter Linux sehr einfach und deshalb empfehle ich es aktiv zu nutzen, anstatt Programme selbst zu kompilieren. Normalerweise ist jedes Programm, das man auf einem Server brauchen könnte in den Debian-Repositories enthalten (dass man auf einem Server nur mit den stable-Repositories arbeiten sollte und von testing tunlichst die Finger lassen sollte, brauche ich hier wohl kaum zu erwähnen).
Abschließend bleibt nur noch einmal zu wiederholen, dass es keine absolute Sicherheit gibt und dass man einen guten Kompromiss zwischen Sicherheit und Freiheit (der Nutzer) finden sollte (Hallo, Herr Innenminister).