Brute-force útoky patří mezi nejčastější hrozby pro servery připojené k internetu. Obvykle jsou automatizované, vytrvalé a levné na provoz. Útočník nemusí o firmě vědět mnoho, aby mohl testovat SSH daemon, koncový bod RDP, ovládací panel, databázi nebo rozhraní pro vzdálenou správu pomocí tisíců odcizených či uhádnutých přihlašovacích údajů.
Mnoho pokusů selže a bezprostředně představuje jen malé riziko. Nebezpečí spočívá v tom, že jeden pokus uspěje, zejména pokud bylo heslo použito opakovaně, starý účet zůstal aktivní nebo je služba vystavena bez vícefaktorového ověřování. Opakovaná selhání přihlášení by proto měla být považována za užitečnou bezpečnostní telemetrii, nikoli jen za běžný internetový šum.
Tento průvodce vysvětluje, jak rozpoznat brute-force útoky na servery, která opatření je omezí, kde mohou strategie blokování selhat a co dělat, když se útočník dostane dovnitř.
Jak vypadá brute-force útok na server
Brute-force útok je pokus získat přístup zkoušením mnoha hesel, uživatelských jmen nebo kombinací přihlašovacích údajů. Moderní kampaně často používají credential stuffing místo náhodného hádání: útočník testuje dvojice uživatelských jmen a hesel získané z předchozích úniků. Password spraying využívá jiný přístup – jedno běžné heslo zkouší proti mnoha účtům, čímž se útočník vyhne blokování jednotlivých účtů.
SSH a RDP jsou častými cíli, protože poskytují přímý administrátorský přístup. Stejně důležité mohou být i další vystavené služby:
- webhostingové a serverové ovládací panely
- brány VPN a portály pro vzdálený přístup
- správa pošty a rozhraní webmailu
- databázové listenery, například MySQL, PostgreSQL nebo Microsoft SQL Server
- přihlašovací stránky aplikací a koncové body API
- konzole pro virtualizaci, zálohování a monitoring
Aktivita může pocházet z jedné adresy, rotujícího seznamu cloudových serverů nebo širokého rozsahu IP adres. Distribuovaný útok může z každé adresy vytvářet jen několik pokusů a přesto celkově generovat velké množství selhání. Proto často nestačí sledovat jediné pravidlo firewallu nebo jeden protokol serveru.
Jak odhalit automatizované pokusy o přihlášení
Začněte u protokolů ověřování
Protokoly ověřování jsou prvním místem, kam se podívat. V Linuxu se události SSH běžně objevují v systémovém journalu nebo v protokolu ověřování. Správci Windows by měli zkontrolovat události RDP a další relevantní události v Prohlížeči událostí nebo na centrální platformě pro protokolování Windows. Ovládací panely, produkty VPN a databáze obvykle vedou vlastní auditní protokoly.
Hledejte vzorce, nikoli izolované události:
- desítky nebo stovky neúspěšných přihlášení během krátké doby
- pokusy proti mnoha uživatelským jménům včetně neexistujících názvů
- opakované pokusy proti privilegovaným účtům, například root, administrator nebo účtům služeb
- připojení přicházející v pravidelných intervalech z měnících se adres
- úspěšné ověření bezprostředně po dlouhé řadě selhání
- přihlášení v neobvyklou dobu, z neobvyklých zemí nebo přes neznámé sítě
- nové účty, změněná hesla, upravené klíče SSH nebo změny členství ve skupinách
Jedno neúspěšné přihlášení není incident. Vzorec selhání napříč několika systémy, zejména pokud po něm následuje úspěšné přihlášení, si zaslouží vyšetření. Týmy, které vyhodnocují nástroje pro odhalování a blokování, mohou jednotlivé přístupy porovnat pomocí těchto zdrojů o detekci brute-force útoků na servery a Fail2banu, každý nástroj by však měl před nasazením automatického blokování ověřit ve vlastním prostředí.
Využijte upozornění a síťové signály
Shromažďování protokolů je užitečné pouze tehdy, pokud je někdo nebo něco kontroluje. Upozornění mohou vycházet z prahových hodnot, například deseti neúspěšných přihlášení SSH během pěti minut, ale pravidla založená jen na prahu mohou přehlédnout pomalý password spraying. Lepší monitoring kombinuje události ověřování se zdrojovými adresami, uživatelskými jmény, geolokací, kritičností aktiv a úspěšnými přihlášeními.
Kontext může doplnit síťová telemetrie. Sledujte náhlý nárůst pokusů o připojení k portům pro správu, opakované TCP handshaky, které se nikdy nedokončí, skenování několika služeb nebo neobvyklý odchozí provoz po podezřelém přihlášení. Napadený server může začít navazovat spojení s infrastrukturou pro velení a řízení, skenovat interní systémy nebo přenášet data.
Centralizovaný monitoring je obzvlášť důležitý pro agentury spravující několik zákaznických prostředí. Jediný řídicí panel nebo platforma SIEM usnadňuje odhalení stejného rozsahu IP adres, vzorce uživatelských jmen nebo kampaně password spr ayingu napříč více servery. Upozornění by měla dorazit člověku, který může jednat, a obsahovat dostatek podrobností, aby zasahující tým během incidentu nemusel procházet nezpracované protokoly.
Zabezpečení SSH a dalších vystavených služeb
Používejte silné ověřování
Pokud je to praktické, zakažte ověřování heslem přes SSH a vyžadujte individuální kryptografické klíče. Každý administrátor by měl mít samostatný účet a klíč, přičemž privilegovaný přístup by měl získávat řízeným povýšením oprávnění, nikoli pomocí sdílených přihlašovacích údajů root. Chraňte soukromé klíče pomocí přístupových frází a bezpečně je ukládejte. Jakmile zaměstnanec nebo dodavatel přístup nepotřebuje, klíče neprodleně odeberte.
U RDP, VPN a ovládacích panelů používejte vícefaktorové ověřování všude, kde ho produkt podporuje. Pokud je to možné, dávejte přednost metodám odolným proti phishingu, zejména u administrátorských účtů. MFA neudělá zranitelnou službu neškodnou, ale výrazně snižuje hodnotu odcizeného hesla.
Zásady pro hesla jsou stále důležité u služeb, které hesla vyžadují. Používejte dlouhé a jedinečné přihlašovací údaje, správce hesel a oddělené účty pro správu, aplikace a databáze. Nikdy nenechávejte aktivní výchozí údaje dodavatele. Neaktivní účty deaktivujte a zkontrolujte, zda účty služeb nemají zbytečný interaktivní přístup.
Omezte vystavení
Nejbezpečnější rozhraní pro správu je takové, které není veřejně dostupné. Pokud je to z provozního hlediska možné, omezte přístup k SSH, RDP a databázím na VPN, privátní síť, bastion host nebo definované rozsahy IP adres administrátorů. Databázový listener obvykle nemá žádný důvod přijímat připojení z veřejného internetu.
Změna výchozího portu SSH může omezit příležitostné skenování, sama o sobě však není bezpečnostním opatřením. Útočníci nestandardní porty rychle objeví. Vnímejte ji jako omezení šumu, nikoli jako ochranu. Silnějšími opatřeními jsou omezení sítě, moderní ověřování, aktualizace a monitoring.
Instalujte bezpečnostní aktualizace operačních systémů, ovládacích panelů, VPN a aplikací. Odstraňte služby, které už nejsou potřeba, a ověřte, že po migracích nebo změnách firewallu nejsou administrátorská rozhraní omylem vystavena. Hostitele zabezpečte podle zdokumentovaného standardu a tento standard pravidelně kontrolujte, místo abyste předpokládali, že jednorázová konfigurace zůstane správná.
Techniky blokování a omezení rychlosti
Firewally a filtrování na úrovni poskytovatele
Hostitelské firewally mohou omezit porty pro správu, povolit jen určité zdrojové sítě a odmítnout provoz dříve, než dorazí k aplikaci. Síťové firewally nebo filtrování na úrovni poskytovatele mohou nežádoucí provoz zachytit či zahodit dříve, což je užitečné, když útok vytváří tolik připojení, že spotřebovává zdroje serveru.
Ovládací prvky na úrovni poskytovatele nenahrazují zabezpečené účty. Mohou být také méně přesné než aplikačně orientované nástroje, zejména když jeden rozsah adres sdílí mnoho legitimních zákazníků. Stanovte schválené sítě administrátorů a udržujte nouzovou přístupovou cestu, aby chybné pravidlo neodřízlo osoby odpovědné za jeho opravu.
Blokování ve stylu Fail2ban
Nástroje jako Fail2ban sledují protokoly a po definovaném počtu selhání přidávají dočasná pravidla firewallu. Jsou praktické pro SSH a další služby s konzistentním formátem protokolů. Dobu blokování, práh selhání a seznam ignorovaných adres vybírejte podle pozorovaného chování, nikoli jejich bezmyšlenkovitým převzetím.
Dočasné blokování obvykle nabízí lepší rovnováhu než trvalé zákazy. Zpomalí opakované pokusy, omezí šum v protokolech a poskytne administrátorům čas reagovat, aniž by vznikal stále rozsáhlejší seznam zákazů. Ověřte, že samotný monitorovací nástroj funguje i po rotaci protokolů, restartu služby a změnách ověřovacího systému.
Omezení rychlosti a kontrola účtů
Omezení rychlosti lze implementovat na reverzní proxy, firewallu, v aplikaci nebo u poskytovatele identity. Je obzvlášť užitečné pro webové přihlašovací stránky a API, kde musí služba zůstat veřejně dostupná. Postupné prodlevy, výzvy CAPTCHA a MFA založené na riziku mohou omezit automatizaci, aniž by po jediné chybě odepřely přístup každému uživateli.
Blokování účtů vyžaduje větší opatrnost. Přísné uzamčení může zastavit hádání hesla u jednoho účtu, ale útočník může během password-spraying kampaně záměrně zablokovat všechny zaměstnance. Dávejte přednost krátkým, postupně prodlužovaným blokacím nebo throttlingu a vytvořte otestovaný proces administrátorské obnovy. U privilegovaného účtu se nikdy nespoléhejte na zásadu blokování jako na jedinou obranu.
Kompromisy a běžná slepá místa
Blokování IP adres je snadno pochopitelné, má však omezení. Adresy mohou sdílet kanceláře, mobilní sítě, cloudové platformy nebo sítě s NAT na úrovni operátora. Zablokování celého rozsahu může ovlivnit legitimní uživatele, zatímco blokování jednotlivých adres může mít proti distribuované kampani malý účinek. Geolokační pravidla mohou také vytvářet falešné poplachy u cestujících zaměstnanců a vzdálených dodavatelů.
Falešné poplachy nejsou jen nepříjemností. Zablokovaný monitorovací systém, operátor záloh nebo nouzový administrátor může zpozdit obnovu. V případě potřeby udržujte seznam povolených důvěryhodných cest pro správu, ale pečlivě ho chraňte a pravidelně kontrolujte. Nepovolujte široký dynamický rozsah jen proto, že byl kdysi spojen s legitimním uživatelem.
Distribuované útoky vyžadují opatření zaměřená na identitu. Pokud je stejný účet napadán z mnoha sítí, blokování zdrojů problém nevyřeší. Silné MFA, jedinečné přihlašovací údaje, zakázané ověřování heslem a centralizovaná detekce představují trvalejší reakci. Hledejte vzorce podle uživatelského jména, zařízení, aplikace a času stejně jako podle IP adresy.
Jak vyšetřit podezřelý útok
Začněte uchováním důkazů. Zaznamenejte napadeného hostitele, časové pásmo, relevantní záznamy v protokolech, zdrojové adresy, cílové účty a všechna již použitá automatická blokování. Exportujte protokoly dříve, než budou přepsány. Pokud existuje reálná možnost napadení, server předčasně nerestartujte ani nečistěte; důležité mohou být volatilní důkazy a aktivní spojení.
Poté zjistěte, zda byla aktivita neúspěšná, nebo zda byl účet použit. Vyhledejte úspěšná přihlášení v blízkosti neúspěšných pokusů a ověřte zdroj, metodu ověřování a čas. Následně zkontrolujte:
- nové místní nebo doménové účty a neočekávané členství ve skupinách
- nové autorizované klíče SSH, naplánované úlohy, cron úlohy nebo položky spouštěné při startu
- změny pravidel firewallu, nastavení vzdáleného přístupu nebo bezpečnostních zásad
- neočekávané procesy, naslouchající porty a odchozí spojení
- upravené webové soubory, binární soubory, skripty a konfigurační soubory
- neobvyklý přístup k datům, stahování, nahrávání nebo eskalaci oprávnění
Porovnejte hostitele se známou bezchybnou konfigurací nebo standardem sestavení. Kromě samotného serveru zkontrolujte také protokoly poskytovatele identity, VPN, firewallu, koncových zařízení a cloudu. Pokud existuje jakékoli rozumné podezření, že byly údaje odhaleny, změňte přihlašovací údaje a odvolejte relace. Pokud systém zpracovává regulovaná data, informace o zákaznících nebo kritické operace, postupujte podle incidentního procesu organizace a zvažte právní, regulační a smluvní oznamovací povinnosti.
Zablokování pokusu není reakcí na napadení
Pravidlo firewallu nebo blokování ve Fail2banu řeší pozorované připojení. Neodstraní útočníka, který se již ověřil. Úspěšné přihlášení mění situaci z obtěžujícího provozu na potenciální bezpečnostní incident.
Pokud máte podezření na napadení, izolujte server od sítě, zachovejte potřebné důkazy a udržujte řízenou cestu pro správu. Podezřelý účet jednoduše nesmažte a neuvádějte hostitele znovu do provozu. Útočník mohl vytvořit mechanismus persistence, odcizit přihlašovací údaje nebo změnit binární soubory. Bezpečnější reakcí je určit rozsah, podle potřeby znovu sestavit systém z důvěryhodného zdroje, opravit původní slabinu, změnit tajné údaje a obnovené služby pečlivě monitorovat.
Obnova závisí také na čistých a použitelných zálohách. Zálohy by měly být izolovány od běžných přihlašovacích údajů serveru a roviny jeho správy, protože útočník s administrátorským přístupem se je může pokusit smazat nebo zašifrovat. Safenix poskytuje off-site zálohování firemních serverů kontrolovaných zákazníkem. Data jsou šifrována klíčem, který Safenix nikdy nevlastní, uložena v Německu a po dobu zvoleného retenčního okna jsou neměnná. Jde o opatření pro obnovu, nikoli náhradu za zabezpečení nebo reakci na incident: zákazník zůstává odpovědný za kontrolu chráněného serveru a rozhodnutí, jak ho obnovit.
Prostředí VPS, dedikovaných serverů a sdíleného hostingu
Dostupná opatření silně závisí na tom, kdo kontroluje operační systém a hranici sítě. Zákazníkem spravovaný VPS obvykle poskytuje přístup k operačnímu systému, firewallu a konfiguraci služeb. Administrátor tak může v rámci omezení platformy poskytovatele vynutit klíče SSH, zakázat přihlašování heslem, nainstalovat monitoring hostitele a omezit provoz pro správu.
Dedikovaný server obvykle nabízí přímější kontrolu nad hostitelem, návrhem sítě a oddělením zátěží, přesná odpovědnost však stále závisí na smlouvě a modelu správy. Spravovaný server může některé změny omezovat a současně poskytovat provozní podporu. Toto rozdělení odpovědností zdokumentujte ještě před vznikem incidentu.
Sdílený hosting je odlišný. Poskytovatel kontroluje hostitele, operační systém, konfiguraci webového serveru i bezpečnostní hranici mezi zákazníky. Zákazníci mohou měnit nastavení aplikace, ale obvykle nemohou instalovat Fail2ban, upravovat firewall hostitele, zakázat SSH pro platformu ani kontrolovat všechny protokoly ověřování. Doporučení týkající se bezpečnostních opatření v zákazníkem spravované infrastruktuře VPS ve srovnání se sdíleným hostingem je proto nutné číst v kontextu skutečně poskytnutého přístupu.
Safenix chrání servery kontrolované zákazníkem. Nenabízí zálohovací plán pro web běžící na sdíleném hostingu a web na sdíleném hostingu by neměl být prezentován, jako by byl pokryt zálohovací službou Safenix pro servery. U sdíleného hostingu musí zákazník využít dostupné možnosti zálohování a exportu poskytovatele, případně přesunout zátěž na infrastrukturu, nad níž má organizace potřebnou kontrolu.
Praktická rutina provozu
Obrana proti brute-force útokům funguje nejlépe jako provozní rutina, nikoli jako jediné nastavení. Minimálně pravidelně kontrolujte vystavené služby a privilegované účty. Testujte upozornění pomocí autorizovaných simulací, ověřujte, že blokování končí podle očekávání, a kontrolujte, zda administrátoři stále dosáhnou na nouzovou přístupovou cestu.
- Udržujte inventář internetově dostupných služeb, jejich vlastníků a schválených sítí pro správu.
- Kontrolujte trendy neúspěšných i úspěšných ověření, nejen nejnovější upozornění.
- Pro správu používejte klíče SSH, MFA, jedinečné účty a princip nejmenších oprávnění.
- Aktualizujte operační systémy a vystavené aplikace a odstraňujte nepotřebné služby.
- Centralizujte protokoly a zajistěte, aby upozornění byla použitelná týmem odpovědným za reakci.
- Testujte obnovu ze záloh a ověřte, že data pro obnovu jsou izolována od přihlašovacích údajů serveru.
- Zdokumentujte kontakty pro eskalaci, kroky k uchování důkazů a postupy opětovného sestavení.
Automatizované útoky budou i nadále testovat vystavené služby, nemusí se však stát krizí. Nejprve omezte vystavení, ztěžte zneužití ověřování, používejte blokování jako uváženou vrstvu a sledujte známky toho, že se pokus změnil v úspěšné přihlášení. Jakmile je hranice překročena, přejděte bez prodlení od blokování k reakci na incident a obnově.