IP maskarada (was: Re: Apache Proxy)

Frantisek Rysanek xrysf03 at staff.eunet.cz
Tue Jul 22 11:56:54 CEST 1997


> > Technicky popis cehokoliv se da sehnat, to neni problem. Me
> > spis zajimalo, v jake situaci pouzit IP_MASQUERADE a v jake
> > neroutujici pocitac s proxy.
To zalezi ponejvice na Vasich specifickych narocich na to, co chcete svym
uzivatelum umoznit. Pokud chcete aby meli transparentni pristup do site
pres Telnet, FTP a (temer) vsemi utilitkami ktere si stahnou z internetu,
pouzijte NAT/IP-masquerade. Pokud jim chcete pokud mozno vsechno zakazat a
pustit je jenom na mail, FTP a WWW, posledni dve s moznosti cache, poridte
si proxy a zakazte pod nim IP forwarding. Pokud chcete plny pristup plus
HTTP/FTP cache, zkombinujte oba prostredky - tim ziskate maximalni
moznosti a konfigurovatelnost celku. Bezpecnost si zajistite podle potreby
filtrovanim/wrapperem a prirozenymi vlastnostmi NAT a proxy. Vzhledem k
tomu, ze typickym prostredim k pouziti techto prostredku je dial-up linka,
o tu bezpecnost bych se az tak nebal.

> 1) Chcete k Internetu pripojit sit, ktera nema pridelenu sitovou IP adresu.
>    Diky maskarade se sit skryje pod adresu jednoho pocitace a muzete v ni
>    adresovat, jak je libo. Ovsem jako vyrazne jednodussi a systemovejsi
>    reseni mi pripada proste si dotycnou adresu opatrit.
Za urcitych podminek to ovsem znamena dost penez navic a pri malem poctu
uzivatelu vyhody neprevazi nad nevyhodami. Penize jsou samozrejme az na
prvnim miste :)

> 2) Chcete podvadet sveho poskytovatele Internetu - zaplatit si pripojeni
>    jednoho pocitace a povesit na nej celou sit. O tomhle samozrejme
>    slusny clovek ani neuvazuje.
Zda jde o podvod ci ne, to zalezi na smlouve, ocenovaci a obecne
marketingove politice toho ktereho providera. Myslim ze tu zatim probleskl
jediny pripad, kdy provider pouzil sankce vuci nekomu, kdo pouzil proxy (a
omylem o tom dal vedet na verejnosti).

Spis muze byt problem, pokud presne nevite, co delate - od sveho providera
nemuzete ocekavat zadnou podporu ci specialni upravy technickych parametru
Vasi pripojky. Za oboji se plati.
Problemove je specialne pripojeni site pres komutovanou linku, zvlaste
pokud si platite "jednouzivatelskou" sluzbu. Komutovana linka vyzaduje
specialni osetreni prenosu posty (prvni problem, kde muzete potrebovat
upravy u providera), pres jednouzivatelsky ucet je navic problem
protlacit postu vice prijemcum (s automatickym tridenim). Take
nepocitejte, ze pres komutovanou linku budete moci poskytovat sluzby
zbytku internetu (FTP, WWW servery) - tyto sluzby vyzaduji, aby byl server
stale dostupny (a to na staticke IP adrese, coz muze byt take problem).
Vlastni DNS sirene do sveta nema smysl uvazovat. (interni DNS samozrejme
neni problem.)
Lze tedy shrnout, ze roubovat sit na jednouzivatelskou pripojku ma cenu
pouze pro ucely simultanniho pristupu k interaktivnim sluzbam (WWW, FTP,
TELNET) klienty z nekolika pracovnich stanic najednou. Problemy budou s
dorucovanim posty vice uzivatelum do separatnich schranek (to nema s
Proxy/NAT co delat). Celkove bude problemem padavost, nespolehlivost a
nizka kapacita telefonni linky.


Napada mne jeste jeden zpusob pouziti NAT/Proxy, tedy:
3) Pripojeni k vice providerum bez nutnosti zridit Autonomni System :)
Ano, jiste, je to pritazene za vlasy, ale teoreticky by pro nekoho mohlo
byt zajimave routovat ruzna mista v internetu pres ruzne providery. Od
jednoho by mel clovek registrovane IP adresy, od ostatnich rekneme od
kazdeho jednu, na ktere by provozoval NAT (pripadne proxy cache). Nebo by
mohl mit NAT klidne pro vsechny. Z hlavy honem nevim, jestli by se dal
uplatnit dynamicky routing - pokud vim, routery u providera by se s
klientskou IP adresou odmitaly na toto tema bavit a i kdyby, musel by u
zakaznika sedet docela nadupany router, aby ty tabulky pobral do pameti a
stihal routovat. Takze zbyva staticky routing. V tom pripade by asi
default route sel na toho providera, ktery ma obecne nejlepsi konektivitu,
a specificke routy k nekterym sitim na ostatni.
Pro tento pripad se skutecne hodi spise NAT (masquerading), protoze jde o
problem ve vrstve IP - v aplikacni vrstve by se dal resit jen dosti tezko,
nejspis kaskadnim razenim cache serveru.
Doufam, ze mne za tento napad vazene publikum neutluce :)

> IP maskarada nema nic spolecneho s bezpecnosti (pocitac datagramy normalne
> propousti, jen meni jejich hlavicky), firewally a podobnymi mechanismy.
Ze nelze otevrit socket zvenci dovnitr (pokud si to vyslovne
nenakonfigurujete), to uz tu nekdo rikal...

Frantisek Rysanek





More information about the net mailing list