 Production CQ instances deserves 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 super user 'admin' have 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 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 productio 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 'anonymous' user completely. Log in as 'admin', 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' user, 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. Actionalable 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. Same applies to WebDAV access[http://dev.day.com/docs/en/crx/current/how_to/webdav_access.html]. If you're running stable in 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 account 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 2. Applicable to both Author and Publish nodes, stop CRXDE Support bundle. Go to http://<host>:<port>/welcome.html Note: Stop and start OSGi bundles does 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. 4. Applicable to Publish node, disable WebDAV by stopping related bundles. Go to http://<host>:<port>/welcome.html 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 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 is one of the same, whereas the OSGi/Web Console Admin account (by default is inactive) is a different account. b. To change CQ/CRX Admin password, use Granite Operations - Users console. c. To change OSGi/Web Console Admin password setting, 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 "Apache Sling Web Console Security Provider" bundle is in active status. If needed, stop "Apache Sling Web Console Security Provider" bundle so #c will be in effect. e. To add more user to be able to access OSGi/Web Console, simply add users and groups to the configuration of"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:
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
2 Comments
Siva
11/2/2014 07:56:08 pm
this is simply excellent note of security checklist. 4/26/2017 10:57:34 am
You can use our Security Scanner for AEM-Based websites for free. https://scan.zapts.com Leave a Reply. |
Categories
All
Archives
May 2020
|
RSS Feed
in loving memory of my mother and my 4th aunt