virtuellen / dedizierten Server absichern

Sie möchten Ihren virtuellen oder dedizierten Server sichern?
Gerade in der Ferienzeit treten vermehrt Vorfälle von Hackversuchen oder DDos-Attacken auf. Sie wollen wissen wie Sie ihren Server davor schützen?Sicherung des Apache Webserver
Um den Apache Webserverdienst gegen DDos zu schützen und ein bisschen sicherer zu machen bietet sich ein ganz bestimmtes Modul des Apache an:mod_evasive
Die Installation ist denkbar einfach:Code:apt-get install libapache2-mod-evasive

fertig
Nun muss man noch die Konfiguration vornehmen, dazu fügt man folgenden Code in die /etc/apache2/apache2.conf ein:
Code:#DOSHashTableSize gibt die Größe der Hashtabelle in Bytes an DOSHashTableSize 3097 #DOSPageCount gibt die Anzahl der Seitenaufrufe eines Clients pro DOSPageInterval-Zeitintervall DOSPageCount 100 #DOSSiteCount gibt die Anzahl der Seitenaufrufe auf einen Child-Prozess pro DOSSiteInterval-Zeitintervall DOSSiteCount 100 #DOSPageIntervall und DOSSiteInterval werden in Sekunden angegeben DOSPageInterval 15 DOSSiteInterval 15 #DOSBlockingPeriod gibt die Sperrzeit in Sekunden an DOSBlockingPeriod 6000 #DOSEmailNotify gibts die eMail Adresse an, an welche eine Warnmail geschickt wird DOSEmailNotify root@localhost #DOSSystemCommand führt bei einem Angriff weitere Programme/Scripte aus wenn gewünscht #DOSSystemCommand „su – someuser -c ‚/sbin/… %s …'“ #DOSLogDir gibt das Verzeichnis an in dem das Modul seine Lock-Datei schreibt #Achtung: der Ordner sollte nur f�r root erreichbar sein DOSLogDir „/var/lock/mod_evasive“ #DOSWhitelist beinhaltet eine Aufzählung aller IP-Adressen für die mod_evasive NICHT gilt #DOSWhitelist 127.0.0.1

Durch die Kommentierung kann man leicht entnehmen welche Einstellungen bei dem jeweiligen Punkt vorgenommen werden müssen. Die richtigen Einstellungen müssen Sie für Ihr System selbst finden.Jetzt noch ein: /etc/init.d/apache2 force-reloadund schon ist der Apache ein kleines bisschen sicherer.Sicherung von SSHAuch immer sehr begehrt: BruteForce Attaken auf den SSH Dienst eines Servers. Hier gibt es viele Möglichkeiten solche Attaken aufzuspüren und zu neutralisieren. Wir haben uns für den Einsatz von DenyHosts entschieden. Warum wird im Punkt 3 klar.Die Installation von DenyHosts ist ebenfalls denkbar einfach unter Debian und Ubuntu:
Code:apt-get install denyhosts

Kurz warten…FERTIG.
Jetzt müssen wir noch ein bisschen die Konfiguration bearbeiten:Code:nano /etc/denyhosts.conf

Hier obliegt es wieder dem Sysadmin sich einen Überblick über die Ausreichend kommentierten Optionen zu verschaffen, sehr wichtig ist:
Code:BLOCK_SERVICE = sshdDENY_THRESHOLD_INVALID = 3DENY_THRESHOLD_VALID = 3DENY_THRESHOLD_ROOT = 3SYNC_SERVER = http://xmlrpc.denyhosts.net:9911

Dann haben wir noch eingestellt, dass sich Denyhosts jede Stunde mit dem Denyhosts Server abgleicht und aus dem Internet eine Liste mit IPs holt, die bereits schon negativ in anderen Systemen aufgefallen sind. Diese Liste wird dann automatisch in /etc/hosts.deny eingetragen.Also dann starten wir DenyHosts mal:
Code:/etc/init.d/denyhosts restart

Und schon werden alle potetiellen Angreifer vom System ausgeschlossen.Aussperren eines AngreifersNun zu dem Punkt, warum wir auf DenyHosts setzen und nicht auf Fail2Ban. Die Möglichkeit sich eine Liste mit IPs zu besorgen läßt uns die Möglichkeit offen, die potetiellen Angreifer direkt auszusperren bevor sich etwas machen, und nicht nur vom SSH Dienst sondern am besten direkt vom ganzen System.Dazu erstellen wir zwei Scripte:
Code:/usr/local/bin/denyiptables.sh

