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

Schlagwort: Networking (Seite 2 von 12)

DNS over TLS mit BIND, Stunnel und Android 9: Eigener DoT-Server

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.

Über die Techniken DoT (DNS over TLS) habe ich bereits im Zusammenhang mit Bind 9.16 geschrieben. Ebenfalls DoH (DNS over HTTPS) gibt es einen kleinen Beitrag.

Bilder der Bind 9 TLS Konfiguration

Zu diesem Zeitpunkt bracht BIND 9 die Unterstützung für DoH und DoT noch nicht selbst mit. Daher waren zu diesem Zeitpunkt noch Umwege über stunnel oder nginx zusammen mit doh-proxy nötig.

Zum Glück kommt die letzte stable Version 9.18.0 (26. Januar 2022) mit dem nötigen Support.

named now supports securing DNS traffic using Transport Layer Security (TLS). TLS is used by both DNS over TLS (DoT) and DNS over HTTPS (DoH).

Warum möchte man noch gleich DoH oder DoT benutzen? Ganz einfach… Über diese Techniken werden DNS Abfragen verschlüsselt übertragen. Dieses ist ein weiterer Schutz davor manipulierte Antworten zu bekommen und selbstverständlich, damit die eigenen DNS Abfragen erst überhaupt nicht mitgelesen werden. Denn wenn von einem Gerät im Netzwerk die DNS Abfrage zu z.B.: www.tagesschau.de kommt, könnte man davon bereits Dinge ableiten.

Wie die meisten Bind Konfigurationen ist dieses ebenfalls straightforward. Ab Version 9.18 bringt Bind alles Nötige mit. Da wir nun TLS mit dem Bind sprechen möchten, benötigen wir natürlich ein gültiges Zertifikat, wie z.B. beim nginx für seine Webseite.

Ebenfalls sollte man ein paar frische Diffie-Hellmann Parameter generieren:

openssl dhparam -out dhparam.pem 4096

Die eigentliche bind Konfiguration kann in der named.conf.options geschehen:

options {
        [...]
        listen-on port 853 tls local-tls { 37.120.183.220; };
        listen-on-v6 port 853 tls local-tls { 2a03:4000:38:20e::853; };
        listen-on port 443 tls local-tls http default { 37.120.183.220;  };
        listen-on-v6 port 443 tls local-tls http default { 2a03:4000:38:20e::853; };
        [...]
        allow-recursion-on { 127.0.0.0/8; ::1/128; 2a03:4000:38:20e::853; 37.120.183.220; };
        [...]
};

Da der bind auf weiteren Ports lauschen soll erweitert man diese für IPv4 und IPv6. Der Default Port für DoH ist dabei 443 und der default Port für DoT ist 853, beides TCP.

listen-on sowie listen-on-v6 sind wohl selbsterklärend.
port ist der TCP Port und erklärt sich ebenfalls.
tls sagt dem Bind das wir tls sprechen möchten.
local-tls verweißt auf den gleichnamigen tls Block über welchen man seine TLS Konfiguration vornimmt.
http ist für DoH.
default gibt den eigentlichen endpoint für die DoH Abfragen an, im default ist es /dns-query

Da der Server unsere DNS Abfragen erledigen soll, müssen wir ihm dieses noch per allow-recursion-on auf den jeweiligen Adressen erlauben.

Als nächstes wird die eigentliche TLS Terminierung konfiguriert (das lässt sich ebenfalls auslagern, wenn gewünscht). Dafür wird der folgende Block, außerhalb der Options Blocks, ergänzt:

tls local-tls {
    cert-file "/usr/local/etc/ssl/wild.kernel-error.de/2022/ecp/chain.crt";
    key-file "/usr/local/etc/ssl/wild.kernel-error.de/2022/ecp/http.key";
    dhparam-file "/usr/local/etc/ssl/dhparam.pem";
    protocols { TLSv1.2; TLSv1.3; };
    ciphers "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256";
    prefer-server-ciphers yes;
    session-tickets no;
};

