How to secure your Octoprint installation

The community of makers using 3D printers is growing. So does the community of Octoprint users. Of course these users want to access their printers interface from remote.

The ISC was mentioning lots of insecure Octoprint installation in one of their posts. 

In return there was another blog post at Octoprint.org telling about more or less secure practices to gain remote access to Octoprint installations. Here is my take on this.

The mentioned blog post tell about how insecure it is to just open a port for forwarding on your router. Do never forget: once you enable the port forwarding, your Octoprint installation is visible to the world, and bad guys could possibly hijack your installation, and turn your heatbed and nozzle to „5 million degrees“, burn your house, and more. So it might be a good idea to add some security to our installation.

„How to secure your Octoprint installation“ weiterlesen

Postfix Antispam – Spamcheck

Mit Spamassassin wird nun anhand von Regular Expressions versucht herauszufinden, ob die Mail Spam ist oder nicht. Den voreingestellten Wert von 5 und mehr Punkten zum Markieren als SPAM habe ich auf 3 gestellt. Die so markierten Mails landen dann bei den Usern über eine Regel im Spam-Ordner, wo der User nochmal prüfen kann, ob die Mail wirklich SPAM ist.

Hier wurden die betreffenden Änderungen in /etc/mail/spamassassin/local.cf gemacht. Wichtig ist dabei required_score und required_hits. Es gab da eine Änderung, seit diesem Zeitpunkt finden sich beide Optionen in dieser Datei.

Möchte man bestimmte Absender von der SPAM-Prüfung ausnehmen, so kann man in dieser Datei auch Whitelist-Einträgf erzeugen: whitelist_from *@blablub.de sorgt dafür, daß eMails von blablub.de 100 Spam-Punkte gutgeschrieben bekommen. Der Absender startet also mit -100 Punkten beim Spamcheck und muss schon gegen viele Regeln verstoßen, um nun noch als Spam markiert zu werden.

Mittlerweile nutzen wir den Spamassassin nicht mehr zum Markieren von Spam. Der Aufwand dafür übersteigt den Nutzen bei weitem.

Postfix Antispam – Viruscheck

Ich prüfe hier mit CLAMAV als Daemon auf Viren in Mails. Durch die Schritte 1-4 hat dieser Daemon allerdings nicht mehr allzuviel Arbeit, ca. 2-5 Viren je Monat müssen noch ausgesondert werden.

Wichtig ist, den clamd zu nutzen, da dies wesentlich resourcenfreundlicher ist als eine Nutzung des Kommandozeilenscanners freshclam.

Je nach verwendeter Distribution lädt man sich bei https://www.clamav.net/ das entsprechende Paket herunter und kompiliert selbst, oder nutzt die Tools wie apt. Eine gute Anleitung findet sich hier: https://www.clamav.net/documents/installing-clamav.

Damit der Clam was tut, muss außerdem Amavisd-new installiert werden. Je nach Distribution geht das anders. Eine Anleitung für Ubuntu-User findet sich z.B. hier: https://wiki.ubuntuusers.de/Amavis-Spam-Virenfilter/.

Wenn beide Tools installiert sind, müssen wir dem Postfix noch erklären, was er damit machen soll. Aber auch das findet sich schon tausendfach beschrieben im Netz. Wichtig ist, eine Art Kette aufzubauen. Also: Mail kommt am Postfix an, der übergibt sie an Amavis, da wird sie per ClamAv gescannt und zurück an Postfix übergeben. Der „Voodoo“ dafür findet hauptsächlich in Postfix master.cf statt.

Dazu habe ich die Zeile für smtp geändert in

 

smtp inet n - - - - smtpd
-o content_filter=smtp-amavis:[127.0.0.1]:10024

Am Ende der master.cf habe ich angefügt

smtp-amavis unix - - - - 2 smtp
-o smtp_data_done_timeout=1200
-o smtp_send_xforward_command=yes
-o disable_dns_lookups=yes
-o max_use=20
127.0.0.1:10025 inet n - - - - smtpd
-o local_recipient_maps=
-o relay_recipient_maps=
-o smtpd_restriction_classes=
-o smtpd_delay_reject=no
-o smtpd_client_restrictions=permit_mynetworks,reject
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o smtpd_data_restrictions=reject_unauth_pipelining
-o smtpd_end_of_data_restrictions=
-o mynetworks=127.0.0.0/8
-o smtpd_error_sleep_time=0
-o smtpd_soft_error_limit=1001
-o smtpd_hard_error_limit=1000
-o smtpd_client_connection_count_limit=0
-o smtpd_client_connection_rate_limit=0
-o receive_override_options=no_header_body_checks,no_unknown_recipient_checks

