Linuxové DMZ - III

19. 2. 2003 | Michal Vymazal | Bezpečnost | 21456×

Modelové topologie. Vyhodnocování provozu systému - IDS.

Modelové topologie

V dnešním díle se podíváme na několik klasických zapojení demilitarizovaných zón. Tato zapojení se vyskytují dosti často a vlastně představují jakási "vzorová" schémata. V praxi se pro takovéto vzory vžilo označení "modelové topologie".

Ptáte se proč model? Na jednu stranu to vypadá, jako bychom měli nesmyslnou snahu vměstnat veškerá možná zapojení do několika vzorů! Ale v tom je právě jádro pudla. Ano, nalézt ty základní způsoby zapojení, popsat je a vytvořit z nich jakési vzory. Uznejte, že stavět (zapojovat, chcete-li) podle vzoru je mnohem snažší a jednodušší než vymýšlet celé zapojení znovu. Univerzální zapojení je mnohem praktičtější než desítky zapojení šitých "na míru", nehledě na to, že při každém takovém novém, nepřenosném zapojení, můžeme snáze udělat chybu. Ať již z neznalosti, nezkušenosti apod.

Další výhodou je možnost hned několikastupňové kontroly. Již samotný fakt, že naše zapojení neodpovídá žádné modelové topologii může sice znamenat, že potřebujeme něco mimořádného, ale na druhé straně může také znamenat, že jsme někde udělali chybu nebo něco přehlédli. Prostě vzor je Vzor. Nejedná se zdaleka jen o zapojení samotné, jde o nastavení systému, zkušenosti (teď mám na mysli zkušenosti těch ostatních), možnost porovnat svá zjištění s archivem někoho jiného apod.

Pojďme se tedy podívat na pár modelových topologií pro stavbu DMZ.

Domáci PC (PPP protokol, modem)

Tuto sestavu asi zná většina z nás. Modem je připojen skrze standardní rozhraní (obvykle to bývá sériový port) k počítači na straně jedné a k telefonní lince na straně druhé. Vlastně se jedná o "vytáčený spoj", kde protějším koncem je tzv. Modem pool na straně našeho zprostředkovatele připojení k Internetu (ISP - Internet Service Provider). Toto modelové zapojení uvádím pro úplnost. Demilitarizovanou zónu bychom zde hledali těžko, nicméně paketový filtr na zmíněném domácím počítači rozhodně neuškodí. Popis jedné starší verzi takového paketového filtru nad IPCHAINS můžete nalézt zde (linuxworld.cz). Na novější verzi se stále pracuje .

Připojení jednoho PC pomocí kabelové televize nebo rádiového spoje je topologicky podobné. Místo modemu však použijeme samostatnou síťovou kartu a převodník pro kabelovou televizi nebo pro anténu.

Linuxová DMZ, připojení k Internetu bez routeru

Zde vidíme základní a nejjednodušší (samozřejmě, nejjednodušší z topologického hlediska) zapojení DMZ. Můžeme mu říkat třeba "Výchozí schéma". Hezký popis paketového filtru pro tuto topologii je zde (root.cz) mějte však na paměti, že autor provozuje vlastně celou DMZ "na firewallu", takže se skutečně jedná jen o zjednodušující příklad.

Linuxová DMZ, samostatné rozhraní pro Modem pool, připojení k Internetu bez routeru

Výchozí schéma jsme rozšířili o tzv. Modem pool, což je zařízení umožňující připojení volajícího skrze telefonní linku. Na našem obrázku je Modem pool znázorněn samostatným počítačem a modemem, což je vlastně nejjednodušší případ. Takto nakreslený Modem pool obslouží právě jednoho volajícího (máme jen jeden modem). Pokud potřebujete obsloužit zároveň více volajících, bude vhodnější využít samostatný směrovač s moduly pro modem pool. Modem pool je opět připojen, skrze samostatné síťové rozhraní, do firewallu.

Linuxová DMZ, samostatné rozhraní pro WAN, připojení k Internetu bez routeru

Naše Výchozí schéma jsme rozšířili o samostatné síťové rozhraní (na straně firewallu) pro WAN (Wide Area Network). Pod pojmem WAN si můžeme představit tzv. Meziměstské sítě, Městské sítě apod. Skrze WAN budou obvykle připojeny další kaceláře, pobočky apod.

