Explain the methods of network access security. This chapter describes techniques for security network access, including access control lists, tunneling, and encryption and remote access. We cover access lists and securing network access in great detail in our Cisco CCNA course.

Back to book index.

Access Control Lists

Access control lists (ACLs) are mechanisms available on different network devices (e.g., routers, switches, firewalls, servers, etc.) and are used to restrict access based on a series of parameters:

• Source MAC address
• Destination MAC address
• Source IP address
• Destination IP address
• Port numbers or services
• Time of day

ACLs allow you to assign permissions to a particular object in order to restrict access on the network or within a specific network area. One common way of restricting network access in wireless environments is based on the MAC address (this is also known as MAC filtering). One downside to this approach is that the devices you want to restrict access to must be on your local subnet; otherwise, the Layer 2 addresses will be irrelevant (i.e., they are unknown).

ACLs on Cisco Devices

Cisco devices are commonly used in modern networks so we will analyze the way ACLs are implemented in these solutions and also provide a few examples. Although we are presenting a few things that are particular to Cisco IOS, the general concepts are valid for all network equipment providers.

The three main types of ACLs available in Cisco IOS are as follows:

• Standard numbered
• Extended numbered
• Standard or extended named

Standard numbered ACLs are the most basic form of ACL you can apply to a router. While they are the easiest to configure, they have the most limited range of filters available. They can only filter based on the source IP address or network. The way to recognize a standard ACL is by the number that precedes the configuration lines, which will be from 1 to 99 (there is an expanded range of 1300 to 1999).

Extended numbered ACLs allow far more granularity but they can be trickier to configure and troubleshoot. They can filter a destination or source IP address or network, a protocol type, and a port number. The numbers you can use to configure extended ACLs are 100 to 199, inclusive (there is an expanded range of 2000 to 2699).

Named ACLs allow you to associate a list of filters with a name rather than a number. This makes them easier to identify in router configurations. Named ACLs can actually be either extended or standard; you choose which at the initial configuration line of the ACL.

The most important ACL rules include the following:

• Use only one ACL per interface per direction (per protocol)
• The lines are processed top-down
• There is an implicit “deny all” at the bottom of every ACL
• The router cannot filter self-generated traffic
• You can reuse the same ACL on multiple interfaces

Wildcard masks are essential to understand when configuring ACLs because they are used as part of the command line configuration in ACLs. They exist because there has to be a way to tell the router which parts of an IP address or network address you want to match.

This matching is performed at the binary level, but you can easily configure wildcard masks using the same notation you use for subnet masks. A binary 1 tells the router to ignore the digit and a 0 means to match the digit.

The easy way to perform wildcard masking is simply to ensure that you add a number to the subnet mask that will give you a total of 255. For example, if your subnet mask in one octet was 192, you would add 63 for a total of 255. If it was 255, you would add 0. Take a look at the examples below:

Subnet	255	255	255	192
Wildcard	0	0	0	63
Equals	255	255	255	255

 

Subnet	255	255	224	0
Wildcard	0	0	31	255
Equals	255	255	255	255

 

Subnet	255	128	0	0
Wildcard	0	127	255	255
Equals	255	255	255	255

You need to enter a wildcard mask if you want your ACL to match a subnet or an entire network. For example, if you wanted to match 172.20.1.0 255.255.224.0, you would enter the following:

Router(config)#access-list 1 permit 172.20.1.0 0.0.31.255

Matching subnet 192.200.1.0 255.255.255.192 would require the following:

Router(config)#access-list 1 permit 192.200.1.0 0.0.0.63

The same principle applies when you have a network with two host bits, as you will need to enter an ACL to match these. For example, matching subnet 192.168.1.0 255.255.255.252 or /30, you will need to enter the following:

Router(config)#access-list 1 permit 192.168.1.0 0.0.0.3

This will match hosts 1 and 2 on the 192.168.1.0 network. If you wanted to match hosts 5 and 6 on the 192.168.1.4/30 network, you would enter the following:

Router(config)#access-list 1 permit 192.168.1.4 0.0.0.3

Standard ACLs

