June 2009 - tproxy - lists.balabit.hu

Backport to 2.6.24
by Harry Mason 13 Jul '09

13 Jul '09

Has anyone backported TPROXY to 2.6.24, the kernel used in Ubuntu Hardy? Any reason why it'd be difficult or impossible? -- Harry Mason Developer SmoothWall Limited 1 John Charles Way Leeds LS12 6QA United Kingdom 1 800 959 3760 (USA, Canada and North America) 0870 1 999 500 (United Kingdom) +44 870 1 999 500 (all other countries) SmoothWall is registered in England: 4298247 This email and any attachments transmitted with it are confidential to the intended recipient(s) and may not be communicated to any other person or published by any means without the permission of SmoothWall Limited. Any opinions stated in this message are solely those of the author. See: http://smoothwall.net/company/email.php for the full text of this notice.

3 2

I need help with tproxy
by Welisson 30 Jun '09

30 Jun '09

I would like of a help of yours, in the following situations. I need redirect all request of port 80, to my proxy server with tproxy active, however it will not be gateway of my network. I am using Debian 5 Etch, kernel 2.6.19 in the two servers and iptables 1.3.7. However i did the following, i redirected of gateway to my proxy server using the command below; iptables -t tproxy -A PREROUTING -s 189.111.xxx.2 -p TCP --dport 80 -j TPROXY --on-ip 189.4xx.xxx.10 --on-port 3129 I got the error below in cache.log 2009/06/29 14:38:58| tproxy ip=189.111.xxx.2,0x2a07fbd,port=0 ERROR ASSIGN Then i did a DNAT rule, e.g below iptables -t nat -A PREROUTING -s 189.111.xxx.2 -p TCP --dport 80 -j DNAT --to-destination 189.4xx.xxx.10 and in proxy server the following command iptables -t tproxy -A PREROUTING -s 189.111.xxx.2 -p TCP --dport 80 -j TPROXY --on-port 3129 The request finised giving timeout. I would like know, if possible used tproxy in this situation. station <---------->gateway<---------->InterNet | redirected to proxy using iptables Proxy/Tproxy Regards

3 4

Squid 3.1 + Tproxy 4.1 in Bridge Mode
by renato＠univem.edu.br 15 Jun '09

15 Jun '09

Hello! First of all, thanks for your effort and great work in providing the Open Source community with this software. I've beeing using TPROXY with Squid 3.1 and 2.6 kernel for sometime in Layer-3/routed firewalls without problems at all. Today, I'm trying to use it in a Bridged firewall, with kernel 2.6.30 (patches with L7-filter only), iptables-1.4.3.2 and squid-3.1.0.8-20090610. The Linux distribution is Slackware 12.2 with gcc 4.3.3 and libcap 2.14. In the kernel, I have configured: CONFIG_SECURITY_FILE_CAPABILITIES CONFIG_NETFILTER_TPROXY CONFIG_NETFILTER_XT_TARGET_TPROXY CONFIG_NETFILTER_XT_MATCH_SOCKET NF_CONNTRACK My bridge interface (br0) is eth0 (Internet) + eth1 (Intranet) and the br0 virtual interface have a routed IP. The bridge is located between the user's switch and the Internet router. SQUID was compiled with these options: Squid Cache: Version 3.1.0.8-20090610 configure options: '--enable-linux-netfilter' '--enable-http-violations' '--enable-async-io=8' '--enable-useragent-log' '--enable-cache-digests' '--enable-follow-x-forwarded-for' '--enable-storeio=aufs' '--enable-removal-policies=heap,lru' '--with-maxfd=16384' '--enable-poll' '--with-filedescriptors=16384' '--disable-ident-lookups' '--enable-zph-qos' '--enable-truncate' '--with-pthreads' '--with-large-files' '--enable-ssl' '--with-openssl=/usr/include/openssl/' '--disable-htcp' '--enable-inline' '--enable-delay-pools' '--enable-underscores' '--enable-icap-client' '--with-default-user=squid' '--enable-ltdl-convenience' 'CFLAGS=-march=core2 -O3 -pipe -fomit-frame-pointer -DNUMTHREADS=60 -funroll-loops -mfpmath=sse -ffast-math -fno-exceptions' 'CXXFLAGS=' --with-squid=/home/sources/SQUID/squid-3.1.0.8-20090610 And in squid.conf, I have the important: http_port 3128 http_port 3129 tproxy I'm using the same rules as I use in the other server: iptables -t mangle -N DIVERT iptables -t mangle -A DIVERT -j MARK --set-mark 1 iptables -t mangle -A DIVERT -j ACCEPT iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT iptables -t mangle -A PREROUTING -p tcp --dport 80 -j TPROXY --tproxy-mark 0x1/0x1 --on-port 3129 ip rule add fwmark 1 lookup 100 ip route add local 0.0.0.0/0 dev lo table 100 echo 1 > /proc/sys/net/ipv4/ip_forward The users can surf the Internet, but they are not redirected to the proxy. The same configuration works in other 3 servers, but routed. I did a lot of research in google and Tproxy related lists, and saw that other friends are having the same problem, but I could not read any post with a solution. I tried a lot of combinations with ebtables, physdev iptables modules and etc, but if you could point me the right direction, I would apreciate very much! Do I have to go back to the tproxy2 when using Bridge mode? Thank you very much for your time and attention! If I forgot any important information, please let me know! Thanks!!

