Poslední záplatovací úterý vydala společnost Microsoft aktualizaci zabezpečení MS12-020, která odstraňuje dvě nedávno objevené chyby v implementaci protokolu RDP (Remote Desktop Protocol) společnosti Microsoft. Jednu z nich Microsoft označuje jako „kritickou“, protože by mohla hackerům umožnit získat kontrolu nad LocalSystem v počítači se systémem Windows s povoleným RDP.
Jak jste již pravděpodobně slyšeli, jedná se o vysoce rizikovou situaci — takovou, která by mohla vyústit ve stejně závažnou epidemii, jakou způsobily Code Red, Melissa nebo SQL Slammer. Záplatu nebo nápravu proveďte hned!
Microsoft vám pomůže udělat obojí. Můžete buď nainstalovat záplatu, nebo spustit online skript Fix It, který problém zmírní do doby, než bude záplata aplikována. Skript zapíná ověřování na síťové úrovni, které vyžaduje ověření před připojením vzdáleného systému.
Mám však ještě další radu. Jak doporučuji již více než deset let, správci by měli zvážit spuštění služeb připojitelných k internetu na jiných než výchozích portech, pokud je to možné. V tomto konkrétním případě by měl být RDP spuštěn na jiném portu než 3389.
Tato rada se vztahuje i na další oblasti. Webové stránky správce by neměly být spouštěny na portu 80 nebo dokonce 443. SSH by nemělo naslouchat na portu 22. Hostitelé Telnetu by neměli naslouchat na portu 23. Jedinou rozšířenou běžnou službou, kterou se mi nepodařilo spolehlivě zprovoznit na jiném než výchozím portu, je FTP: používá porty 21 a 22 (v pasivním režimu) a ani jeho aktivní režim (kde můžete uvést jiné porty) nefunguje dobře přes firewally.
V případě RDP můžete výchozí port změnit podle tohoto návodu. Při změně výchozího portu však musíte v řetězci připojení uvést jiný než výchozí port (například mstsc.exe 192.168.1.12:50045).
Moje doporučení změnit výchozí naslouchací port u celopodnikové služby se často setkává s kritikou. Můj hlavní argument je následující:
Ve většině případů může podnik změnit výchozí naslouchací port, což nezpůsobí žádné problémy nad rámec vzdělání správce a jednorázového překonfigurování některých skriptů a nástrojů, a výrazně se tím sníží riziko ozbrojeného útoku.
Ačkoli hackeři a škodlivý software mohou k nalezení nového portu použít skener portů, jako je Nmap, žádný ozbrojený exploit ještě skenování portů neprovedl, ačkoli by snadno mohl. Už jen tento fakt vám dává velkou ochranu.
Někteří lidé nazývají tento druh doporučení „security by obscurity“, jako by to bylo něco špatného. Pokud se ptáte mě, je zabezpečení prostřednictvím zastínění jednou z nejlepších obran. Jinak by každý stát zveřejňoval, kde má své rakety a jaderné ponorky, místo aby tyto informace tajil.
Červ SQL Slammer je pro mě jedním z nejlepších argumentů pro umístění běžných služeb na jiné než výchozí porty. Byl vydán v roce 2003 a během 10 minut zneužil téměř všechny možné nezáplatované a nechráněné SQL servery připojené k internetu. Vypukl v neděli brzy ráno, a než se většina administrátorů probudila, docházelo k poškození téměř celý pracovní den.
Zjednodušeně řečeno, než jsme si utřeli krupičku soli z očí, bylo po všem – pak jsme se dalších 48 hodin (nebo déle) snažili uklidit nepořádek. Byl to budíček.
Nikdo, kdo povolil SQL na jiném než výchozím portu (tedy na jiném portu než 1433 a 1434), nemusel nic dělat – kromě toho, že klidně sledoval, jak se ostatní vypořádávají se svými katastrofami. Ti, kteří porty přepnuli, nemuseli uklízet obrovský nepořádek. Nemuseli narychlo vydávat záplaty. Nemuseli mít zneužité servery. Stačila jedna změna s minimálním provozním dopadem a mohli se vyhnout tunám rizik.
Jistě stejně dobře fungují i jiná zmírnění, například vyžadování platného připojení VPN před připojením ke službě, vyžadování kombinace předchozích kontaktů na portu před povolením služby nebo vyžadování úspěšného ověření před tím, než služba zareaguje (to je řešení Fix It od Microsoftu), a cokoli dalšího, co by vás mohlo ochránit před útoky se zbraní v ruce.
Ale nenapadá mě žádné jiné jednoduché řešení zabezpečení, které by tak účinně snižovalo riziko, než změna výchozího portu, pokud je to možné. Pokud se budete řídit touto radou, přesuňte port na poměrně vysoké číslo, nad 10 000 nebo 12 000, abyste se vyhnuli možným konfliktům portů s jinými existujícími službami. Otestujte všechna produkční zařízení a aktualizujte všechny potřebné firewally nebo proxy servery. Čtenáři, kteří se touto radou řídili v minulosti, tento týden příliš nespěchají.
.