Oh, that’s a sad thing. No one likes to read that. But what you may not realise is that is sad for a number of reasons. Firstly, because parting – well it kinda feels like we did something wrong – and Secondly – because the chances are it will continue to happen. What follows are a few informal words on experiences of this.
We will normally call it compromised – however hacked, breached or even burst are terms that I have heard used in the past… or the slang p0wn3d if you want to get all Mr Robot about it. The end result in each case is the same. Someone has gained access, or is using resources not intended for them for means that you have no control or involvement in. In general – badness. They do not tend to break in to tidy up – fix that annoying bug with that third page in – or scrunch down your images so they load faster – they are there to make use of your resources – and for bad reasons. Bad reasons include data theft, attacking others, infecting others, infecting you, sending out malware, controlling other machines – the list is long and varied – but the common theme is there – badness.
Nine times out of ten we will notice this before you do. We will notice this because you will start sending out huge amounts of email, or web traffic will go through the roof.
Nine point nine times out of ten – this will also be ‘nothing personal’ it will be automated – it will have nothing to do with you – they just found a way in. This is what is known as low focus, low skill. It is not nice – however it may help you to sleep at night.
Formality kicks in – we let you know / you let us know – and the more obvious files may be highlighted.
This is where the whole story can go one of two ways. The way in which the issue is addressed, or it is sidestepped. Here are some examples of the latter for amusement if nothing else…
I will have option one please…
Deleting the files you can see – mentally announcing “nothing to see here” – and moving along.
Door two for me please….
Restoring back the files over a compromised site, or still using the same database… not changing the database login details from the ones that could be (and will have been) read previously on compromise.
Door number three please….
I have applied patches – that should fix it, I will close the door after the horse has bolted.
Number four!
Files wiped clean. Restored from known good, patched up to date. Winning. But with the same database, or the same database login details.
…
… the variations continue around a common theme. What is missing are the reasonably basic steps below:
– Do not change, touch, view, a thing – note times, dates, users;
– Get help and report it – to us, and if serious enough to actionfraud.police.uk ;
– Identify how this happened, the root cause – be that lack of patching or other;
– Archive up the broken site and take it off the webspace;
– Wipe the space CLEAN, not forgetting the DATABASE TOO;
– Restore from a known good backup prior to the identified breach date;
– Now take positive steps towards:
1) Preventing the previous root cause occurring again;
2) Having a look to see if there is anything else you can do.
That is a fair amount – but this is just being diligent.
Given that it is in the interest of the compromiser to obtain and maintain access, if a backdoor has been installed, they will be back straight away. If the same compromise exists, it will be exploited again. If the compromise was a lack of patching, they will just wait until it happens again.
What about you then?
We take a bunch of care to make sure “we” don’t feel the same pain. In fact, we have a number of tools on a number of platforms – visible and otherwise that will be invisibly stopping the wolf at the door. We work with partners such as patchman and bitninja providing collective intelligence, patching and blocking – as well as employing such tools as cPhulk and fail2ban to block frequent fliers. Equally you will have noticed the web application firewall on some services. Most of which churn away saving you again and again… so events are way down on what we used to see.
Our servers deliver ” a lot “ of sites.
Should the unthinkable happen a lot of our servers contain their users in such a way that one account actively exploding will have little to no impact on the other thousand users… gone are the days of that thankfully. These cages help us ensure that your service is a fair as possible and unaffected by those around you.
“It cannot be us, it must be you, and we are moving” – what has to happen has to happen, but do so with the knowledge that while the account or subscription has been compromised… the server has not. We are here to advise, and we have a lot of experience in both what occurs, what is commonly left un-done, and how to best recover from it should the worst thing happen.
The mantra goes a little like this:
– Backups, backups, and more backups;
– Patching, always patching;
– Strong passwords (https://howsecureismypassword.net/ always amuses);
– Restrict user logins, or abilities, specifically uploading;
– Forms with captcha;
– FCKeditor or TimThumb – if you installed it keep on top of it;
– and finally lock down logins and privilege to locations OR countries OR 2FA.
As with anything – if you are going to put anything of value online, think about the risk it poses to you, to others, and how exactly you are going to manage if that is defaced, deleted, breached…. and for businesses that has implications with regards the Data Protection Act. Scary stuff.
The internet is a force for good, but in the same way as you wouldn’t leave your shiny things on a table in a bar or coffee shop you quite liked while you went outside to make a call…. probably best to get streetwise, and take a few precautions.
In summary.
If your site “keeps getting hacked” then the chances are that the issue will move with you.
It is super fine to want to call it a day … relationships come to an end … but we just don’t like to think of you going on to have it happen again.
“It’s not you…. it’s me.”
….or in this case… as uncomfortable as it may be – your code. So, get in touch, ask us – and let us help.