Understanding the Blocking Process
Threats to our networks never sleep or wait until Monday to
become a burden. While there are many mitigating tools available to the security
administrator such as firewalls, password security, encryption standards, and
even complex networks with private IP addresses, malicious traffic still seems
to find its way into the network. Hence, we have the need for network intrusion
detection systems, or NIDSs, to find these intruders and make the
administrator's aware of the threats to their network and data.
However, Security Administrators and their teams may not always be
available and nobody likes to be awoken in the middle of sleep, or called while
vacationing in Bermuda, to find out their network has just been a victim of a
Denial-of-Service attack, web defacement, or worse. This is where IP blocking
can come in handy. Instead of just watching, logging, and sending alerts as
malicious activity happens on the network, blocking can be put in place to
dynamically stop intruders and allow ample time for someone to take the needed
corrective actions.
If blocking is configured correctly, it can also stop this traffic
from using any other possible entrances to the same network, say from a
redundant connection with a different ISP, and keep the unwanted traffic out
however long the Security Administrator has configured it to do so. We can see
in Figure
8.1 that the IDS sensor can send the Access Control List "199" to both
Internet bordering routers, thus effectively keeping the attacker from entering
the network at either point. Now the Security Administrator can rest easier and
handle the problem when he is ready to handle the problem, not work according to
the attacker's schedule.
What Is Blocking?
So what actually is IP blocking? IP blocking is very much as it
sounds, when a Cisco Secure IDS sensor detects malicious behavior, IP blocking
is implemented to deny further network traffic entering our network from the
identified source host IP address. What's more, we can configure what specific
traffic patterns, or signatures, we want the intrusion
detection system (IDS) to watch for and manage according to an
administrator-assigned severity level.
IP blocking makes use of Access Control Lists (ACLs) to stop the
suspect traffic from entering the network and will block the network traffic
until the block is either manually removed or it exceeds it's predetermined blocking duration.
Access Control Lists
At this point, it is important to have a thorough understanding of
Cisco's Access Control Lists (ACLs), sometimes simply referred to as
access-lists. There are two main types of ACLs we will be concerned with in this
chapter. These are the Standard Access Control List and the Extended Access
Control List. A number that is assigned to them can quickly identify these two
types of ACLs. Two steps must be followed when creating an access-list. The
first step is to create the list itself and the second is to apply the list to
an interface.
Step 1: Standard Access-Lists
These ACLs are used in situations when we only
want to block a source IP host address or an entire network IP address from
accessing a certain network. This is specifically working with the IP addresses
and not giving any mind to other information, such as port number or protocol.
The number assigned to a standard access-list will be in the range of 1–99, and
an expanded range of 1300–1999. Here is the basic format of a standard
access-list:
access-list access-list-number [permit|deny] [source-ip-address] [source-
wildcard]
Here is an example:
access-list 19 permit 172.16.2.0 0.0.0.255
The access list components are as follows:
-
access-list The command used to initiate
the creation of an access-list
-
access-list-number A number within the
range previously specified for the type of access-list being created.
-
[permit|deny] This tells the network
device to either "permit" the traffic to pass the interface or to "deny" the
traffic from passing and drop the traffic.
-
source-ip-address Indicates the
particular host IP or network IP address to be checked.
-
source-wildcard Used to indicate an
actual host, subnet, or network. This is broken down into comparing subnet masks
and the ip address. A "0" indicates the number in its respective octet matches
perfectly. Any "1s" indicate any number can be used. For instance, in the
example, for any ip to be matched by the access-list, 172.16.2 must be the first
part of the IP address. The last octet can be anything from 0–255. The example
"permits" any traffic from the IP range of 172.16.2.1–172.16.2.254 to pass the
network device's interface.
|
Note |
More on wildcard masks and their usage can be found in
various articles at www.cisco.com. |
Let's look at an example to better understand how this
configuration works on a network referring to Figure 8.2.
Let's say Client1 on the Network XYZ needs access to resources
located on the Network ABC. By using an access-list we can provide this
admission and still protect the network from others trying to enter. Here is the
configuration shown as an excerpt from a show run
command:
Router1
!
interface Serial0
ip address 192.168.0.1 255.255.255.252
ip access-group 10 in
!
access-list 10 permit 10.0.0.10
!
Notice the access-list has been applied to the Serial0 interface
on Router1 with the ip access-group 10 in statement. This
configuration will permit only incoming traffic from the address 10.0.0.10, and
allow it access to the entire ABC network.
If it were desired to block Client1 on XYZ and allow the rest of
the network, we would use the configuration:
Router1
!
interface Serial0
ip address 192.168.0.1 255.255.255.252
ip access-group 10 in
!
access-list 10 deny 10.0.0.10
access-list 10 permit any
!
This configuration will allow all users to access every area of
the network except Client1. Keep in mind that access-lists are read from top to
bottom. When a match is found, that match will be used and the router stops
comparing the packets to the access-list. Therefore, once the router reads the
"permit any" statement, it will stop reading and simply allow "any" address
through. Also, the most heavily matched items should be placed at the beginning
of the access-list to help ease the CPU load.
|
Note |
Not shown in the configuration is an implicit "deny all"
statement. This does not need to be manually edited because it is automatically
applied. This is a wonderful security feature, but if you are not aware of its
existence, it can lock out all critical systems attempting to access resources
on the network. As in the preceding configuration, only the host 10.0.0.1 will
be allowed to traverse Router1. All other traffic attempting to enter this
interface will be dropped. |
Step 2: Extended Access-Lists
These ACLs give us much more depth in how to control network
traffic. Extended access-lists can be configured to check port number, protocol,
and the destination address as well as the source address. The number assigned
to an extended access-list is in the range of 100–199, and an expanded range of
2000–2699. Here is the basic format of an extended access-list:
access-list access-list-number [permit|deny] protocol source ip address
source-wildcard destination destination-wildcard [operator]
Here is an example:
access-list 190 deny TCP 172.16.1.0 0.0.0.255 172.16.2.0 0.0.0.255 neq 23
The extended access-list is different than the standard ACL in the
following ways:
-
access-list-number This is a number
within the range previously specified for the type of access-list being created.
In this case, it is an extended access-list, as indicated by the 190.
-
protocol This allows us to filter based
on a particular protocol—typically, IP for filtering by IP address or TCP for
filtering by protocol.
-
destination This is the destination IP
address a particular packet is trying to reach. In the example, it is the
network address of 172.16.2.0.
-
destination-wildcard This works as the
source-wildcard to indicate the host IP address or range of IP addresses trying
to be reached. This saves the time of having to type lines for each IP address
within a particular subnet.
-
Operator This can be used to indicate a
port number when filtering by protocol, such as TCP or UDP. There are four
options that can be used with this feature.
-
eq Equals—when we know exactly what port
needs to be monitored
-
gt Greater than—allows us to specify a
particular range over a particular port number
-
lt Less than—allows us to specify a
particular range lower than a particular port number
-
neq Not equal—allows us
to assert the access-list to all but on port
Let's now see how this works on a network. Refer to Figure
8.3.
Looking at this network example, imagine that all the clients need
access to the e-mail server and only Client3 needs Telnet access to the payroll
server. Our configuration would look similar to this:
Router1
!
interface Ethernet1
ip address 172.16.2.1 255.255.255.0
ip access-group 110 out
!
access-list 110 permit tcp 172.16.1.30 any eq telnet
access-list 110 deny tcp any 172.16.2.10
access-list 110 permit tcp 172.16.1.0 0.0.0.255 any
!
This access-list configuration first allows Client3 to access to
the Demilitarized Zone (DMZ) and specifically access the payroll server using
Telnet (indicated by eq). The next line in the access-list is to deny anyone to
access the payroll server. Notice this comes after the line that allows Client3
access to the same server. Remember, when the router finds the first match, it
will stop reading and take action. The third line allows anyone from the
internal network 172.16.1.0 to access any resource and any protocol, and so on,
not already denied, on the DMZ. If a match is still not found, the implicit deny
will drop all remaining network traffic trying to access the DMZ.
One condition we used in the preceding configuration had to do
with whether we applied the access-list to an internal or external interface and
the particular direction of the traffic flow. In the last example, we can see
the ACL was applied to an external interface, in relation to the internal
network. We also have the command "out" used. This means that traffic trying to
leave the router on the Ethernet1 interface will be checked. The first example,
Figure
8.1, used an ACL on the Serial0 interface, applying the in command. This prevents the network traffic specified in
the ACL from entering the router. The traffic is then dropped right at the front
door.
|
Note |
Only one access-list can be applied to an
interface/direction at a time. If another ACL is applied to the same
interface/direction, the original ACL will be nullified.
|
IP blocking relies on a system that will compare inbound and/or
outbound IP datagrams on a particular interface to a list of signatures and
trigger an alarm if a match is made. The alarm will indicate to the governing
sensor that there is a threat. At this point, the sensor will create a new ACL
and distribute that ACL to the network device providing access to the network in
jeopardy. When the new ACL reaches the network device, it will replace the
resident ACL with the newly arrived one, thus dynamically updating the network
device. This process is referred to as Device
Management.
Device Management
The process of device management includes the
construction of a new ACL and applying that ACL to the appropriate network
device interface thus stopping, or blocking, the network breach immediately. As
mentioned earlier, the block will remain in effect until either it has been
removed manually or the blocking duration has expired. Device management relies
on a Telnet connection, via its command and control interface, to the network
device in question. For the sensor to successfully Telnetted to the network
device, it requires the following:
-
There must be a route to the network device within the
device management list on the sensor or the sensor must reside within the same
subnet as the network device.
-
The network device must be configured to accept Telnet
connections by configuring the vty lines with a login password and, if used, a
Telnet username, and allow secure configuration changes by setting an enable
password.
It is important to keep in mind that the IDS sensor will be
contacting the router with an enable-privileged password. This could foster an
insecure environment if this password were to get out. When possible, it is
recommended to keep the Telnet sessions isolated to a "Telnet only" network.
Another option is to apply ACLs to lock down all Telnet access to the network
device except from approved systems and/or users.
Device management uses extended ACLs to provide its blocking
functionality. The ACLs are 198 and 199. The first ACL to be used by Device
Management is 199. When a change is demanded via an alarm from the sensor,
Device Management will create a new ACL—that's right, 198—and send it to the
rescue.