Taky uz mne kolikrat napadlo, ze street access je trochu riskantni sport, ale rekneme, ze to je jedna z myslenek CZFree, ale na druhou stranu tim vystavujeme sit naprosto vsanc.
Napadla mne myslenka, ktera by mohla byt celkem pruchozi a to je povolit street pristup jen registrovanym, prostrednictvim jakehosi dashboardu, kde by se po prihlaseni musel clovek prihlasit a AP by overilo registraci v centralni databazi uzivatelu a pokud by to bylo ok, tak by povolilo pristup.
to je jasný a taky jsem o tom psal. pokud bude použit jede n hadrware pro street acces a zároveň pro vnitřní komunikaci czf, tak rovnou zapomeňte na jakoukoliv bezpečnost. nemluvě o tom, že pokud na tom rozhraní běží už DHCP, tak to dhcp není schopné přidělovat ip adresy ze dvou různých rozsahů.
V tomto případě není co řešit.
__________________
----------------------------------------------
|Autor je možná lama a v sítích vůbec nevyzná|
----------------------------------------------
Tak jsem to hrde precetl cely a reknu vam, kazdy mame ze svych zkusenosti svoji predstavu o bezpecnosti. uprimne my na Suchdole street access mame, ale za pul roku se tu pripojili dva lidi a doba jejich pripoje byla v radu minut a dle logu je moc czf nezajimalo, sli rovnou na net.
kazdopadne souhlasim s neem, mit na jednom routeru access pro registred nodes a street access, zabezpeceni je celkem "zaplatovanim cedniku".
Asi bych se priklanel k myslence mit dva routery, prvni by byl s closed MAC policy pro nodes a konfigurovany pro ucely pouziti CZF site, druhy by byl mohl mit dhcpko a NAT, nic vic, pricemz by by byl pripojeny k prvnimu routeru, kde by slo nastavit jedno pravidlo podle NATovane IP co ano co ne. Netlucte me za nazor, ale tim nejaky kradeni MAC a IP odpadne, jelikoz vysledna IP by byla vzdy druheho routeru a restrikciovana prvnim routerem jako jeden nod.
Co se tyce nazoru o bezpecnosti, souhlasim s vetsinou z vas, tedy je predmetem kazdeho, tedy kazdy by mel mit firewall, ci NAT, aby pripadny narusitel nemohl napadat ostatni z hacknute, jinak "permited" masiny. APcka (tedy spravci ) by meli zvazit filtering portu 135-139 - win netbios, ktery je nejpouzivanejsim zpusobem hacku. Dale pouzivat firewall v pristupu INPUT na jejich routery na nutne sluzby, omezit porty SSH na duveryhodne IPs, pripadne zakazat uplne.
V pripade sifrovani, mozna bych se primlouval k IP tunneling s kryptovanim+kompresi AP-AP, tez by nebylo marne vyuzit vrstvu PGP (verze 7.0 jeste pod GNU/GPL) pro komunikaci Win-Win.
Samozrejme moznosti je nespocet, ale rad bych se pripojil k nazorum co vetsinovy node, to lama, takze v ramci moznosti samotnych uzivatelu, aby byl zasah v systemu jim samotnym srozumitelny, aby vubec byli ochotni trochu "naklikat" zabezpeceni a nerekli vam z fleku "to je slozity, pecu na to"...
z me strany asi vsepro tuto chvili
__________________
...desktop mam usporadany dle Leffingwellova-Bronsteinova schematu psaciho stolu, verze B...
proto jsem navrhoval ten web, kde se to vygeneruje vcetne "idiotova popisu". mozna by bylo vhodne vygenerovat dva skripty pro zabezpeceni routeru. jeden by byl pro iptables a druhy pro ipchains jstli to nekdo nekde jeste pouziva. vim ze nastavit iptables neni zase tak slozite, ale neni to ani jedoduche obzvlast pro ty co tomu skoro nerozumi. na druhou stranu je take potreba predem rict, ze pouziti firewallingu s sebou prinasi zvysene naroky na hardware. Tyto naroky stoupaji s narustem objemu prenasenych dat a pripadne rychlosti. pokud jsou ted nekde spoje stavene na PI 200MHz, a proteka timto strojem vic jak 2 Mbps, tak takovy stroj nema sanci proste vsechno odfiltrovat. spojeni se zacne hroutit.
__________________
----------------------------------------------
|Autor je možná lama a v sítích vůbec nevyzná|
----------------------------------------------
Dobre, ze o tom diskutujeme. Nicmene - at uz podnikneme kroky k zabezpeceni
nebo ne - teprve praxe ukaze. Pokud dojde k nejakemu masivnimu prulomu, stejne
nejvetsi slabinou czfree bude asi spatna koordinace na prachobycejne lidske
urovni...
Ach jo, je nad mé síli komentovat to, co se tu objevilo od pátku, nebyl jsem tu o víkendu, ale řeknu jen to nejdůležitější.
Ad 1)K těm prvním dvoum příspěvkům hned po mě: Netvrdil jsem, že chci WEP a zároveň street access, co je to za blbost ? To jsem neřekl.
Ad 2)Můj návrh není ani tak obrana, jako spíše nástroj snadné nastavitelnosti a identifikace.
Ad 3)Po přečtení některých příspěvků, argumentující všemožné výmluvy na složitost deklarování a dodržení opatření, musím říci, že někteří nepochopili v tom ten systém.
Vím, že někteří ani nevíte, co je C a N číslo, ale to jsem říkal, jde o to, že žádná zásadní koordinace mezi všema nemusí být !!!
Ten rozsah je přesně dán od začátku v CZF-RFC-ADDRESSING, s tím rozdílem, že nemá praktické efektivní využití !!!
Ovšem to se může změnit, při diskusi v tomto vlákně mě právě na poput oddělení ip rozsahu napadlo toto v souladu s CZF-RFC-ADDRESSING napadlo toto řešení snadné identifikace, útočník dostane ze streetaccessu bez potíží IP, ale z rozsahu o kterém my ostatní víme, co je zač a jak s ním máme naložit resp. jak s tím má naložit FW.
Nevidím důvod jak tu HonzaK doporučuje, zakazavot rovnou všechno a pak něco povolovat, řeknu to jinak, mám větší důvěru v anonymy uvnitř sítě než k street accesu.
Ten rozsah je stejnak už dávnou definovanej, toho se nezbavíte .
A teď ještě jednou názorný příklad - předpoklad:
BFU nebo GURU, to je fuk, ví, že jistý rozsah tvořený podle systému (RFC) je pro street access, a proto může už dnes tento rozsah snadno "uchopit", aniž by ho jakkoliv zajímalo zdali ten rozsah využije jednou za měsíc dohromady 10 lidí v různých cloudech v celé CZFree.Net, dále ho nebude vůbec zajímat, jak a kdy se ty adresy rozdaly a rozdávají (všimě te si toho časování slova ještě jednou prosím), to ani neznamená nějakou organizaci nebo kooperaci či nedejbože přečíslovávání jak se tu naznačuje, protože když to jsou RFC, tak to asi budou dodržovat všichni, co to RFC dodržují a vůle RFC v CZF dodržovat je velká (teda alespoň podle jejich tvůrců :-))) ). Jednoduše proces jde takto, správce cloudu dává jednotlivým správcům NODů své vlastní N číslo, od toho se vyvíje pak naprosto všechno ostatní včetně mého navrženého řešení.
NÓD dostane N číslo a ví, že má k dispozici 3 rozsahy a plus další který sice nemá podle současné podoby RFC, ale teoreticky může mít, ale to jsem teď odběhl.
Takže NÓD ABRAKA DABRA:
ten zná správce cloudu i node, a jeho N číslo,
ví, že z rozsahu 10.C.64+N.0/24 jsou připojeni stálý koncový uživatelé,
ví, že z rozsahu 10.C.128+N.0/24 jsou připojeni uživatelé street access,
ví, že z tohoto rozsahu je jen část pro street access, a tohle vědí všichni a nebo jestli chceme tak to uděláme klidně celý Cčko, stejnak je těch adres mraky, ale to je detail nechytejte mě za slovíčko
nyní řekněme, že ABRAKA DABRA má N=10
Takže pokud je někdo napaden a ví, že adresa je 10.220.138.57 a třeba jiná další adresa je 10.220.74.11, že může jít za správcem cloudu Bčkového rozsahu 10.220/16, ten mu sdělí, že 138-128 a 74-64 je vždy N=10 a to že je NODe ABRAKA DABRA, a že ho spravuje mánička. V podstatě si k tomu číslu N dojde sám každý i to BFU, stačí jen se dozvědět, kterej NODe má N=10 např., takže není zas tak nemožné se dobrat k cíli.
Ovšem toto by se jaksi nemuselo vůbec stát, kdyby bylo dáno, že právě Cčkový roshah v každém Bčku (bavím se teď o třetím bajtovém slově) od 128+N, kde N=1...63, tedy 129-191.* ve všech cloudech tedy všechna Bčka jsou rezervována pro street access, proto by na tento rozsah mohl snadno aplikovat restikce pokud by cítil potřebu, taktéž i správce node (pozor ne jak tu někdo říkal správce cloudu).
Takže v absolutních číslech jedná se o C*63*255= no ... něco v miliónech ip adres, což vypadá hrůzně, ale systém by v tom nějakej byl.
Jednoduše už dnes můžu aplikovat na tento rozsah restikce, aniž bych se staral jak je využívanej a všelijak si měnil něco v compu, protože o to by se starali správci nodů, podle tohoto klíče by street accessům rozdali ipčka a je to, samozřejmě to vše za předpokladu, že se to dodrží.
HACKer by měl pocit, že má normální ipčko a byl by v klidu a nekradl by ipčko z jiného rozsahu, BFU by zase věděl že ten rozsah má např rejected. Vlk by se nažral a ovce by zůstala celá.
BTW: a teď to nejdůležitější toto není žádná komplexní ochrana, je to prostě návrh jak využívat jistý IP rozsah, který je stejnak už dávno dán, a kterého se nezbavíme.
31.08.2003 v 09:56
) by meli zvazit filtering portu 135-139 - win netbios, ktery je nejpouzivanejsim zpusobem hacku. Dale pouzivat firewall v pristupu INPUT na jejich routery na nutne sluzby, omezit porty SSH na duveryhodne IPs, pripadne zakazat uplne.
.
