Tuesday, May 24, 2011

Chapter 03: Network Security Using Cisco IOS Firewalls (Part05)

ACL Considerations

Add a note hereBefore you start to develop any ACLs, consider the following basic rules:

  • Add a note hereBase your ACLs on your security policy: Unless you anchor the ACL in a comprehensive security policy, you cannot be certain that it will effectively control access in the way that access needs to be controlled.

  • Add a note hereWrite it out: Never sit down at a router and start to develop an ACL without first spending some time in design. The best ACL developers suggest that you write out a list of things that you want the ACL to accomplish. Start with something as simple as “This ACL must block all Simple Network Management Protocol (SNMP) access to the router except for the SNMP host at 16.1.1.15.”

  • Add a note hereSet up a development system: Whether you use your laptop PC or a dedicated server, you need a place to develop and store your ACLs. Word processors or text editors of any kind are suitable, as long as you can save the files in ASCII text format. Build a library of your most commonly used ACLs and use them as sources for new files. ACLs can be pasted into the router running configuration (requiring console or Telnet access) or can be stored in a router configuration file. The system that you choose should support TFTP to make it easy to transfer any resulting configuration files to the router.


    		 Note

    Add a note hereHackers love to gain access to router configuration development systems or TFTP servers that store ACLs. A hacker can discover a lot about your network from looking at these easily read text files. For this reason, it is imperative that the system where you choose to develop and store your router files be a secure system.

  • Add a note hereTest: If possible, test your ACLs in a secure environment before placing them into production. Testing is a commonsense approach to any router configuration changes. Most enterprises maintain their own network test beds. Although testing might appear to be an unnecessary cost, over time it can save time and money.

Add a note hereYou should consider several caveats when working with ACLs:

  • Add a note hereImplicit deny all: All Cisco ACLs end with an implicit deny all statement. Although you might not actually see this statement in your ACLs, they do exist.

  • Add a note hereStandard ACL limitation: Because standard ACLs are limited to packet filtering on only source addresses, you might need to create extended ACLs to implement your security policies.

  • Add a note hereOrder of specific statements: Certain ACL statements are more specific than others are; therefore, you need to place them higher in the ACL. For example, blocking all UDP traffic at the top of the list negates the blocking of SNMP packets lower in the list. Take care that statements at the top of the ACL do not negate any statements found lower in the list.

  • Add a note hereDirectional filtering: Cisco ACLs have a directional filter that determines whether they examine inbound packets (toward the interface) or outbound packets (away from the interface). Always double-check the direction of data that your ACL is filtering.

  • Add a note hereModifying ACLs: Cisco IOS Software Release 12.2 and earlier always appends new statements to an existing ACL to the bottom of the ACL. Because of the inherent top-down statement evaluation order of ACLs, these new entries can render the ACL unusable. When a new statement does render the ACL unusable, you must create a new ACL with the correct statement ordering, delete the old ACL, and assign the new ACL to the router interface. If you are using Cisco IOS Software Release 12.3 and later, you can use sequence numbers to ensure that you are adding a new statement into the ACL in the correct location. The ACL is processed top-down based on the sequence numbers of the statements (lowest to highest).

  • Add a note hereSpecial packets: Router-generated packets, such as routing table updates, are not subject to outbound ACL statements applied to interfaces on the source router. If your security policy requires filtering these types of packets, inbound ACLs on adjacent routers or other router filter mechanisms using ACLs must do the filtering task.

  • Add a note hereExtended ACL placement: If you use extended ACLs on routers too far from the source that you need to filter, packets flowing to other routers and interfaces might be adversely affected. Always consider placing extended ACLs on routers as close as possible to the source that you are filtering.

  • Add a note hereStandard ACL placement: Because standard ACLs filter packets based on the source address, placing these ACLs too close to the source can adversely affect packets destined to other destinations. Always place standard ACLs as close to the destination as possible.

Configuring ACLs Using SDM

