Veszélyes az RDP nyitva tartása az interneten?

Gyakran olvastam azt a véleményt, hogy egy RDP (Remote Desktop Protocol) port nyitva tartása az internet felé nagyon nem biztonságos, és ezt nem szabad megtenni. De hozzáférést kell biztosítania az RDP-hez VPN-en keresztül, vagy csak bizonyos „fehér” IP-címekről.

Számos Windows Servert adminisztrálok olyan kis cégek számára, ahol a könyvelők számára a Windows Server távoli elérését kaptam. Ez a modern trend – otthonról történő munkavégzés. Nagyon gyorsan rájöttem, hogy a VPN-könyvelők gyötrelme hálátlan feladat, és az összes IP-cím összegyűjtése a fehérlistára nem fog működni, mert az emberek IP-címei dinamikusak.

Ezért a legegyszerűbb útvonalat választottam - továbbítottam az RDP-portot kifelé. A hozzáféréshez a könyvelőknek most le kell futtatniuk az RDP-t, és meg kell adniuk a gazdagépnevet (beleértve a portot), a felhasználónevet és a jelszót.

Ebben a cikkben megosztom tapasztalataimat (pozitív és nem túl pozitív) és ajánlásokat.

Kockázatok

Mit kockáztat az RDP port megnyitásával?

1) Az érzékeny adatokhoz való jogosulatlan hozzáférés
Ha valaki kitalálja az RDP jelszavát, akkor hozzájuthat olyan adatokhoz, amelyeket privátként szeretne megőrizni: számlaállapot, egyenlegek, ügyféladatok, ...

2) Adatvesztés
Például egy ransomware vírus eredményeként.
Vagy egy támadó szándékos cselekedete.

3) Munkaállomás elvesztése
A dolgozóknak dolgozniuk kell, de a rendszer veszélybe került, és újra kell telepíteni/visszaállítani/konfigurálni.

4) A helyi hálózat kompromittálása
Ha egy támadó hozzáfért egy Windows számítógéphez, akkor erről a számítógépről hozzáférhet olyan rendszerekhez, amelyek kívülről, az internetről nem érhetők el. Például fájlmegosztásokhoz, hálózati nyomtatókhoz stb.

Volt egy esetem, amikor a Windows Server elkapott egy zsarolóprogramot

és ez a zsarolóprogram először titkosította a legtöbb fájlt a C: meghajtón, majd elkezdte titkosítani a NAS-on lévő fájlokat a hálózaton keresztül. Mivel a NAS a Synology volt, konfigurált pillanatképekkel, 5 perc alatt visszaállítottam a NAS-t, és a semmiből újratelepítettem a Windows Servert.

Észrevételek és ajánlások

Windows Servereket figyelek a segítségével Winlogbeat, amelyek naplókat küldenek az ElasticSearch-nek. A Kibanának számos vizualizációja van, és beállítottam egy egyéni műszerfalat is.
A monitorozás önmagában nem véd, de segít meghatározni a szükséges intézkedéseket.

Íme néhány megfigyelés:
a) Az RDP brutális kényszer lesz.
Az egyik szerveren az RDP-t nem a szabványos 3389-es, hanem a 443-as portra telepítettem - hát, HTTPS-nek álcázom magam. Valószínűleg érdemes lecserélni a portot a szabványosról, de nem sok jót tesz. Íme a statisztika erről a szerverről:

Veszélyes az RDP nyitva tartása az interneten?

Látható, hogy egy hét alatt közel 400 000 sikertelen bejelentkezési kísérlet történt RDP-n keresztül.
Látható, hogy 55 001 IP címről próbáltak bejelentkezni (néhány IP címet már letiltottam).

Ez közvetlenül arra a következtetésre utal, hogy be kell állítania a fail2ban-t, de

Windowshoz nincs ilyen segédprogram.

Úgy tűnik, van néhány elhagyott projekt a Githubon, de még meg sem próbáltam telepíteni őket:
https://github.com/glasnt/wail2ban
https://github.com/EvanAnderson/ts_block

Vannak fizetős rezsi is, de ezeket nem vettem figyelembe.

Ha ismer egy nyílt forráskódú segédprogramot erre a célra, kérjük, ossza meg a megjegyzésekben.

Frissítések: A kommentek azt sugallták, hogy a 443-as port rossz választás, és érdemesebb a magas portokat választani (32000+), mert a 443-at gyakrabban vizsgálják, és ezen a porton az RDP felismerése nem probléma.

Frissítés: A megjegyzések azt sugallták, hogy létezik ilyen segédprogram:
https://github.com/digitalruby/ipban

