At TCH we always try to keep our ear to the wall regarding trends in the industry of various forms from new service demands through to security.
Last month word had come to us of a new and emerging trend that was resulting in the compromise of tens-of-thousands of web sites hosted in similar environments to that of TCH, no doubt very concerning to us at first glance. Naturally our first course of action was to research this issue as much as possible to ferret out all the facts of who, what and how this issue was propagating itself across so many web hosts (see the referenced articles at the bottom of this blog entry for more details).
After an evening of wall-to-wall red-eyed trolling across industry news & security sites, IRC chat rooms, and forums of all kinds, the real danger of this new trend roared it ugly head; nobody knew exactly who was responsible for these incidents but most importantly and startling is that nobody had any concrete facts on just how exactly systems were being compromised. So with only a few facts in hand while being mindful of the speculation out there, we set out to combat this threat head on.
The first step was to take what we knew, or to put it more bluntly, what we didn’t know to use. This lead us on a vigilant path to review all servers for available updates for both the control panel and operating system along with ensuring they were consistently installed. Once that task had been completed it left us a bit more reassured on the state of our servers.
Next up was a review of what security practices are in place on our servers, although this is not something I can go into specifics about it is sufficient to say that this review was quickly put behind us as we emphasize on multiple layers of server security from the moment a server is configured & prepared for production use by our techs.
Finally came the most important aspect, actively defending ourself against an attack we know little about. This is where our intrusion detection system (IDS) comes into the fold, we took some of the few facts we had which included the naming scheme for the infected .js files and created a pattern based rule for our IDS. This allows our IDS, which sits on the border of our network between our core router and switching hardware, to scrutinize all traffic coming and going across the network looking for any signs of compromise from the “random .js” exploit toolkit. In turn if any matches in traffic are found, our IDS prompts an alert on our management interface which we can then promptly act on to combat the situation.
So far we have not seen any indication both from our IDS or reported web site issues to indicate attempts against TCH servers but by being mindful of the risks while taking proactive measures – we strive to be one step ahead of the curve on this and other emerging threats.
References:
Linux.com
ComputerWorld