Standard numbered ACLs are the easiest to configure, so this is the best place to start. Standard ACLs can only filter based on a source network or IP address. The ACL would permit or deny this source address:

Router(config)#access-list 1 permit host 172.16.1.1

Router(config)#access-list 1 permit host 192.168.1.1

Router(config)#access-list 1 permit 10.1.0.0 0.0.255.255

The ACL above (numbered 1) will permit traffic coming from two hosts (172.16.1.1 and 192.168.1.1), as well as traffic coming from the 10.1.0.0/16 network. Remember that there will be an implicit “deny all” at the end of this list, so all other traffic will be blocked.

Extended ACLs

Far more granularity is built into extended numbered ACLs; however, this makes them trickier to configure. You can filter source or destination networks, ports, protocols, and services. Generally, you can look at the configuration syntax for extended ACLs, as follows:

access list # permit/deny {service/protocol} {source network/IP} {source port#}{destination network/IP} {destination port#}

An extended ACL example, featuring e-mail, file servers, and Web, would be as follows:

access-list 100 permit tcp host 172.16.1.1 host 172.20.1.1 eq smtp

access-list 100 permit tcp 10.1.0.0 0.0.255.255 host 172.30.1.1 eq ftp

access-list 100 permit tcp host 192.168.1.1 host 172.40.1.1 eq www

ACL 100 above permits SMTP traffic going from 172.16.1.1 to 172.20.1.1, FTP traffic going from 10.1.0.0/16 to 172.30.1.1, and Web traffic going from 192.168.1.1 to 172.40.1.1.

Or, it could be as follows:

access-list 102 permit tcp any host 172.30.1.1 eq ftp established

The [established] keyword tells the router only to permit the traffic if it was originated by hosts on the inside. The three-way handshake flags (ACK or RST bit) will indicate this.

Named ACLs

Unlike numbered ACLs, named ACLs can be easily identified based on their descriptive name, and this is useful especially in large configurations. These ACLs were introduced to add flexibility and ease of management. Named ACLs can be considered more of a configuration enhancement, as they do not modify the core ACL structure (they just modify the way we refer to an ACL).

The syntax is similar to the numbered ACLs case, with the major difference of using names instead of numbers to identify ACLs. Just like in the case with numbered ACLs, you can configure standard or extended named ACLs.

Another difference when configuring named ACLs is that you always have to use the ip access-list command, unlike the case with numbered ACLs, where you could also use the simple access-list command.

Router(config)#access-list ?

<1-99>            IP standard access list

<100-199>         IP extended access list

<1100-1199>       Extended 48-bit MAC address access list

<1300-1999>       IP standard access list (expanded range)

<200-299>         Protocol type-code access list

<2000-2699>       IP extended access list (expanded range)

<700-799>         48-bit MAC address access list

dynamic-extended  Extend the dynamic ACL absolute timer

rate-limit        Simple rate-limit specific access list

Router(config)#ip access-list ?

extended    Extended Access List

log-update  Control access list log updates

logging     Control access list logging

resequence  Resequence Access List

standard    Standard Access List

 

R1(config)#ip access-list standard ?

<1-99>       Standard IP access-list number

<1300-1999>  Standard IP access-list number (expanded range)

  WORD         Access-list name

 

R1(config)#ip access-list extended ?

<100-199>    Extended IP access-list number

<2000-2699>  Extended IP access-list number (expanded range)

  WORD         Access-list name

Named ACLs have a slightly different syntax than the other types of ACLs do (i.e., standard numbered and extended numbered). You can also edit live named ACLs (and numbered in the latest IOS releases), which is a useful feature. You simply need to tell the router that you want to configure a named ACL, and whether you want it to be standard or extended.

When creating a named ACL using the ip access-list command, Cisco IOS will place you in the ACL configuration mode where you can enter or remove ACL entries (i.e., denied or permitted access conditions).

Router(config)#ip access-list extended BlockWEB

Router(config-ext-nacl)#?

Ext Access List configuration commands:

<1-2147483647>  Sequence Number

default         Set a command to its defaults

deny            Specify packets to reject

