Elmesélünk egy hűvös történetet arról, hogy miként próbálták meg a „harmadik felek” megzavarni ügyfeleink munkáját, és hogy ezt a problémát hogyan oldottuk meg.
Hogyan kezdődött az egész
Minden a 31-én, október 31-én, a hónap utolsó napján kezdődött, amikor sokaknak sürgősen be kellett fejezniük fontos kérdéseiket.
Az egyik partnerünk, aki több virtuális gépet tart az ügyfeleink számára a felhőnkben, arról számolt be, hogy 9:10 és 9:20 között több Windows-szerver, amely a mi ukrán helyszínünkön működik, nem fogadta a távoli hozzáférési szolgáltatásra vonatkozó kapcsolatokat, így a felhasználók nem tudtak bejelentkezni a munkaasztalaikra, de néhány perc múlva a probléma mintha magától megoldódott volna.
Megnéztük a kapcsolataink teljesítménystatisztikáit, de nem észleltünk se forgalmi csúcsokat, se kieséseket. Beleszóltunk a számítási erőforrások terheltségi statisztikájába – ott sem voltak anomáliák. Mi lehetett ez?
Ezután egy másik partnerünk, aki a felhőnkben még körülbelül száz szervert üzemeltet, hasonló problémákról számolt be, amelyeket néhány ügyfelük tapasztalt; kiderült, hogy a szerverek összességében elérhetők (rendben reagálnak a ping-tesztekre és más kérésekre), de a távoli hozzáférési szolgáltatás ezeken a szervereken hol elfogadja az új kapcsolatokat, hol elutasítja azokat, ráadásul a szerverek különböző helyszíneken helyezkednek el, és a forgalom különböző adatátviteli csatornákból érkezik.
Nézzük meg ezt a forgalmat. A kapcsolat létrehozására irányuló csomag megérkezik a szerverre:
xx:xx:xx.xxxxxx IP xxx.xxx.xxx.xxx.58355 > 192.168.xxx.xxx.3389: Flags [S], seq 467744439, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
A szerver megkapja ezt a csomagot, de a kapcsolatot elutasítja:
xx:xx:xx.xxxxxx IP 192.168.xxx.xxx.3389 > xxx.xxx.xxx.xxx.58355: Flags [R.], seq 0, ack 467744440, win 0, length 0
Ez azt jelenti, hogy a probléma nyilvánvalóan nem az infrastruktúra működésével kapcsolatos, hanem valami más. Talán minden felhasználónak problémái merültek fel a távoli munkaasztalok licencelésével? Talán valamilyen kártékony szoftver került a rendszereikbe, és ma aktiválódott, ahogyan pár évvel ezelőtt is történt a XData és Petya?
Miközben foglalkoztunk a problémával, hasonló megkereséseket kaptunk néhány további ügyféltől és partnertől.
Mi történik valójában ezeken a gépeken?
Az eseménynaplók tele vannak a jelszó kitalálására tett kísérletekkel szóló üzenetekkel:
Általában az ilyen kísérleteket regisztrálják minden olyan szerveren, ahol a távoli hozzáférési szolgáltatáshoz a standard port (3389) használatos, és ahol engedélyezve van a hozzáférés bárhonnan. Az interneten teli van botokkal, amelyek folyamatosan szkennelik az összes elérhető csatlakozási pontot, és próbálják kitalálni a jelszót (éppen ezért javasoljuk, hogy használjon összetett jelszavakat a "123" helyett). Mindazonáltal, aznap a kísérletek intenzitása túl magas volt.
Mi a teendő?
Azt ajánlani az ügyfeleknek, hogy szánjanak rengeteg időt arra, hogy megváltoztassák a beállításokat a hatalmas számú végfelhasználó esetében, hogy áttérjenek egy másik portra? Nem igazán jó ötlet, az ügyfelek nem fognak örülni. Ajánlani, hogy csak VPN-en keresztül engedélyezzenek hozzáférést? Sietve és pánikban IPSec kapcsolatok beállítása, ahol még nincsenek beállítva – talán ez is örömmel fogadná az ügyfeleket. Bár el kell mondani, hogy ez minden esetben dicséretes dolog, mi mindig javasoljuk a szerver elrejtését egy magánhálózatba, és készen állunk a beállításokban segíteni, az önállóan felfedezőknek pedig megosztjuk az IPSec/L2TP beállítására vonatkozó útmutatót a felhőnkkel site-to-site vagy road-warrior módban, és ha valaki szeretné saját Windows szerverén felállítani a VPN szolgáltatást – mindig készséggel megosztjuk a tippeket arról, hogyan lehet beállítani a standard RAS-t vagy OpenVPN-t. De bármennyire is szeretnénk segíteni, ez nem volt a legjobb időszak az ügyfelekkel való tájékoztatásra, mivel minél előbb meg kellett oldani a problémát a felhasználók számára a lehető legkisebb feszültséggel.
A megvalósított megoldás a következőképpen alakult. Beállítottuk a forgalom elemzését úgy, hogy nyomon kövessük az összes TCP-kapcsolat létrehozására irányuló kísérletet a 3389-es porton, és kiválasszuk azokat az IP-címeket, amelyek 150 másodperc alatt több mint 16 különböző szerverrel próbálnak kapcsolatot létesíteni a hálózatunkban – ezek a támadási források (természetesen, ha bármelyik ügyfelünknek vagy partnerünknek valós szüksége van ilyen sok szerverrel kapcsolódni egyetlen forrásból, az ilyen forrásokat mindig hozzá lehet adni a „fehér listához”. Ugyanakkor, ha egy C osztályú hálózatban 150 másodperc alatt több mint 32 IP-címet észlelünk, érdemes blokkolni az egész hálózatot. A blokkolás 3 napra állítottuk be, és ha ez idő alatt nem történt támadás az adott forrástól, akkor az automatikusan eltávolításra kerül a „fekete listáról”. A blokkolt források listája 300 másodpercenként frissül.
Ez a lista a következő címen érhető el: , ezen alapul építhetitek a saját ACL-jaitokat.
A rendszer forráskódját szívesen megosztjuk, semmi bonyolult nincs benne (ez néhány egyszerű szkript, amelyet szó szerint pár óra alatt „a térdünkön” állítottunk össze), és ráadásul nemcsak ezen támadások ellen véd, hanem bármilyen hálózati szkennelési kísérlet azonosítására és blokkolására is felhasználható:
Ezen kívül néhány változtatást eszközöltünk a monitorozási rendszer beállításaiban is, amely most alaposabban figyelemmel kíséri a virtuális szerverek ellenőrző csoportját a RDP-kapcsolat létesítési kísérletekre: ha nem következik be reakció egy másodpercen belül – az figyelmeztető jel.
A megoldás meglehetősen hatékonynak bizonyult: se a kliensektől, se a partnerektől, se a monitorozó rendszertől nem érkeztek további panaszok. Rendszeresen új címek és egész hálózatok kerülnek a „fekete listára”, ami azt jelzi, hogy a támadás folytatódik, de már nem befolyásolja ügyfeleink munkáját.
Egy katona nem katona.
Ma megtudtuk, hogy más szolgáltatók is hasonló problémával küzdenek. Néhányan még mindig azt hiszik, hogy a Microsoft módosításokat eszközölt a távoli hozzáférési szolgáltatás kódján (ha emlékszel, az első napon mi is gyanakodtunk erre, de ezt a verziót hamar elvetettük), és megígérik, hogy mindent megtesznek annak érdekében, hogy minél előbb megoldást találjanak. Van, aki egyszerűen figyelmen kívül hagyja a problémát, és azt tanácsolja, hogy a kliensek önállóan védjék meg magukat (váltsanak portot, rejtsék el a szervert privát hálózatba stb.). Mi az első napon nemcsak megoldottuk ezt a problémát, hanem egy alapot is létrehoztunk egy átfogóbb fenyegetésészlelő rendszerhez, amelyet a jövőben szeretnénk fejleszteni.
Külön köszönet a klienseinknek és partnereinknek, akik nem hallgattak, és nem ültek a folyóparton várva, hogy egyszer csak elsodródjon az ellenség holtteste, hanem azonnal felhívták a figyelmünket a problémára, ami lehetővé tette számunkra, hogy még aznap orvosoljuk azt.
Forrás: habr.com
