Gyakran olvastam véleményeket arról, hogy a RDP (Remote Desktop Protocol) port nyitva tartása az Interneten meglehetősen balesetveszélyes, és ezt nem szabadna így csinálni. Az RDP-hez vagy VPN-en keresztül, vagy csak meghatározott "fehér" IP címekről érdemes hozzáférést biztosítani.
Több Windows Server adminisztrálását végzem kis cégek számára, ahol az volt a feladatom, hogy biztosítsam a távoli hozzáférést a Windows Serverhez a könyvelők számára. Ez egy modern trend – otthoni munka. Viszonylag gyorsan rájöttem, hogy a könyvelőket VPN-nel kínzó módszer nem hálás feladat, és hogy az összes IP címet összegyűjteni a fehér listához nem fog működni, mert az emberek IP címei dinamikusak.
Ezért a legegyszerűbb úton indultam el – kinyitottam a RDP portot. Most a könyvelőknek csak el kell indítaniuk az RDP-t, be kell írniuk a hoszt nevét (porttal együtt), a felhasználónevet és a jelszót.
Ebben a cikkben megosztom a tapasztalataimat (pozitív és nem annyira pozitív) és ajánlásaimat.
Kockázatok
Mivel kockáztat, ha nyitva hagyja az RDP portot?
1) Jogosulatlan hozzáférés érzékeny adatokhoz
Ha valaki kitalálja az RDP jelszavát, hozzáférhet az Ön által titokban tartani kívánt adatokhoz: számlák állapota, egyenlegek, ügyféladatok, …
2) Adatvesztés
Például egy titkosító vírus miatt.
Vagy egy rosszindulatú támadó célzott cselekedete következtében.
3) A munkaállomás elvesztése
A munkavállalóknak dolgozniuk kell, de a rendszer már kompromittálódott, újra kell telepíteni / helyreállítani / konfigurálni.
4) Helyi hálózat kompromittálása
Ha a támadó hozzáférést szerzett egy Windows számítógéphez, akkor már arról a gépről hozzáférhet olyan rendszerekhez, amelyek kívülről, az Internetről nem elérhetők. Például fájlmegosztókhoz, hálózati nyomtatókhoz stb.
Volt egy esetem, amikor egy Windows Server megfertőződött titkosító vírussal
és ez a vírus először a C: meghajtón lévő fájlok többségét titkosította, majd elkezdett titkosítani fájlokat a NAS-on keresztül a hálózaton. Mivel a NAS egy Synology volt, beállított snapshotokkal, így a NAS-t 5 perc alatt helyreállítottam, míg a Windows Servert nulláról kellett újratelepítenem.
Megfigyelések és Ajánlások
A Windows Server-eket a , amely naplókat küld az ElasticSearch-be, figyelem. A Kibana-ban több vizualizáció is van, és beállítottam egy egyedi irányítópultot is magamnak.
A megfigyelé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-t brute-force támadások fogják érni.
Egyik szerveren az RDP-t nem a megszokott 3389-es portról, hanem a 443-asra állítottam, hogy HTTPS-ként álcázva legyek. Érdemes a megszokott portról váltani, de ennek sok értelme nincs. Íme a statisztika erről a szerverről:
Látható, hogy egy hét alatt közel 400 000 sikertelen RDP bejelentkezési kísérlet történt.
Látható, hogy a bejelentkezési kísérletek 55 001 IP-címről indultak (néhány IP-t már blokkoltam).
Itt jogosan merül fel a következtetés, hogy célszerű lenne fail2ban-t használni, de
Windowsra ilyen segédprogram – nincs.
Van néhány elhagyatott projekt a GitHub-on, amelyek ezt látszólag házi készítésűen megoldják, de még csak nem is próbáltam telepíteni őket:
Vannak még fizetős segédprogramok, de azokat nem néztem meg.
Ha tudsz nyílt forráskódú megoldást erre a célra, oszd meg a megjegyzésekben.
Frissítés: A megjegyzésekben utaltak arra, hogy a 443-as port nem a legjobb választás, inkább használj magasabb portokat (32000+), mert a 443-as portot gyakrabban vizsgálják, és az RDP-t ezen a porton könnyen észlelni lehet.
Frissítés: A megjegyzésekben értesítettek, hogy van egy ilyen segédprogram:
b) Vannak bizonyos felhasználónevek, amelyeket a rosszindulatú támadók kedvelnek.
Látható, hogy a brutanak mérete különböző nevekkel történik.
De amit észrevettem: jelentős számú kísérlet a szerver nevének, mint felhasználónévnek a használata. Ajánlás: ne használj azonos nevet a számítógépen és a felhasználónál. Néha úgy tűnik, hogy a támadók a szerver nevét próbálják elemezni: például egy DESKTOP-DFTHD7C nevű rendszeren a legtöbb bejelentkezési kísérlet a DFTHD7C néven történik:
Ha például a számítógéped DESKTOP-MARIA lesz, akkor valószínűleg a MARIA néven próbálnak bejelentkezni.
Még egy dolog, amit a naplók alapján észrevettem: a legtöbb rendszerben a bejelentkezési kísérletek többsége az "administrator" néven történik. Ennek nem véletlen oka van, mivel sok Windows-verzióban létezik ez a felhasználó. Továbbá – nem is törölhető. Ez megkönnyíti a rosszindulatú támadók dolgát: a név és jelszó kitalálása helyett csak a jelszót kell kitalálniuk.
Megjegyzem, hogy az a rendszer, ami a titkosítót elkapta, rendelkezett Administrator felhasználóval és Murmansk#9 jelszóval. Még mindig nem vagyok biztos benne, hogyan törték fel azt a rendszert, mert éppen az incidens után kezdtem el figyelni, de úgy gondolom, hogy a brutanak lehetséges.
Ha az Administrator felhasználót nem lehet törölni, mit tegyünk? Átnevezhetjük!
Ajánlások ebből a pontból:
- Ne használja a felhasználónevet a számítógép nevében
- Győződjön meg róla, hogy a rendszeren nincs Administrator felhasználó
- Használjon megbízható jelszavakat
Így látom, hogy néhány Windows Server már körülbelül két éve bruteforce áldozatává válik, sikertelenül.
Honnan tudom, hogy sikertelenül?
Mert a fenti képernyőképeken látható, hogy vannak RDP-n sikeres bejelentkezési naplók, amik tartalmazzák az információkat:
- melyik IP-ről
- melyik számítógépről (hostname)
- felhasználónév
- GeoIP információ
És rendszeresen ellenőrzöm ezeket – anomáliákat nem tapasztaltam.
Egyébként, ha egy bizonyos IP-ről különösen aktívan bruteforce-olják, a különböző IP-k (vagy alhálózatok) így blokkolhatók 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 BlockEgyébként az Elasticnál a Winlogbeat mellett van még , ami figyelheti a fájlokat és folyamatokat a rendszeren. Van még egy SIEM (Biztonsági Információs és Eseménykezelő) alkalmazás a Kibanában. Mindkettőt kipróbáltam, de nem láttam különösebb hasznot — úgy tűnik, hogy az Auditbeat hasznosabb lesz Linux rendszerekhez, míg a SIEM egyelőre nem mutatott semmi kézzelfogható dolgot.
Nos, itt a végső ajánlások:
- végezzen rendszeres automatikus biztonsági mentéseket.
- időben telepítse a biztonsági frissítéseket
Bónusz: lista 50 felhasználóról, akiket gyakran használtak az RDP-s bejelentkezési kísérleteknél
"user.name: Csökkenő"
Szám
dfthd7c (hostname)
842941
winsrv1 (hostname)
266525
ADMINISTRATOR
180678
administrator
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
tulajdonos
21855
manager
21852
administrateur
21841
brian
21839
administrador
21837
mark
21824
staff
21806
ADMIN
12748
ROOT
7772
ADMINISTRADOR
7325
SUPPORT
5577
SOPORTE
5418
USER
4558
admin
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
Forrás: habr.com
