[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
BIND-8/9 interface bug? Or is it FreeBSD?
- Subject: BIND-8/9 interface bug? Or is it FreeBSD?
- From: freebsd at jdc.parodius.com (Jeremy Chadwick)
- Date: Fri Apr 18 16:52:59 2003
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
$ 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 220.127.116.11.43116 > 18.104.22.168.23: S 3333778257:3333778257(0) win 64240 <mss 1460,nop,nop,sackOK> (DF)
16:46:19.541515 22.214.171.124.43117 > 126.96.36.199.23: S 3333778257:3333778257(0) win 64240 <mss 1460,nop,nop,sackOK> (DF)
16:46:21.731619 188.8.131.52.43118 > 184.108.40.206.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_(_at_)_parodius_(_dot_)_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 220.127.116.11: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: ns_req: sendto([18.104.22.168].53): Permission denied
> > So, it doesn't look like that's the offender. :-)
> > By the way, something I didn't cover: 22.214.171.124 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_(_at_)_alum_(_dot_)_mit_(_dot_)_edu
> | cjclark_(_at_)_jhu_(_dot_)_edu
> http://people.freebsd.org/~cjc/ | cjc_(_at_)_freebsd_(_dot_)_org
Visit your host, monkey.org