On Fri, Aug 16, 2002 at 02:44:23PM -0500, taproot420 wrote:
> I am not really a tcpdump fan yet, as I am used to snoop but I am trying
> to learn the syntax.
Ick. Snoop annoys me to no end with the inability to turn off its
attempts to resolve IPs to hostnames. The rule syntax is almost the
same with some minor differences. tcpdump has some more options and
flexibility than snoop. However, if you're trying to debug RPC
traffic, snoop does rewl.
> I will try what you suggested and watch things
> happen to see exactly what's going on ,but for now everything is working
> great. Back to what we were conversing about yesterday and I wanted to
> bounce a few ideas for ipf of you. I was just thinking of what you said
> about some users putting a rouge server on the network, I am not talking
> about the case of 12.242.18.34 going down but some user spoofing
> 12.242.18.34 with their dhcp server, or for that matter any server/host
> you have deemed trusted. If IPF could use MAC address in its filters
> that would solve 90+% possibility of communicating with a fake host. I
> know IPF is an ip firewall but it does dabble in layer 2 as on a bridge,
> and on a bridge it would seem possible for Darren to add some code which
> would allow IPF to see MAC address as the interfaces are already in
> promiscuous mode. For example lets say the MAC address for my isp's dhcp
> server 12.242.18.34 is 00:11:12:52:09:2b and the MAC of the interface on
> the nat/router which will be using dhcp 00:02:12:49:08:1b. Ipf might be
> able to monitor the bridge0 interface for this info.
>
> pass in quick on xl1 proto udp from 00:11:12:52:09:2b port = 67 to
> 00:02:12:49:08:1b port = 68.
(1) A MAC address is about this, > <, much harder to spoof than an IP
address on a LAN. (2) Just as your provider might switch IPs on you
without warning, they are even _more_ likely to swap machines (new
MAC) and use the same IP. (3) Load-sharing configurations, like I
believe you said your ISP may use for the DHCP server, often have MACs
jump all over the place. For example, check out what I see on my home
firewall _everyday,_
$ grep '^Aug 15 .* arp' /var/log/messages
Aug 15 03:17:35 <kern.info> buttercup /kernel: arp: 12.234.90.1 moved from
00:d0:ba:83:e6:54 to 00:d0:ba:83:e6:70 on de0
Aug 15 03:17:37 <kern.info> buttercup /kernel: arp: 12.234.90.1 moved from
00:d0:ba:83:e6:70 to 00:d0:ba:83:e6:54 on de0
Aug 15 07:16:35 <kern.info> buttercup /kernel: arp: 12.234.90.1 moved from
00:d0:ba:83:e6:54 to 00:d0:ba:83:e6:70 on de0
Aug 15 07:16:36 <kern.info> buttercup /kernel: arp: 12.234.90.1 moved from
00:d0:ba:83:e6:70 to 00:d0:ba:83:e6:54 on de0
Aug 15 11:15:36 <kern.info> buttercup /kernel: arp: 12.234.90.1 moved from
00:d0:ba:83:e6:54 to 00:d0:ba:83:e6:70 on de0
Aug 15 11:15:40 <kern.info> buttercup /kernel: arp: 12.234.90.1 moved from
00:d0:ba:83:e6:70 to 00:d0:ba:83:e6:54 on de0
Aug 15 15:14:36 <kern.info> buttercup /kernel: arp: 12.234.90.1 moved from
00:d0:ba:83:e6:54 to 00:d0:ba:83:e6:70 on de0
Aug 15 15:14:37 <kern.info> buttercup /kernel: arp: 12.234.90.1 moved from
00:d0:ba:83:e6:70 to 00:d0:ba:83:e6:54 on de0
Aug 15 19:13:36 <kern.info> buttercup /kernel: arp: 12.234.90.1 moved from
00:d0:ba:83:e6:54 to 00:d0:ba:83:e6:70 on de0
Aug 15 19:13:41 <kern.info> buttercup /kernel: arp: 12.234.90.1 moved from
00:d0:ba:83:e6:70 to 00:d0:ba:83:e6:54 on de0
Aug 15 23:12:36 <kern.info> buttercup /kernel: arp: 12.234.90.1 moved from
00:d0:ba:83:e6:54 to 00:d0:ba:83:e6:70 on de0
Aug 15 23:12:36 <kern.info> buttercup /kernel: arp: 12.234.90.1 moved from
00:d0:ba:83:e6:70 to 00:d0:ba:83:e6:54 on de0
00:d0:ba is a Cisco prefix, and 12.234.90.1 is my default route. I
have little doubt that those are both pieces of hardware owned by the
ISP (also AT&T BBI, BTW) in some whacked-out failover configuration
that does some weird flip every four hours.
(4) If you want to lock MAC to IP mappings, you can do it
with arp(8). (5) Nothing in IPFilter is Ethernet specific, don't make
it depend on knowing Ethernet and what other link-layer protocols do
you want to teach it?
> A couple of other things I always wondered if possible in ipf.
>
> 1. Without having to hard wire blocknonip in the bridge0 config, how
> about allowing ipf to make those decisions. This might be useful for
> bridges that have more than 2 interfaces.
The bridging you are using is an OpenBSD-only hack. Bridging in
FreeBSD is very, very different and IPFilter support in FreeBSD
bridging is lame (I can say that, I wrote the code). AFAIK, NetBSD and
Solaris don't bridge at all (without add-on software that doesn't work
well with IPF). Who knows about other platforms. IPFilter itself
doesn't really know or care about bridging.
--
Crist J. Clark | [EMAIL PROTECTED]
| [EMAIL PROTECTED]
http://people.freebsd.org/~cjc/ | [EMAIL PROTECTED]
