I need to know how the IPS makes decision on putting the attacker IP in the denied attackers and is there a way to monitor what was the signature that triggered it.
The case I have is an IPS protecing the WAN zone, it's adding for no reason legitimate IP addresses in the denied attackers pane wihtout knowing what caused the IPS to put them in the denied attackers pane.When I create an event action filter and removes the deny attacker inline from all signatures for that specific IP the issue is resolved, but we don't want this workaround since the customer wants to be restrictive in its policy
From your descripition, I assume that the signature causing the deny-attacker action event is not actually creating an alert. You have a few different tools that can help you identify what signature is executing the deny-attacker action.
- Virtual Sensor statistics (Configuration -> Sensor Monitoring -> Support Information -> Statistics -> scroll down to section "Virtual Sensor Statistics" and look for the signature firing counts
- Event Action Overrides (** use this with caution **)
Signature configuration view filtering
Unless your signatures are significantly tuned, you will only have a few configured with the deny-X action. Go into the signature configuration area of IME and filter on Action -> Deny X (where X is any of the Deny Actions). This will help you identify what signatures are potentially executing the deny-attacker action.
Virtual Sensor statistics
Looking at the signature event count will show you what signatures are eventing, but may not be alerting (no Produce-Alert action set). This will lead you to what signatures are potentially executing the deny-attacker action.
Event Action Overrides
Caution, Caution, Caution: If your sensor is reasonably busy, this will cause many alerts to be generated. Use only for troubleshooting and only if you do not normally see a high event rate.
You can configure an Event Action Override of Product Alert *only* for the signatures you see firing in the Virtual Sensor statistics in the time that the deny-attacker action has been executed. This will cause the deny-attacker signature to alert and you can see the deny-attacker action in the event data.
Please let me know if I understand your issue correctly and if the above information helps.
Thanks for your answer, you understood the issue correctly yes but I need one more clarification: you mean that the issue could potentially be a signature set to deny attackers for instance but not to produce alert right?
If I got you well that would be the most probable cause, i'll check it at the customer's premises and advise
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...