local-tls ist dabei der name des Blocks. Auf diesen verweisen wir oben.
cert-file ist der Pfad zum Zertifikat. Ich habe dort nicht nur das Zertifikat, sondern die gesamte Chain, also mit Intermediate und Root.
key-file ist der Pfad zum Key des Zertifikates.
dhparam-file ist der Pfad zu den Diffie-Hellman Parametern.
protocols definiert die zu verwendenden TLS Protokolle. In diesem Beispiel TLS1.2 sowie TLS1.3.
ciphers definiert die zu verwendenden cipher. Es soll ja „sicher“ bleiben.
prefer-server-ciphers übermittelt dem Client die Information, in welcher Reihenfolge protokoll/cipher Kombinationen probiert werden sollen um einen Match zu finden. Erst das vermeintlich sicherste und dann immer „schlechter“.
session-tickets regelt ob eine Wiederaufnahme von TLS Sessions erlaubt ist oder nicht. Da ich forward secrecy nutzen möchte, ist es deaktiviert.

Damit ist die Konfiguration schon abgeschlossen (Firewall ggf. nicht vergessen!). Also testen….

Ein einfaches Tool dafür ist dog, oder natürlich dig aus den bind-tools aber Version 9.18. Für bind gibt es dann die Optionen +https oder auch +tls

dig +https @dns.kernel-error.de www.kernel-error.de A
dig +tls @dns.kernel-error.de www.kernel-error.de A

Der gleiche Test mit dog, sieht wie folgt aus:

dog www.kernel-error.de --tls "@dns.kernel-error.de"
A www.kernel-error.de. 6h00m00s   148.251.40.23
dog www.kernel-error.de --https "@https://dns.kernel-error.de/dns-query"
A www.kernel-error.de. 6h00m00s   148.251.40.23

Das war es auch schon! Viele Spaß mit einem „besseren“ DNS und wenn es noch Fragen gibt, einfach fragen.

FreeBSD IPv6-Probleme bei Netcup beheben

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.

MikroTik CRS305-1G-4S+IN: Der 10-Gbit-Switch für 130 Euro im Langzeittest

Den MikroTik CRS305-1G-4S+IN habe ich Ende 2020 in meinem Arbeitszimmer in Betrieb genommen. Workstation, Storage, Hauptswitch und Windows-PC hängen seitdem an seinen vier SFP+ Ports. Fünf Jahre später läuft das Teil immer noch ohne Ausfall und ich denke es ist Zeit für ein ehrliches Update.

Damals lag der Preis bei knapp über 100 Euro, aktuell zeigt mir Amazon 131,62 Euro an. Klingt nach Inflation, ist für einen managebaren 4-Port 10-Gbit-Switch trotzdem immer noch ein Witz.

Was bekommt man fürs Geld?

An der Hardware hat sich seit dem Erstkauf nichts geändert: Vier SFP+ Ports mit 10 Gbit/s, dazu ein Gigabit-Port für Out-of-Band-Management. Komplett lüfterlos, das Metallgehäuse dient als Kühlkörper. Stromversorgung wahlweise per Steckernetzteil, über den zweiten Netzteil-Anschluss redundant oder per PoE-In über den Management-Port. Wer es ernst meint mit Hochverfügbarkeit, packt drei verschiedene Quellen drauf.

Auf der Unterseite sind Bohrungen für die Wandmontage. Bei mir hängt der Switch seit Jahren an genau dieser Stelle.

RouterOS, jetzt in Version 7

Auf dem Gerät läuft echtes RouterOS, kein abgespecktes SwitchOS-Light. Vor ein paar Jahren bin ich von Version 6 auf 7 umgestiegen, der Sprung lief schmerzfreier als befürchtet. Container-Support, eine neue Routing-Engine, in-kernel WireGuard, ROSE-storage. Für den CRS305 in reiner Switch-Funktion ist das meiste davon Overkill, aber der gleiche Software-Stack läuft auf allen MikroTik-Geräten und das einmal gelernte Wissen ist übertragbar.

