..or so it seems from a support point of view. Something we are seeing echoed across the marketplace.
This is part one of a two piece article – lets talk about the most obvious and wider reaching implication that effects shared hosting – spam, and blacklisting. The trouble that comes from outbound spam that originates from a website or email account on our network. It’s probably someone else …. this time.
What this means is a number of things – it means queues spiking, alerts, and by then it is already an issue. Listings on the various Realtime Black Lists (DNSBL & RBL’s) will start to occur, and with it the server reputation will be dragged down.
So what do we do about this?
Well we resolve the issue is what we do. We need to get people able to send email from the shared system as soon as possible. We will see alerts from loads rising and mail queues getting larger. Then more again as reputations drop and appearances on blacklists occur – as well as emails from external monitors. We will be not only aware but acting by the time it is an issue.
We would identify the source – stop it (that may mean turning off your website off or your inbox).
We then change the IP address that the server sends as to another, and update relevant DNS and pointers.
Notify the blacklists that there is an issue, what it was, and steps taken to resolve and await de-listing for those that allow this.
This is the elastoplast to the bullet wound – so what causes this – and why is shared hosting so afflicted by this.
Well the here is a statistic that may help set the stage.
“Over 80% of all inbound email connections we have are spam”
Not even a doubt, solid, absolute, Nigerian Prince, Blue Pilled, In Your Area Now, sPaM. Moreover this is not just us, this is a global statistic. No where to run to.
So we have neutered the cause and we have rotated the IP address, and we wait on the release from the blacklists, and improvement in reputation.
Until it happens again.
So why does it happen at all?
There can be a number of reasons for this but the two most common we see are:
– Brute forced passwords for email accounts;
– Compromised websites.
So what can you do about this?
As it happens plenty. It is as much about reducing your risk, being diligent as it is about a magic bullet. Lets cover two of the most generic and common areas in overview.
There is a lot to be said for not frequently changing your passwords. However I don’t think anyone would argue in their right mind with high entropy passwords, and passwords that are unique to a single use.
This makes remembering them a bind. At which point either air gapping them to a notebook that is in a safe physical place is one way, or use of a trusted third party manager such as LastPass is a good way to go.
It is hard to impress how many passwords are still out there and in use that are dictionary words and a number. The response we will often hear is “but that is the password I always use“, or “I cannot be expected to remember that password” – which is fine – as long as you accept that this will be brute forced within moments by an attacker.
Passwords do not need to be massively random. My two favourite examples are Edward Snowden on passwords in an interview with David Oliver stating the unforgettable example of “MargaretThatcherIs100%Hot!” – or the XKCD cartoon with “CorrectHorseBatteryStaple”. In short entropy is key. A machine can attempt 1000 passwords a second. A traditionally “strong” password will fall to this ‘brute forcing‘ in around 3 days for 11 mixed case with special chars.
Think about that a little more. Uncomfortable isn’t it?
Of course – this is all for naught if you use your machine on a public wireless network with no encryption, or you have an infection on your local machine or local network. Oh.
Passwords give access to a bunch of things:
– Your email (they can send as you and harvest your email and contacts);
– Your website through FTP (to upload files even if the site is patched up to speed);
– Your website through a login (into your account, or admin account);
– Your other resources … if you use that password elsewhere.
If these concepts don’t scare you then you should probably stop now. But this is a wider subject area – including that of using one time passwords (OTP), physical auth devices (like YubiKey), and third party auth code generators (such as Google Authenticator).
“I have not changed my code in six years and now this“
…is something that sounds quite obvious here in abstract – however is a very real statement of fact when you are the one uttering it it seems.
I have had a real dislike for car examples – however this is akin to saying “this car runs superbly, I haven’t needed to have it serviced in the last decade”. Yeah – a few substitutions, and its a very different animal isn’t it. Want to buy a car? How about a lift home? No? Must have been something I said : /
Code needs looking after – this is one of those uncomfortable truths.
In the same way as we amend and patch the services that deliver your content in line with standards, new releases, new versions, security fixes, patches, optimizations and so on…. your code will need to move forwards too. In fact this is probably something that needs a whole post on its own. Code needs love, not build and forget – there is ongoing maintenance – whether you take that on yourself, or through your developer.
Most spamming is the result of automated attacks. Thankfully. Meaning its not personal. It is low focus, and low skill, and we can sleep a little better at night. They are scanning at great speeds and frequency to the point of being the background hum of the Internet by and large – the norm – regrettably. These are hunting out known vulnerabilities – the more common the better.
Then you have the ZeroDay stuff – the “oh there is a patch out today – I had best get on that” – as this will reap the biggest results for them in terms of access to sites… as there is more likelihood that less people have patched for that particular attack.
I am talking about your *and* third party software. I am talking about those modules? Maybe even those themes? What about that form code you use? That Captcha? Did you remember to escape all of those fields? You do not allow people to upload code right? How about images? If you allow images, does it check they are images, not just something that looks like it might be an image? …these are a few of the most common.
For example if you happen to be running WordPress (along with 22% of all new website launches globally!), Drupal, Joomla – you are a common target – sure – but if you keep patched they are very much ahead of their game to be at the top of that competitive CMS tree. There are even lists you can sign up to out there to keep you emailed when they discover issues…. something else to consider.
Moreover if your code isn’t kept up to date – it wont be as optimal as it could – and will eventually cease to load… this is all the good stuff.
So what are they after?
Resources they can recruit to use for their own needs.
Sure – we still see the very occasional defacements but mostly for political or religious reasons – and very much the exception to the rule.
An inbox will be used to harvest emails, details, address books of email addresses and send their own email. Be that junk, malware, spamvertising, or part of a wider plan in terms of Phishing or Spearphishing.
A website is a tool with access to even more resources, so all of the above, phishing sites, sales sites, sources of tools, repositories for data, attacks on other sites – networks – governments.
We don’t want you to be the source of any of this kind of badness. We don’t want that on our network or hardware, we don’t want that to be the cause of pain to others on the same node or network segment… and we don’t want your customers at risk of infection, fishing, or similar.
So lets work together to keep your site secure, your passwords thought through. This is as much about diligence as it is about absolute solutions.