Linuxová DMZ, samostatná rozhraní pro WAN a Modem pool, připojení k Internetu skrze router

Předchozí schémata jsem "sloučil" v jedno a přidal router mezi firewall a Internet. K tomuto kroku mě vedlo několik důvodů.

1. Odlehčení směrování na firewallu.
2. Vlastní router představuje "záložní firewall" pro případ havarijního scénáře na firewallu (výpadek firewallu). Mějme na paměti, že výpadek firewallu odřízne Vnitřní síť jak od DMZ, tak od vnějšího světa.
3. Na routeru se může nacházet proxy server pro poštu (MTA on firewall). Důvod je opět zřejmý: odlehčíme firewallu a poštovní server v DMZ pak nemusí být viditelný zvenčí. Záložní poštovní proxy server pak ponecháme na firewallu (za normálních okolností nebude v činnosti) pro případ výpadku routeru.
4. Paketový filtr je v provozu jak na firewallu, tak na routeru. Zatímco paketový filtr na routeru bude mít pravidla spíše jednodušší, paketový filtr na firewallu již bude mít pravidla na úrovni bezpečnostních politik. Zde právě můžeme s výhodou využít faktu, že pro každé prostředí (WAN, Modem pool, Internet, DMZ) používáme na firewallu samostatné síťové rozhraní.
5. Můžeme samostatně vyhodnocovat logy jak z routeru, tak z firewallu.
6. Logy z DMZ budeme vyhodnocovat rovněž samostatně a to pro každý stroj zvlášť.

Tolik k stručnému popisu této modelové topologie. Vidíme, že se vlastně jedná o jakousi stavebnici (což je dobře, tak to má vypadat). Základem je firewall, DMZ, Vnitřní síť a připojení k Internetu. Ostatní díly jako WAN nebo Modem pool můžeme přidávat postupně.

Malé odbočení

