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.