Linuxové DMZ - I

5. 2. 2003 | Michal Vymazal | Bezpečnost | 48357×

Nový seriál o bezpečnosti. Úvod do problematiky demilitarizovaných zón. Povinná literatura.

Často jsem na Internetu marně pátral po jakémsi "slabikáři", který by popisoval využití DMZ. Rozumějte, nic složitého. Prostě kuchařku, která by zahrnovala základní pojmy, odkazy na vysvětlivky, nastavení, parametry, modelové topologie apod. Postupem času se mi začal plnit archiv a jednoho dne uzrál nápad, toto kuchařku začít tvořit. I nabídl jsem Leoši Literákovi námět na článek. Jenomže milá "kuchařka" začala nabývat větších a větších rozměrů. Záhy začalo být jasné, že do jednoho článku se tématicky nevejdu, protože tohle je námět spíše na seriál. Co teď? Když seriál, tak seriál, ale to rozhodně není v silách jednoho člověka. Obrátil jsem se tedy do konference autori@abclinuxu.cz se žádostí o pomoc a s nabídkou spolupráce na tomto dílku. Ozval se mi Martin Pavlíček (seznámíte se s ním hned ve druhém dílu) a výsledkem je (tedy spíše bude) seriál, jehož osnovu můžete číst o pár řádek níže.

A protože správný seriál má být nejenom na pokračování, ale i na přání, rozhodli jsme se, že zmíněná osnova nemusí být nutně neměnná. Zkrátka a dobře, pokud budete mít nějaké přání, či námět, zapadající do tohoto seriálu (či se dokonce rozhodnete některý díl sami napsat), rádi sem vaše dílko zařadíme.

Tolik k předmluvě. Vlastní osnova vypadá takto:

1. Úvod do DMZ
2. Stručný popis všech zařízení (router, firewall, v DMZ - mailer, dns, ftp, www, apod.)
3. Modelové topologie
4. Protokoly rodiny TCP/IP
5. Zpět k routeru - podrobněji - třeba příklad LRP
6. Podrobněji firewall, paketové filtry, stavový firewall, proxy, analyzátor paketů
7. Nástroje pro rozbor logů
8. Analýza logů
9. Rozpis odkazů na zajímavé projekty

Úvod do DMZ

V dnešním prvním díle si něco řekneme o linuxových demilitarizovaných zónách, zkráceně DMZ. Výraz DMZ je skutečně zkratkou z anglického výrazu "Demilitarized Zone" a do češtiny se nepřekládá. Je to označení pro tu část (nebo oblast) informačního systému, která je z určitých důvodů oddělena od ostatních zařízení. Většinou se jedná o samostatnou síť, jejíž typické (chcete-li modelové) zapojení je nakresleno na obrázku.

V demilitarizovaných zónách se obvykle nachází zařízení, která zprostředkovávají určité služby jak pro prostředí vnitřní sítě, tak pro prostředí sítě vnější. Vnitřní sítí je zde označována síť typu LAN (Local Area Network). Pod pojmem "Vnější síť" si můžeme představit Internet, linky vedoucí do jiné Vnitřní sítě (tedy Intranet), tzv. "Městské sítě" (WAN -- Wide Area Network) apod.

Vtip je právě v tom, že zařízení umístěná v Demilitarizované zóně jsou sice dostupná jak z Vnější, tak z Vnitřní sítě, nicméně úroveň přístupu může být (a také bývá) pro obě tyto sítě různá. Obvykle je tomu tak, že uživatelé Vnitřní sítě mají rozsáhlejší úroveň přístupu než je tomu u uživatelů sítě Vnější.

Druhým důvodem pro zřizování DMZ je požadavek, aby Vnější síť "neviděla" síť Vnitřní. Rozumný požadavek, co říkáte? Samozřejmě tím nebráníme přístupu uživatelů z Vnitřní sítě na Internet. Jde o to, aby zařízení těchto uživatelů nebyla z Internetu dostupná, případně dostupná s určitým omezením. Podobně je tomu se všemi ostaními zařízeními ve Vnitřní síti.

Stručně řečeno: Chcete-li nějaké zařízení (například server) zpřístupnit z Internetu, umístěte jej do DMZ.

Propojení Internetu, DMZ a Vnitřní sítě:

Podívejme se teď na jednotlivá zařízení poněkud blíže:

Router

