A Microsoft a legutóbbi javítási kedden kiadta az MS12-020 biztonsági frissítést, amely a Microsoft RDP (Remote Desktop Protocol) implementációjában nemrég felfedezett két hibát zár be. Az egyiket a Microsoft “kritikusnak” címkézi, mivel lehetővé teheti a hackerek számára, hogy LocalSystem irányítást szerezzenek egy olyan Windows-dobozon, amelyen engedélyezve van az RDP.
Amint azt már valószínűleg hallotta, ez egy magas kockázatú helyzet — olyan, amely olyan súlyos járványhoz vezethet, mint amilyet a Code Red, a Melissa vagy az SQL Slammer okozott. Foltozza be vagy javítsa ki most!
A Microsoft segít mindkettőben. Vagy telepítheti a javítást, vagy futtathat egy online Fix It szkriptet, hogy enyhítse a problémát a javítás alkalmazásáig. A szkript bekapcsolja a hálózati szintű hitelesítést, amely hitelesítést igényel, mielőtt egy távoli rendszer csatlakozhatna.
De van más tanácsom is. Ahogy azt már több mint egy évtizede ajánlom, a rendszergazdáknak fontolóra kell venniük, hogy az internetre csatlakoztatható szolgáltatásokat lehetőség szerint nem alapértelmezett portokon futtassák. Ebben a konkrét esetben az RDP-t a 3389-es porttól eltérő porton kellene futtatni.
Ez a tanács más területekre is kiterjed. Admin weboldalakat nem szabad a 80-as vagy akár a 443-as porton futtatni. Az SSH-t nem szabad a 22-es porton hallgatni. A Telnet hosztok nem hallgathatják a 23-as portot. Az egyetlen széles körben elterjedt általános szolgáltatás, amelyet nem tudtam megbízhatóan működésre bírni egy nem alapértelmezett porton, az FTP: a 21-es és 22-es portot használja (passzív módban), és még az aktív mód (ahol más portokat is megadhat) sem működik jól a tűzfalakon keresztül.
Az RDP esetében az alapértelmezett portot az alábbi útmutatást követve módosíthatja. Ha azonban megváltoztatja az alapértelmezett portot, akkor a csatlakozási karakterláncban meg kell adnia a nem alapértelmezett portot (például mstsc.exe 192.168.1.12:50045).
Az alapértelmezett figyelőport megváltoztatására vonatkozó ajánlásomat egy vállalati szintű szolgáltatásnál gyakran kritikával illetik. A központi érvem a következő: A legtöbb esetben egy vállalat megváltoztathatja az alapértelmezett figyelőportot, ami az adminisztrátori oktatáson és néhány szkript és eszköz egyszeri átkonfigurálásán túl nem okoz problémát, és jelentősen csökkenti a fegyveres támadás kockázatát.
Bár a hackerek és a rosszindulatú programok portolvasóval, például az Nmap segítségével megtalálhatják az új portot, fegyveres támadások még soha nem végeztek portolvasást, pedig könnyen megtehetnék. Már ez a tény önmagában is nagyfokú védelmet nyújt.
Mások ezt a fajta ajánlást “security by obscurity”-nek nevezik, mintha ez rossz dolog lenne. Ha engem kérdezel, a security by obscurity az egyik legjobb védelem. Ellenkező esetben minden nemzet nyilvánosságra hozná, hogy hol vannak a rakétái és atom-tengeralattjárói, ahelyett, hogy titokban tartaná az információkat.
Számomra az SQL Slammer féreg az egyik legjobb érv amellett, hogy a közös szolgáltatásokat nem alapértelmezett portokra helyezzük. A 2003-ban megjelent féreg 10 perc alatt szinte minden lehetséges, az internetre csatlakozó, nem javított és nem védett SQL-kiszolgálót kihasználta. Vasárnap kora reggel indult el, és mire a legtöbb rendszergazda felébredt, a kár már majdnem egy teljes munkanapon át tartott.
Lényegében mire kitöröltük a szemünkből a kérges sót, már vége volt — aztán a következő 48 órát (vagy még többet) azzal töltöttük, hogy feltakarítsuk a mocskot. Ez egy ébresztő volt.
Senkinek, aki engedélyezte az SQL-t egy nem alapértelmezett porton (azaz az 1433-on és 1434-en kívüli porton), nem kellett tennie semmit — azon kívül, hogy nyugodtan nézte, ahogy mindenki más megbirkózik a katasztrófával. Azoknak, akik portot váltottak, nem kellett hatalmas rendetlenséget eltakarítaniuk. Nem kellett javítócsomagokat kiadniuk. Nekik nem voltak kihasználható szervereik. Egyetlen, minimális működési hatással járó változtatással rengeteg kockázatot tudtak elkerülni.
Minden bizonnyal más enyhítések is ugyanolyan jól működnek, például érvényes VPN-kapcsolat megkövetelése a szolgáltatáshoz való csatlakozás előtt, előzetes portkapcsolatok kombinációjának megkövetelése a szolgáltatás engedélyezése előtt, vagy sikeres hitelesítés megkövetelése, mielőtt a szolgáltatás válaszol (ez a Microsoft Fix It megoldása), és bármi más, ami védelmet nyújthat a fegyveres támadások ellen.
De nem tudok más egyszerű biztonsági megoldást, amely ilyen hatékonyan csökkenti a kockázatot, mint az alapértelmezett port megváltoztatása, ha lehetséges. Ha követi ezt a tanácsot, helyezze a portot meglehetősen magas számra, 10 000 vagy 12 000 fölé, hogy elkerülje az esetleges portkonfliktusokat más meglévő szolgáltatásokkal. Tesztelje az összes termelő berendezést, és frissítse a szükséges tűzfalakat vagy proxykat. Azok az olvasók, akik a múltban követték ezt a tanácsot, ezen a héten már nem sietnek annyira.