Date: Fri, 18 Apr 2003 16:52:14 -0700 From: Jeremy Chadwick <freebsd@jdc.parodius.com> To: freebsd-net@freebsd.org Subject: Re: BIND-8/9 interface bug? Or is it FreeBSD? Message-ID: <20030418235214.GB85777@parodius.com> In-Reply-To: <20030418220229.GB39466@blossom.cjclark.org> References: <20030418174956.GA71335@parodius.com> <20030418200936.82331.qmail@web10410.mail.yahoo.com> <20030418201645.GA77986@parodius.com> <20030418220229.GB39466@blossom.cjclark.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Since when? :-) That wouldn't make very much sense, and
would be extremely misleading for network administrators.
bpf should have the highest priority, well above ipfw.
I just verified that fact with a test: blocking any telnet I/O
across my public interface and telnetting in from my home
workstation:
$ ipfw add 350 deny tcp from any to any 23 via fxp0
00350 deny tcp from any to any 23 via fxp0
$ ipfw -a list 350
00350 0 0 deny tcp from any to any 23 via fxp0
$ tcpdump -p -ifxp0 -l -n "port 23"
tcpdump: listening on fxp0
16:46:17.585420 12.234.135.66.43116 > 64.71.184.170.23: S 3333778257:3333778257(0) win 64240 <mss 1460,nop,nop,sackOK> (DF)
16:46:19.541515 12.234.135.66.43117 > 64.71.184.170.23: S 3333778257:3333778257(0) win 64240 <mss 1460,nop,nop,sackOK> (DF)
16:46:21.731619 12.234.135.66.43118 > 64.71.184.170.23: S 3333778257:3333778257(0) win 64240 <mss 1460,nop,nop,sackOK> (DF)
$ ipfw -a list 350
00350 3 144 deny tcp from any to any 23 via fxp0
The fact that tcpdump does not see the erroneous behaviour
BIND is exhibiting is very bothersome. What I have yet to do
is run tcpdump on fxp1 and see if the traffic shows up there
(and if it does, then I would classify this as a FreeBSD bug
somewhere, while the origin itself would be a BIND bug).
--
| Jeremy Chadwick jdc@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. |
On Fri, Apr 18, 2003 at 03:02:29PM -0700, Crist J. Clark wrote:
> On Fri, Apr 18, 2003 at 01:16:45PM -0700, Jeremy Chadwick wrote:
> > Oleg:
> >
> > I tried your recommendation of commenting out the transfer-source
> > line, and within a few moments of running this:
> >
> > ipfw zero 1005 && ndc stop && /usr/sbin/named -u bind -g bind
> >
> > ...saw the following in our security syslog:
> >
> > Apr 18 13:11:09 pentarou /kernel: ipfw: Entry 1005 cleared.
> > Apr 18 13:11:33 pentarou /kernel: ipfw: 1005 Deny UDP 10.0.0.1:53 64.71.184.190:53 out via fxp0
> > Apr 18 13:12:04 pentarou last message repeated 5 times
> >
> > ...and our named syslog:
> >
> > Apr 18 13:11:33 pentarou named[77949]: ns_req: sendto([64.71.184.190].53): Permission denied
> >
> > So, it doesn't look like that's the offender. :-)
> >
> > By the way, something I didn't cover: 64.71.184.190 is our
> > secondary nameserver's WAN IP. It's private is 10.0.0.2.
> >
> > I'm still wondering why tcpdump isn't catching the I/O...
>
> That I can answer. The bpf(4) hooks lie very close to the "edges" of
> the stack, right in the device drivers. Outgoing packets that get
> blocked by the firewall never get low enough in the stack to get
> caught by BPF.
>
> I have a guess what those might be, but it'd be a weird
> feature. Perhaps the queries (potentially) involved with zone
> transfers use the transfer address?
>
> It'd be nice if you could get those outgoing packets. Can you turn on
> query logging within BIND? It _is_ possible to grab those packets
> before the firewall blocks them, but it might take some tricks with
> divert(4) sockets or other ugliness to do it.
> --
> Crist J. Clark | cjclark@alum.mit.edu
> | cjclark@jhu.edu
> http://people.freebsd.org/~cjc/ | cjc@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030418235214.GB85777>