ProHoster > Er det farlig Ä ha RDP Äpent pÄ Internett?

Er det farlig Ä ha RDP Äpent pÄ Internett?

Jeg har ofte lest meninger om at det Ä ha RDP (Remote Desktop Protocol) porten Äpen pÄ Internett er veldig usikkert, og at man ikke bÞr gjÞre det. Man bÞr gi tilgang til RDP enten via VPN, eller kun fra bestemte "hvite" IP-adresser.

Jeg administrerer flere Windows Servere for smĂ„ bedrifter, der jeg har fĂ„tt i oppdrag Ă„ sikre fjernadgang til Windows Server for regnskapsfĂžrere. Dette er en moderne trend – Ă„ jobbe hjemmefra. Jeg innsĂ„ ganske raskt at det Ă„ plage regnskapsfĂžrerne med VPN var en utakknemlig oppgave, og det ville ikke vĂŠre mulig Ă„ samle alle IP-adressene for hvitelisten, fordi folk har dynamiske IP-adresser.

Derfor valgte jeg den enkleste lĂžsningen – jeg eksponerte RDP-porten utad. NĂ„ trenger regnskapsfĂžrerne bare Ă„ starte RDP og angi vertsnavn (inkludert port), brukernavn og passord.

I denne artikkelen vil jeg dele erfaringene mine (bÄde positive og negative) samt noen anbefalinger.

Risikoer

Hva risikerer du ved Ă„ Ă„pne RDP-porten?

1) Uautorisert tilgang til sensitive data
Hvis noen klarer Ä gjette RDP-passordet, kan de fÄ tilgang til dataene du Þnsker Ä holde private: kontosaldoer, balanser, kundedata, 


2) Datatap
For eksempel som fĂžlge av en ransomware-virus.
Eller som et resultat av en ondsinnet aktĂžrs handlinger.

3) Tap av arbeidsstasjon
Ansatte mÄ jobbe, men systemet har blitt kompromittert, og det mÄ installeres pÄ nytt / gjenopprettes / konfigureres.

4) Kompromittering av lokalt nettverk
Hvis en angriper fÄr tilgang til en Windows-datamaskin, kan de allerede fra denne datamaskinen fÄ tilgang til systemer som er utilgjengelige utenfra, fra Internett. For eksempel filshares, nettverks skrivere osv.

Jeg har hatt et tilfelle der en Windows Server ble rammet av ransomware

og denne ransomware fÞrst krypterte de fleste filene pÄ disk C:, fÞr den begynte Ä kryptere filer pÄ NAS-en over nettverket. Siden NAS-en er en Synology med innstilte snapshots, kunne jeg gjenopprette NAS-en pÄ 5 minutter, mens Windows Server mÄtte jeg installere pÄ nytt fra bunnen av.

Observasjoner og Anbefalinger

Jeg overvÄker Windows Servere ved hjelp av Winlogbeat, som sender logger til ElasticSearch. I Kibana finnes det flere visualiseringer, og jeg har ogsÄ satt opp en tilpasset dashbord.
Selve overvÄkingen beskytter ikke, men hjelper med Ä bestemme nÞdvendige tiltak.

Her er noen observasjoner:
a) RDP vil bli bruteforst.
PĂ„ en av serverne mine har jeg satt RDP til Ă„ bruke en annen port enn standard 3389, pĂ„ 443 – som om jeg prĂžver Ă„ maskere det som HTTPS. Å endre standardporten er sikkert en god idĂ©, men det gir ikke sĂ„ mye mening. Her er statistikken fra denne serveren:

Er det farlig Ä ha RDP Äpent pÄ Internett?

Det er tydelig at det har vÊrt nesten 400 000 mislykkede forsÞk pÄ Ä fÄ tilgang via RDP i lÞpet av uken.
Det er Äpenbart at det har vÊrt forsÞk pÄ Ä fÄ tilgang fra 55 001 IP-adresser (noen av IP-adressene har jeg allerede blokkert).

Det gir en klar indikasjon pÄ at jeg bÞr installere fail2ban, men

for Windows finnes det ingen slik verktĂžy.

Det er et par forlatt prosjekter pÄ GitHub som ser ut til Ä gjÞre dette, men jeg har ikke engang prÞvd Ä installere dem:
https://github.com/glasnt/wail2ban
https://github.com/EvanAnderson/ts_block

Det finnes ogsÄ betalte verktÞy, men jeg har ikke vurdert dem.

Hvis du kjenner til et Ă„pent verktĂžy for dette formĂ„let – del det i kommentarene.

Update: I kommentarene ble det pÄpekt at port 443 ikke er et godt valg, og det er bedre Ä velge hÞye porter (32000+), fordi 443 skannes oftere, og Ä gjenkjenne RDP pÄ denne porten er ikke noe problem.

Oppdatering: I kommentarene ble det pÄpekt at det finnes et slikt verktÞy:
https://github.com/digitalruby/ipban

