obmedzenie http downloaderov

[Dan Lukes]

Vladimír Benc napsal/wrote, On 05/17/06 12:03:
>> 	A navic, vyzaduje, abyste mel zajisteno, ze IP adresa je
>> jednoznacne prirazena konkretnimu uzivateli a on nesmi mit moznost si
>> ji vymenit za jinou. To neni zdaleka vzdy zajisteno a neni to ani zas
>> tak jednoduche zajistit.
> 
> Muzete alespon nastinit, jak "to zajistit", pokud plati podminka
> nize ?
> 
>> vypnuto (jestli mate svazanou IP a MAC, tak bude muset prohodit i
>> MAC, coz je ale trivialni), a bez omezeni pojede dal ...

	Ja si ted vybavuji metody ctyri -

1. uzivatel vnitrni site se muze dostat "ven" jen tak, ze navaze nejaky 
VPN tunel s vhodnym VPN serverem a teprve timto tunelem (ktery je 
autentizovany a tak o totoznosti uzivatele neni pochyb) odchazi ven.

	Problem teto metody je zbytecny overhead a pri vetsim mnozstvi lidi 
take vykonostni problemy onoho VPN serveru (na druhou stranu, takovych 
muze byt vic). Dalsim problemem muze byt volba vhodneho VPN 
serveru/protokolu.

2. Kombinace svazani IP a MAC (staticke ARP zaznamy na routeru) 
kombinovane s evidenci na jakem sitovem portu se objevila jaka MAC. To 
je spis administrativni opatreni, protoze prohresku nezabrani - ale 
umozni ho dodatecne identifikovat. Muzete vsak prislusne informace 
analyzovat dostatecne casto a pak muze byt prestupce "zastrelen" 
relativne vcasne. Nevyhodou je, ze pouzita infrastruktura (switche) musi 
byt pouzitelnym zpusobem ochotny poskytovat pozadovanou informaci (jaka 
MAC je na kterem portu pouzivana). Druhou nevyhodou je, ze sit je 
"nemobilni" - pocitac musi byt registrovan an konkretni zasuvce (portu 
switche) a neni dovoleno s nim "jen tak" prechazet.

	Variantou teto metody je, ze mam na prislusnych switchich a portech 
(pokdu to umi) rovnou nastaveny jako jedine povolene prave ty MAC ktere 
tam byt maji - jina pak v dane zasuvce nefunguje.

3. Dalsi moznost je zde jiz zminena WWW autentizace na routeru (treba 
pomoci WWW), jak ji popsal Petr Macek. Ano, Windows, pokdu si nastavim 
cizi adresu, ale mam jinou MAC budou "rvat". Uz si ale nejsem jist, ze 
budou "rvat" i v pripade, kdy nastavim nejen cizi IP, ale take cizi MAC. 
  Kazdopadne, at uz rvouci nebo nervouci, takove Windows maji schopnost 
v omezene mire komunikovat, a to na ucet autentizovaneho uzivatele. 
Omezenou merou mam na mysli, z ebude (nikoli vsak neresitelny) problem s 
TCP, ale UDP (a nektere P2P site "jedou" nad UDP) v zasade fungovat 
bude. Lze take pouzivat autentizovane pocitace, tkere jejich uzivatel 
vypnul bez odhlaseni (coz neni nijak neobvykle).

4. Autentizace  na druhe sitove vrtve - 802.1x. To ovsem musi umet 
switche a uzivatel musi na sve strane autentizaci tohoto typu 
nakonfigurovat, coz muze laikum cinit potize a vubec, pro jeho OS musi 
byt v tomto smeru podpora (pro Windows >2000 a Linux je urcite, dal zas 
takovy prehled nemam, podpora na FreeBSD je *velmi* problematicka).  Tim 
vime, kdo danou zasuvku v konkretni chvili pouzival a lze vynutit i to, 
ze pouziva prave a pouze svoji registrovanou MAC. Zbytek jsou staticke 
ARP zaznamy na routeru, ktere svazi (alespon pro prichozi pakety) MAC se 
spravnou IP.

	Metody [1] a [3] nedokazi zabranit neautorizovane pripojenemu pocitaci 
komunikovat po vnitrni siti - coz muze byt nekdy take nezadouci (siri 
tam viry, pokousi se napadnout ostatni pocitace a ty pak vyuzit ke 
komunikaci ven a podobne).

	My v soucasne chvili pouzivame v zasade [4] pripadne, na nakterych 
sitich, "jen" monitorujeme, kde se objevila ktera MAC (bez pravidelneho 
vyhodnocovani).
	
	Nejsem si ovsem jist, zda neopoustime oblast FreeBSD prilis a nakolik 
to zde majoritu ucastniku zajima nebo alespon neobtezuje - mozna by bylo 
lepsi v pripadne dalsi diskusi pokracovat jiz mimo konferenci ...

					Dan


P.S. K Petrovi M. - na to ipfw tee bacha - krome toho, ze to udela kopii 
do divert socketu je to soucasne "accept" pro originalni paket. Jinak, u 
nas studenti neplati za data, ale maji zakazano, pod postihem odpojeni, 
  urcity objem dat bez predchozi domluvy prekrocit. Mluvim o datech 
odchozich - prichozi, maji-li "verejne" adresy, ovlivnit dostatecne 
nemohou (predpokladam, z ei u vas bud' nemaji verejne adresy nebo plati 
jen za odchozi data).



-- 
Dan Lukes                                   SISAL MFF UK
AKA: dan at obluda.cz, dan at freebsd.cz,dan at kolej.mff.cuni.cz