Op Patch Tuesday heeft Microsoft beveiligingsupdate MS12-020 uitgebracht om twee onlangs ontdekte fouten in Microsofts implementatie van RDP (Remote Desktop Protocol) te dichten. Een van deze fouten wordt door Microsoft als “kritiek” bestempeld, omdat hackers hierdoor controle over het lokale systeem kunnen krijgen op een Windows box met RDP ingeschakeld.
Zoals u waarschijnlijk al heeft gehoord, is dit een situatie met een hoog risico — een die kan resulteren in een epidemie die net zo ernstig is als die veroorzaakt door Code Red, Melissa, of SQL Slammer. Patch of herstel nu!
Microsoft zal u helpen beide te doen. U kunt de patch installeren of een online Fix It-script uitvoeren om het probleem te beperken totdat de patch is toegepast. Het script schakelt Network Level Authentication in, dat authenticatie vereist voordat een remote systeem verbinding kan maken.
Maar ik heb ander advies. Zoals ik al meer dan een decennium aanbeveel, zouden beheerders moeten overwegen om Internet-verbonden diensten op niet standaard poorten te draaien, indien mogelijk. In dit geval zou RDP op een andere poort moeten draaien dan poort 3389.
Dit advies geldt ook voor andere gebieden. Admin websites moeten niet draaien op poort 80 of zelfs 443. SSH zou niet moeten luisteren op poort 22. Telnet hosts zouden niet moeten luisteren op poort 23. De enige wijdverbreide algemene dienst die ik niet betrouwbaar aan de praat heb kunnen krijgen op een niet-standaard poort is FTP: Het gebruikt poorten 21 en 22 (in passieve modus), en zelfs de actieve modus (waar u andere poorten kunt aangeven) werkt niet goed door firewalls.
In het geval van RDP kunt u de standaard poort wijzigen door deze aanwijzingen te volgen. Wanneer u de standaardpoort wijzigt, moet u echter de niet-standaardpoort in de verbindingstring aangeven (bijvoorbeeld mstsc.exe 192.168.1.12:50045).
Mijn aanbeveling om de standaardluisterpoort te wijzigen op een bedrijfsbrede service wordt vaak met kritiek ontvangen. Mijn centrale argument is dit: In de meeste gevallen kan een onderneming de standaard luisterpoort wijzigen, wat geen problemen veroorzaakt buiten admin-educatie en het eenmalig herconfigureren van enkele scripts en tools, en het vermindert aanzienlijk het risico van een gewapende aanval.
Hoewel hackers en malware een poortscanner zoals Nmap kunnen gebruiken om de nieuwe poort te vinden, hebben geen gewapende exploits ooit poortscanning gedaan, hoewel ze dat gemakkelijk zouden kunnen. Dat feit alleen al geeft je een hoop bescherming.
Sommigen noemen dit soort aanbevelingen “beveiliging door obscuriteit”, alsof dat iets slechts is. Als je het mij vraagt, is beveiliging door onduidelijkheid een van de beste verdedigingen. Anders zou elk land bekend maken waar zijn raketten en kernonderzeeërs zich bevinden, in plaats van die informatie geheim te houden.
Voor mij is de SQL Slammer worm een van de beste argumenten om algemene diensten op niet-default poorten te zetten. Uitgebracht in 2003, exploiteerde het bijna elke mogelijke ongepatchte en onbeschermde SQL server verbonden met het Internet in 10 minuten. Het ging af op een vroege zondagochtend, en tegen de tijd dat de meeste admins wakker waren geworden, was er al bijna een volledige werkdag schade aangericht.
Basically, tegen de tijd dat we het korstige zout uit onze ogen hadden geveegd, was het voorbij – vervolgens waren we de volgende 48 uur (of langer) bezig om de rotzooi op te ruimen. Het was een wake-up call.
Niemand die SQL had ingeschakeld op een niet-default poort (dat wil zeggen, een andere poort dan 1433 en 1434) hoefde iets te doen — anders dan rustig toe te kijken hoe alle anderen met hun rampen omgingen. Degenen die van poort wisselden hoefden geen grote puinhoop op te ruimen. Ze hoefden geen patches uit te voeren. Ze hadden geen uitgebuite servers. Eén verandering met minimale operationele impact en ze waren in staat om tonnen risico’s te vermijden.
Zeker andere mitigaties werken net zo goed, zoals het vereisen van een geldige VPN-verbinding voordat verbinding wordt gemaakt met de service, het vereisen van een combinatie van voorafgaande poortcontacten voordat de service wordt ingeschakeld, of het vereisen van succesvolle authenticatie voordat de service reageert (dit is de Fix It-oplossing van Microsoft), en al het andere dat je zou kunnen beschermen tegen bewapende aanvallen.
Maar ik kan geen andere eenvoudige beveiligingsoplossing bedenken die het risico zo effectief vermindert dan het veranderen van de standaard poort, indien mogelijk. Als u dit advies opvolgt, zet de poort dan op een vrij hoog nummer, boven de 10.000 of 12.000, om mogelijke poortconflicten met andere bestaande diensten te vermijden. Test alle productieapparatuur en werk eventueel benodigde firewalls of proxies bij. De lezers die dit advies in het verleden hebben opgevolgd, hebben deze week geen grote haast.