On Sat, Dec 19, 2009 at 5:49 AM, esdaniel xw...@esdaniel.com wrote:
I asked Vincent if there was a security how-to / checklist page in the
xwiki
user guide and as such this does not yet exist.
As security is such an important issue for public-facing sites, coupled
with
the fact that in order to help those who have to ensure they can carry out
necessary due diligence on security before they are allowed to adopt
solutions such as Xwiki, I'd like to request the help of the community to
gather knowledge and best practices together.
This thread is a request to gather information from experts and users alike
to then create pages in the user guide that provide security guidance for
administrators of public-facing Xwiki deployments
(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
u...@host.com 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=globaladminsection=Rights
check Prevent unregistered users from editing pages, regardless of the page
or space rights
Niels
http://nielsmayer.com
___
users mailing list
users@xwiki.org
http://lists.xwiki.org/mailman/listinfo/users
