Vlákno názorů k článku Praktické zkušenosti: nasazení IPv6 v síti poskytovatele od Filip Jirsák - Výchozím nastavením firewallu v zákaznickém routeru je jednoduchý...
-
Filip JirsákStříbrný podporovatelVýchozím nastavením firewallu v zákaznickém routeru je jednoduchý stavový filtr, který nepropustí do sítě zákazníka nic zvenčí, pokud zákazník nenaváže spojení sám. V podstatě to má stejný bezpečnostní účinek jako NAT u IPv4.</um>
To by ten firewall musel být hodně děravý, aby měl stejný bezpečnostní účinek, jako NAT.
-
Filip JirsákStříbrný podporovatel
Co myslíte, že se stane, když na vnější rozhraní toho vašeho NATu dorazí paket s cílovou adresou 10.0.24.12? Já tipuju, že si ho NAT ani nevšimne a pošle ho do vnitřní sítě na váš počítač.
-
Pořád všichni pochybují o "firewallových" účincích NATu. Uvědomte si, že popisovaná zranitelnost NATu platila pouze pro dávný návrh fyzicky symetrického NATu. To je dávno pryč. Současné NATy mají jasně odlišené veřejné a vnitřní rozhraní. Dokonce u *WRT je na tom postavená bezpečnost služeb, které se nabindují jen na vnitřní IP adresu a zvenčí se na ně bez port forwardingu nejde dostat.
I kdyby ten NAT byl hloupě symetrický, jakože není, stejně by se tam muselo chodit ze stejné podsítě poskytovatele bez použití brány. Poskytovatelé, aspoň ti větší, dělají Guest Isolation, což například předejde tomu, aby si lidi v paneláku navzájem četli sdílené dokumenty.
Vím, že existují i způsoby zapouzdření paketu, aby se objevil až v cílové síti, ale ten zase musí někdo dekódovat, takže to v podstatě předpokládá hack/špatnou konfiguraci něčeho jiného a pak se někam lámat s úrovní důvěryhodnosti místní sítě. -
j (neregistrovaný)
A vy, blbec, porad odmitate pochopit, ze !ROUTER! pakety (pro vas velke prekvapeni) !!! ROUTUJE !!!, a co ze udela router s paketem, kterej ma adresu v rozsahu kterej zna? Ano presne to, co se od routeru ceka, posle ho tam.
=> zadny NAT neni absolutne nijak bezpecny, je treba (a vzdy byl a bude) FIREWALL.
-
Jenda (neregistrovaný)
Myslíte net.ipv4.conf.all.rp_filter, což implementuje sekci 5.3.8 rfc1812? To dělá validaci source adresy, to u trafficu z Internetu nepomůže, ne?
-
j (neregistrovaný)
Ty vykricniky tam jsou predevsim proto, ze porad nejaky blbci tvrdi, jak je NAT ochrani, a BFUcka tomu pak verej. A tady vidim dalsiho v rade, neb nevi o cem pise. IP spoofing protection ma kazdy normalni router vypnuto, protoze jinak by nemohl fungovat - za normalni router rozhodne nepovazuju router, ktery funguje jako gateway dvou siti (pricemz jedna znich je koncova), ale zarizeni, ktery ma konektivitu do siti nekolika a vzhledem k principu routovani mu tudiz muzou prichazet (a taky prichazeji) pakety z ruznych smeru.
-
Filip JirsákStříbrný podporovatel
Spíš v sítích, kde se chtějí dostat na web, i když jim vypadne primární konektivita. Protože když to řeší až na routeru za tou spadlou linkou, stejně se rozpadnou i všechna odchozí TCP spojení a příchozí provoz nejde vůbec. Takže pokud někdo chce opravdu zálohovat konektivitu, řeší to třeba IP tunelem, VPN nebo PI adresami.
-
Filip JirsákStříbrný podporovatel
Jistě. Pro každý problém existuje jednoduché, snadno pochopitelné špatné řešení.
-
Jediné správné řešení je PI, ale to už nikdo nikomu nedá, protože je RIPE už nepřiděluje. Nehledě na to, že pro malou firmu nebo domácího uživatele je to prostě s těžkým dělostřelectvem na vrabce.
Při NATu se samozřejmě stávající spojení rozpadnou, pro většinu věcí to ovšem nepředstavuje zásadní problém.
-
To je bohužel blbost. Neexistuje žádné jednoduché řešení, které by zajistilo změnu IP adres - DHCP timeouty rozhodně delší než pár vteřin, které trvá přepnutí NAT. Nehledě na to, že přes ten NAT se dají dělat i zajímavější věci, jako třeba rozdělování zátěže - z ulož.to tahám jednou linkou, skype jede druhou.
-
Filip JirsákStříbrný podporovatel
Nejlogičtější a zároveň nejjednodušší řešení je, že mají zařízení IP adresy pro obě konektivity. Dobře se tím řeší dostupnost z venku, v případě výpadku konektivity nebo i jen routeru pro danou konektivitu prostě zařízení automaticky použije výchozí bránu s nižší prioritou. Náhodné rozdělování zátěže můžete jednoduše řešit tak, že některým zařízením nastavíte jako prioritnější jednu konektivitu, ostatním jinou. Rozdělování zátěže podle typu už vyžaduje dostat podrobnější pravidla pro routování až na koncové zařízení, ale předpokládám, že tím směrem se to bude rozvíjet. Ostatně rozhodování na základě toho, jaká je dostupná konektivita, se dnes vyžaduje od každého chytrého mobilu, a to ten mobil není v žádné síti, kde by mu s tím někdo pomohl – prostě má dvě či více úplně nezávislých připojení, a musí si s tím nějak poradit. Takže počítače v síti by to taky mohly zvládnout, a lednička holt použije tu bránu, kterou jí doporučil router.
-
Tak jednoduché to není. Důležité pro ustanovení spojení je volba zdrojové adresy. V případě výpadku vnější konektivity jedním směrem se tyto adresy musejí nějakým způsobem zrušit i na koncových počítačích, aby si náhodou nezvolily tuto adresu jako výchozí (a tím pádem nejely, protože budou tím druhým providerem zaříznuty). A o žádném takovém protokolu, který by adresy z rozhraní rušil nebo jim dával nižší prioritu nevím.
-
Filip JirsákStříbrný podporovatel
V případě konektivity jedním směrem to koncový počítač nejpozději při pokusu navázat tímto směrem spojení zjistí. Takže si danou routu označí za nedostupnou a použije další routu podle priority. Podle routy zvolí cílovou a výchozí adresu a jede. Žádné rušení adresy z rozhraní dělat nebude, protože na této adrese je pořád dostupný třeba v rámci lokální sítě.
-
Filip JirsákStříbrný podporovatel
Unreachable a redirect jsou dvě různé věci. Když nebudete používat NAT, můžete používat IPsec, a pak řízení směrování pomocí ICMP paketů žádné bezpečnostní riziko nepředstavuje.
O tom, že dvě konektivity nelze používat bez NATu, mne nepřesvědčíte. Můj mobil má jednu konektivitu přes WiFi, druhou přes GSM, a jsou to dva úplně odlišní ISP. Takže kdybych měl určit, co je ta síť, která podle vás musí být schovaná za NATem, byl by to celý český internet, a někde v NIXu by byl obrovský NAT, přes který bychom se teprve všichni připojovali do internetu. A to bych s tím mobilem nemohl opustit ČR. Věřte mi, že v NIXu žádný takový obří NAT, za kterým by byl schovaný celý český internet, není. No a když ty dvě konektivity bez NATu zvládá můj mobil, vaše pécéčko by to taky mohlo umět, nemyslíte?
-
Uvedl jsem ICMP redirect proto, že to je patrně ta správná metoda pro přesměrování provozu.
Netvrdím, že dvě konektivity nelze používat bez NATu, to jste četl asi něco jiného, než jsem psal. Příklad s mobilem je úplně mimo, protože je to koncové zařízení se dvěma konektivitami, narozdíl od koncového zařízení připojeného připojeného pouze jednou linkou k upstream konektivitě.
S tím NIXem mi nevnucujte, co jsem neřekl. Do NIXu jsou připojeni privideři nebo zákazníci s PI adresami a používají BGP, čili úplně jiná situace než klasická malá firma, která vlastní AS ani PI adresy nemá.
V IPv4 bez NATu prostě podle mne neexistuje metoda, jak říct koncovému zařízení, aby změnilo algoritmus IPv4 SAS (source address selection).
-
Filip JirsákStříbrný podporovatel
Já ale nechci přesměrovávat provoz, chci jenom oznámit, že daná síť je přes daný router nedostupná. Celou dobu tady řešíme případ, kdy zařízení má pro přístup do internetu dvě konektivity. IPv4 s NATem rozhodně není metoda, jak říct koncovému zařízení cokoli o routování. Např. OSPF je takovou metodou. Navíc tady řešíme IPv6, a to má trochu jiné předpoklady a jiné možnosti, než IPv4.
-
M. (neregistrovaný)
Hlavně myslím, že se dohadují lidi, co to nikdy nezkusili?
Funguje to. A bez vážnějších problémů. Situace:
LAN koncová síť, k ní připojeny dva routery (Mikrotik), každý router má uplink k jinému ISP, od každého má jiný blok /48 globálních adres. každý router propaguje ten svůj (respektive patřičný /64 do LAN, wifi, ...). Vedle toho je ještě aktivní blok ULA adres, které se používají pro spojení do firmy skrz VPN tunel, ULA propagují shodně oba routery.
Krámy v síti používají spokojeně IPv6 (Win XP, Win 7, Nokia E6, nějaké NAS krámy, multifunkční kraksna). Obvkyle mají nahozenu jednu ULA adresu a vedle toho IPv6 globální adreus od hlavního routeru (A). Bez problémů vybírají adresu a komunikujíé jak mají. Klyž hlavnímu routeru chcípne linka (nebo chcípne celý), tak záložní (B) začne propagovat svůj segment (řešeno s pomocí VRRPv6). Během pár sekund všemu naskočí i druhá globální adresa, takže mají ULA adresu, globální A (fakticky nefunkční), globální B. V té chvíli samozřejmě popadají spojení navázane přes global A, začnou se nabazovat nové, něco to zkusí rovnou z adresy B a jede, něco zkusí prvně A, když je jim to omláceno o hlavu nebo se nespojí, tak zkouší znova s adresou B.... Po nějaké době (mám preffered lifetime půl hodiny v RA), zahodí počítače A adresu a jedou už jen z B. Když router A a jeho linka opět ožije, zase zase propagovat on se ven a přejde to zpět na Ačkový segment... Provozováno rok.Pokud někoho zajímá, proč se nepropagují oba veřejné naráz, tak je to dáno nedodělky IPv6 v Mikrotiku, takže se tímto způsobem to ojebává (chybějící možnost ovlivňování priorit routerů a hlavně neexistující podpora pro policy routing IPv6).
Jinak výše popsané řešení je pro koncovou síť, třeba pobočkové nebo náročnější home uživatel pracující z domu a chtějící zálohovanou konekticitu. Jiná varianta pro IPv6 je použití ULA adres a překladu prefixů, což by bylo dfakticky NAT řešení z doby IPv4. Nicméně Mikrotik to nepodporuje.
Pro centrálu/velkou firmu je řešení vlastní blok, vlasatní AS a BGP ke dvěma partnerům (nicméně to má smysl jen s vlastním blokem /32 a žádným menším, jinak se zařadí do řady plačících, že jim IPv6 nefunguje). -
M. (neregistrovaný)
Pro IPv4 to funguje stejně. Jenom moc se nepodporuje u woken a podobných konfigurace víc IP dynamicky.
Je to dáno tím jak většina novějších aplikací dělá navazování spojení (nebo dneska je to už spíše schováno v knihovnách). Pokud používá getaddrinfo(),tak dostane pro danou cílovou adresu/jméno připraveny všechny varianty spojení a jen to ve smyčce zkusí. Dle lokálních preferencí pak může upřednostnit co chce. Takže stejná konfigurace pro IPv4, kdy mám víc IP adres od různých ISP se dá také použít, jen není tak běžná, zde je to běžněji řešeno tím NATem na bráně ven. -
To řešení přes DNS nefunguje, protože ačkoliv klient zkusí všechny kombinace, tak stále neví, kterou IPv4 adresu má použít jako zdrojovou. A pokud se trefí špatně (a když už se jednou trefí špatně, tak se trefí špatně vždycky, pokud nemá dostatečné informace v routovacích tabulkách, což nemá), tak mu provider ten paket zahodí.
(asi by stačilo nemotat cílové a zdrojové adresy dohromady a třeba bychom se domluvili)
-
M. (neregistrovaný)
Chci se spojit na adresu 1.1.1.1 (mimo mojí síť), zavolám an to getaddrinfo a ten mi vráti socket list, kde je připravneo spojení 2.2.2.2->1.1.1.1 a i 3.3.3.3->1.1.1.1, pokud lokální počítač má tyto dvě IP adresy (2.2.2.2, 3.3.3.3) na interfejsích, přes kterou to jde požadovaným směrem k 1.1.1.1, pokud budou mít stejnou metriku. Pokud místo IP použiji www.porno.net, tak dostanu případně v listu patřičně i struktury pro všechny možné IPv6 kombinace (včetně "blbostí" typu IPV4 mapped address) v závislosti na nastavneých preferencích OS (pokud si přes hinty některé věci nevynutím/nezakážu).
Na apliakci je pak jen zavolat v dalším kroku patřičně na ten socket list connect a čekat, která první z těch možností se chytne... -
Santiago (neregistrovaný)
1) C funkce getaddrinfo() nevraci seznam socketu, ale pouze seznam struct addrinfo, ktere obsahuji cilove adresy, ale nespecifikuji zdrojove adresy (viz RFC 3493). Mozna nejaka jina funkce dela to, co zminujes, ale AFAIK to rozhodne neni neco, co by aplikace bezne pouzivaly. Zdrojovou adresu obvykle vybira sitova vrstva OS.
2) Resit vyber 'spravne' zdrojove adresy tim, ze se postupne zkusi vsechny, je dosti zoufale reseni, nebot ne vzdy musi dojit k prijeti ICMP chybove zpravy (a v nejjednodussich pripadech k tomu nedojde) a tedy takove spojeni muze dlouho cekat na timeout.
-
Filip JirsákStříbrný podporovatel
Řekl bych, že pakety OSPF se nebudou bránit vstoupit na síťovou kartu koncového uzlu, služba upravující podle nich směrovací tabulky se také při spuštění na koncovém uzlu normálně rozeběhne. Pokud odmítáte použít jakékoli mechanismy pro řízení routování (ICMP, RA, OSPF), pak to opravdu asi budete muset řešit nějakým hackem. Já bych ovšem k problému dvojí konektivity raději hledal řešení, než abych vymýšlel obezličky, které přinesou spoustu dalších problémů. Zvlášť když IPv6 od začátku předpokládá, že zařízení budou mít více adres a že se bude používat autokonfigurace.
-
Pakety OSPF se nebudou bránit vstupu na síťovou kartu koncového uzlu, ale:
1. do koncových sítí se OSPF pakety neposílají, interfacy routerů jsou ve správné konfiguraci nastaveny jako passive (cisco terminologie), aby náhodou koncová stanice nemohla provádět podvratnou činnost, jako je třeba propagace různých sítí
2. na koncové stanici by musel běžet OSFP routovací démon, což opravdu není standardní situace (existuje něco takového pro windows?)
3. OSPF je link-state protokol a informace se vyměňují po navázání oboustranné komunikace router-router.Neodmítám použití mechanismů pro řízení routování, akorát říkám, že ten váš příklad s ICMP prostě nefunguje. To už je mnohem lepší ten příklad s getaddrinfo(), který by měl fungovat pro všechny komunikace navazované přes volání této funkce (což nemusí být vždycky pravda).
BTW: kdybyste správně sledoval vlákno, tak se od příspěvku kolegy "s" bavíme o 10.0.24.12, tj. IPv4 adresách.
-
Filip JirsákStříbrný podporovatel
Co přesně nefunguje na tom, že když zařízení obdrží ICMP Destination Unreachable, vyzkouší další záznam pro cílovou síť s nižší prioritou? Jak jinak má zařízení na takovou zprávu reagovat?
-
Co přesně by na tom mělo fungovat? Connect už byl proveden, takže IPv4 SAS už bylo resolvováno na nějakou IPv4 adresu. Takže bez další pomoci třeba pomocí toho getaddrinfo to už nemá co dalšího zkoušet. Jenomže i to getaddrinfo() bude fungovat patrně pouze na TCP spojení, takže budou věci, které nebudou fungovat protože fungují přes UDP (NTP a pod). Navíc budou teda fungovat opravdu jenom dobře napsané aplikace.
-
M. (neregistrovaný)
Kolega asi řeší případ, že spojení je již navázáno nějakou cesotu a daná cesta padne. Tak v případě multihomed sítí s různými IP pro různé cesty to spojení padne. V takovém případě samozřejmě není jiné cesty, než pro TCP (a obvkyle i UDP) spojení zahodit a zkusit otevřít nové, iterací přeš další možnosti získané z toho getaddrinfo.
Samozřejmě pro většinu běžného provozu je to asi akceptovatelné, když to nevypadává moc často (zkrátka kliknu reload na ten fejsbůk). Kde není a řešení vlastní AS a PI adresy je problematické, tak používáme to, že u našich apliací se používá SCTP protokol (jako náhrada za TCP/UDP) v režimu multihomed a přímo IP stack za mě drží spojení vícero cestami (např server má dvě IP a klient tkaé dvě IP, tka se naváží 4 kanály) a jen jeden je aktivní a když jim to nejde, tak sám IP stack to začne tlačit jiným, dostupným, bez ztráty dat a spojení dvou konců. Mechanismus přechodu na novou cestu je často i rychlejší, než u varianty PI adresy a vlastní AS. Samozřejmě to jde dělat jen tam, kd emám software pod kontrolou a potřebuji to.
Takže mechanismy existují. -
Filip JirsákStříbrný podporovatel
Případ již navázaného spojení doufám kolega neřeší, hned na začátku jsme se snad shodli, že to je případ, se kterým si ani všemocný NAT neporadí.
-
M. (neregistrovaný)
getaddrinfo samozřejmě funguje i pro UDP a případně i SCTP spojení. Je to jen o tom, že s tím ta aplikace musí být napsaná.
Jistě, pokud nějaká prehistorická apliakce jede svým starým stylem socket, connect, atd, tak má smůlu. Ale většina novějších už používá tento mechanismus (jak v unix, tak i ve windows světe existuje nějaký pátek), tak problém multihomed sítí i dual stack je tím elegantně vyřešen. Původně byl primárně určen k řešení automatického výběru IPv4/IPv6, ale řeší obecně možnost použít cokoliv, co daný stroj bude umět použít. -
Santiago (neregistrovaný)
Diskutujeme (IMHO) situaci, kdy koncove zarizeni je pripojeno do jedne site a az teprve ta sit ma dva ruzne uplinky (na hranicnim routeru ci routerech). V takovem pripade zarizeni ma jedno rozhrani a jednu nebo nekolik defaultnich rout. Diskutujeme IPv6, V takovem pripade:
1) o volbe spatne zdrojove adresy se zarizeni moc nedozvi, nebot zadnou ICMP zpravu dost mozna ani neobdrzi (technicky vzato totiz jde az o chybu pri snaze o doruceni odpovedi), takze chyba se detekuje az timeoutem.
2) I kdyby tu ICMP zpravu obdrzelo, tak ji nepouzije k oznaceni defaultni routy za nedostupnou, nebot nelze dost dobre odlisit duvody, ktere vedly k te ICMP zprave, a zda jsou relevantni k zvolene route/adrese.
3) V IPv6 neni silna vazba mezi pouzitou routou a zvolenou zdrojovou IPv6 adresou. RFC 3484 to moc neresi (az na pripad kdy zarizeni ma rovnou vic rozhrani), to chovani pro defaultni routy od ruznych hranicnich routeru zavadi az RFC 6724 z 2012-09. Nevim, kteri klienti to podporuji, ale vzhledem k novosti se na to asi neda moc spolehat.
4) Asi jedine spolehlive reseni je to, aby router s vypadlym uplinkem propagovat 'svuj' prefix s preferred lifetime 0, cimz se prislusne adresy stanou deprecated a nebudou pouzivany jako zdrojove pro nova spojeni. Nevim ale, zda takove chovani nejaky software podporuje.
-
M. (neregistrovaný)
Add 1] ano, tak se to chová, spojení se navazuje nekřesťansky dlouho, než první pokus vytimeoutuje a pak se zkouší druhé (pokud první linka jde do ztracena a chcípá to na timeout).
Add 4) Takto to mám uděláno pro IPv6 s dvěma routery. Když první ztratí IPv6 spojení, tak druhý začne propagovat svůj prefix a zároveň propaguje prefix prvního routeru s lifetime 0 a počítače od dalšího spojení už přejdou na nové adresy hned. Je k tomu použito VRRPv6, kdy proces routeru (a RA) je svázán s VRRPv6 rozhranním. Normálně ho drží první router a propaguje svůj segment (a zároveň propaguje segment druhého routeru s lifetime 0), když mu linka umře (testuje pingem), shodí si VRRP prioritu tak, že VRRP se překlopí na druhý router (takže první router zastaví posílání RA), tím pádem on pustí RA na VRRP rozhraní na druhém routeru, kde propaguje svůj segment a ten patřící prvnímu routeru s lifetime 0 a klienti na to reagují dle očekávání a od následujícího pokusu o spojení už jedou jen dle IP adres patřící k druhému routeru. Použity dva Mikrotik routery. NEdá s ena ROSu uděla,t aby v jendom segmentu se používaly naráz obě konektivity, protože ROS neumí pro IPv6 policy routing. -
M. (neregistrovaný)
Se obávám, že linux se jen přizpůsobil tomu, co nabízí i někteří jiní. Když nepočítam IPv6-IPv6 prefix translation (RFC6296), což j ejendo z možnáých řešení pro multi home sítě, tak některé renomované bedny umí NAPT i pro IPv6 (ať už 1:1 nebo 1:N). Uživatleé po tom řvou, tak to asi za peníze i dostnaou...
Někde jsme viděl přehled, kdo a co tkaového podporuje a linux v tom nebyl sám. -
Ondřej CaletkaZlatý podporovatelS IPv4 bych to tak samozřejmě neviděl: No new IPv4 Provider Independent (PI) space will be assigned.
-
Filip JirsákStříbrný podporovatel
I když ve stejné podsíti bude jen zařízení ISP, pořád to podle mne není "nikdo". Druhý problém je, že do NATu se díry dělají automaticky, podle toho, jak se implementace snaží uhodnout, že se jedná o nějakou komunikaci, pro kterou je potřeba udržovat "spojení". No a protože se z principu jedná o věštění z křišťálové koule, nikdy se nedá vyloučit, že se někomu nepodaří tu křišťálovou kouli nějak ošálit. Někdy může stačit odeslat paket se zdrojovou adresou z vnitřní sítě, někdy to může být o dost komplikovanější. No a pak taky samozřejmě hrozí, že tu díru v NATu otevře jediným paketem kterýkoli počítač ve vnitřní síti.
O tom, že NAT může být překážkou, myslím nikdo nepochybuje -- ostatně právě to je problém NATu. Jde o to, že pokud to někdo s bezpečností myslí aspoň trochu vážně, stejně musí nakonfigurovat firewall. A měla by to být samozřejmost, zvlášť když konfigurace firewallu je snazší, než konfigurace NATu.
-
fik (neregistrovaný)
nepustit nikoho dovnitř není problém, problém který je spojený s NATem je pustit dovnitř ten chtěný provoz.
jinak řečeno co když by jste se naopak chtěl na svůj počítač dostat pomocí telnetu (ano že je telnet špatný nápad je jasné)? tak třeba SSH, HTTP(s),... už chápete? jasně port forward... ale co když chcete mít víc web serverů? s jednou, nebo jen omezeným počtem veřejných IPv4 adres, začíná sebevražda zvaná nestandardní porty.
v tom je kouzlo globálních IPv6 adres, jejich platnost a dostupnot odkudkoli.
a těch případů bude přibývat, kdo by odolal "internet of things" :)
a to že je bezpečnost složitá? ano může být, tak někomu zaplatím za zabezpečení, u bytu to dělám také,... -
xyyyzzzz (neregistrovaný)
Spojenie bude typu klient-server, klient sa pripaja na konkretny port na servery a pre spatnu konekciu sa otvori port a fw tuto spatnu konekciu povoli na zaklade pravidla ESTABLISH, RELATED za predpokladu ze je ESTABLISH a RELATED povolene. Takze nebudeme tam kde sme teraz z natom. Nakolko rovnako by spojenie fungovalo aj priamo bez firewallu...
Ak bude potrebne inicializovat spojenie z internetu, tak si pouzivatel jednoducho povoli fo fw dany port, rovnako ako si teraz nastavuje presmerovanie portu...
-
Pavel Trefný (neregistrovaný)
Přeně tak, uživatel si upraví firewall podle sebe a je to. Nikde také není řečeno že uživatel si nemůže nastavit firewall na svém koncovém zařízení. V takovém případě je zrušení stavového firewallu to nejmenší.
Jako výchozí rešení, kdy ne každý uživatel vůbec tuší že by se měl nějak chránit je to podle mě dobré. -
Ondřej CaletkaZlatý podporovatel
Já věřím, že časem zase dospějeme do stavu, kdy bude firewall buď na koncovém zařízení, nebo vůbec, jako to kdysi bývalo. Jak může kdokoli za mým počítačem vědět, které služby chci provozovat a které ne?
Do té doby, než k tomuto poznání dospějí všichni, vymyslel jsem rozumný kompromis − propouštět dovnitř provoz na adresy, které mají mezi 64. a 95. bitem nuly (číslováno zleva a od nuly). Tím jsou ze hry všechny autokonfigurované adresy, takže kdo chce přijímat venkovní spojení, nechť si ručně nastaví krátkou IP adresu, např. 2001:db8:dead:beef::abcd:ef. Ostatně, pokud chce někdo přijímat spojení z Internetu, prevděpodobně chce i nějakou krátkou a snadněji zapamatovatelnou adresu.
-
Filip JirsákStříbrný podporovatel
Já věřím, že časem dospějeme do stavu, kdy bude volitelně firewall na rozhraní sítí – a bude tam řešit útoky na síťovou infrastrukturu (pokusy o zahlcení linky, podvržené pakety apod.), případně bude chránit vybraná zařízení (servery, pračky :-) atd.). Na stanici pak nebude žádný firewall, protože zda a jak má nějaký software komunikovat v síti půjde nastavit v tom softwaru.
-
Filip JirsákStříbrný podporovatel
To, že v základní instalaci není spuštěn žádný server, není věc zdravého rozumu koncového uživatele, ale zdravého rozumu dodavatele operačního systému.
-
Sob (neregistrovaný)
Klient-server problem neni. Ale ja si chci s prateli vymenovat instalacky Linuxu pres P2P, posilat naprimo soubory pres Jabber a podobne. :) A to s routerem, kterej blokuje prichozi pripojeni, neni uplne ono. Ja si porty povolim, ale vetsina normalnich uzivatelu nic takovyho nikdy delat nebude. Jeste tak kdyz jim ve Windows vyskoci, ze by program chtel na net, tak to odklepnou, ale router je takova divna vec kdesi daleko, do ktery nepolezou. Takze standard bude takovej, ze na jednoduchy primy pripojeni nebude spoleh, coz je prave velmi podobny tomu, co mame dneska s NATem.
-
Palo M. (neregistrovaný)
Ziadna bezpecnost. Za to moze prave NEbezpecnost. Koncove stanice (hlavne Windoze) mali tradicne ubohe zabezpecenie (najprv ziaden firewall k dieravemu systemu a neskor plno roznych firewallov rozdielnej kvality obvykle ponechanych v pazuroch neskusenych uzivatelov)... Tak sa firewall dal na router, tam kde je aj NAT (vacsina domacich routrov s ktorymi som prisiel do styku naozaj ma okrem NATu aj jednoduchy firewall). Pragmaticke riesenie, ktore vo vysledku len legitimizovalo bordel na koncovych staniciach (kvaziargumentom "ved to je zabezpecene").
Ja mam doma na vsetkych koncovych strojoch firewall nastaveny tak ako ja chcem a potrebujem, kazda masina chrani sama seba svojim vlastnym firewallom, takze na routri mi staci iba minimalny IPv6-firewall (v podstate len ochrana pred falsovanim vnutornych adries zvonka, ale ziadne filtrovanie normalnej prichodzej premavky). Lenze ak by sa taketo nastavenie routra standardne pouzivalo pre beznych ludi, ktori maju firewally na koncovych strojoch bohvieake (a mozno ziadne), pravdepodobne by to skoncilo bezpecnostnou katastrofou (boli by zombici aj tam, kde dnes nie su).
Takze bohuzial, pokracuje sa v pragmatickom rieseni, ktore sice ma pozadovanu bezpecnost, ale zaroven je aj velmi obmedzujuce. Kym v IPv4 bol obmedzenim uz samotny NAT (takze restriktivny firewall na routri neobmedzoval uzivatela viac nez NAT), v IPv6 je restriktivny firewall na routri uz jedine obmedzenie (ale pritom uz to obmedzenie nie je nevyhnutne).
Takze sa skor da suhlasit s tvrdenim "tomu nas naucil NAT" nez s tvojim "bezpecnost je bezpecnost". Aby som to upresnil: Technologia NAT samotna samozrejme za nic nemoze. Ale na obmedzenia vyplyvajuce z jej masivneho nasadenia si ludia v priebehu rokov vacsinou uz zvykli - ty sam si jasnou ukazkou toho, ze "ti to nevadi" a dokonca to obhajujes (vraj je to v zaujme bezpecnosti). Ale nie vsetci sme si na to zvykli... (a na ten tvoj argument sme zareagovali, pretoze je podla nas nespravny) -
Palo M. (neregistrovaný)
Nikdy so netvrdil, ze "NAT mi firewalluje" a taketo slovne spojenie mi nedava zmysel. NAT predsa robi len preklad sietovych adries (ako uz jeho nazov napoveda), takze nic "nefirewalluje" a uz vobec nie mne. Takto postavena otazka je nezmyselna a neda sa na nu odpovedat.
Akurat som povedal, ze NAT _obmedzuje_ uzivatela, a to tvrdim aj nadalej (konkretne priklady obmedzeni uz spomenuli ini, aj v tejto diskusii, napr. Sob vyssie). -
Jenda (neregistrovaný)
„Nikdy so netvrdil, ze "NAT mi firewalluje" a taketo slovne spojenie mi nedava zmysel.“
Jejda, omlouvám se, myslel jsem samozřejmě firewall.
Šlo mi o to, že třeba já nemám na desktopu žádné služby, které by si FW zasloužily. Buď mi poslouchají jenom na lo (webserver, na kterém vyvíjím web, mysql) nebo poslouchají ven, ale pak chci, aby poslouchaly - třeba Jabber přenos souborů.
-
SB (neregistrovaný)
U Ipv4 se MUSÍ lézt na router, protože se tam musí nastavit NAT (protože pouze tam se musejí překládat adresy/porty), ale určitě se tam nemusí lézt kvůli tomu, abych nastavil fajrák! Takže jak bylo psáno výše, nikdo neříká, že se frewall nemůže přesunout z routeru čistě na koncové zařízení (pýsydlo)! Firewall se na router umisťuje proto, aby se v jednom místě vyřešilo 10 lojzů, kteří si ten firewall nastavit neumějí. Není problémem ten firewall na routeru (či ktekoli jinde po cestě) vypnout a říct koncovému uživateli „dělej si s tím, co chceš“. Takže to jsou zcela rozdílné koncepty - NATu je uživatel vždy podřízen, kdežto odpovědnost za provoz (firewall) je možno přesunout KAMKOLIV po cestě.
