Defining granular policies.

Example how to create class-maps. First, we can specify class map with match-any statement and then combine it with access-list in second class-map along with match-all keyword to define policy for particular subnet/host:

class-map type inspect match-any self—service-cmap
 match protocol tcp
 match protocol udp
 match protocol icmp
 match protocol h323
!
class-map type inspect match-all to-self-cmap
 match class-map self—service-cmap
 match access-group 120

 The second class-map means: check  the match of both access-list and ANY of the protocol specified in first class-map.

ZFW, router's Self-zone

 Although the router offers a default-allow policy between all zones and the self zone, if a policy is configured from any zone to the self zone, and no policy is configured from self to the router’s user-configurable interface-connected zones, all router-originated traffic encounters the connected-zone to self-zone policy on its return the router and is blocked. Thus, router-originated traffic must be inspected to allow its return to the self zone.
Note: Cisco IOS Software always uses the IP address associated with an interface “nearest” destination hosts for traffic such as syslog, tftp, telnet, and other control-plane services, and subjects this traffic to self-zone firewall policy. However, if a service defines a specific interface as the source-interface using commands that include, but not limited to logging source-interface [type number], ip tftp source-interface [type number], and ip telnet source-interface [type number], the traffic is subjected to the zone-to-zone firewall policy for the source interface’s zone and the security zone of the destination host. If a service is configured to use an interface that is assigned to a specific security zone, self-zone policy does not apply to that service’s traffic.
Note: Some services (particularly routers’ voice-over-IP services) use ephemeral or non-configurable interfaces that cannot be assigned to security zones. These services might not function properly if their traffic cannot be associated with a configured security zone. If the service is configured to use one of the configurable physical or virtual interfaces on the device, the traffic should be handled by security zone policy relevant to that interface.

Self-Zone Policy Limitations

Self-zone policy has limited functionality as compared to the policies available for transit-traffic zone-pairs: 

• As was the case with classical stateful inspection, router-generated traffic is limited to TCP, UDP, ICMP, and complex-protocol inspection for H.323.
  
• Application Inspection is not available for self-zone policies.
  
• Session and rate limiting cannot be configured on self-zone policies. 

Not the best example, but...:

class-map type inspect match-any self—service-cmap
 match protocol tcp
 match protocol udp
 match protocol icmp
 match protocol h323
!
class-map type inspect match-all to-self-cmap
 match class-map self—service-cmap
 match access-group 120
!
class-map type inspect match-all from-self-cmap
 match class-map self—service-cmap
!
class-map type inspect match-all tftp-in-cmap
 match access-group 121
!
class-map type inspect match-all tftp-out-cmap
 match access-group 122
!
policy-map type inspect to-self-pmap
 class type inspect to-self-cmap
  inspect
 class type inspect tftp-in-cmap
  pass
!
policy-map type inspect from-self-pmap
 class type inspect from-self-cmap
  inspect
 class type inspect tftp-out-cmap
  pass
!
zone security private
zone security internet
zone-pair security priv-self source private destination self
 service-policy type inspect to-self-pmap
zone-pair security net-self source internet destination self
 service-policy type inspect to-self-pmap
zone-pair security self-priv source self destination private 
 service-policy type inspect from-self-pmap
zone-pair security self-net source self destination internet
 service-policy type inspect from-self-pmap

!
interface FastEthernet 0/0
 ip address 172.16.100.10
 zone-member security internet
!
interface FastEthernet 0/1
 ip address 172.17.100.10
 zone-member security private
!
access-list 120 permit icmp 172.17.100.0 0.0.0.255 any
access-list 120 permit icmp any host 172.17.100.10 echo
access-list 120 deny icmp any any
access-list 120 permit tcp 172.17.100.0 0.0.0.255 host 172.17.100.10 eq www
access-list 120 permit tcp any any eq 443
access-list 120 permit tcp any any eq 22
access-list 120 permit udp any host 172.17.100.10 eq snmp
access-list 121 permit udp host 172.17.100.17 host 172.17.100.10 
access-list 122 permit udp host 172.17.100.10 host 172.17.100.17