Česky směrovač, chcete-li. Jedná se o klasický směrovač obsluhující dvě (v našem případě) síťová rozhraní. Důvod, proč jsem před firewall předřadil ještě směrovač je prostý, a vedou k němu dvě nejčastější modelové topologie:

1. Pokud se vaše vnitřní síť nachází v administrativní budově, pak jsou obvykle veškeré datové a telefonní rozvody zvenčí vytaženy do rozvodny, kde se nachází telefonní ústředna, datové směrovače, datové přepínače a řada dalších zařízení. Z této rozvodny jsou pak vedeny veškeré rozvody směrem do vnitřních sítí. V prostoru ústředny se tedy nacházejí datové směrovače, které jsou připojeny na rozvody, jež směřují do vnitřních sítí.
2. Druhou (a velmi častou) modelovou topologií je rodinný domeček, kde máme bezdrátový spoj (anténu). Vývod z bezdrátového zařízení je opět zapojen do směrovače.

Dalším důvodem je skutečnost, že předřazením směrovače vlastně odlehčíte vlastnímu firewallu. Na směrovač můžeme umístit paketový filtr, čímž "odebereme" firewallu část zátěže. Firewall pak bude zajišťovat zbývající bezpečnostní politiky. Paketový filtr na něj umístíme pro jistotu také, ale přijde ke slovu jen při odstavení směrovače, což je vlastně havarijní scénář.

A cože použijeme jako router? Linuxový stroj, přece. Příznivcům BSD větví se omlouvám (jistěže BSD umí pěkné routery), ale já jsem spíše na ten Linux. Pokud chcete použít bezdiskovou stanici s jednodisketovou distribucí Linuxu, pak můžete zkusit Linux Router Project (LRP)

Můžete si samozřejmě postavit vlastní router na libovolné linuxové distribuci. V takovém případě doporučuji použít tu distribuci, kterou znáte nejlépe. Jako paketový filtr pak nejspíš použijete moduly IPCHAINS nebo (novější) IPTABLES.

Firewall

Firewall je samostatné zařízení obvykle se dvěma a více síťovými rozhraními. Vtip je v tom, že pro každé síťové rozhraní lze uplatnit různé bezpečnostní politiky od úrovně paketového filtru (např. pakety s touto hlavičkou nesmíš předat na to a to rozhraní) až po stavový firewall (např. skrze rozhraní to a to nesmí jít žádné spojení pro telnet). Zde je ovšem na místě jistá obezřetnost, protože přemírou politik můžete vytížit firewall tak, že bude prakticky "nepropustný" a naopak, "ořezáním" politik si můžete způsobit ošklivý tunel do vnitřní sítě.

Paketové filtry

Paketové filtry samozřejmě nejsou zařízení nýbrž služba . Nicméně si zaslouží doušku hned na úvod, protože během dalších pokračování se vám z nich bude možná točit hlava (doufám, že ne moc).

Obsáhlý popis využití paketového filtru nad IPCHAINS naleznete zde (ve formátu PDF): Linux Documentation Project Guides.

Kniha se jmenuje: Securing and Optimizing Linux Red Hat Edition - A Hands on Guide, verze 1.3, autor: Gerhard Mourani. Naposledy aktualizováno: srpen 2000.

Knihu si můžete stáhnout v PDF formátu nebo si rovnou začít číst v HTML.

Kniha je sice zaměřena na distribuci Red Hat 6.2, ale nebuďte zklamaní. Je výtečně napsaná a moudra zde jsou naprosto nezávislá na distribuci.

Pokud si na stránce Linux Documentation Project Guides zvolíte tuto verzi: Securing & Optimizing Linux: The Ultimate Solution, verze 2.0, autor: Gerhard Mourani, posl. aktualizace: červenec 2002, pak se dočtete i o paketovém filtru a stavovém firewallu nad IPTABLES. Tuto verzi ovšem zatím nelze prohlížet on-line, takže si budete muset stáhnout PDF soubor. Tato kniha je mnohem komplexnější a oproti dřívější verzi zde naleznete i řadu obecných kapitol o zabezpečení serverů apod. Angličtina určitě nebude překážkou, takže příjemné počteníčko.

Na úvod by to snad mohlo stačit, v příštím díle se směrovačům a firewallům (to je ale strašné slovo) podíváme na zoubek poněkud blíže. Nebude chybět pojednání o směrovacích tabulkách a podíváme se na zařízení (a služby jimi poskytované) uvnitř DMZ.

Související články