Wer den Switch wirklich nur als Switch braucht und das volle Routing-Featureset nicht will, kann alternativ SwOS einspielen. Ich bleibe bei RouterOS, weil ich VLANs, VRRP und gelegentlich mal eine kleine Bridge mit eigenen Regeln nutze.

Härtung: das was 2021 noch keiner gesagt hat

In den letzten Jahren ist MikroTik mehrfach unangenehm aufgefallen. Botnetze auf nicht aktualisierten RouterOS-Geräten (Mēris, TrickBot, VPNFilter), mehrere Webfig-Authentifizierungs-Bypässe, dazu der Klassiker: Default-User „admin“ ohne Passwort. Wer so ein Gerät ohne Härtung ans Internet hängt oder auch nur ohne Trennung ins LAN, hat sich selbst beschenkt.

Mein Standardvorgehen direkt nach dem Auspacken sieht ungefähr so aus:

/user add name=adminneu group=full password=...
/user remove admin
/ip service disable telnet,ftp,www,api,api-ssl
/ip service set winbox address=192.168.X.0/24
/ip service set ssh address=192.168.X.0/24
/system clock set time-zone-name=Europe/Berlin
/system ntp client set enabled=yes servers=pool.ntp.org
/system package update check-for-updates
/system routerboard upgrade

Webfig und API mögen bequem sein, ich brauche beides nicht. Telnet und FTP haben auf einem Gerät von 2026 nichts mehr verloren. Wer trotzdem das Webinterface nutzen will, sollte zumindest auf HTTPS umstellen und die Zugriffe auf das Management-Subnetz beschränken.

Auto-Update gibt es bei MikroTik leider noch immer nicht out-of-the-box. Ich habe mir einen kleinen Cron-Job gebaut, der einmal im Monat anpingt ob ein Update da ist. Manuell einspielen muss ich es dann selbst, weil mir bei einem zentralen Netzwerkgerät ein automatisches Reboot mitten in der Nacht zu heikel ist.

SFP+ Module und DAC-Kabel

MikroTik ist da angenehm tolerant: vendor-locked Module von Cisco, Juniper oder HPE fliegen in der Regel ohne Murren rein. In meinen vier Ports stecken aktuell zwei FS.com-Module mit LWL, ein generisches Kupfer-DAC zur Workstation und ein 10GBASE-T-Adapter ans Storage. Alles funktioniert, kein Kabel oder Modul zickt.

Vorsicht bei 10GBASE-T-Adaptern: die werden warm. Sehr warm. Bei zwei oder mehr Stück im engen Gehäuse kann der Switch im Sommer am thermischen Limit kratzen. Wer kann, sollte LWL oder DAC bevorzugen, das ist effizienter und kühler. DACs sparen außerdem die Modul-Kosten und bringen Latenzen, die mit aktiven Modulen schlicht nicht zu erreichen sind.

Stromverbrauch

Bei mir liegt der Verbrauch im Mittel zwischen 8 und 12 Watt, je nach Bestückung. Mit zwei 10GBASE-T-Adaptern kann es Richtung 14 bis 16 Watt gehen. Für einen 24/7 laufenden Switch ist das vertretbar, in Zeiten von Stromrechnungen die jedes Jahr neue Höchststände erreichen sollte man es zumindest wissen.

Markt 2026: Alternativen

2021 war der CRS305 in seiner Preisklasse fast konkurrenzlos. 2026 sieht das anders aus. Ein paar Optionen, die ich heute mit auf die Liste setzen würde:

  • MikroTik CRS309-1G-8S+IN: Doppelte Portzahl, gleicher Aufbau, etwa 250 bis 300 Euro. Wenn vier Ports knapp werden, der logische Schritt nach oben.
  • MikroTik CRS310-1G-5S-4S+IN: Mischmasch aus 1G/2.5G und 4× SFP+, brauchbar wenn das eigene Netz nicht komplett auf 10G migriert ist.
  • TP-Link TL-SX3008F: 8× SFP+ JetStream-Smart-Switch, kein RouterOS aber gepflegtes Webinterface, etwa 250 Euro. Für reines Switchen oft entspannter als RouterOS.
  • QNAP QSW-M408S: 4× SFP+ plus 4× 1G, simples Web-UI, knapp 280 Euro. Gut für Leute, die kein RouterOS lernen wollen.
  • Ubiquiti USW-Aggregation: 8× SFP+ mit Web-Controller, etwa 280 Euro. Wer schon im UniFi-Ökosystem unterwegs ist, will sowieso nichts anderes.