Damit gibt der Postfix eingehende Mails an den Amavis weiter und bekommt sie von da wieder zurück.

Postfix Antispam – Greylisting

Nach dem eine Mail also die ersten Hürden genommen hat, kommt Greylisting zu Einsatz. Dabei wird beim ersten Zustellversuch ein TEMPORARY ERROR als Antwort gesendet. Jeder vernünftige Mailserver versucht die Zustellung der Mail dann nochmals. Allgemein wird Greylisting so konfiguriert, dass der gegnerische Mailserver nur 1-2 Minuten warten muss vor dem erneuten Zustellversuch. Leider haben sich darauf viele Bots eingestellt. Hier wird mit 5 Minuten Wartezeit gearbeitet – sehr erfolgreich. Über eine Whitelist sind Mailserver von Partnern z.B. vom Greylisting befreit. Auch wenn bestimmte Mailserver-Absender-Kombinationen mehrfach erfolgreich das Greylisting überwunden haben, wird ein Eintrag in der Whitelist-Datenbank erzeugt.

Zum Einsatz kommt dabei Postgrey von David Schweikert. In der /usr/bin/postgrey sollte in der Zeile delay => $opt{delay} || 300, den Wert auf mindestens 300 setzen, das war hier elementar.

Postfix Antispam – Receiver

Grundlegend sollte ein MTA nur Mails für Domains annehmen, für die er auch zuständig ist und wenn es den entsprechenden Empfänger auch gibt.

In der main.cf des Postfix ist daher besonderes Augenmerk auf den Eintrag mydestination zu verwenden. Hier sollten wirklich nur die Domains aufgeführt werden, für die der MTA Mails akzeptieren soll.

mydestination = domain.de, anderedomain.de,...

Durch eine spezielles Regelset (rc_full) wird verhindert, dass Mails in das MTA-System gelangen, für die es keine Empfänger gibt. Dies ist elementar wichtig, wenn der Front-MX nur als Relay für dahinter liegende SMTP-Strukturen dient. In der rc_full werden für beteiligte Domains die validen Empfänger gelistet. Mails an andere als die definierten Empfänger werden mit einem USER UNKNOWN beantwortet. Im Detail gibt es dazu folgenden Eintrag in den smtpd_recipient_restrictions von /etc/postfix/main.cf: check_recipient_access hash:/etc/postfix/rc_full

Aber was enthält nun diese rc_full-Datei? Hier ein Auszug:

emaila@domain.de OK
emailb@domain.de OK
domain.de REJECT User unknown in domain.de
. OK

Mails an emaila und emailb werden über das OK akzeptiert. Alle anderen eMailempfänger für domain.de werden mit User unknown REJECTed. Der Eintrag mit dem Punkt sorgt dafür, dass Mails an nicht in der rc_full aufgeführte Domains akzeptiert werden – natürlich sind dafür nur die Domains in mydestination (siehe oben) gültig. Nach dem Editieren sorgt ein postmap rc_full für die Aktualisierung der Postfix-Datenbanken. Hier gibt es noch Optimierungsmöglichkeiten, in dem die Einträge zum Beispiel anhand der Nutzerdatenbank des nachgelagerten Exchange erstellt werden könnten.

Die ganze Zeile in der main.cf sieht so aus:

smtpd_recipient_restrictions = permit_mynetworks,reject_non_fqdn_recipient,reject_unauth_destination,check_recipient_access hash:/etc/postfix/rc_full

permit_mynetworks erlaubt allen Clients in den angeführten Netzwerken in mynetworks das Anliefern von Mails an den Mailserver zum Weiterversenden

mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 10.0.0.0/8 192.168.1.0/24

reject_non_fqdn_recipient verhindert, dass Mails an Empfänger ohne qualifizierten Domainnamen gesendet werden können.

reject_unauth_destination verwirft Mails an Empfänger, für die wir laut Konfiguration gar nicht zuständig sind.

Postfix Antispam – Helo

 

In der HELO-Phase des SMTP-Dialogs Mails zu blocken hat sich als problematisch herausgestellt.

Selbst viele professionelle IT-Abteilungen sind anscheindend nicht in der Lage, ihre abgehenden MTAs sauber zu konfigurieren. Daher habe ich alle Checks bezüglich des HELOs deaktiviert und akzeptiere auch Hostnamen wie exchange.local und Ähnliches.

