Malte's OpenSource Talk

Seit heute habe ich filerun im Einsatz. Es läuft wirklich wunderbar. Doch habe ich mich nach der Einrichtung gewundert, dass Dateien, die ich mit rsync auf den Server geschoben habe, zwar angezeigt werden, diese aber nicht als Medientypen erkannt werden. Also nicht automatisch als Videos, Bilder oder z.B. PDF Dokumente. Nach einigen Forschen in der Dokumentation, wurde mir dann bewusst, dass Dateien, die manuell auf den Server geschoben werden und nicht über das Webfrontend, manuell erkannt werden müssen. Filerun hat in seinem Stammverzeichnis extra hierfür ein cron Verzeichnis mit den wichtigsten Dateien für die Wartung der Installation angelegt. Dazu habe ich jetzt folgende Cronjobs angelegt:

*/15 * * * *	root	php -c /etc/php/7.4/apache2/conf.d/filerun.ini /var/www/html/filerun/cron/metadata_index.php
*/15 * * * *	root	php -c /etc/php/7.4/apache2/conf.d/filerun.ini /var/www/html/filerun/cron/index_filenames.php /filerun/ true
*/15 * * * *	root	php -c /etc/php/7.4/apache2/conf.d/filerun.ini /var/www/html/filerun/cron/reindex_files.php
*/15 * * * *	root	php -c /etc/php/7.4/apache2/conf.d/filerun.ini /var/www/html/filerun/cron/empty_trash.php –days 30
*/15 * * * *	root	php -c /etc/php/7.4/apache2/conf.d/filerun.ini /var/www/html/filerun/cron/paths_cleanup.php
*/15 * * * *	root	php -c /etc/php/7.4/apache2/conf.d/filerun.ini /var/www/html/filerun/cron/make_thumbs.php

Die folgenden Cronjobs erledigen folgenden Aufgaben: – Erkennen der Metadaten und erkennen von Mediendateien – Aufnahme der Dateinamen in die Suche – Indexieren von allen Dateien – Im Papierkorb alle Dateien löschen, die älter als 30 Tage sind – Manuell gelöscht Dateien aus dem Index entfernen – Erstellen von Thumbnails

Jetzt werden wieder im Webfrontend alle Dateien ordentlich in entsprechender Struktur angezeigt.

#filerun #cron #linux #debian #php

In meinem letzten Artikel habe ich erklärt, wie man unter Linux die Firewall mit einem IP Block ausstatten kann. In diesem Artikel möchte ich euch erklären, wie ihr auch IP's melden könnt, und somit der Community wieder was zurückgeben könnt.

Fail2Ban installieren

Fail2Ban ist schnell installiert:

apt install -y fail2ban

Fail2Ban und UFW

Wie im ersten Artikel bereits beschrieben, nutze ich als Firewall für meine Systeme UFW. Damit Fail2Ban mit UFW sprechen kann, müssen wir kleine Anpassung machen. Als Erstes müssen wir die Datei jail.local erstellen, dazu macht einfach folgendes:

cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

In der jail.local such jetzt bitte die folgende Zeile (ist bei mir die 167):

banaction = ....

Alles hinter dem Gleichzeichen entfernen und ufw angeben.

Fail2Ban und AbuseIPDB

Als Nächstes müssen wir in der jail.local noch eine Änderung vornehmen. Sucht in der Datei, im [DEFAULT] Block bitte die folgende Zeile (ist bei mir 228 kurz vor dem sshd Jail):

action = %(action_)s

Diese muss durch die folgende erstes werden, passt auch direkt deine API Key an.

action = %(action_)s
         %(action_abuseipdb)s[abuseipdb_apikey="DeinAPIKey", abuseipdb_category="18"]

Was haben wir gerade gemacht? Wir haben Fail2Ban gesagt, dass er bei einem Ban, die IP die gebannt wird, an die Aktion AbuseIPDB (bearbeiten wir gleich) übergeben werden soll, mit der Kategorie 18 (Brute-Force). Weiteres zu den Kategorien hier.

In diesem Teil habe ich jetzt beschrieben, wie wir allgemein eine Aktion für alle Bans aufrufen können. Natürlich kann man das für jeden Jail auch einzelnen machen, und so genauer melden, wenn man die entsprechenden Kategorien angibt. So könnte man die Zeile oben auf Default lassen und im Jail sshd zum Beispiel das folgende machen:

