April 2004 - zorp - lists.balabit.hu

Re: [zorp] Bad argument `50080'
by Phil Moors 15 Apr '04

15 Apr '04

Okay, I changed the entries in iptables.conf.in to use the --on-port. Running iptabes-gen exits silently and leaves an iptables.conf.new file. Running iptables-test now shows: iptables-restore v1.2.9: Unknown arg `--on-port' Error occurred at line: 15 Try `iptables-restore -h' or 'iptables-restore --help' for more information. The iptables.conf.in was taken right from the Zorp tutorial. Is the documentation in the tutorial applicable to iptables or is it ipchains based? I'm running a 2.4 kernel. Alternatively, I ran iptables -F and iptabels -X and grabbed the 2nd article from Linux Journal about Zorp. I attempted to type in the commands from listing one in the article and got these results: [root@fw1 etc]# iptables -t tproxy -P PREROUTING ACCEPT [root@fw1 etc]# iptables -t tproxy -A PREROUTING -i eth0 -j PRintra iptables v1.2.9: Couldn't load target `PRintra':/lib/iptables/libipt_PRintra.so: cannot open shared object file: No such file or directory The above looks very strange. What am I missing? Thanks, Phil // // Copyright (c) 2000-2001 BalaBit IT Ltd. // All rights reserved. // $Id: iptables.conf.in,v 1.5 2003/01/17 09:37:51 bazsi Exp $ // // Sample iptables.conf.in file, dropping _ALL_ traffic by default. You // have to change this, if you want to do something useful (otherwise // you could have cut your wire) // *tproxy :PREROUTING ACCEPT :OUTPUT ACCEPT :PRintra - :PRinter - :PRdmz - -A PREROUTING -i IFintra -j PRintra -A PREROUTING -i IFinter -j PRinter -A PREROUTING -i IFdmz -j PRdmz // PRintra chain -A PRintra -p tcp --dport 80 -j TPROXY --on-port 50080 -A PRintra -p tcp --dport 443 -j TPROXY --on-port 50443 -A PRintra -p tcp --dport 21 -j TPROXY --on-port 50021 //PRinter chain -A PRinter -p tcp --dport 80 -j TPROXY --on-port 50080 // PRdmz chain // no services permitted COMMIT *filter :INPUT DENY :FORWARD DENY :OUTPUT ACCEPT :noise - :spoof - :spoofdrop DROP :LOintra :LOinter :LOdmz -A INPUT -j noise -A INPUT -j spoof // permit all traffic initiated by transparent proxies -A INPUT -m tproxy -j ACCEPT // // permit all TCP traffic inititated by local processes, or allowed by the // rules below. We don't trust the state match for UDP traffic, they will be // handled by individual rules below. // -A INPUT -p tcp -m state --state ESTABLISHED,RELATED -j ACCEPT // permit all loopback traffic -A INPUT -i lo -j ACCEPT -A INPUT -i IFintra -j LOintra -A INPUT -i IFinter -j LOinter -A INPUT -i IFdmz -j LOdmz -A INPUT -j DROP -A FORWARD -j LOG --log-prefix "FORWARD DROP: " -A FORWARD -j DROP // LOintra -A LOintra -p dp --dport 53 -j ACCEPT -A LOintra -p udp --dport 123 -j ACCEPT -A LOintra -p tcp --syn --dport 25 -j ACCEPT -A LOintra -j LOG --log-prefix "LOintra DROP: " -A LOIntra -j DROP // LOinter // permit DNS replies, bind is configured to send out packets from this // port. We could also use the state match in our INPUT chain. -A LOinter -p udp -s DNS_SERVERS --dport 53000 -j ACCEPT -A LOinter -p udp -s NTP_SERVERS --dport 123 -j ACCEPT -A LOinter -p tcp --syn --dport 25 -j ACCEPT -A LOinter -j LOG --log-prefix "LOinter DROP: " -A LOinter -j DROP // // noise chain. Should drop all packets which need not be logged, // otherwise it should return to the main ruleset. // -A noise -p udp --dport 137:139 -j DROP -A noise -j RETURN // // spoof chain. Should drop all packets with spoofed source address // otherwise it should return to the main ruleset. // -A spoof -i lo -j RETURN -A spoof ! -i lo -s 127.0.0.0/8 -j spoofdrop -A spoof -i IFintra ! -s NETintra -j spoofdrop -A spoof ! -i IFintra -s NETintra -j spoofdrop -A spoof -i IFdmz ! -s NETdmz -j spoofdrop -A spoof ! -i IFdmz -s NETdmz -j spoofdrop -A spoof -j RETURN // -A spoofdrop -j LOG --log-prefix "Spoofed packet: " -A spoofdrop -j DROP COMMIT >>> illes(a)c3.hu 04/13/04 03:12PM >>> On Tue, Apr 13, 2004 at 02:35:51PM -0400, Phil Moors wrote: > Zorp GPL > > Is this from the iptables user space utility? > > I used the FC1 iptables-1.2.9-1.0src.rpm and added the patch to the spec and SOURCES > and rebuilt the package. There were no errors on applying the patch during the build. > > I get this when starting iptables: > > Applying iptables firewall rules: Bad argument `50080' > Error occurred at line: 15 > Try `iptables-restore -h' or 'iptables-restore --help' for more information. > [FAILED] > > Line 15 in iptables.conf.new: > -A PRintra -p tcp --dport 80 -j TPROXY 50080 You should write -A PRintra -p tcp --dport 80 -j TPROXY --on-port 50080 > Also, after running zorpctl start intra, ps aux shows: > > root 8373 0.0 1.0 4536 1024 pts/0 S 14:31 0:00 /bin/bash /usr/local/sbin/zorpctl start intra > root 8374 4.7 4.4 139296 4148 pts/0 S 14:31 0:00 /usr/local/lib/zorp/zorp --as intra -v3 -p /usr/local/etc/zorp/policy > > Does the above look right for starting one listener (two entries)? The best way is to look at logs for any errors! (Look at your syslog configuration!) Marton -- Key fingerprint = 5CB4 3F40 9F39 9B70 8179 D8B6 7DEA D9C4 D1D8 8C0A _______________________________________________ zorp mailing list zorp(a)lists.balabit.hu http://lists.balabit.hu/mailman/listinfo/zorp The information contained in this communication is confidential and privileged proprietary information intended only for the individual or entity to whom it is addressed. Any unauthorized use, distribution, copying or disclosure of this communication is strictly prohibited. If you have received this communication in error; please contact the sender immediately. If you believe this communication is inappropriate or offensive, please contact the sender's human resources department. It is our policy that e-mails are intended for and should be used for business purposes only.

2 1

Clustering Zorp with LVS
by Sheldon Hearn 14 Apr '04

14 Apr '04

Hi folks, I finally have a working lab setup that uses LVS-DR to load balance across two zorp proxies. The lab configuration is inspired by the load balanced configuration presented on page 10 of the Zorp Professional 2 Product Description at http://www.balabit.com/dl/zorp2.pdf, and a diagram of my implementation is available at http://starjuice.net/zorp/lab_implementation.png [1]. I'm using Linux LVS-DR with fwmarks for both front and back load balancers; birdy (the front load balancer) uses the SH (source hash) balancing algorithm, while wormy (the back load balancer) uses DH (destination hash). This works okay, but the algorithm doesn't balance very well, and doesn't cope well[2] with node addition and removal of nodes (realservers in LVS jargon). Ideally, what the back load balancer for a Zorp cluster needs to do is this: 1) When a SYN comes in from a Zorp host, create a new connection table entry, including the Layer 2 (Ethernet) address of the packet in the entry. 2) When a packet comes back from the servers and is associated with a connection table entry based on Layer 3 and 4 features, route the packet via the Layer 2 address stored in the entry. I've contacted 3 vendors and an open source group looking for a solution like this. Here are the responses: 1) Cisco say their 650x with Content Switching Module support transparent proxy firewalls, and a friend of mine at Cisco confirms this. 2) Enterasys engineering have confirmed that they have no device that can do this. 3) Alcatel have confirmed that they have no device that can do this. 4) The folks on the LVS mailing list can't think of anything better than the SH/DH approach. Now a Cisco 650x w/ CSM costs more than USD 70,000. That's a lot of money to spend on a load balancer for 4 Zorp boxes! So my question is, has anyone solved the Zorp clustering problem in an affordable way, or is the Product Description just describing a theoretical possibility for marketing purposes? Ciao, Sheldon. [1] Beware of [1] In a simple test of 200 packets with randomly generated IP addresses, zorp01 got 44% and zorp02 got 56%.

2 1

Bad argument `50080'
by Phil Moors 13 Apr '04

13 Apr '04

Zorp GPL Is this from the iptables user space utility? I used the FC1 iptables-1.2.9-1.0src.rpm and added the patch to the spec and SOURCES and rebuilt the package. There were no errors on applying the patch during the build. I get this when starting iptables: Applying iptables firewall rules: Bad argument `50080' Error occurred at line: 15 Try `iptables-restore -h' or 'iptables-restore --help' for more information. [FAILED] Line 15 in iptables.conf.new: -A PRintra -p tcp --dport 80 -j TPROXY 50080 I tried starting the zorp listeners before running iptables, but it did not make any difference. Any ideas on where I should look? Also, after running zorpctl start intra, ps aux shows: root 8373 0.0 1.0 4536 1024 pts/0 S 14:31 0:00 /bin/bash /usr/local/sbin/zorpctl start intra root 8374 4.7 4.4 139296 4148 pts/0 S 14:31 0:00 /usr/local/lib/zorp/zorp --as intra -v3 -p /usr/local/etc/zorp/policy Does the above look right for starting one listener (two entries)? Thanks, Phil lsmod shows: iptable_tproxy 13708 0 (autoclean) (unused) iptable_nat 21944 0 (autoclean) [iptable_tproxy] ip_conntrack 29288 1 (autoclean) [iptable_tproxy iptable_nat] ip_tables 15264 4 [iptable_tproxy iptable_nat] parport_pc 18756 1 (autoclean) lp 8612 0 (autoclean) parport 37024 1 (autoclean) [parport_pc lp] autofs 12084 0 (autoclean) (unused) 3c59x 30672 3 dummy0 1636 1 The information contained in this communication is confidential and privileged proprietary information intended only for the individual or entity to whom it is addressed. Any unauthorized use, distribution, copying or disclosure of this communication is strictly prohibited. If you have received this communication in error; please contact the sender immediately. If you believe this communication is inappropriate or offensive, please contact the sender's human resources department. It is our policy that e-mails are intended for and should be used for business purposes only.

2 1

Zorp and TPROXY can't bind or loops infinitely
by Sheldon Hearn 13 Apr '04

13 Apr '04

