Date: Wed, 12 Mar 2003 13:23:33 -0500 From: "JoeB" <barbish@a1poweruser.com> To: <cjclark@alum.mit.edu>, <ipfw@freebsd.org> Subject: RE: Anti-Spoofing Option Message-ID: <MIEPLLIBMLEEABPDBIEGGECLDIAA.barbish@a1poweruser.com> In-Reply-To: <20030312080622.GA42446@blossom.cjclark.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
-----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
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?MIEPLLIBMLEEABPDBIEGGECLDIAA.barbish>