Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
cancel

ASK THE EXPERT – TROUBLESHOOTING INTRUSION PREVENTION SYSTEMS

Welcome to the Cisco Networking Professionals Ask the Expert conversation. This is an opportunity to discuss with Cisco expert Nadeem Khawaja how to troubleshoot IPS.

Nadeem Khawaja supports various security offerings by Cisco Systems, Inc. including Cisco Secure PIX / ASA Firewall, Cisco IOS Firewall, Cisco Secure Access Control Server UNIX & Windows NT, Cisco Secure Intrusion Prevention Systems and Cisco Secure VPN at the High Touch Technical Support (HTTS).

Remember to use the rating system to let Nadeem know if you have received an adequate response.

Nadeem might not be able to answer each question due to the volume expected during this event. Our moderators will post many of the unanswered questions in other discussion forums shortly after the event. This event lasts through April 7, 2006. Visit this forum often to view responses to your questions and the questions of other community members.

64 REPLIES
Community Member

Re: ASK THE EXPERT – TROUBLESHOOTING INTRUSION PREVENTION SYSTE

Hi Nadeem,

My question is not so much a troubleshooting question but more of one relating to a change in the way we see items in v4 verse those of v5.

Could you tell me what the equivalent of “capture trigger packet” is in v5 and how do you enable that in ipsmc 2.2

What is the equivalent of iplogging and how do you enable it per signature in ipsmc 2.2

In v4, we were able to use tcpdump. Is that still possible in v5? One thing that is noticeable is when in service mode the capture interface is by default not up and needs to be forced before you can use tcpdump.

Thanks in advance

Silver

Re: ASK THE EXPERT – TROUBLESHOOTING INTRUSION PREVENTION SYSTE

Hi,

Thanks for your question. Please see inline

Could you tell me what the equivalent of “capture trigger packet” is in v5 and how do you enable that in IPSMC 2.2

>> I think it is log attacker/victim/pair packet

What is the equivalent of iplogging and how do you enable it per signature in ipsmc 2.2

>> It should be the same as log attacker/victim/pair packet

In v4, we were able to use tcpdump. Is that still possible in v5? One thing that is noticeable is when in service mode the capture interface is by default not up and needs to be forced before you can use tcpdump.

>>tcpdump can still be used, or use packet command. yes interface needed to bring up.

for enabling iplogging through IPSMC2.2 you need to set the event actions

please check this link for more details

http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cw2000/mgt_ids/idsmc21/ips21ug/ch05.htm#wp857962

Configuring IPlogging through CLI

http://www.cisco.com/univercd/cc/td/doc/product/iaabu/csids/csids12/cliguide/cliiplog.htm

thanks

Nadeem

Silver

Re: ASK THE EXPERT – TROUBLESHOOTING INTRUSION PREVENTION SYSTE

little correction to above reply

Could you tell me what the equivalent of “capture trigger packet” is in v5 and how do you enable that in IPSMC 2.2

For capture trigger packet you use "produceVerboseAlert" as the action.

Community Member

Re: ASK THE EXPERT – TROUBLESHOOTING INTRUSION PREVENTION SYSTE

Hi,

I reimaged my IDSM2 sensor in the following sequence:

1. Installed WS-SVC-IDSM2-K9-sys-1.1-a-5.1-1.bin.gz

2. Installed IPS-sig-S222-minreq-5.0-5.pkg

I am able to launch IPS DM and work with it. But, I get the following errors when I type "show events" on IDSM-2 CLI.

-------------------------------

evError: eventId=1143377080627763538 severity=warning vendor=Cisco

originator:

hostId: RCIPS

appName: cidwebserver

appInstanceId: 2731

time: 2006/03/26 11:45:53 2006/03/26 14:45:53 UTC

errorMessage: name=errWarning received fatal alert: certificate_unknown

evError: eventId=1143377080627763539 severity=error vendor=Cisco

originator:

hostId: RCIPS

appName: cidwebserver

appInstanceId: 2497

time: 2006/03/26 11:45:53 2006/03/26 14:45:53 UTC

