- zorp-hu - lists.balabit.hu

self.session.pssl.client_peer_certificate.subject elerheto a GPL Zorp-ban?
by Dániel Vásárhelyi 08 Sep '06

08 Sep '06

Sziasztok, self.session.pssl.client_peer_certificate.subjectet szeretnem kinyerni v2 vagy v3 gpl zorp-ban. Lehetseges mar? asd -- Dániel Vásárhelyi If advertisers spent the same amount of money on improving their products as they do on advertising then they wouldn't have to advertise them. Will Rogers

1 0

cttproxy 2.6.17 ?
by Hegedus Ferenc 29 Aug '06

29 Aug '06

Sziasztok Varhato valamikor a 2.0-as cttproxy 2.6.17-es kernelhez valo verzioja? Elore is koszi! Feri

2 1

HTTPS Proxy lefagy.
by Ifj. Darvas Istvan 25 Aug '06

25 Aug '06

sziasztok, A jelenseg a kovetkezo, a HTTPS proxy egy ido utan fogja magat es lefagy. zorpctl restart HTTPS-el sem lehet ujrainditani, hanem konkretan kikell loni a processt es startolni kernel: linux-2.6.15 tproxy: cttproxy-2.6.15-2.0.4 zorp: zorp-3.0.9 , libzorpll3.0.6 (debiancsomagbol felrakva) loglevel 6-ra allitottam mar a naplozast es figyeltem mikor volt lefagyas. kulonbozo libekre panaszkodik a lefagyaskor. Mire lenne szukseg, hogy elkapjuk a kismanot a rendszerben? Amikor ki van fagyva, akkor gyakorlatilag semmit sem hajlando csinalni, meg hibanaplozast sem folyatatja... csak a kill -9 -re reagal... Udv, Istvan ui.: a logot csatoltam, a vegen van a hiba

4 5

HttpProxy, tcp kapcsolat szakadas, timeout
by Tuska Viktor 23 Jun '06

23 Jun '06

