SSH beveiligen tegen aanvallen

Gepubliceerd: februari 2026. Bijgewerkt: augustus 2026. Beoordeeld door het SSH-beveiligings- en sleutelbeheerteam van Encryption Consulting.

Secure Shell (SSH) beveiligt de meeste externe beheer-, automatiserings- en machine-naar-machine-verbindingen in bedrijfs-IT. Het protocol zelf, dat tegenwoordig is gestandaardiseerd op SSH-2, heeft zich cryptografisch goed bewezen. Aanvallers kraken de cryptografie van SSH niet; ze richten zich op een handvol voorspelbare zwakke punten: servers waarop wachtwoordverificatie nog steeds is ingeschakeld, niet-gepatchte OpenSSH-binaries, onbeperkte beheerdersrechten en hergebruikte of onbeheerde sleutels. Deze handleiding richt zich specifiek op proactieve beveiliging , de concrete server-, toegangs- en netwerkcontroles die SSH-aanvallen stoppen voordat ze slagen. Voor de onderliggende protocolzwakheden en de CVE-geschiedenis achter deze aanvallen, zie ons bijbehorende artikel over SSH-kwetsbaarheden . Voor informatie over het beheren van SSH-sleutels gedurende hun volledige levenscyclus, van ontdekking en eigendom tot rotatie en audit, zie onze handleiding voor het beheer van de levenscyclus van SSH-sleutels.

Welke SSH-aanvalstechnieken zijn gericht op bedrijfsservers?

SSH-servers in bedrijven worden aangevallen via vier dominante technieken: brute-force wachtwoordkraken, credential stuffing, man-in-the-middle-aanvallen en het misbruiken van niet-gepatchte CVE's, naast operationele fouten zoals gestolen sleutels en het invoegen van backdoor-sleutels die helemaal geen protocolbreuk vereisen.

• Brute-force wachtwoord raden: Geautomatiseerde scripts proberen duizenden combinaties van gebruikersnamen en wachtwoorden uit op SSH-servers die via poort 22 met het internet verbonden zijn. Elke server waarop wachtwoordverificatie is ingeschakeld, is een doelwit zodra een poortscanner deze detecteert.
• Diploma vulling: Aanvallers gebruiken gebruikersnaam- en wachtwoordcombinaties die zijn gelekt bij andere datalekken, in de hoop dat wachtwoorden hergebruikt worden. Omdat SSH standaard geen snelheidslimiet hanteert, kan één enkele blootgestelde server duizenden pogingen tot wachtwoordaanvallen per uur verwerken zonder dat er een waarschuwing wordt afgegeven.
• Man-in-the-middle (MITM) interceptie: Een aanvaller die zich op het netwerkpad bevindt, presenteert een vervalste host-sleutel om een ​​sessie te onderscheppen of te downgraden. SSH-clients die waarschuwingen over host-sleutels negeren, of servers waarop strikte controle op host-sleutels is uitgeschakeld, maken dit mogelijk.
• Bekende CVE-exploits: Ongepatchte OpenSSH-binaries blijven kwetsbaar, zelfs lang nadat een oplossing is uitgebracht. CVE-2024-6387 (“regreSSHion”), een raceconditie in de signaalafhandeling van de OpenSSH-server (sshd) die versies 8.5p1 tot en met 9.8p1 ​​treft, heeft een CVSS-score van 8.1 en stelt een niet-geauthenticeerde externe aanvaller in staat om onveilige signaalafhandeling te activeren op glibc-gebaseerde Linux-systemen (NVD, CVE-2024-6387). OpenSSH heeft een oplossing uitgebracht in versie 9.8p1; servers die nog steeds een getroffen versie draaien, blijven kwetsbaar, ongeacht hoe goed de rest is geconfigureerd.
• Gestolen of gelekte privésleutels: Een privésleutel die is gekopieerd van een gecompromitteerd eindpunt, een blootgestelde back-up of een openbare codeopslagplaats, verleent onmiddellijke, geauthenticeerde toegang. Omdat SSH een geldige sleutel als identiteitsbewijs beschouwt, genereert die login geen waarschuwing voor mislukte authenticatie. Het incident bij CircleCI in januari 2023, waarbij een aanvaller malware en een gestolen sessiecookie op de laptop van een engineer gebruikte om toegang te krijgen tot productiesystemen, leidde ertoe dat het bedrijf elke klant adviseerde om uit voorzorg SSH-sleutels, tokens en andere opgeslagen geheimen te roteren (CircleCI, 2023).
• Sleutel in de achterdeur steken: Met beperkte toegang tot het bestandssysteem voegt een aanvaller zijn eigen publieke sleutel toe aan de account van een gebruiker. ~/.ssh/geautoriseerde_sleutels bestand. Geen malware, geen binaire wijzigingen, slechts één extra vertrouwde regel die de meeste organisaties nooit controleren.

