May 20, 2020
Estimated Post Reading Time ~

Tighten Up Security in Production CQ Environment

Production CQ instances deserve a tighter security policy. OOTB CQ is too loose in security. For example, you don't need to open your production for client software like CRXDE to access it, nor do you want to open up WebDAV if not necessary. Most importantly, the default password of the superuser 'admin' has got to be changed, which is not a straightforward process as you'd expect. 

In this post, I outlined specific steps that I took to tighten up the security of our CQ Author and Publish nodes in a production environment. If you are planning to launch a public-facing CQ, you can go through the same checklist.

Preliminary Checks
You shouldn't have to do this because the following should be the default when you install CQ. However, in the production environment, it doesn't hurt to check again just in case.

1. Make sure 'everyone' is not accidentally allowed to read/write/etc on all nodes. Log in as 'anonymous' (without password needed) should see nothing. Even better, remove the 'anonymous' users completely.

Log in as 'admin', 
go to CRXDE Lite, 
highlight/node, then 'Access Control Tab', 
make sure NO 'Allow' access control entry is tied to the principle 'everyone'. If so, remove them.

2. Also, check 'anonymous' is not associated with any allow ACL. However, do not remove this user as once misleadingly suggested by Adobe somewhere. If you remove 'anonymous' users, the login page for all users won't work anymore. If you had accidentally removed 'anonymous' user and can no longer log yourself back into CQ, simply restart CQ and the 'anonymous' user will be automatically recreated.

Actionable Security Checklist
CQ comes in loose in terms of security after the default installation. 

Things like the demo websites are those you definitely don't need in your production environment. 

