SRX

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!

Hi,

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.

regards,

Guru Prasad

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. 

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. 

Hello,

I have an issue related to this.

I am trying to make an idp rule to inspect a few customized pattern which has to be permitted, and then drop anything else.

I have created a first rulebase which matches correctly and has "no action", and then a second rulebase which denies everything.

The problem is that traffic is beind dropped because of the most severe action.

I have seen this post and thought I could make a terminal rulebase, but I guess that way won't deny any traffic.

This is an example:

set security idp idp-policy IPS_SIP rulebase-ips rule "Whitelist: Permitted ranges" description "Whitelist: Permitted ranges"
set security idp idp-policy IPS_SIP rulebase-ips rule "Whitelist: Permitted ranges" match application default
set security idp idp-policy IPS_SIP rulebase-ips rule "Whitelist: Permitted ranges" match attacks custom-attacks VOIP:SIP:HEADER-1000
set security idp idp-policy IPS_SIP rulebase-ips rule "Whitelist: Permitted ranges" match attacks custom-attacks VOIP:SIP:HEADER-2000
set security idp idp-policy IPS_SIP rulebase-ips rule "Whitelist: Permitted ranges" then action recommended
set security idp idp-policy IPS_SIP rulebase-ips rule "Whitelist: Permitted ranges" then notification log-attacks
set security idp idp-policy IPS_SIP rulebase-ips rule "Whitelist: Permitted ranges" terminal

set security idp idp-policy IPS_SIP rulebase-ips rule "Blacklist: Denied ranges" description "Blacklist: Denied ranges"
set security idp idp-policy IPS_SIP rulebase-ips rule "Blacklist: Denied ranges" match application default
set security idp idp-policy IPS_SIP rulebase-ips rule "Blacklist: Denied ranges" match attacks custom-attacks VOIP:SIP:RANGE-ANY
set security idp idp-policy IPS_SIP rulebase-ips rule "Blacklist: Denied ranges" then action drop-packet
set security idp idp-policy IPS_SIP rulebase-ips rule "Blacklist: Denied ranges" then notification log-attacks
set security idp idp-policy IPS_SIP rulebase-ips rule "Blacklist: Denied ranges" then severity info

I need some help.