Elk van deze technieken maakt gebruik van een kwetsbaarheid die door beveiliging direct wordt gedicht. De rest van deze handleiding beschrijft de specifieke beveiligingsmaatregelen, per eigenaar, per toegangslaag en per rotatietrigger, die elk pad afsluiten. Voor een diepere technische analyse van de zwakke punten op protocolniveau van SSH en historische CVE's, lees SSH-kwetsbaarheden en hoe u zich daartegen kunt beschermen.

Wie is verantwoordelijk voor de SSH-beveiliging binnen de onderneming?

De beveiligingsmaatregelen voor SSH zijn doorgaans verdeeld over drie verantwoordelijkheden: het beveiligingsteam stelt de basisregels voor het beleid vast, de infrastructuur- en platformteams handhaven deze in sshd_config en bij het inrichten van hosts, en de DevOps- of automatiseringsteams zijn verantwoordelijk voor de sleutels die hun pipelines genereren. Zonder een benoemde verantwoordelijke voor elke laag, loopt de beveiliging spaak zodra een nieuwe server wordt ingericht die afwijkt van de standaardimage.

• Beveiligingsteam: Definieert de cipher, MAC en algoritmebasislijn; stelt het beleid voor root-aanmelding en wachtwoordverificatie in; stelt de MFA-vereiste voor beheerderstoegang in.
• Infrastructuur- en platformteam: Past die basislijn toe en onderhoudt deze via configuratiebeheer of golden images, en houdt de OpenSSH-patchniveaus in de gehele vloot bij.
• DevOps- en applicatieteams: Ze beheren de automatiserings- en serviceaccount-sleutels die hun pipelines genereren, vragen toegang aan via een goedkeuringsworkflow en zijn verantwoordelijk voor het rouleren van wat ze creëren.

Dit weerspiegelt het eigendomsmodel dat gedetailleerd wordt beschreven in onze uitgebreide handleiding voor het beheer van de levenscyclus van SSH-sleutels , die het hele proces van sleutelontdekking, -voorziening en -governance behandelt. Deze sectie richt zich specifiek op de eigendomsvraag die van belang is voor het versterken van de beveiliging tegen aanvallen: wie mag de beveiligingsbasislijn wijzigen en wie is verantwoordelijk wanneer een host hiervan afwijkt? Configuratieafwijkingen, zoals een enkele niet-gepatchte of verkeerd geconfigureerde node, zijn een van de meest voorkomende manieren waarop een beveiligde vloot ongemerkt weer kwetsbaar wordt voor aanvallen. Wijs één team het eigendom van de basisconfiguratie van sshd_config toe en handhaaf dit via configuratiebeheer, in plaats van elke beheerder te vragen deze te onthouden.

Hoe beveiligt u het SSH-toegangsbeleid?

Het versterken van het toegangsbeleid houdt in dat authenticatie uitsluitend met sleutels wordt afgedwongen, directe root-aanmelding wordt uitgeschakeld en elke beheerderssessie via een bastionhost wordt geleid, zodat een gestolen wachtwoord of een enkel gecompromitteerd eindpunt geen directe toegang meer tot een server kan krijgen.

