Sajnos egyre aktuálisabb téma a vállalatot értő támadások megfelelő kezelése. Mivel már egy 10-20 fős vállalatnak is lehet olyan komplex infrastruktúrája, amiben nehéz egy mindenre kiterjedő, de mégis egyszerűen kezelhető biztonsági rendszert kialakítani. Szinte mindenkinél van valamilyen levelezést biztosító termék, így például Microsoft Exchange, VPN megoldás és valamilyen távoli asztal megoldás is előfordulhat.
Ezeket védeni önmagában sem kis feladat, de úgy gondolom nem lehetetlen. Tekintsük az első védelmi vonalat, ilyen mindenkinek van:
Felhasználó/jelszó: Nehéz téma, főleg az ilyen vérzivataros időkben mint az elmúlt pár hónap. Elég csak a Collection #1-ra gondolni (link) minek keretében 773 millió email és 21 millió egyedi jelszó és 23 milliárd email/jelszó páros került ki az internetre. Az emberi természet nem tehet arról, hogy több szolgáltatásnál, azonos, de legalább kicsit hasonló jelszavakat használjon. Tehát valahol lehet a felhasználónak „Start123” a jelszava Facebook-on, és „Start1234” a Linkedin-en. A felhasználóneve pedig általában azonos, például az email címe, nem igényel nagy logikai képességet az azonos cím és a két jelszó egyeztetése, méginkább próba alapú kiderítése. Sajnos igaz ez abban az esetben is, mikor a felhasználó a céges email használatával regisztrál egy oldalra, ne adja ég, a vállalatnál is használt. tartományi jelszavával. Ez utóbbit kizárni teljességgel lehetetlen, viszont a legnagyobb kockázat ami csak lehetséges. Amennyiben egy ilyen oldalt támadnak meg és valamilyen módon legalább a jelszavak hash-eit meg tudják szerezni a támadók, egészen lehetetlen helyzetbe kerülhetünk. A felhasználó email címe, a céges tartományra végződik, máris megvan hová lehet próbálkozni, náluk a felhasználónév és a hash is. Amennyiben a jelszó rainbow táblákkal könnyen kideríthető a hash alapján, akkor már tényleg nyitott kapukat döngetnek. Nincs mit tenni, be fognak jutni. A levelezésbe, a VPN-re, a VDI-re, mindenhová.
Második védelmi vonal:
Korábban írtam róla és nem győzöm eléggé hangsúlyozni a fontosságát. A fizikai token-ek kora bár lejárt, de ha már van a vállalatnál, akkor használjuk. Ha nincs, viszont van legalább TPM chip a felhasználók gépeiben, akkor használható tanusítvány alapú második faktoros hitelesítésre. Ha ez sincs, illetve nem vállalható az ennek implementációjával, üzemeltetésével járó járulékos teher, akkor 2FA mint szolgáltatást javaslom (Azure 2FA, Duo Security stb.). Utóbbi kiterjeszthető lényegében mindenre, azaz kitehető OWA elé, VPN védelmére, de a második kapuőr szerepét is elláthatja a távoli asztal megoldásokban. Mindezt úgy, hogy a felhasználók mobiljára juttatja el a második faktort, push üzenetben. Pont úgy, mint ahogyan egy új levél érkezését jelzi a telefon. Ennél felhasználóbarátabb megoldást nem lehet elképzelni, viszont egy nagyságrenddel magasabb biztonsági szintet garantál. Nem állítom, hogy ezeket nem lehet megtörni, hiszen kompromittált mobilt biztosan lehet támadni, de itt az esetek 99,99%-ra tervezünk. A maradék egy század, pedig az amit kivédeni nem nagyon lehet, csak korlátozni azt a lyukat, amit a támadás ütni fog.
Mi tehető még?
- Az adminisztrátor jogosultsággal rendelkező felhasználói fiókok használatának mellőzése az interaktív belépések során, illetve az adminisztrátori jogosultságok kifejtése egy adminisztratív felhasználói fiókba. Ez annyit jelent, hogy a Domain Admin/Exchange Admin stb. jogosultsággal rendelkező személy, ne olyan felhasználót használjon a VPN-re, laptop-ra történő belépéskor, amivel egyébként ilyen jogosulságok párosulnak.
- Syslog szerver bevezetése és az audit bekapcsolása a sikeres és sikertelen események naplózására. Legyen ez fájlok megnyitására tett próbálkozások, RDP-n történő belépési események vagy OWA felületen tett authentikációs kísérlet. Ez bár nem akadályoz meg egy támadást, de a támadás hatásainak felderítésében nagyon nagy segítség.
- Az offsite mentés. Inkább írom hangsúlyosabban: OFFSITE MENTÉS! Nem tudom ismételni a 3-2-1 szabályt. 3 példány-2 média-1 offsite. Még azt is megkockáztatom, hogy a mentési rendszer – egy ransomware támadás esetén az utolsó gyógyszer – legyen teljesen izolált. Túzfal és ACL szabályozza, honnan, hogyan férhet hozzá és ha lehet, akkor ne legyen tartományi tag. Ha mégis az, akkor ha a domain admin jelszava megvan, akkor a mentőszerver(ek) is potenciális célpont és jó eséllyel a támadó kis ellenállással be is juthat. Ha bejut, akkor van esély arra, hogy a mentéseket is használhatatlanná teszi, ezzel kizárva még a visszaállítás lehetőségét is. Az offsite mentés lehetőleg tényleg legyen offsite, azaz ne legyen fizikai akció nélkül elérhető a mentési kiszolgálón.
- Erős jelszó házirend bevezetése. Ez nehéz, mert felhasználói elégedettség szempontjából ez nem hálás feladat. A felhasználók nem szeretik 2-3 havonta változtatni a jelszavaikat, főleg nem olyanra, ami kicsit sem hasonlít az előző háromra. Pedig az nem jó gyakorlat, ha valakinek a jelszava jelenleg „Start123”, majd a kötelező váltás után „Start234”.
- Amennyiben lehetséges, legalább valamilyen geoblock bevezetése a publikált szolgáltatások elérésében. Nem jelent teljes megoldást, de segít csak arra koncentrálni, amire kell. Nem valószínű, hogy Oroszországból próbálkozik belépni bármelyik felhasználó a VDI gépére, éjjel kettőkor. Tegyük ezt, akkor egy fokkal lehetetlenebbé.
- Olyan antivirus és anti-malware megoldás választása szerver-kliens oldalon, amely képes integrált működésre és kiegészíthető a hálózati szinten történő események által generált és indukált fenyegetésekre adható válaszokkal.
- Titkosítás használata a végpontokon. A hordozható eszközökben található tárolók titkosítása valamilyen megoldással – Bitlocker stb.
- MDM megodások használata, nem csak a mobiltelefonok és tabletek számára, de a Windows 10 és Mac eszközök esetében is.
- Ha a mentési céltároló, de még inkább a produktív és operatív adatokat tartalmazó tárolók képesek a tároló szintjén készített pillanatképek előállítására, akkor az legyen konfigurálva. Nyilvánvalóan a tároló OOB elérése legyen izolált és semmiképpen se legyen Active Directory integrált. Ha ez utóbbiban jogosulságot szerez a támadó, akkor legalább a tárolóra ne tudjon bejutni egyszerűen. A storage snapshot-okból a visszaállítás tényleg lehet instant és egészen megbízható.
Komplex feladat és nincs „one size fits all” megoldás. Minden implementáció egyedi ezért becsülni sem lehetséges a szükséges ráfordítás mértékét. Ennek ellenére ez a legfontosabb feladat a mai IT-ban.