|
Having the tools and mechanisms to identify and classify security threats and anomalies in the network is crucial.
October 02, 2007
URL:http://drdobbs.com/security/identifying-and-classifying-security-thr/202200447
Omar Santos is the author of End-to-End Network Security: Defense-in-Depth , from which this article is adapted. Copyright (c) 2008 Cisco Press. All rights reserved.
Worms and denial of service (DoS) attacks are used maliciously to consume the resources of your hosts and network that would otherwise be used to serve legitimate users. In some cases, misconfigured hosts and servers can send traffic that consumes network resources unnecessarily. Having the necessary tools and mechanisms to identify and classify security threats and anomalies in the network is crucial. This article presents several best practices and methodologies you can use to successfully and quickly identify and classify such threats.
Most people classify security attacks into two separate categories: logic attacks and resource attacks. Logic attacks exploit existing software deficiencies and vulnerabilities to cause systems to crash, to substantially degrade their performance, or to enable attackers to gain access to a system. An example of this type of attack is the exploit of the Microsoft PnP MS05-039 Overflow Vulnerability, in which the attacker exploits a stack overflow in the Windows "plug and play" (PnP) service. You can exploit this vulnerability on Windows 2000 without a valid user account. Another example is the famous and old "ping-of-death," whereby an attacker sends the system Internet Control Message Protocol (ICMP) packets that exceed the maximum legal length (65535 octets). You can prevent most of these attacks by either upgrading the vulnerable software or by filtering particular packet sequences.
The second category of attacks is referred to as resource attacks. The goal with these types of attacks is to overwhelm the victim system/network resources, such as CPU and memory. In most cases, this is done by sending numerous IP packets or forged requests. An attacker can build up a more powerful attack with a more sophisticated and effective method of compromising multiple hosts and installing small attack daemon(s). This is what many call zombies or bot hosts/nets. Subsequently, an attacker can launch a coordinated attack from thousands of zombies onto a single victim. This daemon typically contains both the code for sourcing a variety of attacks and some basic communications infrastructure to allow for remote control. A zombie attack is illustrated in Figure 1.
In Figure 1, an attacker controls compromised hosts in Company A and Company B to attack a web server farm in another organization.
You can use different mechanisms and methodologies to successfully identify and classify these threats/attacks depending on their type. In other words, depending on the threat, you can use specific techniques to identify and classify them accordingly. Following are the most common methodologies:
Complete visibility is one of the key requirements when identifying and classifying security threats. The following sections explain best practices for achieving complete network visibility and the use of the previously mentioned tools and mechanisms.
The first step in the process of preparing your network and staff to successfully identify security threats is achieving complete network visibility. You cannot protect against or mitigate what you cannot view/detect. You can achieve this level of network visibility through existing features on network devices you already have and on devices whose potential you do not even realize. In addition, you should create strategic network diagrams to clearly illustrate your packet flows and where, within the network, you may enable security mechanisms to identify, classify, and mitigate the threat. Remember that network security is a constant war. When defending against the enemy, you must know your own territory and implement defense mechanisms in place. Figure 2 illustrates a fairly simple high-level enterprise diagram.
In Figure 2, the following sections are numbered:
You can create this type of diagram not only to understand the architecture of your organization but also to strategically identify places within the infrastructure where you can implement telemetry mechanisms like NetFlow and identify choke points where you can mitigate an incident. Notice that the access, distribution, and core layers/boundaries are clearly defined.
Look at the example illustrated in Figure 3. A workstation at the call center usually communicates over TCP port 80 (HTTP) to a server in the data center. This traffic is allowed within the access control lists because it is legitimate traffic to the server. However, the traffic from this specific workstation increased more than 400 percent over normal. Subsequently, performance on the server is degraded, and the infrastructure is congested with unnecessary packets.
In this case, NetFlow was configured at the distribution layer switch, and the administrator was able to detect the anomaly. The administrator then configures a host-specific ACL to deny the traffic from the call center workstation, as shown in Figure 4. In more sophisticated environments, you can even implement remotely triggered black hole (RTBH) routing to mitigate this incident.
In the example illustrated in Figure 4, the problem was a defect within the call center workstation application. The administrator was able to perform detailed analysis and patch the machine while preventing disruption of service.
You can also develop a different type of diagram to visualize operational risks within your organization. These diagrams are based on device roles and can be developed for critical systems you want to protect. For example, identify a critical system within your organization and create a layered diagram similar to the one in Figure 5. In this example, a database called ABC is the most critical application/data source for this company. The diagram presents ABC Database Server in the center.
You can use this type of diagram to audit device roles and the type of services they should be running. For example, you can decide in what devices you can run services like Cisco NetFlow or where to enforce security policies. In addition, you can see the life of a packet within your infrastructure depending on the source and destination. An example is illustrated in Figure 6.
Figure 6 shows the packet flow that occurs when a user from the sales department accesses an Internet site. You know exactly where the packet is going based on your architecture and your security and routing policies. This is a simple example; however, you can use this concept to visualize risks and to prepare your isolation policies.
Anomaly detection systems passively monitor network traffic, looking for any deviation from "normal" or "baseline" behavior that may indicate a security threat or a misconfiguration. You can use several commercial tools and even open source tools to successfully identify security threats within your network. These tools include the following:
The following are other technologies and tools you can use to achieve complete visibility of what is happening within your network:
Cisco NetFlow was initially introduced as a packet accounting system for network administration and, in some cases, for billing. However, today you can use NetFlow tolisten to the network itself, thereby gaining valuable insight into the overall security state of the network. This is why it is classified as a form of telemetry that provides information about traffic passing through or directly to each router or switch. NetFlow is supported in the following Cisco platforms:
Note: Indicated models have platform-specific considerations. Please refer to http://www.cisco.com/go/netflow for more compatibility information. The word netflow is a combination of net (or network) and flow. What is a flow? An individual flow comprises, at a minimum, the following elements:
NetFlow also can give you information about network traffic. This information varies somewhat depending on what version of NetFlow Data Export (NDE) you run. The most commonly deployed versions are Versions 5 and 9. Following is some of the additional information you can obtain from a flow in NetFlow Version 5:
All this information can be exported to monitoring systems for further analysis. NetFlow Version 9 supports the same reporting capabilities as NetFlow Version 5 with some additional information. One of the biggest advantages of NetFlow Version 9 is its ability to be configured by the use of templates to use various features to export additional or different information to external systems. In NetFlow Version 5 and earlier, you can export the flow data over UDP. NetFlow Version 9 supports NDE via TCP and SCTP, as well as the classic UDP mode.
Note: All new NetFlow development is based on NetFlow Version 9. In NetFlow Version 9, you can use a template describing the NDE fields within the flow information. This template information is contained in the first NetFlow Version 9 NDE packets sent to the NDE destination (monitoring system) after NDE is enabled on the router or switch. This information is also periodically retransmitted. When the configuration of NDE fields is changed on the router or switch, the updated template is immediately transmitted.
The IETF Internet Protocol Flow Information eXport (IPFIX) working group (WG) has been tasked with developing a common standard for IP-based flow export. This working group has selected Cisco NetFlow Version 9 as the technology of choice.
Note: The IPFIX requirements are defined in RFC 3917. RFC 3954 explains the evaluation of NetFlow Version 9 in IPFIX. The actual outcome and the criteria for the selection of NetFlow Version 9 as the basis for the IPFIX standard are defined in RFC 3955.
It is recommended that you use an isolated out-of-band (OOB) management network to allow you to access and control NetFlow-enabled devices over the network, even when you are under attack or during any security incident or network malfunction. When you transmit network telemetry over the OOB network, you reduce the chance for disruption of the information that provides insightful network visibility.
Typically, enabling NetFlow on software-based platforms consists of one or two steps:
When you configure NetFlow, you must decide between ingress or egress NetFlow for each device. This decision depends on the use and the topology. You can also enable NetFlow for both ingress and egress.
Note: Egress NetFlow is dependent on the version of Cisco IOS you are running. For more information, go to http://www.cisco.com/go/fn.
The following example shows how you can enable ingress NetFlow on a particular interface (GigabitEthernet0/0 in this case):
myrouter#configure terminal myrouter(config)#interface GigabitEthernet0/0 myrouter(config-if)#ip flow ingress
To enable egress NetFlow, use the ip flow egress interface subcommand as follows:
myrouter(config)#interface GigabitEthernet0/0 myrouter(config-if)#ip flow egress
Note: Ingress NetFlow is the most commonly used method. Egress NetFlow is more commonly used with MPLS VPN. The MPLS Egress NetFlow Accounting feature allows you to capture IP flow information for packets undergoing MPLS label disposition. In other words, it captures packets that arrive on a router as MPLS packets and are transmitted as IP packets. Egress NetFlow accounting might adversely affect network performance because of the additional accounting-related computations that occur in the traffic-forwarding path of the router.
The following example shows how to configure the NetFlow-enabled device to export the flow data to a monitoring system:
myrouter(config)#ip flow-export version 5 myrouter(config)#ip flow-export source loopback 0 myrouter(config)#ip flow-export destination 172.18.85.190 2055
In this example, NDE Version 5 is used. All NetFlow export packets are sourced from a loopback interface configured in the router (loopback 0). The destination is a Cisco Secure Monitoring and Response System (CS-MARS) box with the IP address 172.18.85.190 and the destination UDP port 2055.
It is recommended that you alter the setting of the active flow timeout parameter from its default of 30 minutes to the minimum value of one minute. This helps you achieve an environment that is closer to real time. You can do this with the ip flow-cache timeout active command, as shown here:
myrouter(config)#ip flow-cache timeout active 1
Note: The default value for the number of minutes that an active flow remains in the cache before it times out is 30.
The default value for the number of seconds that an inactive flow remains in the cache before it times out is 15.
To view the basic NetFlow information from the CLI, you can use the show ip cache flow command, as shown in Example 1:
myrouter#show ip cache flow IP packet size distribution (9257M total packets): 1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480 .088 .314 .011 .011 .027 .001 .007 .001 .013 .016 .002 .002 .000 .001 .000 512 544 576 1024 1536 2048 2560 3072 3584 4096 4608 .000 .001 .002 .043 .452 .000 .000 .000 .000 .000 .000 IP Flow Switching Cache, 4456704 bytes 43 active, 65493 inactive, 884110623 added 3341579080 ager polls, 0 flow alloc failures Active flows timeout in 30 minutes Inactive flows timeout in 15 seconds last clearing of statistics never Protocol Total Flows Packets Bytes Packets Active(Sec) Idle(Sec) -------- Flows /Sec /Flow /Pkt /Sec /Flow /Flow TCP-Telnet 1072696 0.2 17 578 4.4 9.8 15.3 TCP-FTP 33386 0.0 2392 57 18.6 697.2 7.6 TCP-FTPD 2967 0.0 2869 1049 1.9 4.3 15.2 TCP-WWW 9091735 2.1 222 904 470.3 6.0 5.6 TCP-SMTP 538619 0.1 1 59 0.2 6.9 15.9 TCP-X 3246 0.0 44 909 0.0 0.1 13.4 TCP-BGP 280550 0.0 2 44 0.1 7.2 15.8 TCP-NNTP 2306 0.0 1 46 0.0 0.0 18.1 TCP-Frag 7 0.0 19 152 0.0 8.8 15.4 TCP-other 48037166 11.1 115 887 1289.2 4.5 6.2 UDP-DNS 1043579 0.2 2 74 0.4 3.9 15.9 UDP-NTP 891663 0.2 1 79 0.2 0.0 15.5 UDP-TFTP 138376 0.0 7 55 0.2 21.2 15.5 UDP-Frag 9736 0.0 182 1366 0.4 22.1 15.4 UDP-other 816395802 190.0 1 109 316.9 0.1 18.8 ICMP 6533952 1.5 13 95 20.5 8.3 15.5 GRE 239 0.0 41 97 0.0 66.9 15.2 IP-other 34558 0.0 3907 156 31.4 66.1 15.0 Total: 884110583 205.8 10 750 2155.4 0.5 17.9 SrcIf SrcIPaddress DstIf DstIPaddress Pr SrcP DstP Pkts Fa1/1 14.38.1.9 Null 255.255.255.255 11 0044 0043 1 Fa1/1 0.0.0.0 Null 255.255.255.255 11 0044 0043 209 Fa0/0 172.18.173.68 Fa1/0 14.36.1.208 06 05BC 01BB 452 Fa0/0 172.18.173.68 Fa1/0 14.36.1.186 06 0631 01BB 388 Fa1/0 14.36.1.120 Null 14.36.255.255 11 008A 008A 3 Fa0/0 14.36.1.120 Null 14.36.255.255 11 008A 008A 3 Fa0/0 172.18.124.223 Fa1/0 14.36.197.213 06 8107 2323 1547 Fa0/0 172.18.124.66 Null 14.36.1.184 06 EC83 01BB 1 Fa1/0 14.36.8.48 Fa0/0 172.18.124.154 06 15FE 0FA5 1 Fa1/0 14.36.8.48 Fa0/0 172.18.124.154 06 15FF 0FA5 1 Fa1/0 14.36.8.48 Fa0/0 172.18.124.154 06 15FD 0FA5 1 Fa1/0 14.36.1.3 Fa0/0 172.18.123.69 01 0000 0303 3 Fa1/0 14.36.8.36 Fa0/0 172.18.124.66 11 0202 0202 4 Fa1/0 14.36.99.77 Fa0/0 172.18.124.225 06 01BB 137C 85 Fa1/0 14.36.197.213 Fa0/0 172.18.124.223 06 2323 8107 780 Fa0/0 172.18.124.223 Fa1/0 14.36.1.203 06 8105 2323 19992167 Fa0/0 172.18.85.169 Local 14.36.1.1 06 8E5E 0017 97 Fa0/0 172.18.124.225 Fa1/0 14.36.99.77 06 137C 01BB 85 Fa0/0 172.18.124.128 Fa1/0 14.36.1.128 06 916E 2323 138 Fa0/0 172.18.124.128 Fa1/0 14.36.1.128 06 916D 2323 54 Fa1/0 14.36.1.208 Fa0/0 172.18.173.68 06 01BB 05BC 678
In the highlighted line, you can see that a host (172.18.124.223 is sending 19,992,167 packets to 14.36.1.203. This may be abnormal behavior or an infected machine. The protocol is 06 (TCP), the source port is 33029 (Hex 8105), and the destination port is 8995 (Hex 2323).
You can also obtain export flow information using the show ip flow export command, as shown in Example 2:
myrouter#show ip flow export Flow export v5 is enabled for main cache Exporting flows to 172.18.85.190 (2055) Exporting using source IP address 172.18.124.47 Version 5 flow records 884111088 flows exported in 31352026 udp datagrams 0 flows failed due to lack of export packet 4 export packets were sent up to process level 0 export packets were dropped due to no fib 0 export packets were dropped due to adjacency issues 0 export packets were dropped due to fragmentation failures 0 export packets were dropped due to encapsulation fixup failures
In Example 2, you can see that the router is exporting the NetFlow information to the 172.18.85.190 device (a CS-MARS in this case) over UDP port 2055. The source IP address is 172.18.124.47. A total of 884,111,088 flows have been exported in 31,352,026 UDP datagrams. Please note that all protocol numbers, source ports, and TCP/UDP destination ports are shown in hexadecimal. ICMP packets are represented with the source port field set to 0000, the first two bytes of the destination field set to the ICMP type, and the second two bytes to the ICMP code. If you are using features such as policy-based routing (PBR), Web Cache Communications Protocol (WCCP), Network Address Translation (NAT), or Unicast Reverse Path Forwarding (uRPF) ACLs, you will see a (DstIf) value of Null. To see packet drops caused by ACLs, uRPF, PBR, or null routes, use the show ip cache flow with the include Null option, as shown in Example 3:
myrouter#show ip cache flow | include Null Fa1/0 14.36.1.8 Null 255.255.255.255 11 0044 0043 1 Fa1/1 0.0.0.0 Null 255.255.255.255 11 0044 0043 891 Fa0/0 172.18.124.66 Null 14.36.1.184 06 80AC 01BB 3 Fa0/0 14.1.17.111 Null 14.38.201.1 06 51CD 00B3 2 Fa1/0 172.18.124.11 Null 172.18.124.255 11 0089 0089 18 Fa1/0 172.18.124.153 Null 172.18.124.255 11 008A 008A 3
To see flows that contain thousands or millions of packets, you can use show ip cache flow | include K or show ip cache flow | include M commands, respectively. The Cisco Catalyst 6500 switches and Cisco 7600 router obtain NetFlow information via the Multilayer Switching (MLS) cache. In addition, the amount and type of data recorded in the table must be selected. The mls flow ip interface-full command provides the most useful information and can be configured as follows:
'CAT6k(config)# mls flow ip interface-full CAT6k(config)# mls nde interface
System logs or SYSLOG provide you with information for monitoring and troubleshooting devices within your infrastructure. In addition, they give you excellent visibility into what is happening within your network. You can enable SYSLOG on network devices such as routers, switches, firewalls, VPN devices, and others. This section covers how to enable SYSLOG on routers, switches, the Cisco ASA, and Cisco PIX security appliances.
The logging facility on Cisco IOS routers and switches allows you to save SYSLOG messages locally or to a remote host. By default, routers send logging messages to a logging process. The logging process controls the delivery of logging messages to various destinations, such as the logging buffer, terminal lines, a SYSLOG server, or a monitoring event correlation system such as CS-MARS. You can set the severity level of the messages to control the type of messages displayed, in addition to a time stamp to successfully track the reported information.
The following example shows the commands necessary to configure SYSLOG on Cisco IOS devices:
myrouter#configure terminal myrouter(config)#logging on myrouter(config)#logging host 172.18.85.190
In this example, the router is configured to send the SYSLOG messages to a host with IP address 172.18.85.190. (This is the CS-MARS used in the examples of the previous sections.)
On Cisco IOS routers, the log messages are not time-stamped by default. To enable time stamping of log messages, use the service timestamps log datetime command. The following example shows the different options of this command:
myrouter(config)#service timestamps log datetime ? localtime Use local time zone for timestamps msec Include milliseconds in timestamp show-timezone Add time zone information to timestamp year Include year in timestamp
You can specify the severity level of the SYSLOG messages. The following are the different levels you can configure:
To set the severity level of log messages sent to a SYSLOG server, use the logging trap command. The following example shows the options of this command:
myrouter(config)#logging trap ? <0-7> Logging severity level alerts Immediate action needed (severity=1) critical Critical conditions (severity=2) debugging Debugging messages (severity=7) emergencies System is unusable (severity=0) errors Error conditions (severity=3) informational Informational messages (severity=6) notifications Normal but significant conditions (severity=5) warnings Warning conditions (severity=4)
It is recommended that you send SYSLOG messages over a separate management segment, just as you learned to do earlier in this article in the "NetFlow" section.
To enable the logging of system messages to a SYSLOG server on Cisco Catalyst switches running Catalyst Operating System (CATOS), use the following commands:
set logging server enable set logging server syslog server 172.18.85.190 set logging timestamp enable set logging server severity 4
In this example, the switch is configured to send the SYSLOG messages to the host with IP address 172.18.85.190. Time stamp is enabled, and the severity level of the messages sent to the external server is set to 4 or warnings. Setting logging to the debugging level can cause performance problems. A good rule of thumb is to set the logging severity to 4 or warnings.
Note: A good whitepaper describing best practices when managing Cisco Catalyst switches running CATOS is located at http://www.cisco.com/en/US/products/hw/switches/ps663/products_tech_note09186a0080094713.shtml.
The commands used to enable logging and to send SYSLOG messages to a SYSLOG server are the same on the Cisco ASA and the Cisco PIX security appliances. To enable logging, use the logging on command. To configure the ASA or PIX to send logs to a SYSLOG server, use the logging host command, and to change the log severity level, use the logging trap command. The following example demonstrates the use of these commands.
ciscoasa(config)# logging on ciscoasa(config)# logging host inside 172.18.85.190 ciscoasa(config)# logging trap informational
In this example, the Cisco ASA is configured to send its logs to the host with IP address 172.18.85.190, and the severity level is set to informational. On the Cisco ASA and Cisco PIX security appliances, all SYSLOG messages begin with a percent sign (%) and are designed as follows:
%PIX|ASA Level Message_number: Message_text
The following is an example of a SYSLOG message.
Apr 09 2007 07:35:56: %ASA-6-302021: Teardown ICMP connection for faddr 192.168.202.22/0 gaddr 192.168.202.40/0 laddr 192.168.202.40/0
You can filter SYSLOG messages on the Cisco ASA, Cisco PIX, and Cisco FWSM to send only specific events to a particular output destination. In other words, you can configure the device to send all SYSLOG messages to one output destination and also to send a subset of those SYSLOG messages to a different output destination. You can also configure the Cisco ASA, Cisco PIX, and Cisco FWSM to send SYSLOG messages based on specific criteria, such as the following:
For example, you can use the logging class <message_class> command to specify the specific class.
SNMP is one of the most basic forms of getting information from your network. It is a Layer 7 protocol designed to obtain information from network devices. This information includes but is not limited to the following:
The SNMP solution has three components:
As a best practice, you should set the system contact, location, and serial number of the SNMP agent so that your management servers can obtain these descriptions. This information is useful when responding to incidents. The following example shows how to enter the contact information on the Cisco IOS device:
myrouter#configure terminal myrouter(config)#snmp-server contact John Route myrouter(config)#snmp-server location 1st Floor NY Office myrouter(config)#snmp-server chassis-id ABC12345
In the previous example, the name of the administrator is John Route, the device is located on the 1st floor of an office in New York, and the chassis identification number is ABC12345.
The following example shows how you can configure SNMP Version 3 on a Cisco IOS device:
myrouter(config)#snmp-server group mygroup v3 auth
SNMP Version 3 supports authentication. In the previous example, an SNMP group named mygroup is configured for SNMP Version 3. Authentication is also enabled with the auth keyword. When you configure the snmp-server group command, there are no default values for authentication. To specify authentication user parameters, use the snmp-server user command, as shown in the following example:
myrouter(config)#snmp-server user admin1 mygroup v3 auth md5 zxasqw12 *Feb 8 15:45:04.902: Configuring snmpv3 USM user, persisting snmpEngineBoots. Please Wait...
In the previous example, a user (admin1) is configured and mapped to the SNMP group mygroup. Authentication is done with MD5, and the password is zxasqw12. After you invoke this command, the preceding warning message is displayed. You should match all this information in your SNMP management server.
To verify the configuration, you can invoke the show snmp user command as follows:
myrouter#show snmp user User name: admin1 Engine ID: 8000000903000013C4EC5528 storage-type: nonvolatile active Authentication Protocol: MD5 Privacy Protocol: DES Group-name: mygroup
To view SNMP group information, invoke the show snmp group command, as shown in Example 4. The configured group (mygroup) is shown in the highlighted line.
Note: The following site includes detailed information on how to configure SNMP Version 1 and 2: http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124tcg/tnm_c/snmp/confsnmp.htm#wp1032846. This document also includes the following information:
myrouter#show snmp group groupname: ILMI security model:v1 readview : *ilmi writeview: *ilmi notifyview: <no notifyview specified> row status: active groupname: ILMI security model:v2c readview : *ilmi writeview: *ilmi notifyview: <no notifyview specified> row status: active groupname: mygroup security model:v3 auth readview : v1default writeview: <no writeview specified> notifyview: <no notifyview specified> row status: active
The Cisco ASA and the Cisco PIX security appliances support only SNMP Versions 1 and 2c. They both support traps and SNMP read access; however, SNMP write access is not supported. The following example shows how to configure an ASA to receive SNMP Version 2c requests from host 172.18.85.190 on the inside interface:
ciscoasa(config)# snmp-server host inside 172.18.85.190 Version 2c ciscoasa(config)# snmp-server location Raleigh NC Branch ciscoasa(config)# snmp-server contact Jeff Firewall ciscoasa(config)# snmp-server community th1s1sacommstrng
The ASA in this example is located in a branch office in Raleigh, North Carolina. The point of contact is Jeff Firewall, and the community string is <th1s1sacommstrng>. You can use the snmp deny version command to deny SNMP packets from other SNMP versions. The following example shows the available options:
ciscoasa(config)# snmp deny version ? configure mode commands/options: 1 SNMP version 1 2 SNMP version 2 (party based) 2c SNMP version 2c (community based) 3 SNMP version 3
Note: You can obtain the MIBs for any Cisco device at http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml.
Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.