Mondjunk el egy klassz történetet arról, hogyan próbáltak „harmadik felek” beavatkozni ügyfeleink munkájába, és hogyan oldották meg ezt a problémát.
Hogy kezdődött az egész
Október 31-én, a hónap utolsó napján kezdődött minden, amikor sokaknak égetően szükségük van arra, hogy legyen időnk sürgős és fontos kérdések megoldására.
Az egyik partner, aki az általa kiszolgált kliensek több virtuális gépét is felhőnkban tartja, arról számolt be, hogy 9:10-től 9:20-ig több ukrán oldalunkon futó Windows szerver nem fogadta el a távelérési szolgáltatáshoz való csatlakozást, a felhasználók nem tudtak bejelentkezni az asztali számítógépükre, de néhány perc múlva úgy tűnt, a probléma magától megoldódik.
Megemeltük a kommunikációs csatornák működési statisztikáját, de forgalomnövekedést, meghibásodást nem találtunk. Megnéztük a számítási erőforrások terhelésének statisztikáit – nincs anomália. És mi volt az?
Aztán egy másik partner, aki körülbelül száz további szervert üzemeltet a felhőnkben, ugyanazokról a problémákról számolt be, amelyeket néhány kliense is észlelt, és kiderült, hogy a szerverek általában elérhetőek (megfelelően válaszoltak a ping tesztre és egyéb kérésekre), de a szolgáltatás távoli elérése ezeken a szervereken vagy fogadja az új kapcsolatokat, vagy elutasítja azokat, és itt a különböző oldalakon lévő szerverekről beszéltünk, amelyek forgalma különböző adatátviteli csatornákon érkezik.
Nézzük ezt a forgalmat. Kapcsolódási kérelmet tartalmazó csomag é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 elutasítja a kapcsolatot:
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émát nyilvánvalóan nem az infrastruktúra működésének problémája okozza, hanem valami más. Lehet, hogy minden felhasználónak problémái vannak a távoli asztali licenceléssel? Lehet, hogy valami rosszindulatú programnak sikerült behatolnia a rendszerükbe, és ma aktiválódott, mint néhány éve. XData и Petya?
A rendezés közben több ügyfelünktől és partnerünktől is érkezett hasonló megkeresés.
Mi történik valójában ezeken a gépeken?
Az eseménynaplók tele vannak a jelszó kitalálási kísérleteiről szóló üzenetekkel:
Az ilyen próbálkozásokat általában minden olyan szerveren regisztrálják, ahol a szabványos portot (3389) használják a távoli elérési szolgáltatáshoz, és a hozzáférés mindenhonnan engedélyezett. Az internet tele van robotokkal, amelyek folyamatosan átvizsgálják az összes elérhető kapcsolódási pontot, és megpróbálják kitalálni a jelszót (ezért erősen javasoljuk a „123” helyett összetett jelszavak használatát). Ezeknek a próbálkozásoknak az intenzitása azonban aznap túl magas volt.
Mit tegyek?
Azt javasolja, hogy az ügyfelek sok időt töltsenek a beállítások megváltoztatásával, hogy nagy számú végfelhasználó másik portra váltson? Nem jó ötlet, az ügyfelek nem lesznek elégedettek. Azt javasolja, hogy csak VPN-en keresztül engedélyezze a hozzáférést? Sietve és pánikban IPSec kapcsolatok felépítése azoknak, akiknek nincs felnevelve - talán az ügyfeleken sem mosolyog ez a boldogság. Bár meg kell mondanom, ez mindenesetre istenfélő dolog, de mindig azt javasoljuk, hogy rejtsd el a szervert privát hálózatba, és készen állunk a beállításokban segíteni, aki pedig szereti a saját kezűleg kitalálni, azoknak instrukciókat osztunk meg az IPSec/L2TP beállításához felhőnkben helyek közötti vagy közúti módban -harcos módban, és ha valaki VPN szolgáltatást szeretne beállítani a saját Windows szerverén, mindig készen áll arra, hogy megosszon tippeket a szabványos RAS vagy OpenVPN. De bármennyire is menők voltunk, nem ez volt a legjobb alkalom az ügyfelek körében végzett oktatási munkára, mivel a lehető leggyorsabban meg kellett oldanunk a problémát, minimális stresszel a felhasználók számára.
Az általunk megvalósított megoldás a következő volt. Az átmenő forgalom elemzését úgy állítottuk be, hogy figyelemmel kísérjük a 3389-es porthoz való TCP-kapcsolat létrehozására irányuló összes kísérletet, és kiválasztjuk azokat a címeket, amelyek 150 másodpercen belül megpróbálnak kapcsolatot létesíteni a hálózatunkon lévő több mint 16 különböző szerverrel. - ezek a támadás forrásai (Természetesen, ha az egyik kliensnek vagy partnernek valóban szüksége van arra, hogy ennyi szerverrel létesítsen kapcsolatot ugyanabból a forrásból, az ilyen forrásokat mindig felveheti a „fehér listára”. ha egy C osztályú hálózatban erre a 150 másodpercre 32-nél több címet azonosítanak, akkor célszerű a teljes hálózatot blokkolni. ez a forrás automatikusan törlődik a „fekete listáról”. A blokkolt források listája 3 másodpercenként frissül.
Ez a lista ezen a címen érhető el: , ez alapján építheti fel az ACL-eit.
Készek vagyunk megosztani egy ilyen rendszer forráskódját, nincs benne semmi túlságosan bonyolult (ez több egyszerű szkript, amit szó szerint pár óra alatt összeállítottak a térdre), ugyanakkor adaptálható és használható csak az ilyen támadások elleni védelem érdekében, hanem a hálózat átvizsgálására irányuló kísérletek észlelésére és blokkolására is:
Ezen túlmenően néhány változtatást eszközöltünk a megfigyelő rendszer beállításain is, amely mostantól jobban figyeli a felhőnkben lévő virtuális szerverek egy vezérlőcsoportjának reakcióját az RDP-kapcsolat létrehozására tett kísérletre: ha a reakció nem következik be egy másodszor, ez ok a figyelemre.
A megoldás meglehetősen hatékonynak bizonyult: nincs többé panasz sem az ügyfelek, sem a partnerek részéről, sem a monitoring rendszer részéről. Rendszeresen új címek és teljes hálózatok kerülnek fel a feketelistára, ami azt jelzi, hogy a támadás folytatódik, de már nem érinti ügyfeleink munkáját.
A számokban van biztonság
Ma megtudtuk, hogy más szolgáltatók is találkoztak hasonló problémával. Valaki még mindig azt hiszi, hogy a Microsoft módosított néhányat a távoli hozzáférési szolgáltatás kódjában (ha emlékszel, már az első napon ugyanerre gyanakodtunk, de nagyon gyorsan elutasítottuk ezt a verziót), és megígéri, hogy mindent megtesz a gyors megoldás érdekében. . Vannak, akik egyszerűen figyelmen kívül hagyják a problémát, és azt tanácsolják az ügyfeleknek, hogy saját maguk védekezzenek (változtassa meg a csatlakozási portot, rejtse el a szervert egy magánhálózatban stb.). A legelső napon pedig nemcsak ezt a problémát oldottuk meg, hanem megteremtettük az alapot egy globálisabb fenyegetésészlelő rendszerhez is, amelyet tervezünk fejleszteni.
Külön köszönet azoknak az ügyfeleknek és partnereknek, akik nem maradtak csendben, és nem a folyóparton ülve várták, hogy egy napon egy ellenség holtteste lebegjen rajta, hanem azonnal felhívták a figyelmünket a problémára, amely lehetőséget adott a megszüntetésre. ugyanazon a napon.
Forrás: will.com