Ve schématu zatím nejsou popsány způsoby pro vyhodnocování a předávání varovných zpráv pro správce. Sami tušíte, že se jedná o námět na samostatný seriál (kdo se hlásí? , takže zde se o těchto systémech zmíníme jen stručně.

Vyhodnocování provozu systému - využití IDS

Výraz IDS znamená Intrusion Detection System a do češtiny se obvykle nepřekládá. V podstatě jde o to, že na sledovaném systému (nebo systémech) máme v provozu modul, který umí vyhodnocovat provoz (např. odposlech síťového provozu, vyhodnocení provozu na určitém síťovém rozhraní, sledování provozu určitých démonů apod.) Lidově mu přezdíváme "práskač" aneb "já nežaluju, ale hlásit se to musí". Vynikajícím Open Source IDS je např. Snort. Řadu článků s jeho popisem můžete nalézt zde (underground.cz) nebo zde (root.cz). Vřele doporučuji si stáhnout manuál ke snortu a celý jej přečíst, rozhodně neprohloupíte.

Možná jsem byl až příliš stručný, takže jen na vysvětlenou: IDS systémy (jak ostatně vyplývá z jejich anglického označení) byly původně určeny ke zjišťování "podezřelých" činností v informačních systémech a tedy v podstatě k detekci průniků do těchto systémů. V dnešní době vývoj opět poněkud pokročil, takže je můžeme využít i na výše uvedené vyhodnocování vlastního provozu. Vtip je v tom, že "nestandardní" provoz nemusí nutně způsobovat jen čísi nenechavé ruce, ale také chybná nastavení systému, poruchy aktivních prvků (směrovače, přepínače) apod. Výraz IDS zůstal, ale využití je dnes mnohem širší. Zkrátka, IDS systémy dnes používáme na vyhodnocování provozu informačních systémů.

Odesílání varovných (kritických) zpráv

Určitě jste už zjistili, že samotný IDS je sice hezká věc, ale další (a neméně důležitou věcí) je předávání kritických (či varovných, záleží na rozhodnutí správce) zpráv člověku, tedy správci. Vzhlem k tomu, že celému tématu IDS a souvisejícím modulům pro předávání zpráv se budeme věnovat později, zmíním se zde krátce o modulu logcheck, anglický popis najdete například zde (freeos.com). Pomocí modulu logcheck zajistíme "prohledání" logů IDS (v našem případě snort) a odeslání kritických zpráv na elektronický účet správce. Sám snort totiž odesílání zpráv nezajišťuje. Svá hlášení ukládá do provozního deníku (log), kde je musí logcheck "najít" a pak odeslat.

A konečně se dostávám k tomu, proč jsem vlastně poněkud "předběhl" osnovu a rozepsal se o IDS a vyhodnocovacích modulech přesto, že tyto patří do XX bodu naší osnovy.

První soutěžní otázka zní - do kterého bodu osnovy patří systémy IDS a moduly pro zasílání zpráv?

Jde o to, že odesílání varovných zpráv bude mít vliv i na topologii našeho zapojení. Záleží na tom, jakým způsobem budeme zasílat zprávy správci. V zásadě tak můžeme učinit prostřednictvím elektronické pošty nebo přenosného telefonu.

Tak napřed elektronickou poštu:

1. Hlavní kanál pro odesílání zpráv bude směřovat do Internetu.
2. Záložní kanál bude směřovat do WAN nebo skrze Modem pool

Pro varovné zprávy stačí jedna cílová adresa elektronické pošty, pro kritické volíme alespoň dvě cílové adresy. Zprávy lze pochopitelně odesílat i na přenosné telefony, jen si budete muset zvolit operátora, který takovéto "internetové SMS" umožní .

A nyní přenosný telefon nebo-li SMS gateway:

Je vcelku jasné, že zmíněnou SMS bránu budete muset někam připojit a já se ptám:

Druhá soutěžní otázka zní - kam připojíte SMS gateway? Nezapomeňte na havarijní scénář.

Pro dnešek je to ode mne vše, uvidíme se v některém z pokračování seriálu.

Související články

Linuxové DMZ - I (Úvod do problematiky)
Linuxové DMZ - II (Zařízení v DMZ)
Linuxové DMZ - IV (Protokoly rodiny TCP/IP)
Linuxové DMZ - V (Routery a minidistribuce LRP)
Linuxové DMZ - VI (Firewally)
Linuxové DMZ - VII (Paketové filtry)

Odkazy a zdroje

Linux Networking HOWTO
Snort - OpenSource IDS

       

Komentáře

[Zdenek Kaminski]

Dobry den. Moc nerozumim nekolika pojmum: 1) v prvnim obrazku autor pise, ze se jedna o "zjednodusujici" priklad a ze vlastne DMZ se provozuje "na firewallu". Ja si naopak myslim, ze se jedna o typicky priklad a konec koncu by se to takto melo i stavet. Proc, uvadim nize. 2) u posledniho obrazku je zarazen pred firewall router. Rekneme, ze smysl "zalohovat firewall pro pripad jeho hardwaroveho vypadku je nejakym zpusobem rozumne". Avsak davat tam router proto, ze odlehcim smerovani firewallu, no. Vy mu odhlecite jen tim, ze na router date "proxy server pro smtp". No ten tu postu stejne musi preposlat dale, a to asi do DMZ, ne? Tim tomu moc neusetrite. A navic ten router, pokud jej nekdo hackne prave skrze sluzbu, ktera na nem bezi, tak si z toho stroje bude moci delat co chce, a vy to na firewallu neosetrite. Navic pisete, ze smtp v DMZ pak nemusi byt z venci videt... Proc je teda v DMZ? Ja si vzdycky myslel, ze vsechny verejne sluzby se daji do DMZ a pred firewallem NEMA nic bezet. A eventuelne smtp v DMZ slouzi tak, ze veskerou postu pro danou firmu preposila na vnitrni smtp server ve vnitrni siti. A ten vnitrni smtp naopak veskerou postu preposila pres "externi" smtp v DMZ. A hlavne, kdyz nekdo hackne sluzbu v DMZ, tak na firewallu je snad nadefinovano, ze na ten server muze jit pouze ona sluzba a odchazet z nej taky muze pouze ona sluzba a tak utocnikovi hodne zneprijemnit zivot. Protoze ve chvili, kdy bude na onom povolenem portu provozovat cokoliv jineho, nez to co tam ma bezet, tak to okamzite poznate (nebude Vam chodit napr. posta.. ) a zasahnete. Firewall castecne straci smysl, kdyz bezi nejake sluzby pred nim, ne? A nebo me to Yenya spatne ucil. A nebo jsem to nepochopil... Ale jinak pekny clanek. Preji hezky den.

