Was DD-WRT ist

DD-WRT ist aus der von Linksys für ihre Router entwickelten Software entstanden, welche unter der GPL-Lizenz veröffentlicht wurde. Somit steht auch DD-WRT unter GPL und kann kostenlos heruntergeladen und verwendet werden. Es gibt unterschiedliche Versionen die sich im Funktionsumfang und somit auch in der Dateigröße unterscheiden. Darum bitte zuerst einen Blick in die unterstützten Hardware-Router werfen um die passende Version zu finden. Dies ist abhängig von dem im Router verfügbarem Flash-Speicher. Es wird außerdem noch eine kostenpflichtige Spezialversion angeboten.

Vor der Installation der neuen Firmware sollte zuerst eine passende Anleitung gelesen werden. Hilfe kann man im DD-WRT Forum finden. abhängig von der Hardware kann die Installation direkt über die bestehende Firmware installiert werden oder muss in zwei Schritten eingerichtet werden. Dazu wird erst die bestehende Firmware vom Router gelöscht und im zweiten Schritt über TFTP neu installiert. Die Standard-Zugangsdaten sind anschließend root/admin.

Verbindungsprobleme beheben

Je mehr Benutzer oder Programme gleichzeitig über den Router das Internet benutzen, umso mehr Verbindungen muss dieser gleichzeitig verarbeiten und halten. Falls es zu Verbindungsabbrüchen kommt, kann unter Administration->Management bei IP-Filter-Einstellungen die maximal mögliche Anzahl von 4096 bei Maximale Ports eingetragen werden.

WLAN Reichweite erhöhen mit WDS

Ein weiteres Feature von DD-WRT ist der sogenannte WDS-Modus (Wikipedia). Hierüber kann über ein weiteren Router der WLAN-Bereich vergrößert werden. Der Vorteil von WDS gegenüber vielen einzelnen Access-Points ist, dass der Benutzer unterbrechungsfrei von einem Raum zum anderen gehen kann, ohne sich in ein anderes WLAN Einbuchen zu müssen, da überall die gleiche SSID verwendet wird. Für diesen zweiten (bzw. jeden weiteren) Router ist keine Verkabelung über ein LAN-Kabel nötig. Wichtig ist hierbei, dass die Router untereinander per WDS lediglich in einer gedachten Linie verbunden werden und nicht jeder Router mit jedem anderen Router eine WLAN-Verbindung aufbaut, da es sonst zu Routing-Problemen kommt da verschiedene Wege genommen werden könnten. Nachzulesen ist alles in der Anleitung WDS im DD-WRT-Wiki.

mit DynDNS zum eigenen VPN-Server

Ist DynDNS und der PPTP-Server konfiguriert kann man sich von unterwegs zum Büro oder Daheim ins Netzwerk verbinden und sogar mit der IP-Adresse vom DD-WRT-Router surfen, während die Verbindung verschlüsselt wird. Dazu wird neben der Konfiguration von DynDNS unter Services->VPN unter PPTP-Server die lokale IP des Routers bei DNS1, WINS1 und Server-IP eintragen. Unter Client-IP(s) werden die zu vergebenden IP-Adressen hinterlegt, welche natürlich nicht im DHCP-Bereich liegen sollten, z.b. 192.168.0.100-150 um 50 VPN Adressen zu bekommen. Bei CHAP-Secrets werden die Zugangsdaten zeilenweise im Klartext hinterlegt in Form von Username * Password * – Wichtig ist hierbei die Reihenfolge einzuhalten und die Lehrzeichen vor und nach den Sternen bestehen zu lassen. Falls eine Verbindung von Außen nicht klappt, einfach unter NAT / QoS eine Port-Weiterleitung für 1723 auf die Router-IP selber einrichten.

Die Änderung wird direkt in der Haupt-Konfigurations-Datei /etc/proftpd.conf eingepflegt. Angenommen es soll einen Benutzer (ftp-write) mit vollem Zugriff geben und einen Benutzer (ftp-read) welcher lediglich Lesezugriff hat, dann wird die folgenden Konfiguration übernommen:

<Directory /var/www/example.de/ftp-dir>
<Limit WRITE>
AllowUser ftp-write
DenyAll
</Limit>
</Directory>

Falls es keinen Benutzer mit Vollzugriff auf den Ordner geben soll, dann entfällt die Zeile “AllowUser ftp-write” und es wird lediglich ein Benutzer (ftp-read) angelegt.

Damit der Benutzer mit lesendem Zugriff nicht aus seinem Verzeichnis “ausbrechen”, also nicht eine Ebene höher springen kann, ist die folgende Option wichtig:

DefaultRoot ~

ProFTPD Handbuch

Zuerst muss das Rootkitsuchprogramm installiert werden, das geht unter Debian per:

apt-get install chkrootkit

Anschließend wird ein Cronjob angelegt, welcher regelmäßig das System nach Rootkits prüft und im Fehlerfall eine Meldung sendet. Hier macht eine mail2sms Sinn. Der Cronjob unter /etc/cron.d/chkrootkit soll täglich um sechs Uhr laufen, sowohl morgens als auch abends:

MAILTO=”mail2sms@example.com”
0 6,18 * * *  root    /usr/sbin/chkrootkit -q

Leider kommt es dabei auch vermehrt zu Falschmeldungen, dass sollte bedacht werden, wenn pro SMS Kosten entstehen:

You have 1 process hidden for readdir command
You have 1 process hidden for ps command
chkproc: Warning: Possible LKM Trojan installed

Diese Falschmeldungen entstehen wenn andere Programme während der Prüfroutine laufen und sich somit die Anzahl der laufenden Prozese ändert. Chkrootkit entnimmt diese Anzahl den Systemtools (welche ja bereits durch ein Rootkit ersetzt sein können) und vergleicht diese mit seinem eigenen Tools. Läuft beispielsweise ein anderer Cronjob zeitgleich, kann es somit beim Prüfen durch Chkrootkit auf versteckte Prozesse zu der Falschmeldung kommen.

In der Datei /etc/cron.daily/apt-upgrade-simulation wird der folgende Inhalt hinterlegt:

#!/bin/sh
(
apt-get update -qq
apt-get upgrade -s -V
) | /usr/bin/mail -s ‘apt-get upgrade -s’ root

Die Mails werden auch hier wieder lokal an root zugestellt, dies lässt sich jedoch einfach umstellen.

Das Einspielen der Updates muss man natürlich noch selber von Hand übernehmen – ein automatisches Update ist nicht zu empfehlen, da sonst keine Interaktionsmöglichkeit gegeben ist.

Was die Benutzer der deutschen WordPress Version schon vom Update-Monitor her kennen, wurde nun auf die Plugins erweitert. Die Entwickler schreiben dazu im offiziellen Blog:

Our new update notification lets you know when there is a new release of WordPress or when any of the plugins you use has an update available. It works by sending your blog URL, plugins, and version information to our new api.wordpress.org service which then compares it to the plugin database and tells you whats the latest and greatest you can use.

Was konkret bedeutet, dass die Übertragung der folgenden Daten ohne gewollte vorherige Zustimmung erfolgt: Die Versionsnummer der WordPress-Installation, alle installierten Plugins einschließlich Versionsnummer, eine Information darüber, welche von diesen Plugins aktiviert sind, die URL, unter der das Blog im Internet erreichbar ist.

Was umgangssprachlich als “telefoniert nach Hause”-Programmfunktion bekannt ist, lässt sich in diesem Fall auch gar nicht gewollt über die Oberfläche ausstellen. Was liegt also näher als die URL einfach zu blocken:

iptables -A OUTPUT -d api.wordpress.org -j DROP

Wer will (oder muss, da der Blog auf einem gemieteten System läuft) kann sich auf mit einem Plugin behelfen:

Disable WordPress Plugin Updates

SSH (Wikipedia) ist ein Netzwerkprotokoll über welches von extern verschlüsselt der Server gesteuert werden kann und Daten ausgetauscht werden können.

Unter Windows ist ein SSH-Login mit PuTTY (Wikipedia) zur Konfiguration und das kopieren von Dateien mit WinSCP (Wikipedia) möglich.

Sehr unsicher ist jedoch das verwenden eines Kennwortes für den direkten root-Zugriff (Wikipedia) auf den Server. Darum wird zuerst ein eigenes Zertifikat erzeugt, dann der Zugriff eingeschränkt und anschließend das Passwort-Raten per sog. Brute-Force Angriff (Wikipedia) blockiert.

1. eigenes Zertifikat erzeugen

Mit dem Windows Programm PuTTYgen kann ein eigener Schlüssel erzeugt werden. Der Vorteil ist, dass wenn mehrere Server zu betreuen sind, dass man diesen Schlüssel auf jedem Server ablegen kann (siehe dazu Punkt 2. Zugriff einschränken) und auch nicht jedesmal ein Kennwort eingeben muss. Denn dies wird von nun an mit dem zusätzlichen Programm Pageant erledigt.

Das hier verwendete Prinzip setzt auf einem öffentlichen Schlüssel (Wipipedia), der ohne Bedenken weitergegeben werden kann und einem privaten Schlüssel (Wikipedia) auf, welcher mit einem Kennwort und vor fremdem Zugriff geschützt werden muss.