dynamic         Specify a DYNAMIC list of PERMITs or DENYs

evaluate        Evaluate an access list

exit            Exit from access-list configuration mode

no              Negate a command or set its defaults

permit          Specify packets to forward

remark          Access list entry comment

Router(config-ext-nacl)#deny tcp any any eq 80

Router(config-ext-nacl)#permit ip any any

Named ACL verification can be performed using the following commands:

• show ip access-lists: shows all ACLs created on the device
• show ip access-lists <acl_name>: shows a particular named ACL

Router(config)#do show ip access-lists

Standard IP access list test

30 permit 10.1.1.1

20 permit 192.168.1.1

15 permit 172.20.1.1

10 permit 172.16.1.1

Applying ACLs

To come into effect, you must apply your ACL to an interface either in the incoming (in) or outgoing (out) direction. This is performed using the ip access-group command.

Router(config)#int fast0/0

Router(config-if)#ip access-group 101 in

Router(config-if)#ip access-group 102 out

ACL Sequence Numbers

With IOS 12.4 onward, you can see that Cisco IOS adds sequence numbers to each ACL entry. Now you can create an ACL and then remove a line from it.

Router(config)#ip access-list standard test

Router(config-std-nacl)#permit 172.16.1.1

Router(config-std-nacl)#permit 192.168.1.1

Router(config-std-nacl)#permit 10.1.1.1

Router(config-std-nacl)#

Router(config-std-nacl)#exit

Router(config)#exit

Router#

 

*Jun  6 07:38:14.155: %SYS-5-CONFIG_I: Configured from console by console access

Router#show ip access-lists

Standard IP access list test

30 permit 10.1.1.1

20 permit 192.168.1.1

10 permit 172.16.1.1

Note that the sequence numbers are not displayed in the router running configuration. In order to see them you have to issue a show access-list command.

Tunneling and Encryption

Modern networks allow communication of remote or mobile devices to enterprise resources to improve productivity. One of the challenges of using this approach is to ensure that you provide a secure connection from the external location to the internal network. Two techniques that allow you to achieve this are tunneling and encryption over the public Internet. Details about VPNs and VPN concentrators have been covered in Chapters 16 and 21.

Some of the protocols used to set up tunneling and encryption are:

• SSL
• PPTP
• L2TP
• IPSec

SSL VPN

A common way of setting up a secure communication is using the Secure Sockets Layer (SSL) protocol (TCP 443), which can set up a VPN tunnel between two points. Because this is a very common protocol to use, the associated port is not likely to be blocked at some point between the two points, so this is a reliable method of setting up VPN tunnels.

SSL VPN is usually configured between a client and a site, and from an end-user perspective it can function from a browser (any operating system) or from a VPN client. SSL VPN allows functionalities such as:

• User authentication
• Data encryption

SSL VPN is also referred to as Web-VPN and is basically a technology that provides remote access through a gateway that can offer many different features, access methods, group configurations, and group policies. End-users can access the gateway from a wide variety of end-points. SSL VPN access can be set up in the following modes:

• Clientless access
• Thin client (port forwarding) access
• Full tunnel access

Clientless mode involves the user accessing corporate resources through a Web browser that supports SSL certificates on different operating systems (Windows, Mac OS, or Linux). The user does not need to install any client software, as he has access to Web-enabled applications and file sharing services (using NFS or CIFS). The gateway will perform address and protocol conversion as well as perform content parsing and rewriting.

The thin client access method behaves differently than the clientless mode, in that it uses a Java applet and performs TCP port forwarding so you can use other services besides Web-enabled applications. You can also have TCP port forwarding with static port mapping to extend the application support beyond just Web-enabled applications. Finally, you can use SSH, Telnet, IMAP, POP3, and other protocols.

The full tunnel client mode offers extensive application support and user access by downloading a SSL VPN client. The VPN clients can be loaded through Java or ActiveX and they can operate in two modes:

• Users can install the client and run it in workstation memory for the lifetime of the session and then clear off the machine, for example, when using public workstations
• Users can install the VPN client permanently on a system, if they have administrative permissions

