Kategorie-Archiv: Linux (Ubuntu)

fail2ban mit WordPress, ownCloud und Squirrelmail

Mit fail2ban lassen sich ganz wunderbar die unzähligen Login-Versuche blockieren, die tagtäglich auf einen Linuxserver einprasseln. Für SSH, Apache und viele weitere Dienste sind Filter vorab konfiguriert. Für WordPress, ownCloud und Squirrelmail ist etwas Handarbeit nötig.

Als Grundlage diente hier eine aktuelle Ubuntu 14.04 Installation. WordPress und ownCloud wurden manuell installiert, Squirrelmail direkt aus den Paketquellen. Letzteres benötigt zusätzlich auch noch das Paket squirrelmail-logger.

Die weiter unten erwähnten fail2ban Filter gehören jeweils ins Verzeichniss /etc/fail2ban/filter.d/, wohingegen die jail.conf sich in /etc/fail2ban/ findet. Ehe mittels
service fail2ban restart
die Filter scharf gestellt werden, lassen diese sich zuvor mittels
fail2ban-regex /pfad/zu/logfile.log /etc/fail2ban/filter.d/filtername.conf
manuell anwenden und debuggen.

Wer eine von den fail2ban Standardeinstellungen (im oberen Teil der jail.conf) abweichende findtime (Zeit in der Login-Fehler gezählt werden) oder bantime (Zeit die die IP gebannt wird) je nach Webservice konfigurieren möchte, kann das ganz analog zum Feld maxretry (Anzahl der Login-Fehler ehe geblockt wird) tun.

WordPress

WordPress schreibt in der Standardkonfiguration auf einem Apache in das access.log einen HTTP-Status Code 200 bei einem gescheiterten Login. Der fail2ban filter apache-wplogin.conf sieht dann wie folgt aus

[Definition]
failregex = <HOST>.*] "POST .*/wp-login\.php HTTP.* 200 .*$
ignoreregex =

und die jail.conf wird um folgenden Block ergänzt

