neunzehn83.de

Ein Mann, ein Blog, kein Plan.

Debian Linux Fileserver für Windows und Mac Clients

Ich mag keine NAS-Boxen. Zu eingeschränkt, zu langsam, zu unflexibel. Natürlich besteht für mich der perfekte Fileserver aus einem Debian-System mit ein paar wenigen Standardpaketen. In diesem Fall Debian 10 Buster.

Idee: Für den Zugriff von Windows benötigen wir Samba, für Linux und Mac Clients genügt ein entsprechender SSH-Zugang für SSHFS.

Doch beim Zugriff mit SSHFS ergibt sich ein Problem..

Die Rechtesituation

Eigentlich einfach. Wir möchten verschiedene Linux-Systembenutzer. Gleichzeitig sind dies Samba-Nutzer. Über die Gruppenzugehörigkeit können Zugriffsrechte auf Verzeichnisebene für SSH vergeben werden.

Damit neu erzeugte Dateien der Gruppe gehören und nicht dem User selbst, müssen wir das SETGID Bit beim Hauptverzeichnis setzen.

chmod g+s /storage

Problem: neue Dateien haben je nach Umask des Clients(!) nur Leserechte für die Gruppe. Noch schlimmer: wird eine Datei kopiert, die auf dem Client nur Schreib-/Leserechte für den User und keine Rechte für die Gruppe hat, wird diese so auf den Fileserver kopiert - ganz egal welche Umask gilt. Das ist ein Problem, da andere User diese Datei dann nicht bearbeiten oder vielleicht sogar nicht einmal lesen können.

SSHFS ist auf Serverseite ein SFTP-Server. Genauer gesagt der sftp-server von OpenSSH. Dieser hat leider keine Möglichkeit wie bspw. bei Samba mit inherit permissions die Dateirechte beim Schreiben explizit zu setzen.

OpenSSH sftp-server patchen

Ich habe lange hierzu eine Lösung gesucht - mir erschien der Use-Case eigentlich straight-forward - scheinbar gibt es aber keine einfache Lösung. Auf folgenden Patch für den sftp-server von OpenSSH bin ich gestoßen:

https://bugzilla.mindrot.org/show_bug.cgi?id=1844

Dieser ermöglicht mit dem dann zur Verfügung stehenden "-m" Parameter eine Umask zu forcen. Leider hat es dieser Patch auch nach 10 Jahren noch nicht ins offizielle sftp-server-Paket von Debian geschafft. Außerdem genügt das forcen einer Umask nicht, wenn die Datei auf dem Client grundsätzlich zu wenig Rechte hat. Denn eine Umask erhöht niemals die Rechte.

Ade Standardpakete, selbst ist der Mann - wir erweitern den Patch um das wirkliche Forcieren von Permissions bei allen Schreibvorgängen.

Wir benötigen zunächst grundsätzliche Zugriff auf die Sourcen von Debian-Paketen:

vi /etc/apt/sources.list
deb-src http://ftp.debian.org/debian buster main contrib

apt update

Source holen

apt source openssh-sftp-server
cd openssh-7.9p1/

Patch anwenden

Ich habe den originalen Patch erweitert, so dass Permissions von Dateien nicht übernommen sondern immer die Permissions wie im "-m" Parameter angegeben gesetzt werden.

Der Unterschied zum Originalpatch:

--- sftp-server.c.2     2020-07-13 17:17:58.152172604 +0000
+++ sftp-server.c       2020-07-13 17:18:39.136288633 +0000
@@ -919,7 +919,7 @@
                if (r == -1)
                        status = errno_to_portable(errno);
        }