Unfortunately, the self-zone policy does not offer the capability to inspect TFTP transfers. Thus, the firewall must pass all traffic to and from the TFTP server if TFTP must pass through the firewall.

ZFW L7 in-depth packet analysis

Application inspection can be applied on HTTP traffic to control unwanted use of HTTP’s service port for other applications such as IM, P2P file sharing, and tunneling applications that can redirect otherwise firewalled applications through TCP 80. 

First of all, we need to specify class-map for in-depth analysis headers inside HTTP, for example. 

! configure the actions that are not permitted
class-map type inspect http match-any http-aic-cmap
 match request port-misuse any
 match req-resp protocol-violation

Draw attention at http keyword in class-map definition. It specifies that it's not just a regular class map, but an HTTP traffic inspection map.
Then,

! define actions to be applied to unwanted traffic
policy-map type inspect http http-aic-pmap
 class type insp http http-aic-cmap
  reset
  log

The part beyond is really important, because without it we won't be allowed to apply this class-map to a regular policy-map. We will apply it as service-policy to a regular policy-map. There is a http keyword in policy-map definition also.
Then, let's create standard http class-map:

! define class-map for stateful http inspection
class-map type inspect match-any http-cmap
 match protocol http

And after all of these, we can finally create our last policy-map:

! define policy-map, associate class-maps and actions
policy-map type inspect priv-pub-pmap
 class type inspect http-cmap
  inspect
  service-policy http http-aic-pmap

I would like to say it once again - if we didn't associate first class-map with with policy-map (those, specified with http keyword), then it would be impossible to attach this class-map to a regular policy-map at the end.

Working example:

class-map type inspect match-any Int2Pub
 match protocol https
 match protocol dns
 match protocol icmp
class-map type inspect match-any http-cmap
 match protocol http
class-map type inspect http match-any http-aic-cmap
 match  request port-misuse any
 match  req-resp protocol-violation
!
!
policy-map type inspect http http-aic-pmap
 class type inspect http http-aic-cmap
  reset
  log
 class class-default
policy-map type inspect priv-pub-pmap
 class type inspect Int2Pub
  inspect
 class type inspect http-cmap
  inspect
  service-policy http http-aic-pmap
 class class-default
!
zone security private
zone security public
zone-pair security Int2PubZone source private destination public
 service-policy type inspect priv-pub-pmap
!
interface FastEthernet0/0
 ip address 192.168.255.254 255.255.255.0
 zone-member security private
 !
interface FastEthernet0/1
 ip address 192.168.137.100 255.255.255.0
 zone-member security public

Zone-Based Firewall and Firewall concepts

Cisco IOS Classic Firewall stateful inspection (formerly known as Context-Based Access Control, or CBAC) employed an interface-based configuration model, in which a stateful inspection policy was applied to an interface. All traffic passing through that interface received the same inspection policy. This configuration model limited the granularity of the firewall policies and caused confusion of the proper application of firewall policies, particularly in scenarios when firewall policies must be applied between multiple interfaces.

Zone-Based Policy Firewall (also known as Zone-Policy Firewall, or ZFW) changes the firewall configuration from the older interface-based model to a more flexible, more easily understood zone-based model. Interfaces are assigned to zones, and inspection policy is applied to traffic moving between the zones. Inter-zone policies offer considerable flexibility and granularity, so different inspection policies can be applied to multiple host groups connected to the same router interface.

Zones establish the security borders of your network. A zone defines a boundary where traffic is subjected to policy restrictions as it crosses to another region of your network. ZFW’s default policy between zones is deny all. If no policy is explicitly configured, all traffic moving between zones is blocked. This is a significant departure from stateful inspection’s model where traffic was implicitly allowed until explicitly blocked with an access control list (ACL). 