Für den absoluten Einstieg in 10G zuhause, mit kleinem Budget und der Bereitschaft sich kurz mit RouterOS zu beschäftigen, ist der CRS305 weiterhin der beste Deal. Wer mehr Ports braucht oder das Routing-Featureset gar nicht erst anfassen will, sollte einen der oben genannten in die engere Wahl nehmen.

Fazit nach 5 Jahren

Das Gerät ist seit 2021 ohne einen einzigen Ausfall durchgelaufen, hat zwei Wohnungswechsel und mehrere RouterOS-Major-Updates überlebt. Bei aktuell 131,62 Euro auf Amazon oder direkt von MikroTik bleibt es eine klare Empfehlung. Mit der Einschränkung, dass man die paar Minuten in Härtung investieren sollte, sonst wird aus dem schönen kleinen Switch schnell ein Botnet-Knoten.

Ich mache ja eher selten Werbung für ein Produkt, aber dieser Switch hat sich nach fünf Jahren als die beste Empfehlung herausgestellt, die ich in dieser Preisklasse jemals geben konnte.

Siehe auch: IPv6 Prefix Delegation: FritzBox und MikroTik und Ist mein Netzwerk kompromittiert? Warum das kaum jemand merkt.

Fragen? Einfach melden.

Windows Server RRAS: L2TP/IPsec-VPN mit sicheren Cipher Suites

Windows Server RRAS mit L2TP/IPsec-VPN-Tunnel, Firewall-Konfiguration, AES-256, DH Group 20, UDP 500/4500 und Registry-Hardening.

Wenn ich schon bei Microsoft-Themen bin: Warum nicht gleich noch RRAS (Routing und RAS) mit einem L2TP/IPsec-VPN absichern? Im Standard verbinden sich die Clients nämlich mit SHA-1, 3DES und DH Group 2 (modp1024, also 1024 Bit). SHA-1 ist grenzwertig, 3DES muss nicht sein und modp1024 will man definitiv nicht mehr.

Hinweis: Ursprünglich für Windows Server 2012 R2 geschrieben (inzwischen End of Life). Die Konfiguration über die Windows-Firewall funktioniert auf neueren Versionen identisch.

Wo man die Einstellung findet (Spoiler: nicht bei RRAS)

Ich habe einige Zeit gesucht. Man würde erwarten, dass die IPsec-Cipher irgendwo in der Nähe von Routing und RAS konfiguriert werden. Falsch gedacht. Die Einstellung steckt in der Windows-Firewall mit erweiterter Sicherheit. Irgendeinen Grund wird es haben, das dort zu verstecken. Ich hätte dort nie gesucht.

Der Klickpfad: Windows Firewall → Rechtsklick auf „Windows-Firewall mit erweiterter Sicherheit“ → Eigenschaften → IPsec-Einstellungen → IPsec-Standardeinstellungen → „Anpassen“ → Schlüsselaustausch.

Screenshot der Windows-Firewall mit erweiterter Sicherheit und angezeichnetem Klickpfad um die Sicherheitsmethoden zu konfigurieren.

Hier kann man die Sicherheitsmethoden und Datenschutzeinstellungen anpassen. Windows Firewall als Ort für VPN-Cipher-Konfiguration. Kopfschütteln.

Screenshot der Windows-Firewall mit erweiterter Sicherheit und angezeichnetem Klickpfad um die Datenschutzeinstellungen zu konfigurieren.

UDP Encapsulation hinter NAT

Steht der RRAS hinter einem NAT, muss man noch UDP Encapsulation per Registry aktivieren. Dafür habe ich ein Registry-File:

Registry-File für IPsec UDP Encapsulation

Nach allen Änderungen den Server neu starten. Microsoft halt.