Add a note hereRules define how the router will respond to a particular kind of traffic. Using Cisco Security Device Manager (SDM), you can create access rules that cause the router to block certain types of traffic while permitting other types, create NAT rules that define the traffic that is to receive address translation, and create IPsec rules that specify which traffic is to be encrypted.

Add a note hereCisco SDM also provides default rules that are used in guided configurations, and that you can examine and use when you create your own access rules. It also allows you to view rules that were not created using Cisco SDM, called external rules, and rules with syntax that Cisco SDM does not support, called unsupported rules.

Add a note hereUse the SDM Rules (ACL) Summary window to view a summary of the rules in the router configuration and to navigate to other windows to create, edit, or delete rules. To access this window, choose Configure > Additional Tasks > ACL Editor, as shown in Figure 3-22.

Image from book
Add a note hereFigure 3-22: SDM Access Rules Window

Add a note hereCisco SDM enables you to manage the following types of rules:

  • Add a note hereAccess rules: These rules govern the traffic that can enter and leave the network. You can apply access rules to router interfaces and to vty lines.

  • Add a note hereNAT rules: These rules determine which private IP addresses are translated into valid Internet IP addresses.

  • Add a note hereIPsec rules: These rules determine which traffic is encrypted on secure connections.

  • Add a note hereNAC rules: These rules specify which IP addresses should be admitted to the network or blocked from the network. More precisely, it determines what access is granted to devices exempted from posture validation such as IP phones.

  • Add a note hereFirewall rules (not shown in Figure 3-22): These rules can specify source and destination addresses and whether the traffic should be permitted or denied.

  • Add a note hereQoS rules: These rules specify traffic that should belong to the quality of service (QoS) class to which the rule is associated.

  • Add a note hereUnsupported rules: These are rules that were not created using Cisco SDM and that Cisco SDM does not support. These rules are read only, and cannot be modified using Cisco SDM.

  • Add a note hereExternally Defined rules: These are rules that were not created using Cisco SDM, but that Cisco SDM supports. These rules cannot be associated with any interface using the SDM, however, they can be associated with an interface from the CLI.

  • Add a note hereCisco SDM default rules: These rules are predefined rules that are used by Cisco SDM wizards.

Add a note hereCreating Standard ACLs with Cisco SDM

Add a note hereCisco SDM refers to ACLs as access rules. From Cisco SDM, you can create and apply standard rules (standard ACL) as shown in Figure 3-23.

Image from book
Add a note hereFigure 3-23: Creating a Standard Rule

Add a note hereFollow these steps to configure a standard rule using Cisco SDM:

Add a note hereStep 1

Add a note hereChoose Configure > Additional Tasks > ACL Editor > Access Rules.

Add a note hereStep 2

Add a note hereClick Add. The Add a Rule window appears.

Add a note hereStep 3

Add a note hereIn the Add a Rule window, enter a name or number in the Name/Number field.

Add a note hereStep 4

Add a note hereFrom the Type drop-down list, choose Standard Rule. Optionally, enter a description in the Description field.

Add a note hereStep 5

Add a note hereClick Add. The Add a Standard Rule Entry window appears.

Add a note hereStep 6

Add a note hereFrom the Select an Action drop-down list, choose Permit or Deny.

Add a note hereStep 7

Add a note hereFrom the Type drop-down list choose one of the following types of addresses:

  • Add a note hereA Network: Choose this option if you want the action to apply to all of the IP addresses in a network or subnet.

  • Add a note hereA Host Name or IP Address: Choose this option if you want the action to apply to a specific host or IP address.

  • Add a note hereAny IP address: Choose this option if you want the action to apply to any IP address.

Add a note hereStep 8

