How To Run A Secure PHP Web Site by Jerry Bell
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.
About the Author
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.
IT Capability
|