[Michal Vymazal]

Tedy: 1) Nejedna se o prvni obrazek, ale o druhy obrazek Osobne jsem zastancem nazoru, ze provozovat "celou DMZ" na jednom stroji neni prilis stastne reseni. Mozna to vyhovi nejake male kancelari a pak to mohu oznacit za prave ten zjednodusujici priklad. V urcitem okamziku totiz zacne narustat vytizeni celeho stroje a to muze jit az k neunosnym cislum. Pokud provozuji jednotlive sluzby v DMZ samostatne (na samostatnych strojich), pak rozdelim i zatez. Cast "access listu" bude na routeru prave z toho duvodu, ze se jedna o router providera. 2) SMTP se nachazi v DMZ, na routeru/firewallu pak bezi konfigurace zvana SMTP on firewall. Opet, jedna se o standardni konfiguraci, ktera je dobre popsana zde http://www.postfix.org/faq.html#firewall Jinak, firewall neztraci smysl, pokud bezi nejaka sluzba pred nim (pred nim je prece x smerovacu, hranicnich smerovacu a hromady dalsich veci). Firewall vynucuje dodrzovani bezpecnostnich politik pro pristup do DMZ, pripadne do Vnitrni site.

[Zdenek Kaminski]

Hmm, asi mluvime jeden o koze a druhy o voze. Takze zkusim se zeptat jinak: 1) Pisete, ze cast access listu bezi na routeru providera. Fajn, takze relevantni zbytek pobezi predpokladam na tom mem firewallu. Zajimalo by mne, jak vypadaji "access listy" na strane providera, a jak vypadaji ty me. Vite, mame na kolejich (2 C site) vcelku hodne sofistikovany firewall + pocitani dat pro kazdou IP + omezovani provozu to cele na 100Mbit full duplex (ktery JE vytizeny - a myslim si, ze drtiva vetsina firem je pripojena na neco mensiho nez 2Mbit) a nejak se nemohu zbavit dojmu, ze hardware typu athlon 800MHz to musi utahnout, i kdyby nechtel. Me by porad zajimalo, O KOLIK, JAK usetrite/pomuzete tomu Vasemu firewallu. Ktere pakety se k nemu proste VUBEC nedostanou, protoze je zahodi router pred firewallem? Nebo kde to usetreni sakra bude? Chtel bych odpoved typu: "na routeru omezim/zahodim tyto pakety..." a tim padem usetrim protoze je nebude muset zpracovavat muj firewall. Porad mi neni jasny pojem "provozovani DMZ na firewallu". Existuje pojem "provozovani DMZ jinde, nez na firewallu"? 2) Ja ve svem prispevku nemluvil o tom, ze vsechny sluzby v DMZ bezi na jednom stroji. Je snad nad slunce jasne, ze jedna sluzba = jeden stroj je to nejbezpecnejsi. O tom, ze smtp on firewall je standardni konfigurace slysim poprve. Mozna to je standardni situace pro firmy, ktere neinvestuji do bezpecnosti, nemaji na vice nez jeden stroj pro "pripojeni na internet". Pokud bezi na firewallu krome samotneho firewallu jeste nejaka sluzba, stava se ten firewall zabezpecny tak, jak je minimum(bezpecnost(sluzba)),bezpecnost(firewall)). 3) Hmm, dale jste v clanku psal, ze router je zaroven takove zalozni reseni, kdyby hardwarove odesel firewall (coz jsem ve svem puvodnim prispevku komentoval tak,ze snad nejaky smysl to ma, avsak...) V dalsich odpovedich pisete, ze to je router providera (ja se domnival, ze muj router). No ja bych chtel videt providera, ktery Vam na routeru udela zalozni konfiguraci neceho vaseho a kdyz Vam odejde Vas fw, tak ze ji vicemene okazmite pusti. A naopak. Jak chcete nahrazovat router poskytovatele. Co to tam bude hardware na tom routeru? Cisco? Juniper? To mate COSA kartu v tom PC? Nebo to je obycejne PCcko, ktere Tim vasim PC muzete nahradit? Nebo je architektutra toho firewallu jina nez PC, ze nahradite router poskytovatele? Zalozni ucel/smysl routeru si prosim po Vasich odpovedich skrtneme... 4) Ulehcit firewallu tim, ze na routeru providera (ci asi spise jinde nez na router providera) pobezi SMTP a vy budete provozovat smtp on firewall (podle standardniho reseni podle FAQ postfixu, cha cha ), tak ty emaily k Vam stejne nejak dorazit musi, takze stejne ty pakety musi projit firewallem na firewallu. A jeste je bude muset ten firewall zpracovat, takze jeste uriznete kus vykonu CPU pro samotne smtp.... Prominte, bez urazky, zacinam mit dojem, ze do toho delate sice mozna 19let, ale je to spise 76krat opakovana ctvrtletni zkusenost... Snad ma posledni impertinence nebude duvodem k tomu, ze mi neodpovite. Ja si ji vsak odpustil nedokazal... Preji hezky den.

