-=Kernel-Error=-

IT security, FreeBSD, Linux, mail server hardening, post-quantum crypto, DNS, retro computing & hands-on hardware hacks. Privater Tech-Blog seit 2003.

Kategorie: Kernel-Error-Blog (Seite 12 von 47)

Persönlicher Tech-Blog von Sebastian van de Meer — Beiträge zu IT-Security, Netzwerken, FreeBSD, Linux, Elektronik und Maker-Projekten.

Postfix: Verschleierung nur für SASL-Benutzer einrichten

2. Oktober 2019 / / Keine Kommentare

Wie man bei allen ausgehenden E-Mails dafür sorgt, dass die Client IP Adresse sowie der eingesetzte Mailclient vom Postfix verschleiert wird… Ja dieses habe ich bereits geschrieben. Postfix soll verschleiern…

Nun kann es dennoch Sinn ergeben dieses nicht für jede E-Mail zu tun, welche den Mailserver verlässt. Wenn man dieses nur auf E-Mails anwenden möchte, welche von angemeldeten Benutzern versendet werden, funktioniert es wie folgt.

Man erstellt in der master.cf vom Postfix einen neuen Service:

anonym unix n       -       -       -       0       cleanup
  -o header_checks=pcre:/usr/local/etc/postfix/header_cleanup

Nun sorgt man in der gleichen Konfigurationsdatei noch dafür, dass am Ende vom Submission und smtps Service in diesen neuen Service gesprungen wird:

submission inet n       -       n       -       -       smtpd
[...]
  -o cleanup_service_name=anonym
[...]
smtps     inet  n       -       n       -       -       smtpd
[...]
  -o cleanup_service_name=anonym

Der Inhalt unserer /usr/local/etc/postfix/header_cleanup ist dabei weiterhin gleich:

/^(Received: from)[^\n]*(.*)/ REPLACE $1 ::88 (YOUR MOM [::88])$2
/^X-Originating-IP/ IGNORE
/^User-Agent*(.*)/ REPLACE User-Agent: YOUR MOMS MAILER
/^X-Mailer*(.*)/ REPLACE X-Mailer: YOUR MOMS MAILER

Nach einem Restart vom Postifx hat man nun den gewünschten Zustand. Natürlich dürfen nun die smtp_header_checks nicht mehr in der main.cf sein:

#smtp_header_checks = pcre:/usr/local/etc/postfix/header_cleanup

Viel Spaß

Fragen? Einfach melden.

FreeBSD OpenSSH: OS-Banner sicher entfernen

26. September 2019 / / Keine Kommentare

Im Standard ist der OpenSSH Server auf einem FreeBSD so konfiguriert, dass er jeweils die aktuelle Betriebssystemversion mit ausliefert.

Dieses sieht dann im Beispiel so aus:

telnet bsd01.testsystem 22
Trying 1.2.3.4...
Connected to bsd01.testsystem.
Escape character is '^]'.
SSH-2.0-OpenSSH_7.8 FreeBSD-20180909

Um hier zumindest die genaue OS Version zu verstecken reicht folgendes in der /etc/sshd_config:

#VersionAddendum FreeBSD-20180909
VersionAddendum DemMeisterSeinRennAuto

Testet man nun noch mal sieht man nur noch die Version:

telnet bsd01.testsystem 22
Trying 1.2.3.4...
Connected to bsd01.testsystem.
Escape character is '^]'.
SSH-2.0-OpenSSH_7.8 DemMeisterSeinRennAuto

Auf einem Debian basierten System wäre es hingegen:

DebianBanner no

Siehe auch: SSH-Server absichern

Fragen? Einfach melden.

GhostBSD 19.09 Ports benutzen

25. September 2019 / / Keine Kommentare

Veraltet: GhostBSD 19.09 ist stark veraltet. Aktuelle GhostBSD-Versionen nutzen pkg statt Ports. Siehe ghostbsd.org für die aktuelle Version.

GhostBSD basierte früher direkt auf FreeBSD. Inzwischen ist es aber auf TrueOS gewechselt. So sieht es ebenfalls mit den Ports aus. Man kann also nicht wie unter FreeBSD gewohnt mit portsnap arbeiten sondern muss einen gewissen „Umweg“ nehmen.

Die zu GhostBSD gehörenden Ports bekommt man nun so ins System:

sudo git clone https://github.com/ghostbsd/ghostbsd-ports.git /usr/ports

In GhostBSD Version 19.09 ist etwas Ordnung geschaffen worden und viele vermeintlich unnötige Pakete mussten weichen. Zum arbeiten mit den Ports benötigt man daher noch folgendes:

pkg install src os-generic-userland-devtools

Ab jetzt kann man wie gewohnt mit den Ports arbeiten!

Siehe auch: GhostBSD und FreeBSD: GNOME-Keyring automatisch entsperren, Bluetooth-Audio unter FreeBSD und GhostBSD: Workaround mit Creative BT-W2

Fragen? Einfach melden.

GhostBSD und FreeBSD: GNOME-Keyring automatisch entsperren

25. September 2019 / / Keine Kommentare

Ich nutze auf meinen Desktops GhostBSD und FreeBSD Systeme zusammen mit Mate und LightDM. Ebenfalls verwende ich für ein paar Kleinigkeiten den gnome-keyring. Dabei „stört“ es mich diesen nach der Anmeldung am Desktop gesondert entsperren zu müssen. Es gibt aber eine Möglichkeit dieses von pam nach der Anmeldung automatisch entsperren zu lassen. Dafür müssen nur folgende Zeilen in der /usr/local/etc/pam.d/lightdm ergänzt werden:
auth        optional    pam_gnome_keyring.so
session        optional        pam_gnome_keyring.so    auto_start

Meine sieht nun also wie folgt aus:

#
# PAM configuration for the "lightdm" service
#

# auth
auth		sufficient	pam_self.so		no_warn
auth		include		system
auth		optional	pam_gnome_keyring.so

# account
account		requisite	pam_securetty.so
account		required	pam_nologin.so
account		include		system

# session
session		include		system
session		optional	pam_gnome_keyring.so	auto_start

# password
password	include		system

Nach dem nächsten Login habe ich nun die Möglichkeit, beim Entsperren des Keyrings, einen Haken zu setzten und schon wird bei jedem Login mein Keyring automatisch geöffnet.

Siehe auch: FreeBSD Desktop mit MATE, GhostBSD 19.09 Ports benutzen, Bluetooth-Audio unter FreeBSD und GhostBSD: Workaround mit Creative BT-W2

Fragen? Einfach melden.

DNS over TLS (DoT) mit BIND, Stunnel und Android 9 einrichten

16. Juli 2019 / / Keine Kommentare

Die Zeit ging weiter, die Entwicklung bei BIND und DNS ebenfalls. Daher gibt es nun einen neuen Beitrag, der das aktuelle Setup mit BIND 9.20 auf FreeBSD 15 beschreibt – inklusive sauberer Trennung von authoritative DNS (Port 53) und öffentlichem Resolver (DoT/DoH) sowie reproduzierbaren CLI-Tests für IPv4 und IPv6. Bitte dort weiterlesen.

Die eigenen DNS Anfragen über eine Verschlüsselte Verbindung an einen DNS Server zu schicken welchem man vertraut, dieses liest sich schon gut oder? Keiner verfolgt mein Surfverhalten und zusammen mit DNSSEC schiebt mir so schnell keiner falsche Records unter.

Am ehesten vertraue ich meinem eigenen DNS Server (ns1.kernel-error.de). Auf diesem arbeitet ein Bind und vor diesen habe ich für DoT stunnel gestellt. Die Konfiguration vom stunnel sieht dabei grob wie folgt aus:

[dns4]
accept = 853
connect = 127.0.0.1:53
cert = /usr/local/etc/stunnel/ssl/dns.crt
key = /usr/local/etc/stunnel/ssl/dns.key
CAfile = /usr/local/etc/stunnel/ssl/ca.crt
ciphers = ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
options = NO_SSLv2
options = NO_SSLv3
options = NO_TLSv1
options = NO_TLSv1.1
options = CIPHER_SERVER_PREFERENCE
options = DONT_INSERT_EMPTY_FRAGMENTS
renegotiation = no
TIMEOUTclose = 0


[dns6]
accept = 2a03:4000:38:20e::53:853 connect = ::1:53 cert = /usr/local/etc/stunnel/ssl/dns.crt key = /usr/local/etc/stunnel/ssl/dns.key CAfile = /usr/local/etc/stunnel/ssl/ca.crt ciphers = ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256 options = NO_SSLv2 options = NO_SSLv3 options = NO_TLSv1 options = NO_TLSv1.1 options = CIPHER_SERVER_PREFERENCE options = DONT_INSERT_EMPTY_FRAGMENTS renegotiation = no

Die TLS Konfiguration ergibt dabei nun folgendes Bild: https://tls.imirhil.fr/tls/ns1.kernel-error.de:853

Auf einem Android 9 Gerät kann ich also nun unter den Einstellungen ==> Netzwerk & Internet ==> Erweitert ==> Privates DNS meinen Nameserver eintragen.

Screenshot der Konfigurationseinstellungen für DoT auf einem Android 9.

Jetzt sieht mir keiner mehr beim meinen DNS Abfragen zu.

Siehe auch: RFC 7858 – DNS over Transport Layer Security, DNS over TLS mit Stunnel und BIND9: Eigenen DoT-Server einrichten, DNS over TLS mit BIND, Stunnel und Android 9: Eigener DoT-Server

Matrix Server Synapse: Erste Stable-Version 1 erschienen

12. Juni 2019 / / Keine Kommentare

Es hat einige Zeit gedauert aber gestern ist Synapse in Version 1.0.0 erschienen.

https://matrix.org/blog/2019/06/11/introducing-matrix-1-0-and-the-matrix-org-foundation
https://matrix.org/blog/2019/06/11/synapse-1-0-0-released
https://github.com/matrix-org/synapse/releases/tag/v1.0.0

Eine ganz wichtige Änderung der Version ist, dass Zertifikate anderer Server ab jetzt gültig sein müssen.

Wer seinen Server mittels pip auf den letzten Stand bringen möchte:

$ pip install --upgrade matrix-synapse

„Meldet“ euch doch mal wenn es klappt 🙂

Fragen? Einfach melden.

Tool der europäischen Kommission zur E-Mail Sicherheit MECSA

13. Mai 2019 / / Keine Kommentare

Die Europäische Kommission hat ein online Tool veröffentlicht, welches jedem Benutzer eines E-Mail Dienstes ermöglichen soll den eingesetzten E-Mail Dienst zu „prüfen“.

Natürlich kann man sich nicht blind auf so einen Test verlassen aber dieses Tool gibt einem eine ganz gute Übersicht. Diese wird dabei in drei Bereiche unterteilt:

1. Confidential Delivery
2. Phishing and Identity Theft
3. Integrity of Messages

Dazu habe ich für euch sogar ein >>Youtube Video<<.

Zum Tool selbst geht es hier lang: https://mecsa.jrc.ec.europa.eu/en/

Dort kann man nun seine E-Mail Adresse eintragen, zu dieser sendet das Tool nun eine E-Mail und bittet darum auf die Mail zu antworten. Hat man dies erledigt bekommt man seinen Code zur Auswertung. Diesen kann man nun auf der gleichen Seite eintragen und sich seine Auswertung anschauen.

Mein Identifier vom Report heute ist zum Beispiel: 19a837a05e4b7e04a3dea8cea29bd355

Prüft also ruhig einmal euer eingesetztes Mailsystem und fragt ggf. bei eurem Anbieter/Admin nach, wenn ich beim Ergebnis unsicher seit.

