[19727] in bugtraq
Re: nmap and linux 2.4 (was Re: TCP Timestamping ...)
daemon@ATHENA.MIT.EDU (Stephen A. Zarkos)
Tue Mar 20 14:35:13 2001
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <3AB6533C.36C5C1BC@sentry.net>
Date: Mon, 19 Mar 2001 18:43:08 +0000
Reply-To: "Stephen A. Zarkos" <obsid@SENTRY.NET>
From: "Stephen A. Zarkos" <obsid@SENTRY.NET>
X-To: Bret <bret@REHOST.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
Hello,
I'd like to just add a couple things to this. We've been discussing
this problem a bit on the netfilter mailing list available at
http://lists.samba.org/mailman/listinfo/netfilter,
so this may be the best place to continue this thread, and offer
solutions, etc.
Obviously, the netfilter nat code breaks nmap while using the -O flag or
using decoy options. The (sendto in send_tcp_raw: sendto....) error is
a symptom of this. It also breaks other packet shaping utilities such
as hping, etc., so this does not appear to be an nmap problem.
I don't believe the connection tracking portion of netfilter is to blame
in this case. In my tests the connection tracking code, whether it was
loaded as a module or built statically into the kernel, didn't seem to
get in the way. The cause of the 'sendto..' errors seems to be caused
solely by the iptable_nat.o module(which is huge, of course). Once you
load that one, or build it into the kernel, "nmap -O" no worky. Without
it, nmap/hping/everything works just peachy.
Best Regards,
Steve
Bret wrote:
>
> I am posting this in the hopes that this thread can die on bugtraq and go where
> it is most likely more appropriate (nmap-dev perhaps). Anyway, since I have
> gotten so many different people saying so many different things to me, I
> in response to my previous comments about nmap and linux 2.4 I thought I would
> post this (hopefully) final message in that thread.
>
> Using nmap and linux 2.4 I started noticing some problems. Other people that
> I talked to confirmed they too were having problems. I mentioned this on
> bugtraq, and some people there said they too had sendto() errors, while others
> said they did not.
>
> I started looking around and it appears that the iptables code is what is
> causing the EPERM error. Specifically
> 'Connection tracking (required for masq/NAT)' located in the kernel
> configuration under Networking Options=>IP: Netfilter Configuration.
>
> I have debugging on (dont know if that is required) and get this message
>
> NAT: 3 dropping untracked packet d1c95b20 6 127.0.0.1 -> 127.0.0.1
>
> This is from the connection tracking code that is required for Linux 2.4
> to do NAT. I looked briefly at the source code to this module
> (/usr/src/linux/net/ipv4/netfilter/ip_nat_standalone.c) and it appears that
> if you just not drop the packet, everything will be fine. I really have
> no idea what else may result of doing this, and I really didnt look at this
> part of the code AT ALL. At the time of this writing I have been unable
> to test NAT functionality (although I guess it will work)
>
> One side note to this, you may now see multiple kernel errors as the packet
> goes through the different filters (in, nat, out, etc). I see 3 different
> ones for each packet, but that is not a big deal.
>
> So there are multiple solutions to the sendto() problem with Linux 2.4 + NAT
> 1. Dont use Linux 2.4 + NAT (connection tracking)
> 2. Ignore the sendto() EPERM error, note Test 2 will not be sent
> 3. Alter the kernel to not drop the packet
> I do not know what is going to happen if you do this, so use at
> your own risk. Diff from a linux 2.4.2 kernel
> # diff ip_nat_standalone.c ip_nat_standalone.c.orig
> 81c81
> < return NF_ACCEPT;
> ---
> > return NF_DROP;
>
> For other 2.4 kernels you may want to look for the line:
> printk(KERN_DEBUG "NAT: %u dropping untracked packet %p %u %u.%u.%u.%u -> %u.%u.
> %u.%u\n",
>
> The next statement should be the return.
