lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
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