>>>>> "Duan" == Duan Zhenhai <ccdzh @
shoukui .
pku .
edu .
cn> writes:
Duan> the second question is what can we do and what should we
Duan> consider when we want to antispoofing,does controling the source
Duan> route enough?
(Warning added after I got done composing this: I kinda went off onto
a tangent about packet filtering options, etc., so I'm sure that I'm
inundating poor Duan with more information than he ever wanted, but
there's probably a fair bit of useful information here about packet
filtering considerations... at least I hope so :-)
Well, there are certain things that you can do to limit the boundaries
of IP address spoofing. This might prove to be sufficient for what
you're doing, but it is important to understand the limits of such a
mechanism.
Let's draw a connection to the Internet that will allow connection to
the Internet, and provide a space for a web site, dns server, or
whatever...
| Big bad Internet
|
/\ packet filtering router (1)
\/ one that logs what it rejects, and what it allows
|
___|_____________
| _|_ _|_ "DMZ"
| |WWW| |DNS|
| |___| |___| some machines (accessible to the Internet)
_|_
|PF | another packet filter
|___| (maybe a commercial packet filtering "firewall," or a
| packet filtering router that will LOG everything)
|
__|___________
|
|
/\ packet filtering router (2)
\/ same deal with logging, blah, blah, blah
|
___|________ corporate private network backbone
OK, the packet filtering router (1) that connects our DMZ network(s)
to the Internet can be configured such that it will deny any packets
that claim to originate from either the DMZ or our private network's
address space. Additionally, we'll want to weed out ridiculous things
like 127.* (loopback); 10.*, 172.16.0.0 - 172.31.255.255, 192.168.0.0
- 192.168.255.255 (used for private internets (dare I even say
"intranets" :) only, as per RFC 1918); anything else you can think of
that makes sense to weed out should go here ... this is off of the top
of my head.
Now, what we've done is ensured by rules (note, we're not
guaranteeing, because if someone breaks into our router and changes
the rules, then this changes things... so, lock the router down by
only allowing physical console access - NO REMOTE LOGINS TO YOUR
ROUTERS! ... do some other common sense things to keep anyone from
being able to mess with it.) that any packets that real our DMZ
networks are from the Internet. Anyone can spoof something to look
like it's from some OTHER Internet address, but if you group ALL
Internet (i.e., not yours) IP addresses into one category:
"untrusted," this is OK.
Now, the "PF" packet filter ("firewall," another router, or whatever)
is critical, because it provides a level of redundancy here. Put the
same ACLs that you put on packet filtering router (1) on there, JUST
IN CASE someone does something "impossible" and breaks through your
first router. Again, LOG EVERYTHING that you allow and deny. Also, put
the same ACLs that you have on packet filtering router (2) on there,
just in case something screwy is going on from the inside (perhaps a
bad guy has broken into a terminal server, and is trying to attack
your firewall from the inside out!) that has gotten through your
internal packet filtering router...
Now, your packet filtering router (2) should be configured just as (1)
was, with the exception that it's the reverse: don't allow things from
teh inside the claim to be from anywhere but your own IP address
space. Dont' allow loopback, RFC 1918 addresses, etc. through. Log
everything that you accept or reject.
Logging is a big deal, especially in a packet filtering type of
firewall environment, for several reasons: (1) logging rejects serve
as alarms that will tell you when you're actively under attack. Don't
panic if you get one poke from a site, but if someone is attempting a
portscan of your web server, for example, this is something you'll
definitely want to know, and the logs will show this attempt.
(2) Logging what you're allowing will tell you if your rules are
working. Don't just audit the reject logs. Take a look at what you're
allowing, and make sure that no stupid things are going on. Test them
once in a while (not once a year, I'd say monthly at the worst,
depending on your paranoia.)
Also, make sure that the place your logs go (perhaps you're using a
machine somewhere in your DMZ to accept all of the log data from all
of your packet filters via syslogd) is (1) protected, so that someone
from outside the DMZ (i.e., anything but your packet filters, and
whatever else that's YOURS that is logging to it via syslog) can't
write to it, and (2) it has BOATLOADS of free disk space. If someone
IS able to start writing crap to your log machine's syslogd, they'll
try to fill up your disk space before commencing the attack. If you've
got, say, 10GB of free space at any given time, the liklihood of
success is significantly lower than if you're down to 14k of free
space :-)
Another note, which is depending on your needs and paranoia, is where
to put the publicly accessable servers (like WWW, DNS, etc.) I've
drawn them as part of the DMZ, which might be OK, but might not
be. There is an additional level of security if you subnet them off of
your outside packet filtering router (1), becaues if someone breaks
through your router, and then breaks into one of those machines, an
attack can't commense from the same LAN: it has to attack your
firewall from a LAN that can be labeled "untrusted" by the
firewall. Perhaps they can break through there, too. So you've got
ACLs redundant to what your outside packet filter and "firewall"
packet filter have on your inside packet filter. Again, now they've
got ANOTHER layer to break through. (By this time, your alarms have
been going nuts and have paged everyone from your sysadmins to the CIO
to look into this, right?)
All of this really boils down to a few simple maxims:
* know exactly what it is that you need to do
* don't allow anything to go on that you don't have defined as
being absolutely necessary
* understand the technology you're dealing with: its limits, its
features, and what other people are doing with it
* decide HOW MUCH protection you want, and understand what your
tradeoffs are. (For example, I've shown the above network to
have three packet filtering mechanisms. You could increase
security by adding a fourth, fifth, etc., but are you spending
$1,000,000 to protect $1,000? Also, the more ACLs you have on a
router, the more you're going to slow it down. Are all of those
redundant ACLs going to kill your network performance? Not if
you can afford faster routers, but what if you can only afford
Cisco 4500-Ms? Do you have so many ACLs that to get the same
level of performance that the 4500 offers that you'd need to get
into a 7000 series?)
I personally a bit leery of using purely packet filtering for building
firewalls, but perhaps that's because I don't understand all of the
details of packet filtering technology as it exists right at this
moment. There might be some newfangled ways of doing things that I
don't know about. Perhaps it's because I'm paranoid. Perhaps it's
because there really are significant limitations to what packet
filters can do at this very moment and there is good reason to doubt
them.
However, I *do* think that packet filtering is very important. There
is a definite layer of security that is provided there, and something
as simple as adding some common sense ACLs to a router in front of
(and behind) a good application-layer firewall can provide very useful
logs and additional security. Of course, in really huge environments,
application layer firewalls tend to be problematic from performance
standpoints, although there are ways to solve that problem.
I guess I went off a little more than I intended, but in any event, I
hope the information is useful. Also, if you haven't done so already,
I highly recommend getting ahold of Cheswick & Bellovin's "Firewalls
and Internet Security: Repelling the Wily Hacker," Addison-Wesley
Professional Computing Series 0-201-63357-4 * Paperback * 320 pages *
©1994 (See http://www.aw.com/cp/Ches.html for more info.) This is a
more theoretical approach to security in general, and will leave you
with a much better understanding of the kinds of things to think about
when dealing with security, especially firewalls.
Also, also, I recommend Building Internet Firewalls by D. Brent
Chapman and Elizabeth D. Zwicky. Published by O'Reilly & Associates,
1st Edition September 1995, 517 Pages, ISBN 1-56592-124-0, List price
$29.95. (See http://www.greatcircle.com/firewalls-book/ for more
info.) This is the hands-on approach of HOW to build a firewall:
you'll also get a good appreciation for the kinds of things to think
about, etc., but this is structured for the specific purpose of
showing you how to do it. This book and the C&B book compliment each
other very well.
C Matthew Curtin Chief Hacker
Fahlgren, Inc. 655 Metro Pl S, Ste 700, Box 7159 Dublin OH 43017-7159
http://users1.ee.net/cmcurtin/ cmcurtin @
fahlgren .
com PGP Mail Preferred
Follow-Ups:
|
|