Udv, a kovetkezo problemaval kuzdok: HttpProxy-n keresztul bizonyos (intranet-es)webloldalak elerese eseten az oldalhoz tartozo utolso (komponens-ek/)kep -ek letoltese 30 masodperces timeout-al tortenik. Kicsit tcpdump-olgattam es a kovetkezokre jutottam: A zorp kulso laban csordogalnak lefele az adatok, mignem a browser-tol erkezik egy GET 14:41:57.449898-kor. Ezutan erdekes modon ezen a tcp kapcsolaton keresztul 30 masodpercig nem megy adat semelyik iranyba. Kozvetlenul ezutan a keres utan erkeznek a browser-tol ujabb keresek egy masik(52156-os port) tcp kapcsolaton keresztul. Ezekenek a kereseknek a kiszolgalasa megtortenik jol, majd az elobb emlitett 30 masodperces ido lejarta utan megerkeznek az adatok a server-tol, a korabban kert GET-re valaszkent az 52155-os porthoz tartozo tcp kapcsolaton keresztul. Ugy tunik, hogy valami ok miatt a zorp belso laban mar nem jelenik meg idoben a 14:41:57.449898-kor a kulso labon beerkezett GET keres. 30 masodperc utan a webserver a belso labon lezarja 14:42:27.474240-kor a korabban hasznalt tcp kapcsolatot(gondolom timeout miatt, mivel semmilyen adatforgalom nem generalodik azon). Ezutan a zorp nyit 1 ujabb kapcsolatot es szepen elkuldi azon GET kerest, amit 30 masodperce "tartogatott". Van olyan pillanat, amikor ugyanazon oldalnal nem jelentkezik a hiba. A zorp log-jaiban nem latok error-t/furcsasagot. Kicsit reszletesre allitottam a zorp log-jat, ezert nem vagtam azt be ide. Van valakinek otlete mi lehet a gond? Esetleg valamilyen konfiguralasi problema? Szivesen kuldenek tovabbi adatokat, ha szukseges. Zorp external interface: ... 14:41:57.424095 browser.52155 > zorp-external.www: . ack 139408 win 16022 <nop,nop,timestamp 27500724 7753825> (DF) 14:41:57.449898 browser.52155 > zorp-external.www: P 4184:4774(590) ack 139408 win 16022 <nop,nop,timestamp 27500730 7753825> (DF) 14:41:57.449899 browser.52156 > zorp-external.www: S 4265315493:4265315493(0) win 5840 <mss 1460,sackOK,timestamp 27500731 0,nop,wscale 2> (DF) 14:41:57.449958 zorp-external.www > browser.52156: S 2947827391:2947827391(0) ack 4265315494 win 5792 <mss 1460,sackOK,timestamp 7753828 27500731,nop,wscale 0> (DF) 14:41:57.450124 browser.52156 > zorp-external.www: . ack 1 win 1460 <nop,nop,timestamp 27500731 7753828> (DF) 14:41:57.457584 browser.52156 > zorp-external.www: P 1:589(588) ack 1 win 1460 <nop,nop,timestamp 27500732 7753828> (DF) 14:41:57.457616 zorp-external.www > browser.52156: . ack 589 win 6468 <nop,nop,timestamp 7753829 27500732> (DF) ... 14:41:58.029345 zorp-external.www > browser.52156: P 53723:54921(1198) ack 8818 win 15876 <nop,nop,timestamp 7753886 27500875> (DF) 14:41:58.031300 browser.52156 > zorp-external.www: . ack 54921 win 15705 <nop,nop,timestamp 27500876 7753886> (DF) 14:42:03.033384 zorp-external.www > browser.52156: F 54921:54921(0) ack 8818 win 15876 <nop,nop,timestamp 7754387 27500876> (DF) 14:42:03.073498 browser.52156 > zorp-external.www: . ack 54922 win 16022 <nop,nop,timestamp 27502136 7754387> (DF) 14:42:05.087281 browser.52156 > zorp-external.www: F 8818:8818(0) ack 54922 win 16022 <nop,nop,timestamp 27502640 7754387> (DF) 14:42:05.087299 zorp-external.www > browser.52156: . ack 8819 win 15876 <nop,nop,timestamp 7754592 27502640> (DF) 14:42:27.483361 zorp-external.www > browser.52155: P 139408:139746(338) ack 4774 win 16320 <nop,nop,timestamp 7756831 27500730> (DF) 14:42:27.483386 zorp-external.www > browser.52155: . 139746:141194(1448) ack 4774 win 16320 <nop,nop,timestamp 7756831 27500730> (DF) 14:42:27.483409 zorp-external.www > browser.52155: . 141194:142642(1448) ack 4774 win 16320 <nop,nop,timestamp 7756831 27500730> (DF) 14:42:27.483988 browser.52155 > zorp-external.www: . ack 141194 win 16022 <nop,nop,timestamp 27508239 7756831> (DF) ... Zorp internal interface: ... 14:41:57.420243 webserver.webcache > zorp-internal.33219: P 136615:137071(456) ack 4184 win 49232 <nop,nop,timestamp 243245676 7753825> (DF) 14:41:57.420290 zorp-internal.33219 > webserver.webcache: . ack 129375 win 34752 <nop,nop,timestamp 7753825 243245676> (DF) 14:41:57.420296 zorp-internal.33219 > webserver.webcache: . ack 132271 win 34752 <nop,nop,timestamp 7753825 243245676> (DF) 14:41:57.420346 zorp-internal.33219 > webserver.webcache: . ack 137071 win 31856 <nop,nop,timestamp 7753825 243245676> (DF) 14:41:57.420364 webserver.webcache > zorp-internal.33219: . 137071:138519(1448) ack 4184 win 49232 <nop,nop,timestamp 243245676 7753825> (DF) 14:41:57.420365 webserver.webcache > zorp-internal.33219: P 138519:139236(717) ack 4184 win 49232 <nop,nop,timestamp 243245676 7753825> (DF) 14:41:57.420427 zorp-internal.33219 > webserver.webcache: . ack 139236 win 31856 <nop,nop,timestamp 7753825 243245676> (DF) 14:41:57.458339 zorp-internal.59756 > webserver.webcache: S 2940820984:2940820984(0) win 5840 <mss 1460,sackOK,timestamp 7753829 0,nop,wscale 0> (DF) 14:41:57.458597 webserver.webcache > zorp-internal.59756: S 1722218316:1722218316(0) ack 2940820985 win 49232 <nop,nop,timestamp 243245680 7753829,mss 1460,nop,wscale 0,nop,nop,sackOK> (DF) 14:41:57.458627 zorp-internal.59756 > webserver.webcache: . ack 1 win 5840 <nop,nop,timestamp 7753829 243245680> (DF) 14:41:57.459096 zorp-internal.59756 > webserver.webcache: P 1:589(588) ack 1 win 5840 <nop,nop,timestamp 7753829 243245680> (DF) 14:41:57.459345 webserver.webcache > zorp-internal.59756: . ack 589 win 49232 <nop,nop,timestamp 243245680 7753829> (DF) 14:41:57.464592 webserver.webcache > zorp-internal.59756: . 1:1449(1448) ack 589 win 49232 <nop,nop,timestamp 243245681 7753829> (DF) 14:41:57.464610 zorp-internal.59756 > webserver.webcache: . ack 1449 win 8688 <nop,nop,timestamp 7753830 243245681> (DF) ... 14:41:58.028135 webserver.webcache > zorp-internal.59756: P 55127:55236(109) ack 8818 win 49232 <nop,nop,timestamp 243245737 7753885> (DF) 14:41:58.028201 zorp-internal.59756 > webserver.webcache: . ack 55236 win 34752 <nop,nop,timestamp 7753886 243245737> (DF) 14:42:03.033452 zorp-internal.59756 > webserver.webcache: F 8818:8818(0) ack 55236 win 34752 <nop,nop,timestamp 7754387 243245737> (DF) 14:42:03.033759 webserver.webcache > zorp-internal.59756: . ack 8819 win 49232 <nop,nop,timestamp 243246237 7754387> (DF) 14:42:03.131822 webserver.webcache > zorp-internal.59756: F 55236:55236(0) ack 8819 win 49232 <nop,nop,timestamp 243246247 7754387> (DF) 14:42:03.131852 zorp-internal.59756 > webserver.webcache: . ack 55237 win 34752 <nop,nop,timestamp 7754396 243246247> (DF) 14:42:27.474240 webserver.webcache > zorp-internal.33219: F 139236:139236(0) ack 4184 win 49232 <nop,nop,timestamp 243248682 7753825> (DF) 14:42:27.474753 zorp-internal.33219 > webserver.webcache: F 4184:4184(0) ack 139237 win 34752 <nop,nop,timestamp 7756831 243248682> (DF) 14:42:27.474986 webserver.webcache > zorp-internal.33219: . ack 4185 win 49232 <nop,nop,timestamp 243248682 7756831> (DF) 14:42:27.475386 zorp-internal.36988 > webserver.webcache: S 2971223218:2971223218(0) win 5840 <mss 1460,sackOK,timestamp 7756831 0,nop,wscale 0> (DF) 14:42:27.475614 webserver.webcache > zorp-internal.36988: S 3369441031:3369441031(0) ack 2971223219 win 49232 <nop,nop,timestamp 243248682 7756831,mss 1460,nop,wscale 0,nop,nop,sackOK> (DF) 14:42:27.475641 zorp-internal.36988 > webserver.webcache: . ack 1 win 5840 <nop,nop,timestamp 7756831 243248682> (DF) 14:42:27.476110 zorp-internal.36988 > webserver.webcache: P 1:591(590) ack 1 win 5840 <nop,nop,timestamp 7756831 243248682> (DF) 14:42:27.476364 webserver.webcache > zorp-internal.36988: . ack 591 win 49232 <nop,nop,timestamp 243248682 7756831> (DF) 14:42:27.482734 webserver.webcache > zorp-internal.36988: . 1:1449(1448) ack 591 win 49232 <nop,nop,timestamp 243248682 7756831> (DF) 14:42:27.482764 zorp-internal.36988 > webserver.webcache: . ack 1449 win 8688 <nop,nop,timestamp 7756831 243248682> (DF) 14:42:27.482735 webserver.webcache > zorp-internal.36988: . 1449:2897(1448) ack 591 win 49232 <nop,nop,timestamp 243248682 7756831> (DF) ... #zorpctl version Zorp 3.0.11 Revision: devel(a)balabit.hu--zorp-1/zorp-core--mainline--3.0--patch-424 Compile-Date: Mar 6 2006 23:35:53 Config-Date: 2006/03/06 Trace: off Debug: off IPOptions: off IPFilter-Tproxy: off Netfilter-Tproxy: on Netfilter-Linux22-Fallback: on Linux22-Tproxy: off Conntrack: on Zorplib 3.0.6.6 Revision: devel(a)balabit.hu--zorp-1/zorp-lib--mainline--3.0--patch-134 Compile-Date: Apr 28 2006 14:29:30 Trace: off MemTrace: off Caps: on Debug: off StackDump: on Probaltam gpl-es(3.0.9) zorp-al is, ami ugyanezt produkalta. Remelem valamennyire erthetore sikeredett. Koszontem, Viktor

