netdev - Re: [PATCH] netfilter: nf_nat: avoid double nat for loopback

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4DEEAD6F.8050505@trash.net>
Date:	Wed, 08 Jun 2011 00:59:59 +0200
From:	Patrick McHardy <kaber@...sh.net>
To:	Julian Anastasov <ja@....bg>
CC:	Pablo Neira Ayuso <pablo@...filter.org>,
	netfilter-devel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH] netfilter: nf_nat: avoid double nat for loopback

On 07.06.2011 21:46, Julian Anastasov wrote:
> 
> 	Hello,
> 
> On Tue, 7 Jun 2011, Patrick McHardy wrote:
> 
>> On 04.06.2011 16:02, Julian Anastasov wrote:
>>>
>>> 	Avoid double NAT and seq adjustment for loopback
>>> traffic because it causes silent repetition of TCP data. One
>>> example is passive FTP with DNAT rule and difference in the
>>> length of IP addresses.
>>>
>>> 	This patch adds checks if packet is sent and
>>> received via loopback device. As the same conntrack is used
>>> both for outgoing and incoming direction, we restrict NAT,
>>> seq adjustment and confirmation to happen only in
>>> outgoing direction (OUTPUT and POSTROUTING).
>>>
>>> Signed-off-by: Julian Anastasov <ja@....bg>
>>> ---
>>>
>>> 	As the check is not so cheap, another alternative
>>> is to add new skb flag, eg. "loopback", that can be set in 
>>> drivers/net/loopback.c, loopback_xmit(). May be there is space
>>> for it in flags2?
>>
>> I don't think we should be adding code specifically needed for netfilter
>> to the loopback driver if we can avoid it. I don't think we need to
>> actually avoid calling nf_nat_packet twice, that shouldn't do any harm,
>> just the sequence number adjustment. So we could add the loopback check
> 
> 	Yes, may be calling nf_nat_packet is not fatal.
> 
>> to the IPS_SEQ_ADJUST_BIT case to at least avoid it in some cases.
>> Would that work or am I missing something?
> 
> 	Logically, the new check can be after
> test_bit(IPS_SEQ_ADJUST_BIT, &ct->status). But I suspect
> some modules adjust seqs in the helper->help call,
> for example, sip_help_tcp if I'm correctly reading the
> code.

Yes, you're right. But it's the only one since it's the only helper
doing possibly many modifications on a single TCP packet, which can't
be handled by the generic code properly. So if you're worried about
performance costs, I'd have no problems adding this check to the SIP
helper.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html