04-10-2017 05:52 AM
Hi folks. I am going through a project with IDP on the SRX. While we tune the IDP, there is multiple matches on attacks when in the policy. For instance, I added some XSS attacks to a new rule with an action of drop. Some of these XSS are still bundled with other built-in attack groups that have a recommended action of notify only.
Since the entire IDP policy is evaluated, an XSS attack is logged twice - once with an action of drop and once with an action of notify. This is difficut to deal with in our SEIM tools.
Does anyone know of a way to log only the drop action? I have through about using the terminal option for a rule which would stop the rest of the policy from being evaluated, but it only seems to consider source, destination, and applciation and not attack. That would stop other legimate policies from being evaluated.
Any quick bits of knowledge would be a big help. I have a full lab I can test with.
Thanks in advance!
Solved! Go to Solution.
04-11-2017 01:05 AM
The issue that you are seeing is as per design and if you want to stop this then you need to have terminate option enabled in the policy, This will stop the lookup, however by design IDP does a full lookup.
Lets say you have policy configured with 2 separate actions like drop and permit, then the IDP will take the sever action by default which is the drop.
Hope this answers.
04-11-2017 04:40 AM
Thanks for the reply!
I noted exactly what you said in my question above.
The problem with terminate is only source, destination, and service are used for terminate criteria.
From Junipers PR: "By default, rules in the IDP rulebase are not terminal, which means IDP examines all rules in the rulebase and executes all matches. You can specify that a rule is terminal; that is, if IDP encounters a match for the source, destination, and service specified in a terminal rule, it does not examine any subsequent rules for that connection."
So, If I just want to change the behavior of a single attack to drop-connection, no other rules for that source, destination, and service will be evaluated. If terminate would consider the attack type as criteria, it would resolve this. But I can't see that it does. I can lab it, but I have my doubts.
It seems like the only way to acheive this configuration is to ditch all the built-in attack groups with their recommended actions and build your own. I have no problem doing this, but it takes time and I would like to have accurate logs with small incremental changes.
04-13-2017 05:34 AM
Surprised that no one has run into this.
We are planning on matching the duplicate logs and filtering on a splunk heavy forwarder. So if a log for a specific attack happens on the custom rule I created, we will filter out any other notiifications with that attack type in any other rule.