Because you'll not be developing in your production environment, you shouldn't need your CQ instance to support CRXDE, a pre-packaged stand-alone Eclipse application. You should have such support turned off in the production environment. The same applies to WebDAV access[http://dev.day.com/docs/en/crx/current/how_to/webdav_access.html]. If you're running stable in a production environment, the read and write access from your desktop to the content repository through WebDAV should be turned off.

On the front of user privilege, particularly the user Publish Agent act upon by default if the 'admin' user. Such user may be too powerful and you'd like to designate other user accounts with less (but enough) privilege to act upon by the Publish agent. 

In general, on the production, you'd generated the least amount of unnecessary logs on the file system. Similarly, you want to reveal the least amount of user-facing script (css, javascript, etc.) through compression and minimization.

Lastly, remember to change your default 'admin' password and apply the latest security patch from Adobe for CQ.

Steps to take:
1. Applicable to both Author and Publish nodes, uninstall example package (e.g. cq-geometrixx-all-pkg-5.6.12.zip package).
Go to http://<host>:<port>/welcome.html
Goto Package Manager
Search for 'cq-geometrixx-all-pkg'
select more
uninstall
2. Applicable to both Author and Publish nodes, stop the CRXDE Support bundle.

Go to http://<host>:<port>/welcome.html
Web Console > OSGi Bundle
search for 'Adobe CRXDE Support com.day.crx.crxde-support'
Click on stop
Note: Stop and start OSGi bundles do not require CQ to be restarted afterward to take effect. If a bundle is stopped and goes back into its OSGi 'resolved' state, the status will remain 'resolved' even after a CQ restart.

3. Applicable to Author node, create/assign Replication User and Transport user for Publish Agent.

1. On Author node, create a user named 'replication-user' with permissions to read from nodes that are to be replicated from.
2. On Publish node, create a user named 'transport-user' with permissions to create/write to nodes that are to be published/replicated to.
3. On Author node, put 'replication-user' to the settings of Publish Agent as the Agent User ID; put 'transport-user' to the settings of Publish Agent as the Transport User.
4. On Publish node, put 'transport-user' of Author node to the setting of Publish Agent as the Agent User ID.
4. Applicable to Publish node, disable WebDAV by stopping related bundles.

Go to http://<host>:<port>/welcome.html
Web Console > OSGi Bundle
search for 'dav'
Click on stop for 'org.apache.sling.jcr.webdav'
Click on stop for 'org.apache.sling.jcr.davex'
Note: Stop 'org.apache.sling.jcr.davex' will cause CRXDE Lite to NOT display node structure.

5. Restrict access via Dispatcher.
Refer to this and this.
6. Applicable to ALL instances, install the latest CQ5.6.1 Security Hotfix to prevent DoS attack.

Go to your local CQ Package Share to find and search for package(s) name with 'security hotfix' for your installed CQ version, download it (e.g. cq-5.6.1-hotfix-3306.zip) and install it.
7. Applicable to Publish node, set/modify some OSGi settings to reveal the least information.

Go to http://<host>:<port>/welcome.html
Select Web Console > OSGi Configuration
Find and change the following OSGi configuration ...

Day CQ HTML Library Manager:
enable Minify (to remove CRLF and whitespace characters).
enable Gzip (to allow files to be gzipped and accessed with one request).
disable Debug
disable Timing

Day CQ WCM Filter:
set WCM Mode to "disabled"

Apache Sling GET Servlet:
uncheck 'enable JSON' and 'enable XML' (to disable JSON and XML renderer)

Apache Sling Java Script Handler:
disable Generate Debug Info

Apache Sling JSP Script Handler:
disable Generate Debug Info
disable Mapped Content
Note: Saving the above OSGi settings different than the default values will generate extra configuration nodes under one of the following places to hold the configuration with non-default values:

http://<server>:<port>/crx/de/index.jsp#/apps/system/config
http://<server>:<port>/crx/de/index.jsp#/apps/sling/config

8. Applicable to both Author and Publish nodes, change 'admin' pwd using Granite Operations - Users console.

Notes:

a. CQ Admin and CRX Admin account are one of the same, whereas the OSGi/Web Console Admin account (by default is inactive) is a different account.
b. To change the CQ/CRX Admin password, use Granite Operations - Users console.
c. To change OSGi/Web Console Admin password set, use Web Console > Configuration, look for 'Apache Felix OSGi Management Console', then edit.
d. OSGi/Web Console Admin password setting is not in effect at all (the default) if the "Apache Sling Web Console Security Provider" bundle is in active status. If needed, stop the "Apache Sling Web Console Security Provider" bundle so #c will be in effect.
e. To add more users to be able to access OSGi/Web Console, simply add users and groups to the configuration of the "Apache Sling Web Console Security Provider" bundle.
f. The following curl command is the #b equivalent:
curl -u admin:admin -F rep:password="newadminpwd" -F :currentPassword="admin" http://localhost:4502/home/users/a/admin.rw.html

9. Applicable to Author node, re-enter the Admin password for the Replication User for Publish Agent.

If you change the password of Publish node, then you have to reenter the corresponding user password set on the Author node for the Publish Agent, or your replication triggered from the Author node will always fail.


10. Applicable to both Author and Publish nodes, remove out-of-the-box sample user 'author' whose default password is 'author'. This user is not necessary.

11. Applicable to Author node, remove feature links on the welcome screen (see below) for users of specific groups.


12. Applicable to Author node, remove buttons from Websites window (welcome.html > Websites) for specific users/groups.

To edit ACL permissions for a group, traverse to /libs/wcm/core/content/siteadmin/actions/, then uncheck the checkboxes(Read/Modify/Create etc) for each of activate, deactivate and workflow nodes, then save.


before:


after - the Activate and Deactivate buttons is no longer showing:

13. Applicable to Author node, block unused features on Project Console/Screen (http://<host>:<port>/projects.html) for specific users/groups via controlling the read privilege on nodes under /libs/cq/gui/content/common/links/, under which nodes' existence will in terms control what shows on the left of the following screen:


and nodes under /libs/cq/core/content/tools/jcr:content/content/items/tools/ to control what links shows on the welcome.html page under Tools: 



There are some nodes' (e.g. jcr:content) ACLs they do not show on useradmin (http://<host>:<post>/useradmin) so they can't be seen and be edited using useradmin. Instead, you have to use CRXDE Lite. For example, to modify ACL for nodes under /libs/cq/core/content/tools/jcr:content/content/items/tools/ you have to use CRXDE Lite:Here's an example,



Also, just to be safe, if you really want to surely disallow features of Tools shown on Project Console/Screen (projects.html), remove the read permission from the following nodes:

/libs/granite/security/content/ - to disable Tools > Granite Operations > user/group management (somehow it's different from CQ Operation > user/group management)
/etc/packages/ - to disable Tools > Granite Operations > Packages
/libs/cq/workflow/content/console/ - to disable Tools > CQ Operations > Workflows
/etc/reports/ - to disable Tools > CQ Operations > Reports
/etc/replication/agents.[author|publish] - to disable Tools > CQ Operations > Replication
/libs/launches/ - to disable Tools > Authoring > Launches

14. Further review/revoke unnecessary ACL edit permissions for users/groups.
Don't give out ACL edit permission to users who can only read the node. If they have Edit ACL permission, they can make the node not accessible to you too, which is not what you want. To revoke ACL edit permission:


References
CRX Security Checklist
Security Checklist
Replication
Customize buttons on Day CQ pages


By aem4beginner

No comments:

Post a Comment

If you have any doubts or questions, please let us know.