Ik heb vaak de mening gelezen dat het openhouden van een RDP-poort (Remote Desktop Protocol) voor internet zeer onveilig is en niet mag worden gedaan. Maar u moet toegang tot RDP geven via een VPN, of alleen vanaf bepaalde ‘witte’ IP-adressen.
Ik beheer verschillende Windows-servers voor kleine bedrijven waar ik de taak heb om externe toegang tot Windows Server voor accountants te bieden. Dit is de moderne trend: thuiswerken. Al snel besefte ik dat het kwellen van VPN-accountants een ondankbare taak is, en dat het verzamelen van alle IP-adressen voor de witte lijst niet zal werken, omdat de IP-adressen van mensen dynamisch zijn.
Daarom nam ik de eenvoudigste route: stuurde de RDP-poort naar buiten. Om toegang te krijgen, moeten accountants nu RDP uitvoeren en de hostnaam (inclusief poort), gebruikersnaam en wachtwoord invoeren.
In dit artikel deel ik mijn ervaringen (positief en niet zo positief) en aanbevelingen.
Risico's
Wat riskeert u door de RDP-poort te openen?
1) Ongeautoriseerde toegang tot gevoelige gegevens
Als iemand het RDP-wachtwoord raadt, kan hij of zij gegevens verkrijgen die u privé wilt houden: rekeningstatus, saldi, klantgegevens, ...
2) Gegevensverlies
Bijvoorbeeld als gevolg van een ransomware-virus.
Of een opzettelijke actie van een aanvaller.
3) Verlies van werkstation
Werknemers moeten werken, maar het systeem is gecompromitteerd en moet opnieuw worden geïnstalleerd/hersteld/geconfigureerd.
4) Compromis van het lokale netwerk
Als een aanvaller toegang heeft gekregen tot een Windows-computer, kan hij vanaf deze computer toegang krijgen tot systemen die van buitenaf, vanaf internet, niet toegankelijk zijn. Bijvoorbeeld voor bestandsshares, netwerkprinters, enz.
Ik had een geval waarin Windows Server een ransomware opmerkte
en deze ransomware versleutelde eerst de meeste bestanden op de C:-schijf en begon vervolgens de bestanden op de NAS via het netwerk te versleutelen. Omdat de NAS van Synology was, met geconfigureerde snapshots, heb ik de NAS in 5 minuten hersteld en Windows Server helemaal opnieuw geïnstalleerd.
Observaties en aanbevelingen
Ik monitor Windows-servers met behulp van , die logboeken naar ElasticSearch verzenden. Kibana heeft verschillende visualisaties en ik heb ook een dashboard op maat opgezet.
Monitoring zelf biedt geen bescherming, maar helpt wel bij het bepalen van de noodzakelijke maatregelen.
Hier zijn enkele observaties:
a) RDP zal brutaal zijn.
Op een van de servers heb ik RDP niet op de standaardpoort 3389 geïnstalleerd, maar op 443 - nou, ik zal mezelf vermommen als HTTPS. Het is waarschijnlijk de moeite waard om de poort te veranderen van de standaardpoort, maar het zal niet veel goeds opleveren. Hier zijn de statistieken van deze server:
Te zien is dat er in een week tijd bijna 400 mislukte pogingen waren om in te loggen via RDP.
Te zien is dat er pogingen zijn gedaan om in te loggen vanaf 55 IP-adressen (sommige IP-adressen waren al door mij geblokkeerd).
Dit suggereert direct de conclusie dat u fail2ban moet instellen, maar
Er bestaat niet zo'n hulpprogramma voor Windows.
Er zijn een paar verlaten projecten op Github die dit lijken te doen, maar ik heb niet eens geprobeerd ze te installeren:
Er zijn ook betaalde hulpprogramma's, maar daar heb ik nog niet over nagedacht.
Als u een open source-hulpprogramma voor dit doel kent, deel dit dan in de reacties.
bijwerken: Uit de opmerkingen blijkt dat poort 443 een slechte keuze is, en dat het beter is om hoge poorten te kiezen (32000+), omdat 443 vaker wordt gescand en het herkennen van RDP op deze poort geen probleem is.
b) Er zijn bepaalde gebruikersnamen waar aanvallers de voorkeur aan geven
Het is te zien dat de zoekopdracht wordt uitgevoerd in een woordenboek met verschillende namen.
Maar dit is wat mij opviel: een aanzienlijk aantal pogingen gebruikt de servernaam als login. Aanbeveling: Gebruik niet dezelfde naam voor de computer en de gebruiker. Bovendien lijkt het er soms op dat ze op de een of andere manier de servernaam proberen te ontleden: voor een systeem met de naam DESKTOP-DFTHD7C zijn de meeste pogingen om in te loggen bijvoorbeeld met de naam DFTHD7C:
Als u een DESKTOP-MARIA-computer heeft, probeert u waarschijnlijk in te loggen als de MARIA-gebruiker.
Iets anders wat mij opviel uit de logs: op de meeste systemen worden de meeste pogingen om in te loggen gedaan met de naam “administrator”. En dit is niet zonder reden, want in veel versies van Windows bestaat deze gebruiker. Bovendien kan het niet worden verwijderd. Dit vereenvoudigt de taak voor aanvallers: in plaats van een naam en wachtwoord te raden, hoeft u alleen maar het wachtwoord te raden.
Het systeem dat de ransomware onderschepte had trouwens de gebruiker Administrator en het wachtwoord Moermansk#9. Ik weet nog steeds niet zeker hoe dat systeem is gehackt, omdat ik vlak na dat incident ben begonnen met monitoren, maar ik denk dat overkill waarschijnlijk is.
Dus als de Administrator-gebruiker niet kan worden verwijderd, wat moet u dan doen? Je kunt de naam wijzigen!
Aanbevelingen uit deze paragraaf:
- gebruik de gebruikersnaam niet in de computernaam
- Zorg ervoor dat er geen beheerder op het systeem aanwezig is
- gebruik sterke wachtwoorden
Ik heb dus al een paar jaar verschillende Windows-servers onder mijn controle zien bruut worden uitgevoerd, en zonder succes.
Hoe weet ik dat het niet lukt?
Omdat je in de bovenstaande schermafbeeldingen kunt zien dat er logs zijn van succesvolle RDP-oproepen, die de informatie bevatten:
- vanaf welk IP
- vanaf welke computer (hostnaam)
- gebruikersnaam
- GeoIP-informatie
En ik controleer daar regelmatig - er zijn geen afwijkingen gevonden.
Trouwens, als een bepaald IP-adres bijzonder hard wordt geforceerd, dan kun je individuele IP's (of subnetten) als volgt blokkeren in 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 BlockTrouwens, Elastic heeft dat, naast Winlogbeat, ook , waarmee bestanden en processen op het systeem kunnen worden bewaakt. Er is ook een SIEM-applicatie (Security Information & Event Management) in Kibana. Ik heb beide geprobeerd, maar zag niet veel voordeel - het lijkt erop dat Auditbeat nuttiger zal zijn voor Linux-systemen, en SIEM heeft me nog niets begrijpelijks laten zien.
Nou ja, laatste aanbevelingen:
- Maak regelmatig automatische back-ups.
- Installeer tijdig beveiligingsupdates
Bonus: lijst met 50 gebruikers die het vaakst werden gebruikt voor RDP-inlogpogingen
"gebruikersnaam: aflopend"
Tellen
dfthd7c (hostnaam)
842941
winsrv1 (hostnaam)
266525
ADMINISTRATOR
180678
administrateur
163842
Beheerder
53541
michael
23101
server
21983
steve
21936
John
21927
paul
21913
receptie
21909
Mike
21899
kantoor
21888
scanner
21887
aftasten
21867
david
21865
chris
21860
eigenaar
21855
manager
21852
administrateur
21841
brian
21839
administrateur
21837
Mark
21824
personeel
21806
BEHEERDER
12748
ROOT
7772
BEHEERDER
7325
ONDERSTEUNING
5577
SOPORTE
5418
GEBRUIKER
4558
beheerder
2832
TEST
1928
MySql
1664
beheerder
1652
GUEST
1322
GEBRUIKER 1
1179
SCANNER
1121
SCAN
1032
BEHEERDER
842
BEHEERDER1
525
BACK-UP
518
MijnSqlAdmin
518
RECEPTIE
490
GEBRUIKER 2
466
TEMP
452
SQLADMIN
450
GEBRUIKER 3
441
1
422
MANAGER
418
EIGENAAR
410
Bron: www.habr.com