Ik haw faak lêzen de miening dat it hâlden fan in RDP (Remote Desktop Protocol) haven iepen foar it ynternet is hiel ûnfeilich en moat net dien wurde. Mar jo moatte tagong jaan ta RDP fia in VPN, of allinich fan bepaalde "wite" IP-adressen.
Ik administrearje ferskate Windows-tsjinners foar lytse bedriuwen wêr't ik de opdracht krige om tagong op ôfstân te jaan oan Windows Server foar accountants. Dit is de moderne trend - thús wurkje. Hiel fluch realisearre ik dat it tormentearjen fan VPN-accountants in ûndankbere taak is, en it sammeljen fan alle IP's foar de wite list sil net wurkje, om't de IP-adressen fan minsken dynamysk binne.
Dêrom naam ik de ienfâldichste rûte - stjoerde de RDP-poarte nei bûten. Om tagong te krijen, moatte accountants no RDP útfiere en de hostnamme (ynklusyf poarte), brûkersnamme en wachtwurd ynfiere.
Yn dit artikel sil ik myn ûnderfining (posityf en net sa posityf) en oanbefellings diele.
Risiken
Wat riskearje jo troch de RDP-poarte te iepenjen?
1) Unautorisearre tagong ta gefoelige gegevens
As immen it RDP-wachtwurd riedt, kinne se gegevens krije dy't jo privee wolle hâlde: akkountstatus, saldo, klantgegevens, ...
2) Data ferlies
Bygelyks as gefolch fan in ransomware-firus.
Of in opsetlike aksje fan in oanfaller.
3) Ferlies fan wurkstasjonStencils
Arbeiders moatte wurkje, mar it systeem is kompromittearre en moat opnij ynstalleare / restaurearre / konfigureare.
4) Kompromis fan it lokale netwurk
As in oanfaller tagong hat ta in Windows-kompjûter, dan sil hy fan dizze kompjûter tagong krije ta systemen dy't fan bûten net tagonklik binne, fan it ynternet. Bygelyks om dielen te bestân, nei netwurkprinters, ensfh.
Ik hie in gefal wêr't Windows Server in ransomware fong
en dizze ransomware fersifere earst de measte bestannen op it C:-stasjon en begon doe de bestannen op 'e NAS te fersiferjen oer it netwurk. Sûnt de NAS wie Synology, mei snapshots konfigureare, haw ik de NAS yn 5 minuten werombrocht, en Windows Server fanôf it begjin opnij ynstalleare.
Observaasjes en oanbefellings
Ik monitor Windows Servers mei help , dy't logs nei ElasticSearch stjoere. Kibana hat ferskate fisualisaasjes, en ik sette ek in oanpaste dashboard.
Monitoring sels beskermet net, mar it helpt om de nedige maatregels te bepalen.
Hjir binne wat observaasjes:
a) RDP sil brute twongen wurde.
Op ien fan 'e servers haw ik RDP net ynstalleare op' e standert poarte 3389, mar op 443 - goed, ik sil mysels ferklaaie as HTTPS. It is wierskynlik de muoite wurdich om de haven te feroarjen fan 'e standert, mar it sil net folle goed dwaan. Hjir binne de statistiken fan dizze tsjinner:
It kin sjoen wurde dat der yn in wike hast 400 mislearre besykjen wiene om yn te loggen fia RDP.
It kin sjoen wurde dat der besocht binne om oan te melden fan 55 IP-adressen (guon IP-adressen wiene al troch my blokkearre).
Dit suggerearret direkt de konklúzje dat jo moatte ynstelle fail2ban, mar
D'r is gjin sa'n nut foar Windows.
D'r binne in pear ferlitten projekten op Github dy't dit lykje te dwaan, mar ik haw net iens besocht se te ynstallearjen:
Der binne ek betelle nutsbedriuwen, mar ik haw net beskôge se.
As jo in iepen boarne-hulpprogramma foar dit doel kenne, diel it dan asjebleaft yn 'e kommentaren.
Update: De opmerkingen suggerearre dat haven 443 is in min kar, en it is better om te kiezen hege havens (32000+), omdat 443 wurdt skansearre faker, en werkennen RDP op dizze haven is gjin probleem.
b) D'r binne bepaalde brûkersnammen dy't oanfallers leaver hawwe
It is te sjen dat it sykjen útfierd wurdt yn in wurdboek mei ferskillende nammen.
Mar hjir is wat ik opfallen: in signifikant oantal pogingen brûke de servernamme as oanmelding. Oanbefelling: Brûk net deselde namme foar de kompjûter en de brûker. Boppedat liket it soms oft se besykje de servernamme op ien of oare manier te parsearjen: bygelyks foar in systeem mei de namme DESKTOP-DFTHD7C binne de measte pogingen om oan te melden mei de namme DFTHD7C:
Dêrom, as jo in DESKTOP-MARIA-kompjûter hawwe, sille jo wierskynlik besykje oan te melden as de MARIA-brûker.
In oar ding dat ik opmurken fan 'e logs: op de measte systemen binne de measte pogingen om oan te melden mei de namme "administrator". En dit is net sûnder reden, want yn in protte ferzjes fan Windows bestiet dizze brûker. Boppedat kin it net wiske wurde. Dit ferienfâldigt de taak foar oanfallers: ynstee fan in namme en wachtwurd te rieden, hoege jo allinich it wachtwurd te rieden.
Trouwens, it systeem dat de ransomware fong hie de brûker Behearder en it wachtwurd Murmansk#9. Ik bin noch altyd net wis hoe't dat systeem hacked is, om't ik krekt nei dat ynsidint begon te kontrolearjen, mar ik tink dat it oerkill wierskynlik is.
Dus as de behearder-brûker net kin wurde wiske, wat moatte jo dan dwaan? Jo kinne it omneame!
Oanbefellings út dizze paragraaf:
- brûk de brûkersnamme net yn 'e kompjûternamme
- soargje derfoar dat der gjin administrator brûker op it systeem
- brûke sterke wachtwurden
Dat, ik haw sjoen nei ferskate Windows Servers ûnder myn kontrôle wurde brute-forced foar sawat in pear jier no, en sûnder sukses.
Hoe wit ik dat it net slagge is?
Om't yn 'e skermôfbyldings hjirboppe kinne jo sjen dat d'r logs binne fan suksesfolle RDP-oproppen, dy't de ynformaasje befetsje:
- fan hokker IP
- fan hokker kompjûter (hostnamme)
- Brûkersnamme
- GeoIP ynformaasje
En ik kontrolearje dêr geregeld - gjin anomalies binne fûn.
Trouwens, as in bepaalde IP benammen hurd wurdt twongen, dan kinne jo yndividuele IP's (as subnets) blokkearje lykas dit yn 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 BlockTroch de wei, Elastic, neist Winlogbeat, hat ek , dy't bestannen en prosessen op it systeem kontrolearje kin. D'r is ek in SIEM-applikaasje (Security Information & Event Management) yn Kibana. Ik besocht beide, mar seach net folle foardiel - it liket derop dat Auditbeat brûkberder sil wêze foar Linux-systemen, en SIEM hat my noch neat fersteanber sjen litten.
No, lêste oanbefellings:
- Meitsje regelmjittige automatyske backups.
- ynstallearje befeiligingsupdates op 'e tiid
Bonus: list mei 50 brûkers dy't it meast waarden brûkt foar RDP-oanmeldepogingen
"user.name: Descending"
Telle
dfthd7c (hostnamme)
842941
winsrv1 (hostnamme)
266525
ADMINISTRATOR
180678
administrator
163842
behearder
53541
michael
23101
tsjinner
21983
steve
21936
john
21927
paul
21913
resepsje
21909
mike
21899
kantoar
21888
scanner
21887
scan
21867
david
21865
chris
21860
eigner
21855
behearder
21852
behearder
21841
brian
21839
administrator
21837
merk
21824
personiel
21806
ADMIN
12748
root
7772
ADMINISTRATOR
7325
STYPJE
5577
SUPPORT
5418
BRÛKER
4558
admin
2832
TOETS
1928
mysql
1664
admin
1652
GAST
1322
GEBRUIKER1
1179
TO SCAN
1121
SCAN
1032
ADMINISTRATOR
842
ADMIN1
525
BACKUP
518
MySqlAdmin
518
RESEPSJE
490
GEBRUIKER2
466
TEMP
452
SQLADMIN
450
GEBRUIKER3
441
1
422
BEHEARDER
418
EIGNER
410
Boarne: www.habr.com