Add a note hereDepending on what you chose from the Type drop-down list, complete the following fields:

  • Add a note hereIP Address: If you chose a network, enter the desired IP address in this field.

  • Add a note hereWildcard Mask: If you chose a network, you must specify a wildcard mask to go with it. You can click the drop-down arrow to choose a wildcard mask from the Wildcard Mask drop-down list, or you can enter a custom wildcard mask in the field.


    		 Caution

    Add a note hereRemember, this is a wildcard mask, not a subnet mask.

  • Add a note hereHost Name/IP: If you selected a host name or IP address in the Type field, enter the name or the IP address of the host. If you enter a hostname, the router must be configured to use a DNS server, but once it has performed the DNS address resolution, the IP address will appear in the access list entry

Add a note hereStep 9

Add a note hereOptionally, enter a description in the Description field. The description must be fewer than 100 characters.

Add a note hereStep 10

Add a note hereOptionally, check the Log Matches Against This Entry check box. Depending on how the syslog settings are configured on the router, the matches are recorded in the local logging buffer, sent to a syslog server, or both.

Add a note hereStep 11

Add a note hereClick OK.

Add a note hereStep 12

Add a note hereContinue adding or editing rules until the standard rule is complete. If at anytime you need to rearrange the order of the rules listed in the Rule Entry list, use the Move Up and Move Down buttons.

Add a note hereAfter the Rule Entry list is complete, the next step is to apply the rule to an interface, as shown in Figure 3-24.

Image from book
Add a note hereFigure 3-24: Applying a Standard Rule to an Interface

Add a note hereFollow these steps to apply the rule to an interface:

Add a note hereStep 1

Add a note hereFrom the Add a Rule window, click Associate. The Associate with an Interface window appears.

Add a note hereStep 2

Add a note hereFrom the Select an Interface drop-down list, choose the interface to which you want this rule to apply.

Add a note hereStep 3

Add a note hereFrom the Specify a Direction section, click either Inbound or Outbound. If you want the router to check packets inbound to the interface, click Inbound. The router checks for a match with the rule before routing it; the router accepts or drops the packet based on whether the rule states permit or deny. If you want the router to forward the packet to the outbound interface before comparing it to the entries in the access rule, click Outbound.

Add a note hereStep 4

Add a note hereIf a rule is already associated with the interface and direction you selected, an information box appears. If this occurs, you have the following options:

  • Add a note hereYou can cancel the operation.

  • Add a note hereYou can continue with the operation by appending the new rule entries to the access rule that is already applied to the interface.

  • Add a note hereYou can disassociate the existing rule from the interface and associate the new rule.

Add a note hereCreating Extended ACLs with Cisco SDM

Add a note hereFrom Cisco SDM, you can also create and apply extended rules (extended ACLs) as shown in Figure 3-25.

Image from book
Add a note hereFigure 3-25: Creating an Extended Rule

Add a note hereFollow these steps to configure an extended rule:

Add a note hereStep 1

Add a note hereChoose Configure > Additional Tasks > ACL Editor > Access Rules.

Add a note hereStep 2

Add a note hereClick Add. The Add a Rule window appears.

Add a note hereStep 3

Add a note hereIn the Add a Rule window, enter a name or number in the Name/Number field.

Add a note hereStep 4

Add a note hereFrom the Type drop-down list, choose Extended Rule. Optionally, enter a description in the Description field.

Add a note hereStep 5

Add a note hereClick Add. The Add an Extended Rule Entry window appears.

Add a note hereStep 6

Add a note hereFrom the Select an Action drop-down list, choose Permit or Deny. Optionally, enter a description in the Description field. The description must be fewer than 100 characters.

Add a note hereStep 7

Add a note hereIn both the Source Host/Network section and Destination Host/Network section, from the Type drop-down list, choose one of the following types of addresses:

  • Add a note hereA Network: Choose this option if you want the action to apply to all the IP addresses in a network or subnet.

  • Add a note hereA Host Name or IP Address: Choose this option if you want the action to apply to a specific host or IP address.

  • Add a note hereAny IP address: Choose this option if you want the action to apply to any IP address.

