De top 5 onveilige security-protocollen die hardnekkig blijven rondspoken

Security heeft een talent dat niemand bewondert. Dingen die officieel doodverklaard zijn, blijven nog jaren vrolijk rondlopen in productienetwerken. Niet omdat iemand dat een goed idee vindt, maar omdat legacy, compatibiliteit en “het werkt toch?” vaak winnen van gezond verstand. Hieronder vijf protocollen of protocolvarianten die technisch gezien hun pensioen al lang verdiend hebben, maar in de praktijk nog verrassend vaak worden aangetroffen.

1. NTLM (met name NTLMv1 en NTLMv2 zonder aanvullende mitigaties)

NTLM is zo’n protocol dat nooit bedoeld was om de wereld te overleven waarin het nu wordt ingezet. Het authenticatiemodel is kwetsbaar voor relay-aanvallen, pass-the-hash en credential forwarding, zeker wanneer SMB signing ontbreekt of LDAP over TLS niet wordt afgedwongen. Microsoft zelf stuurt al jaren aan op Kerberos en modernere alternatieven, maar NTLM blijft bestaan omdat oude applicaties, printers en “tijdelijke” koppelingen zelden echt worden opgeruimd. NTLMv2 is minder slecht dan v1, maar dat maakt het nog niet goed.

2. TLS 1.0 en TLS 1.1

Hier zit meteen een nuance. TLS als protocol is niet onveilig, maar de oudere versies wel. TLS 1.0 en 1.1 ondersteunen verouderde cipher suites en zijn kwetsbaar voor bekende aanvallen zoals BEAST en POODLE-achtige varianten, afhankelijk van de configuratie. Dat deze versies nog draaien komt meestal door oude middleware, load balancers of appliances die “nog niet zijn geüpdatet”. Het argument is dan compatibiliteit. De realiteit is technische schuld met een encryptielaagje.

3. SSLv2 en SSLv3

SSLv2 is ronduit kapot. SSLv3 is iets minder kapot, maar nog steeds kapot. Toch duiken ze nog op in scans, vaak niet omdat iemand ze bewust gebruikt, maar omdat ze simpelweg nooit expliciet zijn uitgezet. Vooral oudere netwerkapparatuur en vergeten services luisteren soms nog braaf mee. Dit is geen grijs gebied. Als SSLv2 of SSLv3 ergens actief is, is dat een fout. Punt.

4. SMBv1

SMBv1 is vooral bekend geworden door WannaCry, wat eigenlijk al alles had moeten zeggen. Het protocol mist fundamentele beveiligingsmechanismen zoals encryptie en is extreem gevoelig voor misbruik binnen interne netwerken. Toch draait het nog, meestal voor oude fileshares, legacy scanners of industriële systemen waar “niemand meer aan durft te komen”. Dat is begrijpelijk. Het blijft ook gevaarlijk.

5. HTTP zonder TLS (plain HTTP)

Dit voelt bijna te simpel om te noemen, maar plain HTTP komt nog steeds voor. Interne dashboards, managementinterfaces, API’s tussen systemen “achter de firewall”. Het probleem is niet alleen meeluisteren, maar ook manipulatie en credential harvesting. Het idee dat interne netwerken per definitie te vertrouwen zijn, is al jaren achterhaald, maar blijkbaar blijft het aantrekkelijk om dat te negeren.

Waarom deze protocollen blijven bestaan

Het patroon is telkens hetzelfde. Oude afhankelijkheden, gebrek aan eigenaarschap, angst om iets stuk te maken en het gevoel dat security “later wel komt”. In audits en pentests worden deze protocollen steevast gevonden, vaak met de geruststellende opmerking dat het “bekend” is. Bekend zijn met een risico maakt het niet minder reëel.

Wat dit niet garandeert

Het uitschakelen van deze protocollen garandeert geen veilige omgeving. Dat zou een te makkelijke conclusie zijn en die kan ik niet onderbouwen. Security zit in ketens, niet in losse vinkjes. Maar het blijven toestaan van dit soort protocollen vergroot aantoonbaar het aanvalsoppervlak. Dat durf ik wel te zeggen.

Als je wilt, kan ik dit artikel verdiepen per protocol met concrete aanvalsscenario’s, of juist vertalen naar een bestuurdersversie waarin minder techniek en meer risico-impact zit.


Ontdek meer van IT realiteit

Abonneer je om de nieuwste berichten naar je e-mail te laten verzenden.

Posted in , , , , , ,

Ontdek meer van IT realiteit

Abonneer je nu om meer te lezen en toegang te krijgen tot het volledige archief.

Lees verder