Hi folks, Just before I finish pulling out all my hair in frustration, I thought I'd ask for help here. :-) Basically, I think I've done everything correctly, but can't get zorp to establish the outbound connection to the real server. So obviously I haven't done everything correctly. :-) Client: 172.16.100.2 Server: 10.0.0.101 Zorp01: Linux 2.6.3 (Gentoo-r1 w/ Balabit TPROXY patch) zorp-2.0.8 + libzorpll-2.0.26.24 OR zorp-2.1.5.5 + libzorpll-2.1.12.2-1 eth0 1.2.3.4 <public address obscured> 192.168.0.1 eth1 192.168.1.1 dummy0 192.168.4.1 Routing is correct: Destination Gateway Genmask Iface 1.2.3.4 0.0.0.0 255.255.255.240 eth0 172.16.100.0 192.168.0.254 255.255.255.0 eth0 10.0.0.0 192.168.1.254 255.255.255.0 eth1 192.168.1.0 0.0.0.0 255.255.255.0 eth1 192.168.0.0 0.0.0.0 255.255.255.0 eth0 ... The client routes to the server through the zorp01 box via 192.168.0.154, which is an LVS-DR/fwmarks load-balancer and which delivers the HTTP traffic to 192.168.0.1's MAC address (eth0), but still with 10.0.0.101 as the destination address. Similarly, 192.168.1.154 will gateway traffic between the zorp box and the server, although I haven't bothered to set it up, since zorp still isn't pushing traffic at it (and because I'm still not sure how I'm gonna get the reverse load balancing working, assuming paired SH/DH doesn't work). Here's the tproxy iptable: *tproxy :PREROUTING ACCEPT :OUTPUT ACCEPT :PRinter - -A PREROUTING -i eth0 -j PRinter -A PRinter -p tcp --dport 80 -j LOG \ --log-prefix "NF: PRinter TPROXY 50080: " // Using --on-ip didn't change results -A PRinter -p tcp --dport 80 -j TPROXY --on-port 50080 COMMIT Here's instances.conf: zorp_http --verbose=5 --policy /etc/zorp/policy.py --autobind-ip 192.168.4.1 Here's the policy.py: ----------- Zorp.firewall_name = 'zorp@zorp01' InetZone("internet", "0.0.0.0/0", inbound_services=["intra_http"], outbound_services=["intra_http"]) # We get different results with and without snat=...; see description # to follow. def zorp_http(): Service("intra_http", HttpProxy, snat=ForgeClientSourceNAT()) Listener(SockAddrInet("0.0.0.0", 50080), "intra_http") ----------- With "snat=ForgeClientSourceNAT()" shown above, we get bind() failed; error='Cannot assign requested address' as shown in this log extract: ----------- 00:05:08 zorp_http[14429]: (zorp@zorp01/intra_http): Starting service; name='intra_http' 00:05:08 zorp_http[14429]: (zorp@zorp01/intra_http:0): Starting proxy instance; client_fd='15', client_address='AF_INET(172.16.100.2:32929)', client_zone='Zone(internet, 0.0.0.0/0)', client_local='AF_INET(1.2.3.4:50080)' 00:05:08 zorp_http[14429]: (zorp@zorp01/intra_http:0/http): Proxy starting; class='HttpProxy', module='http' 00:05:08 zorp_http[14429]: (zorp_http@zorp@zorp01/nosession): accept count; accepts='1' 00:21:40 zorp01 zorp_http[14848]: (zorp@zorp01/intra_http:0/http): bind() failed; error='Cannot assign requested address' 00:21:40 zorp01 zorp_http[14848]: (zorp@zorp01/intra_http:0/http): Server connection failure; server_address='AF_INET(1.2.3.4:50080)', server_zone='Zone(internet, 0.0.0.0/0)', server_local='None' 00:21:40 zorp01 zorp_http[14848]: (zorp@zorp01/intra_http:0/http): Proxy ending; class='HttpProxy', module='http' 00:21:40 zorp01 zorp_http[14848]: (zorp@zorp01/intra_http:0): Ending proxy instance; 00:21:40 zorp01 zorp_http[14848]: (zorp@zorp01/intra_http:0/http/client): accounting info; type='stream', duration='2', sent='840', received='43' ----------- Without snat=ForgeClientSourceNAT(), zorp connects to itself, causing the new instance to connect to itself, etc. until we run out of threads. Tcpdump on the loopback interface confirms that zorp is connecting to itself (but see NetFilter log extract below): ----------- 23:43:40 zorp01 zorp_http[13705]: (zorp@zorp01/intra_http): Starting service; name='intra_http' 23:43:40 zorp01 zorp_http[13705]: (zorp@zorp01/intra_http:2): Starting proxy instance; client_fd='15', client_address='AF_INET(172.16.100.2:32926)', client_zone='Zone(internet, 0.0.0.0/0)', client_local='AF_INET(1.2.3.4:50080)' 23:43:40 zorp01 zorp_http[13705]: (zorp@zorp01/intra_http:2/http): Proxy starting; class='HttpProxy', module='http' 23:43:40 zorp01 zorp_http[13705]: (zorp_http@zorp@zorp01/nosession): accept count; accepts='1' 23:43:49 zorp01 zorp_http[13724]: (zorp@zorp01/intra_http:2/http): Server connection established; server_fd='16', server_address='AF_INET(1.2.3.4:50080)', server_zone='Zone(internet, 0.0.0.0/0)', server_local='AF_INET(1.2.3.4:34216)' 23:43:49 zorp01 zorp_http[13705]: (zorp@zorp01/intra_http): Starting service; name='intra_http' 23:43:49 zorp01 zorp_http[13705]: (zorp@zorp01/intra_http:3): Starting proxy instance; client_fd='17', client_address='AF_INET(1.2.3.4:34216)', client_zone='Zone(internet, 0.0.0.0/0)', client_local='AF_INET(1.2.3.4:50080)' 23:43:49 zorp01 zorp_http[13705]: (zorp@zorp01/intra_http:3/http): Proxy starting; class='HttpProxy', module='http' 23:43:49 zorp01 zorp_http[13705]: (zorp_http@zorp@zorp01/nosession): accept count; accepts='1' 23:43:49 zorp01 zorp_http[13705]: (zorp@zorp01/intra_http): Starting service; name='intra_http' 23:43:49 zorp01 zorp_http[13725]: (zorp@zorp01/intra_http:3/http): Server connection established; server_fd='18', server_address='AF_INET(1.2.3.4:50080)', server_zone='Zone(internet, 0.0.0.0/0)', server_local='AF_INET(1.2.3.4:34217)' 23:43:49 zorp01 zorp_http[13705]: (zorp@zorp01/intra_http:4): Starting proxy instance; client_fd='19', client_address='AF_INET(1.2.3.4:34217)', client_zone='Zone(internet, 0.0.0.0/0)', client_local='AF_INET(1.2.3.4:50080)' 23:43:49 zorp01 zorp_http[13705]: (zorp@zorp01/intra_http:4/http): Proxy starting; class='HttpProxy', module='http' 23:43:49 zorp01 zorp_http[13705]: (zorp_http@zorp@zorp01/nosession): accept count; accepts='1' ... 23:43:49 zorp01 zorp_http[13821]: (zorp@zorp01/intra_http:99/http): Server connection established; server_fd='210', server_address='AF_INET(1.2.3.4:50080)', server_zone='Zone(internet, 0.0.0.0/0)', server_local='AF_INET(1.2.3.4:34313)' 23:43:49 zorp01 zorp_http[13705]: (zorp@zorp01/intra_http:100): Starting proxy instance; client_fd='211', client_address='AF_INET(1.2.3.4:34313)', client_zone='Zone(internet, 0.0.0.0/0)', client_local='AF_INET(1.2.3.4:50080)' 23:43:49 zorp01 zorp_http[13705]: (zorp@zorp01/intra_http:100/http): Proxy starting; class='HttpProxy', module='http' 23:43:49 zorp01 zorp_http[13705]: (zorp_http@zorp@zorp01/nosession): Too many running threads, waiting for one to become free; num_threads='100', max_threads='100' 23:43:49 zorp01 zorp_http[13705]: (zorp_http@zorp@zorp01/nosession): accept count; accepts='1' ----------- The NetFilter logs show zorp connecting to the local host, but note that that this infinite self-connection problem is not caused by the iptables rules (remember we only jump to TPROXY for traffic inbound on eth0), because then we'd see a lot more 'PRinter TPROXY 50080' entries: ----------- 23:43:40 zorp01 NF: PRinter TPROXY 50080: IN=eth0 OUT= MAC=00:0c:6e:d2:b0:6d:00:0e:a6:2f:df:76:08:00 SRC=172.16.100.2 DST=10.0.0.101 LEN=60 TOS=0x10 PREC=0x00 TTL=64 ID=16898 DF PROTO=TCP SPT=32926 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0 23:43:40 zorp01 NF: INPUT tproxy: IN=eth0 OUT= MAC=00:0c:6e:d2:b0:6d:00:0e:a6:2f:df:76:08:00 SRC=172.16.100.2 DST=1.2.3.4 LEN=60 TOS=0x10 PREC=0x00 TTL=64 ID=16898 DF PROTO=TCP SPT=32926 DPT=50080 WINDOW=5840 RES=0x00 SYN URGP=0 23:43:40 zorp01 NF: INPUT tproxy: IN=eth0 OUT= MAC=00:0c:6e:d2:b0:6d:00:0e:a6:2f:df:76:08:00 SRC=172.16.100.2 DST=1.2.3.4 LEN=52 TOS=0x10 PREC=0x00 TTL=64 ID=16899 DF PROTO=TCP SPT=32926 DPT=50080 WINDOW=5840 RES=0x00 ACK URGP=0 23:43:49 zorp01 NF: INPUT tproxy: IN=eth0 OUT= MAC=00:0c:6e:d2:b0:6d:00:0e:a6:2f:df:76:08:00 SRC=172.16.100.2 DST=1.2.3.4 LEN=54 TOS=0x10 PREC=0x00 TTL=64 ID=16902 DF PROTO=TCP SPT=32926 DPT=50080 WINDOW=5840 RES=0x00 ACK PSH URGP=0 ----------- It took us a while to get LVS-DR/fwmarks to route the packets to the Zorp box correctly, and when we got it working I thought the hard work was over. But now I'm completely stuck on the Zorp setup. I can't figure out why Zorp is behaving this way, but I'm pretty sure it must be my fault. Any help would be very much appreciated. Thanks, Sheldon.

