Re: [Full-disclosure] RE: Example firewall script

• Previous message: Martin Pitt: "[Full-disclosure] [USN-173-3] Fixed apache2 packages for USN-173-2"
• In reply to: ericscher_at_mac.com: "[Full-disclosure] RE: Example firewall script"
• Next in thread: fd_at_ew.nsci.us: "Re: [Full-disclosure] RE: Example firewall script"
• Reply: fd_at_ew.nsci.us: "Re: [Full-disclosure] RE: Example firewall script"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: Tue, 30 Aug 2005 03:33:05 -0500
To: "ericscher@mac.com" <ericscher@mac.com>

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

On Sat, Aug 27, 2005 at 12:41:33PM -0400, ericscher@mac.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@navigo.com
               ..quis custodiet ipsos custodes?..
(this email has been brought to you by the letters 'v' and 'i'.)
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

• Previous message: Martin Pitt: "[Full-disclosure] [USN-173-3] Fixed apache2 packages for USN-173-2"
• In reply to: ericscher_at_mac.com: "[Full-disclosure] RE: Example firewall script"
• Next in thread: fd_at_ew.nsci.us: "Re: [Full-disclosure] RE: Example firewall script"
• Reply: fd_at_ew.nsci.us: "Re: [Full-disclosure] RE: Example firewall script"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]