Siehe auch: MTA-STS einrichten

Fragen? Einfach melden.

Ersatz für www.dnsinspect.com: Alternatives DNS-Tool im Vergleich

26. April 2019 / / Keine Kommentare

Lange Zeit war dnsinspect eine wunderbare Anlaufstelle um „mal eben“ eine DNS Zone sowie deren Nameserver auf die gröbsten Probleme hinsichtlich ihrer Konfiguration zu prüfen. Schon vor Monaten ging dann dnsinspect in threatintelligenceplatform auf… Hier kann man (mit Account) zwar noch immer prüfen, es ist für mich nur nicht mehr so flüssig, simpel und detailreich wie ich es gerne hätte. Daher musste ein Ersatz hier und dieser ist https://zonemaster.net/

Dieses erfüllt alle meine Wünsche und hat genau einen Zweck und Nutzen. Schaut einfach mal drauf!

Fragen? Einfach melden.

FreeBSD: Native ZFS Encryption einrichten und nutzen

19. April 2019 / / Keine Kommentare

Seit FreeBSD 13 steht native ZFS Encryption zur Verfügung. Datasets lassen sich mit AES-256-GCM verschlüsseln, ohne dass der gesamte Pool verschlüsselt sein muss. Die Verschlüsselung greift pro Dataset und vererbt sich auf Kind-Datasets.

Verschlüsseltes Dataset anlegen

Ein neues Dataset mit Passphrase-Abfrage:

zfs create -o encryption=aes-256-gcm -o keyformat=passphrase usbpool/test01
Enter passphrase:
Re-enter passphrase:

Das Dataset wird sofort gemountet und ist einsatzbereit. Alles was hineingeschrieben wird, liegt verschlüsselt auf der Platte:

zfs list usbpool/test01
NAME             USED  AVAIL     REFER  MOUNTPOINT
usbpool/test01    99K   899G       99K  /usbpool/test01

zfs get encryption usbpool/test01
NAME            PROPERTY    VALUE        SOURCE
usbpool/test01  encryption  aes-256-gcm  -

Nach einem Reboot

Bei einem Passphrase-geschützten Dataset hat ZFS nach einem Reboot den Schlüssel nicht mehr. Das Dataset existiert, ist aber nicht gemountet:

zfs get mounted usbpool/test01
NAME            PROPERTY  VALUE    SOURCE
usbpool/test01  mounted   no       -

Mit zfs mount -l wird der Schlüssel geladen und das Dataset eingehängt:

zfs mount -l usbpool/test01
Enter passphrase for 'usbpool/test01':

zfs get mounted usbpool/test01
NAME            PROPERTY  VALUE    SOURCE
usbpool/test01  mounted   yes      -

Keyfile statt Passphrase

Statt einer Passphrase-Abfrage kann der Schlüssel auch in einer Datei liegen. Praktisch für Server die ohne Interaktion booten sollen:

zfs create -o encryption=aes-256-gcm \
  -o keyformat=passphrase \
  -o keylocation=file:///root/keys/pool.key \
  zroot/encrypted-data

Die Key-Datei enthält das Passphrase als Text. Wichtig: Die Datei muss beim Boot erreichbar sein, also auf einem unverschlüsselten Dataset liegen. Berechtigungen auf 0400 setzen.

Bestehende Datasets verschlüsseln

Verschlüsselung lässt sich nicht nachträglich auf ein bestehendes Dataset aktivieren. Man muss die Daten per zfs send | zfs receive in ein neues, verschlüsseltes Dataset migrieren. Die komplette Anleitung dafür steht im Beitrag ZFS-Dataset nachträglich verschlüsseln.

Eine Übersicht über alle ZFS-Funktionen gibt es im ZFS-Überblick. Wer sich für ZFS Encryption unter Solaris/OpenIndiana interessiert, findet die Anleitung unter ZFS Encryption unter Solaris. Fragen? Einfach melden.