• Wachtwoordverificatie uitschakelen (Wachtwoord Verificatie nr): elimineert brute-force- en credential-stuffing-aanvallen volledig door het type inloggegevens te elimineren waarop deze aanvallen gericht zijn.
• Root-aanmelding uitschakelen (PermitRootLogin nrDit dwingt aanvallers en beheerders om zich te authenticeren met een specifiek account en via sudo toegang te verkrijgen, waardoor de identificatie behouden blijft en een extra stap wordt toegevoegd voordat volledige systeemcontrole mogelijk is.
• MFA is vereist voor interactieve sessies. met behulp van OpenSSH's Authenticatiemethoden richtlijn (bijv. publickey,keyboard-interactiveEen gestolen privésleutel alleen is dus niet voldoende voor shelltoegang.
• Beperk het aantal authenticatiepogingen: reeks MaxAuthTries naar een lage waarde en een korte InloggenGraceTimeEn voeg daar een tool zoals fail2ban of sshguard aan toe om automatisch bron-IP-adressen te blokkeren na herhaalde mislukkingen. De Network Infrastructure Security Guide van de NSA beveelt aan om het aantal authenticatiepogingen te beperken en een inlogvertraging in te voeren, met name om brute-force-aanvallen te dwarsbomen (NSA, 2022).
• Algoritmen beperken: Schakel SSH-1, verouderde versleutelingsmethoden (3DES, Blowfish, CBC-modus) en zwakke MAC's (SHA-1) uit, en verwijder Diffie-Hellman-moduli kleiner dan 2048 bits. /etc/ssh/moduli om het risico op declassificatie en onderschepping te verminderen.
• Onnodige doorsturing uitschakelen: Schakel agent, X11 en poortforwarding standaard uit. Een gecompromitteerde host met ingeschakelde agentforwarding stelt een aanvaller in staat om zich elders te authenticeren zonder ooit de privésleutel aan te raken.
• Leid administratieve toegang via een bastion (jump) host: één enkel, goed bewaakt toegangspunt dat MFA afdwingt, sessies registreert en consistente controles toepast, waardoor productiesystemen geïsoleerd blijven van directe blootstelling.
• Segmentnetwerken en zonetoegang: Productiesystemen mogen geen directe toegang op basis van sleutels accepteren vanaf ontwikkel- of testomgevingen. Het isoleren van vertrouwensgrenzen beperkt de mogelijkheden van een aanvaller nadat één host is gecompromitteerd.

Wanneer moet je je SSH-sleutels en -inloggegevens vernieuwen na een aanval?

SSH-sleutels en hostreferenties moeten worden geroteerd op basis van vooraf gedefinieerde triggers, niet alleen volgens een vast schema: bevestigde of vermoedde inbreuk, uitdiensttreding, een nieuw openbaar gemaakt CVE dat van invloed is op de gebruikte SSH-versie, blootstelling in een repository of back-up, en het einde van een gedefinieerde cryptoperiode voor langlevende automatiseringssleutels.

1. Bevestigde of vermoede inbreuk op de belangrijkste sleutels: De sleutel moet onmiddellijk worden geroteerd en ingetrokken op elke host die de betreffende sleutel vertrouwt.
2. Uitdiensttreding van werknemers of contractanten: De toegang wordt dezelfde dag ingetrokken, niet opgenomen in een periodieke toegangsbeoordeling.
3. Een nieuwe CVE heeft gevolgen voor de gebruikte OpenSSH-versie. (zoals regreSSHion): patch eerst en overweeg het opnieuw uitgeven van host-sleutels als de kwetsbaarheid aannemelijk had kunnen maken dat sleutelmateriaal openbaar is gemaakt.
4. Een sleutel gevonden in een openbare opslagplaats, back-up of gedeelde schijf: Beschouw het als blootgesteld en draai het, ongeacht of misbruik is vastgesteld.
5. Geplande vervaldatum van de cryptoperiode Voor automatiserings- en serviceaccount-sleutels met een lange levensduur. NIST IR 7966 adviseert om deze sleutels met dezelfde zorgvuldigheid te beheren als wachtwoorden en certificaten.
6. Een wijziging in de reikwijdte of het privilege. voor toegang tot het systeem een ​​sleutel.

Gebeurtenisgestuurde rotatie detecteert incidenten die kalendergebaseerde rotatie mist. Een sleutel die de dag na de laatste geplande rotatie wordt gestolen, blijft maandenlang geldig onder een puur periodiek beleid.

Welk auditbewijs toont aan dat aan de SSH-beveiligingsvoorschriften is voldaan?

Auditors en compliance-frameworks zoals SOC 2, ISO 27001 en PCI DSS verwachten gedocumenteerd bewijs dat beveiligingsmaatregelen zijn geconfigureerd en afgedwongen, en niet alleen beschreven in een beleidsdocument.

• sshd_config Basissnapshots of CIS Benchmark-scanresultaten die wachtwoordverificatie, root-aanmelding en toegestane versleutelingsmethoden en MAC-adressen binnen het gehele wagenpark weergeven.
• Een actueel overzicht van SSH-sleutels: eigenaar, doel, aanmaakdatum, laatste gebruik en rotatiegeschiedenis voor elke sleutel.
• Authenticatie- en sessielogboeken van de bastionhost, bewaard volgens het beleid, tonen wie wanneer toegang had tot wat.
• MFA-handhavingslogboeken voor beheerdersaccounts.
• Patch- en versiegegevens die aantonen dat OpenSSH op alle hosts up-to-date is, zijn direct relevant voor periodes waarin CVE's zoals CVE-2024-6387 aan de orde komen.
• Rotatie- en intrekkingsgegevens zijn gekoppeld aan de bovenstaande triggers, niet alleen aan geplande evenementen.

Het handmatig verzamelen van deze gegevens over honderden of duizenden hosts is waar de meeste beveiligingsprogramma's vastlopen. Het centraliseren van de belangrijkste inventaris en configuratiestatus, in plaats van deze tijdens audits te reconstrueren, is een van de duidelijkste voordelen van een beheerd SSH-governanceplatform.

Aanvalstype versus beheersmaatregelen

De onderstaande tabel koppelt elke aanvalstechniek uit het begin van deze handleiding aan de beveiligingsmaatregel die er direct op van toepassing is.

Aanvalstype	Hoe het werkt	Primaire verhardingscontrole
Brute-force wachtwoord raden	Geautomatiseerde, herhaalde inlogpogingen op een blootgestelde poort 22.	Schakel wachtwoordverificatie uit; beperk het aantal verzoeken met fail2ban/sshguard; verlaag het maximale aantal authenticatiepogingen (MaxAuthTries).
Vulling met referenties	Het op grote schaal opnieuw gebruiken van gelekte gebruikersnaam/wachtwoordcombinaties.	Authenticatie met alleen een sleutel; MFA; IP-toegangslijst op de bastionhost.
interceptie door een man in het midden	De aanvaller onderschept of vervalst de sessie met behulp van een vervalste hostsleutel.	Strikte verificatie van host-sleutels; host-identiteit op basis van certificaten
Bekende CVE-exploitatie (bijv. CVE-2024-6387)	Een ongepatchte OpenSSH-bug op afstand misbruiken	Gepland patchbeheer; versiebeheer; kwetsbaarheidsscans
Gestolen of gelekte privésleutels	Sleutel gestolen van een eindpunt, opslagplaats of back-up	Met een wachtwoordzin beveiligde of door een HSM ondersteunde sleutels; kortstondige/vluchtige sleutels; onmiddellijke intrekking bij blootstelling.
Achterdeur sleutel invoegen	De aanvaller voegt een ongeautoriseerde sleutel toe aan authorized_keys na beperkte toegang.	Beperkte bestandsrechten; gecentraliseerde sleutelinventaris; bewaking van de bestandsintegriteit
Laterale beweging via vertrouwensspreiding	Hergebruikte of gedupliceerde sleutels worden vertrouwd in de ontwikkel-, test- en productieomgeving.	Netwerksegmentatie; bastionhost; afgebakend, omgevingsspecifiek vertrouwen

Handmatige sshd_config-beveiliging versus beheerd SSH-beheer: welke is schaalbaarder?

Handmatige beveiliging van sshd_config werkt voor een handvol servers. Daarbuiten zorgen configuratieafwijkingen en inconsistente sleutelrotatie ervoor dat precies die risico's weer terugkeren die beveiliging juist moest wegnemen. Daarom stappen de meeste bedrijven over op een beheerd of geautomatiseerd SSH-governanceplatform zodra hun serverpark groeit tot meer dan een paar dozijn hosts.

Afmeting	Handmatige sshd_config Beveiliging	Beheerde/geautomatiseerde SSH-governance
Initiële installatie-inspanning	Laag voor een enkele gastheer.	Hogere kosten vooraf, daarna consistent op grote schaal.
Consistentie binnen de gehele vloot	Afhankelijk van de discipline; verandert naarmate er meer hosts worden toegevoegd.	Centraal afgedwongen via beleid
Sleutelrotatie	Handmatig, foutgevoelig, moeilijk te verifiëren	Beleidsgestuurd, geautomatiseerd, geregistreerd
Inzicht in wie welke sleutel in handen heeft	Beperkt tot wat gedocumenteerd is.	Continue ontdekking en inventarisatie
Genereren van auditbewijs	Handmatig gereconstrueerd volgens de audit.	Wordt continu gegenereerd en kan op aanvraag worden geëxporteerd.
Snelheid van reactie op incidenten	Beperkt door hoe snel sleutels handmatig kunnen worden gevonden en ingetrokken.	Gecentraliseerde intrekking op elke vertrouwende host.

Geen van beide benaderingen vervangt de andere volledig. De hierboven beschreven sshd_config- baseline, bastionhost en netwerksegmentatie zijn fundamenteel, ongeacht de schaal. Wat verandert bij schaalvergroting, is of deze beheersmaatregelen in de loop der tijd gehandhaafd en aantoonbaar blijven. Dat is precies de kloof die beheerde platforms proberen te dichten.

Hoe implementeer je SSH-beveiliging? Een praktische workflow.

Het implementeren van SSH-beveiliging volgt een herhaalbare reeks stappen: inventariseer de bestaande situatie, stel de basislijn vast, beperk de toegang en controleer vervolgens continu.

1. Inventariseer elke host die via SSH bereikbaar is en de bijbehorende sleutels. Zo wordt niets door aannames vastgelegd.
2. Zorg voor een geharde sshd_config basislijn: Schakel wachtwoordverificatie uit, schakel root-aanmelding uit, beperk versleutelingsmethoden en MAC-adressen en dwing alleen SSH-2 af.
3. Dwing authenticatie af met alleen sleutels, met behulp van wachtwoordbeveiligde of door een HSM ondersteunde sleutels.
4. Implementeer een bastionhost of jumphost. Voor alle administratieve toegang is MFA vereist.
5. Voeg snelheidsbeperking en bescherming tegen brute-force-aanvallen toe. (fail2ban, sshguard of een vergelijkbaar systeem) op netwerk- en hostniveau.
6. Segmentnetwerken Productiesystemen vertrouwen daarom niet op ontwikkelings- of staging-sleutels.
7. Patches en versiebeheer voor OpenSSH op alle systemen. en CVE's bijhouden ten opzichte van de daadwerkelijk geïmplementeerde versies.
8. Definieer rotatietriggers en de rotatie en intrekking ervan automatiseren.
9. Schakel gecentraliseerde logboekregistratie en monitoring in. met waarschuwingen voor afwijkende toegangspatronen.
10. Genereer auditbewijs volgens een schema. en de vloot valideren aan de hand van de basislijn, in plaats van ervan uit te gaan dat deze nog steeds overeenkomt met de configuratie van dag één.

Wat als een aanvaller al SSH-toegang heeft?

Als de SSH-toegang al is gecompromitteerd, beperken beveiligingsmaatregelen de impact, maar de reactie zelf – intrekking, analyse van de omvang en herstel – verloopt via een apart, tijdgevoelig proces. Beveiliging vermindert de frequentie van dit scenario en de mogelijkheden van een aanvaller om binnen te komen, maar het is geen incidentresponsplan. Voor een stapsgewijs proces voor het beheersen van de situatie, de impactanalyse en het herstel, dat moet worden gevolgd zodra is bevestigd dat een sleutel of inloggegevens zijn blootgesteld, raadpleegt u onze speciale handleiding: Incidentrespons bij blootgestelde SSH-sleutels.

Beperkingen

Beveiligingsmaatregelen verkleinen het aanvalsoppervlak aanzienlijk, maar maken SSH niet onkwetsbaar, en het beschouwen ervan als een eenmalig project in plaats van een doorlopende beheersmaatregel ondermijnt de hele inspanning.

• Beveiligingsmaatregelen kunnen een zero-day-kwetsbaarheid niet stoppen voordat er een patch beschikbaar is. Tijdig patchen verkleint dit venster, maar sluit het nooit volledig uit.
• Het uitschakelen van root-aanmelding en wachtwoordverificatie voorkomt niet dat een medewerker misbruik maakt van een rechtmatig verstrekte sleutel. Daarvoor zijn toegang met minimale privileges en aanvullende monitoring nodig.
• Een bastionhost en netwerksegmentatie verminderen laterale beweging, maar elimineren deze niet volledig als de bastionhost zelf onvoldoende wordt bewaakt of te veel bevoegdheden heeft.
• Eenmalig toegepaste en nooit opnieuw gecontroleerde configuratiebeveiliging neemt in kwaliteit af naarmate er nieuwe hosts, images en automatiseringsprocessen worden toegevoegd.
• Geen van deze maatregelen kan een beproefd incidentresponsplan vervangen voor het geval een sleutel of inloggegeven daadwerkelijk openbaar wordt.

Wat zou Encryption Consulting aanbevelen?

Encryption Consulting adviseert om de bovenstaande handmatige beveiligingsmaatregelen te combineren met een platform dat deze continu afdwingt en tijdens een audit kan aantonen, aangezien handmatige configuratie alleen zelden bestand is tegen de groei van het netwerk. Dit is precies waar SSH Secure van pas komt, door de hiaten te dichten die individuele aanpassingen aan sshd_config openlaten.

• Gecentraliseerde zichtbaarheid en eigendomsmapping

  SSH Secure detecteert alle SSH-sleutels op servers en werkstations van gebruikers met behulp van scans met en zonder agents, en consolideert ze in één inventaris die is gekoppeld aan eigenaars- en gebruiksgegevens. Dit elimineert blinde vlekken, verwijdert ongebruikte sleutels en dicht de zichtbaarheidskloof waar aanvallers op vertrouwen bij het invoegen van backdoor-sleutels of het hergebruiken van verouderde inloggegevens.

• Sessiegebonden, tijdelijke sleutels

  Voor gevoelige of tijdelijke toegang kan SSH Secure kortstondige, sessiegebonden sleutels uitgeven die na gebruik automatisch verlopen. Een sleutel die niet meer bestaat, kan niet meer via brute force worden gekraakt, vervalst of maanden later uit een back-up worden gestolen.

• HSM-ondersteunde bescherming van privésleutels

  Privésleutels worden gegenereerd en opgeslagen in hardwarebeveiligingsmodules (HSM's), waardoor ze niet-exporteerbaar en manipulatiebestendig zijn. Dit biedt een directe oplossing voor scenario's met gestolen sleutels en compromittering van eindpunten. Ondersteunde algoritmen zijn onder andere RSA-4096, ECDSA en Ed25519.

• Beleidsgestuurde basishandhaving

  Het genereren, goedkeuren, roteren en intrekken van sleutels verloopt via consistente beleidscontroles. Dit voorkomt configuratieafwijkingen die ervoor kunnen zorgen dat een beveiligd netwerk na verloop van tijd ongemerkt weer wordt opengesteld.

• Continue monitoring, audits en paraatheid voor naleving.

  Realtime monitoring, gedetailleerde gebeurtenisregistratie en anomaliedetectie genereren het auditbewijs dat eerder in deze handleiding is beschreven, zonder handmatige reconstructie. Logboeken kunnen worden geïntegreerd met platforms zoals Splunk of Loki/Grafana voor correlatie en waarschuwingen.

Conclusie

Het beveiligen van SSH tegen aanvallen draait niet om het vinden van één wondermiddel. Brute-force-aanvallen en tools voor het misbruiken van inloggegevens falen bij authenticatie met alleen sleutels. MITM-interceptie faalt bij strikte verificatie van de hostsleutel. Bekende CVE's zoals regreSSHion falen bij een daadwerkelijk patchschema. Gestolen sleutels en sleutels met een backdoor falen bij opslag met een HSM, tijdelijke inloggegevens en een gecentraliseerde inventaris die ongeautoriseerde sleutels zichtbaar maakt in plaats van onzichtbaar.

Geen van deze beveiligingsmaatregelen werkt op zichzelf, en geen enkele blijft effectief zonder een eigenaar, een rotatietrigger en auditbewijs. Organisaties die SSH-beveiliging beschouwen als een continu afgedwongen basislijn, en niet als een eenmalige configuratie, sluiten de paden af ​​die aanvallers daadwerkelijk gebruiken. Voor de volledige levenscyclus van sleutels achter deze maatregelen, zie onze handleiding voor het beheer van de levenscyclus van SSH-sleutels ; voor wat te doen wanneer een sleutel al is blootgesteld, zie Incidentrespons voor blootgestelde SSH-sleutels.

Veelgestelde Vragen / FAQ

Wat is de meest effectieve beveiliging tegen brute-force-aanvallen op SSH? Het uitschakelen van wachtwoordverificatie en het afdwingen van inloggen met alleen een sleutel is de meest effectieve beveiliging, omdat het het type inloggegevens elimineert waarop brute-force- en credential-stuffing-tools zijn ontworpen om te raden. Combineer dit met het beperken van het aantal verbindingen (MaxAuthTries, een korte LoginGraceTime en een tool zoals fail2ban of sshguard) zodat herhaalde mislukte pogingen vanaf elke bron automatisch worden geblokkeerd.

Voorkomt het uitschakelen van root-login privilege-escalatie op een gecompromitteerde SSH-server? Nee. Het uitschakelen van root-login (PermitRootLogin no) dwingt een aanvaller om zich te authenticeren met een account met een naam en via sudo privileges te escaleren. Dit verbetert de identificatie en voegt een extra stap toe, maar het voorkomt op zichzelf geen escalatie. Het moet worden gecombineerd met sudo-regels die het minste privileges garanderen, het loggen van commando's en het monitoren van ongebruikelijk privilegegebruik.

Hoe vaak moeten SSH-sleutels worden geroteerd om aanvallen te voorkomen? Er is geen vast interval dat voor elke sleutel geschikt is. Sleutels voor automatiserings- en serviceaccounts met een lange levensduur moeten een vastgestelde cryptoperiode volgen, maar rotatie moet ook onmiddellijk worden geactiveerd bij specifieke gebeurtenissen: een vermoedelijke inbreuk, het vertrek van een medewerker of contractant, een sleutel die in een openbare repository of back-up wordt gevonden, of een nieuw onthulde CVE die van invloed is op de gebruikte SSH-versie.

Is een bastionhost nog steeds nodig als beheerders al gebruikmaken van authenticatie met alleen sleutels? Ja. Authenticatie met alleen sleutels voorkomt aanvallen met wachtwoorden, maar een bastionhost biedt extra functionaliteit die authenticatie met alleen sleutels niet biedt: gecentraliseerde handhaving van MFA (Multi-Factor Authentication), geregistreerde sessies, één gecontroleerd toegangspunt en isolatie van productiesystemen tegen directe blootstelling. Zonder een bastionhost is elke server een eigen, ongecoördineerd toegangspunt met inconsistente beveiligingsmaatregelen.

Maakt het patchen tegen CVE-2024-6387 een SSH-server op zich veilig? Nee. Het patchen van OpenSSH naar versie 9.8p1 ​​of later verhelpt die specifieke raceconditie, maar regreSSHion was slechts één van de vele mogelijke kwetsbaarheden. Een server kan volledig gepatcht zijn en toch kwetsbaar blijven door wachtwoordauthenticatie, toegestane root-login, onbeheerde sleutels of een gebrek aan netwerksegmentatie. Patchen is noodzakelijk, maar niet voldoende.

Referenties

• NIST IR 7966, “Beveiliging van interactief en geautomatiseerd toegangsbeheer met behulp van Secure Shell (SSH)”: https://nvlpubs.nist.gov/nistpubs/ir/2015/nist.ir.7966.pdf
• NVD, detailrecord van CVE-2024-6387: https://nvd.nist.gov/vuln/detail/CVE-2024-6387
• NSA, “Handleiding voor netwerkinfrastructuurbeveiliging” (2022): https://media.defense.gov/2022/Jun/15/2003018261/-1/-1/0/CTR_NSA_NETWORK_INFRASTRUCTURE_SECURITY_GUIDE_20220615.PDF
• CircleCI, “Beveiligingsincidentrapport van 4 januari 2023”: https://circleci.com/blog/jan-4-2023-incident-report