Proč zabezpečení SSH vyžaduje systematický přístup
SSH zůstává jedním z nejdůležitějších nástrojů pro správu serverů Linux a Unix. Zároveň jde o jednu z nejatraktivnějších cest pro útočníky. Odcizený privátní klíč, odhalené heslo, neaktualizovaná služba SSH nebo účet administrátora s nadměrnými oprávněními mohou poskytnout přímou cestu k citlivým systémům.
Zabezpečeného přístupu k serveru nedosáhnete změnou jediného nastavení v souboru sshd_config. Posílení SSH funguje tehdy, když se vzájemně podporují řízení identity, síťového přístupu, oprávnění operačního systému, monitoringu a obnovy. Silný klíč je užitečný, ale nenahradí klíč uložený v nespravovaném notebooku. Seznam povolených IP adres omezuje vystavení, nezabrání však zneužití z povolené sítě.
Cílem je ztížit neoprávněný přístup, omezit možnosti napadeného účtu, rychle odhalit podezřelou aktivitu a zachovat bezpečnou cestu pro legitimní správu během incidentu.
Začněte dvěma nejcennějšími změnami pro posílení SSH
Vypněte přímé přihlášení uživatele root
Přímé přihlášení uživatele root ztěžuje dohledatelnost odpovědnosti i izolaci incidentu. Každý administrátor se zobrazí jako stejný uživatel a úspěšné přihlášení okamžitě poskytne neomezená oprávnění. Tam, kde je to z provozního hlediska vhodné, nastavte PermitRootLogin no a vyžadujte, aby se administrátoři připojovali pomocí pojmenovaných účtů a pro privilegované akce používali sudo.
Výjimky mohou existovat u pečlivě navržených postupů obnovy, neměly by však být výchozím nastavením. Pokud platforma vyžaduje nouzovou cestu s oprávněními root, chraňte ji samostatným klíčem, omezenou zdrojovou sítí, důsledným monitoringem a zdokumentovaným schvalovacím procesem.
Vypněte ověřování heslem
Ověřování heslem je vystaveno hádání hesel, útokům credential stuffing, phishingu a opakovanému používání hesel. Na serverech, které to podporují, ho po ověření funkčního schváleného přístupu pomocí klíče vypněte nastavením PasswordAuthentication no. Zkontrolujte také související nastavení, například ověřování keyboard-interactive, protože některé konfigurace mohou prostřednictvím této metody stále povolit přihlášení založené na hesle.
Neprovádějte tuto změnu bez otestování aktivní administrátorské relace a samostatné nové relace. Častou provozní chybou je ukončit jediné funkční připojení dříve, než ověříte náhradní způsob přístupu. Pro změny, které by mohly tým odříznout od serveru, mějte k dispozici řízenou konzoli nebo alternativní cestu obnovy.
Správně používejte silné ověřování pomocí veřejného klíče
Ověřování pomocí veřejného klíče je obecně bezpečnější a lépe spravovatelné než hesla, zabezpečení systému však závisí na obou částech páru klíčů. Veřejný klíč patří do konfigurace autorizovaných klíčů na serveru. Privátní klíč musí zůstat tajný a nikdy by neměl být kopírován do ticketů, skriptů, sdílených disků ani chatových zpráv.
Upřednostňujte moderní typy klíčů podporované používaným operačním systémem a verzí OpenSSH. Hardwarové bezpečnostní klíče mohou poskytovat obzvlášť silnou ochranu, protože operace s privátním klíčem probíhá v zařízení a klíč se hůře extrahuje. Pokud hardwarové klíče nejsou praktické, použijte silnou přístupovou frázi a ukládejte privátní klíče v šifrovaném úložišti klíčů operačního systému nebo v důvěryhodném systému pro správu tajemství.
Každý administrátor by měl mít vlastní klíč, nikoli sdílený týmový klíč. Individuální klíče umožňují identifikovat osobu odpovědnou za připojení, odebrat přístup jednomu člověku bez dopadu na ostatní a kontrolovat stáří i účel jednotlivých přihlašovacích údajů. Komentář připojený k veřejnému klíči není bezpečnostním prvkem, užitečné komentáře však mohou během auditu objasnit vlastnictví a data expirace.
Chraňte privátní klíč
Privátní klíč bez přístupové fráze je v podstatě opakovaně použitelný přihlašovací údaj založený na vlastnictví. Pokud je notebook odcizen nebo malware přečte soubor s klíčem, útočník se může okamžitě připojit. Používejte silnou a jedinečnou přístupovou frázi a načítejte klíče do agenta pouze na nezbytně dlouhou dobu. Pracovní stanici chraňte úplným šifrováním disku, zamykáním obrazovky, podporovanými aktualizacemi operačního systému a ochranou koncových zařízení.
Omezte oprávnění k souborům s privátními klíči. V systémech podobných Unixu by měl být klíč obvykle čitelný pouze jeho vlastníkem. Zálohy privátních klíčů vyžadují stejnou péči jako originály; nešifrovaná kopie v úložišti záloh podkopává ochranu pracovního zařízení. Když administrátor odejde, ztratí zařízení nebo má podezření na kompromitaci, považujte privátní klíč za kompromitovaný, dokud nebude odvolán nebo odstraněn ze všech autorizovaných serverů.
Uplatňujte princip nejmenších oprávnění a oddělujte identity administrátorů
Přístup přes SSH by měl poskytovat pouze minimální oprávnění potřebná pro danou roli. Webový vývojář může potřebovat prohlížet aplikační logy a restartovat službu, zatímco systémový inženýr může vyžadovat širší oprávnění operačního systému. Tyto odpovědnosti by se neměly automaticky převádět na neomezený přístup root.
Používejte pojmenované účty a řízená pravidla sudo, která tam, kde je to možné, povolují konkrétní příkazy. Ověřte, zda lze příkazy kombinovat za účelem obejití omezení. Například oprávnění spustit jako root editor, interpret nebo zálohovací nástroj může ve skutečnosti poskytovat neomezený přístup. Návrh podle principu nejmenších oprávnění musí zohlednit praktický dopad každého povoleného příkazu, nejen jeho název.
Oddělujte běžnou správu od vysoce rizikových činností. Administrátor může pro e-mail, prohlížení webu a rutinní práci používat standardní účet a samostatný privilegovaný účet využít pouze v případě potřeby. Snižuje se tak pravděpodobnost, že phishingový útok nebo kompromitace prohlížeče okamžitě získá oprávnění ke správě serveru. Zároveň vznikají přehlednější logy a privilegovanou aktivitu lze snáze kontrolovat.
Servisní účty by se neměly používat pro interaktivní správu. Automatizaci přidělte vlastní identitu, klíč a oprávnění a omezte ji na hostitele a příkazy, které potřebuje. Účet pro nasazování by neměl být zároveň účtem používaným pro údržbu databáze nebo nouzovou obnovu.
Vyberte správný druh druhého faktoru a síťovou hranici
MFA pro SSH
Vícefaktorové ověřování může snížit dopad odcizeného privátního klíče, zejména pokud je druhý faktor nezávislý na pracovní stanici administrátora. Mezi běžné přístupy patří integrace SSH se systémem jednorázových hesel, výzva založená na PAM, centrální poskytovatel identity nebo bastionový hostitel, který vynutí MFA před povolením dalšího přístupu.
Návrh MFA s sebou nese kompromisy. Jednorázový kód vygenerovaný na stejném napadeném notebooku jako klíč SSH může poskytovat menší ochranu než samostatný hardwarový token. Centrální ověřovací služba může zlepšit kontrolu, přináší však závislost, kterou je třeba během výpadku monitorovat a podporovat. Některé automatizace nedokážou dokončit interaktivní výzvu MFA, takže neinteraktivní úlohy potřebují jiný návrh, nikoli trvalou výjimku z MFA na účtu s vysokými oprávněními.
Tam, kde je to podporováno, mohou hardwarové bezpečnostní klíče FIDO2 nebo podobné klíče SSH nabídnout silnou odolnost vůči phishingu. Před jejich povinným zavedením otestujte kompatibilitu se zvoleným klientem, operačním systémem a procesem obnovy. Zachovejte řízený postup pro nahrazení ztraceného tokenu, aniž by vznikla skrytá trvalá zadní vrátka.
Seznamy povolených IP adres, VPN a bastionové hostitele
Omezení SSH na známé zdrojové IP adresy může snížit skenování a příležitostné útoky. Firewall, bezpečnostní skupina nebo síťový seznam řízení přístupu může povolit port 22 pouze z kancelářského rozsahu, sítě pro správu nebo VPN. Je to užitečné, ale nejde o úplnou ochranu: povolené sítě mohou být kompromitovány, adresy se mohou měnit a útočník se může již nacházet uvnitř povoleného prostředí.
VPN vytváří samostatnou administrativní hranici a může zjednodušit správu pravidel firewallu. I VPN však musí být aktualizována, silně ověřována a monitorována. Bastionový hostitel, někdy nazývaný jump host, soustřeďuje administrativní přístup do řízeného systému. Může vynutit MFA, zaznamenávat relace a poskytovat jedno místo pro seznamy povolených adres a logování. Zároveň se stává cenným cílem, proto potřebuje posílenou konfiguraci, omezené množství softwaru, rychlé aktualizace a otestovanou cestu obnovy.
Nevystavujte SSH široce internetu jen proto, že je zapnuto ověřování pomocí klíče. Zároveň nepředpokládejte, že přesun SSH na jiný port je bezpečnostní opatření. Nestandardní port může snížit množství šumu, nenahrazuje však ověřování, aktualizace, síťová omezení ani monitoring.
Rozumějte rizikům předávání agenta SSH
Předávání agenta SSH je praktické, když se administrátor připojí k jednomu serveru a poté potřebuje přistoupit k dalšímu bez kopírování privátního klíče. Vzdálený hostitel může požádat lokálního agenta o provedení ověřovací operace. Samotný privátní klíč se nepřenáší, kompromitovaný vzdálený server však může během aktivního připojení předávaného agenta využít.
Toto riziko je důležité při připojování přes servery, které jsou méně důvěryhodné než cílový server. Předávání agenta ve výchozím nastavení vypněte. Používejte ho jen pro konkrétní a pochopený úkol a zvažte omezení podle cíle, samostatné klíče nebo architekturu s bastionem. Administrátoři by měli vědět, které hostitele mohou k jejich agentovi přistupovat, a předávané relace by měli bez prodlení ukončovat.
Pro automatizaci upřednostňujte krátkodobé přihlašovací údaje, úzce omezené klíče pro nasazování, identitu workloadu nebo správce tajemství, pokud to platforma podporuje. Nikdy nevkládejte dlouhodobý privátní klíč administrátora do repozitáře zdrojového kódu ani do obrazu pro sestavení. Pokud pipeline musí používat SSH, omezte klíč podle zdroje, příkazu a cíle, kdykoli je to možné, a upozorňujte na jeho neočekávané použití.
Promyšleně rotujte, odvolávejte a kontrolujte přístupy
Rotace klíčů není jen každoroční úkol v kalendáři. Vytvořte inventář s vlastníkem každého klíče, jeho účelem, systémy, datem vytvoření, posledním použitím a plánovanou expirací. Odstraňujte nepoužívané klíče z authorized_keys a centrálních systémů řízení přístupu. Klíč bez známého vlastníka považujte za přístupové riziko, nikoli za neškodnou historickou konfiguraci.
Odvolání musí být pod tlakem prakticky proveditelné. Zdokumentujte, jak odstranit klíč z jednotlivých serverů, systémů pro správu konfigurace, bastionů a cloudových řídicích rovin. Pokud používáte certifikáty nebo centrální certifikační autoritu SSH, definujte krátkou dobu platnosti a udržujte spolehlivý proces odvolání. Ověřte, že odvolání přístupu jednoho administrátora omylem neodstraní přístup potřebný pro tým reakce na incidenty.
Kontrolu přístupů provádějte po změnách zaměstnanců, změnách dodavatelů, významných infrastrukturních projektech a bezpečnostních incidentech. Kontrolujte:
- Nastavení přímého přihlášení root a ověřování heslem.
- Neznámé, sdílené nebo neaktivní uživatelské účty.
- Veřejné klíče bez vlastníka, zastaralé klíče a klíče bez data expirace nebo kontroly.
- Příliš široká oprávnění sudo a rizikové povolené příkazy.
- Servisní účty umožňující interaktivní přihlášení.
- Neočekávaná naslouchající rozhraní, pravidla firewallu nebo veřejné vystavení SSH.
- Členství ve VPN, bastionech a MFA, včetně neaktivních účtů.
- Předávání agenta, předávání portů a další funkce SSH, které nejsou potřebné.
- Pokrytí logováním, synchronizaci času a dobu uchovávání událostí ověřování.
Pro praktický kontrolní seznam porovnejte svou aktuální konfiguraci s aktuálními osvědčenými postupy pro posílení SSH serveru a poté každé doporučení ověřte podle svého provozního modelu. Obecné pokyny nemohou rozhodnout, které nouzové výjimky vaše firma skutečně potřebuje.
Aktualizujte službu a zviditelněte podezřelý přístup
SSH je součástí operačního systému a mělo by podléhat stejné disciplíně aktualizací jako zbytek serveru. Aplikujte bezpečnostní aktualizace implementace SSH, operačního systému, knihoven, VPN, bastionu a nástrojů pro správu. Upřednostněte systémy vystavené internetu a definujte, jak se budou urgentní aktualizace testovat a nasazovat, aniž by zůstala nevyřešená kritická zranitelnost.
Zapněte logování připojení a ověřování na úrovni, která podporuje vyšetřování, ale nevytváří nezvladatelné množství šumu. Zaznamenávejte úspěšná i neúspěšná přihlášení, zdrojové adresy, uživatelská jména, identitu klíče nebo certifikátu, pokud je k dispozici, eskalaci oprávnění a změny konfigurace ověřování. Důležité logy odesílejte do samostatného systému, aby útočník s přístupem k serveru nemohl tiše vymazat důkazy.
Upozornění by se měla zaměřovat na užitečné signály. Patří mezi ně opakovaná selhání proti platnému účtu, úspěšné přihlášení z neobvyklé země nebo sítě, nový veřejný klíč, aktivita na úrovni root mimo servisní okno, vypnutá služba logování nebo náhlá změna pravidel firewallu. Upozornění musí mít vlastníka a eskalační postup; nepřehledný proud nekvalitních notifikací poskytuje jen malou ochranu.
Omezení rychlosti a nástroje, které dočasně blokují opakovaná selhání, mohou snížit šum a spotřebu prostředků způsobenou útoky hrubou silou. Mohou však také zablokovat legitimní uživatele za sdílenými adresami nebo nezastavit pomalý distribuovaný útok. Používejte je jako jednu vrstvu vedle silného ověřování, síťových kontrol, monitoringu a otestovaného procesu reakce.
Zabezpečte automatizaci a nouzový přístup
Automatizace často potřebuje přístup přes SSH bez přítomnosti člověka, proto je zde disciplína při návrhu obzvlášť důležitá. Pro každý významný pracovní postup vytvořte samostatný účet. Omezte jeho zdrojové prostředí, cílové hostitele a povolené příkazy. Přihlašovací údaje ukládejte do řízeného úložiště tajemství nebo chráněného runneru, pokud možno omezte jejich životnost a zabraňte vypisování privátních klíčů nebo podrobností o připojení do logů sestavení.
Prověřte, zda úloha skutečně potřebuje SSH. Platforma pro nasazování, systém pro správu konfigurace nebo API poskytovatele mohou nabídnout konkrétnější oprávnění a lepší auditovatelnost. Pokud je SSH nezbytné, oddělte produkční přihlašovací údaje od vývojových a pro změny v produkci vyžadujte výslovné schválení.
Nouzový přístup by měl být dostupný, ale používán zřídka. Uchovávejte zdokumentovaný účet nebo konzolovou cestu pro krizové situace pod kontrolovanou správou, se silným ověřováním, omezeným členstvím a jasnými požadavky na schválení. Každé použití monitorujte a následně zkontrolujte. Postup otestujte ještě před výpadkem; nouzový účet, který nebyl vyzkoušen, může selhat kvůli prošlému klíči, změněné síťové trase nebo zapomenuté závislosti.
Odolnost neřešte ponecháním trvalých neomezených zadních vrátek. Cesta obnovy by měla být chráněna pečlivěji než běžný přístup, v případě potřeby také offline nebo samostatně kontrolovanými informacemi pro obnovu.
Přizpůsobte kontroly SSH serveru, který skutečně spravujete
Rozsah dostupného posílení SSH závisí na modelu hostingu. U VPS nebo dedikovaného serveru, který firma spravuje, zákazník obvykle kontroluje operační systém, konfiguraci démona SSH, pravidla firewallu, uživatelské účty, klíče, aktualizace a logování. Konkrétní odpovědnost může být sdílená se spravovaným poskytovatelem, proto si ověřte, kdo provádí změny a kdo reaguje na upozornění.
U sdíleného hostingu zákazníci obecně nekontrolují konfiguraci SSH platnou pro celý server. Provozovatel hostingu rozhoduje, zda je SSH dostupné, které metody ověřování jsou podporovány, zda je shell přístup omezen a jak se aktualizuje základní systém. Zákazník může být schopen nahrát klíč nebo používat omezený shell, obvykle však nemůže zakázat přihlášení root, měnit sshd_config ani vynucovat celoplošné zásady přístupu organizace. Rozdíl mezi infrastrukturou VPS spravovanou zákazníkem a prostředím sdíleného hostingu je proto důležitý: kontroly SSH závisí na tom, kdo server provozuje.
Nepředpokládejte, že tarif sdíleného hostingu poskytuje stejné administrativní kontroly jako VPS nebo dedikovaný server. Pokud firma potřebuje přístup k operačnímu systému, pojmenované účty administrátorů, vlastní pravidla firewallu, bastion, podrobné logování SSH nebo serverové řízení záloh, vyberte model infrastruktury, u něhož jsou tyto odpovědnosti jasně přiřazeny.
Propojte zabezpečení přístupu s obnovou
Silné kontroly SSH snižují pravděpodobnost neoprávněné správy, nemohou však zaručit, že účet, server nebo pracovní stanice pro správu nebudou nikdy kompromitovány. Plánování obnovy musí počítat s tím, že přihlašovací údaje mohou být odcizeny a útočník může data pozměnit nebo zašifrovat.
Pro servery, které zákazník kontroluje, poskytuje Safenix off-site zálohování navržené pro obnovu firemních serverů. Zálohovaná data jsou šifrována klíčem, který Safenix nikdy nevlastní, uložena v Německu a neměnná po dobu zvoleného retenčního období. Toto oddělení je důležité: přístup k produkčnímu serveru by neměl automaticky umožnit přepsání všech chráněných záloh.
Zálohy nenahrazují posílení SSH a posílení SSH nenahrazuje zálohy. Ověřte, že přihlašovací údaje pro zálohování jsou oddělené od běžných administrátorských účtů, že proces zálohování nelze z kompromitované relace snadno vypnout a že přístup k obnově je zdokumentován. Testujte obnovu, nejen dokončení zálohování, a zaznamenejte, kdo může obnovu schválit a provést.
Praktický cyklus kontrol pro agentury a IT týmy
Učiňte zabezpečení SSH součástí běžné správy, nikoli jednorázového úklidu. Užitečný cyklus kontrol může zahrnovat měsíční kontrolu neúspěšných a neobvyklých přihlášení, čtvrtletní kontrolu účtů, klíčů a oprávnění a kontrolu po změnách personálu, migraci infrastruktury nebo podezření na kompromitaci.
- Vytvořte inventář všech serverů, koncových bodů SSH, administrátorů, identit automatizace a nouzových cest.
- Potvrďte vlastníka a obchodní účel každého účtu a veřejného klíče.
- Ověřte nastavení přihlášení root a heslem, MFA, síťové hranice a možnosti předávání.
- Zkontrolujte pravidla sudo, oprávnění servisních účtů a automatizaci v produkci.
- Prověřte stav aktualizací, logování, směrování upozornění a synchronizaci času.
- Otestujte odvolání klíčů, nouzový přístup, izolaci záloh a obnovu.
- Dokumentujte výjimky s vlastníkem, důvodem, datem expirace a kompenzačními kontrolami.
Nejlepšího výsledku dosáhnete kombinací malých, ověřitelných opatření: pojmenované identity místo sdílených účtů, klíče místo hesel, nejmenší oprávnění místo trvalého přístupu root, omezené sítě místo otevřeného vystavení a otestovaná obnova místo spoléhání na naději. Tento přístup zvyšuje odolnost zabezpečeného přístupu k serveru, aniž by předstíral, že jediné nastavení SSH dokáže odstranit veškerá rizika.