Portál AbcLinuxu, 25. dubna 2024 09:08
Takový firewall si dnes může jako "výchozí konfiguraci" dovolit blokovat veškerá příchozí spojení a povolit odchozí. Výjimky pro příchozí spojení jsou jasně definovatelné právě v důsledku toho, že došlo k separaci "klientských" a "serverových" služeb. Naznačená konfigurace firewallu podle mě velmi zásadně zvyšuje bezpečnost počítačů uvnitř LAN.To je dost naivní pohled, který fungoval tak před 10 lety. Většina zranitelností vám dnes přijde mailem nebo se k vám dostane tak že procházíte web. Botnet sítě s tímto modelem "firewallu" počítají a nemají s tím sebemenší problém.
při použití základního firewallu na routeru už firewall na samotném počítači skoro není potřebaDalší přežitek: model všechno nebo nic. Na síti by měl každý kopat sám za sebe a věřit jen tomu čemu musí.
Ptám se, jak po nasazení IPv6 toto řešit, abych nezabil tu výhodu end-to-end konektivity? Samozřejmě můžu použít klasický stavový firewall přes iptables, a blokovat příchozí spojení. Firemní sítě tak budou velmi pravděpodobně nastaveny. Očekávám, že aplikace typu Skype apod. stejně na IPv6 nebodou moci očekávat, že se vždy bude možné přímé připojení na jiné počítače s IPv6.Vyřešíte to normálně tak že povolíte ten port pro tu aplikaci. Nic lepšího s tím neuděláte. Jestli se aplikace spojuje ven nebo někdo na ni je z hlediska bezpečnosti té aplikace dost jedno. Absence modelu "interní sítě" aspoň donutí lidi se zamyslet nad zabezpečením té aplikace samotné.
Další přežitek: model všechno nebo nic. Na síti by měl každý kopat sám za sebe a věřit jen tomu čemu musí.Tak prezitek? A tim sam za sebe myslite ty uzivatele netusi co je to IP adresa a veri nigerijskym mailum? Nebo ze by si tito lide najednou zacli platit administratory?
Absence modelu "interní sítě" aspoň donutí lidi se zamyslet nad zabezpečením té aplikace samotné.Ktere lidi? Programatory nebo uzivatele? No stejne je to jedno, v realnem svete se nezamysli ani jedna skupina.
tim sam za sebe myslite ty uzivatele netusi co je to IP adresa a veri nigerijskym mailum?Ne, to je myšleno na počítače na síti.
Ktere lidi? Programatory nebo uzivatele?Nejspíš ti, co na dané síti zodpovídají za zabezpečení dat.
Tak jistě, že se malware přizpůsobil, a existuje mnoho zranitelností pro které firewall není překážka. Stojím si ale za tím, že použití popsaného firewallu omezí prostor pro významnou část útoků.Takový firewall si dnes může jako "výchozí konfiguraci" dovolit blokovat veškerá příchozí spojení a povolit odchozí. Výjimky pro příchozí spojení jsou jasně definovatelné právě v důsledku toho, že došlo k separaci "klientských" a "serverových" služeb. Naznačená konfigurace firewallu podle mě velmi zásadně zvyšuje bezpečnost počítačů uvnitř LAN.To je dost naivní pohled, který fungoval tak před 10 lety. Většina zranitelností vám dnes přijde mailem nebo se k vám dostane tak že procházíte web. Botnet sítě s tímto modelem "firewallu" počítají a nemají s tím sebemenší problém.
Na jednu stranu je to pravda, ale neplatí to podle mě obecně ve všech situacích. Např. při instalaci OS, ladění nějakého embedded systému, nebo nějaké nouzové opravě, kdy jsem rád že se mi povede nabootovat nějaký systém a nahodit síť, tak jsem rád, že LAN je oddělena od "nebezpečí" otevřeného internetu. Dnes už to není tak hrozné, ale pamatuji si instalaci Windows 2000 s veřejnou IP adresou nastavenou během instalace. Během 15 minut, ještě než jsem stihl nainstalovat firewall byl ten počítač v podstatě mrtvý. Samozřejmě je to chyba toho systému, ale takové situace nastávají, alespoň já se s nimi setkávám. Model vnitřní síť vs. internet je jaksi proti filosofii původního internetu. Z nějakého důvodu ho ale správci používají i v sítích bez NATu, takže to není z nouze ctnost. Já to vnímám tak, že internet je dnes prostě jiný, než s jakými ideály byl navrhován, a realita se tomu přizpůsobuje. V praxi ideály obvykle podlehnou řešení, které je "funkční", ale ne hezké. Často čtu, že bychom na IPv6 měli využít příležistosi, a udělat to celé lépe, neopakovat chyby jako IPv4 NAT. Podle mě to tak úplně nedopadne. Ještě k tomu multicastu. Nepředpokládám, že by začal být použitelný hned po rozšíření IPv6. Problém není jen v dostupnosti adres, ale také v řízení sítě, resp. účtování a omezování kapacity v sítích ISP. Nevím, jestli IPv6 přichází v této problematice s nějakým reálným řešením. V současnosti multicast funguje v akademických sítích (třeba CESNET) nebo v rámci jednoho ISP pro IPTV apod. (a i uvnitř sítě jednoho ISP není provoz multicastu triviální na správu), v globálním internetu v podstatě neexistuje, i když aplikace, pro které by se vyloženě hodil, jsou.při použití základního firewallu na routeru už firewall na samotném počítači skoro není potřebaDalší přežitek: model všechno nebo nic. Na síti by měl každý kopat sám za sebe a věřit jen tomu čemu musí.
30.6.2010 10:08
pavlix | skóre: 54
| blog: pavlix
Model vnitřní síť vs. internet je jaksi proti filosofii původního internetu. Z nějakého důvodu ho ale správci používají i v sítích bez NATu, takže to není z nouze ctnost.Vnitřní samosatně adresovaná síť bez NATu (nebo nějaké proxy) je naprosto legitimní i když dneska ne tak obvyklé použití TCP/IP. Jen už se z takové sítě nepodíváš na net.
Často čtu, že bychom na IPv6 měli využít příležistosi, a udělat to celé lépe, neopakovat chyby jako IPv4 NAT. Podle mě to tak úplně nedopadne.Zase hop nebo trop, ne. Snad nechceš tvrdit, že se nevyvarujeme žádných (nebo dejme tomu podstatného množství) chyb či nedostatků? Nikdo nikdy netvrdil, že tím vyřešíme všechny.
Ještě k tomu multicastu. Nepředpokládám, že by začal být použitelný hned po rozšíření IPv6. Problém není jen v dostupnosti adres, ale také v řízení sítě, resp. účtování a omezování kapacity v sítích ISP. Nevím, jestli IPv6 přichází v této problematice s nějakým reálným řešením.Problím v účtování a omezování sítě mi přijde na multicastu víceméně nezávislý.
v globálním internetu v podstatě neexistujeProtože na IPv4 musíš žádat o každou globální multicast adresu. Na IPv6 si můžeš globální multicast adresy přidělovat sám. Ale uznávám, že globální multicasting není jednoduchá oblast.
Vnitřní samosatně adresovaná síť bez NATu (nebo nějaké proxy) je naprosto legitimní i když dneska ne tak obvyklé použití TCP/IP. Jen už se z takové sítě nepodíváš na net.Já se ale z té sítě chci "dostat na net", alespoň ve smyslu, že si přes http budu moci stáhout třeba balíčky v instalátoru systému. TCP/IP v izolované síti se používá třeba v různých průmyslových aplikacích, ale je tendence, aby ta síť nebyla tak úplně izolovaná. Aby se z ní daly dostávat informace třeba v rámci firemni LAN nebo VPN. Často se to řeší skrze NAT, takže IPv6 je pokrok. Nicméně průmyslová sféra je v tomhle dost konzervativní. Jsou rádi, že ta zařízení v posledních letech jakž-takž zvládají IPv4. Dokud to uspokojivě funguje (třebaže ze síťového hlediska nehezky), je nějaká změna bezdůvodná. Ohledně multicastu jsem viděl vyjádření v tom smyslu, že unicast je prostě tok dat z místa A do B. Kdežto multicast je z A do teoreticky nekonečně míst. Mám např. od ISP konektivitu 100 Mbit/s NIX a 10 MBit/s tranzit. Pokud bych pustil multicast skrze ten tranzit (a ještě by to šlo přes různé tranzitní ISP), asi bude dost problém v tom, řešit to omezení. Ode mě půjde 10 Mbit/s, ale v sítí ISP se ten tok může násobit, a tranzitní linky zatížit n×10 Mbit/s. Pokud se pletu, budu rád, když mě někdo opraví. Samozřejmě v praxi bude v této situaci zapojeno víc ISP, čímž se problém komplikuje. Multicast zřejmě není úplně kompatibilní se současným modelem prodeje konektivity.
Stojím si ale za tím, že použití popsaného firewallu omezí prostor pro významnou část útoků.Pokud 10% říkáte podstatná část tak proč ne :) Neříkám že takový firewall je a priori k hovnu, jen že sám o sobě je hned za tím hovnem...
Např. při instalaci OS, ladění nějakého embedded systému, nebo nějaké nouzové opravě, kdy jsem rád že se mi povede nabootovat nějaký systém a nahodit síť, tak jsem rád, že LAN je oddělena od "nebezpečí" otevřeného internetu.To je fajn, ale proč by měla mít vaše účetní ze svého PC přístup k tomu embedded nebo čerstvě vylíhnutému OS? Pokud se stroj sám o sobě neumí "bránit" tak mu lze simulovat samozřejmě soukromou síť pomocí předřazeného FW, ale je blbost cpát jeden FW na stovky strojů o kterých nic nevím; proto název "všechno nebo nic".
30.6.2010 09:42
pavlix | skóre: 54
| blog: pavlix
Vlivem nasazování NATu, jsme se na IPv4 dostali do stavu, kdy end-to-end konektivita není obecně dostupná.Což zdaleka neznamená, že jsi v bezpečí.
Ptám se, jak po nasazení IPv6 toto řešit, abych nezabil tu výhodu end-to-end konektivity? Samozřejmě můžu použít klasický stavový firewall přes iptables, a blokovat příchozí spojení.Přesně tak, úplně stejně jako na IPv4. Plus nadefinujete výjimky. Problém IP maškarády je ten, že u ní nelze nadefinovat jednoduché výjimky (ano o portforwardu vím). Skype bych sem netahal, ten žije právě z toho, že si ty díry vytvoří. Navíc bavit se o bezpečnostních rizikách a používat na stejné síti takový balast (šifrováním zamotaná binárka aktivně se bránící debuggerům) je přinejmenším podivné.
Samozřejmě tu zůstává velmi významná výhoda, že na IPv6 mají všechy PC za tím případným firewallem globální adresu, takže si snadno můžu třeba to příchozí ssh povolit. Ale to musí řešit správce firewallu, což není vždy průchodné a hned dostupné řešení.A o tom to je. Buď to správce povolí, nebo ho musíš obcházet. Ale i v tom obcházení ti IPv6 pomůže, protože jakmile získáš kanál pro obousměrnou komunikaci, můžeš v něm udělat tunel a naroutovat si celou takto neomezenou síť.
Nebo je jím přesun pořádného firewallu na každý jednotlivý počítač v LAN?I přesun firewallu je rozhodnutím provozovatele sítě.
To netvrdím, napsal jsem to jako výchozí tvrzení. Důsledkem tohoto faktu je podle mě obecná možnost nasazení stavového firewallu na hranici LAN, který by-default blokuje příchozí spojení. Aplikace s takovým stavem musí počítat kvůli těm NATům, takže pokud mám takový firewall, neomezím zásadně nejvíce používané služby (a to je krom webu ten Skype, ICQ, nebo ať jsme korektní tak i Jabber, apod.).Vlivem nasazování NATu, jsme se na IPv4 dostali do stavu, kdy end-to-end konektivita není obecně dostupná.Což zdaleka neznamená, že jsi v bezpečí.
To chápu, je mi jasná i ta výhoda, že nemusím řešit pofidérní port forward. Pokud ale někdo argumentuje, že IPv6 např. vyřeší současné značné problémy s posíláním souborů nezi IM klienty (to čtu a poslochám velmi často), tak to podle mě není obecná pravda. Když budu mít IPv6 a oba klienti budou v takovéhle síti za firewallem, stejně bude potřeba server pro zprostředkování přenosu.Ptám se, jak po nasazení IPv6 toto řešit, abych nezabil tu výhodu end-to-end konektivity? Samozřejmě můžu použít klasický stavový firewall přes iptables, a blokovat příchozí spojení.Přesně tak, úplně stejně jako na IPv4. Plus nadefinujete výjimky. Problém IP maškarády je ten, že u ní nelze nadefinovat jednoduché výjimky (ano o portforwardu vím). Skype bych sem netahal, ten žije právě z toho, že si ty díry vytvoří. Navíc bavit se o bezpečnostních rizikách a používat na stejné síti takový balast (šifrováním zamotaná binárka aktivně se bránící debuggerům) je přinejmenším podivné.
Souhlas.Samozřejmě tu zůstává velmi významná výhoda, že na IPv6 mají všechy PC za tím případným firewallem globální adresu, takže si snadno můžu třeba to příchozí ssh povolit. Ale to musí řešit správce firewallu, což není vždy průchodné a hned dostupné řešení.A o tom to je. Buď to správce povolí, nebo ho musíš obcházet. Ale i v tom obcházení ti IPv6 pomůže, protože jakmile získáš kanál pro obousměrnou komunikaci, můžeš v něm udělat tunel a naroutovat si celou takto neomezenou síť.
30.6.2010 10:17
pavlix | skóre: 54
| blog: pavlix
Důsledkem tohoto faktu je podle mě obecná možnost nasazení stavového firewallu na hranici LANToto není pravda. Možnost nasazení takového stavového firewallu je na nasazení NAT zcela nezávislá, který by-default blokuje příchozí spojení. Podle tvého tvrzení bych nemohl nasadit stavový firewall bez NATu, což na mnoha místech dělám.
Pokud ale někdo argumentuje, že IPv6 např. vyřeší současné značné problémy s posíláním souborů nezi IM klienty (to čtu a poslochám velmi často), tak to podle mě není obecná pravda.Ano, neplatí to úplně obecně a nefunguje to samo od sebe při nasazení příliš restriktivního firewallu. Ale firewall je tu právě od toho, aby šly věci zakázat.
Když budu mít IPv6 a oba klienti budou v takovéhle síti za firewallem, stejně bude potřeba server pro zprostředkování přenosu.Vyčítáš jiným zjednodušení, které neplatí obecně a sám se ho dopouštíš. To co píšeš, je obcházení firewallu. Pokud správce uzná za vhodné, může firewall nastavit tak, aby ho nebylo potřeba obcházet. Nezapomeň, že doma jsi buď správcem ty, nebo někdo, kdo nastaví firewall, jak si řekneš. Jako zaměstnanec zase nemáš na mimopracovní komunikaci po internetu nárok, maximálně je tolerována. Pro pracovní komunikaci si můžeš vyžádat takovou konfiguraci, aby fungovala.
Toto není pravda. Možnost nasazení takového stavového firewallu je na nasazení NAT zcela nezávislá, který by-default blokuje příchozí spojení. Podle tvého tvrzení bych nemohl nasadit stavový firewall bez NATu, což na mnoha místech dělám.Myslel jsem to jinak. Podle mě, kdyby historicky nedošlo k takovému rozšíření NATu, tak by velká část běžně používaných aplikací (třeba typu instant messaging) mohla počítat s dostupností end-to-end konektivity, a nasazení zmíněného firewallu by takové aplikace odřízlo. Tady to byla spíš taková úvaha co by kdyby. Nic důležitého o čem bych se chtěl dohadovat. Souvislost těchto dvou technologií jsem rozhodně nemyslel jako technickou, spíš jako věc historického vývoje.
Vyčítáš jiným zjednodušení, které neplatí obecně a sám se ho dopouštíš. To co píšeš, je obcházení firewallu. Pokud správce uzná za vhodné, může firewall nastavit tak, aby ho nebylo potřeba obcházet. Nezapomeň, že doma jsi buď správcem ty, nebo někdo, kdo nastaví firewall, jak si řekneš. Jako zaměstnanec zase nemáš na mimopracovní komunikaci po internetu nárok, maximálně je tolerována. Pro pracovní komunikaci si můžeš vyžádat takovou konfiguraci, aby fungovala.Ano zjednodušil jsem to, možná až moc. Doma je to jedna věc, když jsem někde zaměstnán tak je to taky jiná situace. Mě se často stává, že se někdě můžu připojit do sítě (nechce se mi psát, že do Internetu) - na návštěvě, ve škole, v cizí firmě, v hotelu a podobě. Takové sítě jsou často nastavé všelijak a třeba i dost restriktivně. A reálná možnost nějak komunikovat se správcem té sítě, nebo po něm něco chtít prostě není. A když jsem v takové síti, chci se podívat na web, připojit se na IM a chci aby "vše fungovalo" (jako obyčejný uživatel, co se připojí někde na WiFi, ne jako síťový odborník). Nemalá část úspěchu Skype spočívá v tom, že na jakémkoliv počítači s Windows, kde mám třeba minimální práva, a kde jakýmkoliv způsobem jde přístup na web (klidně proxy, firewall etc.), tak tam Skype "prostě funguje". To je (možná smutná) realita, ať je to z pohledu znalého člověka špatně jak chce. I když princip fungování Skype není moc pěkný, o tom se nepřu. Ale normálním lidem "to funguje".
30.6.2010 11:18
pavlix | skóre: 54
| blog: pavlix
Myslel jsem to jinak. Podle mě, kdyby historicky nedošlo k takovému rozšíření NATu, tak by velká část běžně používaných aplikací (třeba typu instant messaging) mohla počítat s dostupností end-to-end konektivity, a nasazení zmíněného firewallu by takové aplikace odřízlo. Tady to byla spíš taková úvaha co by kdyby. Nic důležitého o čem bych se chtěl dohadovat.To už zní o něco věrohodněji, ale vycházíš z předpokladu, že tu dlouho byla IP maškaráda a pak teprve se vymyslel stavový firewall. Nemůžu se dogooglit konkrétních roků, ale všechno nasvědčuje tomu, že stavový firewall je tu minimálně stejně dlouho jako maškaráda. Tudíž, by se aplikace musely přizpůsobit tak jako tak.
Ano zjednodušil jsem to, možná až moc. Doma je to jedna věc, když jsem někde zaměstnán tak je to taky jiná situace. Mě se často stává, že se někdě můžu připojit do sítě (nechce se mi psát, že do Internetu) - na návštěvě, ve škole, v cizí firmě, v hotelu a podobě. Takové sítě jsou často nastavé všelijak a třeba i dost restriktivně.Mám zkušenost, že tyto sítě (například ve školicích střediskách) jsou restriktivnější jak než IP maškaráda, tak než klasický stavový firewall. Takže jedinou možností plnohodnotné konektivity je tunel.
A když jsem v takové síti, chci se podívat na web, připojit se na IM a chci aby "vše fungovalo" (jako obyčejný uživatel, co se připojí někde na WiFi, ne jako síťový odborník).Co chceš je jedna věc, a co dostaneš druhá. Odesílání mailu na port 25 ti fungovat obvykle nebude.
Nemalá část úspěchu Skype spočívá v tom, že na jakémkoliv počítači s Windows, kde mám třeba minimální práva, a kde jakýmkoliv způsobem jde přístup na web (klidně proxy, firewall etc.), tak tam Skype "prostě funguje".Nemalá část úspěchu Skype spočívá v tom, že je to malware.
I když princip fungování Skype není moc pěkný, o tom se nepřu. Ale normálním lidem "to funguje".Normálním lidem funguje to, co jim kdo nainstaluje (nebo poradí nainstalovat). Horší je, když se z normálních lidí stanou rádobyodborníci, kteří přesvědčují a nutí ostatní nainstalovat si to samé. Horší je, že jim to funguje jen do té doby, dokud nenarazí na člověka, který není ochotný si ten malware do počítače instalovat. Skype tímhle problémem trpí extrémně, ICQ už o něco méně díky využití alternativních klientů (tuším stále ještě v rozporu s podmínkami užití). Holt pak tito normální uživatelé musí ještě navíc přemýšlet, kterému člověku můžou zavolat kterým programem, takže ve výsledku to mají ještě složitější (a pokud místo toho zvolí mobilní telefon, tak i o dost dražší).
30.6.2010 10:43
pavlix | skóre: 54
| blog: pavlix
Aplikace s takovým stavem musí počítat kvůli těm NATům,Ono bohatě stačí, aby protokol fungoval pouze na TCP a UDP spojení (ano, musí se k UDP chovat jako ke spojení navzdory povaze UDP!) na modelu klient-server, kdy server je na veřejné adrese. V tomhle se běžné nastavení Firwallu neliší, takže není důvod, aby takovéto klient/server aplikace své chování měnily.
takže pokud mám takový firewall, neomezím zásadně nejvíce používané služby (a to je krom webu ten SkypeSkype je prokazatelný malware, takže škoda mluvit.
ICQICQ (progam) je taky dost na hranici, ICQ (síť) umí využívat veřejné adresy ke zkrácení cesty komunikace, pokud vím.
nebo ať jsme korektní tak i Jabber, apod.).Jabber má spoustu doplňkových služeb, které za NATem buď nefungují, nebo musí pomoct externí počítač (proxy, STUN apod). Zapomněl jsi na e-mail, který taky v dnešní době funguje na modelu klient/server (původně to byla z hlediska uživatele p2p služba, i když se po technické stránce jedná o klient/server). Nenapadlo tě někdy, že to přizpůsobení zpozdilo nástup třeba VoIP o celé roky? Mít veřejné adresy, tak stačilo na firewallu povolit VoIP, zapojit telefon a hotovo. Skype by tak možná ani nestihl vzniknout.
Nenapadlo tě někdy, že to přizpůsobení zpozdilo nástup třeba VoIP o celé roky? Mít veřejné adresy, tak stačilo na firewallu povolit VoIP, zapojit telefon a hotovo. Skype by tak možná ani nestihl vzniknout.Ano, VoIP tu rozhodně mohlo být dříve. Ale Skype lidé často používají proto, že jim jde i v práci v restriktivně nastavené síti. Je to realita, nepište mi, že když si to správce nepřeje, lidé by Skype neměli používat. Prostě tohle "co by se mělo a nemělo" je válcováno realitou. Možná se pohybuji v jiném prostředí než ty, ale já to takhle vnímám. Právě to stačilo na firewallu povolit VoIP je někdy nepřekonatelná věc.
... coz se resi pracovnim radem a IT policy...
druha vec je, ze skype treba dost vyznamne setri penize za zahranicni volani
30.6.2010 11:34
pavlix | skóre: 54
| blog: pavlix
Vedení firmy to v principu nevadí, ale admin nějaké speciální nastavení nedovolíTím zkráceně říkáš, že firmě vládne admin a ne její vedení.
a vedení firmy mu to těžko nařídí protože tomu nerozumí, jsou rádi, že ho tam mají, a nejde o bussiness-critical věc.Tím zkráceně říkáš, že vedení firmy jsou debilové. Máš nějaký tip na takovou firmu, že bych tam šel dělat admina? Nějaká testovací síť na hraní, kde si můžu dělat co chci, by se mi hodila. A vedení bych přikázal, ať mi nakoupí ještě pár pěkných hraček, pokud nechce, abych jim zpomalil síť :).
30.6.2010 11:34
pavlix | skóre: 54
| blog: pavlix
Možná se pohybuji v jiném prostředí než ty, ale já to takhle vnímám.Možná. A možná na to taky nahlížím hodně z technického pohledu.
Právě to stačilo na firewallu povolit VoIP je někdy nepřekonatelná věc.Jo, taky už jsem byl ve firmě, kde (všechny) věci střídavě fungovaly a nefungovaly a se správcem firewallu se nešlo domluvit, protože neměl dostatečné znalosti. Jsem si vědom jednoduchosti nasazení Skype samotnými uživateli a že daleko lépe než firewall funguje audit programového vybavení a pohrůžka vyhazovem při opakovaném zneužití firemních počítačů k činnosti zakázané firemní bezpečnostní politikou, kterou zaměstnanec jistě podepsal. Chápu i to, že je realita jiná a jsem s tím celkem smířený :).
30.6.2010 08:17
Michal Fecko | skóre: 31
| blog: Poznámkový blog
30.6.2010 13:24
Vašek Lorenc | skóre: 27
30.6.2010 13:36
pavlix | skóre: 54
| blog: pavlix
IPv6 nasazujeme taky, ale problém je pořád v segmentu u koncových uživatelů -- víceméně nulové bezpečnostní prvky (každý si může dělat RA, odpovídat na DHCP) a k tomu ke všemu ještě existující Privacy Extension (a následně špatná dohledatelnost kohokoliv podle IPv6 adresy) to celé komplikují.. Nicméně to je jen otázka času a částečně se tomu dá vyjít naproti např. za pomoci 802.1x.Takže staré problémy z IPv4, všechno? Ta bezpečnost místních sítí je dost netriviální problém, díval bych se po 802.1x pro linkovou vrstvu, ale taky IPsec pro vrstvu síťovou. Síť zabezpečená proti lokálnímu zneužití nebude nikdy tak hladce konfigurovatelná.
Nicméně na serverech už by to i šlo, tam je to zpravidla snazší.. tedy, pominu-li nutnost nějakého IPv6 firewallu, je-li ho zapotřebí.Takže proti IPv4 žádné nové problémy?
Takže staré problémy z IPv4, všechno?No vlastne az na mobility a multicast je vsechno pri starem. Nejak si nedovedu predstavit jak ISP resi security atack z nejakeho mobilniho IPcka, ktere se zrovna nachazelo v jejich siti. Globalni multicast je vlastne taky novinka. Problem s IPv6 je v tom, ze vsechno co jste museli resit musite vyresit znovu a jinak. Treba igmp, pokud chcete omezovat uzivatelum prijem lokalniho multicastu, tak nasadite igmp filtry. Pokud je ovsem utocnik mazanej tak posle do site specialni multicast packet a rekne "ja jsem multicast router" a pak je igmp filtry ignoruji a on kuze koukat na jaky kanal chcete. Tohle se samozrejme na IPv6 vyresit da, dokonce to musite vyresit ale jinak. U IPv6 se tohle vsechno resi pres ICMP.
30.6.2010 22:03
pavlix | skóre: 54
| blog: pavlix
No vlastne az na mobility a multicast je vsechno pri starem.V podstatě jo. Není se čeho bát... Ty možnosti většího zabezpečení sice v IPv6 jsou (některé jsou backportované i do IPv4), ale jednak je spousta věcí ještě v návrhu (secure NDP apod), a jednak o ně málokdo stojí.
Pokud je ovsem utocnik mazanej tak posle do site specialni multicast packet a rekne "ja jsem multicast router" a pak je igmp filtry ignoruji a on kuze koukat na jaky kanal chcete.To patří do té třídy link-local bezpečnosti, která se tradičně spíš ignorovala.
Nasazovani IPv6 probiha jinak.IPv6 je hlavně pečlivě porovnávané s IPv4 (což je dobře), jakákoli změna k horšímu se kritizuje a opravuje (viz privacy extensions). Teda aspoň pokud to jde (například zapamatovatelnost obecných adres těžko).
2.7.2010 23:13
pavlix | skóre: 54
| blog: pavlix
no, vše při starém.. snad s tím rozdílem, že pro IPv4 už spousta prvků má vlastnosti a schopnosti obrany (dhcp snooping),Což to je jasné, když tu máme ten protokol už nějakých 30 let :).
což pro IPv6 zatím není. A to _je_ rozdíl.Tak to je implementační rozdíl :).
Není to nová věc, ale v tom výčtu chyběla.. a tohle je jeden z dost nepříjemných problémů nasazování IPv6.Přišlo by mi naopak zvláštní, kdyby nový protokol změny v implementaci nevyžadoval. Nevím, co na tom může koho překvapovat. Disclaimer: Implementaci IPv6 ve firmě už jsem několika lidem rozmlouval a ač nevím, jak velký měly moje rady vliv, implementaci odložili na neurčito. Připomněl jsem jim pár věcí, kterými by se museli zabývat a navrhnul alternativy některých řešení, které šly provést i na IPv4.
2.7.2010 23:15
pavlix | skóre: 54
| blog: pavlix
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.