IDS 4210 - Tipical Configuration

[ovieira]

Hi!

I have deployed a IDS 4210 and i'm having trouble determining wich configuration (log, block or reset) should i apply to all signatures. Right now i have the IDS logging all signatures that came with the IDS.

Question: i can´t find any documentation regarding a tipical configuration. Can someone help me on this?

Regards,

ovieira

[travis-dennis_2]

Whatever you do don't bloack everything! Log everything and then use the Cisco IDS Event Viewer (or some other tool) to see what is actually happening on your network. I feel that you can generally block all high severity alerts with out too many problems but anything else you need to monitor and start to block accordingly. You could potentially shut down your network if you start blocking everything.

[afniwan · Accepted solution]

Yes I agree with Travis-Dennis. You should take a base line of what is happening on your network first and then decide if the sigs. that fire are worth a response to. We took about 3 days of just "watching" what was going on before making dynamic responses to signature matches. Also, you want to decide where you want to make the block/tcp reset happen, either on your serial or ethernet interface of your managed router. The most common approach is on the INBOUND on your serial therefore it will stop the traffic from coming into your router to be processed.

[marcabal]

WARNING

When you say "i have the IDS logging all signatures" what do you specifically mean??

Many people have confused the "log" action that is used for logging of binary packets, with the standard generation and logging of alerts.

Whether or not an alert is generated and written to the harddrive or sent to a management station is not dependant on the action setting for an alert.

In version 3.x sensors each signature is assigned a severity level from 0 to 5 (some management tools use words like low,medium,high in place of the numbers). There is also a destinations file that says where to send the alerts. With the default configuration severity 1 alerts and higher are sent to the loggerd process for writing to the harddrive in the log. file in the /usr/nr/var directory; and severity 3 alerts and higher are also sent to the management station.

This logging of the alarm to the /usr/nr/var/log. file should not be confused with the "log" action.

NOTE1: Severity 0 alerts are considered disabled.

NOTE2: These settings for the destinations can be changed through the management tool. If all of the destinations are changed to hire levels then the low level alarms will also be disabled. For example all destinations are configured for only sev 4 and higher alarms will result in sev 0-3 alarms being disabled.

In version 4.x sensors each sensor is assigned and severity level (Information, Low, Medium, or High), and an Enabled setting (True, or False).

ALL alarms with Enabled set to True will be recorded in the EventStore from which the alarms can viewed through the CLI or be pulled by a management tool.

This logging of the alarm to the EventStore should not be confused with the "log" action.

The "log" action does not control whether or not the alarm is logged in the /usr/nr/var/log. file of a version 3.x sensor or put in the EventStore of a version 4.x sensor.

The "log" action turns on what we refer to as IP Logging. IP Logging is the logging of the binary packets to and from the source ip address of the alarm for a configured number of minutes.

The "log" action is very very very cpu intensive, and will affect the performance of your sensor. You should be very cautious when setting the action to "log". It should only be used when you need to binary packets for doing additional analysis on specific signatures.

Many customers turned on the "log" action for all their signatures thinking it was necessary to log the alarm itself, and not realizing they were logging thousands of binary packets on their sensors. They were logging thousands of packets and never realizing it and never looking at the logged packets.

SO if you have set the action on all of your signatures to "log" then I would recommend going back through and removing the action. If you need to look at the binary packets then only set the action to "log" for the few signatures where you really think you need it.