Rules For Applying Zone-Based Policy Firewall

Router network interfaces’ membership in zones is subject to several rules that govern interface behavior, as is the traffic moving between zone member interfaces:

• A zone must be configured before interfaces can be assigned to the zone.
  
• An interface can be assigned to only one security zone.
  
• All traffic to and from a given interface is implicitly blocked when the interface is assigned to a zone, except traffic to and from other interfaces in the same zone, and traffic to any interface on the router.
  
• Traffic is implicitly allowed to flow by default among interfaces that are members of the same zone.
  
• In order to permit traffic to and from a zone member interface, a policy allowing or inspecting traffic must be configured between that zone and any other zone.
  
• The self zone is the only exception to the default deny all policy. All traffic to any router interface is allowed until traffic is explicitly denied.
  
• Traffic cannot flow between a zone member interface and any interface that is not a zone member. Pass, inspect, and drop actions can only be applied between two zones.
  
• Interfaces that have not been assigned to a zone function as classical router ports and might still use classical stateful inspection/CBAC configuration.
  
• If it is required that an interface on the box not be part of the zoning/firewall policy. It might still be necessary to put that interface in a zone and configure a pass all policy (sort of a dummy policy) between that zone and any other zone to which traffic flow is desired.
  
• From the preceding it follows that, if traffic is to flow among all the interfaces in a router, all the interfaces must be part of the zoning model (each interface must be a member of one zone or another).
  
• The only exception to the preceding deny by default approach is the traffic to and from the router, which will be permitted by default. An explicit policy can be configured to restrict such traffic.

A security zone should be configured for each region of relative security within the network, so that all interfaces that are assigned to the same zone will be protected with a similar level of security. For example, consider an access router with three interfaces:

• One interface connected to the public Internet
  
• One interface connected to a private LAN that must not be accessible from the public Internet
  
• One interface connected to an Internet service demilitarized zone (DMZ), where a Web server, Domain Name System (DNS) server, and e-mail server must be accessible to the public Internet
  

In this example, each zone holds only one interface. If an additional interface is added to the private zone, the hosts connected to the new interface in the zone can pass traffic to all hosts on the existing interface in the same zone. Additionally, the hosts’ traffic to hosts in other zones is similarly affected by existing policies.
Typically, the example network will have three main policies:

• Private zone connectivity to the Internet
  
• Private zone connectivity to DMZ hosts
  
• Internet zone connectivity to DMZ hosts
  

Because the DMZ is exposed to the public Internet, the DMZ hosts might be subjected to undesired activity from malicious individuals who might succeed at compromising one or more DMZ hosts. If no access policy is provided for DMZ hosts to reach either private zone hosts or Internet zone hosts, then the individuals who compromised the DMZ hosts cannot use the DMZ hosts to carry out further attack against private or Internet hosts. ZFW imposes a prohibitive default security posture. Therefore, unless the DMZ hosts are specifically provided access to other networks, other networks are safeguarded against any connections from the DMZ hosts. Similarly, no access is provided for Internet hosts to access the private zone hosts, so private zone hosts are safe from unwanted access by Internet hosts.

Steps to configure ZFW:

1. Define zones.
   
2. Define zone-pairs.
   
3. Define class-maps that describe traffic that must have policy applied as it crosses a zone-pair.
   
4. Define policy-maps to apply action to your class-maps’ traffic.
   
5. Apply policy-maps to zone-pairs.
   
6. Assign interfaces to zones. 
   
   

Configuring Zone-Based Policy Firewall Class-Maps:

Class-maps define the traffic that the firewall selects for policy application. Layer 4 class-maps sort the traffic based on these criteria listed here. These criteria are specified using the match command in a class-map:

• Access-group—A standard, extended, or named ACL can filter traffic based on source and destination IP address and source and destination port.
  
• Protocol—The Layer 4 protocols (TCP, UDP, and ICMP) and application services such as HTTP, SMTP, DNS, etc. Any well-known or user-defined service known to Port-Application Mapping can be specified.
  
• Class-map—A subordinate class-map that provides additional match criteria can be nested inside another class-map.
  
• Not—The not criterion specifies that any traffic that does not match a specified service (protocol), access-group or subordinate class-map will be selected for the class-map.
  

Class-maps can apply match-any or match-all operators to determine how to apply the match criteria. If match-any is specified, traffic must meet only one of the match criteria in the class-map. If match-all is specified, traffic must match all of the class-map’s criteria in order to belong to that particular class.

class-map type inspect match-any my-test-cmap
 match protocol http
 match protocol tcp 

HTTP traffic must encounter the match protocol http first to make sure the traffic is handled by the service-specific capabilities of HTTP inspection. If the match lines are reversed, so traffic encounters the match protocol tcp statement before it compares it to match protocol http, the traffic is simply classified as TCP traffic, and inspected according to the capabilities of the Firewall’s TCP Inspection component. This is a problem for certain services such as FTP, TFTP, and several multimedia and voice signaling services such as H.323, SIP, Skinny, RTSP, and others. These services require additional inspection capabilities to recognize the more complex activities of these services. So, more specific rules should by positioned before less specific.

Class-maps can apply an ACL as one of the match criteria for policy application. If a class-map’s only match criterion is an ACL and the class-map is associated with a policy-map applying the inspect action, the router applies basic TCP or UDP inspection for all traffic allowed by the ACL, except that which ZFW provides application-aware inspection. This includes (but not limited to) FTP, SIP, Skinny (SCCP), H.323, Sun RPC, and TFTP. If application-specific inspection is available and the ACL allows the primary or control channel, any secondary or media channel associated with the primary/control is allowed, regardless of whether the ACL allows the traffic.
If a class-map applies only ACL 101 as the match criteria, an ACL 101 appears as this:

access-list 101 permit ip any any

All traffic is allowed in the direction of the service-policy applied to a given zone-pair, and corresponding return traffic is allowed in the opposite direction. Therefore, the ACL must apply the restriction to limit traffic to specific desired types. Note that the PAM list includes application services such as HTTP, NetBIOS, H.323, and DNS. However, in spite of PAM’s knowledge of the specific application’s use of a given port, firewall only applies sufficient application-specific capability to accommodate the well-known requirements of the application traffic. Thus, simple application traffic such as telnet, SSH, and other single-channel applications are inspected as TCP, and their statistics are combined together in the show command output. If application-specific visibility into network activity is desired, you need to configure inspection for services by application name (configure match protocol http, match protocol telnet, etc.).

Compare the statistics available in the show policy-map type inspect zone-pair command output from this configuration with the more explicit firewall policy shown further down the page. This configuration is used to inspect traffic from a Cisco IP Phone, as well as several workstations that use a variety of traffic, which includes http, ftp, netbios, ssh, and dns:

class-map type inspect match-all all-private
 match access-group 101
!         
policy-map type inspect priv-pub-pmap
 class type inspect all-private
  inspect
 class class-default
!
zone security private
zone security public
zone-pair security priv-pub source private destination public
 service-policy type inspect priv-pub-pmap
! 
interface FastEthernet4
 ip address 172.16.108.44 255.255.255.0
 zone-member security public
!
interface Vlan1
 ip address 192.168.108.1 255.255.255.0
 zone-member security private
!
access-list 101 permit ip 192.168.108.0 0.0.0.255 any

While this configuration is easy to define and accommodates all traffic that originates in the private zone (as long as the traffic observes the standard, PAM-recognized destination ports), it provides limited visibility into service activity, and does not offer the opportunity to apply ZFW’s bandwidth and session limits for specific types of traffic. This show policy-map type inspect zone-pair priv-pub command output is the result of the previous simple configuration that uses only a permit ip [subnet] any ACL between zone-pairs. As you can see, most of workstation traffic is counted in the basic TCP or UDP statistics:

stg-871-L#show policy-map type insp zone-pair priv-pub
 Zone-pair: priv-pub
 
  Service-policy inspect : priv-pub-pmap
 
    Class-map: all-private (match-all)
      Match: access-group 101
      Inspect
        Packet inspection statistics [process switch:fast switch]
        tcp packets: [413:51589]
        udp packets: [74:28]
        icmp packets: [0:8]
        ftp packets: [23:0]
        tftp packets: [3:0]
        tftp-data packets: [6:28]
        skinny packets: [238:0]
 
        Session creations since subsystem startup or last reset 39
        Current session counts (estab/half-open/terminating) [3:0:0]
        Maxever session counts (estab/half-open/terminating) [3:4:1]
        Last session created 00:00:20
        Last statistic reset never
        Last session creation rate 2
        Maxever session creation rate 7
        Last half-open session total 0
 
    Class-map: class-default (match-any)
      Match: any 
      Drop (default action)
        0 packets, 0 bytes

By contrast, a similar configuration that adds application-specific classes provides more granular application statistics and control, and still accommodates the same breadth of services that was shown in the first example by defining the last-chance class-map matching only the ACL as the last chance in the policy-map:

class-map type inspect match-all all-private
 match access-group 101
class-map type inspect match-all private-ftp
 match protocol ftp
 match access-group 101
class-map type inspect match-any netbios
 match protocol msrpc
 match protocol netbios-dgm
 match protocol netbios-ns
 match protocol netbios-ssn
class-map type inspect match-all private-netbios
 match class-map netbios
 match access-group 101
class-map type inspect match-all private-ssh
 match protocol ssh
 match access-group 101
class-map type inspect match-all private-http
 match protocol http
 match access-group 101
!
policy-map type inspect priv-pub-pmap
 class type inspect private-http
  inspect
 class type inspect private-ftp
  inspect
 class type inspect private-ssh
  inspect
 class type inspect private-netbios
  inspect
 class type inspect all-private
  inspect
 class class-default!
zone security private
zone security public
zone-pair security priv-pub source private destination public
 service-policy type inspect priv-pub-pmap
! 
interface FastEthernet4
 ip address 172.16.108.44 255.255.255.0
 zone-member security public
!
interface Vlan1
 ip address 192.168.108.1 255.255.255.0
 zone-member security private
!
access-list 101 permit ip 192.168.108.0 0.0.0.255 any

The more-specific configuration provides this substantial granular output for the show policy-map type inspect zone-pair priv-pub command:

stg-871-L#sh policy-map type insp zone-pair priv-pub
 Zone-pair: priv-pub

  Service-policy inspect : priv-pub-pmap

   Class-map: private-http (match-all)
    Match: protocol http
    Match: access-group 101
    Inspect
      Packet inspection statistics [process switch:fast switch]
      tcp packets: [0:2193]

      Session creations since subsystem startup or last reset 731
      Current session counts (estab/half-open/terminating) [0:0:0]
      Maxever session counts (estab/half-open/terminating) [0:3:0]
      Last session created 00:29:25
      Last statistic reset never
      Last session creation rate 0
      Maxever session creation rate 4
      Last half-open session total 0

   Class-map: private-ftp (match-all)
    Match: protocol ftp
    Inspect
      Packet inspection statistics [process switch:fast switch]
      tcp packets: [86:167400]
      ftp packets: [43:0]

      Session creations since subsystem startup or last reset 7
      Current session counts (estab/half-open/terminating) [0:0:0]
      Maxever session counts (estab/half-open/terminating) [2:1:1]
      Last session created 00:42:49
      Last statistic reset never
      Last session creation rate 0
      Maxever session creation rate 4
      Last half-open session total 0

   Class-map: private-ssh (match-all)
    Match: protocol ssh
    Inspect
      Packet inspection statistics [process switch:fast switch]
      tcp packets: [0:62]

      Session creations since subsystem startup or last reset 4
      Current session counts (estab/half-open/terminating) [0:0:0]
      Maxever session counts (estab/half-open/terminating) [1:1:1]
      Last session created 00:34:18
      Last statistic reset never
      Last session creation rate 0
      Maxever session creation rate 2
      Last half-open session total 0
 
   Class-map: all-private (match-all)
    Match: access-group 101
    Inspect
      Packet inspection statistics [process switch:fast switch]
      tcp packets: [51725:158156]
      udp packets: [8800:70]
      tftp packets: [8:0]
      tftp-data packets: [15:70]
      skinny packets: [33791:0]

      Session creations since subsystem startup or last reset 2759
      Current session counts (estab/half-open/terminating) [2:0:0]
      Maxever session counts (estab/half-open/terminating) [2:6:1]
      Last session created 00:22:21
      Last statistic reset never
      Last session creation rate 0
      Maxever session creation rate 12
      Last half-open session total 0
 
   Class-map: class-default (match-any)
    Match: any 
    Drop (default action)
      4 packets, 112 bytes

