mysql -u root
MariaDB [(none)]> update mysql.user set password=password('geheim') where user='root';
MariaDB [(none)]> update mysql.user set plugin='' where user='root';
MariaDB [(none)]> flush privileges;
]]>
Die Schritte wurden auf einem DS118 mit der Beta Version von DSM 7 durchgeführt.
In der Systemsteuerung unter Terminal & SNMP
zunächst SSH generell aktivieren:
Von Haus aus dürfen sich nur Benutzer via SSH anmelden, die Mitglied der Administrator-Gruppe sind. Über ein händisches editieren der /etc/passwd
lässt sich auch einem anderen Benutzer eine Shell zuweisen, das hält aber nur maximal bis zum nächsten Reboot. Dann wird die Anpassung wieder überschrieben. Beides ist unschön, die dauerhafte Lösung ist die mit der Gruppe. Dazu unter Benutzer & Gruppe
im Gruppentab die administrators
öffnen und den Backupuser hinzufügen:
Eine weitere Alternative, bei der man um die Admingruppe herumkommt, ist durch etwas Bastelei ebenfalls möglich, s. hier: https://blog.emeidi.com/2017/11/25/normalen-benutzern-den-ssh-login-auf-synology-diskstations-erlauben/ Das ist aus Perspektive der Sicherheit die beste Lösung.
Nun ist ein Anmelden via SSH für den Benutzer möglich. Beim Login wird er nach seinem Passwort gefragt. Für Restic ist notwendig, dass die Authentifizierung via Public Key eingerichtet ist, damit eine Anmeldung ohne Passwort möglich ist.
Zunächst muss man auf dem SSH Client ein Schlüsselpaar erstellen, sofern das nicht schon erledigt ist. Hier ein Beispiel für die Erstellung nach dem modernen ED25519 Verfahren:
backup@client:~$ ssh-keygen -t ed25519
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/backup/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/backup/.ssh/id_ed25519
Your public key has been saved in /home/backup/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:Xu5m........................................LzE backup@client
The key's randomart image is:
+--[ED25519 256]--+
| .oo |
| ..o |
| .o |
| . . |
| ... .S o. |
| E.o=o. oo.o |
| .*+**...oo . |
| oo.B**++oo |
| o*B*o+.+. |
+----[SHA256]-----+
Die Passphrase muss dabei leer bleiben.
Die Schlüssel werden standardmäßig in einem neuen Ordner .ssh
innerhalb des Benutzerverzeichnisses erstellt. Der öffentliche Schlüssel heißt i.d.R. id_ed25519.pub
, der private entsprechend nur id_ed25519
. Den öffentlichen Schlüssel kopiert man sich in die Zwischenablage. Dieser Public Key muss nun auf dem SSH Server als erlaubter Schlüssel hinterlegt werden. Dazu loggt man sich auf dem NAS via SSH mit einem Administratorkonto per SSH ein (noch mit Passwort). Die Datei mit den erlaubten Schlüsseln gehört ebenfalls im Homeverzeichnis des entsprechenden Nutzers in den Ordner .ssh
und nennt sich authorized_keys
.
Nehmen wir an, der Benutzer auf dem NAS heißt "backup". Dann ist in der Standardeinstellung das Homeverzeichnis /volume1/homes/backup
. Dort wird jetzt der notwendige Ordner und die passende Datei erstellt:
admin@nas:~# mkdir /volume1/homes/backup/.ssh
admin@nas:~# touch /volume1/homes/backup/.ssh/authorized_keys
In die Datei authorized_keys
fügt man nun den Public Key des Clients ein, der weiter oben in die Zwischenablage kopiert wurde.
SSH ist extrem pingelig, was die Berechtigungen für die Keyfiles angeht. Sollten Sie nicht stimmen, ist ein Anmelden via Public Key nicht möglich und es erscheint die Aufforderung zur Passworteingabe. Daher müssen die Berechtigungen gesetzt werden. Bei Synology sind selbst die Berechtigungen der Homeverzeichnisse zu lax, sodass man hier bereits anfangen muss. Für den User backup ergeben sich folgende Korrekturen:
admin@nas:~#...
]]>
Froxlor ist eine in PHP geschriebene und unter der GPL veröffentlichte Servermanagementanwendung, die das Betreiben von Hostingservern vereinfacht. Einmal eingerichtet lassen sich Hostings (vordergründig Webhosting und Mailhosting, Details s. auf der Homepage von Froxlor) bequem per Webinterface anlegen und verwalten.
Was die Wahl des Serverbetriebssystems angeht, hat man die Wahl zwischen diversen Linuxdistributionen. Am besten unterstützt werden Debian und seine Derivate. Aber auch Centos und Arch Linux stehen zur Auswahl. Außerdem hat man die Wahl, welche Serversoftware eingesetzt werden soll. Beim Webserver beispielsweise zwischen Apache, nginx und Lighttpd.
Wie man die Logs anonymisieren kann hängt von der eingesetzten Webserversoftware ab. Ich möchte hier die Möglichkeiten bei Einsatz des Apache und des nginx erklären.
Beim Apache ist es relativ simpel. Der Server unterstützt von Haus aus das Umleiten des Logfiles an ein Script. Diese Eigenschaft macht man sich zunutze, um die IP Adressen der Besucher zu anonymisieren. Entsprechende Scripte gibt es im Internet, ich bediene mich des Pythonscripts Anonip. Dieses Script speichert man z.B. unter /opt/anonip.py
ab. Anschließend teilt man Froxlor mit, dass es die Logdateien an Anonip weiterleiten soll. Diese Einstellung findet man unter Einstellungen -> Webserver Einstellungen
. Dort das Häkchen für die Umleitung setzen und im Feld darüber den Pfad zu Anonip und die Parameter mitgeben (s. Screenshot)
Bei den Parametern aus dem Beispiel werden bei IPv4 Adressen die letzten 8 Bits (=das vierte Oktett) und bei IPv6 die letzten 64 Bits maskiert. Der Output Parameter sorgt dafür, dass die Logs auch am in Froxlor definierten Ort gespeichert werden. Das führt zu folgenden beispielhaften Ergebnissen:
192.0.2.123 wird zu 192.0.2.0
2001:0db8:aaaa:bbbb::1234:5678 wird zu 2001:0db8:aaaa:bbbb::
nginx unterstützt das Umleiten der Logs an ein Script nicht, das Häkchen ist bei Auswahl von nginx nicht verfügbar. Allerdings bietet Froxlor die Möglichkeit, das Log-Format direkt anzugeben. Um nginx das Anonymisieren beizubringen, braucht man auch hier ein bisschen Programmierlogik. Folgendes Script muss unter /etc/nginx/conf.d/anonymize-log.conf
abgelegt werden. Der Dateiname ist übrigens frei wählbar, muss aber mit .conf enden, da nginx standardmäßig alle .conf Dateien im Verzeichnis /etc/nginx/conf.d/
beim Starten einbindet.
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;
}
Dieses Skript stammt von blag.nullteilerfrei.de. Lediglich die letzten drei Zeilen wurden entfernt, da man das definieren des Logformats Froxlor überlässt.
Unter Einstellungen => Webserver Einstellungen
ist das Access Log Format folgendermaßen anzugeben:
"$ip_anonymized - $remote_user [$time_local] \"$request\" $status $body_bytes_sent \"$http_referer\" \"$http_user_agent\""
Dadurch wird das originale Logformat von nginx beibehalten, die IPs jedoch verschleiert. Wichtig ist, dass die doppelten Anführungszeichen mit einem Backslash escaped werden, da Froxlor das Format selbst in Anführungszeichen setzt. Ohne die Escapezeichen würde nginx meckern. Im Gegensatz zum Apache-Beispiel verschleiert diese Version bei IPv6 Adressen die letzten 96 Bits. Möchte man das ändern, muss die .conf-Datei nach den eigenen Wünschen angepasst werden.
Aus 2001:0db8:aaaa:bbbb::1234:5678 wird hier 2001:0db8:. IPv4 Adressen werden wie oben im letzten Oktett verschleiert.
]]>Ich hoste auf meinem NAS eine Nextcloud Instanz auf einem Apache 2.4 mit PHP 7.0. Sobald ich den integriertem Updater benutzen möchte, um die Version zu aktualisieren, bekomme ich spätestens dann eine Fehlermeldung, wenn während der Prozedur ein Backup erstellt wird. Dieser Vorgang dauert nämlich etwas und nach exakt einer Minute kommt es zum Timeout.
Die Ursache liegt darin, dass die Diskstation ihren eigenen Webserver (nginx) als Reverse Proxy für den Webserver der Web Station schaltet. Dieser nginx hat per Default einen Timeout von 60s gesetzt. Dauert nun ein Vorgang auf dem Apache länger (wie das o.g. Backup) und liefert dieser daher nicht innerhalb von einer Minute eine Antwort, läuft der nginx in einen Timeout.
Mit Hilfe des Supports konnte ich das Problem lösen. Das Problem lag nicht darin, dass ich nicht wusste, wie es zu lösen ist. Es lag eher darin zu wissen, wo es zu lösen ist. Die Diskstation baut ihre Konfigurationen nämlich aus diversen Dateien bei jedem Diensteneustart neu zusammen. Für nginx muss folgende Datei (zumindest Stand jetzt, in der DSM DSM 6.1.5-15254) angepasst werden:
/var/packages/WebStation/target/misc/VirtualHost-nginx.mustache
Dort gibt es zwei Abschnitte, einen für Apache 2.4, einen für Apache 2.2. In beiden muss der Parameter proxy_read_timeout
mit entsprechendem Wert (bei mir zehn Minuten) eingefügt werden:
{{#apache22}}
include proxy.conf;
proxy_read_timeout 600s;
location / {
proxy_pass http://{{listen}};
}
{{/apache22}}
{{#apache24}}
include proxy.conf;
proxy_read_timeout 600s;
location / {
proxy_pass http://{{listen}};
}
{{/apache24}}
Anschließend muss der Dienst noch mittels sudo synoservicectl --restart nginx
neu gestartet werden.
Diese manuelle Änderung wird überschrieben, sobald die Web Station App aktualisiert wird. Man muss diese Prozedur also nach jedem Update wiederholen.
Mit Hilfe des Backup-Managers lassen sich unter Plesk Sicherungen der Hostings anlegen. Diese können direkt auf dem Hostingserver abgelegt, oder per FTP(s) auf einen externen Server übertragen werden. Da das Backup auf dem Hostingserver selbst im Falle eines Crashs nutzlos ist, sollte die Variante mit dem externen Server bevorzugt werden. Wer Cloudspeicher von Strato (“HiDrive”) nutzen möchte, kann das Backup folgendermaßen einrichten:
Im Backup-Manager unter Plesk unter “Einstellungen zum FTP-Speicher” folgende Daten eingeben:
Hostname: ftp.hidrive.strato.com
Verzeichnis: /users/ < HiDrive-Username > /Hosting/
FTP-Benutzername = HiDrive Username
FTP-Passwort = HiDrive Passwort
Passivmodus verwenden: ✓
FTPS verwenden: ✓ (nicht zwingend erforderlich, aber unbedingt empfehlenswert)
Bei Bedarf lassen sich die Backups zusätzlich mit einem Passwort versehen.
Damit ist die Konfiguration bereits beendet. Nach einem Klick auf OK wird der Inhalt des FTP Speichers angezeigt, bei Ersteinrichtung ist hier natürlich noch nichts drin. Aufgelistet werden hier nur die tatsächlichen Plesk Backups. Sofern im Ordner auf dem HiDrive noch andere Daten abgelegt sind, werden sie im Plesk nicht angezeigt. Ab jetzt lassen sich sowohl händisch gestartete als auch geplante Backups im Strato HiDrive ablegen. Es muss darauf geachtet werden, dass als Speicher auch der externe FTP Speicher ausgewählt wird, ansonsten verwendet Plesk den lokalen Server als Ablage.
]]>Kurze Zusammenfassung der Einstellungen für pfSense und Android.
VPN –> IPsec –> Mobile Clients
pfSense unterstützt derzeit nicht das Vermischen von IPv4 und IPv6 im VPN Tunnel. D.h., dass zu einer IPv4 Gegenstelle auch nur IPv4 Traffic getunnelt werden kann und analog bei einer IPv6 Gegenstelle nur IPv6 getunnelt werden kann.
Alle anderen Einstellungen nach Bedarf.
System –> Cert. Manager –> CAs
Hier zunächst eine CA erstellen, wenn nicht bereits erledigt. Unter dieser CA wird anschließend das Serverzertifikat erstellt.
System –> Cert. Manager –> Certificates
Hier ein eigenes, internes Zertifikat unter der eben erstellten CA erstellen, nennen wir es z.B. “IKEv2 Server”. Wichtig ist, dass als Common Name der FQDN eingetragen wird, der später auch im VPN Client des Smartphones benutzt wird. Sonst funktioniert später die Authentifizierung nicht.
VPN –> IPsec –> Phase 1
Alles weitere nach Bedarf, ich habe noch DPD aktiviert.
DH Group 2 ist Pflicht, sofern man neben Androidclients auch Windowsrechner mit Boardmitteln zum VPN verbinden möchte. Strongswan hat diese Group aber nach einem Update aus den Standardproposals entfernt. Man muss es daher zwingend von Hand wieder aktivieren, indem man unter den IKEv2-Algorithmen seine verwendeten Proposals definiert, in diesem Fall aes256-sha256-modp1024.
Die Verschlüsselungsparameter lassen sich unter Windows mit Hilfe der Powershell anpassen. s. hier: Verschlüsselungen im Windows 10 IKEv2 Client anpassen. Damit ist man nicht mehr auf die veraltete DH-Group 2 angewiesen.
VPN –> IPsec –> Phase 2
VPN –> IPsec –> Pre-Shared Keys
Pro User einen Identifier (=Username) und Pre-Shared Key (Typ: EAP) vergeben
Als VPN Client für Android eignet sich sehr gut die App “strongswan”. Das Zertifikat des Servers muss in den Client importiert werden. Einstellungen für strongswan:
Seit Windows 7 unterstützt der Boardeigene VPN Client IPsec mit IKEv2 und Zertifikaten. Hierfür muss man sich zunächst das Zertifikat der CA von der pfSense exportieren und auf dem Windows-PC importieren. Es muss unter den “Vertrauenswürdigen Stammzertifizierungsstellen” gespeichert werden. Das lässt sich zum Beispiel mit der Managementkonsole (Start –> Ausführen –> mmc) erledigen. Anschließend kann die...
]]>Synology hat mit seiner im Betriebssystem DSM integrierten Backuplösung “Hyper Backup” eine einfache Möglichkeit geschaffen, Daten auf verschiedenen Zielen zu sichern und wiederherzustellen. Als Sicherungsziele sind bereits diverse Clouddienste integriert, außerdem lassen sich Backups auch auf andere Synology DiskStations oder externe Festplatten sichern. Beispielsweise ist auch das Strato Hidrive integriert. Die MagentaCloud ist prinzipiell ein Hidrive, das anders vermarktet wird, aber auf der gleichen Plattform basiert. Da die MagentaCloud (noch) nicht in DSM integriert ist, müssen wir hier einen kleinen Umweg in Kauf nehmen. Dieser Umweg nennt sich WebDAV. Aber der Reihe nach:
In Hyper Backup erstellen wir eine neue Sicherungsaufgabe, dazu klicken wir unten links auf das Pluszeichen und wählen “Datensicherungsaufgabe”. Innerhalb von Hyper Backup stehen wie beschrieben bereits diverse Sicherungsziele zur Auswahl. Wer in eine Dropbox, ein Google Drive, ein Amazon Drive u.a. sichern möchte, wählt den entsprechenden Punkt und folgt dem Assistenten weiter. Für die MagentaCloud wählen wir “WebDAV” und bestätigen mit “Weiter”.
Entgegen der bereits eingebauten Dienste, müssen wir hier die Verbindungseinstellungen von Hand eingeben. Der Aufwand hält sich allerdings in Grenzen. Folgende Daten sind notwendig:
Im nächsten Schritt werden die zu sichernden Verzeichnisse auf dem NAS ausgewählt. In meinem Fall ist das ein Ordner, der verschiedene wichtige Dokumente enthält.
Im folgenden Schritt besteht die Möglichkeit, auch Anwendungen zu sichern, das ist für eine einfache Datensicherung nicht nötig und wird hier übersprungen. Weiter geht es mit den Datensicherungseinstellungen. Zunächst einmal braucht die Aufgabe einen Namen, der später auch in der Liste auftaucht.
Sofern man die Verschlüsselung aktiviert, wird nach dem Bestätigen mit “Weiter” eine Schlüsseldatei zum Download angeboten. Diese sollte unbedingt sicher verwahrt werden. Mit ihr lassen sich die Daten entschlüsseln – auch, wenn das Passwort verloren geht. Im Umkehrschluss bedeutet das aber auch, dass jeder, der die Schlüsseldatei hat, die Daten entschlüsseln und lesen kann!
Im nächsten Schritt kann eine Rotation für die Daten erstellt werden. Dadurch werden bei einer Sicherung die bestehenden Daten nicht einfach überschrieben, sondern archiviert. So liegen verschiedene Versionen der Datei vor und können zurückgesichert werden. Das ist z.B. sehr hilfreich, wenn mal ein Dokument durch irgendeinen Grund nicht mehr lesbar ist. Sichert man jetzt klassisch, hat man die...
]]>Die Software Privoxy wurde entwickelt, um die Privatsphäre im Internet zu schützen. Es handelt sich dabei um einen Content-Filter Proxy, der beispielsweise unerwünschte Werbung entfernen und das Ausspähen von Nutzerdaten durch Cookies unterbinden kann.
Das Programm ist in den Paketquellen von Ubuntu enthalten und kann mittels
sudo apt-get install privoxy
installiert werden. Nach der Installation wird der Dienst automatisch gestartet und lauscht auf localhost:8118
.
Die EasyList ist eine Sammlung von Filterlisten, die bekannte Werbe-URLs enthält. Sie werden z.B. auch vom Browser-AddOn “AdBlock” verwendet. Es gibt ein Skript, dass den Download (und später auch die Aktualisierungen) der EasyLists erledigt, sie für Privoxy konvertiert und dort auch aktiviert. Das Skript gibt es hier. Es muss heruntergeladen und anschließend als root ausgeführt werden. Das Skript erledigt den Rest. Anschließend muss Privoxy neu gestartet werden:
sudo service privoxy restart
Nun muss man dem Firefox noch sagen, dass er Privoxy auch benutzen soll. Dazu öffnet man die Einstellungen und hangelt sich dann wie folgt zu den Netzwerkoptionen und den Proxyeinstellungen:
]]>Client
erstellen: ssh-keygen -t rsa
ggf. Passwort zum Schutz des Keys vergebenssh-copy-id -i <Pfad-zur-id_rsa.pub> username@ssh-server
/etc/ssh/sshd_config
bearbeiten und PasswordAuthentication no
sowie UsePAM no
setzen. Anschließend Dienst neu starten.