Aus eigenen Tests heraus kann ich vor der Verwendung der Postfix-Optionen reject_unknown_hostname und reject_non_fqdn_hostname nur warnen. So verlockend die Verwendung dieser Optionen auch scheint: es werden zuviel erwünschte eMails abgelehnt. Eventuell sind diese Optionen in Zukunft einmal sinnvoll verwendbar.

Postfix Antispam – Connect

Der mit Abstand meiste Müll lässt sich durch eine Prüfung des gegnerischen SMTP-Partners aussondern.

Das Ablehnen von Mail in dieser Phase ist auch rechtlich gesehen eine gute Idee, weil auf diese Art und Weise abgelehnte Mails wohl nicht als zugestellt gelten nach derzeitiger Rechtsauffassung.

So prüfe ich auf vorhandene DNS-Einträge für die Absender-IP-Adresse. Die gegnerische IP-Adresse wird auch durch zwei Blacklisten geprüft. So fallen schon mal viele Mails aus Bot-Netzen etc. raus, weil die befallenen PCs entweder nur über eine IP-Adresse ohne zugehörigen DNS-Eintrag verfügen bzw. weil die IP-Adressen meist sehr schnell auf einer Blacklist erscheinen, wenn sie denn mal missbraucht wurden.
Wenn Hosts auf Grund dieser Rules auffällig werden, werden sie zudem durch das kleine Script smtpblock für eine Weile daran gehindert, erneute Zustellversuche zu unternehmen. Diese Maßnahme allein senkt die Last des MTA erheblich.

In meiner main.cf steht dazu:


smtpd_client_restrictions = permit_mynetworks,check_client_access hash:/etc/postfix/client_is_good,reject_unknown_client,reject_rbl_client zen.spamhaus.org,reject_rbl_client bl.spamcop.net

Die beiden Einträge reject_rbl_client zen.spamhaus.org und reject_rbl_client bl.spamcop.net prüfen, ob die absendende IP-Adresse schon mal negativ aufgefallen ist oder ob diese Adresse zum dynamischen Einwahlpool von Internetprovidern gehört – von beiden Gruppen nehmen wir hier keine Mails an.

Der Eintrag reject_unknown_client entsorgt Verbindungsversuche von „Mailservern“ ohne DNS-Eintrag – meist verbergen sich hinter diesen Hosts verseuchte PCs von arglosen Anwendern, auf denen ein Bot sein Unwesen treibt.

Das permit_mynetworks sorgt dafür, dass die anderen Prüfungen auf Verbindungen aus dem internen Netz nicht geprüft werden.

Der Eintrag check_client_access hash:/etc/postfix/client_is_good ist eine Whitelist, die dafür sorgt, dass auch falsch konfigurierte MX von Partnern und Kunden nch Mails abladen können. Dazu gibt es die Datei /etc/postfix/client_is_good mit etwa folgendem Inhalt:


1.2.3.4 OK

Diese Zeile sorgt nach einem postmap sender_is_good dafür, dass Mails von 1.2.3.4 angenommen werden ohne erst eine Prüfung im DNS zu machen bzw. eine Blacklist dafür zu befragen.

Häufig sieht man in den Logfiles, dass ein MX versucht dutzende oder hunderte Verbindungen gleichzeitig aufzumachen. Diese bleiben dann offen bis zum Timeout. Da der Postfix so konfiguriert ist, dass ein Timeout erst sehr spät erfolgt und da die gleichzeitig möglichen Verbindungen limitiert sind, kann dies zu einem Denial of Service führen. Dies kann man ändern, indem man in der main.cf die Timeouts ändert. Folgende Werte haben sich bei mir bewährt:


smtp_connection_reuse_time_limit = 40s
smtpd_timeout = 20s
smtpd_idle_timeout = 20s

Ein weitere Aufgabe besteht darin, einmal negativ aufgefallene Clients von der Verbindungsaufnahme zu unserem Mailsystem abzuhalten, dazu dient mir ein kleines Perlscript mit dem Namen smtblock. Dieses Script parst das Maillog nach abgelehnten Mails aus oben genannten Regeln und erstellt eine Firewallregel für auffällige IP-Adressen. Aller einer Stunde werden diese Blockeinträge wieder gelöscht. Es gibt sicher Optimierungsmöglichkeiten dafür, so werden derzeit auch doppelte Einträge erzeugt. Ausserdem ist das Script ein Resourcenfresser, da es mehrfach pro Minute durch das Maillog auf Suche geht. Bei MTAs an der Lastgrenze ist das sicher keine gute Idee – für mich funktioniert das prima. Für Fehlerfreiheit garantiere ich nicht – für Schäden durch den Einsatz dieses Scripts hafte ich nicht!