Another added benefit of using a more granular class-map and policy-map configuration, as mentioned earlier, is the possibility of applying class-specific limits on session and rate values and specifically adjusting inspection parameters by applying a parameter-map to adjust each class’s inspection behavior.

Configuring Zone-Based Policy Firewall Policy-Maps

The policy-map applies firewall policy actions to one or more class-maps to define the service-policy that will be applied to a security zone-pair. When an inspect-type policy-map is created, a default class named class class-default is applied at the end of the class. The class class-default’s default policy action is drop, but can be changed to pass. The log option can be added with the drop action. Inspect cannot be applied on class class-default. 

Zone-Based Policy Firewall Actions

ZFW provides three actions for traffic that traverses from one zone to another:

• Drop—This is the default action for all traffic, as applied by the "class class-default" that terminates every inspect-type policy-map. Other class-maps within a policy-map can also be configured to drop unwanted traffic. Traffic that is handled by the drop action is "silently" dropped (i.e., no notification of the drop is sent to the relevant end-host) by the ZFW, as opposed to an ACL's behavior of sending an ICMP “host unreachable” message to the host that sent the denied traffic. Currently, there is not an option to change the "silent drop" behavior. The log option can be added with drop for syslog notification that traffic was dropped by the firewall.
  
• Pass—This action allows the router to forward traffic from one zone to another. The pass action does not track the state of connections or sessions within the traffic. Pass only allows the traffic in one direction. A corresponding policy must be applied to allow return traffic to pass in the opposite direction. The pass action is useful for protocols such as IPSec ESP, IPSec AH, ISAKMP, and other inherently secure protocols with predictable behavior. However, most application traffic is better handled in the ZFW with the inspect action.
  
• Inspect—The inspect action offers state-based traffic control. For example, if traffic from the private zone to the Internet zone in the earlier example network is inspected, the router maintains connection or session information for TCP and User Datagram Protocol (UDP) traffic. Therefore, the router permits return traffic sent from Internet-zone hosts in reply to private zone connection requests. Also, inspect can provide application inspection and control for certain service protocols that might carry vulnerable or sensitive application traffic. Audit-trail can be applied with a parameter-map to record connection/session start, stop, duration, the data volume transferred, and source and destination addresses.

Actions are associated with class-maps in policy-maps:

conf t
 policy-map type inspect z1-z2-pmap
  class type inspect service-cmap
   inspect|drop|allow [service-parameter-map]

Parameter-maps offer options to modify the connection parameters for a given class-map’s inspection policy.

Configuring Zone-Policy Firewall Parameter-Maps