1 0

Skype
by _Zorp 21 Jun '06

21 Jun '06

Sziasztok! Használ valaki Skype-ot Zorp tűzfal mögül élvezhető minőségben? A problémám a következő: A tűzfal úgy van beállítva, hogy alapvetően minden forgalmat blokkol, ami nem kell meghatározott feladatokhoz, így nincsenek szabadon használható portok sem kifelé, sem befelé. A HTTP forgalom a megfelelő alkalmazás proxyval és vírus ellenőrzéssel megy át a tűzfalon. A HTTPS forgalom ma még plug-proxyval működik, de ezt is tervezzük alkalmazás proxyra cserélni. Ilyen feltételek mellett azonban a Skype működik ugyan, de gyakorlatilag használhatatlan, annyira szagatottan megy át a hang. A Skype dokumentációja szerint az ideális hálózati konfigurció a Skype számára: 1. Kimenő TCP forgalom engedélyezett az 1024 és nagyobb portokra 2. Kimenő TCP forgalom engedélyezett a 80 és 443 portokra 3. Kimenő UDP forgalom engedélyezett az 1024 és nagyobb portokra. Ahhoz, hogy az UDP-t használni tudja a Skype a NAT-nak engedélyeznie kell, hogy UDP válasz csomagok visszajussanak a küldőhöz (Az UDP "kapcsolatokat" minimum 30 másodpercig meg kell tartani, de azt javasolják, hogy ha lehet, akkor inkább 1 óráig legyenek aktívak az ilyen kapcsolatok.) 4. A NAT konzisztens fordítást kell alkalmazzon, azaz a kimenő címfordításnál használt port azonos a bejövő csomagoknál használt porttal UDP csomagok esetében. A felsorolt környezet vállalati környezetben sok mindennek nevezhető, de nagyon biztonságosnak biztosan nem. Persze van egy olyan jegyzet is a Skype dokumentációban, hogy mik a minimális feltételek a tűzfal mögüli használathoz: - Lehetőleg legyen engedélyezett a kimenő TCP forgalom minden portra (1-65535) - Ha ez nem lehetséges, akkor a 443-as TCP portra legyen engedélyezett a kimenő forgalom. - Ha a fentiek nem lehetségesek, akkor a 80-as portra legyen engedélyezett a kimenő forgalom, de ügyeljünk arra, hogy nem jó az a megoldás, ahol a tűzfal ellenőrzi a 80-as porton a HTTP protokolt, mert a Skype nem használja a HTTP protokolt, így az ilyen tűzfal blokkolni fogja a Skype működését. - Ha a fentiek nem lehetségesek, akkor a Skype képes HTTPS/SSL vagy SOCKS5 proxy használatára. Ezzel sem vagyok nagyon kisegítve. Gondolom esetemben a 443-as porton a Plug-proxyn keresztül megy, és a többi forgalom blokkolt, de így nem igazán használható rendeltetésének megfelelően. Van valakinek esetleg olyan megoldása, ahol még elfogadható szintű a hálózati biztonság és megfelelő minőségben képes működni a Skype is? (Nem kell lemondani a 80 és 443 portok protokol elemzéséről, nem kell kinyitni az összes nagy TCP és UDP portot kifelé.) Van esetleg tapasztalat proxy használatra vonatkozóan és ha igen, akkor melyik proxy szofvert és mire figyelve érdemes használni? A probléma biztosan a tűzfalon van, mert ha ugyanazt a gépet átteszem a tűzfal mögé, akkor nagyságrendeket javul a Skype hangminősége. Előre is köszönöm a segítséget. Petya

