Prodej adres je mozna zapovezen "jakymisi" pravidly, ale zkuste na tuto "protizakonnou" cinnost napasovat pro zacatek treba neco z legislativy CR.
... a timto se odsuzuje se k trestu odneti svobody na 9 mesicu za neopravneny prodej adresoveho bloku x.y.z.0/20 ....
a nebo spise
... za neopravnene sireni smerovacich informaci do BGP o prefixu x.y.z.0/20, ktery byl ziskan na zaklade neopravnene dohody se spolecnosti ABC....
No ci presneji receno jak je co nezabezpecene a jak kdo co nefiltruje. To ze se neco objevi v BGP ci nikoliv je veci vule nekoho prislusny blok inzerovat a dalsich subjektu tyto smerovaci informace akceptovat.
Pokud bude ekonomicky tlak bude i vule ustupovat. Vzhledem k tomu cely aparat propojovani Internetu je postaven na ekonomickych principech tak nevidim duvod proc by to neslo. Resp. mate dnes jinou alternativu?
To ze je to zakazane jistymi regulemi nic neznamena. Take by si nikdo nemel s ostatnimi vymenovat stazene mp3 a presto to spousta lidi dela. Pokud neni zalobce, neni soudce.
Zbynku nema smysl si hrat na pravni kutily :-) Realita je takova, ze prodej adres je zapovezen pravidly.
Bohuzel blby je, ze se klidne muze stat, ze stejnou adresu si nastavi Franta Voprsalek na zaklade jeho pripojky od ISP blackhat, s.r.o. a pri vhodnem nastaveni smerovani to muze napachat docela velkou rotyku (coz jsme vsichni videli nazivo pri kauze "YouTube v Pakistanu").
A protoze zabezpeceni smerovani je na takove urovni, jake je, tak bych se spise budoucnosti IPv4 bal.
Ehm, IP adresa, dns, ... neni (a nikdy sem to nevidel) soucasti smlouvy s ISP, ale soucasti technicke specifikace, kterazto se muze kdykoli zmenit (v souladu se smlouvou a vseobecnymi podminkami).
Ono se totiz klidne muze stat, ze ISP vymeni vic malych rozsahu za jeden vetsi (uz sem parkrat videl) a nasledne musi samozrejme precislovat celou sit.
Advocatus diaboli: Ten ISP muze vybirat penize za to, ze jeho zarizeni prideli zakaznikovi adresu pokazde identickou a ze tuto adresu bude smerovat krz svoji sit. Protoze o vlastnictvi te site a narocich na vynosy z ni patrne zadna pochybnost nepanuje, jista pravni jistota tam prece jen je.
Aneb IP adresu si klient muze nastavit, jakou chce, to je jeho boj. Ale jenom s tou jednou (dvema, osmi, dvestepadesatisesti apod.), kterou mu rekneme a budeme smerovat, mu to bude fugnovat.
Uplny souhlas. Ja prilis nerozumim tomu, kde vznikl ten nazor, ze obchod s IP adresami je nelegalni a naproste fuj. Pravidla RIPE a spol. jsou jedna vec, ale jejich pravni vymahatelnost je podle me sporna. Internet nema centralni rizeni a je prakticky veci dohody co se do BGP siri a co ne (byt se to dnes opira o DB RIPE atd.). Nejake centralni zdrazeni adres provest nelze protoze Internet zadne "oni" nema. Vec pripadne urci trh - a zrovna tady to bude fungoat velice dobre.
Ona obecna manie ze s koncem adres jakoby jako mel skoncit Internet je jen takova hysterie. Je to proste "rozdani lidu, co jeho jest", ktery si casti bude za uplatu dle uvazeni smenovat. To ze je adres malo je dano hlavne tim, ze zdanlive nemaji zadnou hodnotu a jsou ted prakticky zadarmo - jen blazen by je dnes pustil.
Nakonec k tomu stejne bude muset dojit, protoze IPv6 absolutne neni pripraveno pro seriozni pouzivani a bude nutne ziskat dalsi cas pro jeho vyvoj, nasazeni a samozrejme nekonecne debatovani o nem na Lupe :-)
A je to tak dobře. Obchod s IP adresemi nakonec bude úplně normální, ať se to IPv6 jasánkům nelíbí sebevíc. Právě cena za IPv4 jednoznačně určuje termín nasazení IPv6 masově. Zdražte IPv4 a úspěch je zaručen. Jenže to tak jednoduché není, jak se zdá
(proto ty keci o tom, jak je obchod s IP adresami nelegální)
RIPE by to mozna zajimalo, ale tim to nejspis konci. Maximalne nejaka inkvizicni komise, ktera by dojela, adresy nasilne odkonfigurovala a zrusila jejich propagaci do BGP.
Ve smlouvach se naprosto bezne uvadeji IP adresy a pokud by ISP jen tak menil zakaznikovi adresy, tak by taky velice rychle mohl o toho zakaznika taky prijit.
IP adresy je komodita se kterou se uz dnes vicemene obchoduje, byt je to mnohdy ruznymi formami skryte.
Mno, to mate bud tu smlouvu blbe napsanou, nebo ste si ji blbe precet, v kazdym pripade by to mozna mohlo zajimat RIPE - to totiz IPcka taky neprodava, ale prideluje, a tudiz totez ocekava od tech, kterym je pridelil, v opacnem pripade jim je totiz muze taky odebrat.
Ovsem pokud ja vim, tak napr UPC si uctuje 100Kc (nebo tak nejak) za prideleni staticke IP, nikoli za tu kterou IP adresu (a nejak nechapu, proc si uctujou za jednorazovy ukon opakovany poplatek, ale to je na dlouhou debatu).
Zeptám se ryze ze zvedavosti. Vede vás k tomuto řešení nejaky praktický důvod, anebo pouze vidina perspektivního řešení ?
Předpokládám, že propojujete mezi sebou pobočky. Jsou vám schopní poskytovatelé nabídnout spolehlivě fungující IPv6 konektivitu - tedy jednak, že to fakticky funguje a také, že jsou schopní smluvně garantovat SLA ?
cau,pavucik ;]
k tvojej poznamke o migracii - zalezi aj od toho,co a ako migrujes.
v pripade spolocnost kde pracujem mame jasno [aspon zatial] - volime cestu 4in6 - interne siete zostavaju aj nadalej v IPv4 a VPN ktorymi ich prepojujeme budujeme nativne nad IPv6.
momentalne mam na stole 'ipv6 lab' - uspesne mam odsimulovane 4in6 a 6in6 AutoIKE [komplet postavene na Juniper boxoch] - jedine non-juniper zelezo su PC,na ktorych mi bezia Vyatta routery... a beha to spolahlivo. vidim to tak,ze dalsi tyzden/dva stravim nad zabezpecenim a testovanim [THC/backtrack 4]
Obávám se, že to co nejvíce dusí IPV6 je především to, že před těmi 16 lety se pustili do úplně nového protokolu a vůbec nepočítali s masovým souběhem s IPV4 a snažili se vylepšit tehdejší neduhy IPV4 které byly ovšem mezi tím dávno vyřešeny. Ovšem další spusta problémů vznikla a vzhledem k mizernému rozšíření IPV6 jsou řešeny pouze na úrovni IPV4.
Také penetrace "zasíťování" je mnohem jinde. Já nevím jak Vy ale v roce 1995 byly páteřní linky na úrovni rychlostí 256kb/s-2Mb/s takže nějaký DDOs útok byl víceméně chimérou, o sítích zombie počítačů s nesmírnou výpočetní silou se také nikomu nezdálo.
Osobně se domnívám, že pokud by se dnes začal seriózně řešit nedostatek IPV4 adres nějakým rozumným rozšířením IPV4 protokolu, byla by velká šance na rozumné řešení. Jednoduché věci totiž fungujou.
Ehm, zrovna uvádět OpenVPN jake ukázkau, jak se dá jendoduše využít možností OpenSSL knihovny je dost úlet, že? Tak zkprasené využití jsem už dlouho neviděl. Hodně let měli v OpenVPN chybu spočívající v tom, že když se použíl CRL a jemu skončila platnost, tak se ignoroval, takže pokud byl nějaký certifikát zneplatněn a CRL prošlé, tak se přesto přihlásil. Teď je to už aspoň tak,že i po skončení plantosit se CRL uplatňuje a filtruje dle něj, akorát to do logu řve, že už je za zenitem (snad všechny IPsec implementace, co jsem měl v ruce, v takovém případě zastavily komplet vše s certifikáty nbo to bylo konfigurovatlené chování, je na uvážení co je horší). Dosud nezvládá OpenVPN korektn práci ve složitější certifikátové hiearchii (spoustu let visí v TODO, že to bude někdy vyřešeno). Jakmile certifikační autorita, co vydává certifikáty pro OpenVPN, není root, tak je těžký problém opět s CRL, nefungují (funguje jen jeden, a to první nalezený). Natož nějaká snaha o online ověřování certifikátů atd (což už umí i ta poprasená implmentae IPsec v historických XPčkách, když se to v registrech zapne). A pokud vezmu v potaz OpenVPN klienta a jeho použití normálním uživatelem ve woknech, pokud má práva jen user, tak to také není úplně jendoduché (vím, openvpn jako tkaové to relativně OK podporuje, jen k tomu chybí patřičně rozumné GUI, pokud s eněco v posledních mědsících nezměnilo). Taktéž dost problém s HW tokeny pro uložení certifikátů (zvláště v HW tokenech natvrdo v notebooku a kombinace s Windows).
Ale uznávám, že OpenVPN je relativně jednoduché, pokud mám pár klientů/serverů, které mám sám pod kontorlou, k tomu několik mobilních notebookářů, které mockrát nemusím omezovat a ani nejsem závislý na složitější certifikační hiearchii, tak je to v pohodě nástroj. Taktéž to má schopnost lépe prolézat přes NATy, má to menší režii na data (pokud porovnán s defualt klientem ve wonech, který jede L2TP/IPsec mix). Jakmile jsem na to ale tak, že řadu klientů, serverů, protistran má pod palcem někdo jiný, jsem nucen fungovat v rámci hiearchických firemních delegovaných certifikačních autorit s oddělenými pravomocemi, jakmile musím připojovat do VPNka kdejaké obskurní zařízení (včetně třeba mobilních telefonů), tak to smrdí tím IPsecem, který kupodicu funguje. Ano, některé implementace má svoje slabiny, ale dá se s tím vyžít s použitím všech vyjmenovaných sprostých slov. :-)
No zatím se to neprojevuje na koncových cenách. Pořád mám šanci si koupit 1 IP trvale. Dřív nebo později dojde k pronájímání IP adres za nějakou cenu.
Aby mě nebylo chytáno za slovo, pronájem IP adres sem už taky viděl, na různých cloudech a podobných VPS. Zatím jsou ceny takové, že zavádět IPv6 oproti tomu je drahé. Takže proč by se měl svět honit za něčím lepším?
Co nás čeká teď? No čeká nás IPv6. Otázkou je, kdy. Následujících pár let rozhodně masivní nasazení IPv6 neočekávám.
když se podíváte do man tcpdump, tak je tam položka -E. Opravdu stačí jenom malý krůček k tomu, aby si tcpdump bral parametry z nějaké jaderné struktury místo příkazového řádku. To podle mne u OpenVPN neuděláte, protože ten si svoje stavy udržuje uvnitř sebe (a řekl bych, že by to ani nebylo jednoduše implementovatelné, narozdíl od IPSec)
IPSec používáme proto, že se nám dost často stává, že na jedné straně je linux a na druhé třeba cisco. Ale upřimně řečeno si jako masochista připadám pouze na linuxu, protože tam aby se v některých implementacích prase vyznalo a odladilo. U FreeSWAN bylo úplně jednoduché používat tcpdump, protože FreeSWAN vytvářel virtuální interface, přes který se dal odposlouchávat provoz nešifrovaně. U nové implementace je to dost problém. Na druhou stranu, nové řešení je funkční a nestává se mu, že by padalo.
Ta potreba IPv6 jeste stale neni tak vysoka. Tohle jsou trzni zakony, ktere bohuzel malokdo z nas dokaze respektovat. Porad je levnejsi ziskat IPv4 adresu a klienty hazet za NAT (oni si poradi, VPN, N2N, Hamachi, Teredo, Skype a podobne) nez budovat nakladnou IPv6 sit. A o tom to je. Ti co IPv6 implementuji pak delaji proto, aby meli oproti konkurenci +1 feature navic, jenze vzdycky tam hraje roli ze jsou +X chechtaku drazsi, nez konkurence. Takhle se IPv6 placa od nikud nikam, ale pomalu dopredu. Ceka se na firmu Y, ktera nabidne uceleny a relativne levny system, uspeje s tim na trhu a prevalcuje s tim ostatni a ustanovi defacto standard (a standarizacni instituce se tomu prispusobi). A prave slovo "levny" je dulezity, protoze musi byt levnejsi, nez soucasne IPv4 reseni, pripade prinaset neco klientum, napriklas nove uzivatele.
Jeste nas ceka obdobi kseftovani s IPv4 adresami (rozsahy). Ocekavam jej tak do roka a bude trvat cca 3 roky(muj odhad)
Ten prvni pripad s DES56 a AES256 mi teda prijde hodne pritazeny za vlasy, ale budiz. OpenVPN pouziva SSL/TLS vrstvu, kde se samozrejme muzete definovat jak algoritmus (volba cipher), tak delku klice pro jednotlive kanaly (volba keysize). Je to dano moznostmi OpenSSL nez samotnym OpenVPN.
Myslenka s tcpdumpem je hodne zajimava - urcite by neco takoveho spousta lidi ocenila - obecne i do toho OpenVPN :-) .
Argument o zplacanosti je velice sporny. Pokud bych chtel pouzit obdobne zabarveny ekvivalent, tak reknu, ze v IPSec je zas vsecko roztristene. Kupodivu s tou zaplacanosti zijeme v HTTPS, IMAPS, POP3S a nevim jeste v jakem vsem moznem *S. Vrstva SSL/TLS velice dobre odladena, protoze se uz nejaky ten patek pouziva.
Jako vyhodou IPSecu vidim, ze je to standardizovane reseni, takze dokazete propojit treba CIsco a Linux. Tohle na OpenVPN neudelate (zatim).
Jinak samozrejme pred vami smekam, ze jste ochoten dobrobvolne pouzivat IPSec aniz by vas k tomu nutily vnejsi okolnosti (skladba HW, korporatni politika definovana nekde na ustredi v USA). Na druhou stranu kazdy si zde muze zvolit presne to co mu vyhovuje, coz je zasadni rozdil oproti IPv6, kde se musi shodnout vsichni na jednom reseni.
Jen mi hodne vadi, ze kazde IPv6 zarizeni by melo podporovat IPSec. Nastesti na to rada implementaci kasle bez ohledu na to co rikaji RFC.
Zacit od piky by byl problem, protoze nikde neni zaruceno, ze by to nevypadalo uplne stejne jako IPv6. Nejspis i to nove od piky vytvarene by vytvareli stejni lide - takze cekani dalsich 15 let, nez by nove IPvX bylo ve stejnem stavu jako je dnes IPv6.
Vysledek za 15 let by byl nejspis takovy, ze bychom v sitich provozovali:
IPv4 - se vsemi jeho problemy
IPv6 - se vsemi jeho problemy
IPvX - se vsemi jeho problemy
Děkuji za výzvu ač nejsa šlechticem vždy jsem ochoten se postavit jakékoliv výzvě....nicméně položit život za IPV4 rozhodně nehodlám....
Faktem zůstáva, že mne trochu straší jak je možné, že nastala to co nastalo, že docházejí IPV4 adresy a celý ten systém okolo nebyl schopen vyplodit nic lepšího než tento podle mého názoru nedomyšlený paskvil.
No a když vidím co všechno se bude muset ještě vyřešit, mám pocit, že začít od píky by bylo možná mnohem jednodušší. Protože co si budeme nalhávat tak prakticky jakékoliv zařízení, které dnes pro IPV6 pořídíte bude za pár let stejně na vyhození, protože nemůže implementovat to co dnes není dořešené.
Abych to vyjádřil jednoduše, IPSec je možné, díky jeho architektuře, dekomponovat na jednotlivé součástky a ty pak jednodušeji ladit, případně nahradit jiným software. Je možné definovat vazby mezi součástmi mimo program a umožnit tím přístup programům třetích stran, jako třeba zmiňovanému tcpdumpu.
Zkuste mi tedy nastínit s OpenVPN situaci, kdy mám různé úrovně bezpečnosti procesů a chci, aby procesy na úrovni 2 mohly komunikovat pouze prostřednictvím šifrování s DES56 a vyšším a na úrovni 3 se šifrováním AES 256 a vyšším.
To co zmiňujete s rozbalováním v kernelu je čistě implementační záležitost. Tcpdump svého času uměl tato spojení dešifrovat, pokud jste mu předhodili správný klíč. Takže vazba tcpdumpu na jaderné struktury ve kterých jsou aktuální šifrovací klíče tady toto celkem řeší.
OpenVPN má jak provoz, tak výměnu klíčů splácanou dohromady, takže ladění případných problémů je komplikovanější.
Osobně mám IPSec nasazený na několika lokalitách a problémy jsou pouze se starými verzemi FreeSWAN. Nutno přiznat, že dnešní způsob implementace IPSecu v Linuxu, nebo spíše nedotažení nástrojů jako tcpdump, nejsou taky úplně nejlepší.
To neni tak uplne pravda. Treba na reditelove ipadu ipv6 nevypnete, protoze to jednoduse nejde. Takovych zarizeni bude vic. To co pisete plati tak pro PC napriklad v domene, kde to dokazete s primerenym usilim zajistit. Dnes je vypnuti IPv6 na MS prakticky nutnost - nekontrolovane tunely atd. Otazkou je jestli to pujde tak udelat i v dalsich verzich.
Na druhou stranu IPv6 se asi casem vyhnout nejde a zavadet ho vypinanim mi prijde trochu nelogicke. Asi je lepsi odstranit ty chyby a doresit problemy. Jen by me v tomhle zajimalo jestli to bude trvat dalsich 15 let.
> ESP se rozbaluje "nekde" v kernelu, takze pokud chcete ve firewallu ovlivnit/kontrolovat co leze ipsecem (nebo to poslat napr do NATu, DMZ) neni to uplne jednoduche. Stejne tak pokud si potrebujete udelat diagnostiku napriklad tcpdumpem - takrka nemozne (zejmena v netunelovacim rezimu).
Tohle je problem spojeny s tim, ze nektere implementace IPSecu (treba ta v Linuxu) maji divne reseny tunel mod z hlediska jak se prezentuje zbytku sitoveho stacku. Tyto problemy jsou popsane v RFC 3884, doporucene reseni je pro ucely VPN nepouzivat tunel mod, ale transport mod na ipip tunel.
Ok. Tak tedy jak chcete:
- Infsrastruktura verejneho klice je naprosto totozna, jak pro openvpn tak ipsec. Oboji vyuziva X509 certifikatu. Pokud se chcete certifikatum vyhnout muzete pouzit v obou pripadech dohodnute tajemstvi. Takze nevim jak myslite, ze je na tohle ipsec lepe pripraveny.
- Pro ipsec musite musite provozovat doprovodny mechanizmus pro vymenu klicu (IKE), ktery krmi SPD, SA. Na Linuxu resi samosatny daemon (napr. racoon), ktery si veci vymenuje po UDP port 500, nekdy 4500 (nat-t). Takze dalsi dve diry na FW. Celkove tedy pro provoz ipsecu musite rozchodit komunikace na dvou portech + protokol ESP.
- Vlastni rozhodovani co jde do IPSec je soucasti kernelu v podobe SPD. Pri zahajeni komunikce zacne vznikat SA. Jeji vyrizeni chvili trva. SA casem zmizi, takze nezbyva nic jineho nez ipsec spojeni je treba napriklad propingavat (pokud na lince neni trvale provoz).
- ESP se rozbaluje "nekde" v kernelu, takze pokud chcete ve firewallu ovlivnit/kontrolovat co leze ipsecem (nebo to poslat napr do NATu, DMZ) neni to uplne jednoduche. Stejne tak pokud si potrebujete udelat diagnostiku napriklad tcpdumpem - takrka nemozne (zejmena v netunelovacim rezimu).
- Pokud pridavate novou SPD (napr. nova pobocka) vyzaduje to restart racoona, takze vam popadaji vsechny ostatni SA a vse se navazuje znovu. Takze ostatni pobocky nachvili odrovnate. To je snad veci implementace - mozna uz dneska doresene - nevim.
Jsou to pravda zkusenosti nekolik let stare, kdy jsme propojovani ipsecem nakonec definitivne zavrhli. Od te doby jsou pobocky propojene na openvpn, ktere se chova o dost spolehliveji a hlavne proleze temer cimkoliv. Nasazeni ipsec znamena (ci spise znamenalo), ze na to musite malem najmout cloveka, ktery bude resit neustale problemy s ipsecem, ladit chyby implementacich a ucit konfigurovat adminy na pobockach firewall tak aby tim ipsec prolezl.
Zajimave je, ze ipsec je nedotknutelnou svatou kravou, stejne jako IPv6. Sotva nekdo zmini vyhradu, tak se tak se na nej sesypou *jasanci, kteri si vec vyzkouseli tak max. mezi dvema PC. Jen by me zajimalo jestli jsou to stale ti stejni lide, nebo jsou to disjunktnti skupiny :-) Posledni dve vety berte prosim s nadsazkou :-))
To ze ma neco nekvalitni iplementaci muze mit tri duvody:
- Je to prilis nova vec (coz ipsec neni).
- Neda se to dobre naimplementovat protoze je to neskutecne slozite - tedy nejspis vymyslene nejakym vedatorem.
- Je to k nicemu, tak se to naimplementovalo, aby byl ukol splnen a dal uz to nikoho nezajima.
Ipsec je neco naprosto sileneho a pouzije to fakt snad jen masochista, zejmena kdyz existuji moznosti jako openvpn (jeden protokol jeden port proleze takrka cimkoliv).
No nuti, kdyz kazde Visty, 7, Linuxy a uz kdejake telefony maji nebo budou mit IPv6 zaple. Tezko asi muzu zajistit aby kazdy kdo se pripojuje do site si nejdriv odinstaloval/vypnul IPv6.
Jen nechapu, ze ty problemy s IPv6 snad nikomu nevadi a resi se nejake ptakoviny jako ipsec, ktery zas tolik lidi nepotrebuje, a zakladni veci nejsou vubec doresene.
No, co se týče IPsec a levných domácích krabiček, tak je to tal 1:4, co mám zkušenost. Respektive polovina v sobě má nějakou formu helperku do NATu, který to rozbije (většinou vypínatelný) a tam kde není nebo je vypnutý to funguje, ale stále zbývá tak čtvartina, kde ani za boha nechodí.
V kombinaci s ADSL je to ještě o trošku hůře, zejména v síti O2 vzhledme k jejich oblibě pro reordering paketů a nekorektní implementaci IPv4 v některých krámech, kdy neprojde vícenásobně fragmentovaný paket, pokud fragmenty nedorazí uspořádány v pořadí (což už úspěšně rozbije IKE fázi pokud se používají certifikáty, stjeně jako cokoliv nad UDP s dlouhými pakety).
Nemá smysl se hádat, zkrátka IPv6 má šanci část problémů vyřešit a část nových přinese. Vy zastáváte teorii, že to vše jen zhorší a rozbije, já, že to něco vyřeší. Bohužel, ideální rozřešení tohoto sporu ve formě osobního souboje se poslední století nedrží moc v náklonosti široké veřejnosti a i exekutivy (jinak bych tu měl před domem ideální romantické místo k takovému rozřešení za hradbami města, takže mimo dosah městkých zákonů, a i třídní původ mi umožňuje tuto metodiku), takže nám nezbude, než počkat pár let, jak to dopadne i bez našeho zapřičinění. :-(
>Selektivní pamět? To IPsec kontra NAT jsem psal já a stejně tak jsme psal, že jsem v prostředí, kde je IPsec povolen a blbá NAT implentace mi ho kazí, pokud by byly veřejné IPv4 adresy nebo IPv6, tak minimálně mám o tu NAT ptákovinu o starost míň...
No jo, ale psal jste to jako připomínku k tomu, že já tvrdím, že IPV6 nic dobrého nepřinese, že vše je realizovatelné i přes IPV4 a NAPT. A z dnešního článku vyšlo, že základní funkčností firemního firewallu by mělo být zakázání IPSec. Což mimochodem dává za pravdu mně.
Vy jse argumentoval, že v té konrétní síti IPSec povolene je ale že nepřeleze přes ten mizernej NAT z čehož jste evokoval, že když tam bude IPV6 tak že to bude bez NATu a IPSec Vám tedy projde a vy budete v síťovém ráji. To podle mne dnešní článek vyvrací. Navíc i to že v dané síti je povolen IPSec může být způsobenu i tím že není důvod zakazovat něco co stejně přes NAT neprojde....nicméně vzhledem k tomu, IPV4kový IPSec projde přes NAT mnohých levných domácích ADSL krabičkách bez problémů (při správném nastavení) není důvod se domnívat, že to nebylo způsobeno pouze nechutí, nebo neuměním toto nastavit.
Selektivní pamět? To IPsec kontra NAT jsem psal já a stejně tak jsme psal, že jsem v prostředí, kde je IPsec povolen a blbá NAT implentace mi ho kazí, pokud by byly veřejné IPv4 adresy nebo IPv6, tak minimálně mám o tu NAT ptákovinu o starost míň...
Pokud je samozřejmě IPsec jako takový blokván, tak je jedno, zda mám IPv4/6 řešení.
Jinak očekávám obecně, že trošku rozumná firma má vnitřní síť zcela oddělenou a ven se jde jen přes aplikační proxy s rozumným filtrováním a autorizací klientů a volnější komunikace je jen na vybrané konce nebo z oddělených segmentů.
A kdo to tak nemá, tak občas změní názor, až třeba zjisít, že jeho skvělá multifunkční tiskárna/scener/fax/copy krom příslušných funkcí jako neohlášenou bokovku vše co jí prošlo posílá po netu někam do Koree (viděl jsem už tři takové). Takže v této úrovni IPv4/6 není výrazný rozdíl.
Jiná věc je, že IPsec nad IPv6 podpora u krámů je obvkyle tristní, přestože IPsec je papírově povinná součást.
Nu, já myslím, že šmírovací snahy našich vlád nás postupně donutí implementovat něco defacto podoně funkčního, kdy chudák ISP neuvidí nic, než jen IP adresy koncových bodů a vše, včetně protokolu vyšší vrstvy bude šifrováno (než nám to naši pohlaváři začnou zakazovat). Taková ta idea anonymního IPsec v reálu (ale jeho implmentace je ještě mizernější, než vlastního IPsec). Tohle asi zaítm spíše trápí ISPéčka, co se pokusila zamyslet a zjistila, že jejich systémy na řízení datových toků a řezání rchlostí z toho moc nevykoumají.
Předně bych byl nerad, aby věc vyzněla tak, že se IPSec-u něco vytýká. Snahou bylo popsat realný stav věci.
Důvod proč si myslím, že je to důležité je ten, že postupem času došlo k výraznému odklonu od původního záměru použití IPSec. Měl obecně zaručovat bezpečnou komunikaci v idelaním případě mezi jakýmimikoliv uzly (proto ta povinná implementace). To se projevilo v řadě návrhů standardů - například OSPFv3 neřeší autentizaci sousedů, protože se odkazuje na IPSec (viz. http://www.rfc-editor.org/rfc/rfc4552.txt).
Dnes naštěstí postupně dochází k jistému IPSec-ovému "vystřízlivění" a IPSec se postupně dostává tam kde je, dle mého názoru, jeho místo - tunelové provozy, VPN, specializované průmyslové aplikace atd. Tedy rozhodně ne v pozici, kdy vaše účetní komunikuje IPSec-em s internetovým bankovnictvím.
Podobnost s PPTP, L2TP či OpenVPN platí pouze v tunelovacím režimu. Tyto protokoly jsou na úrovní korporatniho firewallu dnes běžně zakazovány a povolovány pouze na validní adresy (tedy servery obsluhující tyto protokoly). OpenVPN tunel připojený na PC vaší účetní by vas určítě vyděsil, nicméně v případě IPSec-u není zvykem o "podivnosti" komunikace takto uvažovat - vždyť je to přece ten bezpečný protokol nového Internetu.
Zde bych viděl jistý rozpor. Není podstatné kdy se začaly tyto technologie používat - někde dřív, někde později na spoustě míst vůbec protože k tomu nebyla realná potřeba.
Problém spíš vidím v tom, že při budování nových sítí je nenavrhujete tak aby fungovaly v době před dvěmi lety, ale tak aby fungovaly dalších 5 let. A důvod proč jsou víc potřeba tyto věci je velice prostý. Společně s elektronizací kdejaké agendy a závislosti na sítí rostou každým dnem nároky na jejích spolehlivost. Výpadek sítě dnes není to co výpadek sítě řekněme před 5 lety. Tenhle trend zkrátka a jednoduše musí sledovat i technologie na kterých se sítě stavějí.
Se zprávami NS a RA máte samořejmě parvdu. flood_router6 skutetečně zasílá kvanta oznámení směrovače. Děkuji za upozornění - pokusím se sjednat nápravu.
Co se týče možnosti filtrace, tak jsme to řešili ve IV. dílu (http://www.lupa.cz/clanky/ipv6-myty-a-skutecnost-dil-iv-podpora-autokonfigurace/). Souhlasím možnosti filtrace tady jsou už dneska. Nejsou ovšem úplně zadarmo. Pokud si porovnáte cenu přepínače, který umí tyhle "vymoženosti" pro IPv4, tak jej mnohdy pořidíte za polovinu ceny přepínače, který umí tyhle věci pro IPv6. V malých číslech se to nemusí tolik projevit, ale pokud řešíte infrastrukturu řekněme s dvěmi tisíci připojnými porty, tak ten cenový rozdíl je markantní.
Chci tím pouze říct, že zavádění IPv6 není pouhé nakonfigurování sítí na rozhraních směrovače (jak se někdy s oblibou prezentuje), ale věc má mnohdy daleko větší přesah a tedy i finanční dopad než se na první pohled může zdát.
Jediné v čem se IPSec v IPv4 a IPv6 liší je to, že v IPv6 je jeho implementace povinná (což ovšem neznamená, že ji všichni výrobci do svých produktů zabudují, případně, že tam bude jiná metoda šifrování a autentizace než NULL, NULL)
IPSec se samozřejmě od ostatních šifrovacích technologií liší, nicméně mají společné to, co se IPSec v článku vyčítá, tj. to, že není vidět do obsahu paketů a je tedy nutné IPSec zakázat. Tímto způsobem by se musely zakázat všechny šifrovací protokoly.
Ja jsem obycejny amater, ale o IPSec se rika, ze v IPv6 je trochu odlisne od IPv4. Me osobne zarazila informace, ze kazde zarizeni, ktere umi IPv6, by melo umet i IPSec. Poznal jsem uz zarizeni, ktera mela pamet tak na 5 (slovy) paketu a zadychavala se i pri vypoctu CRC. Vypocet nejakych sifer by pro tyto brouky byl vrazedny.
Neznam L2TP, ale IPSec se od OpenVPN hodne lisi a od PPTP docela taky.
Tak část o IPSec jste klidně mohli vyhodit, protože:
- je společná pro IPv4 i IPv6
- má téměř stejné vlastnosti jako ostatní technologie typu PPTP, L2TP, OpenVPN, atd.
Co se týká IPSec pro eduroam, tak nahrazení IPSecu RadSecem bylo dáno spíš nekvalitní implementací než nějakou systémovou chybou IPSecu. S kvalifikací správců to nemá nic společného.
Pro profesionální nasazení v koncových sítích není ještě IPV6 ani po 16 letech usilovného "vývoje" použitelné.
Nejvíce se směji tomu IPSecu to mne vůbec nenapadlo, že nejdůležitější funkcí firewalu v IPV6 bude zakázat IPSec komunikaci .....hlavně mně to baví z pohledu mé polemiky se zarytými IPV6-jasánky, kteří se těší, že už žádný NAT/PAT/NAPT jim nebude překážet v IPSec komunikaci a ono ejhle ..ono to možná bude ještě horší....
Osobně se obávám, že výsledkem postupné implementace IPV6 se vytvoří izolované ostrůvky postavené na jedné či druhé implementaci které budou mezi sebou protunelovány a situace bude ještě mnohem složitější než s dnešním NAPTem.
Program flood_router6 neposílá ICMP zprávy Neighbour Solitication, ale Router Advertisement.
Jsou dva způsoby obrany proti tomuto útoku. První spočívá ve filtrování oznámení směrovače (Router Advertisement) na všech portech přepínačů s výjimkou portů vedoucím ke směrovači. Toto umí pouze některé směrovače.
Druhá varianta spočívá v tom, že jako správce jsem schopen řídit stanice, které se připojí k přepínačům (802.1x) a současně jsem schopen řídit, jaké programy mohou uživatelé na těchto stanicích spouštět (např. dobře nakonfigurované politiky v rámci MS Network). Tento přístup není vhodný pro některé typy sítí jako jsou např. vysokoškolské koleje.
Ochrana před většinou v článku uvedených útoků závisí podobně jako v IPv4 na schopnostech přepínače. Když o nich někde povídám, tak končím doporučením, aby při nejbližších plánovaných upgradech přepínačů si vybrali takové, které budou schopni poskytnout ochranu aspoň proti některým uvedeným útokům.
V současnosti je nejdůležitější možnost filtrování ohlášení směrovače, popř. filtrování odpovědí DHCP serveru (DHCP snooping).
Netvrdím, že tyto funkce má každý přepínač na trhu, ale lze vybrat na přijatelné cenové úrovni.
Do jisté míry souhlasím. Zejména pokud někdo získá přístup do lokální sítě, tak na mnoha místech není problém provádět záškodnickou činnost.
Zásadní problémem je, že v současné době dokážete v IPv4 takové čínnosti alespoň omezit - DHCP snooping, ARP protection, dynamic lock down atd. (viz. díl s autokonfigurací). Problémem současného stavu IPv6 je, že tyto prostředky nedokážete nasadit ani pokud byste se rozkrájel a nebo za cenu obrovských nákladů.
Suma sumárum je na tom z hlediska bezpečnosti IPv4 stejně jako IPv6, není zde žádný zásadní rozdíl. Protokol sám prostě nic spasit nemůže, vše vždy bude záležet na konkrétní implementaci a jak s ní admini a useři budou zacházet. Rozřešením zranitelnosti jedné přidáte dvě další, nemají-li být na úkor použitelnosti...