Lighttpd
Nachdem ich meinen neuen vServer abgesichert habe, geht es nun ans
Eingemachte: die Übertragung meines Weblogs von meinem alten Webspace an
seine neue Heimat. Dazu braucht man lediglich einen Webserver, eine
Datenbank (in der Regel MySQL) und PHP. Wenn es darum geht, einen
Webserver unter Linux zu betreiben, dann stößt man im Internet fast
überall auf den Apache Webserver oder nginx. Daneben gibt es aber noch
eine Reihe anderer, z.T. weniger bekannte Alternativen, die vor allem in
Sachen Ressourcensparsamkeit besonders punkten können. Ein solcher
Kandidat ist Lighttpd oder kurz: lighty Ich
setze lighty schon seit geraumer Zeit auf meinem BananaPi ein um dort
Dienste wie etwa owncloud oder tiny tiny rss nutzen zu können. Gerade in
einer Umgebung mit eingeschränkten Ressourcen bei nicht allzu hohen
Anforderungen (etwa viele gleichzeitige Anfragen an den Webserver) hat
lighty bisher eine exellente Figur gemacht. Klar, dass er deshalb auch
prädestiniert für mein vServer-Projekt ist :-)
Konfiguration
Das schöne an lighty ist die recht simple Konfiguration. Zentraler
Anlaufpunkt für die Konfiguration ist die Datei
/etc/lighttpd/lighttpd.conf. Für meine Konfiguration nutze ich
folgende Module:
Die eigentliche Konfiguration für meine Domain packe ich in den
folgenden Abschnitt. Darin definiere ich zunächst das Rootverzeichnis wo
die eigentliche Wordpressinstallation liegt und die Speicherorte für das
access.log und das error.log; zudem schalte ich das 'directory
listing' aus. Da Lighttpd keine Unterstützung für eine .htaccess Datei
bietet muss der Zugriffsschutz auf bestimmte Dateien auf anderem Wege
eingerichtet werden. Mittels url.access-deny kann man den Zugriff auf
diese Dateien verbieten. Zum Schluss noch eine rewrite-Regel, die ich
hier
gefunden habe, damit die Wordpress Permalinks sauber aufrufbar sind. Der
letzte Abschnitt verhindert, dass mein Weblog über die IP-Adresse
aufgerufen werden kann.
$HTTP["host"] =~ "(www.)?thinkretro.de" {
server.document-root = "/var/www/thinkretro.de"
accesslog.filename = "/var/log/lighttpd/thinkretro.de/access.log"
server.errorlog = "/var/log/lighttpd/thinkretro.de/error.log"
dir-listing.activate = "disable"
url.access-deny = ("wp-config.php", "wp-cron.php", "wp-login.php", "wp-trackback.php", "xmlrpc.php")
url.rewrite = (
"^/(.*)\.(.+)$" => "$0",
"^/(.+)/?$" => "/index.php/$1"
)
}
$HTTP["host"] =~ "138.201.159.234" {
url.access-deny = ( "" )
}
Damit die neue Konfiguration geladen wird muss der Webserver neu
gestartet werden:
#: systemctl restart lighttpd
Wenn auf dem System noch eine Firewall läuft, sollte man zudem den Port
80 freigeben. Sonst sollte man sich nicht wundern, warum man einfach
keine Verbindung zum Webserver von außen herstellen kann. ;-)
Installation von MariaDB und Import des SQL-Dumps
Statt MySQL nutze ich die völlig freie und zu MySQL kompatible Datenbank
MariaDB. Die Installation ist
auch schnell erledigt:
#: sudo apt-get install mariadb-server mariadb-client
#: sudo mysql_secure_installation
Standardmäßig wird bei der Installation u. a. eine Testdatenbank und ein
Benutzeraccount "anonymous" angelegt, der jedem den Login ohne Passwort
erlaubt, daher empfiehlt es sich für eine Produktivumgebung erst einmal
aufzuräumen. Der letzte
Befehl
sorgt u. a. dafür, dass diese Testdatenbank entfernt wird und sich nur
autorisierte Benutzer anmelden dürfen.
Neuen Benutzer anlegen und leere Datenbank erstellen:
Nun gilt es eine neue Datenbank und einen neuen Benutzer zu erstellen.
Anmelden an der Datenbank als root:
$: mysql -u root -p
MariaDB [(none)]> create database if not exists wordpress_db;
MariaDB [(none)]> create user 'wordpress'@'localhost' identified by 'password';
MariaDB [(none)]> grant all on wordpress_db.* to 'wordpress';
MariaDB [(none)]> flush privileges;
MariaDB [(none)]> exit;
Als erstes wird eine leere Datenbank 'wordpress_db' erstellt. Danach
ein neuer Benutzer 'wordpress' mit dem Passwort 'password'. Als nächstes
werden diesem Benutzer alle Rechte an der Datenbank 'wordpress_db'
zugeteilt und zum Schluss die Privilegien aktualisiert und die Datenbank
verlassen. Nun kann man den SQL-Dump in die neue Datenbank importieren:
$: mysql -u wordpress -p wordpress_db < sql_dump.sql
PHP
Die Installation von PHP gestaltet sich hier wesentlich simpler und
einfacher. Installation der benötigten Pakete:
sudo apt-get install php5-cgi php5 php5-mysql
Wenn man nicht den Apache als Webserver einsetzen will, muss man hier
auf die richtige Installationsreihenfolge der Pakete
achten.
Damit der Fast-CGI Prozess vom Webserver gestartet werden kann, muss
noch die entsprechende Konfigurationsdatei /etc/lighttpd/lighttpd.conf
angepasst werden. Dort fügt man ein:
#PHP-fcgi:
fastcgi.server = ( ".php" => ((
"bin-path" => "/usr/bin/php5-cgi",
"socket" => "/tmp/php.socket"
)))
Darüber hinaus muss in der Datei /etc/php5/cgi/php.ini der Kommentar
in der Zeile cgi.fix_pathinfo = 1 entfernt werden.
Was noch fehlt
Wie man sieht, ist die Konfiguration wahrlich kein Hexenwerk und - wenn
man sich mal etwas eingelesen hat - auch recht schnell erledigt. Was
jetzt noch fehlt ist die Umstellung des kompletten Datenverkehrs auf
Https.
Es passiert irgendwie immer wieder. Ich habe jüngst auf einer Partition
Windows 7 installiert und irgendwie wurde (mal wieder) der GRUB
Bootloader überschrieben.
Um das Ganze wieder zu reparieren besorgt man sich zunächst das
entsprechende archlinux-iso
und schreibt dieses auf einen USB Stick und bootet dan von diesem USB
Stick. Das Archlinux-Image nehme ich deshalb, da es praktischerweise
sowohl für x86_32 als auch für x86_64 Systeme passt, man kann nämlich
nicht mit einem 32-bit Linux in eine 64-bit Chroot-Umgebung wechseln.
Welche Laufwerke und Partitionen vorhanden sind erhält man mittels:
$: lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 111,8G 0 disk
├─sda1 8:1 0 72,7G 0 part
└─sda4 8:4 0 39,1G 0 part
sdb 8:16 0 232,9G 0 disk
├─sdb1 8:17 0 100M 0 part
└─sdb2 8:18 0 232,8G 0 part
sdc 8:32 0 596,2G 0 disk
├─sdc1 8:33 0 14,9G 0 part
├─sdc2 8:34 0 156,3G 0 part
└─sdc3 8:35 0 425G 0 part
sdd 8:48 1 1007M 0 disk
└─sdd1 8:49 1 1005M 0 part
sr0 11:0 1 1024M 0 rom
In meinem Fall ist /dev/sda4 meine Linux-Partition. Nun kann man die
chroot-Umgebung vorbereiten:
#: mkdir mnt
#: mount /dev/sda4 mnt/
#: mount -t proc proc mnt/proc
#: mount -t sysfs sys mnt/sys
#: mount -o bind /dev mnt/dev
Als nächstes kann die Chroot-Umgebung betreten werden und grub auf
/dev/sda installiert werden:
#: chroot mnt/ /bin/bash
#: pacman -S grub
#: grub-install /dev/sda
#: grub-mkconfig -o /boot/grub/grub.cfg
Danach die Chroot Umgebung verlassen und die mounts wieder auflösen:
#: exit
#: umount mnt/dev
#: umount mnt/sys
#: umount mnt/proc
#: umount mnt/
#: reboot
Das war's. Wie man sieht eine Sache von ein paar Minuten :-)
Seit geraumer Zeit betreibe ich einen kleinen stromsparenden Server, der
auch über das Internet von überall mittels ssh erreichbar ist. Dieser
dient mir als Zugangspunkt zu meinem Heimnetzwerk, falls ich doch einmal
eine bestimmte Datei o. Ä. unterwegs brauche. Um diesen abzusichern,
sollte man die Standardkonfiguration ein wenig anpassen. Die
Konfigurationsdatei für den SSH-Server findet man unter
'/etc/ssh/sshd_config'.
Port umlegen
Standardmäßig arbeitet der SSH-Server auf dem Port 22. Das ist leider
auch so ziemlich jedem klar, der mit dem Begriff "SSH" etwas anfangen
kann. Was liegt also näher, als einfach einen anderen - möglichst von
keinem anderen Dienst belegten Port - einzustellen. Dazu trägt man in
der 'sshd_config' folgendes ein:
Einziger Nachteil ist, dass man von nun an beim Aufruf von ssh mit der
Option -p explizit den Port angeben muss. Allerdings bietet die Umlegung
des Ports allein keinen wirklichen Sicherheitsgewinn. Ein vollständiger
Portscan würde relativ schnell den richtigen Port enttarnen.
$ ssh -p 12345 user@serveradress.de
Rootlogin verbieten
Auf jeden Fall sollte man die Anmeldung als Root verbieten. So muss ein
potentieller Angreifer nicht nur das Passwort, sondern auch gleich noch
den richtigen Benutzernamen erraten. Um die Anmeldung als Root zu
verbieten muss die Option
...
Permit RootLogin no
...
gesetzt werden. Danach kann man sich nur noch mit einem "normalen" User
anmelden.
SSH-Keypair erzeugen
Wesentlich sicherer als die Eingabe eines bloßen Passwort ist die
Authentifizierung mittels RSA-Key. Dabei wird auf dem Client ein Private
Key und ein Public Key erzeugt und der Public Key anschließend auf den
Server transferiert. Die Erstellung eines RSA-Schlüsselpaars geschieht
über:
Danach kopiert man mittels folgendem Befehl den Schlüssel auf den
Server:
$ ssh-copy-id user@serveradress.de
Von nun an wird man bei der Authentifizierung immer nach der
RSA-Passphrase des RSA-Schlüssels gefragt, statt nach einem regulären
Passwort.
Passwortbasierte Anmeldung verhindern
Hat man einmal eine solche Authentifizierung eingerichtet, kann man
gleich auch die passwortbasierte Anmeldung unterbinden. Der Vorteil ist,
dass sich jetzt nur noch derjenige anmelden kann, der über den passenden
Schlüssel verfügt. Dazu muss man nur folgende Option setzen:
...
PasswortAuthentication no
...
Der Nachteil ist, dass man nun auf seinen private-Key Acht geben muss
und ihn irgendwo sicher aufbewahren muss. Hat man physisch keinen
Zugriff auf den Server, hilft bei Verlust des Schlüssels nur noch ein
trauriger Anruf beim Hoster.
StrictHostKeyChecking
Hat man einmal die Authentifizierung mittels RSA-Keys eingerichtet, ist
man im Prinzip schon recht gut abgesichert gegen Personen, die auf dem
Server nichts zu suchen haben. Hat man allerdings seinen Private-Key
verloren ist es prinzipiell dem Finder möglich sich auf dem Server
einzuloggen (falls er die richtige Passphrase für den Private Key
kennt). Zugegeben, dass sind schon recht viele Wenn's, aber 'Unverhofft
kommt oft :-)'Jedenfalls kann man zusätzlich noch das Strict Host Key
Checking aktivieren. Dazu setzt man folgende Option:
...
StrictHostKeyChecking yes
...
Das bewirkt, dass sich nur dem Server bereits bekannte Hosts anmelden
dürfen. Dabei wird der Client-Host-Key mit denjenigen Keys in der Datei
'\~/.ssh/known_hosts' bzw. '/etc/ssh/known_hosts' abgeglichen.
Fazit
Mit diesen relativ einfachen Mitteln hat man gegenüber der
Standardkonfiguration schon einiges an zusätzlicher Sicherheit gewonnen.
Absolute Sicherheit wird es wohl leider nie geben, sodass man auch
weiterhin Serverlast und die Log-Files auf Unstimmigkeiten überwachen
sollte. Man kann also nur hoffen, dass man es einem potentiellen
Angreifer so schwer wie möglich macht und dass dieser sich dann lieber
weniger aufwändigen Zielen zuwendet.