Ez a bejegyzés segít hatékony Snort szabályokat írni, hogy jelentősen javítsa biztonsági helyzetét. Azzal kezdjük, hogy ismertetjük, hogyan épül fel egy szabály, majd példákon keresztül vizsgáljuk meg a legjobb gyakorlatokat annak érdekében, hogy a lehető legtöbb rosszindulatú tevékenységet rögzítsük, miközben a lehető legkevesebb szabályt használjuk.
A Snort egy nyílt forráskódú hálózati behatolásérzékelő rendszer (NIDS), amely valós idejű csomagelemzést biztosít, és a Coralogix STA megoldásának része. Ha Ön a Coralogix STA ügyfele, feltétlenül olvassa el a korábbi bejegyzésemet is arról, hogyan szerkeszthetjük a Snort szabályokat az STA-ban.
A Snort szabályok anatómiája
Mielőtt belemerülnénk a legjobb Snort szabályok megírásának különböző stratégiáiba, kezdjük egy példa Snort szabály boncolásával:
alert: azt mondja a Snortnak, hogy ezt a viselkedést riasztásként jelentse (az STA számára létrehozott szabályokban kötelező).
tcp: azt jelenti, hogy ez a szabály csak TCP forgalomra vonatkozik.
any: ebben a kontextusban azt jelenti, hogy “bármilyen forrásportról”, majd van egy ‘->’ nyíl, ami azt jelenti, hogy “a connection to” (nincs ‘<-‘ operátor, de egyszerűen megfordíthatjuk az argumentumokat az operátor körül. Használhatja a ‘<>’ operátort annak jelzésére, hogy a kapcsolat iránya irreleváns a szabály szempontjából), majd egy IP-tartomány, amely a cél IP-címet, majd a portot jelöli. A porttartományt kettősponttal is jelezheti, például 0:1024, ami 0-1024-et jelent. A kerek zárójelben van néhány direktíva a figyelmeztető üzenet, a szabályra vonatkozó metaadatok, valamint további ellenőrzések beállítására.
msg: egy direktíva, amely egyszerűen beállítja az üzenetet, amelyet elküldünk (STA esetben a Coralogixnak), ha egyező forgalmat észlelünk.
flow: egy direktíva, amely megadja, hogy az aláírásként meghatározandó tartalomnak a szerver (“to_server”) vagy az ügyfél (“to_client”) felé irányuló kommunikációban kell-e megjelennie. Ez nagyon hasznos lehet, ha például a szerver válaszát szeretnénk észlelni, amely azt jelzi, hogy megsértették.
established: egy olyan direktíva, amely arra készteti a Snortot, hogy csak a létrehozott kapcsolatok részét képező csomagokra korlátozza az aláírásnak megfelelő csomagok keresését. Ez hasznos a Snort terhelésének minimalizálása érdekében.
uricontent: egy olyan utasítás, amely arra utasítja a Snortot, hogy egy bizonyos szöveget keressen a normalizált HTTP URI tartalmában. Ebben a példában olyan url-t keresünk, amely pontosan a “/root.exe” szöveget tartalmazza.
nocase: egy direktíva, amely azt jelzi, hogy szeretnénk, ha a Snort a nagy- és kisbetűket nem figyelembe vevő keresést végezne.
classtype: egy direktíva, amely egy metaadat-attribútum, amely jelzi, hogy milyen típusú tevékenységet észlel ez a szabály.
reference: egy direktíva, amely egy metaadat-attribútum, amely egy másik rendszerre mutat további információkért. Példánkban az url,<https://….> érték egy internetes URL-re mutat.
sid: egy olyan irányelv, amely egy metaadat-attribútum, amely az aláírás azonosítóját jelzi. Ha saját aláírást hoz létre (még akkor is, ha csak egy beépített szabályt cserél le), használjon 9,000,000 feletti értéket, hogy elkerülje az ütközést egy másik, már létező szabállyal.
rev: egy direktíva, amely a szabály verzióját jelzi.
Még sok mindent meg kell tanulnia a Snort szabályairól, amely támogatja a RegEx elemzést, a protokoll-specifikus elemzést (akárcsak az uricontent a HTTP esetében), a bináris (nem szöveges) adatok keresését byte hex értékek segítségével, és még sok-sok mást. Ha többet szeretne megtudni, itt kezdheti.
A hatékony Snort szabályok írásának legjobb gyakorlatai
- A sebezhetőséget célozza meg, ne az exploitot – Kerülje a szabályok írását egy adott exploit kit észlelésére, mert számtalan exploit létezik ugyanarra a sebezhetőségre, és biztosak lehetünk benne, hogy újakat írnak, miközben Ön ezt olvassa. Például sok korai aláírás a buffer overrun támadások észlelésére így nézett ki:
alert tcp $EXTERNAL_NET any -> $HOME_NET 80 (content:"AAAAAAAAAAAAAA", msg:"Buffer overrun detected.")
Az ok természetesen az, hogy egy sikeres buffer overrun támadás indításához a támadónak meg kell töltenie egy bizonyos változó pufferét, és a végén hozzá kell adnia a rosszindulatú hasznos terhét, hogy az végrehajthatóvá váljon. Az, hogy milyen karaktereket választ a puffer kitöltéséhez, teljesen jelentéktelen, és valóban, az ilyen típusú aláírások megjelenése után sok támadó eszközkészlet egyszerűen más betűt vagy betűket használt a puffer kitöltéséhez, és teljesen kikerülte az ilyen típusú aláírások felismerését. Sokkal jobb módszer lenne, ha az ilyen jellegű támadásokat úgy próbálnánk felismerni, hogy a mezőkbe történő helytelen bevitelt a mezők típusa és hossza alapján észleljük.
- A különlegességed a legjobb értéked, ezért használd ki – Minden szervezetnek vannak olyan dolgai, amelyek egyedivé teszik. Ezek közül sok igen hasznos lehet, amikor a szervezeten belüli – külső és belső – rosszindulatú tevékenységeket próbálja elkapni. Ha ezt a mély belső tudást az előnyére fordítja, akkor lényegében a problémát technológiai problémából tisztán régimódi hírszerzési problémává alakítja át, és arra kényszeríti a támadókat, hogy sokkal jobban megismerjék a szervezetét, hogy hatékonyan elrejthessék a nyomaikat. Ezek a dolgok lehetnek technológiai jellegűek, vagy alapulhatnak a szervezeted sajátos munkaszokásain és belső irányelvein. Íme néhány példa:
- Tipikus munkaidő: Néhány szervezetnél, ahol dolgoztam, egyáltalán nem engedélyezték az alkalmazottaknak, hogy otthonról dolgozzanak, és az alkalmazottak többsége már 19:00 órakor elhagyta az irodát. Hasonló szervezetek esetében érdemes lenne beállítani egy riasztást, amely értesíti az irodából érkező kapcsolatokról egy bizonyos óra után. Egy támadónak, aki rosszindulatú szoftvert telepítene az Ön szervezetébe, ismernie kellene ezt a viselkedést, és úgy kellene hangolnia a rosszindulatú szoftverét, hogy pontosan ugyanabban az időben kommunikáljon a Command & Control szervereivel, és az ilyen kommunikáció észrevétlen maradjon.
- Tipikus böngésző: Tegyük fel, hogy a szervezet úgy döntött, hogy a Brave böngészőt használja fő böngészőként, és ez automatikusan települ minden új vállalati laptopra, és Ön eltávolította az IE/Edge böngésző asztali parancsikonjait az összes vállalati laptopról. Ha ez a helyzet, akkor a szervezetből mind a belső, mind a külső címekre irányuló, más böngészőt, például IE/Edge-et használó kapcsolatokat úgy kell beállítani, hogy riasztást jelezzenek.
- IP-tartományok a szerepkörök alapján: Például, hogy az összes DB-kiszolgáló a 192.168.0.0/24, a webkiszolgálók a 192.168.1.0/24 stb. címen legyenek, akkor lehetséges, sőt könnyű lenne okos szabályokat felállítani a szerverek szerepük alapján elvárt viselkedése alapján. Például az adatbázis-kiszolgálók általában nem csatlakoznak más kiszolgálókhoz önállóan, a nyomtatók nem próbálnak meg csatlakozni a tartományvezérlőkhöz stb.
- Szokatlan csatlakozási kísérletek: Sok szervezet használ nyilvános megosztást egy fájlkiszolgálón, hogy a felhasználók megoszthassák egymás között a fájlokat, és hálózati engedélyű nyomtatókat használnak, hogy a felhasználók közvetlenül a számítógépükről nyomtathassanak. Ez azt jelenti, hogy az ügyfélszámítógépek nem csatlakozhatnak egymáshoz, még akkor sem, ha (bölcsen) úgy döntött, hogy blokkolja az ilyen hozzáférést egy tűzfalban vagy a kapcsolónál, már maga a kísérlet, hogy az egyik ügyfél egy másik ügyfélszámítógéphez csatlakozzon, riasztást kell, hogy adjon, és alaposan ki kell vizsgálni.
- Szokatlan portok: Egyes szervezetek speciális könyvtárat használnak a szolgáltatások közötti kommunikáció optimalizálására, így a szerverek közötti HTTP-kommunikáció a szokásos portoktól eltérő portot használ (például 80, 443, 8080 stb.). Ebben az esetben jó ötlet olyan szabályt létrehozni, amelyet ezeken az általában közös portokon történő kommunikáció vált ki.
- Honeytokens – Egy olyan csatatéren, mint az internet, ahol mindenki lehet akárki, a megtévesztés, ugyanolyan jól működik a védőknek, mint a támadóknak, ha nem jobban. Olyan trükkök, mint a beépített rendszergazdai fiók átnevezése egy másik, kevésbé vonzó névre, és egy új fiók létrehozása Administrator néven, amelyet soha nem fogsz használni, és egy Snort-szabály létrehozása annak észlelésére, ha ez a felhasználónév, e-mail vagy jelszó valaha is használatban van a hálózaton. A támadók számára szinte lehetetlen lenne észrevenni, hogy a Snort észlelte a hamis rendszergazda felhasználó használatára tett kísérleteiket. Egy másik példa a hamis termékek, ügyfelek, felhasználók és hitelkártya rekordok létrehozása az adatbázisban, majd a Snort szabályainak megfeleltetése ezek észlelésére a hálózati forgalomban.
Reméljük, hasznosnak találta ezt az információt. A Coralogix STA-vel kapcsolatos további információkért tekintse meg a nemrég megjelent legújabb funkciókat.