[sshd]
port    = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s
action = %(action_)s
         %(action_abuseipdb)s[abuseipdb_apikey="DeinAPIKey", abuseipdb_category="18,22"]

Jetzt sind die Kategorien die wir melden, 18 (Brute-Force) und 22 (SSH). So kann AbuseIPDB, das viel genauer filtern und anderen zur Verfügung stellen.

Als letztes müssen wir noch die Action abuseipdb anpassen. Leider, ist die action die mit Debian mitgeliefert wird nicht mehr aktuell, und führt dazu, das ihr nichts melden könnt, weil die API falsch angesprochen wird. Dazu geht in die Datei /etc/fail2ban/action.d/abuseipdb.conf.

Löscht die aktuelle Zeile, die mit actionban = begint komplett und setzt die folgenden rein:

actionban = curl --tlsv1.2 --fail 'https://api.abuseipdb.com/api/v2/report' -H 'Accept: application/json' -H 'Key: <abuseipdb_apikey>' --data-urlencode "comment=<matches>" --data-urlencode 'ip=<ip>' --data 'categories=<abuseipdversionb_category>'

WICHTIG: hier nichts einsetzen, so eintragen wie ich es hier geschrieben habe, der APIKey und die IP und die Kategorien werden von Fail2Ban bei einem Ban übergeben!

Jetzt alles speichern und einen neustart von fail2ban machen:

fail2ban-client restart

Hier sollte kein Fehler kommen, sicherheitshalber kann man auch nochmal die Log überprüfen:

cat /var/log/fail2ban.log

Ergebnis

Dementsprechend wie sehr eurer Server “angegriffen” wird, solltet ihr nach einigen Tagen bereits einige IP's gemeldet haben, bei mir sieht das aktuell so aus:

Im folgenden Artikel möchte ich erläutern, wie ihr eure Linux Firewall (UFW) mit einer Blackliste von IP-Adressen, die durch Meldungen bereits als schadhafte IPs (wurden zum Beispiel für Brute-Force) genutzt, erweitern könnt.

AbuseIPDB

Ich nutze für dieses Setup die Datenbank von AbuseIPDB. Damit auch ihr diese nutzen könnt, müsst ihr euch einfach einen kostenlosen Account erstellen. Danach könnt ihr in den Einstellungen einen API Key generieren, den ihr für das folgenden Setup benötigt.

Software installieren

Wir benötigen natürlich einige Softwarepakete. Grundsätzlich, gehe ich davon aus, dass ihr UFW bereits installiert habt und entsprechend konfiguriert habt. Zusätzliche Pakete, die noch benötigt werden:

apt install -y screen curl 

Ordnerstruktur

Jetzt legen wir den Ordner an, den wir benötigen:

mkdir /opt/blacklist

Los geht es

Ok, jetzt fangen wir dann mal wirklich an. Die erste Datei, die wir anlegen heißt blacklist.shund liegt in dem eben von uns erstellten Ordner. Der Inhalt ist klein und fein und sieht so aus:

#!/bin/bash

while read line;
do
	ufw insert 1 deny from $line to any;
done < /opt/blacklist/blacklist

Das Script macht nichts anderes, als die Datei /opt/blacklist/blacklist Zeile für Zeile einzulesen und entsprechend an die UFW Firewall zu übergeben und zu blockieren. Richtig, jede Zeile enthält eine potenzielle “böse” IP-Adresse.

Entsprechend setzten wir jetzt noch die Rechte auf die Datei:

chmod 700 /opt/blacklist/blacklist.sh

Um diese Liste mit den IP-Adressen zu erstellen, benötigen wir noch ein zweites Script, diese legen wir direkt im Verzeichnis /etc/cron.daily/ an. (Achtung, bei schwachen Servern sollte eher in diesem Verzeichnis /etc/cron.weekly/ die Datei angelegt werden). Das Script hat den Namen getBlacklist. Der Inhalt der Datei sieht wie folgt aus:

#!/bin/bash

#get latest blacklist from abuseIPDB

curl -G https://api.abuseipdb.com/api/v2/blacklist \
  -d confidenceMinimum=50 \
  -H "Key: EurerAPIKey" \
  -H "Accept: text/plain" | sort > /opt/blacklist/blacklist

#block every ip in list

