Restricting Adobe CQ Admin Logins with Trustwave WAFs

One of the many useful features of a web application firewall (WAF) is its ability to add on addition security checks or logic to third party web applications. One common request that my team often receives from WAF customers is that they want to restrict down access to certain portions of their web applications to specified IP addresses or ranges. Oftentimes this type of functionality is not available natively within the application and fortunately it can be added in using a WAF.

Adobe CQ Admin Login - ModSecurity Example

One such example is for the Adobe Experience Manager (CQ) application. How can an Adobe CQ admin restrict down who is allowed to log into the portal interface as the "admin" user? Well, it just so happens that Adobe's Help portal addressed this very issue here where they showed how this can be achieved using Trustwave's open source ModSecurity WAF!

When a client logs into the Adobe CQ app, this is what the raw HTTP request looks like:

POST /libs/cq/core/content/login.html/j_security_check HTTP/1.1
Host: some_website.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:19.0) Gecko/20100101 Firefox/19.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://some_website.com.com/libs/cq/core/content/login.html/j_security_check
Cookie: JSESSIONID=589506ae-50a6-4133-b8db-4af0453f5846
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 83

j_username=admin&j_password=123214&resource=%2Fwelcome&_charset_=UTF-8&contextPath=

The example rules shown on the Adobe help website are the following:

These rule will be activated for the /libs/cq/core/content/login.html/j_security_check URL. If the the client IP address is NOT 172.16.208.11 and they are submitting the "admin" username, it will block them. This ruleset works like a charm and will help you to protect your Adobe CQ admin logins from access attempts by untrusted parties.

Adobe CQ Admin Login - WebDefend Example

In addition to our open source WAF ModSecurity, Trustwave also has our award winning, commercial WAF appliance called WebDefend. What I would like to do now is to show how the exact same custom protections can be implemented with WebDefend using our new "User Defined Rules" capabilities.

Adding New Custom Rules

Step 1: Open User Defined Rules Editor in the WebDefend Console

Step 2: Click Add to Define the New Rule Meta-data

Step 3: Create Custom Rule

It is important to note, as we often get questions along these lines, that WebDefend does not currently share any actual code base with ModSecurity. They are two completely separate applications. What we opted to do in this case, however, is to leverage the very popular ModSecurity Rules Language syntax for creating custom rules. For those of you who have been using ModSecurity and have many custom rules, this may come as good news for you as it would ease a transition into using WebDefend in your environment. As you can see from the screenshot above, the SecRules look very similar to the native ModSecurity rules shown from the Adobe site and they function the same. It will deny access to anyone logging into the "admin" account if they are not coming from 192.168.1.100.

Step 4: Activating the Policy Settings

This screen lets you chose how to respond if this custom rule matches. As you can see there are a variety of options. In this example, I am chosing to log only.

Step 5: Save the new Rule Config

On this screen, we see our final custom rule. We then click on the "Save Rules" button to add this to our polices and active it within the sites.

Step 6: Review New Custom Rule in Active Policy

This screenshot shows our new rule activated rule in the policy with all of the information we added in the custom rule editor.

Step 7: Review Alert Details

If any unauthorized client does attempt to log into the "admin" account, then alerts similar to the one below would be generated.

The Analysis tab shows you all of the various events that triggered including our custom rule. If you want to see the actual request made, you can view the Request tab data as shown below:

As you can see, the two main request components defines in our custom rule (URL + Param value) are highlighted and this event was triggered because the client IP address was not authorized.

Conclusion

Hopefully this blog post has helped to show you how you can use WAFs to help implement custom protections for commercial 3rd party applications.