Ich kann dir keine E-Mail schicken. Ich bekomme immer einen Fehler

13. April 2019 / / Keine Kommentare
Icon E-Mail Icon wird verdeckt von einem roten Kreis mit einem weißen Kreutz, welches verdeutlichen soll, dass E-Mail nicht funktioniert.

Einer der Vorteile eines eigenen Mailservers ist, dass man hier so restriktiv in seiner Konfiguration sein kann wie man es selbst für sich und seine Zwecke für richtig erachtet. So habe ich für mich entschieden, dass ich nur E-Mails annehmen möchte, welche über eine Transportverschlüsselung (TLS) bei mir eingeliefert werden. Wer also die folgende Meldung in seiner Errormail hat, dessen Mailserver hat sicher probiert die E-Mail bei mir ohne Transportverschlüsselung (also im Klartext) abzuliefern.

[...]
530-5.7.0 Must issue a STARTTLS command first
530 5.7.0 For assistance, visit https://matrix.to/#/@kernel-error:kernel-error.com
[...]

Transportverschlüsselung ist dabei bitte nicht zu verwechseln mit einer signierten oder gar verschlüsselten E-Mail. Ich nehme auch E-Mails an, welche weder signiert oder verschlüsselt sind. Die Transportverschlüsselung ist hier etwas wie das s bei httpS://. Das Mitlesen der E-Mail auf dem Weg zwischen eurem und meinem Mailserver soll damit nach Möglichkeit verhindert werden.

Möglichst verhindert werden? Ja, einen 100%tigen Schutz gibt es selbstverständlich nicht. Man kann nur versuchen sich diesem zu nähern. Dieses Nähern betrifft nun den zweiten Punkt welcher verhindern könnte, dass ihr mir eine E-Mail senden könnt. Die eingesetzte Transportverschlüsselung muss nämlich als „sicher“ gelten. Ich nehme also keine SSLv3 RC4 MD5 bla Verbindungen an. Wer also etwas wie das Folgende oder halt „Verbindung nicht möglich“ bekommt, dessen Mailserver ist nicht in der Lage eine „sichere“ TLS Verbindung aufzubauen.

warning: TLS library problem: error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared ciphe

warning: TLS library problem: error:14209102:SSL routines:tls_early_post_process_client_hello:unsupported protocol

warning: TLS library problem: error:142090FC:SSL routines:tls_early_post_process_client_hello:unknown protocol

Warum macht dieses nun nicht jeder so? Nun… Möchte man als Unternehmen Geld damit verdienen, dass man in irgendeiner Form Benutzer dazu bringt bei einem einen E-Mail Service zu nutzen, dann möchte man natürlich seinen Kunden einen möglichst reibungsfreien Austausch ermöglichen. Denn der normale Benutzer wird es kaum verstehen und sicher einfach einen Anbieter wählen bei dem es „funktioniert“. Dieses könnte man daher als Grund anführen warum nicht jeder so restriktiv in seinen Empfangseinstellungen ist. Davon abgesehen hindert es kein Unternehmen daran, seinem Mailserver für ausgehende E-Mails die Möglichkeit zu schaffen gutes TLS zu sprechen. Ok, es sei denn dieser Server steht in China oder Nordkorea. Mein Mailserver ist also weit davon entfernt etwas Unmögliches zu verlangen!!!

Sprecht also mal mit der zuständigen Person eures Mailservers und fragt aus welchem Grund euer Mailserver nicht in der Lage ist sicheres TLS zu sprechen und ob man dieses nicht vielleicht doch ändern könnte!

Um mich in der Zwischenzeit dennoch irgendwie zu erreichen gibt es verschiedene Möglichkeiten welche man >>hier<< findet. Am einfachsten sicher über Matrix/Riot: @kernel-error:kernel-error.com.

Bis dahin.

Siehe auch: SPF-Record einrichten | DKIM einrichten

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=- — RSS

Theme von Anders Norén — Hoch ↑