Cisco IPS sensor scenario two – Inline Interface Pairs

For all of you that are like me preparing for CCIE Security lab exam and are practicing IPS sections, I will try to do IPS 6.x in GNS3 lab environment. There are good chance that CCIE Security is shifting from blueprint 3 to 4 and my guess is that they will use version 7.x of IPS code, but not to worry: all major concepts are the same aside from some new features such as Global Correlation. I could do this tutorial in 7.x as well but this could be only done in real environment, not the GNS3 and not all of us are able to buy an IPS device.

Ok. Let’s start with the assumption that we know how to install and setup GNS3. This article amazed me first time I looked at it. Hope that author won’t mind using his link here. It is about setting GNS3 to work with IPS 6.x.

Like always we start with a blueprint:

Topology IPS 1

We have two routers acting hosts, IPS in Inline Interface Pairs mode and a laptop with IDM on it. The laptop is connected to IPS’ management interface via loopback interface. You can read one of previous articles to learn more about adding a loopback interface.

First we power on all devices and make a console connection to them. Connect to IPS and wait until the analysis engine has done it’s job of building some internal tables. Be patient, this can take some time:

sensor#
sensor# show statistics analysis-engine
Error: getAnalysisEngineStatistics : Analysis Engine is busy
sensor#

We should not try anything while the analysis engine is busy. Be patient! We want to see this:

sensor#
sensor# show statistics analysis-engine
Analysis Engine Statistics
   Number of seconds since service started = 377
   The rate of TCP connections tracked per second = 0
   The rate of packets per second = 0
   The rate of bytes per second = 0
   Receiver Statistics
      Total number of packets processed since reset = 0
      Total number of IP packets processed since reset = 0
   Transmitter Statistics
      Total number of packets transmitted = 0
      Total number of packets denied = 0
      Total number of packets reset = 0
   Fragment Reassembly Unit Statistics
      Number of fragments currently in FRU = 0
      Number of datagrams currently in FRU = 0
   TCP Stream Reassembly Unit Statistics
      TCP streams currently in the embryonic state = 0
      TCP streams currently in the established state = 0
      TCP streams currently in the closing state = 0
      TCP streams currently in the system = 0
      TCP Packets currently queued for reassembly = 0
   The Signature Database Statistics.
      Total nodes active = 0
      TCP nodes keyed on both IP addresses and both ports = 0
      UDP nodes keyed on both IP addresses and both ports = 0
      IP nodes keyed on both IP addresses = 0
   Statistics for Signature Events
      Number of SigEvents since reset = 0
   Statistics for Actions executed on a SigEvent
      Number of Alerts written to the IdsEventStore = 0
   Inspection Stats
  

sensor#

While we wait for this magic to happen we could check on Java version. Some newer versions just won’t work with this version of IPS/IDM. I suggest that we use version 6 update 7. Select Java applet from the Control Panel and check the version:

Java Version

We also must make sure that appropriate runtime parameters are set as per IDM requirements:

Java Runtime 1

Java Runtime 2

By now IPS should be done building it’s tables and we may do a quick CLI setup:

sensor#
sensor# setup

    — System Configuration Dialog —

At any point you may enter a question mark ‘?’ for help.
User ctrl-c to abort configuration dialog at any prompt.
Default settings are in square brackets ‘[]’.

Current Configuration:

service host
network-settings
host-ip 192.168.1.2/24,192.168.1.1
host-name sensor
telnet-option disabled
ftp-timeout 300
no login-banner-text
exit
time-zone-settings
offset 0
standard-time-zone-name UTC
exit
summertime-option disabled
ntp-option disabled
exit
service web-server
port 443
exit
service event-action-rules rules0
overrides
override-item-status Enabled
risk-rating-range 90-100
exit
exit

Current time: Wed Feb 15 17:21:19 2012

Setup Configuration last modified: Wed Feb 15 17:17:12 2012

Continue with configuration dialog?[yes]:
Enter host name[sensor]: IPS1
Enter IP interface[192.168.1.2/24,192.168.1.1]: 1.1.1.2/24,1.1.1.1
Enter telnet-server status[disabled]:
Enter web-server port[443]:
Modify current access list?[no]: yes
Current access list entries:
  No entries
Permit: 1.1.1.1/32
Permit:
Modify system clock settings?[no]:
Modify interface/virtual sensor configuration?[no]:
Modify default threat prevention settings?[no]: 

The following configuration was entered.

service host
network-settings
host-ip 1.1.1.2/24,1.1.1.1
host-name IPS1
telnet-option disabled
access-list 1.1.1.1/32
ftp-timeout 300
no login-banner-text
exit
time-zone-settings
offset 0
standard-time-zone-name UTC
exit
summertime-option disabled
ntp-option disabled
exit
service web-server
port 443
exit
service event-action-rules rules0
overrides
override-item-status Enabled
risk-rating-range 90-100
exit
exit
[0] Go to the command prompt without saving this config.
[1] Return back to the setup without saving this config.
[2] Save this configuration and exit setup.

