Sziasztok! Attachmentben talaltok egy patchet, ami nagyban egyszerusitheti a Zorp-hoz szukseges ipchains letrehozasat. A mukodese kb. annyi, hogy minden egyes Listener automatikusan felveszi a mukodesehez szukseges rule-t, egy megadott chain-be. Hasznalata a kovetkezo: - kell egy skeleton ipchains, ami a Zorptol fuggetlen szabalyokat tartalmazza (dns, ntp, !-y stb) - a skeleton ipchains a megfelelo iranybol "hivjon" meg egy olyan lancot, aminek a neve Z_<peldanynev> - a Zorp peldany init fuggvenyebol meg kell hivni az enableIPChains() nevu fuggvenyt (opcionalis parameter a chain neve, ha nem jo a default), ehhez be kell importalni mindent az IPChains modulbol: from Zorp.IPChains import * - a Listener-t egy kicsit maskepp kell meghivni: regebben: Listener(SockAddrInet('1.2.3.4', 50080), 'http') # ahol az 50080 az a port, ahova az ipchains redirektalt mostantol, ha automata ipchains-t szeretnel: Listener(SockAddrInet('1.2.3.4', 80), 'http', transparent=TRUE) # azaz portkent az eredeti portszamot kell megadni, # a redirektkent hasznalt portot a Zorp automatikusan generalja # portszam+50000 modszerrel. A letrejovo szabaly a kovetkezo alaku: ipchains -A Z_<peldany> -s 0/0 0:65535 -d 0/0 80 -j REDIRECT 50080 ha a cel vagy a forras cimtartomanynak nem jo a 0/0, akkor az is megadhato a Listener-nel: Listener(SockAddrInet('1.2.3.4', 80), 'http', transparent=TRUE, transparent_redir_to=50080, transparent_src=InetDomain('0.0.0.0/0'), transparent_dst=InetDomain('192.168.131.5')) 'transparent' nevu parametere eddig is volt a Listenernek, aminek az ertelmezese ezzel a patchel megvaltozna. Ezert hezitalok, hogy az 1.4-es branchbe bekeruljon-e ez a patch vagy se. Az 1.5-os valtozatunk egyenlore szet van bombazva, ezert az most nem lehetoseg, hogy abban release-ljuk. Kerdes, hogy a 'transparent' nevu parameter ilyen megvaltozasa zavaro-e szamotokra, illetve, hogy altalaban mi a velemenyetek egy ilyen feature-rol? -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
Balazs Scheidler wrote:
Sziasztok!
Attachmentben talaltok egy patchet, ami nagyban egyszerusitheti a Zorp-hoz szukseges ipchains letrehozasat. A mukodese kb. annyi, hogy minden egyes Listener automatikusan felveszi a mukodesehez szukseges rule-t, egy megadott chain-be. Hasznalata a kovetkezo:
Szia Bazsi! Ezt feltetlenul fel kell rakni, vagy csak szabadon valasztott? Koszi! Balage
On Thu, Mar 21, 2002 at 01:46:38PM +0100, Papai Balazs wrote:
Balazs Scheidler wrote:
Sziasztok!
Attachmentben talaltok egy patchet, ami nagyban egyszerusitheti a Zorp-hoz szukseges ipchains letrehozasat. A mukodese kb. annyi, hogy minden egyes Listener automatikusan felveszi a mukodesehez szukseges rule-t, egy megadott chain-be. Hasznalata a kovetkezo:
Szia Bazsi!
Ezt feltetlenul fel kell rakni, vagy csak szabadon valasztott? Koszi!
a patchet azert publikaltam itt, mert kivancsi vagyok a velemenyetekre. termeszetesen feltenni sem kotelezo, csak akkor ha hasznalni szeretned az uj lehetoseget. a patch allapota inkabb BETA, bar az alap funkciokat nem erinti. -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
On Thu, Mar 21, 2002 at 01:35:55PM +0100, Balazs Scheidler wrote:
Attachmentben talaltok egy patchet, ami nagyban egyszerusitheti a Zorp-hoz szukseges ipchains letrehozasat. A mukodese kb. annyi, hogy minden egyes Listener automatikusan felveszi a mukodesehez szukseges rule-t, egy megadott chain-be. Hasznalata a kovetkezo:
Az en velemenyem az, hogy en inkabb kezzel irnam meg a szukseges rule-okat, ezert ha bekerul is, akkor se legyen "kotelezo" hasznalni, lehetosegem legyen nekem eldonteni, hogy akarom-e alkalmazni, vagy sem. Amivel indokolnam: szinte mindenkinek van kialakult gyakorlata az ipchains konfiguralasara, es en peldaul nem szeretnem, ha ram akarna "eroszakolni" valaki a sajatjat :) Ebben az esetben pedig fejben kellene tartanom, hogy a zorp konfigfajljaban mar ez-meg-ez a rule megkrealodik, tehat nem kell meg egyszer beleirnom a sajat beallito szkriptembe. Es meg valami: ha egyszer atterunk az iptablesre, akkor ezt a reszt at kellene (valoszinuleg) irni. Kicsit feleslegesnek tunik az erre forditott munka, es az iptables konfigja - imho - sokkal bonyolultabb (lehet), mint egy ipchains konfig. -- Udvozlettel Zsiga
On Thu, 21 Mar 2002, Kosa Attila wrote:
Es meg valami: ha egyszer atterunk az iptablesre, akkor ezt a reszt at kellene (valoszinuleg) irni. Kicsit feleslegesnek tunik az erre forditott munka, es az iptables konfigja - imho - sokkal bonyolultabb (lehet), mint egy ipchains konfig.
szerintem nem bonyolultabb, számomra az iptables modellje sokkal tisztább és átláthatóbb. tetszenek az új feature-ok, az új szintaxis is. szerintem is akkor már inkább az iptables-be kelle fejleszteni. elõbb utóbb úgyis mindenki át fog állni a 2.4-re. ------------------------- Narancs v1 IT Security Administrator Warning: This is a really short .sig! Vigyazat: ez egy nagyon rovid szig!
On Thu, Mar 21, 2002 at 02:24:04PM +0100, Kosa Attila wrote:
On Thu, Mar 21, 2002 at 01:35:55PM +0100, Balazs Scheidler wrote:
Attachmentben talaltok egy patchet, ami nagyban egyszerusitheti a Zorp-hoz szukseges ipchains letrehozasat. A mukodese kb. annyi, hogy minden egyes Listener automatikusan felveszi a mukodesehez szukseges rule-t, egy megadott chain-be. Hasznalata a kovetkezo:
Az en velemenyem az, hogy en inkabb kezzel irnam meg a szukseges rule-okat, ezert ha bekerul is, akkor se legyen "kotelezo" hasznalni, lehetosegem legyen nekem eldonteni, hogy akarom-e alkalmazni, vagy sem. Amivel indokolnam: szinte mindenkinek van kialakult gyakorlata az ipchains konfiguralasara, es en peldaul nem szeretnem, ha ram akarna "eroszakolni" valaki a sajatjat :) Ebben az esetben pedig fejben kellene tartanom, hogy a zorp konfigfajljaban mar ez-meg-ez a rule megkrealodik, tehat nem kell meg egyszer beleirnom a sajat beallito szkriptembe. Es meg valami: ha egyszer atterunk az iptablesre, akkor ezt a reszt at kellene (valoszinuleg) irni. Kicsit feleslegesnek tunik az erre forditott munka, es az iptables konfigja - imho - sokkal bonyolultabb (lehet), mint egy ipchains konfig.
termeszetesen hasznalata nem kotelezo. jelenleg szukseges a transparent=TRUE hasznalata (vagy a default_transparent nevu valtozo TRUE-ra allitasa) az iptables-en valoszinuleg nagyon hasonloan fog mukodni a dolog (mondjuk mas modult kell importalni IPChains helyett) -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
sziasztok! adott a következõ setup: egy létezõ nem transzparens tûzfalat cserélnénk le zorpra, intranet users -> www/ftpcache -> zorp -> internet azon kívül hogy router=InbandRouter() mit kell még megadni? self.transparent=false? nem akarom az internetes dns-t beadni. tud a zorp akkor ilyent, hogy õt megjelölöm a web böngészõbe proxynak, vagy a cache-be parentnek és akkor õ feloldja a kéréseket? ugyanez kellen ftp proxy esetén is. transzparensbe már csináltam, de nem tr.be még nem sikerült összehozni. mit hova kell még írni, hogy tudja kiket lehet kiengedni? pl. csak bizonyos ipcímeket szolgáljon ki? tudom PF-bõl ezt leszabályozhatom, de a zorp tudja? köszönöm ---- ja és a policy.py syntaxisa elég gyakran változott, uh sose tudom mi hiányzik, kellene több sample config. szeretném a három zónát 3 instance-ra osztani, de így nem indul el. (linuxvilág alapján) köszi ------------------------- Narancs v1 IT Security Administrator Warning: This is a really short .sig! Vigyazat: ez egy nagyon rovid szig!
On Thu, Mar 21, 2002 at 05:39:05PM +0100, Narancs v1 wrote:
sziasztok!
adott a következő setup:
egy létező nem transzparens tűzfalat cserélnénk le zorpra,
intranet users -> www/ftpcache -> zorp -> internet
azon kívül hogy router=InbandRouter() mit kell még megadni? self.transparent=false?
ezek szerint a www/ftpcache cuccos parent proxykent hasznalna a zorpot? http eseten ez a setup mukodokepes, viszont ftp eseten nem. a legegyszerubb imho, hogy a cache szamara is transzparens a zorp, es nem adod meg parentnek.
nem akarom az internetes dns-t beadni.
ezt nem ertem.
tud a zorp akkor ilyent, hogy őt megjelölöm a web böngészőbe proxynak, vagy a cache-be parentnek és akkor ő feloldja a kéréseket?
igen, http eseten tudja. ftp eseten nem, illetve nem tamogatjuk a HTTP-be csomagolt FTP-t. A nem transzparens FTP ugy mukodik, hogy kozvetlenul az FTP proxyhoz kapcsolodsz, es ahelyett, hogy szimplan usernevet adsz meg, meg kell adnod user@gepnev-t. A proxy pedig a '@' utani gephez fog kapcsolodni.
ugyanez kellen ftp proxy esetén is.
transzparensbe már csináltam, de nem tr.be még nem sikerült összehozni.
mit hova kell még írni, hogy tudja kiket lehet kiengedni? pl. csak bizonyos ipcímeket szolgáljon ki? tudom PF-ből ezt leszabályozhatom, de a zorp tudja?
termeszetesen. definialsz egy olyan zonat, ami lefedi azokat a gepeket, amiket nem akarsz kiengedni, es egyszeruen nem adod meg outbound_service-kent az adott szolgaltatast. Pl: InetZone('nemhttp', ['192.168.1.2', '192.168.1.5', '192.168.1.11'], outbound_services=[], inbound_services=[]) Igy a fenti zonabol semmit nem lehet hasznalni. A Zorp mindig a legspecifikusabb zonat keresi meg, es az ahhoz rendelt jogokat hasznalja.
ja és a policy.py syntaxisa elég gyakran változott, uh sose tudom mi hiányzik, kellene több sample config.
az 1.4 soran nem valtozott a konfig, legalabbis lathatoan nem. most lenne az automata ipchains kapcsan egy valtozas, felteve persze, hogy ezt 1.4-be is berakjuk.
szeretném a három zónát 3 instance-ra osztani, de így nem indul el. (linuxvilág alapján)
mi a hibauzenet? -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
participants (4)
-
Balazs Scheidler
-
Kosa Attila
-
Narancs v1
-
Papai Balazs