Zkoušení hesel na RDP

Moc pěkná otázka dorazila, rád odpovídám rovnou veřejně, protože to je velmi obecný problém:

Včera jsem si všiml, že jsme pod brutforcem nějakých hackerů z Ruska. Útočili nám na Remote Desktop Connection broker (3389). Dělali to pěkně pomalu a opatrně, už jsme to dost minimalizovali. Odkážete mě na nějaké dražší hardwarové/softwarové řešení nebo toto spíš navrhujete řešit jiným způsobem? Resp. nechci odkazovat na nějaký konkrétní produkt, spíš mě zajímá Váš postoj k tomuto. Třeba mi řeknete, že po dobrém nastavení hesel a oprávnění to řešit nemusíme vůbec.

Odpověď

Z toho, jak to popisujete, se dá vyhodnotit, že zřejmě máte otevřen přímý přístup přes TCP 3389 z internetu a někdo zkoušel online hesla na nějaké loginy.

Nejprve se zabývejme loginy. Byly to nějaké vaše skutečné existující loginy, nebo to vždycky selhalo na tom, že to nebyl správný login? To poznáte například na tom RDP serveru v logu z Failure Audit události typu Logon. Bude v tom chyba 0xC000006D (což je obecně STATUS_LOGON_FAILURE), ale také tam bude přesnější důvod - buď 0xC000006A (STATUS_WRONG_PASSWORD), nebo právě 0xC0000062 tedy STATUS_INVALID_ACCOUNT_NAME.

Pokud útočník nezná ani loginy, tak je jasné, že to je úplný cizinec. Pokud loginy zná, tak se ptejme, jestli to jsou nějaké známé loginy, jako třeba administrator a nestálo by za to tyto loginy buď přejmenovat, nebo určitě rovnou i zakázat.

Pokud by útočník znal všechny vaše loginy, mohl by vám je takto dokonce vzdáleně všechny pozamykat. Nemusí vůbec zkoušet hesla s cílem je uhádnout. Prostě jenom na každý účet bouchne několikrát, aby se zamknul. Takto by vám pozamykal i servisní účty a vyřadil tak celou vnitřní infrastrukturu, alespoň na nějakou dobu

Dále je vždycky žádoucí mít kvalitní hesla. Pokud by to jedno online ověření trvalo třeba 15 ms, což je dnes cca standard na rychlých systémech, tak vyzkoušet polovinu osmiznakových alfanumerických (alfanum8) hesel by trvalo 52 000 let. Píšete, že to navíc zkoušeli velmi pomalu, což indikuje, že se prostě snažili použít jen několik profláknutých hesel.

Proti tomu se dá obvykle chránit delšími hesly. Pokud si dáte politiku alespoň 10 znaků, tam už moc profláknutá hesla nejsou, protože to už není například jen jedno slovo a číslo.

Máte Windows AD prostředí, takže máte politiku 3of4. Až budu u vás, nasadíme vám moji politiku 4of4, takže si lidé budou muset dávat hesla obsahující alespoň jeden speciální znak, což kompletně odstraní problém profláknutých hesel a to i na intranetu.

To jsou ale spíše okrajové záležitosti.

Zabezpečení vzdáleného přístupu proti zkoušení hesel

Jak ale omezíme zkoušení hesel úplně? Musíte vyžadovat něco jiného než heslo už jen k tomu, aby se vůbec ustavilo vzdálené spojení. Na to se používají buď VPN připojení s ověřením pomocí buď klientského certifikátu (client certificate), nebo nějaká jiná multifaktorová autentizace (token, smart card, RSA SecureId kalkulátor, SMS, apoška).

Microsoft k tomuto má možnosti jako je SSTP (TLS HTTPS VPN), nebo IKEv2 a DirectAccess, všechno s čipovou kartou nebo jen certifikátem v počítači.

Pokud se jedná o prosté RDP, tak můžete využití také RD Gateway. RD Gateway může také vyžadovat klientský certifikát (nebo i čipovou kartu - smart card) k připojení. Takže neotevřete rovnou 3389, ale budete mít otevřen jenom TCP HTTPS 443 směrem na RD Gateway, která bude vyžadovat client certificate vůbec k vytvoření TLS spojení.

Webové aplikace, nebo i RD Gateway se dají dále publikovat přes WAP (Web Application Proxy), která může stejně tak vyžadovat klientský certifikát.