At 12:32 PM 3/23/2001 -0500, [EMAIL PROTECTED] wrote:
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)
>> Specific to organization
2. Applying filters on external and internal interfaces provides better
logging capabilities.
and can increase CPU utilization
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.
disable DNS, limit the folks who have access to router configs, and don't
allow high priced security consultants log on to the routers.. :)
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.]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
