Förra Patch Tuesday släppte Microsoft säkerhetsuppdatering MS12-020 för att täppa till två nyligen upptäckta brister i Microsofts implementering av RDP (Remote Desktop Protocol). Den ena av dem betecknar Microsoft som ”kritisk” eftersom den skulle kunna göra det möjligt för hackare att få kontroll över LocalSystem på en Windows-box med RDP aktiverat.
Som du antagligen har hört vid det här laget är detta en högrisksituation – en situation som skulle kunna resultera i en lika allvarlig epidemi som den som orsakades av Code Red, Melissa eller SQL Slammer. Laga eller åtgärda nu!
Microsoft hjälper dig att göra både det ena och det andra. Du kan antingen installera patchen eller köra ett Fix It-skript online för att lindra problemet tills patchen har installerats. Skriptet aktiverar autentisering på nätverksnivå, vilket kräver autentisering innan ett fjärrsystem kan ansluta.
Men jag har ett annat råd. Som jag har rekommenderat i mer än ett decennium bör administratörer överväga att köra tjänster som kan anslutas till Internet på portar som inte är standardportar om det är möjligt. I det här fallet bör RDP köras på någon annan port än port 3389.
Detta råd gäller även andra områden. Adminwebbplatser bör inte köras på port 80 eller till och med 443. SSH bör inte lyssna på port 22. Telnetvärdar bör inte lyssna på port 23. Den enda utbredda vanliga tjänsten som jag inte har kunnat få tillförlitligt fungerande på en annan port än standardporten är FTP: Den använder portarna 21 och 22 (i passivt läge), och till och med dess aktiva läge (där du kan ange andra portar) fungerar inte bra genom brandväggar.
I RDP:s fall kan du ändra standardporten genom att följa denna vägledning. När du ändrar standardporten måste du dock ange den icke-standardiserade porten i anslutningssträngen (till exempel mstsc.exe 192.168.1.12:50045).
Min rekommendation att ändra den lyssnande standardporten i en tjänst som omfattar hela företaget möts ofta av kritik. Mitt centrala argument är följande: I de flesta fall kan ett företag ändra standardporten, vilket inte orsakar några problem utöver utbildning av administratörer och omkonfigurering av vissa skript och verktyg vid ett tillfälle, och det minskar avsevärt risken för vapenattacker.
Och även om hackare och skadlig kod kan använda en portscanner som Nmap för att hitta den nya porten, har inga vapenattacker någonsin gjort portscanning, även om de lätt skulle kunna göra det. Enbart det faktumet ger dig ett stort skydd.
Vissa personer kallar den här typen av rekommendationer för ”security by obscurity”, som om det vore en dålig sak. Om du frågar mig är ”security by obscurity” ett av de bästa försvaren. Annars skulle varje nation offentliggöra var dess missiler och atomubåtar fanns i stället för att hålla informationen hemlig.
För mig är SQL Slammer-masken ett av de bästa argumenten för att sätta vanliga tjänster på portar som inte är standardportar. Den släpptes 2003 och exploaterade på tio minuter nästan alla möjliga okontrollerade och oskyddade SQL-servrar som var anslutna till Internet. Den utlöstes tidigt en söndagsmorgon, och när de flesta administratörer hade vaknat hade skadorna uppstått i nästan en hel arbetsdag.
När vi hade torkat bort det krystade saltet ur ögonen var det över – sedan tillbringade vi de följande 48 timmarna (eller längre) med att försöka städa upp efter det som hänt. Det var en väckarklocka.
Ingen som hade aktiverat SQL på en annan port än standardporten (det vill säga en port förutom 1433 och 1434) behövde göra något — förutom att lugnt titta på hur alla andra hanterade sina katastrofer. De som bytte portar behövde inte städa upp en enorm röra. De behövde inte rusa ut med patchar. De hade inga exploaterade servrar. En förändring med minimal operativ påverkan och de kunde undvika massor av risker.
Säkerligen fungerar andra begränsningsåtgärder lika bra, t.ex. att kräva en giltig VPN-anslutning innan man ansluter till tjänsten, att kräva en kombination av tidigare portkontakter innan man aktiverar tjänsten, eller att kräva framgångsrik autentisering innan tjänsten svarar (det här är Microsofts Fix It-lösning), och allt annat som kan skydda dig mot vapenattacker.
Men jag kan inte komma på någon annan enkel säkerhetslösning som minskar risken så effektivt som att ändra standardporten, när det är möjligt. Om du följer detta råd bör du flytta porten till ett ganska högt nummer, över 10 000 eller 12 000, för att undvika eventuella portkonflikter med andra befintliga tjänster. Testa all produktionsutrustning och uppdatera eventuella brandväggar eller proxies. De läsare som följde detta råd tidigare har inte så bråttom den här veckan.