Kategorie: Server

FreeNAS: ZFS-Replication über Wireguard

Posted on by Falk Jeromin

Bisher habe ich für den Abgleich meiner zwei FreeNAS-Boxen OpenVPN verwendet. Wireguard ist eine schnelle Alternative, dafür aber etwas komplizierter vom Setup.

Die ZFS-Replication ist ein praktisches Hilfsmittel, um Daten zwischen zwei FreeNAS-Installation synchron zu halten. Sinn des Ganzen ist die Schaffung eines Offsite-Backups, bei dem die Daten auch einen Wohnungsbrand oder Einbruch überstehen würde, ohne auf externe Cloud-Services zurückzugreifen (was zum einen aus Datenschutz-Aspekten schwierig ist und zum anderen auch ein Kostenfaktor wird, sobald es sich um mehrere Terabyte an Daten handelt).

Anders als OpenVPN ist Wireguard noch nicht Bestandteil von FreeNAS. Man muss es also anderweitig installieren. Um das FreeBSD möglichst unangetastet zu lassen, habe ich mich für eine Debian VM entschieden. Der Grundlegende Datenfluss sieht dann folgendermaßen aus.

  1. Ein ZFS-Snapshot wird erstellt
  2. Die Daten werden über eine statische Route an die Wireguard-Verbindung geleitet
  3. Das 2. FreeNAS-System im Zielnetzwerk verarbeitet die Daten