Inhalt:
Code:#!/bin/bashROOT_UID=0E_NOTROOT=67if [ „$UID“ != „$ROOT_UID“ ]; thenecho „Must be root to run this script.“exit $E_NOTROOTfiiptables -Fecho „The following ips are blocked: “ 1> /var/log/block.logfor x in `cat /etc/hosts.deny | grep -v ^# | cut -d : -f 2`; do/usr/local/bin/deny.sh $x >> /var/log/block.logdoneexit 0;

Und:
Code:/usr/local/bin/deny.sh

Inhalt:
Code:#!/bin/bashROOT_UID=0E_NOTROOT=67if [ „$UID“ != „$ROOT_UID“ ]; thenecho „Must be root to run this script.“exit $E_NOTROOTfiiptables -I INPUT -s $1 -j DROPif [ $? != 0 ]; thenecho „block did not work on $1″exit 1;fiecho „$1 was blocked.“exit 0;

Nun noch die richtigen Rechte setzen:
Code:chmod +x /usr/local/bin/deny.sh /usr/local/bin/denyiptables.sh

Was machen diese Scripts?Sie durchsuchen die /etc/hosts.deny Datei (die Denyhosts mit “bösen” IPs füllt) und blocken via iptables diese IPs für das ganze System (also auch für den Webserver, Email etc…)Nun wollen wir das aber nicht immer per Hand ausführen, sondern das soll Cron für uns übernehmen:Als root:Code:crontab -e

Und dann folgendes Einfügen:
Code:*/5 * * * * /usr/local/bin/denyiptables.sh

Damit wird unser Script alle 5 min ausgefüht. Das sollte reichenSystem updatenSehr wichtig: als erstes das System updaten. Auch wenn Sie eine Vorinstallation vom Provider haben, die aktualisieren ihr Template nicht alle 2 Wochen, sondern etwa alle 2 Monate, wenn überhaupt. Deswegen, updaten! Sofort!Wie das geht, ist von Distribution (“Marke” des Linux Systems) unterschiedlich, bei

  • Debian: apt-get update dann apt-get dist-upgrade
  • SuSE: YaST benutzen
  • Andere: RPM benutzen und damit neue Pakete installieren oder lest in Euren Handbüchern zur jeweiligen Distribution nach.

SSH gegen Angriffe absichern, Teil A: root Login verbietenDamit kein Scriptkiddie Ihr SSH oder Ihr root Passwort knacken, sollten Sie von vorneherein den Login mit root über SSH verbieten. Folgende Schritte ausführen:

  1. Erstmal neuen Benutzer anlegen:useradd Name“Name” sollte natürlich nicht “admin”, “login”, “ssh” oder so was sein, das würde ja keinen Sinn machen. Am besten den eigenen Vornamen, oder “Firmen”namen ode ähnlichem, etwas, worauf man nicht so schnell kommt.
  2. Testen, ob Sie mit dem User per SSH reinkommen, sonst sperren Sie sich aus! Und Kennwort festlegen:passwd Nameund dann den Anweisungen auf dem Bildschirm folgen.
  3. In der Datei sshd_config (meist unter /etc/ssh) die Zeile PermitRootLogin yesändern in PermitRootLogin no
  4. Jetzt noch einmal probieren ob man noch mit “root” reinkommt. Wenn ja, SSH per
    /etc/init.d/ssh restart

neu starten.Ab jetzt können Sie sich mit dem neuen Benutzer einloggen (der soweit ja keine Rechte hat und damit eher ein Dummy ist). Mit dem Befehlsu –können Sie zum root-Benutzer wechseln, dabei müssen Sie dann natürlich das Root-Passwort eingeben!SSH gegen Angriffe absichern, Teil B: Auf Protokoll 2 umsteigenIn der Datei sshd_config (meist unter /etc/ssh) folgende Zeile ändern (wenn Ihr Provider das nicht gemacht hat):

Protocol 1

wird zu

Protocol 2

Der wichtigste Bestandteil ist allerdings die Software aktuell zu halten!