[Michal Vymazal]

Ach ty koleje Tak predne, onen predrazeny router "zahodi" vsechny pakety s adresami patricimi do rfc 1918 (privatni site). Podobne pakety nemaji ve verejnych sitich co delat. Zda na nej umistite dalsi black list, je jen na vas. Podrobnejsi vysvetleni/odliseni ohledne router vs. firewall mate v poslednim (mem) prispevku. Nu, a pokud ani to nebude stacit, pak budete muset na NIST. Mimochodem, kolik politik mate na tom firewallu a jaka je uroven logovani? SMTP on firewall je popsan jako standardni konfigurace napr. na strankach postfixu (precetl jste si ten odkaz opravdu pozorne? - vzdyt to je SMTP proxy, ktera jen preposila postu). NIST je zde: http://csrc.nist.gov/publications/drafts.html

[Zdenek Kaminski]

Ach ty koleje??? Nevim, cemu se porad smejete. Hmm, vite, kolik procent paketu, ktere jdou z internetu a maji privatni adresy dorazi na takovy "router"? Myslim, ze to neni ani promile (a to mam overeno na strojich umistenych v Internetu). Tak jake pak odlehcovani!!! Black list? Zblaznil jste se? Kolik si myslite, ze date do blacklistu ip adres? 100, 200? To jako bude firewall prochazet sekvencne tolik pravidel, nez propusti paket k dalsimu rozhodovani (resp. zjisti, ze ho muze propustit dal)? Ptal jste se me na kolejni firewall, fajn: bezi nam to na 433 Celeronu a tyka se to 2 Ccek. No, nerozumim presne otazce "kolik mame politik", ale z toho, co logujeme to snad bude jasne: Takze logujeme VSECHNY syn pakety, VSECHNY UDP pakety. Dale kazde spojeni oznacime a spocitame, kolik v nem proteklo dat a to pro spojeni, ktera jdou mimo sit muni.cz. Merime proste kompletni traffic. Dale nektere skupiny IP adres maji z venku povolene nektere sluzby, nektere nic a nektere maji specificke pozadavky. A tem IP adresam, ktere prekroci nejakou kvotu, tak se provoz omezuje. Mozna si reknete, ze s takovou davkou logovani jsme nachylni na nejaky DoS, no neni to pravda... Generujeme si dynamicky black list (na ktery jsem ovsem vyse nadaval)... Rekl bych, ze 100Mbit full duplex je dostatence provereni takoveho routeru/firewallu. Nevidim jediny duvod, abychom si pred tento stroj davali nejaky router, ktery by mu odlehcil. Jste mimo misu. Jaky je rozdil mezi routerem a firewallem, to je mi jasne, to mi opravdu rikat nemusite. Avsak firewall, kdyz ma vice sitovych karet, tak proste routovat musi TAKE. Router v podstate kazde PC, ktere ma vice nez 1 fyzicke rozhrani a pakety proste preposilat musi. A ze na tom bezi firewall, tak to najednou routerem prestava byt? Ad smtp on firewall. Ano, ten odkaz jsem si cetl opravdu pozorne. I kdyz je to proste jen proxy, co to preposila, tak nez smtp dostane email, tak se ten email musi poskladat z tech paketu, ktere prijdou a ten smtp server ten email musi zpracovat ve smyslu, ze zjisti, ze to posila dal. Naco tam je sakra ta DMZ, kdyz mate "smtp on firewall". Ach jo. Rekl bych, ze jste nepochopil pojem DMZ... A jeste k tomu hardwarovemu zalohovani. Neodpovedel jste mi. Btw, jak tu jiz nekdo psal, cim vice prvku v siti, a ja dodam ZA SEBOU, tim vetsi nespolehlivost... Myslim, ze nase debata zacina ztracet smysl... Preji Vam hezky den a mene matoucich clanku...