Add a note hereStep 8

Add a note hereDepending on what you selected from the Type drop-down list, complete the following fields:

  • Add a note hereIP Address: If you selected a network, enter the desired IP address in this field.

  • Add a note hereWildcard Mask: If you selected a network, you must specify a wildcard mask to go with it. You can click the drop-down arrow to choose a wildcard mask from the Wildcard Mask drop-down list, or you can enter a custom wildcard mask in the field.


    		 Caution

    Add a note hereRemember, this is a wildcard mask, not a subnet mask.

  • Add a note hereHostname/IP: If you selected a hostname or IP address in the Type field, enter the name or the IP address of the host. If you enter a hostname, the router must be configured to use a DNS server.

Add a note hereStep 9

Add a note hereIn the Protocol and Service section, choose the protocol and service, if applicable, to which you want the entry to apply. The information that you provide differs from protocol to protocol. The following are the protocols you can choose, and the services or options that you must enter for each protocol:

  • Add a note hereTCP and UDP: When you select either one of these protocols, you will be asked to provide source port information and destination port information. You can specify the source and destination port by name or number. If you do not remember the name or number, click the ... button and choose the value you want from the Service window. This field accepts protocol numbers from 0 to 65535. In addition, you must specify how you want the rule applied to the port:

    • Add a note here=: The rule entry applies to the value that you enter in the field. In the CLI, this is stated as eq.

    • Add a note here!=: The rule entry applies to any value except the one that you enter in the field. In the CLI, this is stated as neq.

    • Add a note here<: The rule entry applies to all port numbers lower than the number you enter in the field. In the CLI, this is stated as lt.

    • Add a note here>: The rule entry applies to all port numbers higher than the number you enter in the field. In the CLI, this is stated as gt.

    • Add a note hererange: The entry applies to the range of port numbers that you specify in the fields. In the CLI, this is stated as range.

      Add a note hereIt is not really necessary to set a source port value for a TCP connection. If you are not sure you need to use this field, you leave it set to = any. However, best practices recommend that you set the source port to greater than 1023 on inbound ACL to block crafted packets.

      Add a note hereThe content of the Service window will change depending on whether the ACE is filtering TCP, UDP, ICMP, or IP, as explained next.

  • Add a note hereICMP: When you select ICMP, you can choose any for the ICMP type or you can enter a type name or number. If you do not remember the name or number, click the ... button and choose the value from the Service window. This field accepts protocol numbers from 0 to 255.

  • Add a note hereIP: If you select IP, the rule will apply to any protocol in the TCP/IP protocol suite. If you want to specify a specific protocol, you can enter it by name or number. If you do not remember the name or number of the protocol, click the ... button and choose the value you want from the Protocols window. This field accepts protocol numbers from 0 to 255.

Add a note hereStep 10

Add a note hereOptionally, check the Log Matches Against This Entry check box. Depending on how the syslog settings are configured on the router, the matches will be recorded in the local logging buffer, sent to a syslog server, or both.

Add a note hereStep 11

Add a note hereClick OK.

Add a note hereAfter the Rule Entry list is complete, the next step is to apply the rule to an interface, as shown previously in Figure 3-24.


Using ACLs to Permit and Deny Network Services

Add a note hereACLs can be used to permit or deny different network services. ACLs can be used not only to filter user traffic, but also to filter routing updates, traffic originating from a vty session, ICMP messages, and many other uses. This section shows the different uses of ACLs.

Add a note hereControlling Routing Updates

Add a note hereCisco routers share routing table update information to provide directions on where to route traffic. ACLs can be used to limit which routes a router accepts (takes in) or advertises (sends out) to its counterparts.

Add a note hereFigure 3-26 shows examples of routing protocol entries using SDM. On the left, you can see an example of how to filter Open Shortest Path First (OSPF) or Enhanced Interior Gateway Routing Protocol (EIGRP). On the right, you can see how to filter Routing Information Protocol (RIP).

