Message-ID: <20050830083304.GA30850@navigo.com>
Date: Tue Aug 30 09:53:38 2005
From: rara at navigo.com (Rachael Treu Gomes)
Subject: RE: Example firewall script

Just a couple of caveats, in-line...

On Sat, Aug 27, 2005 at 12:41:33PM -0400, ericscher@....com said something to the effect of:
> 

> Actually, that's not true.
> I would agree that as a general rule of thumb
> you should have a deny statement at the end
> of every ACL. In fact, Cisco places an implicit
> DENY ANY ANY at the end of their ACL's
> automatically.

I offer that the above might be regarded as a bit rigid.  
As you later state, ACLs can be categorized as tools for 
traffic shaping.  A default deny is not a requisite in 
many cases, and is not the best or only option for 
terminating an ACL, particularly when the chief function 
of the ACL is not security.

..snip snip..

> While an ACL being used as a security device 
> should have a deny statement at the end, proper 
> construction of the ACL is more about following 
> the proper construction rules.

Some might argue that appending a default deny is not
necessarily a best practice for all security-centric
ACLs/firewalls/filters, too.

Depending on the placement of the device/ACL, as well 
as the vendor in question, configuring explicit deny
statements that thwart large ranges/CIDR blocks and
appending a "permit ip any any" rule to the ruleset
may be a preferred method.

When dealing with traffic traversing segments or
situations where large numbers of disparate hosts
are involved, defining explicit permits can result
in too much overhead for the RE/RP to act upon its
instructions reliably; think Cisco and the tendency 
for some devices to barf on ACLs over 128 lines, 
or some of their carrier-class routers that are 
notorious for redistributing ACL rules to other 
cards (?!), and therefore interfaces (?!?!), when 
express forwarding or some such other load demands 
resource/process reallocation.  (ESRs and GSRs are 
strangely flaky with ACLs on some interfaces because 
of the rate at which they're packet-switching across 
huge circuits.)

To my knowledge, neither of these is a deliberate 
Cisco "feature", but both are examples of valid 
reasons to consider explicitly denying objectionable 
traffic and permitting all else.

> 
> This is actually a huge subject, far too big 
> for an individual e-mail to a list.
> 
> But there are some basic rules to keep in mind:
> 
> ACL's analyze traffic from top to bottom, so 
> keep your most specific entries at the top, 
> with more general entries near the bottom; 
> and do your "permits" before your "denys".
> That means you deal with hosts first, then 
> subnets, then  networks, and at each level 
> you have your permit statements  before your 
> deny statements. 

Another potential outlier...regarding this theory...
it is not uncommon (and some will say it is best
practice, in fact) to begin ACLs with anti-spoof
and bogon rules, which will be netblocks and not
hosts and deny rules, not permits.  

Further, thess rules may then be followed by, say, 
icmp-related rules and rules performing blanket actions 
on traffic based on service, which will likely govern 
netblocks again and are just as likely to be set to 
deny as they may be to permit.  Continuing, network-
specific rules may come next, interlaced with rules
designed to impact individual hosts.  I, myself, 
have seen and written countless ACLs that were almost 
exactly inverted compared to what you describe.

In general theory, yes, filters can often be 
strategized as best written going from most to least 
specific, but not-so-rare exceptions to this concept
should also be considered.  

In keeping with the first-match policy of ACLs that you 
mention below, rules "hit" more often by traffic 
can/should be configured to precede rules hit less often 
to cut down on the ACL-parsing that consumes processor 
resource.  

Additionally, when more specific rules permit 
circumnavigation of another function of the ACL (i.e. if 
allowing traffic between 2 specific hosts would also let 
through a specific service later denied in the same ACL), 
their placement earlier in the ruleset is inappropriate.  


> The reason for this is because 
> once a packet matches a line, it's dealt with 
> right then and there. You don't want to have 
> a packet thrown away just before a line that 
> would have permitted it.

Nor would you want the reverse; if configuring an
ACL that explicitly denies all ftp between subnets
being routed, having a 

    permit ip host x.x.x.x host y.y.y.y 

will poke holes in that service-specific rule, as host 
x.x.x.x can throttle any traffic it wants at host y.y.y.y, 
including ftp.  You would only lead with that rule if 
looking to exempt those hosts from that later restriction.

> 
> There are also issues of what KIND of ACL to 
> use and where  to place them; Inbound or Outbound.
> 
> In terms of the original question, the only 
> difference between a "good" line item or a 
> "bad" line item is whether or not the syntax 
> is correct.

Nicely put.
> 
> The only difference between a "good" ACL 
> and a "bad" ACL is  whether or not it's 
> structure is properly designed and whether
> or not it's placed in the proper location.

Again, nicely put.  I might also suggest adding the 
idea that ACL logic and format follow with the same 
requirements for placement, and that overarching 
rules/guidelines regarding their structure and flow be 
evaluated on a case-by-case basis.  It is incomplete
and rife with exception, unfortunately, to decree that
all ACLs and firewall feature sets be constructed in a 
particular manner without taking into account the
particulars surrounding their respective deployments.

Cheers,
--ra

-- 
rachael treu gomes                            rara@...igo.com
               ..quis custodiet ipsos custodes?..
(this email has been brought to you by the letters 'v' and 'i'.)

Powered by blists - more mailing lists