errorMessage: name=errTransport WebSession::sessionTask(10) TLS connection exception: handshake incomplete.

-------------------------------

I am not sure how to get out of these errors.

Please help. Thanks.

Silver

Re: ASK THE EXPERT – TROUBLESHOOTING INTRUSION PREVENTION SYSTE

Hi,

FYI,

These errors shows incomplete SSL/TLS sessions to HTTPS on the sensor. Its possible to see these errors when management software connects to the device.

There is an enhancement request filed on these errors to provdie the IP addresses of the remote hosts.

The broken handshake messages are benign. They would only be a concern if the number was excessive, in which case a denial of service attack may be in progress. When they appear at regular intervals it indicates an RDEP client is misconfigured.

RDEP clients, such as IEV and SecMon, use TLS (formerly known as SSL) to secure the communications. The client keeps a copy of the certificate it received from the web server on the sensor. When it connects again later, it compares the certificate received with the original. If the

certificates match, the RDEP client can be sure that it is in communication with the sensor, and not an attacker attempting to pose as the sensor. When the certificates do not match, the RDEP client immediately disconnects and the error messages that were provided by the customer are written to the log. IEV and SecMon will keep trying to connect, and until the certificate problem is fixed, they will fail.

There are a number of reasons why the certificate on a sensor is re-generated. The most common causes are: (1) the user issues the "tls generate-key" CLI command, (2) the user changes the IP address of the sensor, (3) the user issues the "recover" CLI command, and (4) the user re-images the sensor using the CD. In each case, any existing RDEP clients that were subscribing to the IDS event feed will become disconnected.

While the error messages in the log are noisy and somewhat annoying, the sensor should continue to operate normally. Other properly configured RDEP clients should be able to get events.

Thanks

Nadeem

Community Member

Re: ASK THE EXPERT – TROUBLESHOOTING INTRUSION PREVENTION SYSTE

I did try enabling “produce verbose alert” earlier on in our implementation but I had some problems view the triggered packet from within SecMon 2.2. In SecMon you can right click on the alert and then use tool/ trigger packet to view the details but I had no success with this.

It did work for us in version 4.

Silver

Re: ASK THE EXPERT – TROUBLESHOOTING INTRUSION PREVENTION SYSTE

Now that could be a different issue.

You need to look at the alert a seen by "show events" on the CLI to see if the trigger packet is being attached with the "produceVerboseAlert" event action.

If the trigger packet is their, but SecMon is not able to view it, then it would be considered a SecMon issue.

Community Member

Re: ASK THE EXPERT – TROUBLESHOOTING INTRUSION PREVENTION SYSTE

HI! Nadeem

My question is not exactly about the troubleshooting but want to clear some queries from you.

First which are the companies providing the Internet over satellite in middle east and west asia.

Second, how the PIX is being use in IOS web VPN and Broadband connection simultaneously.

Thanks in advance.

M.SARASWAT

Silver

Re: ASK THE EXPERT – TROUBLESHOOTING INTRUSION PREVENTION SYSTE

Hi Saraswat,

Thanks for your questions. I would not be able to answer them as they are out of scope on this forum.

Please post the question on Firewall Forum.

Thanks

Nadeem

Community Member

Re: ASK THE EXPERT – TROUBLESHOOTING INTRUSION PREVENTION SYSTE

Hi Nadeem,

I have a question about troubleshooting load/capacity on the IDS sensor. We enable sig 993 Missed Packet Count with the following thresholds:

MpcPercentThreshold: 1

MpcTimeout: 10

One of our sensors, a 4250-SX continually fires this event every 1 to 5 minutes, sometimes more often. The sensor is running software version 4.1(5).

From the sensor's IDM, Monitoring > Statistics

VirtualSensor0

General Statistics for this Virtual Sensor

Number of seconds since a reset of the statistics = 431582

Measure of the level of resource utilization = 0

Total number of packets processed since reset = 46240405

Total number of IP packets processed since reset = 45938195

Total number of packets that were not IP processed since reset = 302210

Total number of TCP packets processed since reset = 40950104

Total number of UDP packets processed since reset = 4983779

Total number of ICMP packets processed since reset = 4312

