-=Kernel-Error=-

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

Schlagwort: FreeBSD (Seite 2 von 7)

FreeBSD: Unverschlüsseltes ZFS-Dataset nachträglich verschlüsseln

26. April 2021 / / Keine Kommentare
Bild der Bücher FreeBSD Mastery ZFS und FreeBSD Mastery Advanced ZFS

ZFS Encryption lässt sich nicht nachträglich auf ein bestehendes Dataset aktivieren. Die Daten müssen per zfs send | zfs receive in ein neues, verschlüsseltes Dataset geschrieben werden. Typischer Anwendungsfall: Jails, die in eigenen Datasets liegen und nach einem FreeBSD-Upgrade auf 13+ verschlüsselt werden sollen.

Wer die Grundlagen zu ZFS Encryption noch braucht (Dataset anlegen, Passphrase, Mount nach Reboot), findet sie im Beitrag Native ZFS Encryption einrichten.

Ausgangslage

Ein Pool zroot mit dem unverschlüsselten Dataset varta:

zfs list zroot/varta
NAME          USED  AVAIL     REFER  MOUNTPOINT
zroot/varta   100M  12.0G      100M  /zroot/varta

zfs get encryption zroot/varta
NAME         PROPERTY    VALUE   SOURCE
zroot/varta  encryption  off     default

Migration

Bei zfs send | zfs receive kann man kein Passphrase interaktiv eingeben, weil stdin durch die Pipe belegt ist. Deshalb legt man den Schlüssel temporär in einer Datei ab:

echo 'MeinGeheimesPassphrase' > /tmp/keyfile.txt
chmod 600 /tmp/keyfile.txt

Snapshot erstellen und in ein neues verschlüsseltes Dataset senden:

zfs snapshot zroot/varta@migration

zfs send zroot/varta@migration | \
  zfs receive -F \
  -o encryption=on \
  -o keyformat=passphrase \
  -o keylocation=file:///tmp/keyfile.txt \
  zroot/en-varta

Das neue Dataset zroot/en-varta enthält jetzt dieselben Daten, verschlüsselt mit AES-256-GCM:

zfs list zroot/varta zroot/en-varta
NAME             USED  AVAIL     REFER  MOUNTPOINT
zroot/en-varta   100M  11.8G      100M  /zroot/en-varta
zroot/varta      100M  11.8G      100M  /zroot/varta

Aufräumen

Die Keyfile-Referenz auf Passphrase-Abfrage umstellen und die temporäre Datei löschen:

zfs set keylocation=prompt zroot/en-varta

zfs get keylocation zroot/en-varta
NAME            PROPERTY     VALUE   SOURCE
zroot/en-varta  keylocation  prompt  local

rm /tmp/keyfile.txt

Dann das alte Dataset entfernen und das neue umbenennen:

zfs destroy -r zroot/varta
zfs rename zroot/en-varta zroot/varta

Fertig. Das Dataset liegt jetzt verschlüsselt am selben Mountpoint wie vorher:

zfs get encryption,keylocation,keyformat zroot/varta
NAME         PROPERTY     VALUE        SOURCE
zroot/varta  encryption   aes-256-gcm  -
zroot/varta  keylocation  prompt       local
zroot/varta  keyformat    passphrase   -

Stolperfallen

Keyfile in /tmp ist ein Kompromiss. Auf FreeBSD-Default ist /tmp zwar ein tmpfs im RAM, aber bei Speicherdruck kann das System swappen. chmod 600 schützt gegen andere Benutzer, nicht gegen root, Backup-Prozesse oder einen Crash-Dump. Sauberer ist eine keylocation auf einem schon verschlüsselten Dataset oder ein FIFO statt einer regulären Datei. In beiden Fällen existiert die Passphrase nie persistent auf der Platte.

Properties gehen beim Send verloren. Ohne -R (Replication Stream) oder explizite -o-Optionen werden compression, recordsize, quota, reservation, atime und eigene Properties nicht mitübertragen. Wer compression=zstd oder recordsize=1M gesetzt hatte, muss die beim receive wieder setzen oder direkt einen Replication Stream nutzen.

Mountpoint nach dem Rename prüfen. Lag das alte Dataset auf /var/jails/varta, muss der Mountpoint nach dem Rename wieder explizit gesetzt werden, sonst landet das Dataset am Default-Pfad des Pools:

