Options to Secure Web Servers

As a product of Project287SecuringWebServers, we produced the table below of various possible actions/considerations people could take when configuring a web server. Some of these could equally apply to other forms of service too.

It is hoped this list will continue to evolve, and links to actual code/configuration/documentation be added as time allows. Note the Priority column was only used as guidance for the project.

Priority What Difficulty Effectiveness Notes
10 Regular rootkit scan Easy High Again assuming low false positives, a good way to spot a compromised machine. Low impact on users
10 Monitor outbound email (volume of, rather than content) Easy High We should spot a spike in number of messages being sent. Low impact on users
10 Reduce apache (and any other) identity strings Easy Low Low impact on users. Done SecuringWebServers
20 Be less accommodating of older browser short comings. Easy Low Should be low impact, as hopefully people not using old browsers
20 Make sure our HTTPS is securely configured eg encryption types Easy Low Low impact on users, unless common browsers affected. Encryption types done in apacheconf-ssl.h
20 Block all outbound (uninitiated) traffic Easy Med Should be low affect on users
20 Remove common tools: wget/curl etc Easy Med Easy to do, but possibly disruptive to web service and users
20 Only allow ifriend access where necessary Easy Med from Toby. Low affect on users. Done in SecuringWebServers, but not fool proof, especially virtualhosts.
50 Limit who can publish content/scripts Medium High Difficulty will depend on the site, easy for some, hard for others. Medium to high impact on users, though depends on site
50 Run tripwire Medium High Assuming false positives kept to a minimum, should highlight compromised systems quickly. Low impact on users
50 Regular scan for known exploitable software, eg old WordPress. Medium High Tricky part keeping on top of what is current, and then searching all the relevant locations. Will impact on users, forcing them to updated old software.
60 Block outbound DNS queries/force use of local DNS servers Medium Med Low affect on users
60 Cosign everything Medium Med Difficulty will depend on the site. Should be low affect on users
60 Keeping an eye out for SSL vulnerabilities Medium Med from Toby. Keeping an eye out would be a manual thing, presumably the effectiveness depends on what the vulnerability is. Should be low impact on users, unless common browsers are affected
60 Use existing auditd to spot things Medium Med The tricky part is spotting odd activity. Low impact on users
60 Make sure OS and Software up-to-date Medium Med OS easy, software could rely on manual monitoring. Possibly impact on users if they required a specific version of software
70 Restricted set of RPMs Medium Low Difficulty depends on sites, it should be simple for new site, less so for existing ones with user scripts. Affect on users probably low
70 Close unnecessary ports/services Medium Low If truly unnecessary, then affect on users low
90 Monitor logs for odd requests/traffic Hard Med Actual monitoring not too hard, making a determination of "odd" traffic harder. Low impact on users
90 Limit what daemons and scripts can do, eg some form of jail. Hard High Impact on users would depend on the site
90 DMZ in the event of server being compromised Hard High The effectiveness should be high due to limiting affect of compromised service, wouldn't lessen the service being compromised. Might impact users depending on service
90 Monitor network traffic. Does a server suddenly start talking to external hosts? Hard High Actual monitoring not too hard, making a determination of "odd" network activity harder. Low impact on users

-- NeilBrown - 16 May 2016

Topic revision: r1 - 16 May 2016 - 15:34:30 - NeilBrown
This site is powered by the TWiki collaboration platformCopyright © 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