2 2

compiling zorp
by Irjê - Administrador 08 Apr '04

08 Apr '04

Regards, I´m compiling a zorp package, but it´s returning a error: configure: error: python extension class required I can not compiling python with extensioclass, can anybody help me? Irjê Schmitz Administrador de Redes - Área de Tecnologia - Fone: (55) 3512 6685 Viabrazil Telecomunicações Ltda - Av. Santa Cruz, 1042 - Santa Rosa - RS --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com) Version: 6.0.650 / Virus Database: 416 - Release Date: 4/4/2004

2 1

Compile problems with Zorp 2.0.8 GPL
by Börje Wallin 05 Apr '04

05 Apr '04

I have problems compiling Zorp. The configure part is performed without problems, but the make part is broken. I am compiling on a Fedora core 2 box. Below is the output from the make command. I am using gcc 3.3.2 and python 2.3. The ExtensionClass 1.2.1 and the libzorpll 2.0.26.24 compiled, and installed without problems. make[3]: Entering directory `/home/reino/fedoraC2/BUILD/zorp-2.0.8/lib' /bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/home/reino/fedoraC2/BUILD/zorp-2.0.8/lib -I/home/reino/fedoraC2/BUILD/zorp-2.0.8 /usr/include/python2.3 -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -D_GNU_SOURCE -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -O2 -g -pipe -march=i686 -O2 -Wall -W -g -D_GNU_SOURCE -c proxy.c gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/home/reino/fedoraC2/BUILD/zorp-2.0.8/lib -I/home/reino/fedoraC2/BUILD/zorp-2.0.8 /usr/include/python2.3 -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -D_GNU_SOURCE -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -O2 -g -pipe -march=i686 -O2 -Wall -W -g -D_GNU_SOURCE -c proxy.c -fPIC -DPIC -o proxy.lo gcc: cannot specify -o with -c or -S and multiple compilations make[3]: *** [proxy.lo] Error 1 make[3]: Leaving directory `/home/reino/fedoraC2/BUILD/zorp-2.0.8/lib' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/reino/fedoraC2/BUILD/zorp-2.0.8/lib' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/reino/fedoraC2/BUILD/zorp-2.0.8' make: *** [all-recursive-am] Error 2 _________________________________________________________________ Lättare att hitta drömresan med MSN Resor http://www.msn.se/resor/

2 1

tproxy source IP address question
by Gunjan 05 Apr '04

05 Apr '04

Hi, I was looking for a transparent proxy which does not change the source IP address when it tries to establish connection with the actual destination for the client. I tried squid, but it changes the source IP address to the proxy server IP address. I was going thru the tproxy patch readme file, and it says that it can establish connection with "foreign IP address" , does that mean that it does not change the source IP address even though it breaks the connection? Can someone confirm this? Thanks, Gunjan __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/

2 1