/usr/bin/bash /opt/blacklist/blacklist.sh

Bitte ersetzt EurerAPIKey mit eurem Key, achtet auf das Leerzeichen nach dem Doppelpunkt!

Entsprechend setzten wir jetzt noch die Rechte auf die Datei:

chmod 755 /etc/cron.daily/getBlacklist

Diese Datei holt die IP-Adressen aus der AbuseIPDB Datenbank und schreibt diese in die blacklist Datei. Danach wird unser erstes Script aufgerufen. Der Wert confidenceMinimum gibt das folgenden an:

Wir empfehlen Ihnen, nach abuseConfidenceScore zu filtern, d.h. nach unserer berechneten Bewertung, wie missbräuchlich die IP ist, basierend auf den Nutzern, die sie gemeldet haben (mehr).

Quelle: AbuseIPDB Dokumentation

Testen

Wichtig: Diese Liste enthält aktuell über 10.000 IP-Adressen

Das Einfügen einer solchen Menge in die Firewall, dauert. Also werden wir den folgenden Befehl ausführen, nachdem wir screen gestartet haben.

screen
# Enter drücken
# dann folgendes ausführen
bash /etc/cron.daily/getBlacklist

Jetzt sollten die IP's geladen werden und dann alles in die Firewall eingetragen werden. Mit Strg + a und Strg + d verlasst ihr die aktuelle screen Session. Um das Ergebnis zu sehen, gebt einfach folgenden Befehl ein:

ufw status

Das Bild sollte dann diesem hier sehr ähnlich sein:

Channel	Kontakt
Mail	malte.kiefer@mailgermania.de (PGP)
Jabber	pr3ach3r@trashserver.net
Threema	VCM8D6DB
Mastodon	https://social.tchncs.de/@beli3ver

In meinem neuen Unternehmen arbeiten wir nur noch mit PostgreSQL Datenbanken. Für ein aktuelles Projekt haben wir jetzt in die Backup Strategie natürlich auch den Dump der jeweiligen Datenbank mit aufgenommen. Im folgenden will ich kurz erklären, wie es schnell unter Linux mit Cron zu lösen ist.

Dazu legen wir eine Datei an, mit dem Name db_backup.sh. Diese sollte dann die folgenden Rechte gesetzt bekommen:

chmod 700 db_backup.sh

Grund hierfür ist, dass wir in die Datei, das Passwort des jeweiligen DB Nutzers ablegen müssen.

Als nächstes kommen wir zum Inhalt:

#!/bin/bash

date=$(date +%Y-%m-%d-%H-%M)
export PGPASSWORD=PasswortVomNutzerTest
/usr/bin/pg_dump -C -f /opt/backup/dumps/${date}_postgres_dump_churchevents.dmp --encoding=UTF-8 -U Test

find /opt/backup/dumps -mtime +5 -exec rm {} \;

Okay, gehen wir Zeile für Zeile durch

date=$(date +%Y-%m-%d-%H-%M)

Wir legen einen Variabel mit dem Namen date fest, die einen String aus dem aktuellen Datum und Uhrzeit beinhaltet.

export PGPASSWORD=PasswortVomNutzerTest

In dieser Zeile legen wir das Passwort vom Nutzer Test fest, was als Umgebungsvariable übergeben wird. Jetzt kommen wir zum eigentlichen Sicherungsbefehl:

/usr/bin/pg_dump -c -C -f  p /opt/backup/dumps/${date}_postgres_dump.sql --encoding=UTF-8 -U Test

• -c enthält im Dump eine Passage, was beim importieren die bereits vorhandene DB löscht und alles neu anlegt
• -C enthält im Dump eine Passage, mit CREATE TABLE Statments
• -f Speicherort des Dumps (das p bedeutet Plaintext, also SQL)
• —encoding ist glaube ich klar :–)
• -U Angabe des Datenbankbenutzers, hier Test

Und als letztes ein Befehl der alle Dumps älter als 5 Tage löscht:

find /opt/backup/dumps -mtime +5 -exec rm {} \;

Jetzt legen wir noch den jeweiligen Cronjob an und das wars.

Alle Datenbanken sichern

Um alle Datenbank zu sichern, gibt es den Befehl pg_dumpall:

pg_dumpall -U postgres > /opt/backup/all.sql