[apache-wplogin]
enabled = true
port = http,https
filter = apache-wplogin
logpath = /var/log/apache*/*access.log
maxretry = 3

ownCloud

Für ownCloud müssen zunächst in der config.php folgende drei Punkte ggf. ergänzt werden

'logtimezone' => 'Europe/Berlin',
'log_type' => 'syslog',
'log_authfailip' => 'true',

um anschließend den fail2ban Filter owncloud.conf zu erstellen

[Definition]
failregex = .*ownCloud.*Login failed:.*, IP:<HOST>.*$
ignoreregex =

und die jail.conf zu erweitern

[owncloud]
enabled = true
port = http,https
filter = owncloud
logpath = /var/log/syslog
maxretry = 3

Squirrelmail

Nachdem das Paket squirrelmail-logger installiert war, hat Squirrelmail von sich aus nach syslog geloggt, daher kann direkt der fail2ban Filter squirremail.conf erstellt werden

[Definition]
failregex = .*squirrelmail: Failed webmail login.* at <HOST>.*$
ignoreregex =

und der entsprechende Block in der jail.conf ergänzt werden

[squirrelmail]
enabled = true
port = http,https
filter = squirrelmail
logpath = /var/log/mail.log
maxretry = 3

Bei der Recherche waren die folgenden Quellen teilweise nützlich:

  • fail2ban und WordPress
  • fail2ban und ownCloud
  • box.net via WebDAV mounten

    Um den Cloud-Speicherdienst box.net (oder andere) via WebDAV direkt unter Linux zu mounten findet sich hier eine tolle Anleitung.

    Seid kurzem sind die Zertifkate von box.net jedoch self-signed oder zumindest nicht mehr unter Ubuntu 12.04 enthalten. Daher klappt der automatische mount nicht mehr. Mit diesem Befehl wird der öffentliche Teil des Zertifikats heruntergeladen und unter dem Namen box.net.cert in der davfs Konfiguration abgelegt.

    $ echo "HEAD / HTTP/1.0\n Host: www.box.net:443\n\n EOT\n" | openssl s_client -prexit -connect www.box.net:443 > /etc/davfs/certs/box.net.cert

    Anschließend muss das Zertifikat noch in der davfs Konfiguration aktiviert werden. Hierzu in der Datei /etc/davfs2/davfs2.conf die entsprechende Zeile ändern:

    servercert box.net.cert

    Jetzt sollte es auch wieder mit dem automatischen mount klappen.

    Gnome 3 und die Netzwerk-Profile

    Nach dem Upgrade auf Ubuntu 11.10 und den Wechsel zu Gnome 3 hatte ich einige Probleme mit dem kabelgebundenen Netzwerk.
    Wie sich herausgestellt hat, lag es an einem alten Profil, dass ich für eine spezielle Verbindung mit statischer IP-Adresse konfiguriert hat. Da es das einzige Profil war, wurde dies stets zuerst gewählt anstatt eine Verbindung via DHCP zu konfigurieren. Klarheit schafft ggf. ein Blick in den „alten“ Netzwerk-Manager, der auch das anlegen neuer Profile erlaubt. Diese tauchen anschließend auch im Gnome 3 Applet auf und können ausgewählt werden.

    $ nm-connection-editor

    Ubuntu 11.04 Backport-Kernel unter Ubuntu 10.04

    Für die LTS Version 10.04 von Ubuntu gibt es inzwischen Backports der Kernel 2.6.35 und 2.6.38 aus Maverick bzw. Natty. Ab 2.6.33 bietet der Kernel mit ext4 unter anderem volle Unterstützung für ATA-TRIM. Die Kernel können direkt aus den Paketquellen installiert werden:

    $ sudo apt-get install linux-image-generic-lts-backport-natty linux-headers-generic-lts-backport-natty

    Falls proprietäre Treiber installiert sind (z.B. NVIDIA) müssen diese noch geupdated werden:

    $ sudo apt-add-repository ppa:ubuntu-x-swat/x-updates && sudo apt-get update
    $ sudo apt-get install nvidia-current nvidia-settings nvidia-current-dev nvidia-current-modaliases

    Nach einem Neustart können die Treiber unter „System -> Systemverwaltung -> Hardware-Treiber“ aktiviert werden. Unter „System -> Systemverwaltung -> Software-Paketquellen“ sollte man ggf. noch das neue Repository deaktivieren, sonst landen weitere Xorg Updates etc… auf dem Rechner.

    Quellen:

  • Backport Kernel
  • NVIDIA Update
  • eGroupware 1.8 unter Ubuntu 10.04

    Seit kurzem ist die Community Version 1.8 von eGroupware erschienen. Um diese unter Ubuntu 10.04 zum laufen zu bekommen sind jedoch noch ein paar kleine Anpassungen nötig. Es wird im Folgenden davon ausgegangen, dass Apache, MySQL und PHP bereits installiert sind.

    Die PHP Version 5.3.2 aus den Ubuntu-Quellen hat einen Fehler, der zum Absturz des Webinterfaces führt. Die aktuelle PHP Version 5.3.3 für Ubuntu 10.04 gibt es in diesem Repository. In Zukunft vielleicht auch in den offiziellen Quellen. Der folgende Befehl fügt das Repository den Paketquellen hinzu.

    $ sudo add-apt-repository ppa:nginx/php5

    Als erstes wird jetzt PHP geupdated.

    $ sudo apt-get update && sudo apt-get upgrade

    Anschließend editiert man die beiden Dateien /etc/php5/cli/php.ini und /etc/php5/apache2/php.ini und sucht nach dem Eintrag data.timezone. Die geänderte Zeile sollte anschließend so aussehen:

    date.timezone = Europe/Berlin

    Das Repository für eGroupware liegt auf den openSUSE Servern. Hierzu muss die folgende Zeile an die /etc/apt/sources.list angefügt werden.

    deb http://download.opensuse.org/repositories/server:/eGroupWare/xUbuntu_10.04/ ./

    Außerdem sollte man noch den Schlüssel des openSUSE Repositories importieren um lästige Nachfragen zu unterbinden.

    $ wget -O - http://download.opensuse.org/repositories/server:/eGroupWare/xUbuntu_10.04/Release.key | apt-key add -

    Jetzt kann eGroupware aus den Paketquellen installiert werden und wird zukünftig auch mit automatischen Updates versorgt.

    $ sudo apt-get update
    $ sudo apt-get install egroupware egroupware-egw-pear

    Während der Installation wird normalerweise eine Datenbank und ein entsprechender User für eGroupware angelegt. Was die weiterführende Konfiguration angeht, verweise ich an dieser Stelle einfach mal auf die offizielle Seite von eGroupware. Wer wie ich bereits die Version 1.6 installiert hatte, sollte die Installation ggf. an dem Punkt abbrechen. Unter den Release Notes der Version 1.8 steht noch ein wenig mehr darüber, wie man eine bestehende Version 1.6 upgraded.

    Kalender und Adressbuch mit Thunderbird synchronisieren.

    Um Kalender und Adressen anschließend durch den eGroupware eigenen GroupDAV-Server mit Thunderbird zu synchronisieren benötigt man die zwei Erweiterungen SOGo Connector und Lightning. Die Lightning Version 1.01b funktioniert mit Thunderbird 3.0.x problemlos. Die Lightning Version 1.02b macht im Zusammenspielt mit Thunderbird 3.1.x jedoch Probleme. Ich empfehle daher nicht nur den SOGo Connector sondern auch die angepasste Lightning Version direkt von Inverse zu nutzen.

    Nicht vergessen: Solange GroupDAV für den entsprechenden User unter eGroupware nicht aktiviert wurde, wird es nicht funktionieren. Das selbe gilt für SyncML, das man zum synchronisieren auf den meisten Handys kann.

    Samba Server

    Um im lokalen Netzwerk von einem Windows Client auf Dateien eines Linux Servers zuzugreifen bietet sich ein Samba Server an. GNOME und KDE bringen auch eine Möglichkeit mit direkt von der grafischen Oberfläche entsprechende Freigaben zu erzeugen. Hier soll jedoch die Installation eines „vollwertigen“ Samba Servers beschrieben werden. Zunächst muss dieser aus den Paketquellen installiert werden.

    $ sudo apt-get install samba

    Alle Benutzer die später über Samba Zugriff erhalten sollen, müssen zunächst in die Samba Benutzerdatenbank aufgenommen werden. Hierbei empfiehlt es sich das selbe Passwort zu vergeben wie für das System.

    $ sudo smbpasswd -a USERNAME

    Anschließend muss die Konfigurationsdatei /etc/samba/smb.conf angepasst werden. Diese ist in Verschiedene, jeweils durch [xyz] gekennzeichnete Abschnitte aufgeteilt.

    [global]
      workgroup = ARBEITSGRUPPE
      usershare allow guests = no

    Die Standardeinstellungen im [global] Block sind sinnvoll. Angepasst werden sollten ggf. nur die beiden Einträge. workgroup gibt die Windows Arbeitsgruppe des Netzwerks an. Um anonyme Gastzugänge zu unterbinden und nur registrierten Benutzern Zugriff zu gestatten sollte usershare allow guests = no gesetzt sein.

    Will man nun für jeden Benutzer (und nur für diesen) das eigene Home-Verzeichnis (und nur dieses) freigeben, so müssen im dafür vorgesehenen Block [homes] nur die Semikolons am Zeilenanfang entfernt werden.

    [homes]
      comment = Home Directories
      browseable = no
      read only = no
      create mask = 0700
      directory mask = 0700
      valid users = %S

    Es gibt auch bereits vorbereitete Freigaben für Drucker [printers] und das CD/DVD-Laufwerk [cdrom]. Auch dort müssen nur die Semikolons entfernt bzw. hinzugefügt werden um die Freigaben zu aktivieren bzw. deaktivieren. Gerade die [cdrom] Freigabe ist sehr praktisch falls das eigene Netbook z.B. kein CD/DVD-Laufwerk besitzt und auch kein externes USB-Laufwerk zur Hand ist.

    FreeNX Remote Desktop Server

    Vorausgesetzt ein Server besitzt überhaupt eine grafische Oberfläche, dann gibt es verschiedene Verfahren um Fernzugriff zu erhalten. Das Methode sollte hohe Performance bieten und auch über eine Internetverbindung gut bedienbar sein. Darüber hinaus sollte das ganze Verfahren am besten durch einen SSH Tunnel verschlüsselt sein. Als Client sollte Linux oder Windows zum Einsatz kommen.

    Da X Forwarding übers Internet einfach zu langsam ist und Windows als Client nicht gerade eine Option, war ich schon kurz davor einen VNC Server aufzusetzen. Wird zuvor ein SSH Tunnel geöffnet kann die gesamte Verbindung auch zuverlässig abgesichert werden. Windows als Client ist dank PuTTy auch kein Problem. Sollen jedoch mehrere Benutzer auf dem Server gleichzeitig remote einloggen ist das nicht so einfach. Durch Zufall und Google stieß ich jedoch auf den Free NX Server von www.nomachine.com und war begeistert.

    • Die Performance ist extrem hoch (selbst über ein normale Internetverbindung lässt sich sehr gut arbeiten)
    • Komplette SSH Verschlüsselung der gesamten Kommunikation
    • Ähnlich dem Windows Remote Desktop können Sitzungen unterbrochen und zu einem späteren Zeitpunkt fortgesetzt werden
    • Client Software existiert für Linux und Windows
    • Mehrere Nutzer können gleichzeitig remote eingeloggt sein
    • Kostenlose Server Version (Limitierung auf max. 2 Benutzer)

    Das NX Protokoll ist eigentlich nur ein Protokoll zur Komprimierung des X Servers. Es werden also nicht wie bei VNC Bilder erstellt und dann übermittelt. Die Bildqualität ist daher sehr hochwertig. Der Client baut zunächst eine Public-Key basierende SSH Verbindung zum Server auf. Anschließend authentifiziert sich der Benutzer gegenüber dem System. Diese erfolgt direkt wenn Passwort Authentifizierung für SSH gestattet ist oder über eine eigene NX Benutzer Datenbank.

    Ich werde im Folgenden die Installation und Konfiguration des Servers unter Ubuntu beschreiben und wie man die Authentifizierung über die NX Benutzer Datenbank einrichtet. Diese hat den Vorteil, dass man für den SSH Server nur das sichere Public-Key-Verfahren zulassen kann.

    Installation und Konfiguration Server

    1. Falls noch nicht geschehen muss der SSH Server installiert werden (siehe SSH Server)
    2. Im Download Bereich von www.nomachine.com müssen unter „NX Free Edition for Linux“ nacheinander
      1. NX Client
      2. NX Node
      3. NX Server

      heruntergeladen und installiert werden. Dies erfolgt mittels dpkg und ist im dortigen Download Bereich erklärt.

    3. Als nächstes muss die Datei /usr/NX/etc/server.cfg angepasst werden. Hierzu editiert man die beiden folgenden Einträge.
    4. EnableUserDB = "1"
      EnablePasswordDB = "1"
    5. Nun wechseln wir ins Verzeichnis /usr/NX/bin/ und fügen einen neuen Benutzer hinzu indem wir nacheinander folgende Befehle ausführen. Der Benutzer sollte anschließend in der Liste erscheinen, die mit dem letzten Befehl angezeigt wird.
    6. $ sudo ./nxserver --useradd USERNAME
      $ sudo ./nxserver --userauth USERNAME
      $ sudo ./nxserver --userenable USERNAME
      $ sudo ./nxserver --passwd USERNAME
      $ sudo ./nxserver --userlist
    7. Als nächstes tauschen wir die bei der Installation mitgelieferten Public-Keys noch gegen einen Neuen aus. Dies ist zwar nicht unbedingt nötig aber sicher ist sicher.
    8. $ sudo /usr/NX/scripts/setup/nxserver --keygen
    9. Die Zugriffsrechte für einige Dateien müssen noch korrekt gesetzt werden.
    10. $ sudo chown nx:root /usr/NX/home/nx/.ssh/authorized_keys2
      $ sudo chmod 0644 /usr/NX/home/nx/.ssh/authorized_keys2
      $ sudo chown nx:root /usr/NX/home/nx/.ssh/default.id_dsa.pub
      $ sudo chmod 0644 /usr/NX/home/nx/.ssh/default.id_dsa.pub
    11. Als letztes tauschen wir den alten privaten Schlüssel auf dem Client aus. Der neue Schlüssel findet sich unter /usr/NX/share/keys/default.id_dsa.key und muss im Client Installationsverzeichnis unter share/keys/ abgelegt werden.

    Installation und Konfiguration Client

    1. Im Download Bereich von www.nomachine.com unter „NX Client Prodcuts“ den passenden Client heruntergeladen und installieren.
    2. Falls der Public-Key geändert wurde (Punkt 5 – Installation Server) muss dieser nun ins Installationsverzeichnis unter share/keys/ kopiert werden.
    3. Startet man nun den Client muss zunächst ein neues Profil eingerichtet werden. Die Schritte sind selbsterklärend. Es ist jedoch wichtig, dass abschließend in den Einstellungen unter Configure... --> General --> Key... der neue Public-Key importiert wird.

    Weiterführende Dokumentation und Hilfe

    Im Support und Documents Bereich von www.nomachine.com finden sich jede Menge gut beschriebene HowTo Anleitungen für die Installation und Administration.

    Es gibt darüber hinaus inzwischen auch eine an Ubuntu angepasste Version. Unter wiki.ubuntuusers.de/FreeNX finden sich mehr Informationen darüber.

    SSH Server

    Einen SSH Server einzurichten um von einem anderen Rechner Zugang zum eigenen Homeserver zu erhalten ist denkbar einfach. Zunächst wird der SSH Server aus den Paketquellen installiert:

    $ sudo apt-get install openssh-server

    Die Konfigurationsdatei findet sich unter /etc/ssh/sshd_config und ist meist schon sehr vernünftig eingestellt. Drei Einträge können jedoch verändert bzw. ergänzt werden um ein zusätzliches Maß an Sicherheit zu erhalten:

    PermitRootLogin no
    PasswordAuthentication no
    AllowUsers USERNAME1 USERNAME2 USERNAME3

    Mit dem ersten Eintrag wird der Login für den Benutzer root unterbunden.
    Der zweite Eintrag unterbindet die Anmeldung mittels Benutzername und Passwort. Nur noch die sichere Anmeldung mittels Public-Key wird gestattet. Es ist wichtig, dass man diese Option erst aktiviert nachdem dem eigenen Public-Key der Zugang gestattet wurde. Andernfalls sperrt man sich selbst aus. Ohne physikalischen Zugang zum Server sieht man dann alt aus.
    Der letzte Punkt beschränkt den Zugang auf die angegebenen Benutzer. Alternativ lassen sich mit AllowGroups, DenyUsers, DenyGroups auch feinere Abstufungen machen. Man könnte z.B. alle Benutzer die einen remote Zugang erhalten sollen in eine Gruppe remoteUsers packen und diese dann freischalten.

    AllowGroups remoteUsers

    Abschließend muss der SSH Server neu gestartet werden um die Änderungen an der Konfigurationsdatei einzulesen.

    $ sudo /etc/init.d/ssh restart

    Projekt Homeserver

    Ich habe endlich Zeit gefunden mein „Projekt Homeserver“ auch schriftlich zu dokumentieren. Den Anfang bildet die Seite Homeserver in welcher ich die Motivation und einige Umbauten an der Hardware beschreibe. Ein Schlosser, etwas schwarzer Lack und eine SSD machen aus einem Shuttle X27D Barebone die ideale Basis für den eigenen lautlosen Homeserver.

    Als nächstes werden Artikel zur Konfiguration einzelner Dienste folgen.