My next topic for writing up my notes is the security section.
For this post and all posts following I will be using the CCIE blueprint from Cisco here (you may need CCO access to access that document but that is free).
My reasoning for structuring it like this is to make it easier both myself to reference and hopefully someone else will find it easier as well.
Some of the information is a little basic and will have been covered at CCNA and CCNP levels but seen as CCIE doesn’t actually have any pre-requisites I thought it best not to leave any stone unturned.
Implement access lists
There are two types of access lists that can be used on Cisco platforms; the standard access list and the extended access list.
Standard access lists are a little basic in their use and can only match on the source address of the traffic you are matching.
Extended access lists differ from standard access lists in that they can not only match on both source and destination addresses but they can also match a whole plethora of other things such as L4 src/dst port number, DSCP marking, packet size etc.
Just like there are two different types of access list there are also two different methods of configuring them.
Firstly there is the numbered access-list method (which is the older method) where depending on what number you give to your ACL will depend on what type it is:
1-99 - Standard access list 100-199 - Extended access list 1300-1999 - Expanded standard access list (useful if you have >100 standard ACL's) 2000-2699 - Expanded extended access list (useful if you have >100 extended ACL's)
There is also the named access-list method in which the name that you give to the access list is completely agnostic to type of ACL it is. When you are using named access-lists you have to explicitly tell the CLI which type of access-list you are creating.
Things to remember about all ACL’s: – All ACL’s end with an implicit deny all – Order of statements in the ACL is critical (they match on a top down approach)
To create a numbered ACL you do as follows:
R1(config)#access-list ? <1-99> IP standard access list <100-199> IP extended access list <1300-1999> IP standard access list (expanded range) <2000-2699> IP extended access list (expanded range)
Once you are in numbered access-list mode it depends on which type it is to what options you will have, as has already been mentioned standard access-lists can only match on one IP/subnet tuple where as the extended type can match on many more things.
R1(config)#access-list 50 permit 192.168.1.0 0.0.0.255 ? log Log matches against this entry <cr>
R1(config)#access-list 150 permit tcp 192.168.1.0 0.0.0.255 host 192.168.2.1 eq www ? ack Match on the ACK bit dscp Match packets with given dscp value established Match established connections fin Match on the FIN bit log Log matches against this entry log-input Log matches against this entry, including input interface option Match packets with given IP Options value precedence Match packets with given precedence value psh Match on the PSH bit rst Match on the RST bit syn Match on the SYN bit time-range Specify a time-range tos Match packets with given TOS value urg Match on the URG bit <cr>
As you can see above you can be a lot more granular with the options when you are using extended ACL’s.
When using named access-list mode the options are all the same only the way that you create them is a little different:
R1(config)#ip access-list standard STANDARD_ACL R1(config-std-nacl)#permit 192.168.1.0 0.0.0.255 R1(config)#ip access-list extended EXTENDED_ACL R1(config-ext-nacl)#permit tcp 192.168.1.0 0.0.0.255 host 192.168.2.1 eq www
CBAC or Context-Based access control is a feature in the firewall feature set of IOS routers that allows for ACL’s to be dynamically modified to allow return traffic.
For CBAC to work properly you have to have an ACL applied in the opposite direction than the CBAC inspection rule to block the traffic you are going to allow with CBAC, this sounds like quite a un-nerving thing at first but hopefully the info below should sum it up pretty well.
For the below example we will first create an ACL to block all traffic (but still allow routing traffic, as this is not being inspected) and apply in in the inbound direction of our ‘outside’ interface.
Once we have created this ACL we will also create our CBAC rulebase and apply it in the opposite direction to the above ACL, therefore completing the requirements for CBAC to work.
You will notice that for the icmp rule I also add the ‘router-traffic’ option, what this means is that traffic that is originated from the router will also be inspected, as default only traffic that passes through the router is considered for inspection.
R1(config)#ip access-list extended CBAC_ACL R1(config-ext-nacl)#permit ospf any any R1(config-ext-nacl)#permit pim any any R1(config-ext-nacl)#deny ip any any log R1(config-ext-nacl)#exit R1(config)# R1(config)#ip inspect name CBAC tcp router-traffic R1(config)#ip inspect name CBAC icmp router-traffic R1(config)#ip inspect name CBAC ftp R1(config)# R1(config)#int f0/0 R1(config-if)#ip access-group CBAC_ACL in R1(config-if)#ip inspect CBAC out
Now that the above is applied we will be able to ping from R1->R2 as the CBAC inspection will allow the ICMP echo-reply’s. However any traffic that is not originated by R1 (for instance R2 pinging R1) would still be blocked as there will be no rule dynamically added by CBAC for it.
### Ping from R1 to R2 ### R1#ping 10.0.1.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.1.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 16/19/28 ms R1#sh ip inspect sessions Established Sessions Session 67F0C51C (10.10.1.1:8)=>(10.0.1.2:0) icmp SIS_OPEN ### Ping from R2 to R1 R2#ping 10.0.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.1.1, timeout is 2 seconds: U.U.U Success rate is 0 percent (0/5)
What CBAC Does
- Traffic filtering
- Traffic inspection
- Alerts and audit trails
- Intrusion prevention
What CBAC Doesn’t DO
CBAC does not provide a method of filtering all types of traffic, only a limited amount of protocols are supported by CBAC, for protocols that are not supported they will need to be handled normally using extended ACL’s to permit/deny the traffic.
Once again with these notes, in places they are a little bare and there are far more features to CBAC than I have covered in this post, for more information please take a look at the Cisco doc pages here.
Implement Zone Based Firewall
Zone based firewall was a feature that was originally introduced in 12.4(6)T and allowed for the pervious firewall-like behaviour of CBAC/ACL’s to be improved further.
ZBFW allows an IOS device to behave more like a regular PIX/ASA firewall in that it utilises zones.
By default traffic is allowed to pass between interfaces that are in the same zone but traffic is NOT allowed to pass between different zones or between interfaces that are in zones to interfaces that are not in a zone.
ZBFW uses a structure similar to that of the MQC to define class and policy maps using the new ‘inspect’ type.
The steps to setting up ZBFW are as follows:
- Create your zones (inside, outside, DMZ etc.)
- Decide how traffic will flow on the device and create zone-pairs for these flows.
- Create class-maps to identify the inter-zone traffic that will be inspected by the firewall.
- Assign policies to the traffic by creating policy maps and associating class maps with them.
- Assign the aforementioned policy map to a specific zone-pair.
- Assign interfaces to a zone, interfaces are only allowed to be a member in one zone at a time.
To create zones and zone-pairs follow the following steps:
R1(config)# zone security inside R1(config-sec-zone)# description inside zone R1(config)# zone security outside R1(config-sec-zone)# description outside zone R1(config)# zone-pair security inside_out source inside destination outside R1(config)# zone-pair security outside_in source outside destination inside
By default when you create ZBFW policy maps there is a class-default (like other MQC based policies) however all traffic in this class is dropped and therefore you need to ensure that all traffic that you want to be allowed is allowed.
When creating class-maps or policy-maps for use by ZBFW you need to use the ‘type inspect’ option when creating them:
R1(config)# class-map type inspect HTTP_TRAFFIC R1(config)# policy-map type inspect inside_out
To assign a ZBFW policy map to a zone-pair it is fairly similar to applying a QoS policy, to do this follow the below:
R1(config)# zone-pair security inside_out source inside destination outside R1(config-sec-zone-pair)# service-policy type inspect inside_out
To assign an interface to a zone do the following:
R1(config)# interface Fa0/0 R1(config-if)# zone-member security inside
As with other topics in these notes there are more details on the Cisco documentation pages here.
Implement Unicast Reverse Path Forwarding (uRPF)
Unicast Reverse Path Forwarding (uRPF) is a feature that can help protect the network against spoofed or malformed IP packets.
Much like the similarly named RPF check in Multicast forwarding the router implements this feature by checking an incoming packet against the unicast routing table (FIB).
Cisco Express Forwarding (CEF) is required for uRPF as it uses the FIB to carry out its check.
When a packet comes into the router on an interface with uRPF enabled it takes the source IP address of the packet and compares it to the FIB entry for that IP. If the incoming interface and interface listed in the FIB do not match then the packet will be dropped.
The uRPF feature is enabled using the
ip verify unicast reverse-path interface configuration command.
Implement IP Source Guard
IP source guard is usually used alongside another feature, DHCP snooping.
The below is an extract from the Cisco document here.
IP source guard is a security feature that restricts IP traffic on nonrouted, Layer 2 interfaces by filtering traffic based on the DHCP snooping binding database and on manually configured IP source bindings. You can use IP source guard to prevent traffic attacks caused when a host tries to use the IP address of its neighbour.
You can enable IP source guard when DHCP snooping is enabled on an untrusted interface. After IP source guard is enabled on an interface, the switch blocks all IP traffic received on the interface, except for DHCP packets allowed by DHCP snooping. A port access control list (ACL) is applied to the interface. The port ACL allows only IP traffic with a source IP address in the IP source binding table and denies all other traffic.
The IP source binding table has bindings that are learned by DHCP snooping or are manually configured (static IP source bindings). An entry in this table has an IP address, its associated MAC address, and its associated VLAN number. The switch uses the IP source binding table only when IP source guard is enabled.
IP source guard is supported only on Layer 2 ports, including access and trunk ports.You can configure IP source guard with source IP address filtering or with source IP and MAC address filtering.
AAA stands for Authentication, Authorisation and Accounting but for now we are only really bothered about the first of the A’s Authentication.
When connecting to a device there are many different ways that you can authenticate to it, you can use no password, you could use a line password, you could use a local username database or you could use an external server such as RADIUS or TACACS+.
One of the major plus points for using a centralised solution such as RADIUS or TACACS+ is that if you have a large deployment of devices there is one central place that all usernames/passwords are stored and therefore easier to maintain for additions/removals.
The two technologies that IOS devices support for external authentication are RADIUS and TACACS+ (as mentioned earlier), both are fairly similar in their use however there are a few things that are different between them:
|Scope of encryption (what is encrypted)||Password only||Entire payload|
|Layer 4 protocol||UDP||TCP|
|Well-known port / IOS default port||1812/1645||49/49|
|Standards based or proprietary||RFC 2865||Proprietary|
Below I am enabling the use of AAA and authenticating to a TACACS+ server, in-case of a failure in the TACACS+ server the device will fallback to using its own local database:
R1(config)#aaa new-model R1(config)#username david secret p4ssw0rd R1(config)#tacacs-server host 192.168.1.10 R1(config)#tacacs-server key s3cre3tk3y R1(config)#aaa authentication login default group tacacs+ local R1(config)#aaa authentication enable default group tacacs+ enable
Implement Control Plane Policing (CoPP)
Control Plane Policiing (CoPP) is used for protecting and ensuring that the control plane of a Cisco device is not overloaded with traffic that it does not need.
The control plane is where the ‘network’ is run from, it is where the routing protocol processes live, it is where BPDU’s for STP are processed and it is where all the management process also live (SSH, Telnet, SNMP, AAA).
All you need is one malicious device (deliberate or accidental) to bring down the control plane on the device, if this happens then everything will be brought down.
When using CoPP you configure it using the MQC (as used in QoS) to define class and policy maps to classify the different types of traffic and what to do with them.
With CoPP class-maps you can only match on IP precedence markings, DSCP markings or ACL’s. You cannot use anything like NBAR as you can with QoS class-maps.
As with when you are configuring a QoS policy you do not want to create too many class-maps as this could be detrimental to your goal, at the same time you do not want to create too little class-maps as this could mean that you end up grouping too many things and locking yourself out of the router.
For L2 traffic and CoPP the only type of traffic that can be explicitly matched in a class-map is ARP, all other L2 traffic such as BPDU’s are handled by the class-default class.
R1(config)#ip access-list extended CoPP_MANAGEMENT R1(config-ext-nacl)#permit tcp any eq 22 any established R1(config-ext-nacl)#permit tcp any any eq 22 R1(config-ext-nacl)#permit tcp any eq telnet any established R1(config-ext-nacl)#permit tcp any any eq telnet R1(config)#ip access-list extended CoPP_ROUTING R1(config-ext-nacl)#permit tcp any eq bgp any established R1(config-ext-nacl)#permit tcp any any eq bgp R1(config-ext-nacl)#permit ospf any any R1(config-ext-nacl)#permit eigrp any any R1(config)#class-map CoPP_ROUTING R1(config-cmap)#match access-group name CoPP_ROUTING R1(config)#class-map CoPP_MANAGEMENT R1(config-cmap)#match access-group name CoPP_MANAGEMENT R1(config-cmap)#policy-map CoPP R1(config-pmap)#class CoPP_MANAGEMENT R1(config-pmap-c)#police cir 10000 R1(config-pmap-c-police)#conform-action transmit R1(config-pmap-c-police)#exceed-action drop R1(config-pmap)#class CoPP_ROUTING R1(config-pmap-c)#police cir 100000 R1(config-pmap-c-police)#conform-action transmit R1(config-pmap-c-police)#exceed-action transmit R1(config)#control-plane R1(config-cp)#service-policy input CoPP *Nov 23 14:13:20.846: %CP-5-FEATURE: Control-plane Policing feature enabled on Control plane aggregate path R1#sh policy-map control-plane Control Plane Service-policy input: CoPP Class-map: CoPP_MANAGEMENT (match-all) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: access-group name CoPP_MANAGEMENT police: cir 10000 bps, bc 1500 bytes, be 1500 bytes conformed 0 packets, 0 bytes; actions: transmit exceeded 0 packets, 0 bytes; actions: drop violated 0 packets, 0 bytes; actions: drop conformed 0 bps, exceed 0 bps, violate 0 bps Class-map: CoPP_ROUTING (match-all) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: access-group name CoPP_ROUTING police: cir 100000 bps, bc 3125 bytes, be 1500 bytes conformed 0 packets, 0 bytes; actions: transmit exceeded 0 packets, 0 bytes; actions: transmit violated 0 packets, 0 bytes; actions: transmit conformed 0 bps, exceed 0 bps, violate 0 bps Class-map: class-default (match-any) 24 packets, 2580 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: any
Implement Cisco IOS Intrusion Prevention System (IPS)
IPS (Intrusion Prevention System) is a feature that you can enable on Cisco routers. Once enabled it acts as an inline IPS device and inspects every packet that passes through the router to a set of signatures that it has stored in its memory.
IPS allows routers to scan all packets and hopefully stop worms, virii etc before they spread further, this feature is most readily used in small branche offices where the traffic level is not enough to warrant a dedicated IPS device.
The amount of IPS signatures that a device can store is only dependant on the amount of memory that the device has available.
New signature databases can be obtained from Cisco to those who have a valid service agreement for the service.
Whilst (as usual) there are a lot more features to IPS than what I have brushed over here, for more information please check out the Cisco documentation page here.
Due to the extra load on the devices CPU you should always disable/retire any signatures that aren’t needed.
R1(config)#ip ips signature-category R1(config-ips-category)#category all R1(config-ips-category-action)#retired true R1(config-ips-category-action)#exit R1(config-ips-category)#category ios_ips basic R1(config-ips-category-action)#retired false R1#mkdir flash:IPS Create directory filename [IPS]? Created dir flash:ipsR1 R1(config)#ip ips name CCIE R1(config)#ip ips config location flash:IPS R1(config)#int Fa0/1 R1(config-if)#ip ips CCIE outbound
Implement Secure Shell (SSH)
in order to use SSH you need a K9 image which is capable of encryption/decryption
Telnet has been around since time begun (I believe archaeologists have found proof that dinosaurs originally used it!) and as such has a few flaws, the biggest of those is that all telnet traffic is transmitted in clear-text, meaning that anyone that happens to be lurking around and sniffing up your 1’s and 0’s will be able to see exactly what you are doing, including passwords!
SSH is a nice alternative to Telnet which encrypts all traffic to/from the server and therefore is a lot more secure.
As default all IOS powered devices (that have a K9 image) are able to be used as SSH clients however to be enabled as an SSH server you first have to jump through a few hoops:
- Configure a hostname on the device (if you haven’t already!)
- Configure a domain name on the device
- Generate the RSA key pairs for the device (which is why you needed steps 1 & 2)
- Create a local username/password to authenticate the SSH users (or set up some other AAA server)
As default IOS will enable SSH version 1 when you enable SSH, unfortunately this older version of SSH is known to have its fair share of bugs and therefore Cisco recommend that you enable SSHv2.
Below is an example of how to enable SSH on a router:
Router(config)#hostname R1 R1(config)#ip domain-name CCIELAB R1(config)#crypto key generate rsa The name for the keys will be: R1.CCIELAB Choose the size of the key modulus in the range of 360 to 2048 for your General Purpose Keys. Choosing a key modulus greater than 512 may take a few minutes. How many bits in the modulus : 1024 % Generating 1024 bit RSA keys, keys will be non-exportable...[OK] R1(config)# *Nov 21 22:52:51.131: %SSH-5-ENABLED: SSH 1.99 has been enabled R1(config)#username david secret p4ssw0rd R1(config)# ## Now enable SSHv2 ## R1(config)#ip ssh version 2
802.1x or Dot1x is a feature that can be used on switches in order to secure switchports from unauthorised use.
Whilst not usually use in server facing or secure ports it would be considered useful in public ports or ports that are not in a secure area.
When a switchport is in an unauthorised state the only traffic that is allowed to pass over it is EAPOL (used for the dot1x authentication), CDP and STP. Once the port has fully authenticated other traffic will be allowed as normal.
Switches utilise a protocol called EAPOL to communicate with the end-user device and then a protocol such as RADIUS to speak to the central authentication server.
Ports can be in a number of different ‘modes’ in terms of dot1x:
force-authorized ? disables 802.1x authentication and causes the port to change to the authorised state without any authentication exchange required. The port sends and receives normal traffic without 802.1x-based authentication of the client. This is the default setting.
force-unauthorized ? causes the port to remain in the unauthorised state, ignoring all attempts by the client to authenticate. The switch cannot provide authentication services to the client through the port.
auto ? enables 802.1x authentication and causes the port to begin in the unauthorised state, allowing only EAPOL frames to be sent and received through the port. The authentication process begins when the link state of the port changes from down to up or when an EAPOL-start frame is received. The switch requests the identity of the client and begins relaying authentication messages between the client and the authentication server. Each client attempting to access the network is uniquely identified by the switch by using the client MAC address
There are several steps that are needed in order to rollout dot1x, below is a config excerpt (the below assumes you have already configured your RADIUS server):
SW1(config)#aaa new-model SW1(config)#aaa authentication dot1x default group radius SW1(config)#dot1x system-auth-control SW1(config)# SW1(config)#interface Fa0/1 SW1(config)#dot1x port-control auto
As default all ports are in the force-authorized unless otherwise instructed by the per-interface config (above).
There is a lot more information on the nitty gritty of dot1x and the many other features that it contains (such as dynamic VLAN assignment) over on the Cisco documentation website here.
In NAT addresses are considered Global or Local:
- Global – seen on outside network
- Local – seen on local network
In NAT when you are looking at translation tables etc you need to know and understand the following address types:
- Inside Local – Address assigned to a host inside the network (usually an RFC1918 address)
- Inside Global – Non-private address that represents the inside host
- Outside Local – IP address of an outside host as it appears on the inside network
- Outside Global – IP address assigned to a host on the outside network
In the CCIE Written exam we do not need to know a LOT of detail about NAT or any of the very complex solutions it can create, we only need to know about static NAT translations (which are by far the easiest!).
When configuring NAT you define the interfaces that are classed as ‘inside’ and ‘outside’, this is so that when you configure the actual translations the IOS NAT engine knows which addresses to translate and in which direction etc.
R2(config)#int f0/0 R2(config-if)#ip nat inside ## Define the 'inside' interface R2(config-if)#int s1/0 R2(config-if)#ip nat outside ## Define the 'outside' interface R2(config-if)#exit R2(config)#ip nat inside source static 10.10.1.1 172.16.1.1 ## Configured so that 10.10.1.1 appears as 172.16.1.1 to the outside world R2(config)#end R2#sh ip nat translations Pro Inside global Inside local Outside local Outside global --- 172.16.1.1 10.10.1.1 --- ---
Port address translation (PAT)
PAT is used because lets face it, there are a lot more private hosts that need internet access than there actually are public IP’s.
If you were just using regular NAT then for each inside host that needed external access you would need a public IP. This kind of negates the main functionality of NAT (conserving IP space).
Instead of just translating the IP addresses to/from global addresses PAT also uses port numbers and then keeps a state table to know which port on the external facing interface matches up to which port on an internal host. This way multiple hosts can appear to come from the same IP address.
PAT is configured by using the ‘overload’ keyword when configuring NAT but as mentioned above is not needed/used in the CCIE written exam.