Re: ACL design.

["Michael Painter" <tvhawaii () shaka com>]

> > 2.  Every rule's processing includes matching, even if the match fails
and the packet falls through to the next rule, so try to avoid duplicating
effort.  Filter out bad source addresses early (anti-spoofing) so you can
just use "any" as the source for the remaining rules.<<

And Cisco has this to say:

With the use of the protocols and addresses identified, the infrastructure ACL can be built to permit the protocols and protect the 
addresses. In addition to direct protection, the ACL also provides a first line of defense against certain types of invalid traffic 
on the Internet.

RFC 1918 space must be denied.

Packets with a source address that fall under special-use address space, as defined in RFC 3330, must be denied.

Anti-spoof filters must be applied. (Your address space must never be the source of packets from outside your AS.)

--Michael



----- Original Message ----- 
From: "David Gillett" <gillettdavid () fhda edu>
To: "'Nick Vaernhoej'" <nick.vaernhoej () capitalcardservices com>; <security-basics () securityfocus com>
Sent: Friday, May 04, 2007 6:55 AM
Subject: RE: ACL design.


>  There is, I believe, an O'Reilly book dedicated to the subject.
>
>  I work with (extended) ACLs extensively, and there are a couple of
> basic things to keep in mind:
>
> 1.  Every packet starts at the top of the list and works its way down
> until it matches.  So the more packets you can match near the top of
> the list, the less having an ACL will impact your network performance.
> So, for instance, your "permit tcp any any established" line should
> be right near the top.  Try to put general rules near the top and more
> specific rules near the bottom.
>
> 2.  Every rule's processing includes matching, even if the match fails
> and the packet falls through to the next rule, so try to avoid duplicating
> effort.  Filter out bad source addresses early (anti-spoofing) so you can
> just use "any" as the source for the remaining rules.
>
> 3.  While it never makes sense to have a discontiguous subnet mask,
> sometimes you can save a rule or two by having a discontiguous wildcard
> mask in an ACL.  Get very comfortable with wildcard masks.
>
> 4.  There are some issues for which you NEED a stateful firewall, and
> ACLs just won't cut it.  Understand these issues, and don't try to build
> baroque ACL structures to "work around" them.  Know the limitations of
> your tools.
>
> 5.  This is a reasonably good forum to ask for help with specifics; there
> may be even better ones out there.
>
> David Gillett
>
>
> > -----Original Message-----
> > From: listbounce () securityfocus com
> > [mailto:listbounce () securityfocus com] On Behalf Of Nick Vaernhoej
> > Sent: Thursday, May 03, 2007 12:53 PM
> > To: security-basics () securityfocus com
> > Subject: ACL design.
> >
> > Good afternoon,
> >
> > What reading material can you guys suggest to establish a
> > good/great understanding of how to implement and maintain
> > access control lists.
> > Imagine going from no ACL's and dumb switches to a number of
> > core switches and plenty of ACl options. Aside from the
> > manual telling me how to create them it would be great with
> > some guidance.
> >
> > Thanks!
> >
> > Nick Vaernhoej
> > "Quidquid latine dictum sit, altum sonatur."
> >
> >
> > This electronic transmission is intended for the addressee
> > (s) named above. It contains information that is privileged,
> > confidential, or otherwise protected from use and disclosure.
> > If you are not the intended recipient you are hereby notified
> > that any review, disclosure, copy, or dissemination of this
> > transmission or the taking of any action in reliance on its
> > contents, or other use is strictly prohibited. If you have
> > received this transmission in error, please notify the sender
> > that this message was received in error and then delete this message.
> > Thank you.