zfs set mountpoint=/var/jails/varta zroot/varta

Jail vorher stoppen. service jail stop <name> bzw. iocage stop oder bastille stop. Sonst sind Dateien offen, zfs destroy -r schlägt fehl und der Rename macht keinen Spaß.

Inkrementelle Migration für große Datasets

Bei Jails mit Datenbank, Mailspool oder einfach mehreren hundert GB ist Downtime gleich Send-Laufzeit nicht akzeptabel. Besser: initial senden während der Dienst läuft, dann nur kurz stoppen und den inkrementellen Rest nachziehen.

# Phase 1: initialer Send im laufenden Betrieb
zfs snapshot zroot/varta@migration-1
zfs send zroot/varta@migration-1 | \
  zfs receive -F \
  -o encryption=on \
  -o keyformat=passphrase \
  -o keylocation=file:///tmp/keyfile.txt \
  zroot/en-varta

# Phase 2: Dienst stoppen, inkrementelles Delta senden
service jail stop varta
zfs snapshot zroot/varta@migration-2
zfs send -i @migration-1 zroot/varta@migration-2 | \
  zfs receive zroot/en-varta

# Phase 3: Rename und Neustart
zfs destroy -r zroot/varta
zfs rename zroot/en-varta zroot/varta
zfs set mountpoint=/var/jails/varta zroot/varta
service jail start varta

Die Downtime reduziert sich so auf den inkrementellen Send plus Rename, bei einer typischen Mailbox sind das Sekunden statt Minuten. Bei sehr aktiven Datasets kann man mehrere inkrementelle Snapshots nacheinander schieben, bis das Delta klein genug für die gewünschte Zielzeit ist.

Update 2026: was heute dazugekommen ist

OpenZFS 2.x ist auf FreeBSD 14 und 15 stabil. Der eigentliche Migrationspfad hat sich nicht geändert, drumherum ist einiges dazugekommen:

Raw encrypted send/receive. Mit zfs send -w wird ein verschlüsseltes Dataset ohne Entschlüsselung übertragen. Der Remote-Host lagert den Stream, kennt den Schlüssel nicht und sieht keinen Klartext. Für Offsite-Backups der saubere Weg, sobald die Migration durch ist:

zfs snapshot zroot/varta@backup
zfs send -w -R zroot/varta@backup | \
  ssh backup@remote zfs receive backuppool/varta

Andere Keyformate. Statt keyformat=passphrase gehen auch keyformat=raw (32-Byte-Keyfile, z.B. aus HSM oder TPM) oder keyformat=hex (64 Zeichen Hex). keylocation=https://... holt den Schlüssel beim Pool-Import von einer URL, praktisch für headless Systeme, bei denen die Passphrase-Abfrage beim Boot stört.

Kompression vor Verschlüsselung. ZFS komprimiert zuerst, verschlüsselt danach. compression=zstd zusammen mit encryption=on wirkt also wie erwartet, und der komprimierte Zustand bleibt auch im Raw Stream erhalten.

Nur für Datenpools und Non-Root-Datasets. Diese Anleitung deckt Jails, Home-Verzeichnisse, Mailspools und ähnliches ab. Verschlüsseltes Root-on-ZFS ist ein eigenes Thema und braucht zusätzlich Boot-Environment-Handling (bectl) sowie ein geli-verschlüsseltes Swap.

Siehe auch

Native ZFS Encryption einrichten und nutzen für die Grundlagen zu Dataset, Passphrase und Mount nach Reboot. Verschlüsseltes ZFS-Backup auf USB-Platte mit geli für die Offline-Sicherung. Linux Mint mit verschlüsseltem ZFS-Root-Pool installieren für das Linux-Pendant mit Root-Pool.

Eine Übersicht über alle ZFS-Funktionen gibt es im ZFS-Überblick. Fragen? Einfach melden.

FreeBSD IPv6-Probleme bei Netcup beheben

1. Februar 2021 / / Keine Kommentare
Dinosaurier beißt ein Patchkabel durch, im Hintergrund das Buch IPv6 Workshop.