Image from book
Add a note hereFigure 3-26: ACL to Filter Routing Updates as Applied Using SDM

Add a note hereExample 3-7 shows an extended IP ACL that accepts only OSPF, EIGRP, and RIP traffic sourced from the IP address 192.168.1.1.

Add a note hereExample 3-7: Extended IP ACL to Control Routing Updates 
Add a note herer1(config)# access-list 120 permit émigré host 192.168.1.1 any
r1(config)# access-list 120 permit ospf host 192.168.1.1 any
r1(config)# access-list 120 permit udp host 192.168.1.1 any eq rip
r1(config)# interface fa0/2
r1(config-if)# ip access-group 120 in

Add a note hereIP Address Spoof Mitigation: Inbound

Add a note hereGenerally, you should not allow any IP packets containing the source address of any internal hosts or networks inbound to a private network. Figure 3-27 shows how SDM can be used to configure an antispoofing rule detailed in Example 3-8.

Image from book
Add a note hereFigure 3-27: SDM: Creating an Inbound Antispoofing Rule

Add a note hereExample 3-8 shows ACL 150 for router r1. In this example, the ACL denies all packets containing the following IP addresses in their source field:

  • Add a note hereAny local host addresses (127.0.0.0/8)

  • Add a note hereAny reserved private addresses (RFC 1918, Address Allocation for Private Internets)

  • Add a note hereAny addresses in the IP multicast address range (224.0.0.0/4)

Add a note hereExample 3-8: ACL for Inbound IP Address Spoofing Mitigation 
Add a note herer1(config)# access-list 150 deny ip 0.0.0.0 0.255.255.255 any
r1(config)# access-list 150 deny ip 10.0.0.0 0.255.255.255 any
r1(config)# access-list 150 deny ip 127.0.0.0 0.255.255.255 any
r1(config)# access-list 150 deny ip 169.0.0.0 0.255.255.255 any
r1(config)# access-list 150 deny ip 172.16.0.0 0.15.255.255 any
r1(config)# access-list 150 deny ip 192.168.0.0 0.0.255.255 any
r1(config)# access-list 150 deny ip 224.0.0.0 15.255.255.255 any
r1(config)# access-list 150 deny ip host 255.255.255.255 any
r1(config)# access-list 150 permit any any

Add a note hereIP Address Spoof Mitigation: Outbound

Add a note hereGenerally, you should not allow any outbound IP packets with a source address other than a valid IP address of the internal network.

Add a note hereFigure 3-28 shows a partial configuration using SDM of an inbound spoofing protection.

Image from book
Add a note hereFigure 3-28: Creating an Outbound Antispoofing Rule Using SDM

Add a note hereExample 3-9 shows ACL 105 for router r1. This ACL permits only those packets that contain source addresses from the 10.0.1.0/24 network and denies all others.

Add a note hereExample 3-9: ACL for Outbound IP Address Spoofing Mitigation 
Add a note herer1(config)# access-list 105 permit ip 10.0.1.0 0.0.0.255 any

 Note

Add a note hereCisco routers running Cisco IOS Software Release 12.0 and later can use IP Unicast Reverse Path Forwarding (RPF) verification as an alternative IP address spoof-mitigation mechanism.

Add a note hereICMP Filtering

Add a note hereHackers use several ICMP message types to attack networks. Unfortunately, there are many legitimate ICMP messages as well. Various management applications use ICMP messages to gather information. Network management uses ICMP messages automatically generated by the router.

Filtering Inbound ICMP Packets

Add a note hereHackers can use ICMP echo packets to discover subnets and hosts on the protected network and to generate DoS floods. Hackers can use ICMP redirect messages to alter host routing tables. Both ICMP echo and redirect messages should be blocked inbound by the router.

Add a note hereSDM can be used to filter ICMP messages, as shown in Figure 3-29.

