Cisco ASA 5508-X, Руководство по настройке

Страница: 27 / 428

3-3
Cisco ASA Series Firewall CLI Configuration Guide
Chapter 3 Access Control Lists
About ACLs
Develop a naming convention that will help you identify the intended purpose of the ACL. For example,
ASDM uses the convention
interface-name_purpose_direction , such as “outside_access_in”, for an ACL
applied to the “outside” interface in the inbound direction.
Traditionally, ACL IDs were numbers. Standard ACLs were in the range 1-99 or 1300-1999. extended
ACLs were in the range 100-199 or 2000-2699. The ASA does not enforce these ranges, but if you want
to use numbers, you might want to stick to these conventions to maintain consistency with routers
running IOS Software.
Access Control Entry Order
An ACL is made up of one or more ACEs. Unless you explicitly insert an ACE at a given line, each ACE
that you enter for a given ACL name is appended to the end of the ACL.
The order of ACEs is important. When the ASA decides whether to forward or drop a packet, the ASA
tests the packet against each ACE in the order in which the entries are listed. After a match is found, no
more ACEs are checked.
Thus, if you place a more specific rule after a more general rule, the more specific rule might never be
hit. For example, if you want to permit network 10.1.1.0/24, but drop traffic from host 10.1.1.15 on that
subnet, the ACE that denies 10.1.1.15 must come before the one that permits 10.1.1.0/24. If the permit
10.1.1.0/24 ACE comes first, 10.1.1.15 will be allowed, and the deny ACE will never be matched.
In an extended ACL, use the line number parameter on the access-list command to insert rules at the
right location. Use the show access-list name command to view the ACL entries and their line numbers
to help determine the right number to use. For other types of ACL, you must rebuild the ACL (or better,
use ASDM) to change the order of ACEs.
Permit/Deny vs. Match/Do Not Match
Access control entries either “permit” or “deny” traffic that matches the rule. When you apply an ACL
to a feature that determines whether traffic is allowed through the ASA or is dropped, such as global and
interface access rules, “permit” and “deny” mean what they say.
For other features, such as service policy rules, “permit” and “deny” actually mean “match” or “do not
match.” In these cases, the ACL is selecting the traffic that should receive the services of that feature,
such as application inspection or redirection to a service module. “Denied” traffic is simply traffic that
does not match the ACL, and thus will not receive the service.
Access Control Implicit Deny
All ACLs have an implicit deny statement at the end. Thus, for traffic controlling ACLs such as those
applied to interfaces, if you do not explicitly permit a type of traffic, that traffic is dropped. For example,
if you want to allow all users to access a network through the ASA except for one or more particular
addresses, then you need to deny those particular addresses and then permit all others.
For ACLs used to select traffic for a service, you must explicitly “permit” the traffic; any traffic not
“permitted” will not be matched for the service; “denied” traffic bypasses the service.
For EtherType ACLs, the implicit deny at the end of the ACL does not affect IP traffic or ARPs; for
example, if you allow EtherType 8037, the implicit deny at the end of the ACL does not now block any
IP traffic that you previously allowed with an extended ACL (or implicitly allowed from a high security