In PuTTYgen wird unter Parameters die Einstellung auf SSH-2 DSA gewählt und mit einem Klick auf Generate der Schlüssel erstellt. Nachdem Mausbewegungen für Zufallsparameter gesorgt haben kann ein Kommentar wie z.B. der eigene Name oder E-Mail Adresse eingegeben werden um später mehrere Schlüssel auseinander zu halten.

Für maximale Sicherheit muss der Schlüssel mit einer Passphrase geschützt werden. Im Unterschied zu einem Passwort kann hier auch ein ganzer Satz eingegeben werden.

Der Public key für OpenSSH wird aus dem Fenster rauskopiert und in einer Textdatei gespeichert. Der mit einer Passphrase geschützten Private key wird mit der Endung .ppk auf der Festplatte gespeichert. Dieser kann später mit Pageant geöffnt werden und verschwindet dann als Icon in der Statuszeile neben der Windows-Uhr, um dann Logins mit PuTTY oder WinSCP automatisch mit dem passenden Schlüssel zu versorgen und so einem Zugriff ohne eine nochmalige Passwort-Eingabe zu ermöglichen.

2. Zugriff einschränken

Der eben eingerichteten und kopierten öffentlichen Schlüssel aus dem Feld Public key für OpenSSH wird nun auf dem Server eingerichtet. Dazu benötigt man zuerst einen neuen Benutzer, wenn man sich vorher nur über root verbunden hat.

adduser –ingroup users –disabled-password BENUTZERNAME

im neu erstellten Home-Verzeichniss wird ein neuer Ordner .ssh erstellt und eine neue Datei authorized_keys erstellt und mit den richtigen Rechten versehen:

mkdir /home/BENUTZERNAME/.ssh
touch /home/BENUTZERNAME/.ssh/authorized_keys
chown -R BENUTZERNAME:users /home/BENUTZERNAME/

In diese neue Datei authorized_keys wird der öffentliche Schlüssel kopiert.

Während die Verbindung mit root-Rechten offen bleibt, wird versucht eine neue zusätzliche Verbindung zum Server aufzunehmen. Klappt alles hat man sich nicht selber ausgesperrt.

Nun ist es soweit den Root-Login auf den Server zu verbieten, in der Datei /etc/ssh/sshd_config wird folgende Einstellung vorgenommen:

PermitRootLogin no

Somit wird in Zukunft, nach einem Neustart von sshd ein direkter Root-Zugriff verhindert:

/etc/init.d/ssh restart

Befehle oder Aktionen, wie das einspielen der Sicherheitsupdates, erfordern natürlich auch weiterhin root-Rechte, die aber für normale Benutzer mit entsprechender Kenntnis des Root-Kennworts einfach zu erlangen sind:

su -

3. Brute-Force Angriffe blockieren

beim verfolgen der Einträge in der Protokolldatei /var/log/auth.log fällt sofort auf, dass hier ständig probiert wird Benutzernamen und entsprechende Passwörter zu raten. Die passiert per Brute-Force und meist sogar ohne Wissen der Benutzer der IP. Dies kann sowohl ein von Viren befallener PC, oder ein gehackter Server sein. Da diese meist im Ausland beheimatet sind, ist eine Meldung oder Anzeige kaum erfolgreich.

Hier hilft nur den Server selber mit einer eigenen Firewall zu schützen. Das Tool iptables (Wikipedia) ist dafür ausgelegt, Pakete zu prüfen und entsprechend eingestellter Regeln zu verwerfen.

Wenn gewünscht ist den Angreifer auszubremsen und ihm so ein Passwort-Raten zu erschweren wird ein Shell-Script angelegt, z.b. bfstopper.sh und mit dem folgenden Inhalt befüllt:

iptables -A INPUT -m state –state ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp –dport ssh -m recent –update –seconds 600 -j DROP
iptables -A INPUT -p tcp –dport ssh –tcp-flags syn,ack,rst syn -m recent –set -j ACCEPT

Somit werden alle wiederholten Verbindungen auf den SSH-Port 22 von der gleichen IP für 600 Sekunden, also 10 Minuten geblockt.

Alternativ gibt es natürlich weitere Methoden, wie das verlegen von SSH auf einen anderen Port, oder ein aktives Pflegen der hosts.allow und hosts.deny Dateien, oder durch das verwenden von fail2ban. Alles etwas überdimensioniert.

OpenSSH
iptables

Hier hilft vorbeugen. Suhosin ist ein umfangreiches Schutzsystem für die eigene PHP Installation. Entwickelt wurde dieser Patch, um Server und Benutzer sowohl vor bekannten und unbekannten Fehlern in PHP Anwendungen als auch im PHP Kern zu schützen. Suhosin besteht aus zwei voneinander unabhängigen Teilen, welche entweder einzeln oder auch kombiniert verwendet werden können.

