You are here

Securing web servers

Project ID: 
287
Current stage: 
Manager: 
Summary: 
See what we can do to limit the possibility of a web server being compromised, and if compromised, limit the damage that could be done.
What: 

The MPU have taken steps to secure/harden the external facing ssh servers. Web servers are equally external facing and we should make sure they are as secure as they could be. And should they be compromised, limit what could be done from them.

Why: 

A compromised web server could lead to:

  • reputational damage
  • theft of personal/private/restricted data
  • the possibility of hosting illegal material
  • our equipment being used in a crime, eg phishing/fraud.
When: 

These possible threats are not new, but it's percived that there's a growing risk of damage being done. So sooner rather than later.

How: 

Possible options

  • Making sure software is up-to-date with latest security fixes/patches
  • Separate web instances so if one is exploited, damage can be limited.
  • Tighter control over who can publish web content, CGIs or web apps
  • Remove superfluous software from servers
  • Limit what can be done from a web server, eg no SSH outbound. Local DNS only, block outbound DNS, close outbound firewall holes
  • Better monitoring, eg monitor network traffic

A longer list of possible options is listed on the "Report" wiki page.

In the first instance, we only need to be more secure than the next guy, so we'll probably look at the low hanging fruit (ie the easy to do) first.

It would be nice if we could come up with simple header files people could include to implement simple fixes. Unfortunately some fixes will depend greatly on the web service you are trying to harden.

Plan:

  1. List possible steps to harden/secure sites - done
  2. Prioritise list (probably do the easiest ones first) - draft order added to wiki page
  3. Work through the list:
  4. Either implement as a simple header and/or document what's required to
    achieve an generic solution. Site owners will need to decide how to
    implement/configure more specific solution for their site.
  5. Inform site managers of new header/docs.
  6. Move onto next in priority list.
  7. Repeat until out of time.
  8. Document project.
Effort estimate: 
4 weeks
Other: 

Dependencies: network, security knowledge

Risks: see Why? section

The effort includes implementing any changes across the various managed web servers, there are 5 main ones: www.inf, groups.inf, wcms.inf, homepages/wiki.inf, aiai.ed. each may/will have different "superfluous" software.

What about other web (app) sites, eg rbs.inf, computing.help, ifile.inf, webprint.inf, pp.inf, lcfg.org etc

If we're going to limit the software on web servers hosting user generated content/CGIs, then how will users develop their content? Logon to the live service? (undesirable) Or will we need to maintain a second development version of the service which users can log into, but is not accessible outside of inf? (sounds more likely, at the expensive of maintaining more servers)