Linuxové DMZ - II (Zařízení v DMZ)
Linuxové DMZ - III (Modelové topologie)
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 Documentation Project Guides
Linux Router Project (LRP)

       

Komentáře

[pistiq]

zdravim, mal by som len 1 poznamku.Clanok sa mi paci,az na tu jednu vec.Po vybornom a zaujimavom uvode nasledoval kopec odkazov na zname Mouraniho knihy.Sam pisem clanky, a pisem ich tak, ze neodkazujem ludi na dalsie stranky ale snazim sa vysvetlit zamer povodneho clanku a pripadne iba na konci zhrnut literaturu.Neberte to ako kritiku , je to iba poznamka.Clanok je inak dobry a tesim sa na pokracovanie.

[Michal Vymazal]

Kritika je opravnena, ale bohuzel mi nezbylo nic jineho, nez se zminenou literaturu zaradit. Zkratka, nutne zlo

[Aldagautr]

tak doufam, ze dalsich dilu se dockame brzy a budou nemene dobre

[Leoš Literák]

pristi tyden uz je nachystany melo by to vychazet s tydennimi intervaly

[Michal 'Mišú' Úradník]

Firewall je IMHO o ochrane a router o routovani... Preto paketovy filter na router nepatri... Maximalne ak nejaka ochrana proti pretazeniu routra floodom... Pokial je router aj firewall ta ista masina (velmi caste riesenie) tak je to samozrejme o inom... Ale ked to uz niekto oddeluje (co ma tiez vela vyhod), tak nech to zostane oddelne :)

A este nieco, dufam, ze bude vysvetlene ze medzi iptables a ipchains je velky rozdiel. Lebo teraz to vyzera ako 2 zamenitelne sluzby.

[Jirka]

No ja tak jenom doplnim, ze kazdy firewall *musi* byt ze sve podstaty zaroven router...
Jinak, pokud mam PC se dvema sitovyma kartama a rikam mu router a za nim PC se trema sitovkama a rikam mu firewall - toz, nic proti gustu, ale valny vyznam to mit takto rozdelene to asi nema. To fakticky obslouzi jedno PC.
Zajimavejsi situace bude, kdyz bych mel nejaky *opravdovy* router - nejake gigabitove ethernety na nekolik poskytovatelu, BGP routing a tak. Za nim pak ma smysl mit samostatny firewall, treba uz z toho duvodu, ze spravne nastavit firewallovaci pravidla na vyse popsanem routeru je znacne netrivialni zalezitost.

[Michal 'Mišú' Úradník]

Aj linux vie routovacie protokoly :) Len treba trosku deamonizovat :)

[Jirka]

To ja samozrejme vim [Druhou otazkou ovsem je, jak by se treba takova striktni linuxova RFC implementace protokolu BGP pobavila s tim, cemu_rikaji_BGP_kluci_od_Cisca . Pozitivne vim, ze vsichni poskytovatele, nabizejici BGP routing, se nechteji bavit s nicim jinym nez s Ciscem, a to pouze od IOS verze X nahoru . Tomu rikam komapatibilita ))]
Nic to ale nemeni na faktu, ze na vetsim routeru (klidne linuxovem - ale nemam na mysli router s jednou radiovou kartou a jednou sitovkou) fakticky neni zadna sranda nastavit zaroven firewall tak, aby si clovek mohl byt primerene jisty, ze to ma nastavene dostatecne dobre

[kolisko]

*musi* ??? co to?? to jsou mi ale novinky. Co takhle FW bridge? kolisko

[kokot]

Ja vim, ze jste odpornici na bezpecnost a ze pres vase firewalli se nikdo nedostane, ale stejne by me zajimalo proc takhle tvrde prosazujete oddeleni routeru od firewallu. Souhlasim s vama, je to urcite lepsi a zvlast pri hodne vytizene rychle siti optimalni reseni. Nicmene v domecku s radiovym nebo telefenim pripojenim 33kbit/s ktere mame doma staci dat obe funkce dohromady.. nebo ne? jake jsou duvody pouzit pro nekriticke aplikace oddelene stroje? Dalsi argument je, ze kdyz prijdete nekam do firmy tak na vas vybafnou, ze slyseli o tom ze linux nekdo takhle pouziva a na to vyclenily starou 486 a na vic nemaji. Pokud pak je stesti, ze ty rozvody v budove jsou koncipovany tak jak pisete daji se aspon premluvit ale jinak ne. Proc na router pouzit linux a ne nejake levne cisco jak to casto byva? je to zamerenim serialu (ok vase vec) nebo je k tomu jiny duvod?