[BoodOk]

Mam pocit, ze autor nechava celou infrastrukturu zbytecne nabobtnavat. Nakonec tam bude mit tolik prvku a zaloznich reseni, ze s urcitosti sem tam neco nepojede. Uprimne receno, vzhledem k tomu, jaky typ ctenaru cte tento server, by se dosavadni 3 casti Vaseho serialu dali v pohode shrnout do jedne. Na jednu stranu tady jsou Jaderne noviny a na druhou stranu clanek o DMZ hemzici se spustou zbytecnych schemat a nepodlozenych zduvodneni a zaveru. Presne ve smyslu predchoziho prispevku. Pridam zalozni/odlechcujici prvek (router) a jsem jako v pohode. Ze mi beh cele site nyni zavisi ne na 1, ale 2 strojich prece nikoho netrapi. Ve skutecnosti se uroven spolehlivosti site snizi. A jakym zpusobem se firewallu routerem odlehci tusi zrejme pouze sam autor. Nakonec totiz vetsinu routovani musi provadet firewall, protoze router ma v zasade 2 routy. Default a route do vnitrni site na IP vnejsiho adapteru firewallu.

[Michal Vymazal]

Dobre se bavim Delam do toho asi 19 let. A ted strucne, ten router pred firewallem je obvykle providera a cast "access listu" se nachazi prave na nem. Bavime se totiz o univerzalnich modelovych topologiich, coz jsem vysvetloval jiz nekolikrat. Schema pro svou potrebu si samozrejme muzete zjednodusit a umistit si treba celou DMZ na firewall Obcas to lide i delaji. Casem zjisti, ze provozovat apache, ftp server, mysql, smtp, squid a buh vi co jeste, prinasi tomu nebohemu stroji znacne zatizeni a vlastne "se miji ucinkem". Pokud jednotlive sluzby umistite do DMZ na samostatne stroje, pak rozdelite zatez.

[Matlas]

No, abych rekl pravdu, duvody, ktere autor uvadi pro pridani smerovace pred firewall mi prijdou docela legracni. detaily urcite nebudu rozepisovat, jsou pekne recene v predchozim prispevku. Ja si myslim, ze duvodem, proc je namalovan router na poslednim z obrazku je ten, ze autor nekde videl pekny obrazek se screening routerem a nepochopil presne, jaka je jeho uloha (nebo vlastnik). Precetl jsem si predchozi dva dily clanku a myslim, ze by se to dalo shrnout nasledujicim konstatovanim: 'ucitel je o lekci dale, nez zaci'. Ikdyz v tomto pripade se nabizi otazka, nejsou-li zaci dale. Na odpovedi na otazky kolem IDS se taktez docela tesim. Uz ze samotneho zadani ukolu se mi zda, ze autor toho o IDS moc nevi. Jedna otazka pro autora clanku: co kdyz moje IDS sonda pouziva stealth rozhrani? Muzu si pres nej taky poslat mail s 'varovnym hlasenim'?

[Michal Vymazal]

