First let me list all the kudos I have for y'all as I upgrade my sensors from 2.2.8 to 3.0(S7). I feel like Chistmas has come! I can set signatures by IP destination, I can filter out an entire /23 network for every signature for both inbound and outbound with two filter entries, I can tune the thresholds on my signatures, I can shun with a PIX, I can detect and shun on ACL violations on my Catalyst, I can use the official signatures instead of my homegrown RegEx ones. I can even build better homegrown ones. Man, this is wonderful!
But today I have slammed into the wall and must halt my deployment until I figure a new hack, I mean approved method for getting alerts to my
You see, I managed to get the 10k+ alarms per day down to 300 per day by managing false positives. But to limit the number of times my 24x7 crew has to hunt down a client at night or a weekend, I took advantage of the higher alarm levels above 5. So my NOC knows that an alarm 9 is an outbound attack, and alarm 10 is an inbound recon attempt, and an alarm 11 is an attack with almost ZERO chance of false positive.
The director is set to use eventd to send the e-mail to the NOC, for when I'm not here. All other alarms I handle when I review the database.
But when I went to reset those signatures, I received an error. It seems that over 98% of my potential alarm space has been lost.
What am I to do? Y'all use the severities to track how severe an attempt was whether it might be false or not. I was using it (right or wrong) as a gauge for confidence that people should be gotten out of bed.
OK, I know the answer is to tune false positives down enough to only the real events alert. That's clearly the right way to do it. But there is so much that is real that I want to respond to thropugh automated abuse scripts and don't want in front of the NOC. I can think of all sorts of ways of handling this, but it all seems to mean that I must either risk alerting on a benign trigger (at least the first time) or rewriting ALL sig IDs for every signature.
See, no matter how sure you are that nobody is using a feature, some idiot will always base everything he does upon it. :-)
I manually edited the packetd.conf (using vi) and changed the severity levels to 9 and 11 for some sigs and the signatures fired with those severity levels, so it appears that this is not a sensor problem.
I then tried to make these same changes using the new 2.2.3 Unix Director and found that they have put in a new check to keep the severity level from being greater than 5. I am not sure when this change was made or why, and will ask for a repsonse from the Unix Director development team.
As for a "new hack", the temporary workaround would be to
1) Use vi to edit the packetd.conf file, and change the severity level of the sigs to the levels higher than 5
2) Then double click on the sensor in nrConfigure
3) You will be prompted that the packetd.conf file on the sensor differs from the saved one in nrConfigure, and be asked to download the changes. Reply yes to download the new packetd.conf file.
4) Now you can continue to use the other features in nrConfigure.
(Unless you come across another area in the GUI with the same problem, inwhich case you would have to resort to vi for that change as well.)
This appears to work fine and does not create errors in nrConfigure, unless you try to change the action or severity level of signature that has the severity level greater than 5. So yu can still use the features to create the new signatures, and exlcude the signatures, but change severity levels using vi.
Hope this helps, and gets you started in 3.0, and I will check with the Unix Director team.
I am from the Unix Director Team. As part of a enchancemnet request we changed the severity level from 0 to 255 to 0 to 5 for 2.2.3 not realizing your type of usage. Since there seems to be need for you to configure severity level upto 255 we can create a new build and deliver it to you as soon as possible.
Login to the FXOS chassis manager.
Direct your browser to https://hostname/, and log-in using the user-name and password.
Go to Help > About and check the current version:
Check the current version availa...
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...