Re: nmap and linux 2.4 (was Re: TCP Timestamping ...)

["Stephen A. Zarkos" <obsid () SENTRY NET>]

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.