b) Vannak bizonyos felhasználónevek, amelyeket a támadók előnyben részesítenek
Látható, hogy a keresés különböző nevű szótárban történik.
De a következőt vettem észre: jelentős számú próbálkozás használja a szerver nevét bejelentkezésként. Javaslat: Ne használja ugyanazt a nevet a számítógép és a felhasználó számára. Sőt, néha úgy tűnik, hogy megpróbálják valahogy elemezni a kiszolgáló nevét: például egy DESKTOP-DFTHD7C nevű rendszernél a legtöbb bejelentkezési kísérlet DFTHD7C néven történik:

Veszélyes az RDP nyitva tartása az interneten?

Ennek megfelelően, ha DESKTOP-MARIA számítógépe van, valószínűleg MARIA felhasználóként próbál bejelentkezni.

Még egy dolog, amit észrevettem a naplókból: a legtöbb rendszeren a legtöbb bejelentkezési kísérlet „rendszergazda” néven történik. És ez nem ok nélkül, mert a Windows számos verziójában létezik ez a felhasználó. Ráadásul nem is törölhető. Ez leegyszerűsíti a támadók feladatát: a név és a jelszó kitalálása helyett csak a jelszót kell kitalálnia.
A ransomware-t elkapó rendszer egyébként az Administrator felhasználót és a Murmansk#9 jelszót kapta. Még mindig nem tudom, hogyan törték fel ezt a rendszert, mert közvetlenül az incidens után kezdtem el figyelni, de valószínűnek tartom, hogy túlzásba esik.
Tehát ha a rendszergazda felhasználó nem törölhető, akkor mit kell tennie? Átnevezheted!

Javaslatok ebből a bekezdésből:

  • ne használja a felhasználónevet a számítógép nevében
  • győződjön meg arról, hogy nincs rendszergazda felhasználó a rendszerben
  • használjon erős jelszavakat

Így már körülbelül néhány éve figyelem, hogy több, az irányításom alatt álló Windows Servert brutálisan erőszakolják, és sikertelenül.

Honnan tudhatom, hogy sikertelen?
Mert a fenti képernyőképeken láthatja, hogy vannak sikeres RDP-hívások naplói, amelyek a következő információkat tartalmazzák:

  • melyik IP-ről
  • melyik számítógépről (gazdanév)
  • Felhasználónév
  • GeoIP információk

És rendszeresen ellenőrzöm ott – semmi rendellenességet nem találtak.

Mellesleg, ha egy adott IP-t különösen keményen erőszakolják, akkor blokkolhatja az egyes IP-címeket (vagy alhálózatokat), így a PowerShellben:

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

Az Elasticnak egyébként a Winlogbeat mellett még van Auditbeat, amely képes figyelni a rendszeren lévő fájlokat és folyamatokat. Kibanában van egy SIEM (Security Information & Event Management) alkalmazás is. Mindkettőt kipróbáltam, de nem láttam sok hasznot – úgy tűnik, hogy az Auditbeat hasznosabb lesz Linux rendszereken, és a SIEM még nem mutatott nekem semmi érthetőt.

Nos, az utolsó ajánlások:

  • Rendszeresen készítsen automatikus biztonsági mentést.
  • időben telepítse a biztonsági frissítéseket

Bónusz: az 50 felhasználó listája, akiket leggyakrabban használtak az RDP bejelentkezési kísérletekhez

"user.name: Csökkenő"
Gróf

dfthd7c (gazdagépnév)
842941

winsrv1 (gazdanév)
266525

ADMINISZTRÁTOR
180678

adminisztrátor
163842

adminisztrátor
53541

Michael
23101

szerver
21983

Steve
21936

János
21927

paul
21913

fogadás
21909

mikrofon
21899

iroda
21888

scanner
21887

beolvasás
21867

david
21865

chris
21860

tulajdonos
21855

menedzser
21852

administrateur
21841

Brian
21839

adminisztrátor
21837

jel
21824

személyzet
21806

ADMIN
12748

שורש
7772

ADMINISZTRÁTOR
7325

Támogatja a
5577

TÁMOGATÁS
5418

USER
4558

admin
2832

TEST
1928

mysql
1664

admin
1652

VENDÉG
1322

User1
1179

SZKENNELNI
1121

LETAPOGATÁS
1032

ADMINISZTRÁTOR
842

ADMIN1
525

BACKUP
518

MySqlAdmin
518

RECEPCIÓ
490

User2
466

TEMP
452

SQLADMIN
450

User3
441

1
422

MANAGER
418

TULAJDONOS
410

Forrás: will.com

Hozzászólás