Tento příspěvek vám pomůže napsat efektivní pravidla Snortu, která podstatně zlepší vaši bezpečnostní pozici. Začneme rozborem toho, jak se pravidlo sestavuje, a poté na příkladech prozkoumáme osvědčené postupy, abychom zachytili co nejvíce škodlivých aktivit a zároveň použili co nejméně pravidel.
Snort je open-source systém detekce narušení sítě (NIDS), který poskytuje analýzu paketů v reálném čase a je součástí řešení Coralogix STA. Pokud jste zákazníkem Coralogix STA, nezapomeňte se také podívat na můj dřívější příspěvek o tom, jak upravovat pravidla Snort v STA.
Anatomie pravidel Snort
Než se ponoříme do různých strategií pro psaní nejlepších pravidel Snort, začněme rozebráním příkladu pravidla Snort:
alert: říká Snortu, aby toto chování hlásil jako výstrahu (je povinné v pravidlech vytvořených pro STA).
tcp: znamená, že toto pravidlo se bude vztahovat pouze na provoz v TCP.
any: v tomto kontextu znamená „z libovolného zdrojového portu“, dále je zde šipka ‚->‘, která znamená „spojení na“ (operátor ‚<-‚ neexistuje, ale můžete jednoduše přehodit argumenty kolem operátoru. Operátor ‚<>‘ můžete použít k označení, že směr připojení je pro toto pravidlo irelevantní), dále rozsah IP, který označuje cílovou IP adresu, a pak port. Rozsah portů můžete uvést pomocí dvojtečky, například 0:1024, což znamená 0-1024. V kulaté závorce se nachází několik direktiv pro nastavení výstražné zprávy, metadat o pravidle a také dalších kontrol.
msg: je direktiva, která jednoduše nastavuje zprávu, která bude odeslána (společnosti Coralogix v případě STA) v případě, že bude detekován odpovídající provoz.
flow: je direktiva, která udává, zda se má obsah, který se chystáme definovat jako náš podpis, objevit v komunikaci se serverem („to_server“) nebo s klientem („to_client“). To může být velmi užitečné, pokud bychom například chtěli detekovat odpověď serveru, která naznačuje, že došlo k jeho narušení.
established: je direktiva, která způsobí, že Snort omezí vyhledávání paketů odpovídajících této signatuře pouze na pakety, které jsou součástí navázaných spojení. To je užitečné pro minimalizaci zátěže Snortu.
uricontent: je direktiva, která dává Snortu pokyn, aby hledal určitý text v normalizovaném obsahu HTTP URI. V tomto příkladu hledáme url, které je přesně textem „/root.exe“.
nocase: je direktiva, která označuje, že chceme, aby Snort prováděl vyhledávání bez ohledu na velikost písmen.
classtype: je direktiva, která je atributem metadat označujícím, jaký typ aktivity toto pravidlo detekuje.
reference: je direktiva, která je atributem metadat odkazujícím na jiný systém pro více informací. V našem příkladu hodnota url,<https://….> odkazuje na adresu URL na internetu.
sid: je direktiva, která je atributem metadat označujícím ID podpisu. Pokud vytváříte vlastní signaturu (i když jen nahrazujete vestavěné pravidlo), použijte hodnotu vyšší než 9 000 000, abyste zabránili kolizi s jiným již existujícím pravidlem.
rev: je direktiva, která označuje verzi pravidla.
Je toho mnohem více, co se můžete dozvědět o pravidlech Snort, která podporují parsování RegEx, parsování specifických protokolů (stejně jako uricontent pro HTTP), vyhledávání binárních (netextových) dat pomocí hexadecimálních hodnot bajtů a mnoho dalšího. Pokud se chcete dozvědět více, můžete začít zde.
Nejlepší postupy pro psaní efektivních pravidel Snortu
- Zaměřte se na zranitelnost, ne na exploit – Vyhněte se psaní pravidel pro detekci konkrétní sady exploitů, protože pro stejnou zranitelnost existuje nespočet exploitů a můžeme si být jisti, že v době, kdy toto čtete, vznikají nové. Například mnohé z prvních signatur pro detekci útoků s překročením vyrovnávací paměti vypadaly takto:
alert tcp $EXTERNAL_NET any -> $HOME_NET 80 (content:"AAAAAAAAAAAAAA", msg:"Buffer overrun detected.")
Důvodem je samozřejmě to, že k úspěšnému útoku s překročením vyrovnávací paměti potřebuje útočník zaplnit vyrovnávací paměť určitou proměnnou a na konec přidat svůj škodlivý payload, aby se stal spustitelným. Znaky, které zvolí k vyplnění vyrovnávací paměti, jsou zcela nepodstatné a skutečně, poté, co se takové signatury objevily, mnoho útočných toolkitů jednoduše použilo k vyplnění vyrovnávací paměti jiné písmeno nebo písmena a zcela se vyhnulo detekci tohoto typu signatur. Mnohem lepším způsobem by bylo pokusit se odhalit tento druh útoků pomocí detekce nesprávného vstupu do polí na základě jejich typu a délky.
- Vaše zvláštnost je vaší nejlepší devizou, tak ji využijte – Každá organizace má věci, které ji činí jedinečnou. Mnohé z nich mohou být docela užitečné, když se snažíte zachytit škodlivé aktivity ve vaší organizaci – jak externí, tak interní. Využitím těchto hlubokých interních znalostí ve svůj prospěch v podstatě změníte problém z technologického na čistě staronový zpravodajský problém a donutíte útočníky, aby vaši organizaci znali mnohem podrobněji a dokázali po sobě účinně zamést stopy. Tyto věci mohou být technologické povahy nebo mohou vycházet z konkrétních pracovních zvyklostí a interních směrnic vaší organizace. Zde je několik příkladů:
- Typická pracovní doba: Některé organizace, ve kterých jsem pracoval, vůbec neumožňovaly zaměstnancům pracovat z domova a většina zaměstnanců opouštěla kancelář již v 19:00. V některých organizacích bylo možné pracovat i z domova. U podobných organizací by mělo smysl nastavit upozornění, které by upozorňovalo na spojení z kanceláře po určité hodině. Útočník, který by ve vaší organizaci instaloval škodlivý software, by musel toto chování znát a vyladit svůj škodlivý software tak, aby komunikoval se svými příkazovými & řídicími servery přesně ve stejnou dobu, kdy by taková komunikace zůstala bez povšimnutí.
- Typický prohlížeč: Předpokládejme, že se vaše organizace rozhodla používat jako hlavní prohlížeč prohlížeč Brave, který se automaticky instaluje na každý nový firemní notebook, a že jste ze všech firemních notebooků odstranili zástupce na ploše pro prohlížeč IE/Edge. V takovém případě by připojení z organizace, a to jak na interní, tak na externí adresy, které používají jiný prohlížeč, například IE/Edge, mělo být nakonfigurováno tak, aby vyvolalo výstrahu.
- Rozsahy IP na základě rolí: Pokud je možné přiřadit různé rozsahy IP pro různé servery na základě jejich role, například mít všechny servery DB na 192.168.0.0/24, webové servery na 192.168.1.0/24 atd., pak by bylo možné a dokonce snadné nastavit chytrá pravidla na základě očekávaného chování serverů podle jejich role. Například databázové servery se obvykle samy nepřipojují k jiným serverům, tiskárny se nepokoušejí připojit k vašim řadičům domény atd.
- Neobvyklé pokusy o připojení: Mnoho organizací používá veřejné sdílení na souborovém serveru, které pomáhá uživatelům sdílet soubory mezi sebou, a používá síťové tiskárny, které umožňují uživatelům tisknout přímo z jejich počítačů. To znamená, že by se klientské počítače neměly navzájem připojovat, i když jste se (moudře) rozhodli zablokovat takový přístup ve firewallu nebo v přepínači, samotný pokus o připojení jednoho klienta k jinému klientskému počítači by měl vyvolat výstrahu a být důkladně prošetřen.
- Neobvyklé porty: Některé organizace používají speciální knihovny pro optimalizaci komunikace mezi službami, takže veškerá komunikace HTTP mezi servery používá jiný než běžný port (např. 80, 443, 8080 atd.). V takovém případě je dobré vytvořit pravidlo, které by se spouštělo při jakékoli komunikaci na těchto běžně používaných portech.
- Honeytokeny – Na bitevním poli, jako je internet, kde každý může být prakticky kýmkoli, funguje klamání, pro obránce stejně dobře jako pro útočníky, ne-li lépe. Triky jako přejmenování vestavěného účtu správce na jiné, méně atraktivní jméno a vytvoření nového účtu s názvem Administrator, který nikdy nepoužijete, a vytvoření pravidla Snortu pro detekci, pokud je toto uživatelské jméno, e-mail nebo heslo někdy v síti použito. Pro útočníky by bylo téměř nemožné, aby si všimli, že Snort zjistil jejich pokusy o použití falešného uživatele správce. Dalším příkladem je vytvoření falešných produktů, zákazníků, uživatelů a záznamů o kreditních kartách v databázi a následné přiřazení pravidel Snort pro jejich detekci v síťovém provozu.
Doufáme, že vám tyto informace pomohly. Další informace o systému Coralogix STA najdete v nejnovějších funkcích, které jsme nedávno vydali.