How to write SRX IDP Custom Attack/Signature

Here is a sample configuration of a custom attack configuration on SRX. It is very basic and does only block URLs having *.exe in path and sends a RST back to the client. My regex might not be %100 correct but it has no purpose rather than showing a simple configuration;

1) Configure custom attack

2) Either create a new rule or attach this attack to an existing rule. I created a new rule under active idp-policy which is Recommended

3) Make sure active policy is Recommended and applied to a policy

4) Once ready send a test http request

Because we receive a RST sent by SRX, we see this “connection reset by peer” message.

Last but not least, when you change idp policy, there is a compilation process that needs to be completed. Till then, you will still be using the previous policy. To check compilation process run;

As it can be seen policy is still being compiled. Lets try once again;

Now the compilation is completed and you can see the new policy in effect.

5) What if we want to enforce some rules after this attack is detected?
For example: we want to block rest of the connection for 60 secs
Here is the new rule with the new “ip-action” settings;

If you want to see the rule in action;

From output you can see that connection has been dropped for 60 secs in total and 55 secs left to permit the connection once again.

8 thoughts on “How to write SRX IDP Custom Attack/Signature

  1. Dave Killion

    Your pattern has more match than is necessary, to be honest. Every URL starts with /, so looking for it is a bit unnecessary. Putting a dot-star before it equally so.

    Furthermore, the pattern in its current state is case-sensitive, and would miss files with .EXE, .eXe, .ExE and so on. A more suitable DFA pattern would be:


    The escaped open and close brackets denote the range of case-insensitivity.

    Finally, for URL path inspection, a better context would be the http-get-url-parsed or just http-url-parsed – this context parses any encoding tricks (such as “%2e%65%78%65” which is one way of many to encode “.exe”).

    Doing the parsed context + making it case-insensitive increase the signature’s effectiveness significantly by making it evasion-resistant. Dropping the extraneous dot-star slash check reduces DFA states by ~28%, increasing performance.

    SRX also has a feature called “Application Intelligence” (AI), which detects services/applications regardless of their default ports. By specifying the application, however, you’ve actually disabled AI and forced the signature to only be inspected on the SRX’s default pre-defined application port for HTTP, which is TCP/80.

    In order to maximize detection, we need to leverage AI. To do so, the correct application binding value should be “default” rather than “junos-http”. This tells the SRX to select applications the rule is looking for based on the signatures’ service contexts used in that rule (in this case, http-*) and then leverages AI to find those applications on any port.

  2. rtoodtoo Post author

    Thanks Bryan and Dave for your valuable feedback, I have corrected my mistakes. I hope it looks better now.

  3. tom

    can you inport snort rules straight into a juniper IPS or is there some kind of conversion that needs to take place using a tool or something?

  4. jais

    Hi can you help me..i have SRX 1400 at client site, IDP/IPS both license are there. I want to block facebook. Can i create a signature based policy for http or https traffic comes for facebook. can anybody tell me or give me some particular hint about this configuration using regular expression?please mail me the solution at


You have a feedback?

This site uses Akismet to reduce spam. Learn how your comment data is processed.