Prüfen ob es geklappt hat

Auf einem Windows-Client per PowerShell (mit erweiterten Rechten) prüfen, welche Cipher die VPN-Verbindung tatsächlich nutzt:

Get-NetIPsecMainModeSA | Select-Object -First 1
Screenshot des Kommandos Get-NetIPsecMainModeSA inkl Konsolenausgabe.

Relevant sind CipherAlgorithm, HashAlgorithm und GroupId. Im Standard steht da 3DES, SHA-1 und DH Group 2 (1024 Bit). Nach den Änderungen:

Encryption:                AES256
Authentication/Integrity:  SHA-1
Key Size:                  DH Group 20 (384-bit ECC)

Immer noch SHA-1 für die Integrity, aber AES-256 und ECC sind ein großer Sprung. Über Gruppenrichtlinien ließe sich das Ganze auch zentral ausrollen, aber das ist nochmal ein eigenes Thema. Vor allem die Reihenfolge korrekt vorzugeben ist dort unerwartet fummelig.

Wer auch die TLS-Cipher für Exchange/OWA härten will: SSL Labs A+ mit Exchange. Fragen? Einfach melden.

TLS-ECDHE mit AES-256-GCM-SHA384 einfach erklärt

Verschlüsselung-cipher

Wer sich mit TLS beschäftigt, stolpert früher oder später über Zeichenketten wie TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 oder TLS_AES_256_GCM_SHA384. Was da genau drinsteht, ist auf den ersten Blick nicht offensichtlich. Dabei folgt die Benennung einem klaren Schema.

Die Bestandteile einer Cipher Suite

Jede Cipher Suite beschreibt vier Dinge:

  • Key Exchange — wie sich Client und Server auf einen gemeinsamen Sitzungsschlüssel einigen.
  • Certificate Verification — wie das Serverzertifikat geprüft wird (Signaturverfahren).
  • Bulk Encryption — die symmetrische Verschlüsselung der eigentlichen Daten.
  • Hashing — die Prüfsummen, die Integrität und Authentizität sicherstellen.

TLS 1.2 vs. TLS 1.3

In TLS 1.2 stehen alle vier Bestandteile im Namen der Cipher Suite. Nehmen wir TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 auseinander:

  • TLS — das Protokoll (Transport Layer Security)
  • ECDHE — Key Exchange (Elliptic Curve Diffie-Hellman Ephemeral)
  • ECDSA — Certificate Verification (Elliptic Curve Digital Signature Algorithm)
  • AES_256_GCM — Bulk Encryption (AES mit 256 Bit im Galois/Counter Mode)
  • SHA384 — Hashing (SHA-2 mit 384 Bit)

TLS 1.3 hat das Namensschema verkürzt. Key Exchange und Certificate Verification sind nicht mehr Teil des Cipher-Suite-Namens, weil sie separat verhandelt werden. Darum sieht TLS_AES_256_GCM_SHA384 so kompakt aus: nur Protokoll, Verschlüsselung und Hash.

Key Exchange

Der Schlüsselaustausch legt fest, wie Client und Server einen temporären Sitzungsschlüssel aushandeln. Man will hier Ephemeral-Verfahren, also temporäre Schlüssel. Warum? Selbst wenn jemand den Traffic mitschneidet und später an den privaten Schlüssel des Servers kommt, kann er die aufgezeichneten Verbindungen nicht entschlüsseln. Der Sitzungsschlüssel existiert nur für die Dauer der Verbindung. Das nennt sich Perfect Forward Secrecy.

DHE (Diffie-Hellman Ephemeral) funktioniert, sollte aber mindestens 2048 Bit nutzen. Besser ist ECDHE (Elliptic Curve DHE), weil es bei gleicher Sicherheit deutlich kleiner und schneller ist. Idealerweise bietet der Server nur ECDHE an. Alles ohne das E am Ende (also statisches DH) hat kein Forward Secrecy und gehört abgeschaltet.