Als Kunde, der bei Netcup FreeBSD-Rootserver auf KVM/QEMU-Basis einsetzt, habe ich schnell gemerkt, dass meine IPv6-Verbindung nicht stabil ist.

Symptome

  • Direkt nach dem Boot funktioniert IPv6 wie gewünscht
  • Nach einiger Zeit brechen Verbindungen zusammen — sowohl eingehend als auch ausgehend
  • Verbindungen haben „Startprobleme“ — ein Ping läuft erst ein paar Mal ins Leere, dann funktioniert plötzlich alles wieder für einen Moment

Ein Ping auf die IPv6-Adresse des Netcup-Gateways stellt die Konnektivität kurzzeitig her. Das deutet sofort auf ein NDP-Problem (Neighbor Discovery Protocol) hin.

Diagnose

FreeBSD behandelt Neighbor Solicitations anders als Linux. Netcups Netzwerk-Setup kommt damit offenbar nicht klar — unter Linux funktioniert IPv6 problemfrei, unter FreeBSD (und NetBSD) nicht. Die ICMPv6-Statistiken zeigen das Problem deutlich:

netstat -s -picmp6 | grep -i neighbor
    neighbor solicitation: 29          # Output: wenige eigene Anfragen
    neighbor advertisement: 10         # Output: wenige eigene Antworten
    neighbor solicitation: 633         # Input: Flut eingehender Anfragen
    neighbor advertisement: 25         # Input: wenige Antworten zurück
    423 bad neighbor solicitation messages  # <-- das Problem

633 eingehende Neighbor Solicitations, davon 423 als „bad" verworfen. FreeBSD verwirft die Anfragen, weil sie nicht von einer On-Link-Adresse kommen — ein Verhalten, das FreeBSD aus Sicherheitsgründen seit einem Security Advisory von 2008 erzwingt.

Lösung

FreeBSD anweisen, Neighbor Discovery nach RFC 4861 zu machen — das akzeptiert auch Solicitations von Off-Link-Adressen, wie es Netcups Router sendet. Zum Testen:

sysctl net.inet6.icmp6.nd6_onlink_ns_rfc4861=1

Funktioniert es, den Eintrag in /etc/sysctl.conf permanent machen:

net.inet6.icmp6.nd6_onlink_ns_rfc4861=1

Wichtig: FreeBSD hat dieses Verhalten aus Sicherheitsgründen deaktiviert. Die strenge Prüfung schützt gegen NDP-Spoofing-Angriffe. Auf einem VPS bei einem vertrauenswürdigen Hoster ist das Risiko überschaubar — auf einem System in einem offenen Netzwerk sollte man abwägen.

Netcup-Support

Ich habe einige Zeit mit dem Support verbracht. Das Problem wurde mir bestätigt — es liege an den Core-Routern, ein Update sei geplant, aber ohne Termin. Mein System wurde auf verschiedene Hosts verschoben, ohne Besserung. Das Problem ist im Netcup-Forum bekannt und betrifft alle BSD-Systeme. Aus meiner Sicht lässt Netcups Setup keine einfache Lösung zu, daher bleibt der sysctl-Workaround.

Siehe auch: IPv6 ULA und Priorität

Fragen? Einfach melden.

Cliqz: Der Datenschutzbrowser – Was du wissen solltest

8. Januar 2020 / / Keine Kommentare

Veraltet: Cliqz wurde im April 2020 eingestellt. Wer einen datenschutzfreundlichen Browser sucht, kann Firefox mit entsprechenden Einstellungen oder Brave nutzen.

Cliqz Logo

Ich bin auf Cliqz aufmerksam gemacht worden und teste den Browser seit einigen Tagen.  Der Browser ist aus einer Suchmaschinenerweiterung für den Firefox entstanden. Auf Firefoxbasis ist es dann selbst zu einen Browser geworden. Die Entwickelnde Firma sitzt in Deutschland und hält selbst Anteile an Ghostery. Ghostery ist also im Browser integriert, wie auch die Suchmaschinenerweiterung, ein Videodownloader….

Firefox ist seit vielen Jahren der Browser meiner Wahl. Gestartet habe ich mit Netscape und ich habe ihn schon eingesetzt als er noch den Namen Phoenix hatte. Damit möchte ich sagen, dass ich schon sehr „eingesessen“ bin und mir ein Wechsel schwer fallen würde. Da Cliqz aber die Firefox Basis hat, bekannt funktioniert und sogar die Firefox Plugins funktionieren (ja ja)… Ersetzt er mehr und mehr meinen Firefox!

