- tproxy - lists.balabit.hu

Re: [tproxy] netcat for tproxy (and additional noob questions)
by Adrian Chadd 07 Jul '09

07 Jul '09

2009/7/7 John Lauro <john.lauro(a)covenanteyes.com>: >> Reusing the original port is usually a bad idea. A notable example of >> things breaking is Netfilter connection tracking, which gets confused >> if >> you reuse the exact same endpoints for a different connection. > > Technically they are not the exact same if you include the interface. If it > doesn't consider the interface then they would appear the same. Well, you don't always have >1 interface. Consider WCCPv2 "cache on a stick" with only one upstream interface to the router redirecting it both the client and server traffic. Adrian

1 0

Re: [tproxy] netcat for tproxy (and additional noob questions)
by KOVACS Krisztian 07 Jul '09

07 Jul '09

Hi, On Sun, Jul 05, 2009 at 03:16:47PM -0400, John Lauro wrote: > > * create listen socket > > * setsockopt to make it transparent > > * bind() to 0.0.0.0, relevant port that you've redirected traffic to > > * listen() as usual > > > > Then, you accept() as usual, use getsockname() to determine the > > original destination. Then for the outbound socket: > > Getsockname is returning back the source/client IP & port instead of the > original destination. I will need that, but that's only half... I'm > possibly just not passing the correct structure(?) Switching a couple of > things around, instead it returns back the generic 0.0.0.0 address I bound > as, which is not any better. It might not help that I am tested it from a > slightly modified netcat instead of a more simple test and I am probably > overlooking something simple. Perhaps next I'll try a more simple code test > from scratch instead of patching netcat. I have a very simplistic patch for netcat here: http://home.sch.bme.hu/~piglet/netfilter/tproxy/netcat-ip_transparent-suppo… May or may not work, since it was a long time ago I wrote that. In theory, getsockname() for the fd returned by accept() should be the original destination address, while getpeername() should return the client (source) address. For UDP, you should be able to get the original destination address via an ancillary message returned by recvmsg() (You can find the git commit introducing that feature here: http://tinyurl.com/n4yjlt) > > * create socket > > * setsockopt to make it transparent > > * bind() to relevant IP (and port, or leave it 0 to let the stack > > choose a port IIRC) > Should I be able to reuse the original source port, or will that fail/cause > problems as it would already be in the connection table (except with > local/foreign reversed)? Reusing the original port is usually a bad idea. A notable example of things breaking is Netfilter connection tracking, which gets confused if you reuse the exact same endpoints for a different connection. -- KOVACS Krisztian

3 3

Re: [tproxy] netcat for tproxy (and additional noob questions)
by Adrian Chadd 07 Jul '09

07 Jul '09

2009/7/5 John Lauro <john.lauro(a)covenanteyes.com>: > > Most of the examples I found are for more specific cases, such as for use > with squid on just port 80. I am not certain I understand fully the > interaction between the rules for iptables and the interaction with tproxy. > Is there someplace this is all documented, along with all the details from a > programmer perspective such as the use of setsockopt? (I think I just need > updated man pages?) Ive been looking to put some better documentation together for what Lusca does for TPROXY4 (I'm guessing you're talking about that and not TPROXY2.) In any case, the process is somewhat like this: * iptables/routing table setup - http://wiki.squid-cache.org/Features/Tproxy4 * create listen socket * setsockopt to make it transparent * bind() to 0.0.0.0, relevant port that you've redirected traffic to * listen() as usual Then, you accept() as usual, use getsockname() to determine the original destination. Then for the outbound socket: * create socket * setsockopt to make it transparent * bind() to relevant IP (and port, or leave it 0 to let the stack choose a port IIRC) * connect() as usual I haven't yet really looked into the TPROXY4 kernel implementation to know precisely what is going on. I can't find some clear, concise documentation either explaining the "how" or "why" behind the iptables rules and why packets need to be punted via the loopback interface. HTH, Adrian

3 2

netcat for tproxy (and additional noob questions)
by John Lauro 05 Jul '09

05 Jul '09

Hello, I am new to the list, and couldn't find this discussed in the archives: Does anyone have a working version of nc/netcat that supports tproxy? There appears to be several implementations of netcat, but only found patches for a version that appears not to be available any longer. I made a patch to netcat, but it's not working and so I am not certain if it's a problem with my patch or my ip tables setup (probably the later). Specific links to versions of netcat and patch for it would be appreciated. I do have kernel 2.6.29.3 and latest (or at least not more than a couple months old) iptables. A quick sanity check that the following is possible: (99.9% sure based on other comments on the list) 1. Want to have a box with two NICs between the internet and local machines, basically a router. (Although a bridge might be even better). 2. Have that machine intercept all connections from local machines -> internet with tproxy on all ports, and create matching connections using src ip of original machines -> internet. (Interception of connections the other way, internet -> local machines is not required, but will not hurt, but obviously they have to be able to at least forward through ok). 3. Do some custom stuff on the streams mainly for monitoring, and also a little manipulation (mainly http redirects). Assuming the above is possible, will it be possible to keep the same source port number on the outgoing connections? (Which would mean two connections with the same src/dst pairs, but communicating on different interfaces). What should the ip tables rules look like for this to function? Most of the examples I found are for more specific cases, such as for use with squid on just port 80. I am not certain I understand fully the interaction between the rules for iptables and the interaction with tproxy. Is there someplace this is all documented, along with all the details from a programmer perspective such as the use of setsockopt? (I think I just need updated man pages?) Thanks in advance for any help/advice.

1 0

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