Date: Wed, 12 Mar 2003 10:58:30 -0800 From: "Crist J. Clark" <crist.clark@attbi.com> To: JoeB <barbish@a1poweruser.com> Cc: ipfw@freebsd.org Subject: Re: Anti-Spoofing Option Message-ID: <20030312185830.GC16143@blossom.cjclark.org> In-Reply-To: <MIEPLLIBMLEEABPDBIEGGECLDIAA.barbish@a1poweruser.com> References: <20030312080622.GA42446@blossom.cjclark.org> <MIEPLLIBMLEEABPDBIEGGECLDIAA.barbish@a1poweruser.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Mar 12, 2003 at 01:23:33PM -0500, JoeB wrote:
> This is a half baked idea. Any rule option that only works on
> stateless rules is incomplete. This option needs more development so
> it will function correctly in an rule set that contains dynamic
> rules generated by the keep-state option. Dynamic rules are an
> integral part of IPFW and nothing should be allowed into IPFW that
> will give the misguided impression that the exclusive use of
> stateless rules result in a firewall that will provide adequate
> protection in today's world.
Uh, where does it say that it doesn't work with dynamic rules? The
examples I gave were stateless because it's easier to give
free-standing examples. The reason I made it a option rather than an
action was specfically to make it work better in dynamic rules. This,
# ipfw add 1000 pass ip from ${internal_net} to any verrevpath in via ${if}
Will work fine and check that the returning packets that otherwise
match the dynamic rule are also not spoofed.
> -----Original Message-----
> From: owner-freebsd-ipfw@FreeBSD.ORG
> [mailto:owner-freebsd-ipfw@FreeBSD.ORG]On Behalf Of Crist J. Clark
> Sent: Wednesday, March 12, 2003 3:06 AM
> To: ipfw@freebsd.org
> Subject: Anti-Spoofing Option
>
> I've created a new option for ipfw(8) (IPFW2-only to be exact) that
> basically does automatic anti-spoofing. I've called the knob,
> "verrevpath," in honor of the Cisco command,
>
> ip verify unicast reverse-path
>
> When the option is specified in a rule, a packet tested against the
> rule matches iff,
>
> a) The packet is _not_ entering the system, or
>
> b) The packet is coming into the interface that traffic sent to
> the
> packet's source address would go out of.
>
> For example, take a firewall with three interfaces,
>
> Internet}---if0[Firewall]if1---{192.168.0.0/24
> --
> if2---{172.16.0.0/16
>
> Any packets arriving on if0 with a source of 192.168.0.0/24 or
> 172.16.0.0/16 will not match a rule with 'verrevpath.' Likewise,
> anything coming in on if1 that doesn't have a source of
> 192.168.0.0/24
> will not match, nor will anything on if2 without a 172.16.0.0/16
> source.
>
> To turn on anti-spoofing on a firewall, put,
>
> # ipfw add 100 pass ip from any to any verrevpath
>
> Before any other rules. All done (well, only if you're not using
> dynamic rules).
>
> The check is done by simply getting the route for the source of the
> packet and making sure the interface the route goes out on is the
> same
> as the one the packet arrived on.
>
> Of course, the really interesting appeal of this may not necessarily
> for "firewalls," but for routers running dynamic routing protocols
> (which is why I was thinking sysctl(8) at first).
>
> Patch for CURRENT is attached. It should apply to STABLE (make sure
> to
> patch ip_fw2.h rather than ip_fw.h), but I've had a little trouble
> getting IPFW2 running right on my STABLE crash box so I have not
> tested it.
>
> Now, some discussion. I originally was just going to implement a
> sysctl(8) knob that did the check in ip_input() for every packet.
> But
> after starting on that, it occured to me that it might be better as
> a
> firewall action. I started doing that when I realized that it
> doesn't
> really work well as a firewall action. I went back to a sysctl(8)
> until I decided that it would work fine as a firewall option. I'm
> not
> 100% on any of those choices yet.
>
> One of the problems I had with making it an action (and one of the
> initial reasons I leaned away from a sysctl(8) knob) is how to
> handle
> logging. And I'm still not happy with the logging issue. It would be
> nice to somehow include in the logs that the packet was dropped
> because there was a RPF problem and log the incoming interface and
> where we expected such a packet to come from. Right now, there is no
> logging angle. Making it an action could give you more ways to go
> there, but how do you tell it to log only failures? To log failure
> and
> success? To log neither? (Actually, that's pretty easy to do, but
> the
> rules would get ugly lookin'.)
>
> Anyone have any ideas on how to improve on this before I commit it
> (after which making major changes is less desirable)? Ideas how to
> do
> the logging better? Keep in mind that I don't want to have to put
> terrible, ugly hacks in luigi's purty IPFW2 code to implement any
> suggestions.
>
> Oh, and of course, please test it. Also, some thoughts about
> configurations where this option can break things (like when you are
> purposely doing asymmetric routing) and any creative uses.
> --
> Crist J. Clark | cjclark@alum.mit.edu
> | cjclark@jhu.edu
> http://people.freebsd.org/~cjc/ | cjc@freebsd.org
--
Crist J. Clark | cjclark@alum.mit.edu
| cjclark@jhu.edu
http://people.freebsd.org/~cjc/ | cjc@freebsd.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ipfw" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030312185830.GC16143>