Sidst i forbindelse med Patch Tuesday frigav Microsoft sikkerhedsopdatering MS12-020 for at lukke to nyligt opdagede fejl i Microsofts implementering af RDP (Remote Desktop Protocol). Den ene af dem betegner Microsoft som “kritisk”, fordi den kan give hackere mulighed for at opnå LocalSystem-kontrol på en Windows-boks med RDP aktiveret.
Som du sikkert har hørt nu, er der tale om en højrisikosituation – en situation, der kan resultere i en epidemi lige så alvorlig som den, der blev forårsaget af Code Red, Melissa eller SQL Slammer. Patch eller afhjælp nu!
Microsoft vil hjælpe dig med at gøre begge dele. Du kan enten installere patchen eller køre et online Fix It-script for at afhjælpe problemet, indtil patchen er installeret. Scriptet aktiverer Network Level Authentication, som kræver autentificering, før et fjernsystem kan oprette forbindelse.
Men jeg har et andet råd. Som jeg har anbefalet i mere end et årti, bør administratorer overveje at køre tjenester med internetforbindelse på ikke-standardporte, hvis det er muligt. I dette særlige tilfælde bør RDP køres på en anden port end port 3389.
Dette råd gælder også på andre områder. Admin-websteder bør ikke køres på port 80 eller endog 443. SSH bør ikke lytte på port 22. Telnet-værter bør ikke lytte på port 23. Den eneste udbredte almindelige tjeneste, som jeg ikke har kunnet få pålideligt til at fungere på en anden port end standardporten, er FTP: Den bruger port 21 og 22 (i passiv tilstand), og selv dens aktive tilstand (hvor du kan angive andre porte) fungerer ikke godt gennem firewalls.
I RDP’s tilfælde kan du ændre standardporten ved at følge denne vejledning. Når du ændrer standardporten, skal du dog angive den ikke-standardiserede port i forbindelsesstrengen (f.eks. mstsc.exe 192.168.1.12:50045).
Min anbefaling om at ændre standardlytteporten på en tjeneste, der dækker hele virksomheden, bliver ofte mødt med kritik. Mit centrale argument er følgende: I de fleste tilfælde kan en virksomhed ændre standardlytterporten, hvilket ikke medfører nogen problemer ud over uddannelse af administratorer og engangsrekonfigurering af nogle scripts og værktøjer, og det mindsker risikoen for våbenangreb betydeligt.
Men selv om hackere og malware kan bruge en portscanner som Nmap til at finde den nye port, har ingen våbeneksplosioner nogensinde foretaget portscanning, selv om de let kunne. Alene den kendsgerning giver dig en stor beskyttelse.
Som nogle mennesker kalder denne form for anbefaling for “sikkerhed ved uklarhed”, som om det var en dårlig ting. Hvis du spørger mig, så er sikkerhed ved uklarhed et af de bedste forsvar. Ellers ville hver nation offentliggøre, hvor dens missiler og atomubåde befandt sig, i stedet for at holde oplysningerne hemmelige.
For mig er SQL Slammer-ormen et af de bedste argumenter for at placere almindelige tjenester på ikke-standardiserede porte. Den blev udgivet i 2003 og udnyttede på 10 minutter næsten alle mulige ikke-patchede og ubeskyttede SQL-servere, der var forbundet med internettet. Den blev udløst tidligt en søndag morgen, og da de fleste administratorer var vågnet, var der sket skader i næsten en hel arbejdsdag.
Helt grundlæggende var det overstået, da vi havde tørret det skorpede salt ud af øjnene – og så brugte vi de næste 48 timer (eller længere) på at rydde op i rodet. Det var et wake-up call.
Ingen, der havde aktiveret SQL på en port, der ikke var standardport (dvs. en port ud over 1433 og 1434), behøvede at gøre noget — andet end at se roligt på, hvordan alle andre håndterede deres katastrofer. De, der skiftede port, behøvede ikke at rydde op i et stort rod. De behøvede ikke at haste ud med patches. De havde ikke udnyttede servere. En ændring med minimal operationel indvirkning, og de var i stand til at undgå tonsvis af risici.
Sikkert virker andre afbødninger lige så godt, f.eks. at kræve en gyldig VPN-forbindelse, før der oprettes forbindelse til tjenesten, at kræve en kombination af forudgående portkontakter, før tjenesten aktiveres, eller at kræve vellykket godkendelse, før tjenesten reagerer (dette er Microsofts Fix It-løsning), og alt andet, der kan beskytte dig mod våbenbaserede angreb.
Men jeg kan ikke komme i tanke om nogen anden simpel sikkerhedsløsning, der mindsker risikoen så effektivt som at ændre standardporten, når det er muligt. Hvis du følger dette råd, skal du flytte porten til et ret højt nummer, over 10.000 eller 12.000, for at undgå mulige portkonflikter med andre eksisterende tjenester. Test alt produktionsudstyr, og opdater eventuelle nødvendige firewalls eller proxyer. De læsere, der tidligere har fulgt dette råd, har ikke den store travlhed i denne uge.