William,
My opinion is both! There are several different factors involved. The primary one is to protect the router itself from attack (internal or external) and the secondary is to dump erroneous packets the router doesn't need to process. Here's some other possibilities:
1. Cisco IOS vulnerabilities may require you to filter inbound traffic on the external interfaces (See IOS security info)
2. Applying filters on external and internal interfaces provides better logging capabilities.
3. If one of your internal systems gets compromised, using it to attack other systems is more difficult.
If you have done a good job of designing your internal IP numbering scheme you can keep the lists short using masks. For example, I try to keep all my network devices in the 1-16 IP range, my network printers and servers in the 17-64 IP range. This allows me to permit or deny the entire block of devices with one or two ACL entries. It also allow me to cutdown list processing time but putting "jump" enties at the beginning of the list.
For example, if all my PC addresses are 128-254 I can put an "established" entry near the beginning of my ACL that will "jump" out of the list before processing all the host specific entries.
I also recommend naming your host in the router config instead of using DNS to look entries up. It takes more time to maintain but eliminate the possibility that a corrupt DNS would cause an ACL to be bypassed.
I know this wasn't the simple answer you were hoping for but I hope it helps
-- Bill Stackpole, CISSP
| William Kupersanin <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED] 03/24/01 06:18 AM
|
To: [EMAIL PROTECTED] cc: Subject: Access lists |
Hello,
I am working with someone designing access control lists on a router and I wanted
the groups opinion on ACL design. The scenario is that the router basically has two
external interfaces (one leading to the world at large and one leading to dialin
devices) and a few internal interfaces. We pretty much want unfettered communication
between the two external interfaces but we want to protect the internal interfaces.
My initial thought was to put the "permits" (and implicit as well as explicit
"denys") on the internal interfaces which are directly related to the service in
question. In other words, if one of the internal segments hosts a web server, I
would think it would be better to put the "permit tcp any host webserver eq www" on
the internal interface. She suggests that we put the rules protecting the internal
services on both the external interfaces. Her reasoning is that the router itself
is less vulnerable if the packet never makes it over any interface to begin with. My
feeling is that the rulesets should be kept as straight forward as possible.
So what does the group think? Does stopping the packet at the external interface
make sense from a denial of service or some other perspective, or should I keep my
rulesets simple with the thought that convoluted rulesets are a detriment to
security?
Thanks in advance,
-- Willie
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
