By Don R. Crawley
Access Control Lists (ACLs) are sequential lists of permit and deny conditions applied to traffic flows on a device interface. ACLs are based on various criteria including protocol type source IP address, destination IP address, source port number, and/or destination port number.
ACLs can be used to filter traffic for various purposes including security, monitoring, route selection, and network address translation. ACLs are comprised of one or more Access Control Entries (ACEs). Each ACE is an individual line within an ACL.
ACLs on a Cisco ASA Security Appliance (or a PIX firewall running software version 7.x or later) are similar to those on a Cisco router, but not identical. Firewalls use real subnet masks instead of the inverted mask used on a router. ACLs on a firewall are always named instead of numbered and are assumed to be an extended list.
The syntax of an ACE is relatively straight-forward:
Ciscoasa(config)#access-list name [line number] [extended] {permit | deny} protocol
source_IP_address source_netmask [operator source_port] destination_IP_address
destination_netmask [operator destination_port] [log [[disable | default] | [level]] [interval seconds]] [time-range name] [inactive]
Here's an example:
asa(config)# access-list demo1 permit tcp 10.1.0.0 255.255.255.0 any eq www
asa(config)# access-list demo1 permit tcp 10.1.0.0 255.255.255.0 any eq 443
asa(config)# show access-list demo1
access-list demo1; 2 elements
access-list demo1 line 1 extended permit tcp 10.1.0.0 255.255.255.0 any eq www
access-list demo1 line 2 extended permit tcp 10.1.0.0 255.255.255.0 any eq https
In the above example, an ACL called "demo1" is created in which the first ACE permits TCP traffic originating on the 10.1.0.0 subnet to go to any destination IP address with the destination port of 80 (www). In the second ACE, the same traffic flow is permitted for destination port 443. Notice in the output of the show access-list that line numbers are displayed and the extended parameter is also included, even though neither was included in the configuration statements.
You can deactivate an ACE without deleting it by appending the inactive option to the end of the line.
As with Cisco routers, there is an implicit "deny any" at the end of every ACL. Any traffic that is not explicitly permitted is implicitly denied.
**Editing ACLs and ACEs**
New ACEs are appended to the end of the ACL. If you want, however, to insert the new ACE at a particular location within the ACL, you can add the line number parameter to the ACE:
asa04(config)# access-list demo1 line 1 deny tcp host 10.1.0.2 any eq www
asa04(config)# show access-list demo1
access-list demo1; 3 elements
access-list demo1 line 1 extended deny tcp host 10.1.0.2 any eq www
access-list demo1 line 2 extended permit tcp 10.1.0.0 255.255.255.0 any eq www
access-list demo1 line 3 extended permit tcp 10.1.0.0 255.255.255.0 any eq https
Notice in the first line of the example above that an ACE is added at line one in the ACL. Notice in the output from the show access-list demo1 command that the new entry is added in the first position in the ACL and the former first entry becomes line number two.
You can remove an ACE from an ACL by preceding the ACE configuration statement with the modifier no, as in the following example:
Asa04(config)#no access-list demo1 deny tcp host 10.10.2 any eq www
In my next article, I'll show you how to use time-ranges to apply access-control lists only at certain times and/or on certain days. I'll also show you how to use object-groups with access-control lists to simplify ACL management by grouping similar components such as IP addresses or protocols together.
Copyright (c) 2008 Don R. Crawley
ACLs can be used to filter traffic for various purposes including security, monitoring, route selection, and network address translation. ACLs are comprised of one or more Access Control Entries (ACEs). Each ACE is an individual line within an ACL.
ACLs on a Cisco ASA Security Appliance (or a PIX firewall running software version 7.x or later) are similar to those on a Cisco router, but not identical. Firewalls use real subnet masks instead of the inverted mask used on a router. ACLs on a firewall are always named instead of numbered and are assumed to be an extended list.
The syntax of an ACE is relatively straight-forward:
Ciscoasa(config)#access-list name [line number] [extended] {permit | deny} protocol
source_IP_address source_netmask [operator source_port] destination_IP_address
destination_netmask [operator destination_port] [log [[disable | default] | [level]] [interval seconds]] [time-range name] [inactive]
Here's an example:
asa(config)# access-list demo1 permit tcp 10.1.0.0 255.255.255.0 any eq www
asa(config)# access-list demo1 permit tcp 10.1.0.0 255.255.255.0 any eq 443
asa(config)# show access-list demo1
access-list demo1; 2 elements
access-list demo1 line 1 extended permit tcp 10.1.0.0 255.255.255.0 any eq www
access-list demo1 line 2 extended permit tcp 10.1.0.0 255.255.255.0 any eq https
In the above example, an ACL called "demo1" is created in which the first ACE permits TCP traffic originating on the 10.1.0.0 subnet to go to any destination IP address with the destination port of 80 (www). In the second ACE, the same traffic flow is permitted for destination port 443. Notice in the output of the show access-list that line numbers are displayed and the extended parameter is also included, even though neither was included in the configuration statements.
You can deactivate an ACE without deleting it by appending the inactive option to the end of the line.
As with Cisco routers, there is an implicit "deny any" at the end of every ACL. Any traffic that is not explicitly permitted is implicitly denied.
**Editing ACLs and ACEs**
New ACEs are appended to the end of the ACL. If you want, however, to insert the new ACE at a particular location within the ACL, you can add the line number parameter to the ACE:
asa04(config)# access-list demo1 line 1 deny tcp host 10.1.0.2 any eq www
asa04(config)# show access-list demo1
access-list demo1; 3 elements
access-list demo1 line 1 extended deny tcp host 10.1.0.2 any eq www
access-list demo1 line 2 extended permit tcp 10.1.0.0 255.255.255.0 any eq www
access-list demo1 line 3 extended permit tcp 10.1.0.0 255.255.255.0 any eq https
Notice in the first line of the example above that an ACE is added at line one in the ACL. Notice in the output from the show access-list demo1 command that the new entry is added in the first position in the ACL and the former first entry becomes line number two.
You can remove an ACE from an ACL by preceding the ACE configuration statement with the modifier no, as in the following example:
Asa04(config)#no access-list demo1 deny tcp host 10.10.2 any eq www
In my next article, I'll show you how to use time-ranges to apply access-control lists only at certain times and/or on certain days. I'll also show you how to use object-groups with access-control lists to simplify ACL management by grouping similar components such as IP addresses or protocols together.
Copyright (c) 2008 Don R. Crawley
Don R. Crawley, CCNA-certified, is president and chief technologist at soundtraining.net, the Seattle training firm specializing in business skills and technical training for IT professionals. He works with IT pros to enhance their work, lives, and careers. For more information about soundtraining.net's accelerated Cisco ASA training, visit here
Article Source: http://EzineArticles.com/?expert=Don_R._Crawley
https://unichrone.com/au/courses/it-security-governance/cism-certification-training/bathurst
ReplyDeletenice information. please visit this also.
Unichrone offers CISM Certification Training Course in Bathurst Australia by its most experienced CISM Certified Professional Trainer. This CISM Training in Bathurst will enable you to clear CISM exam with ease, and thereby, improve your employability. Certified Information Security Manager Training Course in Bathurst demonstrates relationship between an information security program and broader business goal objectives. The CISM Certification helps you gain an in-depth knowledge of the four CISM domains: security governance; risk management and compliance; security program development and management. The CISM® Certification endorses international security practices and acknowledges the professional who manages designs, and oversees and assesses an enterprise’s information security. The qualification differentiates you as having knowledge and experience in building and managing an information security program. CISM Certification Training in Bathurst Australia is not only an objective measure of excellence, but a globally recognized standard of achievement for security training. Unichrone provides comprehensive CISM Training in Bathurst Australia for participants who wish to gain expertise in defining the design, architecture, management and controls leading to a secure business environment. Individuals possessing this vendor neutral credential are high in demand by corporations all over the world who want to protect their organizations from a growing spurt of sophisticated cyber attacks.