OK, I just applied the latest patch of IDSk9-sp-3.0-2-S9.bin, and the first thing I notice is a rash of detects for which some sensors have filters. I've added filters for other ones (specifically Echo Sweeps - 2100 - from my network management systems) but they don't seem very effective now.
Now the filters have always been somewhat leaky since I first was able to use IP subnets in the filters, but the amount of leaks have been minimal.
This seems much more severe. I am running the UNIX Director, with the 2.2.3 and sig updates installed.
From what I've seen yes. The only one I'm having a problem with is Signature 3030...as that is the only signature that I am filtering...or at least attempting to, and was successfully before I loaded the S9 patch this morning.
There was a DDTS Issue fixed in 3.0(2)S9 (listed in the Resolved Defects section in the readme):
packetd - RecordOfExcludedPattern * *
There was issue with the 3001 signature in prior versions where you could not exclude the source ip of the alarm. As a workaround the source ip of the alarm could be placed in the destination ip field of the exclusion.
With 3.0(2)S9 the problem has been fixed, so user who have taken advantage of the previous workaround would have to undo the workaround and move the source ip address from the destination ip field back to the correct source ip field.
I want to exclude the 3001 alarm with source address of 10.1.1.1
so I would create RecordOfExcludedPattern 3001 * 10.1.1.1 *
In ealier versions this didn't work so the workaround was to move 10.1.1.1 into the destination field making the exclusion: RecordOfExcludedPattern 3001 * * 10.1.1.1
BUT now that 3.0(2)S9 has fixed the problem, the workaround no longer works and the original exclusion RecordOfExcludedPattern 3001 * 10.1.1.1 * has to be put back in place.
The 3001 and 3030 signatures are related in how they fire so the same problem/workaround may also have applied to the 3030 signature.
To see if this is the issue please check the source and destination ip fields in your exclusion against the source and destination ip fields in the actual alarm.
If you are using RecordOfExcludedAddress or RecordOfExcludedNetAddress (Simple Filtering in CSPM) then I would also recommend using RecordOfExcludedPattern (Advanced Filtering in CSPM).
If you want you can copy and paste the RecordOfExcluded.... token from packetd.conf and a sample from your log file in a reply to this posting, so we can see if this is the issue that you are seeing.
I was unable to find the 'RecordOfExluded' in the packetd.conf file...it was however in SigSettings.conf file. Here it is:
RecordOfExcludedPattern 3030 * 18.104.22.168/24,22.214.171.124/24 *
here is a snipit from my log as well:
,0.0.0.0, - Interval Summary: 1 of total 2 alarms
Any ideas? Thanks
You have it configured properly, so what you are seeing is a bug.
I will see if a member of our team can analyze what is going on, or look into it myself later today.
The tester or myself will get back with you later today or tomorrow morning on this forum.
Things which we will be trying in our lab which you may want to try if you have the time (or you can just wait till we've had a chance):
Splitting the excluded networks into two different lines; it's possible that the comma might be the issue.
Listing the networks as 126.96.36.199-188.8.131.52; it's possible that the sensor is misinterpreting /24.
See if it works for a single address instead of a network.
Anyting we find would be written up as a DDTS Issue and fixed in the 3.0(3)Sx Service Pack.
In my case with the 2100 scans, my filter lines are for single addresses or for single subnets (depending on the sensor) and are still not responding to the filter - so I don't believe it's in the comma....
Several of our engineers have been running through some tests to determine the issue.
What it looks like is that the Summary feature is producing a new situation which our tests did not catch.
The first alarm fires would have fired with an actual destination address which matches the * in the destination field, and therefore does not get sent to the director or log files.
But after enough of the packets come in then the alarm goes into Summary mode. In this mode the destination address is replaced with "0.0.0.0" to signify that the alarm is being matched against multiple destinations. We have a bug in our software: the 0.0.0.0 in the Summary alarm is not matching the * in the destination field of the exclusion so the alarm is firing.
It appears that the word OUT does match the 0.0.0.0 and will prevent the exclusion.
So you can create a second exclusion for these alarms with the word OUT for the destination field. So in the configuration file you will need the original line and a copy of it with the * changed to the word OUT, and then the Summary alarms should be excluded as well.
You may also want to try using the address "0.0.0.0" in the destination field of the second line. I've asked the engineers if this will work as well, but they haven't gotten back to me with an answer as of yet.
We will attempt to fix this in the next sensor service pack 3.0(3)Sx.
Tnak you for your patience and time.
As a follow up, our engineers tried using just the 0.0.0.0 in the destination field of hte exclusion to exclude the summaries and it did not work. So the OUT keyword is the only workaround to use for now.
Did this solve the problem with the 2100 alarm seen by crossmanj??
While waiting for the bug fix, I have reduced the severity to a '2' so it won't hit the console, and will instead go to the database directly. I did this before the workaround was discovered.
I'd change it but I'd have to go every sensor again. When can I get a global filter capability on my director?
Global Filters and Global Policy features are a must for scalability in MSP and Enterprise environments for CSPM, VMS 2.0 and Director.
A autoupdate for multiple managment consoles would also be a god send especially in an MSP environment.
Well, Im doing the same manual filtering too.
A. Yes using 0.0.0.0 did not work for me either, interesting to note though that while I switched to OUT, I also had my 2100 alarms set to GlobalSummarize so overnight I got several hundred 0.0.0.0 0.0.0.0 alarms for 2100.
...blocking this won't work on 3.0(2) so Im trying 2100 OUT OUT (otherwise I suppose I'll have to switch to FireOnce?)