| 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 |
DICE Web>DevelopmentMeeting>Project287SecuringWebServers>OptionsToSecureWebServers (16 May 2016, NeilBrown)EditAttach
Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.