Mam za to, ze router pred firewallem jsem vysvetloval jiz v prvnim dilu. Nebavime se o "kutilskych" schematech. Bavime se o standartnich modelovych topologiich. Navic, ten router nemusi nutne patrit vam, casto se jedna o zarizeni providera. Ohledne IDS - za prve to bylo male odboceni, ktere jsem zaradil proto, ze ma vliv na topologii, za druhe davam prednost "pasivnim" senzorum. Otazka pro vas - procpak by IDS sonda mela pouzivat stealth rozhrani? A otazka druha - cetl jste skutecne clanek pozorne? Jaka byla druha soutezni otazka. Nebyla nahodou o tom, kam umistite do topologie SMS gateway?

[Matlas]

Bingo, to jsem prave myslel. Mozna by stalo za uvahu, kdyz popisujete schema spise uvest, ze jde o screening router a ne placat nesmysly o 'snizeni smerovaci zateze'. pokud totiz jde o zarizeni providera, tak tam urcite NENI proto, aby vasemu FW odlehcilo jak hezky pisete. Berte muj predchozi post jako podnet, kterak zlepsit a zvysit hodnotu clanku. To co jste napsal fakt smrdi chybami a moznosti rozdilne interpretace. A k tomu odboceni: odboceni vam jeste nedava pravo mast ctenare.

[Michal Vymazal]

Ach jo. Cetl jste opravdu pozorne, nebo se chcete jen hadat? V tom pripade ale doporucuji nejake jine forum. Takze jeste jednou. Na tom "predrazenem" routeru jsou access listy vaseho providera. Tento router by mel (mimo jine) zarucovat, ze provider bude dodrzovat RFC 1918 a tedy jeho infrastruktura nebude predavat pakety s adresami z rozsahu pro privatni site (uvedene v danem RFC). Takze na routeru se asi bude nachazet paketovy filtr, ktery je popsan v literature v prvnim dilu. Jinymi slovy, tyto pakety se az k vasemu firewallu nedostanou a tim jsme mu ponekud odlehcili (tomu firewallu). A k vasim komentarum: Moznost komentare vam jeste NEDAVA PRAVO URAZET AUTORY. Nebo se mylim? Pokud se chcete opravdu ponorit do hloubky, zkuste si pro priste projit dokumenty NIST, neboli National Institute of Standards and Technology, k doptani zde: http://csrc.nist.gov/publications/drafts.html Budu se o nich samozrejme zminovat na konci serialu Jsou to sice americke normy a tudiz jsou v anglickem jazyce, ale s tim se asi budeme muset smirit (tedy s tou anglictinou). Mimochodem, procpak se podepisujete jen prezdivkou?

[Matlas]

Specialne kvuli vam jsem si precetl znovu prvni dil. O tom routeru se v nem pise to same co v dile tretim. Nechapu proc ten problem stale omilate dokola. Osobne jsem povazoval vec za uzavrenou. Ted ve me budite zdani urazene jesitnosti. Jeste k jednomu postu, ktery me zaujal: pokud vas architektura a bezpecnost siti zivi skutecne 19 let jak tvrdite, budete asi opravdu nadupany machr. Neberu vam to. Jen jsem se dosud nesetkal s nikym, koho by v CR tato problematika zivila tak dlouho. Publikoval jste v nejakem odbornem periodiku? (snazim se dopatrat, zda jsem od vas neco cetl, nebo zda jsem vas nekde potkal). Jelikoz nas zivi velice podobna problematika, je to dost mozne. Hadat se s vami skutecne nechci, ale pokud vas urazi fakta a reference na literaturu, pak je mi z toho spise smutno. Proc se podepisuji prezdivkou? No protoze me pod ni na Internetu spousta lidi identifikuje a zna. Vadi vam to moc?

[Matlas]

Jinak NIST samozrejme znam. Je to velice dobry zdroj informaci.

[Matlas]

btw. kde autor bere to presvedceni, ze IDS je degradovano pouze na sondu poslouchajici nekde na siti. Videl uz nejaky takovy system v provozu?

[Michal Vymazal]

Cetl jste pozorne? Bavime se o vyhodnocovani provozu. K tomu mohu vyuzit IDS a to tak, ze budu JEN POSLOUCHAT. Vysledky techto "odposlechu" si pak urcitym zpusobem zpracuji, rozdelim (podle danych kriterii) na zpravy varovne a kriticke a odeslu spravcum.