Dank der statischen Route sieht es für das sendende FreeNAS aus, als würde sich das empfangende im selben Netzwerk befinden. Wireguard liefert anders als OpenVPN eine deutlich bessere Auslastung der Schnittstelle (in meinem Fall VDSL mit 250/40 Mbit/s für FreeNAS-Box 1 und VDSL 50/10 Mbit/s für FreeNAS-Box 2. In Senderichtung liegt das Limit also bei 40 Mbit/s – für den Fall, dass ich das Backup benötige und wieder einspielen muss wäre vermutlich ein Datenträger-Versand schneller. Insgesamt sieht der Aufbau aus wie in dieser Darstellung:

Wireguard als Verbindung zwischen zwei Netzwerken

Wireguard: Peer-IP-Check

Posted on by Falk Jeromin

Wer Wireguard mit Peers benutzt, deren IP-Adresse sich ändert (z.B. weil sie an einem privaten DSL-Anschluss sind), muss regelmäßig die IP-Adresse überprüfen.

Wireguard selbst macht nur beim Starten der Schnittstelle eine DNS-Auflösung um die aktuelle IP-Adresse des Peers zu bekommen. Wenn sich aber z.B. die Adresse des Servers ändert, schlägt die Verbindung irgendwann fehl.

Zum Glück lässt sich dies mit einem kleinen Script, welches z.B. alle 10 Minuten ausgeführt wird, abfangen. Ein Ansatz ist das Script in der Ubuntu-Dokumentation zu Wireguard, welches aber auf meinem Debian-Client nicht ohne weiteres funktionierte (und mir auch etwas kompliziert vorkam). 

#!/bin/bash
# Status von der Schnittstelle überprüfen
# wg0-client: Name der Schnittstelle, die geprüft werden soll
# meinpeer.dyndns.net: der Name des Peers, dessen IP geprüft werden soll
        
cip=$(wg show wg0-client endpoints | grep -E -o "([0-9]{1,3}[\.]){3}[0-9]{1,3}") 	
echo "$cip"
digIP=$(dig +short meinpeer.dyndns.net) # Die Adresse des Peers muss angepasst werden
   echo "$digIP"
     if [ "$digIP" != "$cip" ]
       then
          echo "Daten sind anders"
          /usr/sbin/service wg-quick@wg0-client restart
            
        else 
	  echo "Daten sind gleich"
	  #nichts zu tun
	 fi

Die wesentlichen Elemente des Scripts oben: in Zeile 6 wird mittels der wireguard-tools und grep die aktuelle IP-Adresse, die die Schnittstelle verwendet ermittelt. In Zeile 8 wird geprüft, welche IP-Adresse der Peer aktuell hat. Weichen diese beiden Werte voneinander ab, wird die Wireguard-Schnittstelle in Zeile 13 neu gestartet – dann erfolgt auch die Auflösung der IP-Adresse erneut und die Verbindung steht wieder.

Der Restart der Wireguard-Schnittstelle in Zeile 13 muss ggf. angepasst werden, abhängig davon wie die Schnittstelle in eurem Setup tatsächlich heißt.

Es gibt natürlich noch andere Ansätze, die IP-Auflösung durchzuführen, aber für mein Setup ist dies ein sehr einfacher Weg. Ein Nachteil: sollten mehrere Peers vorhanden sein, klappt dieser Ansatz nicht so einfach – dann müsste man erst einmal den richtigen Peer per Regex ermitteln, um dann dort die entsprechenden Daten auszulesen.

Nötig ist dieses Script für das Aufrechterhalten der Verbindung in meinem FreeNAS-Replications-Setup, welches jetzt mit Wireguard funktioniert.

Warum WordPress-Sicherheit wichtig ist

Posted on by Falk Jeromin

Wer einen kleinen Blog betreibt, mag sich vielleicht denken, dass ein sicheres Passwort oder 2-Faktor-Authentifizierung nicht so wichtig sind.

Das ist jedoch ein Trugschluss: auch ein Blog wenig nur ein paar Dutzend Zugriffen am Tag steht ausreichend im Fokus der „Hacker“, dass es pro Tag mehrere Login-Versuche täglich gibt.

Fail2Ban-Statistiken für drei Tage, nur WordPress-Logins

Mittels eines fail2ban-Plugins (ich verwende https://wp-fail2ban.com/) können fehlgeschlagene Login-Versuche protokolliert werden und die IP-Adressen, von denen die Angriffe ausgehen, blockiert werden.

In meiner Konfiguration werden IP-Adressen nach zwei Versuchen in einem Zeitraum von zwei Stunden für 24 Stunden komplett gesperrt. Die Sperre gilt nicht nur für den Login-Bereich, sondern für alle Seitenaufrufe.

Wer keine Möglichkeit hat, fail2ban für WordPress zu verwenden, sollte trotzdem ein Minimum an Sicherheitshinweisen befolgen: der Username sollte nicht unbedingt „admin“, „root“, „Administrator“ lauten, dass Passwort sollte mindestens 10 Zeichen inkl. Sonderzeichen & Zahlen lang sein und die Dateirechte für WordPress sollten möglichst restriktiv gesetzt sein. Für den letzten Punkt gibt es auf binary-butterfly.de eine sehr gute Anleitung: Dateirechte: warum eigentlich?

Wie sind eure Erfahrungen? Ist eure Webseite schon einmal Opfer eines Hackerangriffs geworden? Welche Sicherheitsmechanismen setzt ihr ein? Über Kommentare würde ich mich freuen!

FreeNAS: SMB/CIFS Auflistung beschleunigen

Posted on by Falk Jeromin

Wer mit FreeNAS eine Windows-Freigabe eingerichtet hat, kann die Zeit, die das Auflisten der Dateien in einem Ordner benötigt, deutlich verkürzen. Dafür müssen einige Parameter an Samba übergeben werden.

Dies lässt sich einfach über die Oberfläche realisieren, indem „Auxiliary Parameter“ für den SMB-Service hinterlegt werden.

ea support = no
store dos attributes = no
map archive = no
map hidden = no
use sendfile= no
aio read size = 1
aio write size = 1
map readonly = no
map system = no

Das Auflisten von Verzeichnissen und Dateien ist nach den Änderungen sehr viel schneller – bisher habe ich es auf die Verbindung mittels WLAN zwischen Client und Server geschoben. Diese funktioniert jedoch reibungslos mit ca. 55 Megabyte pro Sekunde netto Datenrate.

FreeNAS 11.2: neues Webinterface & neue Funktionen

Posted on by Falk Jeromin

Nachdem FreeNAS 10 „Corral“ ein erster – schnell scheiternder – Versuch war, eine neue Benutzeroberfläche einzuführen, gibt es jetzt mit FreeNAS 11.2 ein neues, AngularJS basiertes UI. Dieses ist auch mobil optimiert.

FreeNAS 11.2 Dashboard auf einem HP Microserver Gen8

Abgesehen vom Webinterface, gibt es für FreeNAS 11.2 eine Reihe von Neuerungen, die die bisherige Entwicklung logisch fortführen und erweitern. Die wichtigsten Änderungen:

  • FreeBSD boot-loader anstatt von GRUB
  • Plugins und Jails werden statt von „warden“ von „iocage“ verwaltet, das bisherige System „warden“ wird nicht mehr gepflegt. 
  • Man kann mit verschiedenen Cloud-Diensten synchronisieren, darunter Amazon Cloud Drive, Box, Dropbox, FTP, Google Drive, HTTP, Hubic, Mega, Microsoft OneDrive, pCloud, SFTP, WebDAV, und Yandex. Verschlüsselt werden auch die Daten inklusive Dateinamen vor der Übertragung lokal, sodass kein Risiko für die Daten in der Cloud besteht.
  • Self-Encrypting Drives (SEDs) werden unterstützt, die entsprechenden Daten werden über die Oberfläche gepflegt.
  • ZFS ist auf dem aktuellen Stand – einmal durchgeführt, führt ein Upgrade eines Pools dazu, dass nur aktuelle FreeNAS bzw. FreeBSD-Versionen damit arbeiten können, ein Downgrade ist dann nicht mehr möglich

Das Update ist für bestehende Installation einfach über die Oberfläche möglich, in dem man den Update-„Train“ auf 11.2-stable stellt und nach Updates sucht. Für Neuinstallationen kann man die aktuelle Version auf der FreeNAS-Webseite herunterladen.

Freenas 11.1: integrierten OpenVPN-Client nutzen

Posted on by Falk Jeromin

Seit einiger Zeit benutze ich zwei FreeNAS-Boxen an zwei Standorten, um meine Daten mittels ZFS-Snapshots und Replication zu sichern. Diese Verbindung soll zusätzlich mittels OpenVPN abgesichert werden.

Die Idee: an beiden Standorten jeweils ein Raspberry Pi, die miteinander über OpenVPN verbunden sind, dazu entsprechenden statische Routen, damit sich die beiden FreeNAS-Boxen erreichen können. Grundlage dafür ist der Ansatz, ein OpenVPN-Gateway aufzubauen. 

Aber: es geht auch einfacher. FreeNAS 11.1 verfügt über OpenVPN 2.4.3 und kann damit selbst Verbindungen zu OpenVPN-Servern aufbauen. Der Vorteil:  man benötigt kein komplexes Gateway-Setup, welches mit einem zweiten Raspberry Pi eine weitere Fehlerquelle mit sich bringt.

Die Einrichtung ist einfach: sobald man einen funktionierenden VPN-Server hat, kann man mittels der gängigen Befehle eine Verbindung aufbauen:

/usr/sbin/local/openvpn --config config.ovpn --daemon

Danach erreicht man den Server „am anderen Ende“ unter seiner gewohnten IP-Adresse, z.B. 192.168.178.45. Damit kann man die Replication-Tasks in FreeNAS konfigurieren, als wäre das Ziel im eigenen Netzwerk. Weiterer Vorteil: man benötigt beim Ziel nur einen offenen Port für das VPN und keinen weiteren für SSH. 

OpenVPN auf FreeNAS 11.1

Die Einrichtung des VPN-Servers auf dem Raspberry-Pi kann einfach mittels PiVPN erfolgen. Ich verwende die Raspi im Zielnetzwerk auch dafür, um den FreeNAS-Server zeitgesteuert einzuschalten – das spart Strom in der Zeit, in der eh keine Änderungen an Dateien vorgenommen werden. 

Nginx: IP-Adresse nicht in Log-Files speichern

Posted on by Falk Jeromin

Wer aus Datenschutzgründen – DSGVO ist das Stichwort – möglichst wenige Daten speichern will, kann ein entsprechendes Logfile-Format definieren. Damit werden sowohl IPv4- als auch IPv6-Adressen anonymisiert.

Für die Error-Logs lässt sich leider kein neues Format definieren – hier kann man jedoch auch bei ausreichend kurzer Speicherfrist ein berechtigtes Interesse zum reibungslosen Betrieb annehmen. Die Einrichtung der anonymisierten Logfiles ist einfach: folgender Code wird in die zentrale nginx.conf eingefügt, dadurch werden bei IPv4-Adressen die letzten drei Ziffern durch „0“ ersetzt, bei IPv6-Adressen werden ebenfalls die letzten beiden Blöcke gelöscht.

map $remote_addr $ip_anonym1 {
default 0.0.0;
"~(?P<ip>(\d+)\.(\d+)\.(\d+))\.\d+" $ip;
"~(?P<ip>[^:]+:[^:]+):" $ip;
}

map $remote_addr $ip_anonym2 {
default .0;
"~(?P<ip>(\d+)\.(\d+)\.(\d+))\.\d+" .0;
"~(?P<ip>[^:]+:[^:]+):" ::;
}

map $ip_anonym1$ip_anonym2 $ip_anonymized {
default 0.0.0.0;
"~(?P<ip>.*)" $ip;
}

log_format anonymized '$ip_anonymized - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent"';

access_log /var/log/nginx/access.log anonymized;

Für die einzelnen Virtualhosts wird nun jeweils in der Access-Log-Zeile der Eintrag „anonymized“ hinzugefügt. Danach müssen einmal alle alten Logfiles gelöscht werden. Ab dem nächsten Server-Neustart werden dann die reduzierten Logfiles gespeichert, ansonsten funktioniert alles wie gewohnt. In Sachen Datenschutz ist man damit etwas näher an einer „sauberen Lösung“, die ganz im Sinne der EU-DSGVO-Datensparsamkeit ist. Diese Lösung wird auch auf diesem Server angewendet.

Raspberry Pi 3B+: Gigabit-LAN und 200 MHz mehr Takt

Posted on by Falk Jeromin

Die Raspberry Foundation hat eine Überarbeitung des Raspberry 3 vorgestellt: das Modell 3B+. Mehr Takt und bessere Netzwerk-Anbindung sind die wesentlichen Merkmale.

RASPBERRY PI 3 MODEL B+ (Bild: Raspberry Foundation)
RASPBERRY PI 3 MODEL B+ (Bild: Raspberry Foundation)
Das Format ist das selbe geblieben, bestehende Projekte mit einem Raspberry Pi können einfach auf das neue Modell geupgraded werden – sofern der Takt, der beim neuen Modell auch unter Dauerlast höher ausfallen soll, der limitierende Faktor ist.

Die Daten im Überblick:

  • 1.4 GHz 64-bit quad-core ARM Cortex-A53 CPU (BCM2837B0)
  • Dual-band 802.11ac wireless LAN and Bluetooth 4.2 (BCM43455)
  • Faster Ethernet (Gigabit Ethernet over USB 2.0, LAN7515)
  • Power-over-Ethernet support (with separate PoE HAT)
  • Improved PXE network and USB mass-storage booting
  • Improved thermal management

Nach wie vor ist der Ethernet-Anschluss über USB-2.0 angebunden (LAN7515), was vor allem für Media-Player-Projekte ein limitierender Faktor sein kann. Zumindest wird eine höherer Bandbreite erreicht als bisher. Verbesserungen gibt es ebenfalls beim WLAN: der Funkchip BCM43455 unterstützt 2,4- und neu 5-GHz-Netzwerke, dazu Bluetooth 4.2.

Das neue Modell ist ab sofort verfügbar zum Preis des bisherigen Raspberry Pi 3B. Ein aktualisiertes Raspbian-Image steht ebenfalls bereits zum Download bereit. Wann eine wirkliche Weiterentwicklung in Form eines Raspberry Pi 4 auf den Markt kommt ist offen – vor 2019 wird dies wohl kaum passieren.

FreeNAS 11.1 erschienen

Posted on by Falk Jeromin

Das auf FreeBSD basierende NAS-System FreeNAS ist in der neuen Version 11.1 erschienen, die etliche Neuerungen mit sich bringt.

Die Änderungen im Changelog betreffen OpenZFS, welches vor allem beim verarbeiten von Snapshots und großen Dateien schneller geworden sein soll. Außerdem wurde der Hardware-Support verbessert sowie Funktionen zum Cloud-Sync mit Amazon S3, Microsoft Azure Blob Storage, Backblaze B2 und Google Cloud Storage hinzugefügt. Dateien können ohne weiteres mit den genannten Diensten abgeglichen werden, was für Offsite-Backups sinnvoll ist. Viele Änderungen betreffen auch die Möglichkeiten für virtuelle Maschinen, angefangen bei Support für Nicht-US-Tastatur-Layouts bis hin zu RancherOS Docker-Instanzen.

Nach dem Corral-Experiment scheint FreeNAS noch einmal die Kurve gekriegt zu haben und ist wie gewohnt leicht zu installieren gewesen. Natürlich sollte beim bei OS-Updates auf einem NAS immer ein Backup zur Verfügung haben, in meinem Fall habe ich das zweite FreeNAS, welches die Daten spiegelt, noch nicht aktualisiert. FreeNAS 11.1 gibt es auf der Projekt-Seite zum Download, es werden 8 Gigabyte RAM empfohlen und ein 64-Bit-Prozessor ist pflicht.


FreeNAS: Pi-Hole & PiVPN in Ubuntu-VM

Posted on by Falk Jeromin

Wer FreeNAS 11 als NAS- bzw. Homeserver-Software verwendet, kann pi-hole sowie pi-vpn verwenden und sowohl auf das eigene Netzwerk zugreifen als auch Werbung zuverlässig blockieren.

PiVPN (http://www.pivpn.io/) ist ein Installations- und Verwaltungsscript für OpenVPN. Eigentlich gedacht für die Verwendung auf einem Raspberry Pi, funktioniert die Installation auch ohne Probleme auf einem Ubuntu 17.04, welches in einer bhyve-VM läuft. Der Ablauf ist der selbe wie beim „Bastelrechner“: 

curl -L https://install.pivpn.io | bash

Das Installationsscript beschwert sich zwar, dass die verwendete Linux-Version gegebenenfalls nicht kompatibel ist und verweigert das automatische konfigurieren von einigen Dingen, am Ende läuft aber alles soweit problemlos durch. Wichtig: damit das deutleiten der VPN-Verbindung klappt, muss unter Ubuntu die Firewall „ufw“ (uncomplicated firewall – ein Commandozeilen-Tool für das einfache Einstellen von iptables-Regeln) installiert sein und der entsprechende Port freigegeben sein.