Re: [PATCH] ipt_REDIRECT: only change dest-ip if not local ip

[Bas van Sisseren <bas@quarantainenet.nl>]

Hello Pascal,

On 16/07/10 14:42, Pascal Hambourg wrote:
> Bas van Sisseren a écrit :
>>
>> When redirecting, the destination address is replaced by the first
>> ip-address on the receiving interface.
> 
> As described in the iptables manpage.
> 
>> If the packet originally was sent to the second ip-address (or third,
>> fourth, etc..), this patch doesn't change the destination ip.
> 
> Is this patch in reaction to the recent thread "iptables not forwarding
> port 443" in the netfilter user list from someone who stumbled into this
> issue ?

I didn't read that thread. Although this patch would probably solve that issue.


> My thoughts :
> 1) The iptables manpage would need to be updated accordingly.
> 
> 2) I wonder whether it is really useful. The purpose of REDIRECT is to
> make sure a packet is redirected to the local machine itself without the
> need to care about the machine's address (just as MASQUERADE). If you
> don't want to change the destination address or need finer control over
> it, I believe DNAT can be used instead. Can you provide a use case ?

It's a honeypot system with advanced routing and a lot of ip-addresses. The
honeypot is running as non-root, which complicates usage of ports < 1024.
The REDIRECT rule helps us to redirect the connection to higher
port-numbers. With REDIRECT, we can request the original dst ip:port with
the SO_ORIG_DST sockopt. With DNAT the SO_ORIG_DST is not available.

Besides that, we have to run some services on multiple port-numbers
(sometimes even varying per ip-address). Using only one listening socket
instead of 1000 sockets really helps then.

We can redirect all those connections to the interface's first address. In
fact, this is what we do now. But now and then it is confusing (e.g when
building ip-range check rules in the filter INPUT chain), and we also seem
to trigger routing problems (might be in combination with advanced routing).



> 3) Why restrict only to the addresses attached to the receiving
> interface ? Why not extend to any address attached to a host's
> interface, or even any local address (such as the whole 127.0.0.0/8
> prefix) ?

I don't see any use for that. :-)


-- 
Bas van Sisseren <bas@quarantainenet.nl>
Quarantainenet
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html