[Matlas]

Jak jsem rekl, IDS neni pouze sonda, ktera je povesena na siti. IDS je infrastruktura. Kdyz to, co jste napsal bude cist uplny laik, nabude dojmu, ze IDS je neco, co mu posloucha na siti a sbira data. Nic jineho, ze to nedela. Pokud od toho chce vice, musi shanet dalsi sw. nebo si to napsat. To ale prece neni pravda. Doporucil bych vam neco si o problematice precist, nez zacnete delat zavery. Pro zacatek zkuste treba toto: Terry Escamilla - Intrusion Detection: Network Security Beyond the Firewall,ISBN: 0471290009 myslim, ze vam to da pomerne dost materialu k premysleni. Jestli chcete, muzu dat dalsi reference. (Snort opravdu neni jediny - zkuste se podivat na ISS, Cisco Netranger, ...atd.)

[Michal Vymazal]

Aha, takze tady jseme si nerozumeli. Ja v clanku pisi, ze pouzivam IDS na vyhodnocovani provozu. Tedy jen nasloucham, nic vic. Zkratka - v nasem pripade vyuzivame pasivni IDS sondu na vyhodnocovani provozu systemu. Mel jsem za to, ze jsem to dostatecne vysvetlil jiz v textu, ale pokud vas to mate, muzeme text upravit. Mast ctenare samozrejme nechci

[Jiri Bajer]

Mozna by stalo za to zminit v ramci IDS take trosku jiny pohled na ochranu pred vniknutim - patch do jadra LIDS. Zatimco SNORT detekuje sitove pokusy o prekonani filtrovacich pravidel firewallu, LIDS pomahaji v druhe fazi - pri utoku na sluzby. Umozni omezit prava privilegovanych SUID procesu pro pripad, ze obsahuji bezecnostni diry. Viz. www.lids.org BTW: Kolisko, nechtel jsi pred casem o LIDS neco napsat? B-)

[Matlas]

Ano, LIDS je jedna z variant. Znamena ale, ze mate linux. Pokud se mame bavit v obecne rovine, je jasne, ze system musi byt(teda mel by byt) zabezpecen. Btw. co rikate na RSBAC (www.rsbac.org) Ja s nim mam pomerne dobre zkusennosti.

[Michal Vymazal]

Vzhledem k tomu, ze nas predrazeny router tu vyvolal malou polemiku (ale uzitecnou - Martine, dame to FAQ, co rikas?), pokusim se o male shrnuti. Obecne cas od casu panuje presvedceni, ze router v podstate plni funkci firewallu a naopak. Obavam se, ze to je velmi nestastne reseni, protoze: 1) Hlavni funkci routeru je smerovani paketu. Chceme, aby to delal s co nejvetsi spolehlivosti (co nejmene "ztracenych" paketu) a aby to delal rychle. 2) Hlavni funkci firewallu ale naproti tomu je vynucovani bezpecnostnich politik. Citite ten rozdil? Zatimco na routeru si mohu dovolit omezit vsechny ostatni veci (krome smerovani, samozrejme) - tedy napr. logovani udalosti (na rozumnou miru, potrebuji vykon stroje pro rychlost smerovani), pak na firewallu jsou na prvnim miste prave ty politiky (lidove receno, co neni dovoleno, je zakazano . Ano, oba stroje maji smerovaci tabulky a samozrejme oba smeruji pakety, ale kazdy z nich ma jine priority. Co se paketovych filtru tyce: Paketove filtry se budou nachazet na obou strojich, ale na kazdem budou plnit jinou funkci. Na routeru to bude krome "access listu" napr. vynuceni dodrzovani rfc 1918 o rozsazich adres pro privatni site (pakety s temito adresami by se nemely potulovat Internetem). Na firewallu to jiz budou nase bezpecnostni politiky - napr. pristup k sluzbam v DMZ, maskovani Vnitrni site apod. Firewall tech stupnu ma samozrejme vice, paketove filtry tvori jejich zaklad, ale to Martin jiz psal v minulem dilu. Snad jsem to vysvetlil dostatecne. Podrobnejsi popis routeru uz ma nejspis Martin v dalsim dilu (osnova).