Image from book
Add a note hereFigure 3-29: SDM: Creating a Standard Rule

Add a note hereThe ACL statement shown in Example 3-10 permits necessary ICMP traffic and blocks all the others. The first line in access-list 112 ensures that inbound replies to our outbound echo requests (pings) will be allowed to come in. The second line in access-list 112 ensures that source-quench messages originating from a host located on the outside are allowed to come in to notify our inside host to reduce the pace at which it is sending packets to that outside host. The third line in access-list 112 ensures that ICMP messages originating from the outside and having for the destination an inside host, and bearing the news “unreachable,” such as port unreachable, network unreachable, host reachable, and the like, are allowed to reach that inside host.

Add a note hereExample 3-10: Filtering Inbound ICMP Messages 
Add a note herer1(config)# access-list 112 permit icmp any any echo-reply
r1(config)# access-list 112 permit icmp any any source-quench
r1(config)# access-list 112 permit icmp any any unreachable
r1(config)# access-list 112 deny icmp any any

Filtering Outbound ICMP Packets

Add a note hereSeveral ICMP messages are required for proper network operation and should be allowed outbound:

  • Add a note hereEcho: Allows users to ping external hosts

  • Add a note hereParameter problem: Informs the host of packet header problems.

  • Add a note herePacket too big: Required for packet maximum transmission unit (MTU) discovery

  • Add a note hereSource quench: Throttles down traffic when necessary

Add a note hereAs a rule, you should block all other ICMP message types outbound. The ACL in Example 3-11 permits all of these ICMP messages outbound while denying all others.

Add a note hereExample 3-11: Filtering Outbound ICMP Messages 
Add a note herer1(config)# access-list 114 permit icmp 16.2.1.0 0.0.0.255 any echo
r1(config)# access-list 114 permit icmp 16.2.1.0 0.0.0.255 any packet-too-big
r1(config)# access-list 114 permit icmp 16.2.1.0 0.0.0.255 any source-quench

 Note

Add a note hereThe examples shown are not meant to be comprehensive examples of router security best practices, but rather as used for pedagogical purpose.

Add a note herePermitting Common Services

Add a note hereDNS, SMTP, and FTP are common services that you often have to allow through a firewall. Figure 3-30 and Example 3-12 show how to configure these three services.

Image from book
Add a note hereFigure 3-30: Permitting DNS, SMTP, and FTP Using SDM
Add a note hereExample 3-12: Permitting DNS, SMTP, and FTP Using an ACL 
Add a note herer1(config)# access-list 122 permit udp any host 172.16.2.2 eq domain
r1(config)# access-list 122 permit tcp any host 172.16.2.2 eq smtp
r1(config)# access-list 122 permit tcp any host 172.16.2.2 eq ftp

Add a note herePermitting Router Service Traffic

Add a note hereIt is also quite common that you will need to configure a firewall to permit protocols that are necessary to administer a router. For example, it might be necessary to allow traffic through an internal router that permits router maintenance traffic from an outside device. Telnet, SSH, syslog, and SNMP are examples of services that a router may need to include. Figure 3-31 and Example 3-13 show how to allow these services.

Image from book
Add a note hereFigure 3-31: Using SDM to Allow Router Service Traffic
Add a note hereExample 3-13: Allowing Router Service Traffic Using an ACL 
Add a note herer1(config)# access-list 180 permit tcp host 192.168.1.1 host 10.0.1.11 eq telnet
r1(config)# access-list 180 permit tcp host 192.168.1.1 host 10.0.1.11 eq 22
r1(config)# access-list 180 permit udp host 192.168.1.1 host 10.0.1.11 eq syslog
r1(config)# access-list 180 permit udp host 192.168.1.1 host 10.0.1.11 eq snmptrap
r1(config)# interface fa0/2
r1(config-if)# ip access-group 180 in

 Note

Add a note hereSSH is preferred over Telnet whenever possible.


at

No comments:

Post a Comment