Total number of packets that were not TCP, UDP, or ICMP processed since reset = 0

Total number of ARP packets processed since reset = 302210

Total number of ISL encapsulated packets processed since reset = 0

Total number of 802.1q encapsulated packets processed since reset = 0

Total number of packets with bad IP checksums processed since reset = 0

Total number of packets with bad layer 4 checksums processed since reset = 4

Total number of bytes processed since reset = 17655026574

The rate of packets per second since reset = 107

The rate of bytes per second since reset = 40907

The average bytes per packet since reset = 381

Given the bytes/sec,

40907*8 = 327256 bps or 0.33 Mbps

This is a far cry from the 350 Mbps that the 4250-SX is capable of. I can't imagine the sensor is actually not able to keep up with this small amount of traffic.

http://www.cisco.com/en/US/products/hw/vpndevc/ps4077/products_data_sheet09186a008014873c.html

Is there a way to find out which signature may be consuming the sensor's resources? A load check of the sensor from shell (via service account) does not show the CPU load to be very high.

Community Member

Re: ASK THE EXPERT – TROUBLESHOOTING INTRUSION PREVENTION SYSTE

Hi,

I have an IDSM2 running IPS5.1(1) S222.0 upgraded recently from 4.x.

My network has windows desktops, spanned on multiple VLANs. Cisco 6500 FWSM module routes between these VLANs and is the default gateway for each of these desktop VLANs.

Since I upgraded to IPS 5.x, I am seeing lots and lots of TCP Hijack and TCP Segment Overwrite alarms. The source addresses of these alarms are my windows PCs, destination addresses are Windows 2003 servers..There is no pattern. All traffic that crosses my firewall module is being marked as "TCP Segment Overwrite" or "TCP Hijack"

It is difficult to ignore so many alarms unless there is a technical explanation to see if the placement of FWSM is causing IPS to treat this traffic as malicious.

I was not seeing these alarms when I had IDSM-2 with 4.x software

Please guide me to troubleshoot this issue.

regards,

Vasanth

Silver

Re: ASK THE EXPERT – TROUBLESHOOTING INTRUSION PREVENTION SYSTE

Hi Vasanth,

Thanks for your question. I think you are facing this bug CSCsd00877.

Here is the detail

Symptom:

TCP Hijack signatures (3250,3251) fire at random times and there is no hijack or traffic

that appears to be a hijack occuring.

Conditions:

A IPS sensor in promisc mode will sometimes fire a hijack signature when none of the

traffic that should trigger the signature is observed.

Workaround:

Set enabled: false for the signatures until this DDTS is resolved

Community Member

Re: ASK THE EXPERT – TROUBLESHOOTING INTRUSION PREVENTION SYSTE

Hi Nadeem,

Thanks for the bug ID and explanation. The bug covers 3250 and 3251.

What about TCP Segment Overwrite - Sid ID 1300 that is being fired in my network. Even that is random and there is no pattern.

Silver

Re: ASK THE EXPERT – TROUBLESHOOTING INTRUSION PREVENTION SYSTE

How are you monitoring your traffic, is it before and after the firewall both?

Here is a descripton of this signature

-----------------------

TCP Segment Overwrite

Description: This signature fires when one or more TCP segments in the same stream

overwrite data from a one or more segments located earlier in the stream. This may

indicate an attempt to hide an attack. Overwriting TCP segments do not normally occur and

should be treated with suspicion.

Benign Trigger(s): No known triggers.

Recommended Signature Filter: No recommended filters.

Data Field Information Tag: None

Related Vulnerabilities: 1001300

User Notes: User Notes Page

-----------------

btw searching for some bugs on this signature I came across this CSCsc60852

Symptom:

Signature 1300 fires on what appears to be normal traffic.

Condition:

Networking stacks based on BSD4.2 implementations might use a older method of

sending TCP keepalives. The IDS flags this as a TCP overwrite and fires

signature 1300. The segment is in fact a overwrite but it is benign.

Workaround:

None.

Thanks

Nadeem

215
Views
14
Helpful
64
Replies
CreatePlease to create content