Full tunnel mode offers the most access of all the access methods because it supports all IP-based applications, not just TCP or HTTP as clientless mode does. This functions a lot like IPSec remote access VPN.

The next issue that must be analyzed involves the places that the VPN devices and firewalls will be installed. Unlike traditional designs, which included separate VPN and firewall devices, in modern networks the VPN concentrator and firewall are usually integrated into the same platform, like the ASA appliance from Cisco or other UTM devices from other vendors.

An issue security network engineers should think about is the IP addressing mechanisms to be used in a VPN solution. You can use statically configured IP pools on devices or you can leverage DHCP services, either inside the network or in a DMZ. When using DHCP, the recommended method is to associate a dedicated scope of DHCP addresses to the VPN concentrators.

Large enterprise organizations may want to use a RADIUS server or LDAP services to allow users single sign-on privileges. If the user device uses a clientless access method (via a Web browser), the VPN concentrator device will proxy ARP on behalf of all the local subnet IP addresses, so the client will receive the traffic from the headend interface IP.

PPTP

Another way of bringing up a VPN tunnel is to use the Point-to-Point Tunneling Protocol (PPTP). As opposed to SSL VPN, PPTP only creates the tunnel; it does not perform any type of encryption or decryption along with that. This means that using PPTP is not enough, as you also have to run some type of encryption protocol to secure the communication.

PPTP uses different authentication methods, such as:

• MS-CHAPv2 (Microsoft Challenge-Handshake Authentication Protocol): integrated into Windows
• EAP-TLS (Extensible Authentication Protocol-Transport Layer Security): offers both authentication and encryption

From an encryption standpoint, PPTP can be used together with Microsoft Point-to-Point Encryption (MPPE). PPTP is one of the simplest tunneling techniques, as it can be configured to work by providing just a username and password to create the tunnel. PPTP clients are integrated in most operating systems.

L2TP

Layer 2 Tunneling Protocol (L2TP) is a successor to PPTP and it uses UDP port 1701. Just like PP2P, L2TP can create the tunnel but it is often used together with other protocols to ensure data encryption. One of those protocols is IPSec.

L2TP is built into a lot of operating systems (both desktop and mobile) and is often used by service providers to provide endpoint connectivity.

IPSec

IPSec represents a suite of protocols working together to achieve different security features in IP networks. Virtual Private Networks provide connections between devices that do not literally share a physical cable. Using VPNs, networks look like they are connected but the connection between them is just logical in nature. IPSec ensures data protection on top of those specific logical connections.

IPSec helps protect the information that is transmitted through the VPN. VPNs with IPSec can be of two main varieties:

• Site-to-site VPNs
• Remote access VPNs (client-to-site)

Site-to-site VPNs provide a permanent secured connection between two locations. Remote access VPNs are used when the virtual link is not always on. This is a situation where an individual needs to transfer something for a short duration of time, up to the corporate headquarters, and then the user will disconnect. Remote access VPN technologies are similar to dial-on-demand technologies, like old circuit-based technologies that functioned only after a number was dialed. The remote access connection closes after it is used and it does not remain permanently open like a site-to-site connection.

IPSec is a security suite that allows for many different degrees of security to be designed and implemented. Some situations might require strict security features to be implemented, while other situations might require the security policies to be relaxed for various reasons. The most important security mechanisms provided by IPSec are as follows:

• Data origin authentication: ensures that the packet was sent by an authorized user
• Data integrity: ensures that the packet was not changed or manipulated in the transit path
• Data confidentiality: ensures that only the authorized users read the data so sensitive information is not compromised
• Anti-reply: protects against DoS attacks that send the same packet multiple times

The IPSec VPN tunnel is built in two phases:

• ISAKMP/IKE negotiation
• Data transmission using negotiated IPSec SA

The ISAKMP/IKE negotiation phase is not very secure and it represents an initial security phase in which details about how the data will be secured are discussed. The secure VPN tunnel is built after this initial phase. ISAKMP/IKE negotiation serves as a mechanism for transferring the IPSec SA (Security Associations, which are forms of agreements on different IKE/IPSec parameters) and is composed of two distinct phases:

• Phase 1: ISAKMP SA setup
• Phase 2: IPSec SA negotiation

ISAKMP (Internet Security Association and Key Management Protocol) and IKE (Internet Key Exchange) establish an initial secure negotiation channel used for the initial exchange of parameters. The ISAKMP/IKE goals include:

• Authentication of the parties and establishment of a secure negotiation channel (Phase 1, ISAKMP SA)
• Perform additional negotiation (Phase 1, including Xauth and mode configuration)
• Negotiate data protection parameters (Phase 2, IPSec SA)

In the first phase, ISAKMP uses a technology called Diffie-Hellman (DH), which can generate cryptographic keys to ensure that the communications are secure. Phase 1 can operate in two modes:

• Main mode
• Aggressive mode

Main mode takes longer to negotiate and hides the parties’ identities by performing the DH exchange ahead of time. The aggressive mode takes less time to negotiate but does not provide the same level of security as the main mode because it does not hide the parties’ identities. ISAKMP aggressive mode permits flexible authentication with pre-shared keys (e.g., Easy VPN).

The ISAKMP initial Phase 1 negotiation process provides several authentication mechanisms to verify the parties’ identities. These mechanisms offer different degrees of security, as follows:

• Pre-Shared Keys (PSK): Using this technology, hosts know the same key via an out-of-band messaging system. This is the least secure authentication mechanism.
• RSA signatures: Using this method, hosts trust a certificate authority for authentication. This is a much more secure mechanism than using PSK because a trusted third-party authority controls the process by verifying the identity of each party involved in the authentication process.
• RSA encrypted nonces (IOS only): This technology uses RSA keys to hash random numbers (nonces) and other values.

Once ISAKMP Phase 1 is completed, you have to decide how the data will actually be secured. ISAKMP SA determines how the secure negotiation channel will be established and the ISAKMP SA peers must agree on the following parameters:

• Authentication method: PSK (weak), RSA signatures (strong)
• Encryption type: DES (weak), 3DES (medium), AES (strong)
• Hash algorithm: MD5 (weak), SHA (strong)
• Diffie-Hellman group: 1, 2, or 5

After ISAKMP Phase 1 is completed, a secure communication channel exists between the IPSec peers and the IPSec SA can be created. ISAKMP Phase 2 can be implemented based on two different technologies:

• Authentication Header (AH)
• Encapsulated Security Payload (ESP)

AH is rarely used in modern networks because it can only perform authentication, without securing the data. On the other hand, the ESP approach uses both authentication and encryption and is the preferred method to be used in ISAKMP Phase 2.

When you design IPSec VPNs and provide all the criteria for Phase 1 and Phase 2, you must define a lifetime for the entire negotiation process. ISAKMP and IPSec SAs have a definable lifetime and when this expires, the processes at Phase 1 and Phase 2 will rerun. A shorter lifetime means that you have more security and more overhead, and a longer lifetime implies less security and less overhead. This is because if the process is alive for a long period of time, a possible attacker also has a lot of time to hack the connection (by solving the algorithms).

The IPSec SA re-keying process can also involve Perfect Forward Secrecy (PFS), which is a technology that allows the re-keying to take place while the IPSec tunnel is in place. The PFS mechanism adds extra CPU overhead and it is used to run additional DH exchanges so the IPSec SA keys are not derived from ISAKMP SA keys.

All the details covered above confirm that IPSec VPNs are based on a complex suite of technologies, and for each of these technology areas you need to design the appropriate level of security. You always need to balance things like the SA lifetime and the number of IPSec tunnels you create against the router’s ability to handle these resource-intensive processes. An important thing to remember is to always monitor the network devices to make sure that their resource utilization stays within normal limits.

Remote Access Technologies

When designing and implementing remote access services, you want to make sure that the network users will have transparent access to the network from wherever they are, just like when they are connected to the actual network. The users must reach the resources they are authorized to use just as they would from the enterprise campus.

In order to provide these services, the connection requirements must be carefully analyzed to make sure that they are fulfilled. Typical requirements include:

• VoIP support
• VPN support
• High volume traffic or low volume traffic
• Permanent connection (whether needed or not)
• Type of flows