Hier wird der Benutzer postgres verwendet, was der Default Admin Nutzer ist. Entsprechend sein Passwort muss verwendet werden.

Dokumentation

Weitere Hilfe könnt ihr auch in der Dokumentation finden.

Im folgenden Artikel, möchte ich kurz erläutern, wie ihr eine Sicherung von Mailcow auf einer Hetzner Storagebox auslagern könnt. Ich gehe davon aus, dass ihr bereits eine Hetzner Storagebox habt und den SSH sowie den RSYNC Zugriff erlaubt habt.

Storagebox vorbereiten

Es werden einige kleine Schritte benötigt, damit ihr mit der Storagebox problemlos arbeiten könnt. Als erstes generieren wir einen neuen SSH Key:

ssh-keygen -t ed25519

Beantwortet die Fragen nach euren Bedürfnissen, jedoch darf der Key kein Passwort haben. Als nächstes installieren wir sshfs um unsere Storagebox zu mounten:

apt install sshfs -y

Im nächsten Schritt, werden wir die Storagebox mounten:

mkdir /mnt/storagebox
sshfs u123456@u123456.your-storagebox.de:/ /mnt/storagebox/

Jetzt noch entsprechend den Ordner und die Datei für den Schlüssel anlegen:

mkdir /mnt/storagebox/.ssh
touch /mnt/storagebox/.ssh/authorized_keys

Jetzt kopieren wir noch den Key auf die Storagebox:

cat ~/.ssh/id_ed25519.pub >> /mnt/storagebox/.ssh/authorized_keys

Als vorletzten Schritt legen wir noch das Sicherungsverzeichnis in der Storagebox an und umounten die Storagebox wieder vom System:

mkdir /mnt/storagebox/mailserver
fusermount -u /mnt/storagebox

Als letzten Schritt, müssen wir noch eine SSH Config Datei anlegen, da die Storagebox einen anderen Port benutzt:

Host u123456.your-storagebox.de
        User u123456
        Port 23

Bitte wieder den Nutzer entsprechend anpassen

Danke an Thomas Leister

Diese Schritte sind im groben von Thomas Leistner kopiert und angepasst worden. Danke

Backup einrichten

Als erstes legen wir mal die Ordner an die wir brauchen

mkdir /backup
mkdir /opt/backup

Als nächstes legen wir die Datei environment.sh im Verzeichnis /opt/backup mit folgendem Inhalt an:

#!/bin/bash
export RESTIC_REPOSITORY="sftp:u1234567.your-storagebox.de:mailserver"
export RESTIC_PASSWORD="MeinSicheresBackupPasswort"

Bitte passt entsprechend u1234567 und MeinSicheresBackupPasswort an!

Jetzt legen wie die Datei backup.files im Verzeichnis /opt/backup mit diesem Inhalt an:

/etc
/backup
/root
/opt

Wie ihr dem Namen vielleicht entnehmen könnt, wollen wir, das restic diese Verzeichnisse sichert. Diese könnt ihr natürlich erweitern. Als letztes legen wir die Datei backup.sh im Verzeichnis /opt/backup mit folgendem Inhalt an:

#!/bin/bash

MAILCOW_BACKUP_LOCATION=/backup /opt/mailcow-dockerized/helper-scripts/backup_and_restore.sh backup all --delete-days 30

source /opt/backup/environment.sh

### Backup new stuff
restic backup \
        --verbose \
        --files-from /opt/backup/backup.files \

### Remove old stuff
echo "Deleting old backups ..."
restic forget --prune \
        --keep-last 7 \
        --keep-daily 14 \
        --keep-weekly 4 \
        --keep-monthly 6 \


restic check

Hier müsst ihr den Pfad zum Mailcow Verzeichniss anpassen: /opt/mailcow-dockerized Zum Schluß machen wir das Script jetzt noch ausführbar:

chmod 700 /opt/backup/backup.sh

Repo initialisieren

Damit restic auch läuft, müsst ihr den folgenden Befehl einmal ausführen, dabei wird die Repo angelegt:

source /opt/backup/environment.sh && restic init

Crontab

Jetzt legen wir noch einen Cronjob an, der alle 4 Stunden die Sicherung ausführt, dazu bearbeiten wir die Datei /etc/crontab und fügen folgendes ein:

0 */4    * * *    root    /bin/bash /opt/backup/backup.sh