39360.zip
A skálázható és hatékony Snort nyílt forráskódú hálózati behatolásjelző rendszer (NIDS) jól definiált szabályok sorozatát használja a hálózaton található rendellenes csomagok észlelésére. Ezeknek a szabálykészleteknek a karbantartása drámaian javítja a rendszer hatékonyságát. Néhány szabálykezelési technika segíthet a Snort IDS karbantartásában. Először is, a változódefiníciók szigorításával és a Snort-szabályok ápolásával megelőzheti a riasztások túlterhelését. Egyéni szabályait a szabálykészlet-frissítések során is megőrizheti. Végül pedig dekonstruálhat egy szabályt, hogy megértse, hogyan kell a szabályokat a környezetéhez igazítani.
A Snort alapértelmezés szerint több mint 1900 készletszabályt tartalmaz egy közel 50 szöveges fájlból álló, típusok szerint rendezett sorozatban, ahogy az 1. ábra mutatja. Ezek a szabályok számos ismert, a Windowsra, UNIX-ra és a széles körben használt alkalmazásokra, például a Microsoft IIS-re, az Apache-ra, a Microsoft SQL Serverre és az Oracle SQL-re vonatkozó sebezhetőségi kihasználásokra vonatkozó válaszkioldókat határoznak meg. A szabályok segítségével a Snort felderítési adatokat és lehetséges konfigurációs figyelmeztetéseket is szolgáltat, hogy figyelmeztessen például a hálózati letapogatásokról vagy egy olyan gépről, amely SNMP alapértelmezett közösségi karakterláncot sugároz. Amint azt elképzelheti, a Snort óriási számú riasztást képes generálni. A készletszabályok zajának csökkentése érdekében a Snort alapértelmezett konfigurációja a szabályoknak csak körülbelül 1300-at engedélyez alapértelmezés szerint, és teljes szabálytípusokat, például a házirend, a csevegés és a vírus alapértelmezés szerint letilt. (Egy szabálytípus általában saját szöveges fájlban található, így a vírus típusú szabályokat a virus.rules fájl tartalmazza.) Tekintse át a letiltott szabálycsoportokat, és engedélyezze azokat, amelyek az Ön környezetére vonatkoznak.
Prune Your Rules
A Snort IDS-rendszere még az alapértelmezetten letiltott szabályok ellenére is valószínűleg sok riasztást fog generálni. Ha ezeket a riasztásokat végig kell néznie, az eltompíthatja az érzékeit a valóban gyanús forgalomra. Miután telepítette a Snortot a környezetébe, szűkítse le a szabályokat, hogy eltávolítsa azokat, amelyek nem vonatkoznak a környezetére, vagy amelyek nem érintik Önt. Például, ha nem használja a HTML-be ágyazott PHP szkriptnyelvét: Hypertext Preprocessor (PHP) telepítve van a környezetében, letilthatja a web-php.rules szabályfájlt. Annak eldöntésekor azonban, hogy mely szabályokat tiltsa le, vegye figyelembe azokat a felhasználókat, akiknek a gépén különböző szoftverek lehetnek. Például az egyik Snort-érzékelője gyanús csomagokat észlelhet egy veszélyeztetett otthoni gépről VPN-kapcsolaton keresztül. Tehát, folytatva az előző példát, még ha nincs is telepítve a PHP a vállalati számítógépeken, az egyik végfelhasználó telepíthette otthon. Ha ez az otthoni számítógép a PHP sebezhetőségén keresztül veszélybe kerül, a támadó képes lehet hozzáférni a vállalati hálózatához, miközben a veszélyeztetett számítógép távolról kapcsolódik a vállalati hálózathoz (például VPN-en keresztül).
A legtöbb riasztási és jelentési rendszer megjeleníti az egyes szabályok nevét és SID-jét a könnyű hivatkozás érdekében. Az engedélyezett szabályok listájának további csökkentéséhez figyelje a rendszereit, jegyezze fel a felesleges szabályok nevét vagy SID-jét, majd tiltsa le ezeket a szabályokat. Egy Snort-szabály kézi letiltásához nyissa meg a szabályfájlt, és illesszen be egy fontjelet (#) a szabály elé. Egy teljes szabályosztály letiltásához tegyen egy fontjelet a szabály fájlneve elé a Snort konfigurációs fájlban. A módosított szabályok betöltéséhez újra kell indítania a Snortot.
A szabályok rendszeres felülvizsgálata és a hálózatra nem vonatkozó szabályok folyamatos kiküszöbölése jelentősen csökkenti a Snort által generált riasztások számát, ezáltal megkönnyítve a valóban gyanús csomagok felismerését és azonosítását. Ne feledje, hogy szükség esetén újra aktiválja a szabályokat, ha olyan új technológiát vezet be, amelyet a jelenleg letiltott szabályok védenének.
A szabályok naprakészen tartása
A snort.org a Snort szabályok két változatát tartalmazza: snortrules-stable és snortrules-current, amelyek a Snort 2.0x és a Snort 1.9x rendszerrel működnek. Az újabb szabályok további aláírásokat és a meglévő szabályok frissítéseit tartalmazzák a kibővített változók használata érdekében. A 2.0.0 verziójú szabályok például olyan változókat határoznak meg, amelyek kifejezetten bizonyos gépi funkciókat írnak le (pl. a HTTP_SERVERS és HTTP_PORTS változók olyan számítógépeket jellemeznek, amelyek webes szolgáltatásokat futtatnak, és hajlamosak lehetnek webes szolgáltatási támadásokra). Ezek az új változók az új szabályokban a bejövő támadások további szűrésére szolgálnak. Egy régi szabály figyelmeztethet egy gyanús HTTP-kérésre, amely a hálózat bármely számítógépére irányul, de az új szabály csak akkor keresi ugyanazt a támadást, ha az a HTTP_SERVERS változó által meghatározott webkiszolgálóra irányul. Ez az osztályozási folyamat segít csökkenteni a téves riasztások számát.
A Snort.org gyakran frissíti a szabálykészleteket, hogy naprakész maradjon az új exploit felfedezésekkel. A naprakészség érdekében rendszeresen ellenőrizze, töltse le és alkalmazza azokat az új szabályokat, amelyek hasznosak lehetnek az Ön környezetében. Vegye azonban figyelembe, hogy amikor új szabálykészletet tölt le, az új szabályokat tartalmazó szövegfájlok felülírják a régi szabályokat tartalmazó fájlokat. Hamar rájön, hogy a nem használt szabályok minden egyes frissítéskor történő kommentálása megterhelő.
Oinkmaster a megmentő
Szerencsére számos nyílt forráskódú eszköz segíthet ennek a problémának a leküzdésében. Az Oinkmaster nevű Perl script program, amelyet a http://www.algonet.se/~nitzer/oinkmaster címről tölthet le, automatizálja az új szabályok letöltését, és kezeli a letiltott vagy módosított szabályokat. A UNIX-rendszerekre szabott Perl-szkript a wget, tar és gzip eszközöket használja az új szabályok lekérdezésére és kibővítésére, amikor a szkript fut. Ezen eszközök többsége telepítve van a UNIX rendszerekre, de letöltheti az eszközöket Windows rendszerre is. Ne feledje, hogy a nyílt forráskódú megoldásoknak korlátozott a dedikált támogatása (ha van egyáltalán), ezért az interneten keressen megoldást az esetlegesen felmerülő problémákra vagy kérdésekre. A nyílt forráskódú szoftverek (OSS) közössége bővelkedik hasznos információkban. Jó kiindulópont lehet, ha feliratkozik a Snort egyik levelezési listájára, amelyre a http://www.snort.org/lists.html.
címen lehet feliratkozni.A platformjára vonatkozó részletes telepítési utasításokért mindenképpen olvassa el a README fájlt. Az Oinkmaster alapvető telepítési eljárása abból áll, hogy az oinkmaster.pl és oinkmaster.conf fájlokat kibővítjük a Snort könyvtárunkba (vagy egy általunk megadott könyvtárba), majd az oinkmaster.conf segítségével konfiguráljuk az Oinkmaster-t.
Az oinkmaster.conf fájlt megnyitva kövessük a soron belüli megjegyzéseket az eszköz konfigurálásához. Először is erősítse meg a frissített szabályok helyét webcímként (pl. http://www.snort.org/dl/signatures/snortrules.tar.gz). Ügyeljen arra, hogy az Oinkmaster egy megbízható és jó hírű webhelyre mutasson, különösen, ha a szabályok automatikus letöltését és telepítését választja. Ellenkező esetben fennáll a veszélye annak, hogy sérült (vagy ami még rosszabb, manipulált) szabályokat tölt le, amelyek veszélyeztethetik az IDS-t.
A következő lépésben adja meg a kihagyandó, módosítandó és letiltandó fájlokat. Alapértelmezés szerint az Oinkmaster nem dolgozza fel (azaz kihagyja) a local.rules és a snort.conf fájlokat.
A szkript modifysid funkciója lehetővé teszi az újonnan letöltött szabályok módosítását; gondoljon a modifysid-ra úgy, mint egy keresés és csere funkcióra egy adott szabályhoz, amelyet az SID alapján azonosít. Ezzel a paranccsal módosíthatja egy adott szabály szövegét. A modifysid segítségével például engedélyezhet egy alapértelmezés szerint letiltott szabályt. Ehhez adjon hozzá egy új modifysid parancsot, amely azonosítja az engedélyezni kívánt szabályt, és utasítja a modifysid-et a megjegyzés karakter (#) eltávolítására. Bármikor, amikor egy új szabálykészlet letöltésre kerül, ez a megjegyzés karakter eltávolításra kerül, amikor az Oinkmaster elemzi az adott szabályt. A modifysid parancsot használhatja egy szabály akciótípusának emelésére is. Például a
modifysid 2003 "alert" | "sev1"
parancs a 2003-as SID-vel rendelkező riasztást a sev1 egyéni művelettípusra emeli. Az Oinkmaster ezt úgy éri el, hogy rákeres az “alert” szóra, és kicseréli a “sev1” szóra. És igen, többszörös helyettesítést végez, ezért óvatosan használja.
Az utolsó és legnépszerűbb Oinkmaster funkció, a disablesid, lehetővé teszi a kiválasztott szabályok letiltását. Adja meg az összes olyan szabály SID-jét, amelyet letiltva szeretne tartani. Például a hálózati vizsgálatokra vonatkozó riasztások letiltásához a
disablesid 469, 615, 618, 620
hoz hasonló bejegyzéssel kezdhetjük, miután letöltöttünk és elemeztünk egy új szabálykészletet, az Oinkmaster megkeresi a megadott SID-ket, és kikommentálja a szabályokat. Amíg az Oinkmaster kezeli a szabályokat, addig a szabályok a szabálykészlet frissítése során is letiltva maradnak.
Minden alkalommal, amikor frissíteni szeretné a szabályokat, manuálisan futtassa a szkriptet. Ha bátornak érzi magát, ütemezze be a szkript futtatását és a szabályok rendszeres frissítését. Az Oinkmaster lekérdezi a szabályokat, kibővíti őket, és bemásolja az érzékelő szabálykönyvtárába. Mint a legtöbb OSS esetében, az Oinkmastert is óvatosan használja, és először tanulja meg, hogy mit csinál, és hogyan befolyásolja a környezetét. Például teszteljen egy új szabálykészletet a Snort önteszt üzemmódban történő futtatásával (a snort -T és az egyéb paraméterek használatával), mielőtt a szabályokat a termelési környezetébe telepítené.
Az Oinkmaster segítségével elkerülheti a kétes frissítések letöltésének kockázatát, mivel lehetőséget ad a régi szabályok biztonsági mentésére, és a műveleteiről naplót küld a konzolra. Tekintse át ezt a kimenetet, amely az eltávolított szabályokat, a módosított aktív szabályokat, a nem szabályrevíziókat és az új fájlokat mutatja, annak megerősítésére, hogy az Oinkmaster sikeresen elvégezte a feladatait, valamint az Oinkmaster által módosított szabályok megerősítésére. Ha úgy dönt, hogy az Oinkmaster automatikus futtatását ütemezi, fontolja meg az eredmények e-mailben történő elküldését a felülvizsgálat megkönnyítése érdekében, amint azt a 2. ábra mutatja. A következő példa azt mutatja, hogyan ütemezhető az Oinkmaster napi 6:15-kor történő futtatása a Linux crontab parancs segítségével (a crontab segítségével ütemezhetők a feladatok Linuxban):
15 6 * * * /home/snort/oinkmaster.pl -o /home/snort/rules -b /home/snort/backup 2>&1 | mail -s "Oinkmaster"
Az Oinkmaster paraméterei megadják a szabálykönyvtárat (-o), a biztonsági másolat szabálykönyvtárát (-b), valamint az eredményeket a tulajdonosnak e-mailben elküldő parancsot. A 2>&1 parancs a StdErr kimenetet az StdOut-ra (a konzolra) küldi, mielőtt elküldi az e-mail alkalmazásnak.
Egy Snort-szabály megtekintése
A készletszabályok letiltása vagy alapvető módosításai mellett saját szabályokat is létrehozhat, és tovább testre szabhatja a Snort-szabályokat közvetlenül a környezetéhez. Vegyünk például egy olyan érzékelő telepítést, amely a tűzfalon belüli és kívüli forgalmat figyeli. Bár érdekelheti, hogy hány féregtámadást hárít el a tűzfal, de az, hogy ezek közül a támadások közül bármelyik a hálózaton belülről származik-e, valószínűleg még inkább érdekli. A Snort-szabályok között nemrégiben megjelentek a fenti példához hasonló “tuningolt” szabályok, de sok más is maradt, amelyeket hasonlóan testreszabhat. Az 1. lista egy standard szabályt mutat, amely riaszt, ha az SQL Slammer (más néven Sapphire) férget észleli. Bontsuk gyorsan szét ezt a szabályt. (A szabályokat definiáló összes rendelkezésre álló paraméterről részletes információt a Snort alapos szabálydokumentációjában talál a http://www.snort.org/docs/writing_rules/chap2.html#tth_sec2.3.26 oldalon.)
Minden szabálynak egy sorban kell állnia, és egy szabályakcióval kell kezdődnie, ami ebben az esetben
alert
A szabályakció határozza meg, hogy a Snort hogyan reagál a szabályra, ha kiváltja azt. Módosíthatja a szabály típusát (például egy olyan karakterláncra, mint a ‘sev1’), hogy egyéni kezelést biztosítson – például, hogy a műveletet egyezés esetén eszkalálja. Ez a lépés eltér az előző példától, amelyben az Oinkmaster segítségével módosítottuk egy meglévő szabály riasztási típusát; ebben a példában új szabályt hozunk létre egy meglévő szabályt sablonként használva.
A paraméterek halmaza
udp $EXTERNAL_NET any -> $HOME_NET 1434
megadja a szabály protokollját, IP-címét, portinformációját és a forgalom irányát. Ez a szabály utasítja a Snortot, hogy keressen meg minden olyan UDP csomagot, amely egy hálózati forrásból (amelyet a $EXTERNAL_NET változó határoz meg) a $HOME_NET változóhoz próbál eljutni az 1434-es porton. A legtöbb alapértelmezett szabály elsősorban a $EXTERNAL_NET és a $HOME_NET változókat használja. Néhány szabály azonban ennél specifikusabb változókat is használ. Például a DNS-kiszolgálókra vonatkozó szabályok (a dns.rules fájlban) a $DNS_SERVERS változót használják. Ezeket a változókat a Snort konfigurációs fájljában (általában a snort.conf fájlban) kell definiálni. Opcionálisan hozzon létre saját változókat a topológia tükrözésére (pl. $MAIL_SERVERS) és az egyéni szabályokban való használatra. Definiáljon egy változót a nevével (pl. var MAIL_SERVERS= 192.168.0.20/30), majd hivatkozzon a változóra egy dollárjel előtaggal ($ – pl. $MAIL_SERVERS). A szabály művelete és ezek a paraméterek alkotják a szabály fejlécét.
A szabály opciók tovább finomítják a szabályt, hogy egy gyanús csomag (és csakis egy gyanús csomag) választ váltson ki. Mint sejthető, ezek az aláírások igen részletesek lehetnek, és messze túlmutatnak az egyszerű portillesztésen. Képzeljük el például, milyen hamis pozitív eredményekkel járna, ha ez a Slammer-szabály egyszerűen csak az UDP 1434-es porton zajló forgalomra figyelmeztetne.
A msg opció
msg:"MS-SQL Worm propagation attempt"
egyszerű leírást ad a riasztásról a riasztási és jelentési tevékenységekhez. A content opció
content:"|04|"; depth:1; content:"|81 F1 03 01 04 9B 81 F1 01|";content:"sock"; content:"send";
tartalmazza a nagy- és kisbetűkre érzékeny, ASCII vagy hexadecimális értékekből álló payload mintaillesztő karakterláncot (a hexadecimális értékeket a pipe karakterrel zárja be-|). Több tartalmi opciót is megadhat. A depth opció minden egyes tartalmi opciót követ, és megadja, hogy hány bájtnyi haszonnövényben keresse a megadott tartalmat. Ebben a példában egy csomag akkor vált ki választ, ha az első bájtban a 04-es hexaértéket vagy a hasznos teherben bárhol a többi tartalmat tartalmazza.
A letöltött szabályok gyakran tartalmaznak hivatkozásokat a gyanús exploitra vagy a szabály létrehozásának okára vonatkozó részletes információkra. Egyes jelentési rendszerek támogatják a hivatkozási lehetőséget azáltal, hogy közvetlen hivatkozásokat biztosítanak ezekre az információkra:
reference:bugtraq,5310; reference:bugtraq,5311;reference:url,vil.nai.com/vil/content/v_99992.htm;
A Snort a szabályokat osztályokhoz rendeli, és ezeknek az osztályoknak magas, közepes vagy alacsony prioritást rendel. Jelenleg több mint 30 osztályozás létezik, köztük az admin-kísérlet, a trójai aktivitás, a szolgáltatás megtagadásának kísérlete és a network-scan. Példánkban az osztályozás
classtype:misc-attack
A Snort rögzíti az észlelt behatolások válaszprioritását. Egy külső eszközzel vagy szkripttel tovább elemezheti ezt a prioritást, és intézkedhet a jelentési alkalmazással.
Az utolsó szegmensben
sid:2003; rev:2;
sid egy egyedi Snort-szabályt jelöl, a rev pedig a revíziószámot jelöli. Ezek a tulajdonságok egyedileg azonosítják a szabályt.
A szabály testreszabása
Vizsgáljuk meg, hogyan módosíthatjuk ezt a szabályt, hogy eszkalált riasztást adjon, amikor belső fertőzött állomásokat észlel. Mivel ugyanazt az exploitot kezeljük, mint az eredeti szabály, a szabály tartalmi definíciója ugyanaz marad. Csak az IP-címeket és a forgalom irányát kell módosítanunk. Módosítsuk a forrás IP-címet $HOME_NET-re a következők szerint:
udp $HOME_NET any -> $EXTERNAL_NET 1434
A snort.conf a $EXTERNAL_NET-et “any”-ként definiálja, így ez a szabály továbbra is elkapja a belső hosztokat célzó korrupt csomagokat (ahogy az eredeti szabály is). Most azonban, hogy van egy dedikált szabályunk, amely csak a belső forrás IP-címeket követi, megváltoztathatjuk a művelettípust egy egyéni művelettípusra, amely eszkalált riasztást vált ki.
A jelenlegi Snort-szabályok alapértelmezett szabálykészletében szerepel ez a kimenő Slammer féregfelismerő szabály. Ha azonban egy új féreg, vírus vagy más exploit kezd terjedni, fontolja meg új szabályok létrehozását, amelyek kiemelik a konkrét behatolásokat.
Szabályok készítése
A meglévő vagy egyéni szabályok mellett, amelyeket módosíthat vagy létrehozhat, érdemes lehet más forrásból származó szabályokat is felvenni. Amikor például egy új féreg híre terjed az interneten, a biztonsági webhelyek és hírcsoportok gyorsan közzéteszik az új féreg észlelésére alkalmas egyszeri Snort-szabályokat. Illessze be ezeket az új szabályokat a local.rules fájlba, majd indítsa újra a Snortot, hogy az új szabályok hatályba lépjenek.
A Snort egy olcsó és testre szabható IDS keretrendszerét biztosítja. A közösség által támogatott szabálykészletnek köszönhetően a Snort továbbra is rugalmas és hatékony rendszer. A szabályok naprakészen tartása növeli az éberséget, és csökkenti a hatástalan riasztásokból eredő zajt. Mint minden nyílt forráskódú projekt esetében, ha időt szán a rendszer működésének megértésére, és megismerkedik a közösség által fejlesztett bővítményekkel, az jelentősen javítja a rendszerrel kapcsolatos komfortérzetét, és növeli annak hatékonyságát a környezetében.