[tproxy] tproxy routing issue within processes in the same machine
mctiew at yahoo.com
Wed Sep 19 07:06:31 CEST 2012
--- On Tue, 9/18/12, Karol Piłat <cubix at vitresoft.com> wrote:
> From: Karol Piłat <cubix at vitresoft.com>
> Subject: Re: [tproxy] tproxy routing issue within processes in the same machine
> To: "Balazs Scheidler" <bazsi at balabit.hu>
> Cc: "Ming-Ching Tiew" <mctiew at yahoo.com>, "tproxy at lists.balabit.hu" <tproxy at lists.balabit.hu>
> Date: Tuesday, September 18, 2012, 6:11 PM
> AFAIK it is possible.
> 1. You have to bind new (spoofed) connection's port in
> certain range (e.g. 5000 - 10000, not ephemeral port
> 2. Setup rule to forward all outgoing TCP packets to ports
> in that range to localhost
> 3. Make connections to physical, not loopback address.
> I have it running on production for about 2 months now.
> Iptables rules and routes:
> ip rule add fwmark 1 lookup 100
> ip route add local 0.0.0.0/0 dev lo table 100
> iptables -t mangle -N DIVERT
> iptables -t mangle -A PREROUTING -p tcp -m
> socket -j DIVERT
> iptables -t mangle -A DIVERT -j MARK
> --set-mark 1
> iptables -t mangle -A DIVERT -j ACCEPT
> iptables -t mangle -A OUTPUT -p tcp --dport
> 5000:9999 -j MARK --set-mark 1
> Example python code to create spoofed connection:
> s = socket.socket(socket.AF_INET,
> s.setsockopt(socket.SOL_IP, 19, 1) #
> IP_TRANSPARENT, not available in python's stdlib
> s.bind(('220.127.116.11', 5001))
> s.connect(('192.168.1.9', 1234)) # connection
> always to physical interface address!
> I do free port management by myself, but you can do bind()
> in a loop.
If the understand correctly, the only thing you added is the iptables -t mangle -A OUTPUT -p tcp --dport .....-j MARK --set-mark 1
I did exactly as what you did, however it did not seem to work for my test case. For my case, the server is a http server, so I only need to setmark on the listening http port, ie
iptables -t mangle -A OUTPUT -p tcp --dport 9090 -j MARK --set-mark 1
The outgoing packets from the spoofing client (program) seem to get appear in the lo interface, however, the server reply did not get back to the spoofing client, instead the packet went out to the external interface ( confirmed using tcpdump ).
More information about the tproxy