Because remote access and VPN networks often use the public Internet or the PSTN as their carrier, you should be aware of possible spoofing (or masquerading) techniques that will allow an attacker to impersonate a legitimate client and gain remote access or VPN access through the enterprise network. The network becomes vulnerable to spoofing when the attacker is able to steal some credentials or to guess some authentication key. Another issue is compromising data confidentiality and integrity that can happen from both the central remote access module and the branch/remote offices, so the other side of the connection should be properly secured as well.

To secure remote access, you should carefully implement VPN technologies using dedicated equipment or software solutions that include advanced security mechanisms. Some of the most commonly used remote access protocols are:

• RAS
• PPP
• PPPoE
• RDP
• ICA
• SSH

Remote Access Service (RAS) is a legacy technology that was used by remote users to communicate to a central location using dial-up over PSTN lines. This was implemented either in hardware or software that could function as an RAS server. RAS was a term created by Microsoft but became generic over time.

Another protocol commonly used in remote access solutions is Point-to-Point Protocol (PPP), which is a Layer 2 protocol so you can use it in conjunction with many Layer 2 protocols. It provides the following functionalities:

• Authentication
• Data compression
• Error detection
• Multilink

PPP is a very versatile protocol and it is used in many different environments, including:

• Serial connections
• Telephone lines
• Mobile connections

One common way to implement PPP in modern networks is over Ethernet using the PPP over Ethernet (PPPoE) protocol. PPP functions by encapsulating PPPoE and is often used in association with DSL lines. Service providers that offer such services can set up a connection with PPP, authenticate it, and build a circuit that can be used mostly by residential users.

PPPoE is simple to implement because it is similar to dial-up architecture, it is natively supported in many operating systems, and you don’t need to use a router for this because of the Layer 2 protocol. This means that PPPoE does not involve a lot of costs so it is an affordable remote access solution.

Remote Desktop Protocol (RDP) can also be considered a remote access technology because it allows a remote user to access an internal enterprise system and control it. RDP allows screen (desktop) or application sharing over TCP port 3389. RDP functionality is built into most of the Windows platforms and it can be used with a pair of valid credentials, without additional overhead. Even though it is a Windows-specific protocol, other operating systems offer RDP clients so you can use this over any type of OS:

• Windows
• Mac OS
• Linux
• Unix
• Mobile OS systems

Independent Computing Architecture (ICA) is a proprietary protocol from Citrix Systems that allows user access to a particular server or service. Even though it is Citrix-proprietary, ICA is used in many systems and allows users to run applications remotely using dedicated clients (for multiple OSs, including Mac OS, Linux, and Unix). With this technology you can have many clients connected to a single server and all of them running independent sessions. This brings a series of advantages:

• Increased administration flexibility
• Centralized management
• Reduced client footprint

Secure Shell (SSH) offers communication services to remote devices over a terminal session, and this is one of the most basic ways of remotely managing network devices. SSH offers increased security, as it encrypts the communication between the two endpoints. It also provides a command line view of the remote device. SSH does not require a lot of bandwidth and it functions by having an SSH server on the managed device and an SSH client on the client side. The most commonly used SSH client is PuTTY (an open source application).

Summary

Access control lists (ACLs) are mechanisms available on different network devices (e.g., routers, switches, firewalls, servers, etc.) and are used to restrict access based on a series of parameters:

• Source MAC address
• Destination MAC address
• Source IP address
• Destination IP address
• Port numbers or services
• Time of day

Modern networks allow communication of remote or mobile devices to enterprise resources to improve productivity. One of the challenges of using this approach is ensuring that you provide a secure connection from the external location to the internal network. Two techniques that allow you to achieve this are tunneling and encryption over the public Internet.

Some of the protocols used to set up tunneling and encryption are:

• SSL
• PPTP
• L2TP
• IPSec

Some of the most commonly used remote access protocols are:

• RAS
• PPP
• PPPoE
• RDP
• ICA
• SSH

We cover access lists and security in great detail in our 101 Labs – Cisco CCNA lab book.

Read the Cisco access list notes.