b) Det finnes spesifikke brukernavn som angripere foretrekker.
Det er tydelig at angrepene skjer ved Ă„ bruke ordbĂžker med forskjellige navn.
Det jeg la merke til, er at et betydelig antall forsÞk bruker servernavnet som brukernavn. Anbefalingen: bruk ikke samme navn for datamaskinen og brukeren. Dessuten ser det ut til at det noen ganger forsÞkes Ä parsette navn pÄ serveren: for eksempel for et system med navnet DESKTOP-DFTHD7C er det flest forsÞk med navnet DFTHD7C:

Er det farlig Ä ha RDP Äpent pÄ Internett?

Derfor, hvis du har en datamaskin som heter DESKTOP-MARIA, vil det sannsynligvis vÊre forsÞk pÄ Ä logge inn som brukeren MARIA.

En annen ting jeg la merke til fra loggene: pĂ„ de fleste systemene er de fleste forsĂžkene med navnet "administrator". Og dette er ikke uten grunn, ettersom denne brukeren finnes i mange versjoner av Windows. Dessuten – du kan ikke slette den. Dette forenkler oppgaven for angriperne: i stedet for Ă„ mĂ„tte gjette bĂ„de navnet og passordet, trenger de bare Ă„ gjette passordet.
Forresten, systemet mitt som ble rammet av ransomware hadde brukeren Administrator og passordet Murmansk#9. Jeg er fortsatt ikke sikker pĂ„ hvordan de klarte Ă„ bryte seg inn i det systemet, fordi jeg begynte Ă„ overvĂ„ke etter at den hendelsen fant sted, men jeg tror at det var et gjentatt angrep – det er sannsynlig.
SĂ„, hvis brukeren Administrator ikke kan slettes, hva kan man gjĂžre? Man kan endre navn!

Anbefalingene fra dette punktet:

  • bruk ikke brukernavnet i datamaskinens navn
  • SĂžrg for at systemet ikke har brugeren Administrator.
  • Brug sikre adgangskoder.

PÄ denne mÄde har jeg observeret, at flere Windows Servere under min kontrol er blevet brute-forced i et par Är nu, uden held.

Hvordan ved jeg, at det er uden held?
Fordi det fremgÄr af skÊrmbillederne ovenfor, at der er logfiler med succesfulde RDP-login, der indeholder information:

  • fra hvilken IP
  • fra hvilken computer (hostname)
  • brugernavn
  • GeoIP-information

Og jeg tjekker regelméssigt — ingen anomalier blevet opdaget.

For resten, hvis et sÊrligt ihÊrdigt brute-force-angreb kommer fra en bestemt IP, kan du blokere enkelt IP'er (eller subnet) pÄ denne mÄde 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 Block

For resten, Elastic har, udover Winlogbeat, ogsĂ„ Auditbeat, som kan overvĂ„ge filer og processer pĂ„ systemet. Der er ogsĂ„ en SIEM (Security Information & Event Management) applikation i Kibana. Jeg har prĂžvet begge dele, men sĂ„ ikke meget nytte i det — det ser ud til, at Auditbeat vil vĂŠre mere nyttigt for Linux-systemer, mens SIEM endnu ikke har vist mig noget substantielt.

Og de sidste anbefalinger:

  • lav regelmĂŠssige automatiske backups.
  • opdater Security Updates rettidigt.

Bonus: liste over 50 brugere, der oftest blev brugt til at forsĂžge at logge ind via RDP.

"user.name: Descending"
Antal

dfthd7c (hostname)
842941

winsrv1 (hostname)
266525

ADMINISTRATOR
180678

administratoren
163842

Administrator
53541

michael
23101

server
21983

steve
21936

john
21927

paul
21913

reception
21909

mike
21899

office
21888

scanner
21887

scan
21867

david
21865

chris
21860

owner
21855

manager
21852

administrateur
21841

brian
21839

administrador
21837

mark
21824

staff
21806

ADMIN
12748

ROOT
7772

ADMINISTRADOR
7325

SUPPORT
5577

SOPORTE
5418

BRUKAR
4558

-e pÄ serveren hvor prosjektets depot er plassert. FÞrst mÄ det tas en backup av depotet.
2832

TEST
1928

MySql
1664

Admin
1652

GUEST
1322

USER1
1179

SCANNER
1121

SCAN
1032

ADMINISTRATEUR
842

ADMIN1
525

BACKUP
518

MySqlAdmin
518

RECEPTION
490

USER2
466

TEMP
452

SQLADMIN
450

USER3
441

1
422

MANAGER
418

OWNER
410

Kilde: habr.com

KjĂžp pĂ„litelig hosting for nettsteder med DDoS-beskyttelse, VPS VDS-servere đŸ”„ KjĂžp pĂ„litelig hosting for nettsteder med DDoS-beskyttelse, VPS VDS-servere | ProHoster