Attack Vectors¶
In the context of responsible risk assesment we have to think about how the server farm can be attacked from outside, what the consequences would be and how we can protect ourselves from such attacks.
In essence there are 2 possible scenarios:
- An attacker gets access to the inner part of the server farm
- An attacker manages to make our infrastructure unresponsive
Users¶
This is always the weakest link in all IT environments. The danger of mistakes by regular users is fairly limited and mitigations or recovery strategies are described in the Desaster discovery section.
More difficult is this for DevOps or system administrators. Their possible mistakes come with a huge risk to the whole infrastructure and this can only be mitigated by some weak factors:
- only grant permissions to an individual that they really need
- have a backup for every key admin but still limit the number of admins to the absolut minimum
- allow for enough resources such that every development can be tested well enough
- implement and live the culture where development always gets reviewed to increase the chance to pick on mistakes before they hit your environment
Social Engineering¶
This is an external attack which addresses this aforementioned users. Somehow an attacker wants to get access to the system so that they can steal data and manipulate the application(s). To social engineer on regular users is relatively unattractive, although even that can cause real damage. I.e. if someone external gets access to a user account with editing permission on the official site, they can easily damage the reputation of the site owner by publishing insulting or malicious content.
More important is the behaviour of users with higher permissions like DevOps and system administrators. These people have to be trained and trusted that they behave themselves and make sure that they never do anything that would allow any attacker to get access to any one of the systems.
Here is a list of guidelines that should be forced on any user and application:
- Using strong passwords
- Never re-use any password - never use any single password on more than one account
- Never share passwords or other credentials with anyone
- Never click on a link in an email, not even from senders you know
- Never download anything for which you haven't looked for actively by yourselves
- [...list to be continued...]
Domain attacks (DNS or registrar or SSL)¶
This is something that gets more and more popular. But it is a global problem and nothing that any one site owner could do anything about. However, let's quickly look into this:
If the DNS records get attacked, either by hijacking them or by overloading the responsible DNS server, then the domain is worthless for the duration of that attack. The same applies, if an attacker manages to get hold of the domain registration as such. Both of these issues are close to the topic that we've discussed above under social engineering.
The SSL attack is close to this but slightly different. It has to do with the laziness of some domain owners who carelessly order some SSL certificates and then send them around by email. In every single instruction from certificate authorities you can find a bold warning that the private key should never be given away. But what else happens when it is attached to an email? By that time it has become part of the public domain - that's a fact. And that means that a man-in-the-middle can easily sniff into assumed encrypted sessions and by that get access to the internal systems.
(D)DoS attacks¶
Denial of service attacks, whether dynamic or not, are a pretty powerful means to cause real trouble. Have such attacks been undertaken by kids in the past, that has changed and professional criminals with the intend to earn money with it have taken over.
As the owner of a single site or a small to medium sized farm thinking about DoS protection is pretty simple: protecting hosts at the border of a data center is impossible! This is because the bandwidth the attackers can afford these days is that high (we're talking hundreds of GB per second) that the infrastructure of any data center is just not able to handle that - with none of today's available mechanisms. Even worse if we get into the area of amplification attacks, the attacker only requires low bandwidth but manages to aplify the effect in orders of magnitude.
If denial of services attacks are a realistic thread to your business, you have to hide your entire infrastructure behind a shield, which is as far away from your physical data center as possible. Providers like Akamai or ClourFlare are providing such services and they come with additional features that greatly improve the performance of every web application, but they also come for a price.