6 7

cib
by Kosa Attila 24 May '06

24 May '06

Hello! A www.cib.hu cimen elerheto javas banki alkalmazast sikerult mar valakinek zorp mogul hasznalnia (nem sima pluggal)? Mert ugy tunik, hogy ha az alkalmazas nem a sajat certificate-jet "latja", akkor nem indul el... Azt account nelkul is ki lehet probalni, hogy eljut-e odaig az ember, hogy beirhassa a usernevet es jelszot. -- Udvozlettel Zsiga

4 6

smuggle attack
by Kosa Attila 22 May '06

22 May '06

Hello! Zorp 3.0.8, Sarge, kernel 2.4.32. Sima http proxy eseten eleg sok oldal miatt (peldaul tomato.integrity.hu) kapom az alabbi uzenetet a logba: Possible smuggle attack, removing header duplication; header='Connection', value='keep-alive' Eddig nem kaptam, es mas verzioju zorp-pal kapcsolatban sem talalkoztam meg ilyen uzenettel. Valaki el tudna mondani, hogy mi ez? -- Udvozlettel Zsiga

2 4

egyszeru sedproxy help
by Rozsahegyi Bela 19 May '06

19 May '06

Sziasztok! Par napja ismerkedem a Zorppal (3.0.9GPL, Centos4.3(Python 2.3.4)), de picit elakadtam egy egyszerunek latszo dolognal. A vegso cel egy feloldalas https proxy lenne (doksibol megvan, mukodik), url filterrel (google+levlistabol megvan, mukodik), illetve egy sed-es kiegeszitessel, mivel a webszerver egy aldott jo resin, amit nem akarok piszkalni lehetoseg szerint, s http://-t valaszolgat vissza, illetve ha mar a lehetoseg adott, akkor meg szepitenek is rajta pluszban egy konyvtarnev cserevel kesobb, usereknek legyen jo cimszoval, de az alapok se mennek. A doksiban ratalaltam ehhez a sedproxys peldara, nem tagadom, orultem is neki, de nem akarja az igazat. Fizikailag nezve nem csereli le a http-t, ekozben logban 7-es loglevel felett egy tracebacket is megemlit mar. policy.py reszlet, leegyszerusitve teljesen, tenyleg szinte copy-paste szintu mar: (remelem nem csuszik szet, de indent sztem rendben ranezesre) class FeloldalasHttpsProxy(PsslProxy): def config(self): PsslProxy.config(self) self.client_need_ssl = TRUE self.client_cert_file = '/usr/local/etc/zorp/https/admin.crt' self.client_key_file = '/usr/local/etc/zorp/https/admin.key' self.client_ca_directory = '/usr/local/etc/zorp/https/https.ca/' self.client_verify_type = SSL_VERIFY_NONE self.server_need_ssl = FALSE self.stack_proxy = HttpSedProxy class HttpSedProxy(HttpProxy): def config(self): HttpProxy.config(self) self.response_stack["GET"] = (HTTP_STK_DATA, "/bin/sed -e 's|http://|https://|g'") Log reszlet: May 19 05:13:30 fw intra[8205]: (Log thread): Traceback (most recent call last): May 19 05:13:30 fw intra[8205]: (Log thread): File "/usr/local/share/zorp/pylib/Zorp/Proxy.py", line 236, in stackProxy May 19 05:13:30 fw intra[8205]: (Log thread): proxyLog(self, CORE_DEBUG, 7, "Stacking child proxy; client_fd='%d', server_fd='%d', class='%s'", (client_stream.fd, server_stream.fd, proxy_class.__name__)) May 19 05:13:30 fw intra[8205]: (Log thread): AttributeError: 'str' object has no attribute '__name__' Barmi otlet, tipp, javaslat? :) Elore is koszi, RB

