Final Report for Project 287 - Security Web Servers

Overview

The aim of this project was to see what can be done to limit the possibility of a web server being compromised, and if it is compromised, limit the damage that could be done.

We came up with a list of possible options that could be implemented/considered when configuring a web service. These would help harden that service against attacks. We then implemented some of those options as default configuration changes for DICE services using the dice/options/apacheconf.h header file. Though we were concentrating on web servers, a lot of the items on the list could apply to servers running other services.

We were never going to implement all the ideas on our list of options, but we did hope to do more than actually achieved. However, as little or no time is now being spent on this project due to other priorities the project has been closed. We can always come back to the list and pick off more items as time allows.

What was achieved

Between ourselves (the computing staff) we came up with a list of various options we could implement to improve the security of a web server. This list remains on the Wiki as a general page for people to refer to, and continue to add to.

https://wiki.inf.ed.ac.uk/DICE/OptionsToSecureWebServers

Apart from the list, which in itself is a useful outcome from this project, some of the quick wins were implemented. Most were changes to the default configuration of the apacheconf component, the dice/options/apacheconf.h header and are documented on:

https://wiki.inf.ed.ac.uk/DICE/SecuringWebServers

Links to the specific configuration changes are on the list.

It isn't always the case what are sensible defaults for one site, are appropriate for other sites. So there are easy ways to opt out of some of the default sensible settings, by #define'ing the appropriate variable(s), eg sites that require large uploads will probably want to increase the size various mod_security limits with the DICE_OPTIONS_APACHECONF_SECURITY_BODY.*LIMIT defines.

Or again, mod_security can be overly paranoid, and DICE_OPTIONS_APACHECONF_SECURITY_ALLOWHYPHENS avoids some false positives when submitting web forms.

What wasn't achieved

There were a lot of possibilities on the list of options one could consider when securing a web site. We were never going to come up with a canned solution for all of them, as some are too service specific eg HTTPS and Cosign on every service; and some just too hard, eg monitoring logs for "odd" requests. What's "odd" for one service, might be fine on another.

None of the "spotting a compromise" type suggestions were implemented. I did start looking at monitoring and reporting outbound email from a server, but then decided I was reinventing the wheel, and I should perhaps be looking at something like rrdtool. I did have a look, but didn't spend enough time on it.

The MPU are already using "chkrootkit", "rkhunter", and "auditd" for some of its service, so we should have been able to come up with some concrete guidance for the use of those tools.

Problems

There were no real problems with this project. Sometimes the scale of it was a bit daunting, given all the possibilities that could be deployed to secure a web service, but I just had to keep reminding myself that we were never going to implement for all of them.

However I'd have hoped to have implemented, or better documented possible strategies for, more of the list of options than I did. I'm just going to put this down to poor prioritisation on my part.

Conclusion

Though what has been produced is useful, there's certainly more that could be done. I've only spent about half the time allocated to this project, but unless we are happy to have this project drag on, I propose we close (or stall) it until the SL7 migration work is complete.

We could spawn a follow up project at a later date, or restart this one of we choose to stall it.

In the meantime, I'd imagine some things in the list of options may actually get done as a side affect of other tasks.

Time

The project was estimated to take 4 weeks (140 hours), so far I've spent 9 days (64 hours), over 2½ years!

-- NeilBrown - 24 Sep 2015