OpenSSH-lek maakt man-in-the-middle-aanval op OpenSSH-client mogelijk
Een kwetsbaarheid in OpenSSH maakt het mogelijk om een man-in-the-middle (mitm)-aanval op OpenSSH-clients uit te voeren. Er is een nieuwe versie uitgebracht om de kwetsbaarheid te verhelpen. Ook een beveiligingslek dat tot een denial of service kan leiden is opgelost. OpenSSH, ook bekend als OpenBSD Secure Shell, is een verzameling van netwerktools gebaseerd op het SSH-protocol, en laat gebruikers op een beveiligde manier op bijvoorbeeld servers inloggen of op afstand machines beheren.
De mitm-kwetsbaarheid, aangeduid als CVE-2025-26465, doet zich alleen voor als de VerifyHostKeyDNS-optie staat ingeschakeld, wat standaard niet het geval is. Via de optie kan worden aangegeven of de key van de host wordt geverifieerd aan de hand van DNS- en SSHFP-records. Wanneer een kwetsbare client verbinding maakt met een server, kan een actieve man-in-the-middle-aanvaller de controle van de identiteit van de server omzeilen en zich zo als de server voordoen. Het probleem is al sinds december 2014 in OpenSSH aanwezig. De optie stond van september 2013 tot en met maart 2023 bij FreeBSD wel standaard ingeschakeld.
Een andere kwetsbaarheid (CVE-2025-26466) maakt het daarnaast mogelijk om een denial of service-aanval op servers uit te voeren. Dit probleem bevindt zich augustus 2023 in de code. Beide kwetsbaarheden werden gevonden door onderzoekers van securitybedrijf Qualys. Beheerders worden opgeroepen om te updaten naar OpenSSH 9.9p2.
Niet onbelangrijk is dan een tutorial voor huidig gebruik.
I.p.v. SSHFP kun je -naar verluid- beter het TLSA record gebruiken i.c.m. DNSSEC.
Of beter, beiden bijten elkaar niet...
3 staat voor DANE-EE, end-entity match.
Match Host *.example.tld
CheckHostIP no
ProxyCommand dane ssh %h %p
En nee, lees dit niet alsof dit een workaround voor deze CVE zou zijn - eerder juist de problematische usecase (waarvoor vast wel een oplossing komt op korte termijn).
Maar, ik hoor graag commentaar/kritiek/suggesties.
(maar andersom: als je geen serieuse fingerprint-verificatie doet uit luiheid, wees dan s.v.p. evenzo lui met reageren)
~ LV
Ongeacht alle focus op security en supersterke protocollen met private keys, exploits zijn niet onmogelijk.
Ik neem aan dat er geen manier is om SSH aan te bieden op een dichte poort? :-)
(Er even van uit gaande dat een server met alle poorten dicht 100% veilig is.)
Ongeacht alle focus op security en supersterke protocollen met private keys, exploits zijn niet onmogelijk.
Ik neem aan dat er geen manier is om SSH aan te bieden op een dichte poort? :-)
(Er even van uit gaande dat een server met alle poorten dicht 100% veilig is.)
zie:
https://en.wikipedia.org/wiki/Port_knocking
Zoekt en vindt middels "knockd ssh pf" - of uw firewall naar keuze
Zoals https://medium.com/@reotmani/port-knocking-dbe6d8aaeb9
Ik heb in het verleden althans een aantal jaar met fwknop gewerkt: port knocking met versleuteling en bescherming tegen replay-attacks. De poort blijft voor verder alle andere IP-adressen gesloten.
https://www.cipherdyne.org/fwknop/
Niet onbelangrijk is dan een tutorial voor huidig gebruik.
I.p.v. SSHFP kun je -naar verluid- beter het TLSA record gebruiken i.c.m. DNSSEC.
Of beter, beiden bijten elkaar niet...
3 staat voor DANE-EE, end-entity match.
Match Host *.example.tld
CheckHostIP no
ProxyCommand dane ssh %h %p
En nee, lees dit niet alsof dit een workaround voor deze CVE zou zijn - eerder juist de problematische usecase (waarvoor vast wel een oplossing komt op korte termijn).
Maar, ik hoor graag commentaar/kritiek/suggesties.
(maar andersom: als je geen serieuse fingerprint-verificatie doet uit luiheid, wees dan s.v.p. evenzo lui met reageren)
~ LV
Ter aanvulling :
https://en.wikipedia.org/wiki/SSHFP_record
https://datatracker.ietf.org/doc/html/rfc4255
TLSA : https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities#TLSA_RR
"10.000x beter" wil nog niet zeggen dat iets 100% veilig is.
Als je daadwerkelijk alle risico moet vermijden, dan is het toch volledig logisch om poort 22 te firewallen?
(Met een IP whitelist, of anders misschien met de daarboven genoemde "port knocking")
"10.000x beter" wil nog niet zeggen dat iets 100% veilig is.
Als je daadwerkelijk alle risico moet vermijden, dan is het toch volledig logisch om poort 22 te firewallen?
(Met een IP whitelist, of anders misschien met de daarboven genoemde "port knocking")
...terwijl we net zo makkelijk complementair en complimentair zouden kunnen zijn!
Globaal zou ik roepen dat èn [1] knockd, op [2] een wireguard (geen openvpn!) interface, met daarop [3] een goed geconfigureerde ssh server, en met [4] sshguard (geen fail2ban!)...
toch al snel wel zo'n 4x beter is.
https://hubandspoke.amastelek.com/protect-your-linux-system-with-sshguard-a-better-alternative-to-fail2ban
...terwijl we net zo makkelijk complementair en complimentair zouden kunnen zijn!
Globaal zou ik roepen dat èn [1] knockd, op [2] een wireguard (geen openvpn!) interface, met daarop [3] een goed geconfigureerde ssh server, en met [4] sshguard (geen fail2ban!)...
toch al snel wel zo'n 4x beter is.
https://hubandspoke.amastelek.com/protect-your-linux-system-with-sshguard-a-better-alternative-to-fail2ban
https://linuxiac.com/how-to-secure-ssh-server-with-sshguard/#SSHGuard_vs_FailBan:_Key_Differences
...terwijl we net zo makkelijk complementair en complimentair zouden kunnen zijn!
Globaal zou ik roepen dat èn [1] knockd, op [2] een wireguard (geen openvpn!) interface, met daarop [3] een goed geconfigureerde ssh server, en met [4] sshguard (geen fail2ban!)...
toch al snel wel zo'n 4x beter is.
https://hubandspoke.amastelek.com/protect-your-linux-system-with-sshguard-a-better-alternative-to-fail2ban
Je bent niet ingelogd en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.
Security Adviseur
bij HHNK
Heb jij een passie voor informatiebeveiliging en wil je jouw expertise inzetten in een organisatie met impact? solliciteer nu! Bij HHNK hechten we veel waarde aan de veiligheid van onze informatie en systemen. Met een breed scala aan informatie-technologie (IT) en operationele technologie (OT) binnen onze taken, is het essentieel om deze veilig te houden.
Security Specialist
Directie Informatievoorziening & Inkoop
Als security specialist is je primaire taak het detecteren en het afhandelen van (mogelijke) security incidenten. Hiervoor vergaar je dreigingsinformatie en richt je op basis van risico's detectieregels in, opdat aanvallers in een zo vroeg mogelijk stadium geïdentifi-ceerd kunnen worden. Wanneer een dreiging wordt gedetecteerd, zorg jij ervoor dat de juiste acties worden uitgezet.
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?