-       if (a.flags & SSH2_FILEXFER_ATTR_PERMISSIONS) {
+       if (permforce == 0 && a.flags & SSH2_FILEXFER_ATTR_PERMISSIONS) {
                logit("set \"%s\" mode %04o", name, a.perm);
                r = chmod(name, a.perm & 07777);
                if (r == -1)
@@ -972,7 +972,7 @@
                        if (r == -1)
                                status = errno_to_portable(errno);
                }
-               if (a.flags & SSH2_FILEXFER_ATTR_PERMISSIONS) {
+               if (permforce == 0 && a.flags & SSH2_FILEXFER_ATTR_PERMISSIONS) {
                        logit("set \"%s\" mode %04o", name, a.perm);
 #ifdef HAVE_FCHMOD
                        r = fchmod(fd, a.perm & 07777);    

Entweder der Reihe nach den Originalpatch anwenden, dann die zwei Änderungen oben oder hier auch als Komplett-Patch herunterladen.

wget https://neunzehn83.de/blog/files/2020/openssh-sftp-server-patch.diff
patch sftp-server.c openssh-sftp-server-patch.diff

Bauen & installieren

apt build-dep devscripts openssh-sftp-server
cd debian
debuild -b -uc -us
cd ../../
dpkg -i openssh-sftp-server_7.9p1-10+deb10u2_amd64.deb

Damit haben wir den openssh-ftp-server mit "-m" Parameter gebaut!

Konfiguration

Damit bei SSHFS-Verbindungen der neue Parameter auch genutzt wird, muss die openssh-Konfiguration entsprechend angepasst werden:

vi /etc/ssh/sshd_config
Subsystem sftp /usr/lib/openssh/sftp-server -m 770
/etc/init.d/sshd restart

Testen

Wir kopieren eine Datei mit den lokalen Rechten "700" auf ein SSHFS-Mount (hier: /mnt/files/test). Nach dem Kopieren hat die Datei die Rechte "770".

Mailjet und die Deliverability zu @t-online.de

Als kleiner Mailserver-Betreiber tut man sich bekanntlich schwer, eine gute Zustellbarkeit zu erreichen. Für wirklich wichtige E-Mails, bspw. transaktionale E-Mails eines Online-Shops wie Bestellbestätigungen usw., sollte man daher auf einen externen SMTP-Service zurückgreifen.

Da gibt es einige: Mailgun, Amazon SES, etc. Wer dann noch darauf achten muss oder will, dass die über den SMTP-Service versendeten Daten nicht in irgendwelchen US-Clouds landen hat es schon schwerer. Mailjet sieht hier nach einer ordentlichen Alternative aus.

Aus aktueller Erfahrung kann ich aber sagen, dass es dort selbst mit den bezahlten Paketen ohne exklusive IP immer wieder zu Problemen mit der Zustellbarkeit kommt. Insbesondere mit @t-online.de Adressen aber auch des öfteren zu @yahoo.de und ähnliche.

Ich wollte das zuerst nicht so recht glauben, dass so ein großer Anbieter solche Probleme mit der Zustellbarkeit zu einem der größten deutschen Mailprovider hat. Der Support wollte darauf aber nicht eingehen, hat das Problem aber bestätigt und als Alternative dazu nur ein Upgrade auf eine exklusive IP angeboten (Kosten: ab 50 Euro im Monat).

Da meiner Meinung nach eine exklusive IP nur mit entsprechend hohen Versandzahlen Sinn macht, scheidet für mich wie es scheint Mailjet als Mailversender aus.

Es ist verständlich, dass deren shared IP-ranges blacklist-anfällig sind, da darüber jeder free-user wilde E-Mails versenden darf. Warum bietet Mailjet dann aber keine premium shared IP-ranges an, welche nur bezahlte Accounts nutzen dürfen? Hier hätte Mailjet die bessere Kontrolle über blacklisting.

Ich bin also auf der Suche nach einer Alternative zu Mailjet, einem zuverlässigen SMTP-Service gehostet in Deutschland oder der EU. Selbstverständlich darf dieser Service auch etwas kosten. Das ist gar nicht so einfach, hier etwas zu finden. Vorschläge willkommen.

Kündigungs-Bluff: 25% Rabatt bei UnityMedia / KabelBW

Da ich demnächst in ein Gebiet umziehe, das nicht von UnityMedia versorgt wird, habe ich meinen Kabelanschluss kürzlich gekündigt. Und das kann ich allen Bestandskunden auch nur empfehlen, denn: Seit meiner Kündigung erhalte ich immer tollere Angebote von UnityMedia.

Zuerst kam eine E-Mail mit dem Betreff "Ihre Kündigung - Letzte Chance" und bot mir 20% auf alle Internet-Produkte. Zwei Wochen später kam dann die "Allerletzte Chance" mit 25% auf alle Produkte sowie:

Noch nicht überzeugt? Dann finden wir sicher ein individuelles Angebot, das Ihnen besser gefällt. Wir freuen uns auf Sie!

Donnerwetter! Das nenn ich Service. Für mich kommen diese Angebote mangels Versorgung im neuen Wohngebiet natürlich nicht in Frage - und UnityMedia sollte das eigentlich wissen - aber allen Bestandskunden würde ich den Kündigungs-Bluff schon empfehlen!

Armer kleiner Postmaster

Geht es nur mir so, oder wird es immer schwieriger als kleiner privater Mailserver-Betreiber eine gute "deliverability" zu erreichen? Soweit ich das beurteilen kann, habe ich alles in meiner Macht stehende getan und sämtliche neumodischen Technologien in die Postfix-Config geworfen: feste IP, rDNS, SPF, DKIM und DMARC. Sämtliche "Mail-Checker" und Blacklist-Auskünfte geben meinem Mailserver und dessen IP Höchstnoten! Und dennoch: Immer wieder passiert es, dass Mails an große Anbieter still und leise im Spam-Ordner landen.

Beispiel gmail: Hier liefere ich sowieso nur noch mit IPv4 ein, da eigentlich alle Mails, die über IPv6 eingeliefert werden, im Spam-Ordner landen - aber das ist ein anderes Thema. Hin und wieder sind aber auch über IPv4 eingeliefert E-Mails betroffen und landen teilweise im Spam, ohne besondere Rückmeldung vom Mailserver. Wahrscheinlich immer dann, wenn ein mehr oder weniger entfernter IP-Nachbar ein Spam-Vorfall hatte.

Beispiel AOL: Auch hier landeten meine Mails plötzlich im SPAM-Ordner. In meiner Verzweiflung habe ich an den AOL Postmaster geschrieben und auch tatsächlich eine Antwort erhalten:

Your issue has been resolved.  Please allow two business days for delivery to improve.  If you are still receiving errors after two business days, please submit a new support request at https://postmaster.aol.com/trouble-ticket .

Warum aber überhaupt meine IP eine schlechte Reputation hatte ist nicht nachvollziehbar. Generell sind die IP-Reputationssysteme der großen Mailprovider absolut intransparent.

Ständig auf seine IP-Reputation zu achten und Mailprovider anzuschreiben ist frustrierend. Zumal die Mailserver meistens die Mails anstandslos entgegennehmen und ohne weitere Nachricht in den Spam-Ordner zustellen. Man muss also aktiv Mails an alle großen Provider senden und den Posteingang prüfen (!) um überhaupt feststellen zu können, dass man betroffen ist.

Aus diesen Grund überlege ich mir, ob ich für E-Mails an Gmail&Co nicht einfach einen SMTP-Relay a la Mailjet oder Amazon SES vor meinen Postfix schalte.

Die Idee beim Betrieb eines eigenen Mailservers ist zwar eigentlich, die Daten möglichst bei sich zu halten und nicht unnötig sämtliche E-Mails an US-Unternehmen zu übergeben - wenn man die Nutzung eines SMTP-Relays aber auf die ohnehin an US-Provider adressierten Mails beschränkt macht es eigentlich keinen Unterschied.

Habe ich einfach Pech mit meiner IP und dessen Nachbarn oder ist dies ein generelles Problem privater Mailserver-Betreiber?

fail2ban.log mit fail2ban überwachen für hartnäckige Angreifer

Wenn man mit fail2ban die eigene Logdatei überwacht kann man besonders hartnäckige Angreifer für einen längeren Zeitraum ausschließen. Dazu wird ein eigener Filter auf die fail2ban.log Datei angelegt. Fail2ban logt hier sämtliche bans und unbans. Wenn also ein Angreifer bspw. bereits mehrere Male wegen fehlgeschlagener SSH Login-Versuche aufgrund des "ssh"-Jails gebannt wurde, kann dieser jetzt mit einer längeren bantime versehen werden.

Beispiel aus der fail2ban.log für einen geduldigen Angreifer, der jedes Mal die bantime des ssh-Jails abwartet:

2016-05-24 04:28:30,113 fail2ban.actions[726]: WARNING [ssh] Ban 218.255.3.67
2016-05-24 04:38:30,867 fail2ban.actions[726]: WARNING [ssh] Unban 218.255.3.67
2016-05-24 04:38:49,899 fail2ban.actions[726]: WARNING [ssh] Ban 218.255.3.67
2016-05-24 04:48:50,681 fail2ban.actions[726]: WARNING [ssh] Unban 218.255.3.67
2016-05-24 04:49:13,715 fail2ban.actions[726]: WARNING [ssh] Ban 218.255.3.67
2016-05-24 04:59:14,497 fail2ban.actions[726]: WARNING [ssh] Unban 218.255.3.67
2016-05-24 04:59:38,533 fail2ban.actions[726]: WARNING [ssh] Ban 218.255.3.67
2016-05-24 05:09:39,313 fail2ban.actions[726]: WARNING [ssh] Unban 218.255.3.67

Der Filter für die fail2ban.log ist somit eigentlich ganz einfach. Taucht eine IP hier mehr als maxretry auf, erfolgt ein Ban mit extra hoher bantime.

Wir legen einen Filter für die fail2ban eigene Logdatei unter /etc/fail2ban/filter.d/fail2ban.conf an:

[Definition]
failregex = fail2ban.actions\[(.*)\]?: WARNING \[(.*)\] Unban <HOST>
ignoreregex = fail2ban.actions\[(.*)\]?: WARNING \[fail2ban\] Unban <HOST>

Wir aktivieren unser Jail in /etc/fail2ban/jail.local:

[fail2ban]
enabled = true
action   = iptables-allports[name=fail2ban]
filter = fail2ban
logpath = /var/log/fail2ban.log
findtime = 86400
bantime = 86400

Dieser Filter ist deutlich rabiater als die Standardwerte von fail2ban und blockt alle Ports für einen ganzen Tag.

Je nach fail2ban Version kann es vorkommen, dass der Unban des zuerst auslaufenden ssh-Jails auch den fail2ban-Jail aufhebt. Ich konnte dies mit fail2ban unter Debian Jessie zwar nicht nachvollziehen, ein Workaround hierzu wäre aber beim fail2ban eigenen Jail auf die Unbans statt Bans zu monitoren, somit ist der fail2ban-Jail niemals parallel zu anderen Jails aktiv, sondern erst direkt nach deren Aufhebung.

Archiv »