Palo Alto Networks NGFW and Prima Access have many predefined IPS vulnerability signatures but sometimes extra custom signatures are needed that are specific to the application being protected as this need internal domain knowledge.
I'll provide examples related to the most common type of traffic—web application HTTP traffic—using HTTP Forever as the backend to avoid dealing with SSL for the purposes of this article.
Also Destination NAT is configured as to redirect traffic from my internal VM-ware Workstation environment to the outside.
I'll demonstrate how to write custom signatures through four examples: enforcing parameter length and protecting against brute-force password attacks on a login page using both GET and POST methods. The final example will cover creating an application signature.
Note: Avoid wrapping the entire pattern match expression in parentheses () by default. Parentheses in regex are used for grouping, so enclosing the entire expression unnecessarily can lead to unintended behavior.
1. Parameter length enforcement
The first example shows how to create a signature that blocks parameters "user" and "pass" if they exceed 14 characters as a parameter protection from buffer overflow or fuzzing attacks, where humans or automations just try random stuff in the parameter fields till something happens. The two parameters are in "OR" with or conditions as I want to match and exceeding parameter length no matter if it is for the "user" or "pass" parameters. The action is to send TCP RST to the client and server as to not leave any connection opened when the signature is matched.
It is interesting that the regex for the second ''pass'' parameter matches also the parameter itself so this is why extra 6 characters are added ''{.20}'' as the delimiter & is at start of the second parameter, so regex for the first parameter " user=[^&]{14,} " can't be be used and the second regex is " pass=.{20,} " as you discover such thing by testing and playing around 😉.
Also not only the "Pattern Match" operator can be used but the "Greater Then" Operator that has a context different than "http-req-params" that is "http-req-param-length" but this is for the entire parameter field and it is less granular but also simpler.
The command testing is with "curl" and will work for GET and POST parameters as I have not specified a qualifier that I will do in the next examples.
The Threat log shows examples of the triggered custom signatures.
2. Brute force protection for a login page for GET method query parameters
Before testing custom signatures for brute force keep in mind Palo Alto already has predefined signatures for such attacks, so first test them and see the reference links for more information.
Using combination signatures that allow to trigger a signature by specifying the number of times something needs to happen is a great way to do DOS or brute force protection on the layer 7 application web level. This approach uses a normal signature that is in allow state and it is used only to match the traffic pattern that if seen too many times will cause a block of the source IP address. The action is "Allow" as this signature is used a trigger by the next signature.
I have two "And" matches as the first regex matches the login page as to not cause too much CPU issues with the custom signature and I also added qulifier to tigger only on GET method again for the same reason. Also the login page match when "Ordered Condtion Match" is enabled should be before the parameter match.
It is interesting that the regex for the login page "" /login\\? "" needs "" \\ "" for escape as "" ? "" is a special regex character that matches any one charracter but in this case I needed it to be matched literally as the Context "http-req-uri-path" captures it and this is present as delimeter for query parameters. I think two escape characters \ are needed and not one because of the Palo Alto's XML configuration format. The second regex for parameters is simple "" user.*pass.* "" as "" .* "" will match any or more characters in between.
After this you make a second signature that is combination based and it is triggered by the first signature and by the time component if there are 10 hits for 60 seconds. The action is to block the source IP address for 10 second. The "Track By" in some cases needs to be change to source and destination if there are several servers behind maybe DNS FQDN name.
To test you just need to run curl command more than 10 seconds in 1 minute and then you will get no reply and timeout after the 10th time.
3. Brute force protection for a login page for POST method body parameters
To test this you can use curl command with -d "user=da&pass=da" and the method is auto switched to POST.
I used the same code for POST and GET parameters but another example for the query parameters could be "http-req-uri" that unifies the login page and Query pameter match but I saw some issues on my NGFW version.
To implement site wide protection as to allow the number of hits on a login page to be for example 200 per second as this could be number the server can handle you can change the aggregation criteria to be "" destination "" and then maybe change the action to do RST and not block IP addresses as this is like a rate limiter for a URL as the TCP RST will be send to the client till "Time Attribute" value expires, similar to Rate Limiter.
4. Application signature basic example
In some cases you may want to mark maybe your internal website as a separate application as in this way the default Timeouts and other parameters can be changed just when the website is accessed.
In the first tab selects parent application "web-browsing" as Palo Alto needs this as initially the HTTP traffic will match this App ID.
The second tab is where port tcp/80 is configured as the example web I used is httpforever and also the timeouts can be controller from this tab as could be the main purpose to create a custom app id.
The final tab is where the match signature is configured and the most simple way is Host header match "" httpforever\\.com "" or "" ^httpforever\\.com$ "" .
