The Risk Many people will say “but I only run a small forum on X subject. No one could possibly want to harm it – there are much bigger targets out there.” The truth is that the landscape has changed in the world of information security. Exploiting vulnerabilities has become a big business generating a lot of money. Exploiters frequently target websites to either send millions or billions of SPAMs out from, or to host phishing or browser exploit code to steal personal information from unknowning web surfers. As with any business, automation is the key to a good living, and the hackers have learned that lesson well. Most all web site attacks are completely automated. A botnet of compromised home PC’s are used to systematically attempt to exploit vulnerabilities on millions of websites.
Lately though, the attacks have become more targeted. Application vulnerabilities often exist for a distinct version of a particular application. Web applications by default boast their name and version number at the bottom of pages. Search engines pick up those version numbers. Botnets now only have to perform a Google search on a string that contains the application name and version number to get a comprehensive list of all vulnerable websites to begin a highly effective campaign of taking over sites. No decision is ever made whether or not to attack your small forum on X topic. It just happens.
A similar, but more involved process happens for bots trying to exploit vulnerabilities in mail servers, dns servers, ssh servers, ftp servers and so on.
Software Vulnerabilities
The low cost of entry for running websites driven largely by the LAMP model – Linux, Apache, MySQL and PHP, has caused an explosion of both websites and applications to run on them. Most common among those applications are content management systems and forums. The ease with which applications are developed has partially led to a crisis of sorts – vulnerabilities in sites that are only casually administered.
There was a time that restricting ports and ensuring password strength was all that was needed to keep things secure. Now, though, there are workable attacks against all facets of a site. Web applications are frequently found to have vulnerabilities that can cause code to be installed and run or to manipulate the database. Vulnerabilities in the web server itself can allow an attacker direct access to the web server OS. OS tools like the ssh daemon, the ftp daemon or mail server are other commonly exploited avenues for taking over a system.
If you decide to run a website, it is akin to taking care of a child or pet: you are making a commitment that you have to fulfill; otherwise bad things are going to happen. For years, companies have had to deal with security problems, but they’ve had designated people who are responsible for identifying and fixing vulnerabilities.
If you do choose to run your own site, you and you alone are responsible for determining when you need to patch. Here’s a good strategy:
First, identify all the applications you are using on the server. List off the following and their version numbers:
- OS - Web server (ie. Apache) - Database server (ie. MySQL) - PHP version - Names and version numbers ALL web applications. - Names and versions of all supplemental tools you run (Mail server, ftp, etc)
Next, identify the security notification mechanisms from the providers of each item above. Nearly all software has an “announce” mailing list or similar security list. Sign up for each one of them. Whenever a message comes into those lists READ IT. It will tell you about the problem, workarounds and how to fix the problem.
Making it difficult
Now that we know a bit about some of the attack vectors, methods and motives, we can start to construct a reasonable method for managing security on a site.
First and foremost, we must have a solid base of keeping software up-to-date.
Next, obscure the version numbers and preferably names of the applications you are running. Many web applications have license terms that require the name and a link back to the author’s site – but frankly, the authors need to get over that and either come up with some other way of obtaining the benefit that all the links create or face the consequences of placing their user-base in harms way. Likewise, ssh and mail server applications may have the ability to change their banner to display something other than the version number.
For things other than web servers and mail servers, it is a prudent and easy step to change the port that they applications listen on. For example, if you have sshd listen on port 23 instead of 22, bots that are searching for vulnerable ssh servers or performing brute-force login attempts will see nothing and move on to some other site.
The above steps will not reduce your risk of being hacked to zero. A determined attacker has many different ways to penetrate defenses, but then again, the vast majority of attacks are not carried out by skilled people; they are done either by “script kiddies” or with bots. The real pros are after the big money that comes from writing the bots, malware and the like.
In summary, securing your server is your responsibility. If you are unable to perform that responsibility, you need to seek assistance from those who can by choosing a different service provider or plan.
Jerry Bell has been in the information security industry for 8 years and has spent 4 years as the Director with responsibility for information security and regulatory compliance at a $300M public company. See http://www.itcapability.com for more suggestions on security and http://www.networkstrike.com for security news.
