Previously, we discussed the first three steps on reacting to a successful attack. This week we will finish off with the last two steps of this five step process.
Step four: delegation of responsibilities
Whoever owns the account is responsible for the code that they have uploaded. This means that due to liabilities it is best to delegate ANY changes in code to them, and they should (hopefully) have a developer or webmaster who would want to handle it anyways. Furthermore, if your server has 1000 accounts then there is no way you will ever have time to audit all accounts for input sanitation and other vulnerabilities. It is a good idea as any shared host to have a publicly documented abuse procedure allowing you to suspend the site and pass it off to the owner or their developer. Nobody knows their code better than them, and they are responsible for ensuring their own account security. They control the code, they set their passwords, and therefore they are responsible for doing so without jeopardizing your business. Conversely, you have a right to enforce policies that keep your server safe and secure, so donâ€™t be afraid to leverage them. This includes suspending abusive or compromised accounts because it absolutely has an effect on the serverâ€™s integrity. How you set and enforce these policies is your prerogative, so I would strongly recommend consulting a local attorney or expert as laws vary wildly by location and are not generally written to be read by the lay person.
Step five: Follow up
Any abuse procedure should include some pressure on the client to provide the steps taken to correct the issue. It may even behoove one to not allow the siteâ€™s suspension to be removed until the client can provide a complete plan of action for remedying the abuse and ensuring the continued security of the environment. If we do not follow up on these, then we are leaving our server and therefore our business open to attack, so once again letâ€™s not get too comfy. Although this will of course be unique to the situation at hand, here is a decent set of guidelines for your abuse policy and how to follow up on it:
- Did the plan of action provided by the client constitute an effective remedy for both the initial attack vector as well as the resultant malicious activity?
- Was the plan followed through completely and thoroughly? Were ALL associated passwords updated? This should include all FTP, email, and the cPanel passwords.
- Did their post-recovery update include exactly what changes were made? Was any code updated? Were any weakly written scripts removed from the server completely? It isnâ€™t uncommon for people to leave code laying around thinking that because it isnâ€™t used it wonâ€™t be compromised. If the code is there, there is generally a way to get to it so itâ€™s best to completely remove any unused code.
- Did they make any changes or checks regarding their database? Many CMS back-ends rely heavily on database content, so if they donâ€™t sanitize their database then itâ€™s entirely likely that a back door is waiting to allow the attacker right back in. Sometimes it may be as simple as creating an Admin user that you could likely miss amongst the siteâ€™s many users.
- Run an audit. Come up with your own procedure, and add to it regularly. Check WordPress/Joomla/Etc. versions to ensure that everything is up to date. Check for known plugins/addons that have caused issues. You can find PLENTY of information with a rather boring â€ś<insert your CMS/plugin/addon here> vulnerabilitiesâ€ť search. For example, the twentyten is one Iâ€™ve seen plenty of times getting compromised, and using the â€śtwentyten vulnerabilityâ€ť search method as indicated above I get the following:Â http://www.securityfocus.com/bid/57073/discuss
I strongly recommend having a regularly updated audit process. Black hats and script kiddies are working tirelessly to compromise servers and the sites that reside upon them, so itâ€™s sadly necessary for anybody whose income relies on this sort of thing to stay frosty.
- Securing your website or dealing with the fallout
- Securing your website or dealing with the fallout Part 2