ACLs Ahoy!

Basics

Cisco ACLs are a list of rules which are used to evaluate packets. They are
mainly used for packet filtering, but are also useful in a number of other
situations where you might want to select some packets and not select
others. An ACL is always checked from the top to the bottom, rule by rule,
and checking terminates on the FIRST match. Therefore, when sanity checking
your ACLs, you should always check for rules which are subsets of others,
since they just take up space. I've seen many examples like:

deny ip 128.128.0.0 0.0.255.255
[...more rules...]
permit tcp host 128.128.1.5 any

Probably the thing that gives newbies the most trouble is the "Crazy Cisco
Inverse Netmask Thing of Doom" (the 0.0.255.255 above). It's really quite
simple, though. It's not a Netmask. It's not even an inverse netmask
(really) - it's just a wildcard. While it's true that you can use the
complement of your netmask (255 - mask) to calculate the inverse, you can
also do "tricks". Just remember that any '1' in the wildcard byte means the
value to be checked can be '1' or '0' while a '0' means that the value must
be the SAME as in the match value. For confusing values that aren't exactly
in a subnet range, you can use selective permits.

Example: Permit 192.168.1.18 through 192.168.1.33

deny ip any host 192.168.1.16
deny ip any host 192.168.1.17
permit ip any 192.168.1.16 255.255.255.15 (permit 16 - 31)
permit ip any host 192.168.1.32
permit ip any host 192.168.1.33

Five statements - I've seen this written with fifteen.

Random Tips

Logging - cut down false positives

If you're logging denys (lots of people do) then try and remove some common
false positives (like netbios traffic) like this:

[many rules]
deny udp any any eq 137
deny ip any any log

This is one reason for using deny statements before a final logged deny.
Note that the final deny is implied, but we need to write it explicitly if
we want to log.

While we're on logging, remember to produce useful logs, with these
commands:

ntp server x.x.x.x (this could be a security issue - try and use a trusted
one on the inside)
clock timezone EXAMPLE 9 30 (set your local timezone and local time / date)
service timestamps debug datetime msec
service timestamps log datetime msec

Reflexive ACLs

USE THESE.

http://www.cisco.com/univercd/cc/td/doc/product/software/ios113ed/113ed_cr/s
ecur_c/scprt3/screflex.htm

Using reflexive ACLs you can escape the "Gaping DNS Hole" problem that
standard ACLs create - you can simulate statefulness with outgoing UDP
traffic and not just have a permit statement allowing UDP 53 into the
network.

Reflexive ACLs don't fix the "Gaping non-PASV FTP hole", though - you need
CBAC for that, which is a whole different kettle of fish.

Frankly, there's really not much reason to use standard ACLs unless you're
worried about RAM - which will mostly be if you have very large pipes and
underpowered routers. "Static" permit statements in ACLs should be avoided
as much as possible. If you use standard ACLs, "permit tcp any MYNET MYMASK
established" works wonders. If you use reflexive ACLs then you can do even
better and use pseudo-stateful filters. With R-ACLs, you should really only
need to use fixed permit statements for things that you want the Internet to
be able to see (Mail servers, WWW servers etc).

Anyway, that's about enough for now, I guess. Maybe one day I'll write
something up properly (Ha!)

Cheers,

--
Ben Nagy
Network Security Specialist
Marconi Services Australia Pty Ltd
Mb: +61 414 411 520  PGP Key ID: 0x1A86E304  
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]

Reply via email to