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-management-tp4191478p4197507.html Sent from the XWiki- Users mailing list archive at Nabble.com. _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
