I have an IPS v5 running on my network and now on the process of tuning signatures.
Event filter is one of the option that I am working now but it seems that it does not work.
I want some of the signatures on my sensor to only trigger on my specified range of ip's (network servers). That is it should work in a manner that signature will only fire on any attacker address and on a range of specified destination ip range.
Anyone have an idea how to do it?
Attacker address = any
destination address = 10.10.10.1 - 10.10.10.10
*condition - trigger only when 10.10.10.1-10 is attack. I should only see this ip's from the show events or event viewer and no other ip outside this range.
If this was not a Host Sweep signature then the answer would be to generate 2 filters.
The first filter would match the 3030 SigId, and the 10.10.10.1-10.10.10.10 Destination Address. The key to making this work is to leave the "actions-to-remove" blank, and to set "stop-on-match" to "true".
This way when it is matched the sensor will stop checking additional filters and go ahead and execute any actions on the signature (like the produce-alert action).
The second filter would then be created to match everything else for that signature and remove all actions. Match the Sigid 3030, and leave the default to match all destination addresses. This time select every action in the "actions-to-remove" field, and once again select true for the "stop-on-match" field. This way all other triggerings of the signature would be fitlered out by this second filter.
NOTE: Filters are checked in order, so the 2 filters must be in the exact order above to work properly.
HOWEVER, the 3030 is a sweep signature.
Sweep signatures have an interaction with filters that most users are not expecting.
There are multiple destination addresses being targeted in a Host Sweep. The expectation of most users is that the filter would be able to filter on each target address indpendantly.
Unfortunately this is not the case. In fact it is Only the last destination address targeted that will be checked against the filters. What makes it often more confusing is that this last address is not seen in the alert itself. Instead to see this last address being checked against the filter the signature shoudl have the "produce-verbose-alert" action selected so that the trigger packet is attached to the alert. Ethereal would then need to be used to view the trigger packet and determine the final destination address triggering the alert, It is that address that would be used to check against the filters.
So I generally do not recommend filters to do what you are asking. If you try to generate a filter to only allow 3030 to fire when it is targeting the 10.10.10.1-10.10.10.10 address range you won't get what you want.
Let's say for example that 3030 fires when 10 SYN packets are seen. If the first 9 SYN packets go to the 188.8.131.52 network, and the 10th SYN packet goes to the 10.10.10.2 address, then the signature will still create an alert. You will only see the first 9 addresses on the 184.108.40.206 network in the alert itself, but you will see the 10.10.10.2 address in the trigger packet and it is that trigger address that forced the alert to be created.
Or the opposite may happen where the first 9 SYN packets are for addresses 10.10.10.1-10.10.10.9, the 10th packet is, however, to 220.127.116.11. The signature will not fire because you will have filtered out the 18.104.22.168 address as the destination address. Even if the 11th packet goes then to 10.10.10.10 it still won't create an alert because of the counting mechanism used in the sensor.
This issue is being addressed in the upcoming IPS version 5.1 release.
It is not a change to the Filter functionality in event-action-rules. Instead there is a new parameter as part of the signature definition itself.
Beginning with version 5.1 you can configure the signature itself to tell the sensor to only look for packets destined to 10.10.10.1-10.10.10.10 when doing analysis for the signature. This way the signature itself ignores packets destinated to other IPs and the signature will only ever fire fire for the 10.10.10.1-10.10.10.10 destination addresses.
In affect we added address filtering capability directly into the signature definition to control what the signature even looks at rather than trying to filter it after having been triggered.
Thank you marcabal for a very well explained info. It is indeed very helpful.
Just for clarification, since in the first part you said that since this is a sweep attack it will not responed to that kind of filter. Does this mean that with other signatures I could do this kind of scenario?? Only in sweep attack that this filter will not work??
Can you run a "show conf" on your sensor and copy the "service event-action-rules rules0" (where the filters are) and paste in a response to this post.
Without looking at the config myself my first guess is that the filters may be in the Inactive list.
Ensure that the filters are active and in the correct order. I can verify this with the "show conf" output from your sensor.
You would also need to see if other filters may have been configured on your sensor that may be matching before these 2 filters. If the other filters match it could affect how these 2 filters act on the alerts.
By unsuccessful I assume mean that the signature is still being triggered for other victim addresses.
Can you provide an example of one of these alerts that continues to fire.
Also provide the output of "show ver". Then I can try and recreate in my lab. It should be working, but there is always the possibility that we may have a bug.
DocumentationCode download linksGoalRequirementLimitationsSupported ISR
and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationConfigure one of the connectivity
options to access the Cisco IMC from the n...
Firepower Threat Defense (NGFWv) on UCS E-series - Transparent Mode in
HA DocumentationCode download linksGoalRequirementLimitationsSupported
ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationCo...
Question I am currently unable to specify "crypto keyring" command when
configuring VPN connection on my cisco 2901 router. The following
licenses have been activated on my router :