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

[edit security idp]
root@srx1# show custom-attack block-exe
recommended-action close-client;
severity major;
attack-type {
    signature {
        context http-url-parsed;
        pattern ".*\.\[exe\]";
        direction client-to-server;
    }
}

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

[edit security idp]
root@srx1# show idp-policy Recommended rulebase-ips rule 10
match {
    from-zone attacker;
    source-address any;
    to-zone victim;
    destination-address victim1;
    application default;
    attacks {
        custom-attacks block-exe;
    }
}
then {
    action {
        recommended;
    }
}

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

[edit security idp]
root@srx1# show active-policy
active-policy Recommended;

[edit]
root@srx1# show security policies from-zone attacker to-zone victim
policy attacker-to-victim {
    match {
        source-address attacker1;
        destination-address victim1;
        application any;
    }
    then {
        permit {
            application-services {
                                  idp;
            }
        }
    }
}

4) Once ready send a test http request

--2011-09-22 21:34:53--  (try: 2)  http://victim/html.exe
Connecting to victim|10.1.1.2|:80... connected.
HTTP request sent, awaiting response... Read error (Connection reset by peer) in headers.
Retrying.

--2011-09-22 21:34:55--  (try: 3)  http://victim/html.exe
Connecting to victim|10.1.1.2|:80... connected.
HTTP request sent, awaiting response... Read error (Connection reset by peer) in headers.
Retrying.

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;

[edit]
root@srx1# run show security idp policy-commit-status
 Compiling policy...

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

[edit]
root@srx1# run show security idp policy-commit-status
 IDP policy[/var/db/idpd/bins/Recommended.bin.gz.v] and detector[/var/db/idpd/sec-repository/installed-detector/libidp-detector.so.tgz.v] loaded successfully.
 The loaded policy size is:3493926 Bytes

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;

[edit security idp idp-policy Recommended rulebase-ips rule 10]
root@srx1# show
match {
    from-zone attacker;
    source-address any;
    to-zone victim;
    destination-address victim1;
    application default;
    attacks {
        custom-attacks block-exe;
    }
}
then {
    action {
        recommended;
    }
    ip-action {
      ip-block;
      target source-address;
      timeout 60;
    }
}

If you want to see the rule in action;

[edit security idp idp-policy Recommended rulebase-ips]
root@srx1# run show security flow ip-action
Src-Addr        Src-Port Dst-Addr        Dst-Port/Proto Timeout(sec) Zone       Action
10.2.2.2        *        *               */*            55/60        *          drop

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.