As per the previous blogs if you have followed from the start you will notice you have downloaded, installed, and configured your Juniper SRX to support IDP technologies. This is a great start. For most users the default templates defined by Juniper provide ample coverage for most attacks. The purpose of this post is to define custom objects that allow businesses with custom application or a specific detailed need to utilize IDP technologies. The two examples I will use within are HTTP-header and FTP usernames. I am planning on blocking Google Music and FTP usernames.

First I will create my custom attack named GoogleMusic, set it to block the common host headers, and ensure it is client-to-server interactions.

set security idp custom-attack GoogleMusic severity minor
set security idp custom-attack GoogleMusic attack-type signature context http-header-host
set security idp custom-attack GoogleMusic attack-type signature pattern ".*\[music\.google\.com\]"
set security idp custom-attack GoogleMusic attack-type signature pattern ".*\[google\.com\music\]"
set security idp custom-attack GoogleMusic attack-type signature direction client-to-server

Not a very hard to implement rule-set but can save you a lot of headaches of attempting to block people from streaming music. The example below would be superb to stop random access attempts to bruteforce default usernames. So currently if a packet is sent to the IDS and the ftp-username field detects root, anonymous, or administrator, we can then action a command for the SRX to perform an action.

set security idp custom-attack FTP-access-access attack-type chain member FTP-access-Username attack-type signature context ftp-username
set security idp custom-attack FTP-access-access attack-type chain member FTP-access-Username attack-type signature pattern "^root$"
set security idp custom-attack FTP-access-access attack-type chain member FTP-access-Username attack-type signature pattern "^anonymous$"
set security idp custom-attack FTP-access-access attack-type chain member FTP-access-Username attack-type signature pattern "^administrator$"
set security idp custom-attack FTP-access-access attack-type chain member FTP-access-Username attack-type signature direction client-to-server

Alright. Now we need to define our IDP policies to know what to match to apply the IDP rule too. This will take a packet matching the from zone, address, to zone, and application then additionally add our custom rule. It will then perform an action we want it to. In our case it is log and close the connection. This is the same with our FTP rule.

set security idp idp-policy active rulebase-ips rule GoogleMusic match from-zone lab-zone
set security idp idp-policy active rulebase-ips rule GoogleMusic match source-address any
set security idp idp-policy active rulebase-ips rule GoogleMusic match to-zone untrust
set security idp idp-policy active rulebase-ips rule GoogleMusic match destination-address any
set security idp idp-policy active rulebase-ips rule GoogleMusic match application junos-http
set security idp idp-policy active rulebase-ips rule GoogleMusic match attacks custom-attacks GoogleMusic
set security idp idp-policy active rulebase-ips rule GoogleMusic then action close-client-and-server
set security idp idp-policy active rulebase-ips rule GoogleMusic then notification log-attacks
set security idp idp-policy active rulebase-ips rule FTP-access match from-zone trust
set security idp idp-policy active rulebase-ips rule FTP-access match source-address any
set security idp idp-policy active rulebase-ips rule FTP-access match to-zone lab-zone
set security idp idp-policy active rulebase-ips rule FTP-access match destination-address any
set security idp idp-policy active rulebase-ips rule FTP-access match application junos-FTP-access
set security idp idp-policy active rulebase-ips rule FTP-access match attacks custom-attacks FTP-access-access
set security idp idp-policy active rulebase-ips rule FTP-access then action close-client-and-server
set security idp idp-policy active rulebase-ips rule FTP-access then notification log-attacks

Now we need to enable our IDP policy which we do below.

set security idp active-policy active

Now we set up our security zone to and from and the policy we apply. This policy entitled SOCIAL-MEDIA punts matches to the IDP engine.

set security policies from-zone lab-zone to-zone untrust policy SOCIAL-MEDIA then permit application-services idp

Cool. Now IF we needed to make a zone exempt from being run against the IDS we would need to create exemptions.

set security idp idp-policy active rulebase-exempt rule GoogleMusic match from-zone EXEMPT-ZONE
set security idp idp-policy active rulebase-exempt rule GoogleMusic match source-address any
set security idp idp-policy active rulebase-exempt rule GoogleMusic match to-zone untrust
set security idp idp-policy active rulebase-exempt rule GoogleMusic match destination-address any
set security idp idp-policy active rulebase-exempt rule GoogleMusic match attacks custom-attacks GoogleMusic

So there we are. Making policies is fun although it can be time consuming. I suggest testing it in the lab first. It is also important to remember that people may get around your rules you define and or develop or mask what you are searching. IDP makes up only one layer in the defense in depth security onion. Thanks for reading.