In Zukunft kommt hier noch Post-Quantum dazu. Mit X25519MLKEM768 lassen sich hybride Verfahren nutzen, die auch gegen Quantencomputer absichern. Wer das auf Nginx einrichten will, findet bei mir eine Anleitung: Post-Quantum TLS.

Certificate Verification

Verschlüsselung allein hilft nicht, wenn man mit dem falschen Server spricht. Das Serverzertifikat beweist die Identität. Es wird von einer CA signiert, kann per DANE/TLSA im DNSSEC-geschützten DNS verankert sein und sollte nicht trivial fälschbar sein.

RSA-Zertifikate sollten mindestens 2048 Bit haben, besser 4096 Bit. Allerdings werden RSA-Schlüssel mit steigender Sicherheit immer größer und langsamer. ECDSA-Zertifikate lösen das elegant: Ein ECDSA-Schlüssel mit 256 Bit bietet vergleichbare Sicherheit wie RSA mit 3072 Bit, ist aber deutlich kleiner und schneller zu verifizieren. Als Kurve sollte es mindestens secp256r1 (P-256) sein. secp384r1 geht auch, bringt aber aktuell keinen praktischen Vorteil.

Bulk Encryption

Das ist die eigentliche Datenverschlüsselung. Brauchbare Kombinationen sind:

  • AES-128-GCM oder AES-256-GCM — Standard, schnell, hardware-beschleunigt auf den meisten CPUs
  • ChaCha20-Poly1305 — gute Alternative, besonders auf Geräten ohne AES-NI

AES mit CBC ist noch akzeptabel, aber GCM ist vorzuziehen. Von 3DES sollte man die Finger lassen. Wenn irgendwo RC4 oder DES auftaucht: abschalten.

Hashing

Der Hash sichert die Integrität der übertragenen Daten. Minimum ist SHA-256, ein guter Mittelweg ist SHA-384. SHA-1 sollte man nicht mehr einsetzen. Taucht MD5 auf, stimmt etwas grundlegend nicht.

Update Juli 2026: Wie dieselbe Zerlegung in der Post-Quantum-Welt aussieht, habe ich für X25519MLKEM768 in einem eigenen Beitrag durchgespielt: X25519MLKEM768 zerlegt.

Fragen, Korrekturen oder Ergänzungen? Einfach melden.

We have now run out of IPv4 addresses.

Wenn ich dann mal „zitieren“ darf..

Dear colleagues,

Today, at 15:35 UTC+1 on 25 November 2019, we made our final /22 IPv4 allocation from the last remaining addresses in our available pool. We have now run out of IPv4 addresses.

Our announcement will not come as a surprise for network operators - IPv4 run-out has long been anticipated and planned for by the RIPE community. In fact, it is due to the community's responsible stewardship of these resources that we have been able to provide many thousands of new networks in our service region with /22 allocations after we reached our last /8 in 2012.

----------------------------------------------------------------
Recovered IPv4 Addresses and the Waiting List
----------------------------------------------------------------

Even though we have run out, we will continue to recover IPv4 addresses in the future. These will come from organisations that have gone out of business or whose LIR accounts are closed, or from networks that return addresses they no longer need. They will be allocated to our members according to their position on a new waiting list that is now active.

While we therefore expect to be allocating IPv4 for some time, these small amounts will not come close to the many millions of addresses that networks in our region need today. Only LIRs that have never received an IPv4 allocation from the RIPE NCC (of any size) may request addresses from the waiting list, and they are only eligible to receive a single /24 allocation.

LIRs that have submitted an IPv4 request can see their position on the waiting list in the LIR Portal. A new graph has also been published that shows the number of requests on the waiting list and the number of days that the LIR at the front of the queue has been waiting:
https://www.ripe.net/manage-ips-and-asns/ipv4/ipv4-waiting-list

----------------------------------------------------------------
Call for Greater Progress on IPv6
----------------------------------------------------------------

This event is another step on the path towards global exhaustion of the remaining IPv4 addressing space. In recent years, we have seen the emergence of an IPv4 transfer market and greater use of Carrier Grade Network Address Translation (CGNAT) in our region. There are costs and trade-offs with both approaches and neither one solves the underlying problem, which is that there are not enough IPv4 addresses for everyone.

