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
user(a)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=globaladmin§ion=Rights
check "Prevent unregistered users from editing pages, regardless of the
page
or space rights"
Niels
http://nielsmayer.com