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
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:
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:
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:
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:
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
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