Using ACLs to Perform Blocking

As previously discussed, Cisco's ACLs are a list of rules that will either permit or deny traffic entering or leaving the network. We can use either standard ACLs, for controlling network access for a particular source IP address, or extended ACLs for a more specific control such as source and destination IP address, protocol, and so on. There are other types of ACLs used by Cisco with varying functions, such as Lock and Key (Dynamic ACLs) which force an authentication before a router allows traffic to pass, and IP-named ACLs which allow a user to name an access-list as opposed to using a number. These other ACL types are beyond the scope of our subject but more information can be found at www.cisco.com. Give an actual link, not just the generic Cisco site.

Device management takes advantage of ACLs by creating and applying ACLs to network devices being monitored by a particular sensor. We have already discussed how blocking works, now lets take a look at what actually happens with the device management process.

ACL 198 and 199 are the two extended IP access-list numbers that device management utilizes. These are the only two and a sensor-created ACL will take priority over any previously established ACL by the same number. A sensor begins with the ACL 199. When a security threat triggers an alarm, the monitoring sensor will create a new ACL number—you guessed it, 198. This new ACL is equipped with the appropriate settings to block out the newly realized threat. The sensor will then Telnet to the network device, authenticate, and then apply the ACL 198 to the interface in question. Since we can only have one ACL per interface and direction combination, ACL 198 will replace the current ACL 199. The next alarm that is triggered on this interface will receive the ACL 199 again but with new configurations. These two ACLs are switched back and forth as needed and the method used to apply them ensures consistent protection.

Note

To use an ACL as a preshun or a postshun ACL, it must be an extended IP ACL and can be either named or numbered. Preshun and postshun ACLs can be used to indicate a standard group of settings to be included with all ACLs being implemented. Therefore, when the IDS sensor deems an ACL creation necessary, the preshun and postshun settings will be included with the deployed list. Preshun indicates the standard information will be included before the IDS created portion of the ACL. Postshun would be in the ACL after the IDS created portion of the ACL.

This feature could be very important in helping to keep particular, or critical, connections open all the time or blocked all the time, whatever the case may be.

General Considerations for Implementation

Before implementing any new type of technology to our networks, it is, of course, critical to have a plan that has been thought out and preferably tested. A few things that should be considered before we move forward with our implementation have to do with a sensor accidentally creating a Denial of Service (DOS) on our network. The following are topics that can have a positive and negative effect on our networks and must be considered carefully before implementation.

Knowing your network's entry points As mentioned earlier in the chapter about master blocking, there are times when we will have multiple entries to our networks. Be sure to locate each one of these entries and document their purpose and what type of services and traffic traverse each one. This is helpful in establishing our sensors in the correct places and utilizing master blocking to lock-down our networks. Hackers love a good challenge and finding the one spot that was overlooked during this lock-down is an excellent one.

Note