Wer ihn sich also noch nicht angeschaut hat und selbst Firefox Benutzer ist, könnte einen Blick riskieren. Ohne große Schmerzen erwarten zu müssen!

https://cliqz.com/

Oh ja… Bei FreeBSD ist er bereits in den Ports.

Fragen? Dann fragen.

Bluetooth-Audio unter FreeBSD und GhostBSD: Workaround mit Creative BT-W2

21. Oktober 2019 / / Keine Kommentare

Bluetooth-Audio und FreeBSD vertragen sich nicht. Der Bluetooth-Stack wird nicht mehr gepflegt, in OpenBSD wurde er komplett entfernt. Einen Bluetooth-Dongle oder eine eingebaute Bluetooth-Karte dazu zu bringen, sich mit einem Audio-Gerät zu verbinden, funktioniert unter FreeBSD praktisch nicht.

Der Workaround: Creative BT-W2

Die Lösung ist ein USB-Dongle, der sich selbst um Bluetooth kümmert: Der Creative BT-W2. Das Gerät meldet sich am Betriebssystem als normale USB-Soundkarte. Das Pairing mit dem Bluetooth-Kopfhörer oder -Lautsprecher macht der Dongle selbständig per Knopfdruck. FreeBSD sieht nur eine Soundkarte, kein Bluetooth.

Das Kernelmodul snd_uaudio kümmert sich um die Erkennung. In der /etc/rc.conf:

kld_list="snd_uaudio"

Nach dem Laden des Moduls erscheint das Gerät im dmesg:

uaudio0:  on usbus0
uaudio0: Play: 48000 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer.
uaudio0: Record: 48000 Hz, 1 ch, 16-bit S-LE PCM format, 2x8ms buffer.
pcm5:  on uaudio0
uaudio0: HID volume keys found.

Pairing und Nutzung

Kurz den Knopf am Dongle drücken, er blinkt und verbindet sich mit dem nächsten Bluetooth-Audio-Gerät in Reichweite. Kopfhörer, Headsets, Lautsprecher und Mikrofone funktionieren. Die Qualität reicht auch für Telefonie, Latenz und Codec sind in Ordnung.

Das Audio-Device ist je nach Systemkonfiguration /dev/dsp5 oder ein anderer Index. Mit cat /dev/sndstat lässt sich prüfen welches Device der BT-W2 bekommen hat.

Nicht die eleganteste Lösung, aber sie funktioniert zuverlässig. Solange der Bluetooth-Stack auf FreeBSD nicht wiederbelebt wird, ist ein Dongle wie der BT-W2 der pragmatischste Weg.

Siehe auch: FreeBSD auf dem Desktop, GhostBSD und FreeBSD: GNOME-Keyring automatisch entsperren, GhostBSD 19.09 Ports benutzen

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.

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.

FreeBSD als IPsec/L2TP-Client für Microsoft Windows Routing und RAS VPN

4. April 2019 / / Keine Kommentare
FreeBSD IPsec L2TP Client to Microsoft Windows Routing RAS Server Diagramm.

Einen FreeBSD-Desktop an einen Microsoft Windows Routing und RAS VPN-Server anbinden, per IPsec/L2TP. Klingt nach Qual, ist aber erstaunlich einfach. Ich nutze strongSwan für den IPsec-Tunnel und mpd5 für L2TP.

Ausgangslage

Der FreeBSD-Desktop hat die IP 192.168.10.57. Der Windows RRAS-Server steht unter vpnserver.domain.tld (88.88.88.88). Tunneltyp ist IPsec/L2TP mit Pre-Shared Key für IPsec und Active Directory-Anmeldung über L2TP. Die Firmennetze 172.16.0.0/12 und 10.0.0.0/8 sollen über den Tunnel erreichbar sein.

strongSwan: IPsec-Tunnel

/usr/local/etc/ipsec.conf:

config setup

conn %default
        ikelifetime=60m
        keylife=20m
        rekeymargin=3m
        keyingtries=1
        keyexchange=ikev1
        authby=psk

