John Smith wrote: I'd definitely be interested in seeing an outline of your changes to the code to beef up security.
Ah. We haven't actually
changed the code for security, except to move the database file out of the web document root. To a large extent it has been what can we do
without changing the code.
Disabling indexing globally, and moving the database.php file out of the document root have had no adverse effects at all. (Although the latter is probably not really required since it is just PHP, and not directly visible as such to users.)
Although this doesn't protect the server itself as such, we have configured Apache to use SSL with HSTS enabled, only TLS protocols available and HIGH (3DES) and elliptic curve ciphers. Apache rewrite rules force users over the HTTPS route.
As already mentioned, all access to 'upgrade.php' has been denied. We'll enable this as and when required. Access to 'management.php' is IP restricted. If remote access is required, then the use of VPN, and a short-term reconfiguration with the VPN IP address can be done. A little messy, but we don't envisage this scenario happening very often. Access to the 'website_code/php/management' directory is likewise IP restricted. There is no access to the '/error_logs' directory. Anyone needing to see the error logs has to go through the '/management.php' route.
Since we use Shibboleth for authentication, access to various directories requires authentication. This, in effect, means that users can't do anything useful without hitting one of these directories.
We have extended the 'error log' ability (function 'receive_message') a little in that when a user logs in (via Shibboleth) an entry is written to a LOGINS error log. Likewise when they log out an entry is written. Failed login attempts are also recorded in the same log, and are shown in red (oooh!) just to try and make them stand out a bit more. In no case is the password recorded. The IP address and userid are always recorded. This to some extent provides us with an audit trail of who logged in and when.
We have also modified access to the 'management' area in that logins and logouts are recorded in a MGMT error log. Again, failed logins are also recorded. And again no passwords are recorded, and since there is only one valid userid that too is not recorded. The user IP address is recorded, and the userid used if the login attempt was unsuccessful. Failed logins here also appear in red. We have also included a log entry whenever someone 'saves' something (clicks the 'Save' button). At the moment this only applies to 'site' changes, and 'templates' I think. It should really be used whenever anything is changed/saved - licences, user accounts etc. Again it provides a bit of auditing of what was done, when and possibly by whom.
For the Shibboleth login, we have removed the userid and password boxes from the login page because they are not required. We have also removed the 'demo' link on the login page since we don't want non-authenticated users using that and (possibly) slowing the server down. The link itself has been moved to the 'Other resources' section for logged in users (so basically our users can still see the demo, they just have to login first). This way the login page presents nothing usable to users. (The main picture and copyright notice are still there, and the links to opensource, xerte and apereo are still there since they take the user away from our server.) A look at
this link
will show you.
For PHP itself, we have set the 'open_basedir' which, again, hasn't caused any problems. This obviously needs to include the document root, and any external directories that may be used. We have wondered if the 'allow_url_fopen' and 'allow_url_include' options could be set, but for the moment haven't touched these. Again, they may not be required if the code does not make use of URLs with fopen/include, but if some PHP is uploaded which makes use of these then it could offer some protection.
The MySQL setup only allows local server access to the database. There is no external access allowed at all.
Given that Xerte has plugins for ClamAV and filetype checking, we will make use of these. These still need to be tested though, and should provide a major part of the security since they should prevent anything nasty getting onto the server in the first place. We have modified the call to ClamAV to include options such as '--detect-pua' and '--detect-broken'. These, as well as the 'clamscan' pathname, should be configurable though via the management page.
Other than that I cannot think of any more we have really done on the security side of things. Standard server things such as setting up the local firewall, stopping/removing unwanted services, only local access via SSH keys, installing security software, monitoring software, patching etc are applied to all our servers.
John.