Parameter-maps specify inspection behavior for ZFW, for parameters such as DoS protection, TCP connection/UDP session timers, and audit-trail logging settings. Parameter-maps are also applied with Layer 7 class and policy-maps to define application-specific behavior, such as HTTP objects, POP3 and IMAP authentication requirements, and other application-specific information.
Inspection parameter-maps for ZFW are configured as type inspect, similar to other ZFW class and policy-objects:

stg-871-L(config)#parameter-map type inspect z1-z2-pmap
stg-871-L(config-profile)#?
parameter-map commands:
  alert           Turn on/off alert
  audit-trail     Turn on/off audit trail
  dns-timeout     Specify timeout for DNS
  exit            Exit from parameter-map
  icmp            Config timeout values for icmp
  max-incomplete  Specify maximum number of incomplete connections before
                  clamping
  no              Negate or set default values of a command
  one-minute      Specify one-minute-sample watermarks for clamping
  sessions        Maximum number of inspect sessions
  tcp             Config timeout values for tcp connections
  udp             Config timeout values for udp flows

Specific types of parameter-maps specify parameters applied by Layer 7 application inspection policies. Regex-type parameter-maps define a regular expression for use with HTTP application inspection that filters traffic using a regular expression:

parameter-map type regex [parameter-map-name]

Protocol-info-type parameter-maps define server names for use with instant messaging application inspection:

parameter-map type protocol-info [parameter-map-name]

Device hardening

The list of enabled by default, but unnecessary services, which should be disabled:

1. BOOTP server (config)# no ip bootp server
2. Cisco Discovery Protocol (CDP). Should be disabled globally or on outside interfaces  (config)# no cdp run   (config-if)# no cdp enable
3. Packet assembler/disassembler (PAD) service (config)# no service pad
4. Maintenance Operation Protocol (MOP) service (config-if)# no mop enabled
5. Simple Network Management Protocol (SNMP) (config)# no snmp-server enable
6. Domain Name Service (DNS). Cisco routers use 255.255.255.255 as the default address to reach a DNS server for name resolution. If not used, this service should be disabled. If needed, explicitly set the address of the DNS server. (config)# no ip domain-lookup
7. ICMP Redirects. This service causes the router to send an ICMP redirect message when a packet is forwarded out the interface it arrived on. An attacker can use such information to redirect packets to an untrusted device. This service should be disabled when not needed. (config)# no ip icmp redirect
   (config-if)# no ip redirects
8. IP Source Routing. This service allows the sender to control the route that a packet travels through a network. Such a service can permit an attacker to bypass the normal forwarding path and security mechanisms in a network. Because most network devices should not attempt to dictate their preferred path through the network, this service should be disabled. (config)# no ip source-route
9. Finger service. The finger protocol (port 79) retrieves a list of users from a network device, which includes the line number, connection name, idle time, and terminal location. Such information is also seen in the show users Cisco IOS command, and can be used for reconnaissance attacks. This service should be disabled when not needed. (config)# no service finger
10. ICMP unreachable notification. This service notifies a sender of invalid destination IP subnets or specific addresses. Such information can be used to map a network. Thisservice should be disabled.(config-if)# no ip unreachables
11. IP identification service. The identification protocol (RFC 1413) reports the identity of the TCP connection initiator. Such information can be used in reconnaissance attacks. This service should be disabled. (config)# no ip identd
12. TCP keepalives. TCP keepalives help clean up TCP connections when a remote host has stopped processing TCP packets (such as after a reboot). This service should be enabled to help prevent certain DoS attacks. Disabled by default. To enable this service, enter (config)# service tcp-keepalives-in. (config)# service tcpkeepalives-out
13. Gratuitous ARP. This service is the primary means used in ARP poisoning attacks. Unless needed, this service should be disabled. (config)# no ip arp gratuitous
14. Proxy ARP This service permits the router to resolve Layer 2 addresses. This feature is only useful if the router is acting as a Layer 2 bridge. Because this is unlikely in modern networks, this service should be disabled. (config)# no ip arp proxy