[Leoš Literák]

aby nedoslo k omylu: tento serial pisi redaktori, nepodilel se na nem zadny zamestnanec AbcLinuxu s.r.o.

[Jiří Svoboda]

Levne Cisco? To existuje? Neni to nahodou oxymoron?

[Michal 'Mišú' Úradník]

Oxymoron nie je cisco :) Ale soft ktory programujem (za casu na cas) :) oxymoron.fobie.cz

[BoodOk]

Spise dotaz nez pripominka. Linux FW nastavovat umim, ale terminus technicus nejsou moje hobby. Neni nahodou stavovy firewall uplatnovani stavovych pravidel (mluvim o iptables) RELATED atd.? Zakazat spojeni na telnet (23) je prece bezestavova zalezitost - paketovy filtr. Opravte mne prosim, mylim-li se. Nejaka vysvetleni jsou na: http://www.nss.co.uk/Certification/Firewalls/FirewallsWhitePaper.htm

[Jiří Svoboda]

Mam za to, ze se nemylis.

[Michal Vymazal]

Mate naprostou pravdu. Potiz je v tom, ze se snazime psat obecne. Vztahnout stavovy firewall jen k IPTABLES by asi nebylo nejlepsi reseni, protoze bychom pak mohli docilit toho, ze bude cast ctenaru klast rovnitko mezi stavovy firewall a IPTABLES. Ale stavy lze vyhodnocovat (ano, velmi omezene) i napr. pomoci IPCHAINS - a hele mam soutezni otazku! Ktere pak to jsou? Mn, ehm, ja nasel jeden. Ale velmi, velmi pouzitelny ....

[BoodOK]

... až po stavový firewall (např. skrze rozhraní to a to nesmí jít žádné spojení pro telnet)

Mi slo spis o to, ze ta veta podle mne neni spravna. O nejakem rovnitku stavovy firewall = vylucne iptables jsem snad ani nepsal. Jinak stavove pravidlo pro IPchains by mne skutecne zajimalo. Podle meho neni totiz stav ve smyslu teto diskuze vlastnosti packetu, ale konverzace. A nemylimli se, IPchains si stav konverzace neudrzuji.

[Michal Vymazal]

Ja osobne jsem toho nazoru, ze SYN paket je stav, takze vyhodnocovanim SYN paketu (povol, zakaz) mam vlastne jakysi jednoduchoucky stavovy firewall. Vic toho samozrejme z IPCHAINS nedostanu, coz je skoda. U BSD klonu bylo mozne kontrolovat vsechny flagy TCP paketu (je jich tusim 6). Pokud tedy telnet zakazi tak, ze zakazi vsechny SYN pakety na port telnetu, pak jsem vlastne zakazal telnetove spojeni pomoci stavu. Pochopitelne, zakazal jsem pouze "prichozi" spojeni.

[BoodOk]

Hmmm, ale pokud je SYN stav, pak je stavem i IP adresa, cislo portu a vse ostatni. Nakonec udrzovat konverzaci v naprosto nestavovem prostredi (tedy stroje by si z predchoziho paketu nepamatovali vubec nic) by bylo skutecne zabavne Tohle by se melo VYJASNIT!

[Michal Kubeček]

Nesouhlasím. Rozdíl mezi stavovým a bezstavovým firewallem je v tom, že bezstavový firewall posuzuje každý paket zvlášť - o jeho propuštění nebo zadržení rozhodují výhradně jeho hlavičky a obsah. Takže stejný paket vyvolá pokaždé stejnou reakci. Oproti tomu stavový firewall bere v úvahu i obsah předchozích paketů, takže stejný paket může jednou projít a podruhé ne. Proto je rozlišování podle SYN jednoznačně bezstavové.

[Michal Vymazal]

No, ale jak potom posoudite stav pri navazovani spojeni? Jde totiz o to, ze pred timto paketem zadny jiny paket nebyl, takze nelze posuzovat obsah predchozich paketu. A to je pripad, ktery jsem mel na mysli. Proto souhlasim s nazorem, ze SYN paket je vlastne ten nejjednodussi pripad stavu. Pravdou je, ze v tomto pripade vyvola stejny paket pokazde stejnou reakci - je to zkratka ten nejjednodussi a pocatecni pripad.

[Michal Kubeček]

