|
Securing your servers & applications is always at the forefront of any “good” development group’s conscience.
If it is not, then heck, you are amateurs and your company deserves to whither and die because this is not a business where the”Fisher Price - My First Web Company” type of stuff cuts it.
This applies to the following people or companies:
Web Freelancers who deploy open source or use community-grown contributions and freeware code for their clients.
Companies & Developers who deploy or base customer-applications or tools off of open source or other frameworks.
Companies and Freelancers who DO NOT watch to see if what they are deploying for their clients and customers later develops security flaws, exploits or other nasties.
Web Hosts who run VPS or Dedicated Servers for their clients.
Probably YOU - if you are still reading this.
Bottom line is that it is often a “company-ending” event when a server gets hacked and you are not prepared both legally (read that as you have strong contracts in place to protect you from these events) - and defensively to limit the damage.
IMPORTANT - If you are hosting web sites for your clients and letting them install any number of applications like Bulletin Boards (PHPBB), CMS’s (Mambo / Joomla), Shopping Carts (OSCommerce, Zen-Cart) or even Blogs like this one - AND - you do not understand any of what we are about to list off - then you should call us TODAY (877-239-3083) because you definitely need some quick and inexpensive help to secure your business.
For anyone who has even watched a company, client or server burn because a “guestbook” compromised their entire server - this is for you.
For anyone who lets their clients install applications via Fantastico or PLESK Application Vault - then this is for you.
For anyone who does not know what scripts & applications their clients are currently running on servers you are responsible for - then this is for you.
Kevin Huisman, our Development Manager and “server watchdog” recently posted the following:
For everyone interested in server security stuff, we thought we’d pass on a bit of info.
We had been using some home-grown rules to combat hack attempts, and decided to really do some research into finding a more comprehensive rule set. Sort-of a “why reinvent the wheel”…
There is a great site to become familiar with — http://www.gotroot.com that has a really comprehensive set of rules for multiple issues - IP and proxy black lists, known bad useragents, comment spam, etc.
Some of the rule sets make sense to use verbatim:
Rule Exclusions
Comment spam blacklist
Compromised/Hacker boxes blacklist
Anti-Proxy protection
Bad UserAgents blocking
Anti-Proxy protection
“Google Hacks” signatures
Known rootkits/worms
And so on…
There’s also a badips.conf file found in the “All in one” downloads that isn’t directly linked to from their list. It’s another set of IPs to ban, and it’s specifically for Apache 1.x / ModSecurity 1.9x, which usually fits the bill on most older versions. They retired it in Mod Security 2.x. rules, since there seems to be a better way of doing it in that version.
You should also look at what they call “Just in Time” protection, a set of rules that combat known vulnerabilities in specific open source web apps.
They have rules for squirrel mail, phpbb, formmail.cgi/pl, Coppermine, and a whole host of others.. You may not really need the bulk of the rules if you do not specifically run those web apps. You can just use those you need on each server.
It is recommended that rather than a wholesale deployment of all possible rules - you merely go through and whittle the list of rules down and remove those that do not apply to the web app versions you are using. Many times you simply find that even with these rulesets some of them maye .conf files are actually behind the versions of the web apps you’re using such as when specific files with specific known vulnerabilities that have been fixed since the rules were created. This is a bit of a lower priority at this time, since it probably doesn’t save much in the way of speed or processor.
As far as processing/speed goes, it’s a fairly big set of rules when you combine them all together, and we noticed that it takes a few beats longer to restart apache, but once it’s running, we haven’t seen any significant slowdowns.
Individual results may vary based on how many domains and traffic each of your servers or VPSs have.
| 
Icons & Buttons
XML - FLASH
