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

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

packetd.conf anomalies

I received three brand new sensors in the mail configured with 3.0(S4). I upgraded them to the latest service packet and with S10 signatures. (I'll do S11 later)

Anyway, here's my test:

packetd.conf contains the following:

SigOfGeneral 3306 0 5 5 5 5 # Windows Registry Access

When I start up the sensor daemon, I would expect that the 3306 signature to not be logged. Well it appears multiple times in the ../var/log.* file anyway.

Why is this signature being logged? The action is '0' (do nothing), and I left the severity levels as 5.

Has it changed so that 0's have to be put in the destination columns now? It didn't used to...

Cisco Employee

Re: packetd.conf anomalies

The 0 you are refferring to is the Action field.

The Logging controlled by the Action Field is specifically for IP Logging and not for whether or not the alarm gets logged.

IP Logging is the loggingin a binary (non human readable format) of the packets that came from the source ip address of the alarm after the alarm fired. The binary packets are logged in the /usr/nr/var/iplog and /usr/nr/var/iplog/new directories.

The determination as to whether or not the alarm is logged, is determined by the severity of the alarm, and the minimum severity levels for a destination.

If the alarm is a level 3 and my destination (in the destinations file) is set to receive level 2 alarms or higher, then the level 3 alarm will be logged along with level 2,4, and 5 alarms. (Only level 0, and level 1 alarms will not be logged to that specific destination.)

The only way to prevent an alarm from being logged is to set it severity level to be less than the smallest destination level. So if your smallest destination severity level is 2, then setting the alarm severity to 1 or 0 will prevent it from being logged.

User's understanding of how this works, however, has been affected by how the maangement tools were coded.

In CSPM, the developers unfortunately labeled the IP Log action as simply Log instead of calling it IP Log or even Binary Packet Log. So users incorrectly assumed that they had to set the action to Log in order to have the alarm logged in the /usr/nr/var/ file. When what is really happening is that they are telling the sensor to log the binary packets from the source of the attack.

Some users have inadvertantly set the majority of their alarms to Log action, and unknowingly are filling their sensors with these binary IP Logs which they never look at it. Then end result is that the sensor is working very hard to log all of these packets that the user never looks at, and this slows down the sensor's performance where it could be missing attacks.

The other misconception came when CSPM added an option to Disable a signature. In the GUI the severity stayed looking the same when Disable was selected, but when the signature is written in the packetd.conf file the severities were all changed to 0, because there is no other way to prevent the signature from being logged to a destination with a severity level of 1. So what CSPM shows the user isn't exactly what is written to the sensor, because there is no real enable/disable flag in packetd.conf.

I can't remember if the Unix Director has similar issues or not.

As for the question about has this changed. The answer is NO, this is the way the sensors have ALWAYS worked. Sorry for any confusions you may have had.