Ale ne. I situace, kdy ještě žádný paket nepřišel, je stavem - stavový automat musí mít vždy nějaký počáteční stav. Jenže zatímco netfilter umožňuje tento stav odlišit od situace, kdy už nějaké pakety přišly předtím, bezstavový filtr (ipchains) to neumí. V tom je právě stavovost firewallu. Teoreticky byste se mohl hádat, že i filtr z řady 2.2 je stavový, protože má degenerovaný stavový automat o jednom stavu, ale tak hluboko snad neklesneme... SYN není stav, stejně jako jím není URG, PSH, FIN, ToS, TTL, port, zdrojová adresa ani žádná jiná položka hlavičky (nebo jejich kombinace). Stav je interní veličina, kterou si udržuje netfilter a která se mění podle určitých pravidel v závislosti na současné hodnotě a příchozích paketech. Stavovost netfilteru je právě v tom, že kromě obsahu paketu umí při rozhodování zohlednit i hodnotu této veličiny.

Modelový příklad: zkuste si

ipchains -A input -p tcp 80 -y -j ACCEPT
iptables -A INPUT -p tcp --dport 80 --syn -m state --state NEW -j ACCEPT

(v syntaxi pro ipchains budou asi drobné chyby, už jsem je dlouho nepoužíval) a pošlete si tam rychle za sebou dva zcela identické pakety navazující spojení. Ipchains nemá jinou možnost než pustit oba. Netfilter u toho druhého pozná, že není v pořádku a nepustí ho. Rozliší totiž situaci, kdy "předtím nic nebylo" od situace, kdy už má navázané spojení a nový paket s ním koliduje. A to je ten stav.

[dejf]

Jde o to co myslime stavem, z hlediska konstrukce pocitace je vskutku stavem kazdy kus Ip adresy a dalsi veci, protoze PC je deterministicky automat s nepredstavitelnym mnozstvim stavu. Bavime-li se o aplikaci a jejich stavech pak je mezi IPchains a IPtables rozdil.

[Chroooostal]

Fuuuuuj, ty lidi sou hnusny, vzdycky cloveku seberou co chtel rict )) No nic, pockam si, az zde vyjdou nejake clanky urovne http://www.root.cz/clanek/1497 , nebo toho predchoziho dilu, a pak si kazdy pokritizuje dle libosti )) Hlavne nezapomente, ze [citat]Nejčastějším grafickým režimem je X server.[/citat] ))

[kolisko]

Zdravim, budete v serialu popisovat take FW v hybridnim (bridgeovacim/routovacim) rezimu s podporou VLANu? Popripade jeste s kombinaci s QoS a VPN (IPSec) tunelama pro vzdaleny pristupy? Je to pro mne momentalne aktualni tema, takze bych se rad neco priucil. kolisko

[Michal Vymazal]

No, v osnove to zatim nemame a v mem archivu toho mnoho neni. Vidim to tak, ze zminene tema nabidneme zajemcum na zpracovani. Nechcete nam neco maleho napsat? Ale ted vazne, pokud se k tomu odhodlate, budeme jedine radi.

[kolisko]

jestli to rozchodim (ted to testuju, konecne vysledky budou pocitam do 14-ti dnu), a dokopu se to napsat, tak proc ne. Je to preci jenom nekolik ruznych oblasti splacanych do jednoho celku, takze to chce cas. Vysledky jsou zajimave (puvodne toto umi pouze komercni zarizeni od 1mil Kc vyse, nebo nase company na nic levnejsi nenarazila), zatim to vypada, ze takovou kombinaci linux zvlada. Ted budu testovat hlavne stabilitu a vykonnost. Ale myslim, ze to je dost specificka zalezitost a ze ne kazdy v tom najde sve zalibeni. Nevim, jestli to pro ctenare ABCLinuxu bude vubec zajimave. Navody na takoveto "PAkonfigurace" jsem tu zatim nevidel. Spise se tu resi standardnejsi v praxi obecne vyuzitelne zalezitosti. kolisko

[Leoš Literák]

no, ja bych to tu klidne publikoval. uz treba jen pro tu prestiz

[Mackiada]

Já jsem každopádně pro!! Přesně tohle také chystám v naší firmě a návodů není nikdy dost. Hlavně bych potřeboval rady ohledně zabezpečení. Nastavení IPSecu už tady bylo, ale něco praktickýho ohledně zabezpečení moc ne... Rád bych využíval tokeny, ale asi s tím bude problém.