Der erste Teil ist ein kleiner Patch im PHP Kern, der verschiedene Schutzfunktionen vor low-level Pufferüberläufen und zum Schutz von Format String Schwachstellen, die noch nicht beseitigt wurden oder konsstruktionsbedingt nicht vollständig geschützt werden können.

Der zweite Teil des Suhosin Schutzsystems ist eine mächtige, leistungsfähige PHP Erweiterung, die alle anderen Schutzfunktionen anbietet. Anders als der PHP Patch zur PHP Härtung ist Suhosin binär kompatibel zur PHP Installation und ist ein Mittel, die einer PHP Installation eine binäre Erweiterung beifügt, wie sie beispielsweise auch durch den ZendOptimizer hinzugefügt werden kann. Im weitesten Sinn ist Suhosin also eine Erweiterung für PHP.

Seit Debian Etch ist Suhosin auch als Paket erhältlich und muss also nicht selber kompiliert werden. Da jedoch Debian von Natur aus sehr konservativ gegenüber neuen Version ist, sollte man sich überlegen diese PHP-Pakete von einer externen Quelle zu beziehen.

Hier bietet sich dotdeb.org an. Was genau in die /etc/apt/sources.list eingetragen werden muss um in den Genuss der aktuellsten Pakete zu kommen steht auf der Webseite. Zu Beachten ist jedoch das diese Pakete wie gesagt von einer externen Quelle stammen und Debian entsprechend vor der Installation warnt.

apt-get install php5-suhosin

hiermit installieren wir suhosin. Da es kein gewöhnliches Plugin für Apache ist, muss es auch nicht erst aktiviert werden, sondern ist nach einem Neuladen der Konfiguration mit sofort aktiv:

apache2ctl graceful

Überprüfen wir das Ganze indem wir eine info.php erstellen und die folgenden Zeilen einfügen:

<?
phpinfo();
?>

wir finden dort einen Eintrag wie

This server is protected with the Suhosin Patch 0.9.6.2
Copyright (c) 2006 Hardened-PHP Project

im Error-Log von Apache finden wir nun immer die abgefangenen Anfragen, z.b.

[Thu Jun 28 21:41:50 2007] [error] [client 12.23.34.45] ALERT – configured GET variable value length limit exceeded – dropped variable ‘content’ (attacker ’12.23.34.45′, file ‘/var/www/example.com/www/htdocs/(…).php’), referer: http://example.com/(…).php

Hier noch die Links:

Suhosin
Debain Suhosin
dotdeb

Nicht nur kann man so alles optimal auf seine eigenen Bedürfnisse einstellen, sondern kann auch weitergehend durch Verschlüsselung des E-Mailverkehrs über eigene Zertifikate seine Nachrichten schützen.

E-Mail kann man gut mit Postkarten vergleichen, jeder kann fremde Nachrichten mit minimal technischem Aufwand lesen und verändern. Wie man dies verhindern kann werde ich später erklären.

Als Betreuer oder Besitzers eines Servers ist man selber für alles verantwortlich was von und auf dem eigenen Server passiert. Somit ist es wichtig, dass kein Spam (Wikipedia) direkt über den eigenen Server versandt wird.

Ein sogenanntes Offenes Relay (Wikipedia) lässt sich einfach überprüfen (abuse.net), dabei werden verschiedene Formen des E-Mailversand geprüft und die Ergebnisse direkt angezeigt. Das Ganze lässt sich auch anonym testen.

Es gibt viele Anleitungen einen eigenen Mailserver zu erstellen. Erste Anlaufstelle für Debian-Benutzer wären eigentlich somit die Hilfestellungen von debianhowto.de (de:howtos:sarge:exim4_vexim2_courier_mailman) – der Autor verweist auf die Mailingliste, auf der jedoch nicht so erfreuliche Beträge zu finden sind (lists.debianhowto.de). Zusammengefast wird die Systematik von Debian zerstört, über welche sich neue Pakete installieren lassen und die Konfiguration standardisiert definiert wird. In der Liste wird sogar davon gesprochen, das Updates später unmöglich sind. Also muss etwas anderes her.

Nach einiger Suche hab ich für Debian eine gute Anleitung gefunden. Der Autor Christoph Haas stellt für Debian Sarge (deutsch und englisch) und Etch (englisch) eine ausführliche Anleitung zur Verfügung, die auch sehr gut funktioniert. Verschiedene Domains mit einer Verwaltung über die Datenbank, Spam und Viren-Erkennung und Filterung sind mit eingeschlossen. Das Beste daran ist natürlich, dass alles gut erklärt wird wie es gemacht wird und warum.

ISP-style Email Server with Debian-Etch and Postfix 2.3
ISP-ähnlicher Email Service mit Debian-Sarge und Postfix 2.1
ISP-style Email Service with Debian-Sarge and Postfix 2.1