In meinen Honeypots war 2019 ein deutlicher Trend sichtbar: SSH-Brute-Force-Angriffe zielten massiv auf den Benutzernamen pi. Im November 2018 waren 13 Prozent der Loginversuche mit dem User pi. Im März 2019 lag der Anteil bei 87 bis 88 Prozent.
Mar 25 06:20:21 pot06 sshd[93829]: Invalid user pi from xx.xx.xx.xx port 55312
Mar 25 06:20:21 pot06 sshd[93829]: Failed unknown for invalid user pi from xx.xx.xx.xx port 55312 ssh2
Mar 25 06:20:21 pot06 sshd[93827]: Invalid user pi from xx.xx.xx.xx port 55310
Mar 25 06:20:21 pot06 sshd[93827]: Failed unknown for invalid user pi from xx.xx.xx.xx port 55310 ssh2
Warum gerade pi?
Bis April 2022 legte Raspberry Pi OS automatisch den Benutzer pi mit dem Standardpasswort raspberry an. Millionen von Geräten liefen mit diesen Default-Credentials, viele davon direkt am Internet. SSH war standardmäßig aktiviert. Die Botnetze haben das erkannt und ihre Wörterbücher entsprechend angepasst.
Auffällig war auch die Herkunft: Die Quellen kamen nicht wie sonst überwiegend aus Asien, sondern vermehrt aus dem DACH-Raum. Das deutet darauf hin, dass die Angriffe erfolgreich waren und bereits kompromittierte Raspberry Pis in Deutschland, Österreich und der Schweiz als Sprungbrett nutzten.
Was sich geändert hat
Seit April 2022 erzwingt Raspberry Pi OS bei der Ersteinrichtung die Vergabe eines eigenen Benutzernamens und Passworts. Der automatische User pi wird nicht mehr angelegt. Das ist ein richtiger Schritt. Das Problem sind die Millionen von Altgeräten die noch mit den Default-Credentials laufen und nie aktualisiert wurden.
Wer einen Raspberry Pi am Internet betreibt: Standardpasswort ändern, SSH mit Key-Authentifizierung absichern, idealerweise mit Zwei-Faktor-Authentifizierung. Und den User pi am besten ganz durch einen eigenen ersetzen.
Ich habe heute auch mal den postfix-mta-sts-resolver auf meinem privaten System zugeschaltet. Einfach um es mal zu „probieren“.
Tut einfach und wie beschrieben, ist so aber sicher nicht für größeren und produktiven Betrieb gedacht. So wie der resolver kommt schreibt er alle Meldungen leider nur in die Konsole, es gibt keinen File-Logger. Ich ähm will/brauch den aber!
Wer es also ebenfalls mal probieren möchte, viel Spaß.
Der mta-sts-daemon loggt nun per default in /var/log/mta-sts.log. Config über yml ist ebenfalls nun drin genau wie die Konfiguration per Startparameter. Das rc.d script für FreeBSD könnte sicher schöner sein und hätte gerne im default den Benutzer mta-sts im System. Wir wollen es ja nicht als Root laufen lassen, hm?
Das einzelne Programm mta-sts-query greift auf den gleichen Logger zu, gibt damit also nichts mehr in der Konsole aus sondern auch im Logfile. Vielleicht passe ich dieses noch an, wenn dann mache ich auch einen pull request. Sonst gehe ich mal davon aus, dass es eh bald im postifx ist *daumen-drück*
Update
Habe ich jetzt gemacht. Pullrequest wurde angenommen und das neue Release ist auch schon gemacht. Jetzt also mit Logfile und rc.d script für FreeBSD.
Das Projekt FragDenStaat kennt ja inzwischen fast jeder und die meisten werden es schon mal genutzt haben. Etwas übersehen habe ich Topf Secret. Kommt aus dem gleichen Projekt, dreht sich dabei aber speziell um das Thema Lebensmittelhygiene.
Ich habe ein paar Anfragen gestellt, bin mir nur noch nicht ganz Sicher ob ich es wirklich wissen möchte. Ein Kollege hat mir mal gesagt: „Wer viel fragt; bekommt viele Antworten!“ :-/ Was meint ihr dazu?
SMTP überträgt E-Mails standardmäßig im Klartext. Mit STARTTLS lässt sich die Verbindung verschlüsseln, aber kein sendender Server ist gezwungen das auch zu tun. Schlimmer noch: Ein Angreifer im Netzwerk kann die STARTTLS-Antwort einfach unterdrücken und die Verbindung bleibt unverschlüsselt. MTA-STS (RFC 8461) löst dieses Problem: Der Empfänger veröffentlicht eine Policy, die sendenden Servern sagt „hier wird nur verschlüsselt zugestellt, mit gültigem Zertifikat, an genau diesen MX“.
MTA-STS vs. DANE
Es gibt zwei Wege, Transportverschlüsselung für E-Mail zu erzwingen: DANE und MTA-STS. DANE nutzt DNSSEC und TLSA-Records im DNS. Das ist technisch sauberer, setzt aber DNSSEC auf der Empfängerseite voraus. Viele große Provider (Google, Microsoft) haben kein DNSSEC. MTA-STS funktioniert ohne DNSSEC: Die Policy liegt als Textdatei auf einem Webserver, abgesichert durch ein normales TLS-Zertifikat. Wer beides kann, sollte beides einsetzen. DANE für die Server die DNSSEC können, MTA-STS für den Rest.
Die drei Komponenten
MTA-STS besteht aus drei Teilen: einem DNS-Record, einer Policy-Datei auf einem Webserver und optional TLS Reporting.
1. DNS TXT-Record
Ein TXT-Record unter _mta-sts.domain.de signalisiert, dass eine Policy existiert:
_mta-sts.kernel-error.de. IN TXT "v=STSv1;id=20260115130000Z;"
Die id ist ein beliebiger String. Sendende Server cachen die Policy und prüfen über die ID ob sich etwas geändert hat. Bei jeder Policy-Änderung muss die ID aktualisiert werden. Ich verwende dafür einen Zeitstempel, das macht es nachvollziehbar.
2. Policy-Datei
Die eigentliche Policy liegt unter https://mta-sts.domain.de/.well-known/mta-sts.txt. Wichtig: Der Webserver muss ein gültiges TLS-Zertifikat haben und unter genau diesem Hostnamen erreichbar sein.
enforce = nur verschlüsselt zustellen. testing = wie enforce, aber bei Fehlern trotzdem zustellen (gut zum Einstieg). none = Policy deaktiviert.
mx
An welche MX-Server zugestellt werden darf. Mehrere Einträge möglich (je eine Zeile). Wildcards gehen: *.kernel-error.de
max_age
Wie lange die Policy gecacht wird, in Sekunden. 2419200 = 28 Tage.
Der empfohlene Weg: Mit mode: testing anfangen und die TLS-Reports auswerten. Wenn alles sauber ist, auf enforce umstellen.
3. TLS Reporting
Wie bei DMARC gibt es auch für MTA-STS ein Reporting-System: SMTP TLS Reporting (RFC 8460). Ein weiterer DNS TXT-Record teilt Absendern mit, wohin sie Berichte über TLS-Verbindungsprobleme schicken sollen:
_smtp._tls.kernel-error.de. IN TXT "v=TLSRPTv1;rua=mailto:postmaster@kernel-error.de"
Die Reports kommen als JSON per Mail und enthalten Informationen über fehlgeschlagene TLS-Verbindungen, ungültige Zertifikate oder MX-Mismatches. Google und Microsoft schicken diese Reports zuverlässig.
Postfix und MTA-STS
Postfix prüft von Haus aus keine MTA-STS-Policies. Für die ausgehende Seite braucht es postfix-mta-sts-resolver, ein Policy-Daemon der sich als smtp_tls_policy_maps in Postfix einhängt. Der Daemon cached die Policies und liefert Postfix die passende TLS-Konfiguration pro Zieldomain.
Die eingehende Seite braucht keine Software. Die drei DNS-Records und die Policy-Datei auf dem Webserver reichen aus. Sendende Server wie Gmail, Outlook oder Yahoo werten die Policy selbständig aus.
Zusammen mit SPF, DKIM, DMARC und DANE ergibt MTA-STS eine lückenlose Absicherung: Authentifizierung (wer darf senden), Integrität (DKIM-Signatur) und Transportverschlüsselung (DANE/MTA-STS). Fragen? Einfach melden.
Die niederländische Regierung betreibt mit internet.nl ein kostenloses Testtool für Webserver und Mailserver. Im Gegensatz zu Qualys SSL Labs, das sich auf TLS-Konfiguration konzentriert, prüft internet.nl das gesamte E-Mail-Sicherheitsbild einer Domain.
Was getestet wird
Der Mailserver-Test prüft:
STARTTLS
Ob der MX TLS anbietet und welche Protokollversionen und Cipher unterstützt werden
Ob MTA-STS konfiguriert ist und die Policy konsistent ist
DNSSEC
Ob die Domain mit DNSSEC gesichert ist
Für jede Kategorie gibt es Punkte. 100 Prozent erreicht man nur wenn alles korrekt konfiguriert ist. Domains die sowohl beim Web- als auch beim Mailtest 100 Prozent erreichen, landen in der Hall of Fame.
Strenge Anforderungen
internet.nl ist strenger als die meisten anderen Testtools. TLS 1.0 und 1.1 geben Abzug. Ohne DANE ist kein voller Score möglich. Die Cipher-Anforderungen orientieren sich an den niederländischen IT-Sicherheitsrichtlinien, die auch für Behörden gelten.
Das macht den Test besonders nützlich als Benchmark. Wer dort 100 Prozent hat, hat sein E-Mail-Setup nach aktuellem Stand abgesichert. Wer Abzüge bekommt, sieht genau wo es hakt.
Fremde Domains testen
Man kann beliebige Domains testen, nicht nur die eigene. Das ist praktisch um Dienstleister, Geschäftspartner oder den eigenen Provider zu prüfen. Ein kurzer Test zeigt schnell ob der Mailserver auf der anderen Seite zeitgemäß konfiguriert ist oder ob dort noch SSLv3 mit RC4 läuft.
Mir ist ein weiteres Onlinetool zum scannen seiner Domain durch den Browser gerutscht. https://www.hardenize.com/
Wie immer darf man nicht bild jedem Tool trauen und sich ohne denken darauf verlassen! Die Ergebnisse müssen immer mit dem nötigen Hintergrundwissen und Feingefühl interpretiert werden…. Hardenize testet nach der Eingabe einer Domain etwas umfassender. Es schaut sich die TLS Konfiguration der Webseite, sowie des Mailservers an. Prüft auf wichtige Policys, schaut in den DNS und bewertet somit etwas das Gesamtbild.
Betreff: RE: X4300 und IPv6
was ist aus der IPv6 Anfrage des Kunden geworden? Hat der Admin einen anderen Weg gefunden?
Wir hatten den Fall eskaliert und folgende Antwort bekommen:
JSP will successfully validate only following IPv6 address types in manual address box:1. Site local IPv6 addresses (With prefix fec0)2. Link local addresses with prefix fe803. Global unicast addresses with prefix
Das heißt zusammengefasst, dass der Kopierer nicht mit einer Unique Local Address (fd00 Präfix) arbeiten kann.
Ich würde mich freuen, wenn sie sich diesbezüglich nochmal bei uns melden, damit wir wissen, ob wir den Fall schließen können.
Danke und beste Grüße
fec0?!?!? Das war eine Idee aus 1995 welche 2004 aus guten Gründen mit RFC 3879 gekippt wurde. Der Drucker frisst also fe80 sauber per EUI-64 (oh was ein wunder), globale Adressen (ok, kann jemand sinnvolle und brauche Ansätze nennen warum man das tun sollte?!?) und Adressen die man seit knapp 15 Jahren nicht mehr benutzen sollte.
Mal sehen wie Samsung / HP nun darauf reagiert. Ich kann doch nicht der einzige auf diesem Planeten mit dem Problem sein. dieses JSP-Ding wird doch auf allen erdenklichen Netzwerkdruckern eingesetzt. Das muss doch noch jemandem auffallen, oder? Dieser Bug muss doch nur von einem Entwickler dort gelesen werden, der versteht was ich sage, dann macht er es schnell schön und gelöst ist das Problem. Ist da denn keiner?!?
Im August wurde TLS 1.3 auf der IETFE-Tagung als fertig beschlossen. Damit haben sich aber alle wirklich Zeit gelassen! OpenSSL hat am 11.09.2018 die Version 1.1.1 (LTS) freigegeben. Am 12.09.2018 ist diese in die FreeBSD Ports gekommen und:
root@www:/ # /usr/local/bin/openssl version
OpenSSL 1.1.1 11 Sep 2018
Fehlt also nur noch ein Eintrag in der make.conf und schon lässt sich nginx sauber dagegen bauen und alles automatisch mit portmaster auf dem neusten Stand halten 🙂
/etc/make.conf DEFAULT_VERSIONS+= ssl=openssl111
Schaut mal nach, die meisten machen wohl jetzt schon TLS 1.3 beim lesen dieser Zeilen ^^
Qualys und SSL Labs hängen leider noch etwas nach, hier wird noch auf/gegen die Draft Version geprüft (For TLS 1.3 tests, we currently support draft version 28.). Aber ich wette das wird nicht mehr lange dauern!
TLS 1.0 stammt von 1999, TLS 1.1 von 2006. Beide Versionen haben bekannte Schwächen (BEAST, POODLE, fehlende AEAD-Cipher) und werden seit 2020 von keinem Browser mehr unterstützt. Qualys SSL Labs vergibt seit 2020 maximal ein B-Rating wenn TLS 1.0 oder 1.1 aktiv ist. Es gibt keinen Grund mehr, diese Protokolle anzubieten.
Postfix
In der main.cf die Mindestversion auf TLS 1.2 setzen. Die Einstellungen gelten getrennt für eingehende (smtpd) und ausgehende (smtp) Verbindungen:
Die Syntax >=TLSv1.2 gibt es seit Postfix 3.6. Bei älteren Versionen muss man die alten Protokolle einzeln ausschließen: !SSLv2, !SSLv3, !TLSv1, !TLSv1.1. Wenn OpenSSL 1.1.1+ oder neuer installiert ist, wird TLS 1.3 automatisch unterstützt und bevorzugt.
ssl_min_protocol gibt es seit Dovecot 2.3.15. In älteren Versionen heißt es ssl_protocols = !SSLv3 !TLSv1 !TLSv1.1. Die Cipher-Liste enthält nur AEAD-Cipher mit Forward Secrecy.
Die TLS-1.3-Cipher (TLS_AES_*) werden von OpenSSL automatisch bevorzugt und lassen sich nicht über ssl_ciphers deaktivieren. Die Reihenfolge in der Cipher-Liste gilt nur für TLS 1.2.
stunnel
Wer stunnel als TLS-Wrapper nutzt (z.B. für DNS over TLS):
Das Internet funktioniert nicht, wie euer normales Netzwerk zuhause. Es basiert in den weitesten Teilen auf BGP, dem Border Gateway Protocol. Natürlich kann es auch dabei zu Problemen kommen, mal macht ein Mensch einen Fehler, mal Hardware oder Software oder eine Regierung möchte etwas „blockieren“… Naja, oder die bösen Hacker halt.
Unter folgendem Link, werden BGP Probleme visualisiert und mit einer Historie versehen:
Klickt unbedingt auch mal auf „More detail“ bei einem Event und schaut euch das Replay an, das ist nicht nur interessant, sondern auch lehrreich. Viel besser zu verstehen, als wenn man nur die BGP Events im Log fliegen sieht!
