Do not enter!
Traffic laws are actually quite simple: You stop on a red light, honor
the speed limit, and, of course, do not enter a one-way from the opposite
end or park in a restricted area. Despite all the individuals participating
in the daily traffic, the aforementioned rules usually work out quite good.
Basically, because everybody knows about them and more or less adheres to
It seems quite obvious that bending the rules would not exactly be a
smart thing to do during your driving exam. But after passing it? When
driving through the city the other day all of a sudden everybody was slowing
down for no apparent reason. But, sure enough, a "flash" later some guy not
paying attention scored himself a rather expensive photo — for
speeding within city limits.
As it seems, merely having rules is not enough. There has to be someone
to enforce them. And to enforce the rules, someone has to go patrolling.
What seems to be so obvious for road traffic and its rules seems to be less
obvious for many web developers. They tend to slack on defining (and
monitoring) what is happening at the application level as well as the
infrastructure level of their application. It is not enough to run a default
install of your operating system of choice, add whatever services you need,
and hope for the best. Considering the amount of money as well as damage to
reputation, either directly due to fraud and abuse or indirectly by time
lost to recover a hacked system or software, the "let's hope for the best"
approach is of arguable quality. And we are not even considering general
Before you can implement any access rules and define means to enforce
them, you need to consider which services you actually need, how they are
supposed to communicate, and with what permissions you want them to
Hardening the systems (which — besides other things — means
removing unneeded services that come with a default installation or
enforcing security rules such as limiting shell access to a certain set of
IP addresses and users) is the first thing to do once the base system has
been installed. This is a prerequisite for a secure environment.
Given the fact there is no such thing as 100% in security on the other
hand, it is vital to define what the risks are and what a failure in
enforcing any of the aforementioned rules might result in. The
infrastructure you are going to use or are already using is likely to be
under constant attack. Either by manual attempts to hack into the system or
by automated scripts and bots that are always looking for new victims. The
housing location, for instance, and the type of uplink for your server might
be as important as the operating system and other software components as
well as the versions in use or the hardware platform the whole thing is
Thinking about the uplink and location for the server might not seem
relevant to security at first glance. But is yet another key factor in the
broader picture: No matter how much time and money you spent on securing the
services reachable via remote connections on the software level, all these
efforts are for naught if there is no security protocol for physical access
to the machine in question. Why would a dedicated attacker try to hack into
your well protected database server when it's so much easier to simply steal
the physical machine — or the latest backup tape?
There is also no point in securing only one — possibly prominent
— system while leaving other parts of the infrastructure unprotected,
as I have seen during an audit a while back: Imagine a web server which is a
protected by an application level firewall, only allowing valid HTTP
traffic, hosted on a sealed box making it virtually impossible to hack it.
But the database was running on an unprotected 3rd party machine, open for
everyone to connect to. Even though that was originally only planned for
development purposes, there was now no need for an attacker to hack his way
through the firewall to gather all the data he might need.
But how can you tell if someone is actually trying to break in? Pretty
much exactly as the police does for road traffic: with speed checks and by
patrolling. A properly configured firewall will show as well as inhibit any
unauthorized communication within the network and all you need to do is
monitor the vital signs of your infrastructure. Apart from network traffic
that includes operating system level details such as CPU load and memory
usage, continues with gathering statistical data to tell expected traffic
peaks from attacks, and ends with analyzing logfiles for unusual and
potentially problematic warnings.
This article originally appeared in Web & PHP magazine.