Trustwave SpiderLabs Exposes Unique Cybersecurity Threats in the Public Sector. Learn More

Trustwave SpiderLabs Exposes Unique Cybersecurity Threats in the Public Sector. Learn More

Managed Detection & Response

Eliminate active threats with 24/7 threat detection, investigation, and response.

Co-Managed SOC (SIEM)

Maximize your SIEM investment, stop alert fatigue, and enhance your team with hybrid security operations support.

Advisory & Diagnostics

Advance your cybersecurity program and get expert guidance where you need it most.

Penetration Testing

Test your physical locations and IT infrastructure to shore up weaknesses before exploitation.

Database Security

Prevent unauthorized access and exceed compliance requirements.

Email Security

Stop email threats others miss and secure your organization against the #1 ransomware attack vector.

Digital Forensics & Incident Response

Prepare for the inevitable with 24/7 global breach response in-region and available on-site.

Firewall & Technology Management

Mitigate risk of a cyberattack with 24/7 incident and health monitoring and the latest threat intelligence.

Offensive Security
Solutions to maximize your security ROI
Microsoft Exchange Server Attacks
Stay protected against emerging threats
Rapidly Secure New Environments
Security for rapid response situations
Securing the Cloud
Safely navigate and stay protected
Securing the IoT Landscape
Test, monitor and secure network objects
Why Trustwave
About Us
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Security Operations Platform
Trustwave Security Colony
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Trustwave PartnerOne Program
Join forces with Trustwave to protect against the most advance cybersecurity threats
SpiderLabs Blog

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

12073_d7f54bff-d2e4-437f-a462-0f6559ed2030One 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
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
Cookie: JSESSIONID=589506ae-50a6-4133-b8db-4af0453f5846
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 83


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

<LocationMatch /libs/cq/core/content/login.html/j_security_check>
SecRule REMOTE_ADDR "!@ipMatch" "id:'23000',chain,deny,log"
SecRule ARGS:j_username "admin" "t:lowercase"

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 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

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.


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

Latest SpiderLabs Blogs

Important Security Defenses to Help Your CISO Sleep at Night

This is Part 13 in my ongoing project to cover 30 cybersecurity topics in 30 weekly blog posts. The full series can be found here.

Read More

2024 Public Sector Threat Landscape: Trustwave Threat Intelligence Briefing and Mitigation Strategies

Trustwave SpiderLabs’ 2024 Public Sector Threat Landscape: Trustwave Threat Intelligence Briefing and Mitigation Strategies report details the security issues facing public sector security teams as...

Read More

How to Create the Asset Inventory You Probably Don't Have

This is Part 12 in my ongoing project to cover 30 cybersecurity topics in 30 weekly blog posts. The full series can be found here.

Read More