Jag har ofta läst åsikten att det är väldigt osäkert att hålla en RDP-port (Remote Desktop Protocol) öppen till Internet och inte bör göras. Men du måste ge åtkomst till RDP antingen via ett VPN eller bara från vissa "vita" IP-adresser.
Jag administrerar flera Windows-servrar för små företag där jag har fått i uppdrag att tillhandahålla fjärråtkomst till Windows Server för revisorer. Detta är den moderna trenden - att arbeta hemifrån. Ganska snabbt insåg jag att att plåga VPN-revisorer är en otacksam uppgift, och att samla in alla IP-adresser för den vita listan kommer inte att fungera, eftersom människors IP-adresser är dynamiska.
Därför tog jag den enklaste vägen - vidarebefordrade RDP-porten till utsidan. För att få åtkomst måste revisorer nu köra RDP och ange värdnamnet (inklusive port), användarnamn och lösenord.
I den här artikeln kommer jag att dela med mig av mina erfarenheter (positiva och inte så positiva) och rekommendationer.
Risker
Vad riskerar du genom att öppna RDP-porten?
1) Obehörig åtkomst till känsliga uppgifter
Om någon gissar RDP-lösenordet kommer de att kunna få data som du vill hålla privat: kontostatus, saldon, kunddata, ...
2) Dataförlust
Till exempel som ett resultat av ett ransomware-virus.
Eller en avsiktlig handling av en angripare.
3) Förlust av arbetsstation
Arbetare måste arbeta, men systemet har äventyrats och måste installeras om/återställas/konfigureras.
4) Kompromiss av det lokala nätverket
Om en angripare har fått tillgång till en Windows-dator, kommer han från denna dator att kunna komma åt system som är otillgängliga utifrån, från Internet. Till exempel för filresurser, till nätverksskrivare, etc.
Jag hade ett fall där Windows Server fångade ett ransomware
och denna ransomware krypterade först de flesta filerna på C:-enheten och började sedan kryptera filerna på NAS:en över nätverket. Eftersom NAS var Synology, med ögonblicksbilder konfigurerade, återställde jag NAS:n på 5 minuter och installerade om Windows Server från början.
Observationer och rekommendationer
Jag övervakar Windows-servrar med hjälp av , som skickar loggar till ElasticSearch. Kibana har flera visualiseringar, och jag har även satt upp en anpassad instrumentpanel.
Övervakning i sig skyddar inte, men det hjälper till att fastställa nödvändiga åtgärder.
Här är några observationer:
a) RDP kommer att vara brutalt forcerat.
På en av servrarna installerade jag RDP inte på standardporten 3389, utan på 443 - ja, jag kommer att maskera mig som HTTPS. Det är förmodligen värt att byta port från standarden, men det kommer inte att göra mycket nytta. Här är statistiken från denna server:
Man kan se att det på en vecka gjordes nästan 400 000 misslyckade försök att logga in via RDP.
Det kan ses att det gjordes försök att logga in från 55 001 IP-adresser (vissa IP-adresser var redan blockerade av mig).
Detta antyder direkt slutsatsen att du måste ställa in fail2ban, men
Det finns inget sådant verktyg för Windows.
Det finns ett par övergivna projekt på Github som verkar göra detta, men jag har inte ens försökt installera dem:
Det finns också betalda verktyg, men jag har inte övervägt dem.
Om du känner till ett verktyg med öppen källkod för detta ändamål, vänligen dela det i kommentarerna.
Uppdatering: Kommentarerna antydde att port 443 är ett dåligt val, och det är bättre att välja höga portar (32000+), eftersom 443 skannas oftare, och att känna igen RDP på denna port är inte ett problem.
b) Det finns vissa användarnamn som angripare föredrar
Det kan ses att sökningen görs i en ordbok med olika namn.
Men här är vad jag märkte: ett betydande antal försök använder servernamnet som inloggning. Rekommendation: Använd inte samma namn för datorn och användaren. Dessutom ser det ibland ut som att de försöker analysera servernamnet på något sätt: till exempel, för ett system med namnet DESKTOP-DFTHD7C, är de flesta försöken att logga in med namnet DFTHD7C:
Följaktligen, om du har en DESKTOP-MARIA-dator, kommer du förmodligen att försöka logga in som MARIA-användare.
En annan sak jag noterade från loggarna: på de flesta system görs de flesta försök att logga in med namnet "administratör". Och detta är inte utan anledning, för i många versioner av Windows finns den här användaren. Dessutom kan den inte raderas. Detta förenklar uppgiften för angripare: istället för att gissa ett namn och lösenord behöver du bara gissa lösenordet.
Förresten, systemet som fångade ransomwaren hade användaren Administrator och lösenordet Murmansk#9. Jag är fortfarande inte säker på hur det systemet hackades, eftersom jag började övervaka precis efter den incidenten, men jag tror att det är troligt att det är överdrivet.
Så om administratörsanvändaren inte kan raderas, vad ska du då göra? Du kan byta namn på den!
Rekommendationer från denna paragraf:
- använd inte användarnamnet i datornamnet
- se till att det inte finns någon administratörsanvändare på systemet
- använd starka lösenord
Så jag har sett flera Windows-servrar under min kontroll bli brute-forced i ungefär ett par år nu, och utan framgång.
Hur vet jag att det är misslyckat?
För i skärmdumparna ovan kan du se att det finns loggar över lyckade RDP-samtal, som innehåller informationen:
- från vilken IP
- från vilken dator (värdnamn)
- Användarnamn
- GeoIP-information
Och jag kollar där regelbundet - inga anomalier har hittats.
Förresten, om en viss IP är brute-forced särskilt hårt, då kan du blockera individuella IP:er (eller subnät) så här i PowerShell:
New-NetFirewallRule -Direction Inbound -DisplayName "fail2ban" -Name "fail2ban" -RemoteAddress ("185.143.0.0/16", "185.153.0.0/16", "193.188.0.0/16") -Action BlockElastic har förresten, förutom Winlogbeat, också , som kan övervaka filer och processer på systemet. Det finns också en SIEM-applikation (Security Information & Event Management) i Kibana. Jag försökte båda, men såg inte mycket nytta - det ser ut som att Auditbeat kommer att vara mer användbart för Linux-system, och SIEM har inte visat mig något begripligt än.
Tja, sista rekommendationer:
- Gör regelbundna automatiska säkerhetskopior.
- installera säkerhetsuppdateringar i tid
Bonus: lista över 50 användare som oftast användes för RDP-inloggningsförsök
"user.name: Fallande"
Att Räkna
dfthd7c (värdnamn)
842941
winsrv1 (värdnamn)
266525
ADMINISTRATÖR
180678
administratör
163842
Administratör
53541
michael
23101
server
21983
steve
21936
john
21927
paul
21913
mottagning
21909
Mike
21899
KONTOR
21888
Skannern
21887
scanna
21867
David
21865
chris
21860
ägaren
21855
chef
21852
administrateur
21841
brian
21839
administratör
21837
markera
21824
personal
21806
ADMINISTRATION
12748
ROT
7772
ADMINISTRATÖR
7325
STÖD
5577
STÖD
5418
ANVÄNDARE
4558
administration
2832
TEST
1928
MySql
1664
Administration
1652
GÄST
1322
ANVÄNDAR1
1179
ATT SKANNA
1121
SCAN
1032
ADMINISTRATÖR
842
ADMIN1
525
KOPIA
518
MySqlAdmin
518
RECEPTION
490
ANVÄNDAR2
466
TEMP
452
SQLADMIN
450
ANVÄNDAR3
441
1
422
CHEF
418
ÄGARE
410
Källa: will.com