Without wide-scale IPv6 deployment, we risk heading into a future where the growth of our Internet is unnecessarily limited - not by a lack of skilled network engineers, technical equipment or investment, but by a shortage of unique network identifiers. There is still a long way to go, and we call on all stakeholders to play their role in supporting the IPv6 roll-out.

At the RIPE NCC, we are here to support our membership and the wider RIPE community in this work. Aside from allocating the IPv6 resources that will be required, we will continue to provide advice, training, measurements and tools to help network operators as they put their deployment plans into action.

We are optimistic and excited to see what the next chapter will bring. So let's get to work - and together, let's shape the future of the Internet.

Best regards,

Everyone at the RIPE NCC

Japp… RIPE NCC ist damit leer!

Siehe auch: IPv6 Grundlagen

Fragen? Einfach melden.

DoH (DNS over HTTPS) mit BIND auf eigenem Server

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.

Meine Tests mit DoT (DNS over TLS) habe ich bereits vor einiger Zeit gestartet.  DoT DNS over TLS mit Bind, stunnel und Android 9 Dieses arbeitet noch immer ganz fein auf meinem Smartphone. DoT gefällt mir noch immer um einiges besser als DoH aber auch hier wollte ich nun einmal einen Versuch starten. Zusammen mit nginx und einem etwas angepassten doh-proxy läuft dieses nun auf dem gleichen System.

Im Firefox ist es schnell aktiviert https://ns1.kernel-error.de/dns-query…

DoH DNS over HTTPS Firefox

Es funktioniert auch, so richtig glücklich macht es mich aber nicht! Natürlich ist die Umsetzung nur etwas für einen kleinen privaten Test. „Schnell“ genug ist es ebenfalls! Zumindest zum Surfen im Internet, dennoch wäre mir eine saubere Implementierung von DoT im resolver vom OS viel lieber. So wie bereits ab Android 9 zu sehen. Vielleicht ändert sich mein Gefühl ja etwas zusammen mit QUIC (HTTP/3)?!?

Siehe auch: DoT mit Stunnel und BIND9

Fragen? Einfach melden.

Dell Latitude E6540 mit Intel Wireless-AC 9260

Mein privates Notebook ist noch immer ein Dell Latitude E6540. Die ab Werk verbaute Intel Centrino Ultimate-N 6300 macht zwar noch immer ihren Job, inzwischen stört mich immer öfter ihr Durchsatz. Maximal soll sie 450 Mbps bringen, dieses schafft sie natürlich nur unter guten Bedingungen. Früher ist mir dieses nicht besonders aufgefallen, durch bessere WLAN APs und schnelleres Internet bremst mich inzwischen meine verbaute WLAN Karte beim Download :-/ das ist doof!

Also einfach neue Karte kaufen, ins Notebook stecken und los gehts.. Naja, fast! Im Latitude können drei PCIe Half MiniCard verbaut werden. Aktuelle WLAN Karten für Notebooks nutzen inzwischen aber M.2 als Schnittstelle zum Notebook. Ebenfalls sind die Anschlüsse der Antennen „kleiner“ geworden. Intel bietet für ihre Produkte auf ihrer Webseite die Option an ihre Produkte miteinander zu vergleichen. >klick<

Um M.2 komme ich nicht herum, wenn ich es mit einem möglichst einfachen Adapter anschließen möchte muss ich darauf achten, dass die neue Karte PCIe spricht. Die Intel Wireless-AC 9260 kann dieses und bietet dazu noch 1,73Gbps. Dazu noch ein Adapter und zwei Antennenadapter. Alles bekommt man schnell für einen kleinen Euro auf Amazon.

Intel Wireless-AC 9260
Adapter
Antennenadapter

Alles zusammen sitzt nun in meinem Notebook und das Internet „fliegt“ wieder.

Siehe auch: Lifebook E7110 unter Linux

Fragen? Einfach melden.

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

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 als IPsec/L2TP-Client für Microsoft Windows Routing und RAS VPN

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.

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