FinalProjectReport287SecuringWebServers < DICE

DICE Web>DevelopmentMeeting>Project287SecuringWebServers>FinalProjectReport287SecuringWebServers (19 Sep 2016, NeilBrown) (raw view)EditAttach
---+ 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 <code>#define</code>'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
<code>DICE_OPTIONS_APACHECONF_SECURITY_ALLOWHYPHENS</code> 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&half; years!

| *Quarter* | *Hours spent* |
| 2013 Q4 | 4 |
| 2014 Q1 | 5.1 |
| 2014 Q2 | 9.4 |
| 2014 Q3 | 13 |
| 2014 Q4 | 2.4 |
| 2015 Q1 | 16.8 |
| 2015 Q2 | 5 |
| 2015 Q3 | 0.6 |
| 2015 Q4 | 3.1 |
| 2016 Q1 | 0 |
| 2016 Q2 | 4.3 |
| Total | %CALC{"$SUM($ABOVE())"}% |

-- Main.NeilBrown - 24 Sep 2015
Topic revision: r4 - 19 Sep 2016 - 11:09:54 - NeilBrown
DICE
This is WebLeftBar
Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies