Improving response time

[willdavi129]

Here is my current situation. I am running MARS application version 4.2.1 I have a test environment of 1 - 2821 Router with IPS module version 12.4T, 1 - 2621 Router with net flow running version 12.2, 1 - 2950 OS Switch and a stand alone MARS Server. When I run the scenario to test the response time (the time it takes MARS to notify me of the attack) it takes any where from 1/2 hour to and 1 hour before the alarm show up in the event Dash board is there a way to improve the response time? Secondly, I see the IPS signatures in the syslog but I do not see them on my MARS application when investigating an attack. If I run a query for real time I see everything but can't investigate the attack.

[willdavi129]

I hope I am on the right track I adjusted the running time level to info instead of trace. Please let me know if I am on the right track.

[pmccubbin]

David,

A few questions so we can help with your troubleshooting. Please forgive me for beginning with some MARS 101 questions.

1. How long have you had this test environment set up? Netflow usually needs a few days to baseline your network, even in a test lab.

2. What sort of scenario are you using to test the response time?

3. Do these bugs apply to your situration?

Take a look at:

CSCsc50636, CSCsc50652

Issues: Backend IPS process runs at 99% CPU when pulling large IP Logs

The backend IPS process reaches 1GB in memory used when pulling IP Logs. The process names depending on the version on MARS that is running:

In version 4.2.1 and earlier, the process names are pnids50_srv and pnids40_srv.

Go to the command line on the Mars box and do a sysstatus to see what system resources a process on your Mars device is using.

Hope this helps. Let us know more details when you have the chance.

[willdavi129]

Thanks for the response. The test enviornment been in place for at least 2 1/2 weeks.

The senario I have been testing is basic penetration testing, port scan, snmp brute force, upd port 9 and 7, general ips 4 signitures.

the memory and cpu issue is not a factor and the processors are well below 25%.

I am concern because this is a proof of concept and it appears I need to get a patch for version 4.2.2 to fix some of my issues(DST)Other then that I am still stuck.

[pmccubbin]

Just so I know what are your criteria for success in this proof-of-concept?

More basic MARS 101 questions:

1. In your configuration of the MARS box did you enter the specific subnets from your network that the IPS monitors? Or did you summarize the subnets?

2. Are you using SNMP and or syslog? Is their output pointed at MARS?

3. Is the IPS capable of blocking an attack? If the IPS blocked the attack , mitigation has already been performed and the alarm is reported as a system-determined false positive.

4. Do you want MARS to display the payload of a packet that triggers an event? If so, ensure that IPS events have an action of Produce Verbose Alert. You use the Intrusion Detection Manager (IDM) to set this feature.

5. On the ISR router do you have all signatures enabled? Any unused signatures should be turned off to save memory.

Hope this helps.

[willdavi129]

My definition is timely notification of an attack with detailed information on the type of attack.

1. I specified the subnets that the IPS monitors.

2. both and they are pointing to the MARS server

3. the IPS is capable of blocking but currently I have that turned off.

4. the only problem I am having with this is I do not even See the information on the MARS server unless I am running a real time query.

5. yes when I do a show logging I see the signitures that where triggered.

[pmccubbin]

If your criteria for success includes a timely notification of an attack and you are not seeing the attack in the Dashboard for a 1/2 hour, then something is certainly amiss.

More MARS 101 questions:

1. Have you tried duplicating the rule and making it so sensitive that a single event will trigger it? I'd then do a query on All Events in a 10 minute time frame to make sure that MARS and the IPS are communicating in a timely fashion.

2. Have you configured any of the alerting features like email of SMS? Do these take 1/2 hour to alert you of an Incident?

3. How about the time on all of your devices, are you using NTP?

4. When the incident shows up in the Dashboard is the time correct? In other word, I want to know if the time in the Incident on the dashboard is the time when all the events together triggered the rule.

[willdavi129]

what you are asking is exactly what I did.

1. I did duplicate the rules and lower the time.

2. I configured the email and it takes just as long.

3. I am using NTP but it is drifting plus I am running version 4.2.1 so I do have a DST issue but I was told my test enviornment should stay GMT so that issuse should go away.

4. Yes, when the incident do show up it is correct.

[pmccubbin]

You have two more things you can do:

1. Upgrade the software to the latest code;

2. Burn an ISO image of the latest code, wipe the box clean, and start all over.

At this point I'd be doing the second option because it sounds like you have done a thorough job of troubleshooting.

Hope this helps.

[willdavi129]

That sounds like a plan but I am running a POC so currently I do not have a contract to upgrade the current version is there a temp somewhere I can finish my POC at the right level??

[willdavi129]

Thanks for the response. The test enviornment been in place for at least 2 1/2 weeks.

The senario I have been testing is basic penetration testing, port scan, snmp brute force, upd port 9 and 7, general ips 4 signitures.

the memory and cpu issue is not a factor and the processors are well below 25%.

I am concern because this is a proof of concept and it appears I need to get a patch for version 4.2.2 to fix some of my issues(DST)Other then that I am still stuck.

[mhellman · Accepted solution]

I would question the usefulness of a POC if you're not running the latest version of the software. Cisco should provide the latest update to you. The DST issue, for example, caused some major problems for us.

Run a real-time event query to determine if the events you are generating are being "collected" immediately. If they are, what are the events? What rule are you expecting to fire? Here is a description of the rules should work (they should fire right away before any throttling starts).

http://ciscomars.blogspot.com/2007/02/guest-article-mars-inspection-rule.html