Enter your selection[2]:
Configuration Saved.
*17:22:11 UTC Wed Feb 15 2012
Modify system date and time?[no]:
IPS1#
IPS1#

As we can se we assigned the IP address 1.1.1.2/24 to the sensor and we will use IE to connect to this address (https://1.1.1.2) and start the IDM.

Now we should enable two interfaces we are about to use for interface pairs. Go to Configuration->Interfaces, select both GigabitEthernet0/1 and GigabitEthernet0/2, click Enable and then Apply:

Enable Interfaces

After this we need to create an interface pair, which is kind of a logical interface we are going to assign to one of four virtual sensors. Click Interface Pairs->Add. Type a name and select previously enabled interfaces. Click OK and Apply:

Interface Pair

Now we must assign this interface pair to a sensor. The easiest way is to assign it to default virtual sensor which is vs0. Under the Analysis Engine select Virtual Sensors->vs0->Edit and select desired interface pair, click Assign and then Apply:

Assign Interface Pair

Now it’s time to set up routers. Only the basic configs. IMPORTANT: the IPS is NOT a router so we have to assign both router’s interfaces IP addresses from the same subnet, in this case 10.0.0./24. If our scenario is such that routers and IPS are connected through the switch and not directly, make sure that R1’s FastEthernet0/0 and IPS’ GigabitEthernet0/1 are in *different* VLAN than R2’s FastEthernet0/0 and IPS’ GigabitEthernet0/2 and that both router’s IPs share the same IP segment. This way all traffic will flow through the sensor.

R1

Router>
Router>
Router>en
Router#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#host R1
R1(config)#int f0/0
R1(config-if)#ip addr 10.0.0.1 255.255.255.0
R1(config-if)#no sh
R1(config-if)#end
R1#

R2

Router>
Router>
Router>en
Router#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#host R2
R2(config)#int f0/0
R2(config-if)#ip addr 10.0.0.2 255.255.255.0
R2(config-if)#no sh
R2(config-if)#end
R2#

It’s a good idea to verify that the traffic is actually going through the sensor. This will make a troubleshooting easier later on. In the IPS console issue “packet display gigabitEthernet0/1” and do a ping from R1 to R2:

R1#
R1#ping 10.0.0.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 20/39/56 ms
R1#

IPS1#
IPS1# packet display gigabitEthernet0/1
Warning: This command will cause significant performance degradation
tcpdump: WARNING: ge0_1: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ge0_1, link-type EN10MB (Ethernet), capture size 65535 bytes
18:01:23.852717 CDPv2, ttl: 180s, Device-ID ‘Router’, length 332
18:01:24.992332 arp who-has 10.0.0.2 tell 10.0.0.1
18:01:25.065620 arp reply 10.0.0.2 is-at c4:01:2d:f0:00:00 (oui Unknown)
18:01:26.972277 IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 0, seq 1, length 80
18:01:27.012886 IP 10.0.0.2 > 10.0.0.1: ICMP echo reply, id 0, seq 1, length 80
18:01:27.022241 IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 0, seq 2, length 80
18:01:27.032493 IP 10.0.0.2 > 10.0.0.1: ICMP echo reply, id 0, seq 2, length 80
18:01:27.042216 IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 0, seq 3, length 80
18:01:27.091752 IP 10.0.0.2 > 10.0.0.1: ICMP echo reply, id 0, seq 3, length 80
18:01:27.102200 IP 10.0.0.1 > 10.0.0.2: ICMP echo request, id 0, seq 4, length 80
18:01:27.112441 IP 10.0.0.2 > 10.0.0.1: ICMP echo reply, id 0, seq 4, length 80
17 packets captured
17 packets received by filter
0 packets dropped by kernel
IPS1#

So all is ok. Now let’s try to fire some alarm. We can edit a signature and try to trigger it. The easiest way is to enable signature ID 2004 – ICMP Echo Request. Under Policies->Signature Definitions->sig0 select Sig ID, type 2004 and click Find. Click Enable and Apply:

Enable Sig 2004

Now let’s do a ping again:

R1#
R1#ping 10.0.0.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/42/120 ms
R1#

To check if the signature fired go to Monitoring->Events and click View. Find two events. First is the first ping that triggered the alarm:

ICMP Event

and second is the “summary event” that says we got hit five times, each time for one ping:

ICMP Summary

It has been fun so far, but let’s make it even more fun. Let’s adjust this signature to block pings from R1 to R2. Find the signature 2004, click Actions and select Deny Attacker Inline:

ICMP Deny Attacker Inline

Now let’s try to ping:

R1#
R1#ping 10.0.0.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)
R1#

We can prove that this is not a network issue but rather the event we wanted. View events and find ICMP signature and verify that action has been taken:

ICMP Denied Attacker

We could also verify that the R1 is actually blocked by going to Monitoring->Denied Attackers:

Denied Attackers

So that’s it! You can practice a little bit with other signatures or make your own, say block telnet from R1 to R2 if we issue “erase startup-config” command. In the next article we will discuss Inline VLAN Pair mode of operation.

Advertisements
This entry was posted in Cisco, GNS3, IPS and tagged , , , , . Bookmark the permalink.

15 Responses to Cisco IPS sensor scenario two – Inline Interface Pairs

  1. Pingback: Blocking/shunning attackers with Cisco IPS and ASA | popravak

  2. Pingback: Cisco IPS scenario three – Inline VLAN Pairs | popravak

  3. Bikas Pandey says:

    Hi ,

    When i try to enable the signature it takes so much time and finally through an error stating that the request can not completed at this time. Can you help me with the setting you used for the IPS in gns3 to successfully tune the signature.

    • Sasa says:

      Well, the most common reason for this, at least in a virtualized environment, is that the signature engine is not ready. When you power on the sensor, give it some time. You can view the status of the signature engine from the CLI, using show commands.

      Hope this helps.

  4. Bikas Pandey says:

    Hi Sasa,

    It take about 2-3 hour but no luck and then through error that it can not process the request.

    • Sasa says:

      Well, try enabling signature from the CLI. This way you will rule out Java issues. The IPS is *very* sensitive when the Java version is in question.

      • afifi says:

        how to enable signatures through CLI

      • Sasa says:

        Here is the example of enabling, for example, ICMP Echo Request (SIG_ID:2004/0) for sig0 set:

        SensorDC1#
        SensorDC1# conf t
        SensorDC1(config)# service signature-definition sig0
        SensorDC1(config-sig)# signatures 2004 0
        SensorDC1(config-sig-sig)# status
        SensorDC1(config-sig-sig-sta)# enabled true
        SensorDC1(config-sig-sig-sta)# exit
        SensorDC1(config-sig-sig)# exit
        SensorDC1(config-sig)# exit
        SensorDC1(config-sig)# exit
        SensorDC1(config)# exit
        SensorDC1#

        Hope this helps.

  5. Bikas Pandey says:

    Hi Sasa,

    I tried enabling signature using CLI but no luck. It stuck on processing the changes and takes 2-3 hour without success.

  6. Abrham says:

    hey i tried this lab but i couldnt ping router 2 from router 1 and vise verse

    • Sasa says:

      Please double check everything. The most important thing is that both R1 and R2 *must* be in the same LAN segment. You may also try log to the IPS CLI and issue “packet display gigabitEthernet0/1” and “packet display gigabitEthernet0/2” to make sure the IPS actually receives the traffic. If not, there could be a GNS3/Qemu issue.

      • Abrham says:

        thank you Sasa , the ping is working fine . the other problem that i am facing right now is as follows :-
        1 when ever i tried to enable signatures it takes too long and finally it end up with error
        2 when ever i tried to assign interface pair to virtual sensor (vs0) it takes too long and finally it end up with error and now am trying it using CLI and it almost took around 40 min but no changes .
        is there any way that you can help me with this problems .

        conf t
        service analysis-engine
        virtual-sensor vs0
        logical-interface MY-PAIR
        exit
        apply changes?[yes]:

      • Sasa says:

        Well, it is a GNS3/Qemu issue. Not sure how you can correct this. Maybe trying with more resources or waiting for analysis engine to be ready after power on, before making any changes. Please see a note regarding show statistics analysis-engine command mentioned in the blog post. You could also try running an IPS on the Linux box. I didn’t do that myself, but sometimes some things go better in Linux 🙂

  7. Jay says:

    Hey Sasa,

    I had the same problem as Abrham but not as bad as far as analysis-engine taking so long, and I followed all of your suggestions but I can’t get traffic to pass through the IPS. When I perform a packet display on the IPS I can see that the IPS is receiving traffic on both interfaces of the inline pair but traffic will not go through. I’ve tried directly connecting to Routers together like your inline pair diagram, I’ve tried going through an Ethernet switch, I’ve tried using the 3725 Router with the switch port module access ports connected to the IPS as well as some other type connection methods but none work but the IPS does receive traffic. I wanted to get your feedback on what could be causing this problem.

    Take Care,

    ____________________

    Im running:

    GNS3 0.8.6
    Router 3725-Advipservices9-mz.123.14.T7 with NM-16ESW
    Qemu Options: -smbios type=1,product=IDS-4235,serial=12345789012,uuid=E0A32395-8DFE-D511-8C31-001FC641BA6B,sku=011,family=IDS-4235/4250

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s