ok, se speciálním adr. rozsahem jsem se trochu unáhlil.
ale názory některých mají větší váhu, než jiných. pokud jbohac napíše, že se mu to moc nelíbí, tak mu to věřím. ctirada neznám, ale asi taky neplácá do větru.
wep je sice skoro k ničemu, ale je to lepší než nic. je rozdíl vyběhnout nahatej do deště nebo si vzít aspoň deštník.
k těm správcům, to je fakt těžký. většina lidí, co něco umí totálně nestíhá. ale jsou nějaký crony, které se dají nastavit, aby automaticky jednou týdně zkoukly opravy, stáhly je a nainstalovali. ale je to na odpovědnosti každého jednotlivce, věnovat tomu aspon chvilku navíc při nastavování.
většinou to bohužel bývá tak, že se postaví AP s vypětím všech sil a pak už se na to nešáhne.
a nechytej mě za slovo, víš dobře, jak to myslím. AP=linuxový router, většinou.
mam pocit, ze se tu micha nekolik problemu dohromady.
Je opravdu potreba prisne rozdelit aplikacni a transportni vrstvu site.
V soucasne dobe se bavime pouze o transportni, pripadne fyzicke vrstve.
Z tohoto hlediska neexistuje nic jineho nez WEP/EAP.
Pokud chcete zabezpecit svoji sit a zaroven poskytovat verejny pristup k siti, nezbyde vam nic jineho nez rozdelit sit na dve casti jak na urovni hardwarove tak na urovni softwaru (tim myslim adresaci site).
pro ucely vnitrni casti CZF je vhodne vypnout propagovani SSID, pouzit WEP(EAP), a pouzit mac policy.
Pro Hotspoty pouzit normalne verejny pristup s dedikovanym rozsahem ip adres, ktery bude mozne jednoznacne identifikovat a pro ty, kdo si nepreji hotspotum povolit pristup do svych siti umoznit zamezeni pristupu temto rozsahum ip adres. jine technicke reseni me nenapada.
Toto reseni je podmineno ovsem spolupraci vsech cloudu ktere nabizeji hotspot, nebo ho maji v planu nabizet.
Predpokladam ze maximalni pocet pripojenych lidi na jeden hotspot bude 64. vetsi mnozstvi je temer nerealizovatelne uz technicky. Duvod proc to neni technicky realizovatelne je ten, ze asi malokdo ma kapacitu na to aby povolil pristup vsem lidem na hotspot pripojenych do dalsich casti CZF. uvazujme jako maximalni realnou propustnost 3,2Mbps hotspotu. pri 256 pocitacu to je asi 12,5 kbps na hlavu (neresme to, ze z toho musi byt jedno ipcko routeru, druhe site a treti broadcast).
Bude nekde existovat centralni databaze hostpot adresniho rozsahu, ze ktereho se bude pridelovat jednotlivym cloudum (nodum) poskytujicim sluzbu hotspot, adresni rozsah, na zaklade techto zaznamu v dbf dojde k zapisu routovaciho zaznamu do Zebry a soucasne s tim se vygeneruje nejaky jednoduchy skriptik nebo napoveda, ktera umozni tento prideleny adresni rozsah zapsat na strane cloudu/node do jeho router/firewallu. Defaultne bude hotspot adresni rozsah zakazany, a pri vygenerovani pozadavku dojde k povoleni daneho prideleneho adresniho rozsahu s naslednym napovednym skriptem/textem pro cloud/node.
Vzhledem k tomu ze CZF ma v sobe asi tak prumerne 170 IQ na metr ctverecni, tak si myslim ze tohle napsat a stvorit je otazka chvilky.
__________________
----------------------------------------------
|Autor je možná lama a v sítích vůbec nevyzná|
----------------------------------------------
Zapoměl jsem dodat že AP != Cloud/node
to? věc jedna,
Pokud si to bude řešit každý Cloud/node sám, tak se na to rovnou můžete vys....., protože jakékoliv zabezpečení postrádá smysl, nebo se může potom stát že z nějakého node/cloudu proběhne attak do czf a všichni se svorně na daný cloud/node namíchnete a sestřelíte ho... to mi nepřipadá jako vhodný způsob řešení problematiky......
__________________
----------------------------------------------
|Autor je možná lama a v sítích vůbec nevyzná|
----------------------------------------------
30.08.2003 v 14:37
