Date: Wed, 25 Feb 2004 06:41:08 +1100 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Andrea Venturoli <ml.ventu@flashnet.it> Cc: freebsd-net@freebsd.org Subject: Re: Bad loopback traffic not stopped by ipfw. Message-ID: <Pine.BSF.3.96.1040225055545.5463A-100000@gaia.nimnet.asn.au> In-Reply-To: <200402241611.i1OGBMmY026274@soth.ventu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 24 Feb 2004, Andrea Venturoli wrote:
> 4.8-RELEASE-p15:
ipfw1?
> In /var/log/all.log I get a lot of:
>
> snort: [1:528:4] BAD-TRAFFIC loopback traffic [Classification:
> Potentially Bad Traffic] [Priority: 2]: {TCP}
> 127.0.0.1:80 -> xx.xx.xx.xx:1055
>
> (src port is always 80, dst port changes, xx.xx.xx.xx is my tun0 IP.)
There's a bit of that about; been seeing such here for some weeks now:
Feb 18 04:53:19 [..] ipfw: 60020 Deny TCP 127.0.0.1:80 w.x.y.z:1612 in via tun0
Feb 18 05:02:36 [..] ipfw: 60020 Deny TCP 127.0.0.1:80 w.x.y.z:1785 in via tun0
Feb 18 05:02:36 [..] ipfw: limit reached on rule #60020
# ipfw -t sh|grep -1 60020
60000 408814 51012356 Wed Feb 25 05:36:00 2004 \
allow ip from any to any via lo0
60020 390 15600 Wed Feb 25 02:05:17 2004 \ <<<<<-----
deny log ip from 127.0.0.0/8 to any
60030 0 0 \
deny log ip from any to 127.0.0.0/8
.. still dribbling in I see. Yawn. But they're being denied ok here.
> tcpdumping all interfaces one by one shows the packet only on tun0:
>
> tcpdump -i tun0 -l src or dst 127.0.0.1
>
> 17:03:17.069193 127.0.0.1.http > 82.48.28.67.us-gv: R 0:0(0) ack 1889337345 win 0
> 17:03:18.034467 127.0.0.1.http > 82.48.28.67.tcp-id-port: R 0:0(0) ack 142009958 5 win 0
> ..
>
> ipfw -a l (relevant parts):
>
> 00050 1152 388408 divert 8668 ip from any to any via tun0
> ..
> 01000 6 1248 allow ip from any to any via lo0 (this is really local ntp traffic)
> ..
> 01000 0 0 deny log ip from 127.0.0.0/8 to any in recv tun0
Try just 'deny log ip from 127.0.0.0/8 to any' (and as mentioned, 'deny
log ip from any to 127.0.0.1/8' outbound also. Works here.
Not sure if the diversion for NAT above might affect whether they're
appearing to ipfw as still being 'in recv tun0' or not at rule(s) 1000,
but you'd want to block these on any interface, in or out, wouldn't you?
> IMHO opinion wrong packets are arriving from the upstream router (for
> which it would be useless to ask for a fix),
Indeed, it's probably not paying attention to source addresses anyway.
> snort and tcpdump correctly report them, but I think I should also
> see ipfw blocking them. At least this is what I read, googling
> around, on a previous thread on freebsd-stable.
You should indeed, but maybe some other rule between 50 and 1000 is
either blocking or allowing them? Anyway, try the more general rule?
(Caveat: the above are on a 2.2.6 router/gw that's still chugging along;
I assume it's more likely a config prob than an issue with 4.8 ipfw(n))
Cheers, Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.1040225055545.5463A-100000>