Thanks Niels, this is very helpful. A few questions... Re: #2 / #3 Forgive my lack of understanding here but how might this affect friendly URLs, if at all - what's best way to approach friendly URL config when following advice below? Niels Mayer wrote:
(1) Have the java-web-server (e.g. tomcat) only accessible on localhost:8080 such that server configuration requires special access beyond port 80/443 seen by outside world (e.g. SSH tunnel : "ssh -x -L 8080:localhost:8080 [email protected] cat"). This also enables java to not run as superuser -- having the smallest amount of new things running with privileges is what make sysadmins and security czars happy that they're not introducing new untested technology and new security holes into their "fortress."
(2) One of the well-understood parts of the sysadmin fortress is Apache httpd. Therefore, front the Xwiki-based website with Apache HTTPD and use mod_proxy_ajp to "firewall" the parts of the xwiki site you want exposed to the outside world on public ports (80/443) -- e.g. to access "/xwiki" use "ProxyPass /xwiki/ajp://127.0.0.1:8009/xwiki/". With this in place you can use Apache to SSL-wrap access to a java based site, and potentially add further gating based on SSL-authentication (mod_ssl) and Apache basic auth (e.g. like the 2-factor authentication I setup for https://www.ipssources.com/ <https://ipsssources.net> ). You can also use Apache configurations to further limit or disable access to any parts of the wiki that aren't used or you don't want available to the public. E.g. /xwiki/webdav/ and /xwiki/admin/ might be limited to access from certain IPs, or only using SSL, etc.
For additional level of protection (beyond Xwiki's auth gating users not having "admin" rights), one may want to block outside access to URL's like /xwiki/bin/export/XWiki/* to prevent access to "hidden" password data even if something breaks, or someone accidentally gives the wrong users, or guests admin or other rights that could compromise a xwiki based site.
(3) No passwords in the clear: Use aforementioned Apache httpd gating to prevent access to /xwiki/bin/login/* unless user accessing via HTTPS. Depending on the level of security desired, the session can then remain in HTTPS entirely, or be redirected back to HTTP... It might be a good idea to further "gate" destructive operations (e.g. /xwiki/bin/admin/ ) so that they require an SSL login. This would at least force admins to not transmit the admin password for the site in the clear.
(4) xwiki.cfg, etc. (i) change xwiki.authentication.validationKey and xwiki.authentication.encryptionKey; (ii) be sure xwiki.superadminpassword not set.
(5) Initial XAR import of xwiki-enterprise-wiki-*.xar or on each upgrade importation: (i) After installing XAR from upgrade be sure to skip install of XWiki.Admin which will override the admin password you set for this user, setting it back to default/public password. (ii). Be sure to set a secure password for XWiki.Admin (iii). Those having imported from older 1.X xwikis may want to check to make sure XWiki.Admin doesn't have *XWiki.XWikiRights[1]* set with so that nonexistent user 'WikiWiki' can edit the 'XWiki.Admin' user. This could grant unexpected privileges to a wiki with open registration and no user XWiki.WikiWiki existing already. (iv) In /xwiki/bin/admin/XWiki/XWikiPreferences?editor=globaladmin§ion=Rights check "Prevent unregistered users from editing pages, regardless of the page or space rights"
Niels http://nielsmayer.com
-- View this message in context: http://n2.nabble.com/Security-best-practices-for-Xwiki-deployment-and-manage... Sent from the XWiki- Users mailing list archive at Nabble.com.