conn vpnname
        type=transport
        leftfirewall=yes
        right=vpnserver.domain.tld
        rightid=%any
        rightsubnet=0.0.0.0/0
        auto=add
        left=%defaultroute
        leftprotoport=17/%any
        rightprotoport=17/1701
        ike=3des-sha1-modp1024!
        esp=3des-sha1
        modeconfig=push

Der Pre-Shared Key in /usr/local/etc/ipsec.secrets:

vpnserver.domain.tld %any : PSK "abcdefg1234567"

Tunnel aufbauen:

root@errortest:~ # ipsec up vpnname
initiating Main Mode IKE_SA vpnname[20] to 88.88.88.88
[...]
IKE_SA vpnname[20] established between 192.168.10.57[192.168.10.57]...88.88.88.88[88.88.88.88]
CHILD_SA vpnname{38} established with SPIs c387d93f_i 4720cab6_o
  and TS 192.168.10.57/32[udp] === 88.88.88.88/32[udp/l2f]
connection 'vpnname' established successfully

Status prüfen mit ipsec statusall. Wichtig ist die Zeile ESTABLISHED und dass die SPIs gesetzt sind.

mpd5: L2TP-Verbindung

/usr/local/etc/mpd5/mpd.conf:

startup:
    log +ALL +EVENTS -FRAME -ECHO

default:
    load L2TP_client

L2TP_client:
    create bundle static B1
    set iface up-script /home/kernel/vpnname-up.sh
    set iface down-script /home/kernel/vpnname-down.sh
    set bundle enable crypt-reqd
    set bundle enable compression
    set bundle enable ipv6cp
    set ccp yes mppc
    set mppc no e40 e56
    set mppc yes e128 stateless
    set ipcp ranges 0.0.0.0/0 0.0.0.0/0
    set ipcp enable req-pri-dns
    set ipcp enable req-sec-dns
    set iface route 172.16.0.0/12
    set iface route 10.0.0.0/8
    set iface enable tcpmssfix

    create link static L1 l2tp
    set link action bundle B1
    set auth authname "AD-USERNAME"
    set auth password "AD-PASSWORD"
    set link max-redial 0
    set link mtu 1400
    set link keep-alive 20 75
    set link accept chap-msv2
    set link no pap eap

    set l2tp peer vpnserver.domain.tld
    open

Starten mit mpd5. Wenn alles klappt, erscheint ein ng0 Interface:

ng0: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST>
    inet 10.16.100.34 --> 10.16.100.13 netmask 0xffffffff

Hinweise zur mpd5-Konfiguration

set ccp yes mppc aktiviert MPPC-Komprimierung und MPPE-Verschlüsselung. set mppc yes e128 stateless ist Pflicht für die Zusammenarbeit mit MS-CHAPv2 auf der Windows-Seite. Andere MPPE-Varianten (e40, e56) funktionieren mit MS-CHAPv2 nicht.

Der Windows VPN-Server übermittelt zwar Routen und DNS-Server, mpd5 übernimmt davon aber nicht alles automatisch. Deshalb die manuellen Routen mit set iface route. Die DNS-Server werden per IPCP abgefragt und an die Up/Down-Scripte übergeben. Da ich die DNS-Konfiguration kenne, kopiere ich in den Scripten einfach die passende /etc/resolv.conf.

Ich starte IPsec und dann mpd5 von Hand, wenn ich die Verbindung brauche. Man kann beides auch als Dienst konfigurieren.

Wer seinen Windows RRAS-Server mit sicheren Cipher Suites absichern will: In dem Beitrag geht es um die TLS-Seite der gleichen Infrastruktur.

Siehe auch: RRAS L2TP/IPsec VPN Cipher Suites

Fragen? Einfach melden.

Postfix MTA-STS Resolver für FreeBSD mit Logfile einrichten

25. März 2019 / / Keine Kommentare

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!

Also habe ich einen Fork erstellt und ihn überredet in eine Datei zu loggen und direkt noch ein sehr rudimentäres rc.d init script beigelegt: https://github.com/Kernel-Error/postfix-mta-sts-resolver

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.

Fragen? Dann fragen.

Siehe auch: MTA-STS einrichten

Fragen? Einfach melden.

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=- — RSS

Theme von Anders Norén — Hoch ↑