3 4

Anyone have done successful implementation on Centos
by Asif Bakali 15 Jun '09

15 Jun '09

Hi there anyone have done successful implementation on Centos 5.2 i am trying to patch with this document its not working for me http://wiki.squid-cache.org/ConfigExamples/TPROXYPatchingCentOS or any one have alternate step by step guide on any distro

1 0

tproxy side effect - expansion of worm attack
by elyasaf 11 Jun '09

11 Jun '09

tproxy side effect - expansion of worms attacks: We have identified a serious "social" side effect in tproxy that results significant performances lose. The scenario is as follows: We have proxy machines that each one serve about ten thousand internet users with unique IP. Since we are listening beside the outgoing traffic also to the ingoing traffic on all the ports: ${iptables} -t mangle -A ROUTINE -p tcp -j TPROXY --on-port 3144 --on-ip 0.0.0.0 --tproxy-mark 0x1/0xffffffff Now each worm that tries to access the computers behind our network, thinks that the remote port is open and our customers are vulnerable, will try more attacks and as result increase significantly the load of the servers (in some hours more than 50% of all the new connections are worms one!) Technically (without considering some flood protections on the iptables, that result sometimes unexpected behavior) we cannot see how to avoid that since we accept the connection from the internet, in case there is user server behind it and in case that not because we can't know which destination ip and port is accessed before accepting the new connection. BTW, similar kind of problems arise on outgoing connections where some applications that run on the customers desktops get confused where the connection to the remote server succeeds but no real server really listening. It's looks like that we have conceptual problem here, possible workaround can be to "know" somehow the remote address details before accepting the connection. Can someone please say if this kind of thing exists and if not is there chance to implement that thing from the perspective of the tproxy patch. br, elyasaf Do you think that there should be an option to implement the accept fucntion without SYN-ACK? And only after a SYN-ACK is received from the server side send the SYN-ACK to the client?

2 3

Reg:Guide and help me for T-Proxy
by Naveen Kumar 11 Jun '09

11 Jun '09

Hi , I need to install TProxy server on my pc but i tried lots of steps to patch the files but it wont installed.so please help me to provide some installation guide and patch files to install the TProxy as well successfull. Thank u... Hope u great week end. Regards, Naveen Own a website.Get an unlimited package.Pay next to nothing.*Go to http://in.business.yahoo.com/

2 1

Is tproxy a real transparent proxy?
by mtpr 08 Jun '09

08 Jun '09

I am testing tproxy with a vmware Centos-5.3 virtual server. I installed squid-3.1, iptables-1.4.3 and kernel-2.6.28.3. Everything seems to be working, unless one... There is a proxy behaviour I thought it would be expectable, but I found it doesn't work the way I thought. Here is the example: If I create a cgi-bin script in a apache webserver that prints the client ip address like this one: #!/bin/env python # coding: utf-8 import os print 'Content-Type: text/plain' print print os.environ['REMOTE_ADDR'] I thought that, in a real transparent proxy, it would give me the original client ip address of the browser computer. But no! Like the old transparent proxy way (not tproxy), it prints the ip address of the proxy server. If I want the original ip address, I need to read the environment variable HTTP_X_FORWARDED_FOR. It doesn't seem to be a "real" transparent proxy. Is this the expectable behaviour, or could be something wrong with the way I setup my tproxy? mtpr

3 4