Security is a hot topic in today's networks, and will continue to be for a long time to come. With that in mind, you must consider adding a Cisco security certification to your resume and firewall skills to your skill set.
It's quite a jump from the CCNA to the CCSP (Cisco Certified Security Professional), and Cisco has made that leap more manageable by adding Specialist certifications. These certifications can give quite a boost to both your resume and your skill set, and act as a great "stepping stone" to the CCSP.
At present, Cisco offers four VPN/Security certifications, those being Cisco Firewall Specialist, Cisco IPS Specialist, Cisco VPN Specialist, and Cisco VPN/Security Sales Specialist. Since every WAN engineer has contact with Cisco firewalls on a regular basis, we'll take a closer look at this popular certification first. (And those who want to be WAN engineers had better learn something about firewalls, too!)
At the writing of this article (October 21, 2005), Cisco is offering an option for each of the two exams you'll need to pass to earn this certification. For the first exam, you can take either the 642-551 SND (Securing Cisco Network Devices) or 642-501 SECUR (Securing Cisco IOS Networks). The final day to register for the SECUR exam is December 19, 2005.
For either, you'll need to be able to answer questions regarding the proper use of Cisco security devices; how to configure security on a Cisco switch and on a router, including syslog logging, AAA, ACLs, and security for router services and interfaces.
The choices for the second exam are the 642-522 SNPA (Securing Network with PIX and ASA) and 642-521 CSPFA. Topics for these exams include , IPSec, NAT, firewalls, AAA, and policy mapping. (As always, you should check for the latest exam blueprints at Cisco's website. Click "Learning And Events" on the main page, www.cisco.com).
The only prerequisite for this certification is that you must hold a valid CCNA certification.
As always, getting some hands-on experience is the best way to prepare for your Cisco exams. (Your employer is going to get a little upset if you practice your configs on his or her PIX. It would be a good idea to have a good lawyer, too.) There are online rack rental services that include Cisco security devices in their pods.
Cisco certifications are a great way to help protect your career as well as your network. The more you know, and the more varied your skills, the more valuable you are to your present and future employers. Use your CCNA as a foundation, and keep building on your skills!
Showing posts with label acl. Show all posts
Showing posts with label acl. Show all posts
Friday, December 26, 2008
Wednesday, December 24, 2008
Cisco CCNA Certification Exam Tutorial: Access List Details You Must Know!
To pass the CCNA exam, you have to be able to write and troubleshoot access lists. As you climb the ladder toward the CCNP and CCIE, you'll see more and more uses for ACLs. Therefore, you had better know the basics!
The use of "host" and "any" confuses some newcomers to ACLs, so let's take a look at that first.
It is acceptable to configure a wildcard mask of all ones or all zeroes. A wildcard mask of 0.0.0.0 means the address specified in the ACL line must be matched exactly a wildcard mask of 255.255.255.255 means that all addresses will match the line.
Wildcard masks have the option of using the word host to represent a wildcard mask of 0.0.0.0. Consider a configuration where only packets from IP source 10.1.1.1 should be allowed and all other packets denied. The following ACLs both do that.
R3#conf t
R3(config)#access-list 6 permit 10.1.1.1 0.0.0.0
R3(config)#conf t
R3(config)#access-list 7 permit host 10.1.1.1
The keyword any can be used to represent a wildcard mask of 255.255.255.255.
R3(config)#access-list 15 permit any
Another often overlooked detail is the order of the lines in an ACL. Even in a two- or three-line ACL, the order of the lines in an ACL is vital.
Consider a situation where packets sourced from 172.18.18.0 /24 will be denied, but all others will be permitted. The following ACL would do that.
R3#conf t
R3(config)#access-list 15 deny 172.18.18.0 0.0.0.255
R3(config)#access-list 15 permit any
The previous example also illustrates the importance of configuring the ACL with the lines in the correct order to get the desired results. What would be the result if the lines were reversed?
R3#conf t
R3(config)#access-list 15 permit any
R3(config)#access-list 15 deny 172.18.18.0 0.0.0.255
If the lines were reversed, traffic from 172.18.18.0 /24 would be matched against the first line of the ACL. The first line is “permit any", meaning all traffic is permitted. The traffic from 172.18.18.0/24 matches that line, the traffic is permitted, and the ACL stops running. The statement denying the traffic from 172.18.18.0 is never run.
The key to writing and troubleshoot access lists is to take just an extra moment to read it over and make sure it's going to do what you intend it to do. It's better to realize your mistake on paper instead of once the ACL's been applied to an interface!
The use of "host" and "any" confuses some newcomers to ACLs, so let's take a look at that first.
It is acceptable to configure a wildcard mask of all ones or all zeroes. A wildcard mask of 0.0.0.0 means the address specified in the ACL line must be matched exactly a wildcard mask of 255.255.255.255 means that all addresses will match the line.
Wildcard masks have the option of using the word host to represent a wildcard mask of 0.0.0.0. Consider a configuration where only packets from IP source 10.1.1.1 should be allowed and all other packets denied. The following ACLs both do that.
R3#conf t
R3(config)#access-list 6 permit 10.1.1.1 0.0.0.0
R3(config)#conf t
R3(config)#access-list 7 permit host 10.1.1.1
The keyword any can be used to represent a wildcard mask of 255.255.255.255.
R3(config)#access-list 15 permit any
Another often overlooked detail is the order of the lines in an ACL. Even in a two- or three-line ACL, the order of the lines in an ACL is vital.
Consider a situation where packets sourced from 172.18.18.0 /24 will be denied, but all others will be permitted. The following ACL would do that.
R3#conf t
R3(config)#access-list 15 deny 172.18.18.0 0.0.0.255
R3(config)#access-list 15 permit any
The previous example also illustrates the importance of configuring the ACL with the lines in the correct order to get the desired results. What would be the result if the lines were reversed?
R3#conf t
R3(config)#access-list 15 permit any
R3(config)#access-list 15 deny 172.18.18.0 0.0.0.255
If the lines were reversed, traffic from 172.18.18.0 /24 would be matched against the first line of the ACL. The first line is “permit any", meaning all traffic is permitted. The traffic from 172.18.18.0/24 matches that line, the traffic is permitted, and the ACL stops running. The statement denying the traffic from 172.18.18.0 is never run.
The key to writing and troubleshoot access lists is to take just an extra moment to read it over and make sure it's going to do what you intend it to do. It's better to realize your mistake on paper instead of once the ACL's been applied to an interface!
Subscribe to:
Posts (Atom)