Nowadays, use of the terms hacker and cracker reflect a strong revulsion against the theft and vandalism perpetrated by cracking rings in the everyday understanding (or misunderstanding) of the terms. While it is expected that any real hacker will have done some playful cracking and knows many of the basic techniques, any true hacker past larval stage is expected to have outgrown the desire to do so except for immediate, benign, practical reasons (for example, if it's necessary to get around some security in order to get some work done).

Thus, there is far less overlap between hackers and crackers than the mundane reader misled by sensationalistic journalism might expect. Crackers tend to gather in small, tightly knit, very secretive groups that have little overlap with the huge, open polyculture of hackers. Though crackers often like to describe themselves as hackers, most true hackers consider them a separate and lower form of life.

Configuring the blocking duration When an alarm is triggered, the ACL is applied to the appropriate interface and the traffic violation is halted. The default duration for a Cisco Secure IDS to block the suspect traffic is 30 minutes. During this time, the network security team can research the problem and create a fix to prevent the issue from reoccurring or determine the necessary steps to pursue legal action. The blocking duration may be extended for times when network security staffing is unable to respond immediately, such as weekends or holidays. If the block has been set manually, the default blocking duration will be 1440 minutes, or 24 hours.

Clever anti-spoofing attacks Anti-Spoofing is accomplished by only allowing valid internal IP addresses to exit the network and disallow any incoming traffic with a source IP address that is used on the internal network. If a crafty cracker has a go at our network, the hacker may opt to create suspect traffic while using a valid internal network IP address, thus causing the monitoring sensor to create and apply an ACL that restricts a valid IP address or block of addresses. If this happens, we can see how legitimate internal clients may be cut off from needed network resources.

Note

Spoofing is when an external attacker infiltrates an internal network by using an IP address that is common to that internal network. The idea behind it is that the firewall will automatically assume the traffic is internal and allow it to pass to areas restricted to intranet clients.

Another popular choice for configuring firewalls is to disallow any external source IP addresses to establish a connection with any system within the internal network. If a valid remote connection is needed, a connection should be made directly to a firewall, remote access server, and so on located within the Demilitarized Zone (DMZ). From that point, the DMZ system can establish a secure (most likely authenticated) connection with the internal resources requested.

Choosing signatures Carefully performing this step will allow the monitoring sensor to perform its duties efficiently. If we chose to include every signature available to us while monitoring, a massive strain will be realized on the sensor and the potential for errors and missed packets increases. Thus, we will want to choose signatures that relate to the type of traffic and services being passed through our network. It is very easy for someone to run a utility that scans for these services and types of traffic and either explains how to take advantage of them or provides a list that the attacker can use to find their failings on one of hundreds of web sites out there.

Configuring & Implementing: Finding Vulnerabilities to Monitor
When we choose which signatures to configure, we should consider the way most attacks are constructed. Of course, we should first clarify that network attacks are becoming more complex and intricate everyday, yet most of them seem to follow a particular format. This process is important for any Security Administrator to understand and it will help us to decide which signatures to select.

The ease of performing a vulnerability assessment to determine weaknesses is rather frightening. Even more frightening are the so-called "Script Kiddies," who have no prior knowledge of the scanning tools they are using against your network and can produce volatile results.

The basis of most attacks is for the attacker to launch a scan of a network using particular tools to find out as much about a network as possible. This is called the reconnaissance phase of an attack, and can include DNS lookups and zone transfers, which could potentially provide an enormous amount of information about a company's web servers, such as server names, IP addresses, and operating systems. Once this is completed, a list of targets is now ready. Using any IP addresses the attacker found, a ping sweep could be launched to discover if any other vulnerable systems have been missed. While the ping sweep is in action, the attacker can then use the newfound information to scour the Internet and find potential vulnerabilities to try.

This is when it becomes crucial to know what services we are running. The attacker can connect to one of many web sites to find what vulnerabilities could be tried on the particular operating system. For instance, imagine an attacker found out we were running Microsoft IIS 5.0 on one of our web servers. The attacker could go to a hacker web site, run a search for "Microsoft IIS 5.0" and come up with a list of vulnerabilities to try and probably get the list in order of severity. These listed exploits, more than likely, will provide step-by-step instructions on how to perform the attack, (usually followed with the step-by-step instructions on how to fix them). Perhaps the vulnerability of a "built-in" administrator account or FTP domain authentication is discovered, we can only guess what would happen from that point on.

It should now be easy to see the importance of knowing what services we are running when picking our signatures. With more and more vulnerabilities being discovered daily, we can also see how important it would be to keep our signatures up-to-date with Cisco-provided updates.

If properly prepared, it may be reasonable to run a vulnerability scan on our own networks. However, vulnerability scanning can put a major strain on our networks and perhaps create the unwanted Denial-of-Service conditions we are trying to avoid. The best option for this is to know exactly what the pros and cons are of particular scanning tools and note which tool would be the best choice for our situation. Owners of critical systems should be made aware of, and be present during, a vulnerability scan in the event something should go awry.

Defining your critical hosts This is a step that will help in the preceding step as well, Choosing Signatures. It's important to find critical systems that may need to perform their functions free of blocking. Examples include: DNS Servers, Windows Domain Controllers, and WINS and DHCP servers. The Secure IDS Sensors and Director will also need to be free from the potential of blocking. These systems may be detrimental to a company's productivity if blocked. Thus, you should have local security controls in place so Cisco Secure IDS can perform tasks such as logging and trigger alarms without the use of IP blocking.

Where Should I Put My Access Control Lists?

As we know from earlier in the chapter, we can only have one ACL applied to an interface in a specified direction—for instance, Serial 0 out. If a specific interface and direction has been previously configured with an ACL manual, when a sensor is appointed to monitor that interface, it will replace that ACL with the sensor-generated one, thus replacing the manually configured ACL. If, for some reason, the manually configured ACL is using the same ACL number the sensor does, 198 or 199, the ACL will simply be replaced with the new sensor-generated one. The sensor's ACL will take priority over whatever ACL is currently in place and will not merge any of the two rules sets together.

The ACL may be configured for either the internal interface of a router, facing the Internet, or the internal interface, facing the internal network. There are both good and bad results from either method chosen. Before we decide on an interface, we will want to consider the direction the traffic will be heading. For instance, if traffic from an internal system enters a router on Serial 0 and exits to the Internet on Serial 1, the traffic direction will be "in" for Serial 0 (into the router), and "out" for Serial 1 (out of the router).

When applying an ACL to an external interface, we are essentially keeping any external traffic from even entering the router. This traffic could include different types of network-scanning tools, Internet broadcast advertisements and so forth. This is a highly protective state and if all the services and network traffic needed by the internal network are well defined, it can be a good choice. With the external "inbound" ACL in place, denied data packets not processed by the router will allow the router to perform its duties free of wasteful excess processing power. The external packets will be dropped at the door.

When configuring an ACL to an internal interface "outbound," the data packet enters the router and is processed and sent to the correct interface to traverse the router. When the packet is switched to the correct interface, the ACL will be checked to see if the data packet will be allowed to proceed into the Internal network. As you can imagine it is less then desirable to have our routers processing packets only to have them dropped afterwards at the interface. The packets are also reaching the network device, which is not quite network-security friendly.

It seems obvious that performing blocking on the external interface "in" would be the best solution. However, it may be suitable to perform IP blocking on the internal "out" interface. This may be because there already exists an external "in" ACL and the only option for the sake of stability is to configure the internal "in" interface. If a DMZ is in place, we may need to allow some traffic to enter the router and proceed to that DMZ and at the same time deny that very traffic from entering our local network. This situation could include a general ACL on the external "in," with regards to ICMP echo requests and perhaps some unneeded ports, and two internal "out" interfaces (one for each internal interface). Now its time to turn our attention to how we can configure our sensors to react to triggered alarms and how our routers can accept requested modifications.

Using ACLs to Perform Blocking