3 2

Zorp Mérnöki Vizsgák
by Gyorko Zoltan 24 Apr '06

24 Apr '06

Zorp mérnöki vizsgák május 8-án A Zorp mérnöki képzés korábban bejelentett átalakulásának utolsó lépéseként bevezetjük a kétszintű vizsgarendszert, melyben BCZA és BCZE oklevelet szerezhetnek a hallgatók. Az új partnerek már csak vizsgázott mérnökökkel nyújthatnak Zorp támogatást, meglévő partnereinknek 2006 év végéig van idejük arra, hogy Zorp mérnökeik levizsgázzanak. A jelentkezők számára felkészítő tananyagot biztosítunk. További információ Böröcz Róbert i érhető el a +36 1 371 0540 telefonszámon vagy a borocz.robert(a)balabit.hu e-mail címen. Bővebben: BCZA vizsga http://www.balabit.hu/services/tanfolyam/exam_bcza.bbq BCZE vizsga http://www.balabit.hu/services/tanfolyam/exam_bcze.bbq -- Györkő Zoltán <gyorkoz(a)balabit.hu>

1 0

SIP proxy kérdés
by Deim Agoston 24 Apr '06

24 Apr '06

hali, örömteli számomra, hogy van már SIP proxy. Ehhez kapcsolódna egy kérdésem, amihez egy diaban készített Móricka ábrát is csatoltam. A kérdés: ha a(z egyik) DMZ-ben van a SIP-es server, a kliensek pedig egy másik zónában, a LAN-ban, akkor Sip proxy lekezeli ezt? Ha jól tudom és látom, akkor most minden megfelelően kezdeményezett SIP kapcsolat lekezeléséhez létrejön egy iptables szabály. Mivel az RTP-n történő kommunikációt a kliensek már egymás között végzik, ezért ehhez kapcsolódóan kell létrehozni az iptables szabályokat is. Ezt az alapbeállításokkal meg tudja majd tenni a zorp vagy bele kell túrnom az osztályokba és sajátot kell készítenem? Ha erősebben nézem a .py-t akkor amit benne látok az openStream és closeStream-re, abban az iptables résznél nincs definiálva interface csak címek s a portok. Esetleg elég csak a permit_trp_zones-ba megadni a zónákat? (internet + LAN)? Elnézést, hogy nem fordítottam rá most több időt, nem szokásom így bedobni a kérdést, elég egy igen, nem RTFM, aztán megoldom onnatól, csak az irányt jelöljétek ki. üdv, Ago

1 0