Site hacked ~ Check your Google cache NOW!

Maybe, but I doubt it ~ they are taking a very disinterested approach to all of this and I'm not all that impressed to be honest...

Time to move...

 

Is there not an 'oftel' for webshosts? Some kind of watchdog/official body?

 

ha, i remember the UK launched 90 internet police a couple of years back.

90.. thats less than the number of staff some people have here at dp.

Also oftel doesnt exist any more. Its ofcom - office of communication - covers tv, net, phone etc etc..

 

Is it worth trying to go to them?

 

If your brick and mortar shop comes crashing down due to the owner not maintaining it, and he wouldn't care, you'd get some regulating bodies in there. They have responsibilities. It MUST be similar for webhosts, surely. They are probably obliged by means of the data protection act to at least keep your data separated from others sufficiently.

I don't know the details but if they show ignorance I'd try and whack them from a different angle, from above them.

If they offer merchant solutions, they have to be verified by VISA. Tell VISA and they might be threatened with suspension. Etc.

 

Damn, I was hoping that this would explain the recents drops for one of my sites. No such luck.

 

That's the VISA CISP program.

If you can show that the vendor is not protecting cardholder data, you can cause the vendor an incredible amount of trouble.

 

Not unless you can show credit card details have been stolen. From my years working for ISPs I can tell you that although the police were generally very friendly and polite, they didn't have much of a clue - I regularly had to explain things like email headers, and the difference between an IP address and a hostname.
They also (very understandibly) concentrate on more serious crimes like child porn than simple defacements, which is essentially what is happening here.

The fact that the perpetrators don't seem to be in the UK means you're even less likely to get any joy.

 

Ditto that - every once in a great while, Apache does this to you - kinda sucks.

BTW, putty/ssh is great (I sure you are not running telnet) and consider running on a non-standard port (other than 22) since this takes care of most of the door-knockers.

 

BTW, same principals apply to non-PHP'ers ... for instance, the first thing I do in my Perl code with any user input is "sanitize" it - i.e. I have a list of characters that are "normal" [a-z,A-Z,0-9,etc] and anything ELSE is replaced/removed. Note that the "only allow what I know is OK" approach is preferable to "remove what I know is bad" ... since in the later case, there may be something you don't know is bad. CR's/LF's/null's are especially problematic. Ditto ";" if (on Unix) you are turning around and running system commands - be VERY careful doing so with user input.

None of this ensures security of course, but it can only help and is good programming practice.

I have crackers "knocking on my door" all the time and it's pretty annoying, although fortunately, I've been able to mostly ignore 'em - helps that I do Sysadmin in my day job - good luck!

 

I've never had a problem with Apache just dieing for no reason. Are you sure your logs aren't exceeding 2GB?

I use the excellent monit to make sure everything stays running - in the event there is a problem it will send you a mail and then restart the service.

As for SSH door-knockers - there's a hell of a lot about, which I why I'd always strongly recommend key-based rather than password-based logins.

 

I don't remember Apache ever flat-out dying on me (and I moved to daily rotations versus weekly so the 2GB limit wasn't an issue) ... but I certainly have seen an "apachectl restart" kill the existing processes, but fail to start the new ones.

And yea, having monitoring is a darn good idea.

 

Is there actually a solution to hackers and folk who want to 'destroy' websites and there rankings then, or are we all pretty much sitting ducks?

Say one had a successful website pulling in thousands per week and relied on this 1 website for income - how would one go about securing the site and the server absolutely so that the only thing the site is at threat from is the latest update by Google?

There's enough to worry about in this game, nevermind hackers and securing your hosting and site etc - this hadn't crossed my mind much.

Are we (the average Joe) talking about renting our own server at a company and paying for it to be administrated and secured properly for every eventuality? Heck. This is the kind of stuff that frustrates me about this Internet lark. You have to be not just a jack of all trades, but an extremely good jack!

Pete

 

Do you accept submissions of any kind on your site? Maybe they are inserting the code into the submissions. If that is the case you need to install a filter to filter out that junk. If that's not the case maybe your hosting account was compramized.

 

Well, here's an issue I see, and I am new on this forum so hopefully I don't irritate anyone with my comment -

When you install something such as WordPress, Mambo, Drupal or any opensource software you found, downloaded and installed you run the risk of opening your web site up. If you install something commercial, you still run the same identical risk, however you can generally have a bit more legal ground to stand on, but not much more at all.

So, how many people do you know got a hosting account, after reading on some forums, or other web resources, installed a bunch of scripts via their hosting panel and called it good? I know several - the host at that point should be liable for the security of the scripts, and should know what they are doing. However, I have seen many hosts that do not know what they are doing, or claim no liability in ther TOS.

Okay, second case - user gets hosting account, installs the software themselves - how much do they understand programming or server security? How many know the difference between register_globals on or off? I have found too many that don't have a clue, but they wanted a web site forum, or shopping cart to sell stuff in and could not afford to pay someone to help or did not want to pay someone to help. That someone being someone who knows a bit on the security side.

In the case of some of the CMS systems, such as Mambo, Drupal, Xoops, PHP-Nuke - they are so widely used and have so many malicious scripts available to hack them it is not even funny....and many time they implement earlier versions of other open source software that can cause more security risks, but people just don't know it, or don't care since they get an all-in-one package.

To further cause frustration, several of the packages have some built-in directories that they "require" to be chmod 777 to even use the software. Ouch - worse some of the files need to be chmod 777 to work, and these are known files, in known directories to the hacker script writer etc. So they open up the entire server, which in the case of a shared server, opens up every site on that machine - as well as the machine itself.

Think of a server farm - you are one of 2500 sites on one server, and the hosting company has several thousand servers. All together they host over 1 million web sites. How many system admins does it take to update that many servers to the latest kernel? The latest MySQL and PHP versions? Let alone, when they update 150,000 customer's call in because their Mambo or phpBB just choked because they are running a 6-month to 1-year old version of it that does not work with the recent server updates.

And if that isn't bad enough, as Gadood points out, you *must* be a jack of all trades and a good one at that. If you rent a dedicated server, you are in control of the entire machine, security, OS, PHP, MySQL and it is very daunting. But if you cannot afford someone to do it for you, then you *must* learn it yourself, otherwise you should just quit IMHO. If you do not know how to program, and you just install pre-written stuff, do not keep up on security issues, and run it for 2 years thinking "My site is doing good" - wow, I feel sorry for you. On the other hand, if you know how to program, and you don't know jack about server security, then maybe you need to have someone verify your programming - for all you know you may open the server to attack by using a command that increases functionality ten-fold, but in the end it is not worth it.

Then to take it one last step - as pointed out several times - you *must* check and validate all user inputed material via any accepted method (get, post, url, session, cookie, etc) to verify it is the inteded format and inteded type. Otherwise you could open things up in about 1.23 millisenconds for some really nasty stuff to come your way, or as the movies say, "Something wicked this way comes..."

It is sad this is where the Internet is - it sure has change in the past 12 years I have been using it - some really powerful things, some really dumb things and some really bad things. But as in Spiderman, "Where great power is given, great responsibility is required," or as the Bible says, "Where much is given, much is required."

If you just run along and install scripts without spending at *least* several weeks investigating them fully, reading about security flaws, requirements etc. I feel that is a loss, and should be amended.

If you are not sure of the server security find a host (by doing research) that takes care of this for you. My last host was using PHP 4.1.3 and MySQL 3.10.xx last I checked....both are to version 5+ now. Find a host that keeps up with this type of stuff.

The last thing I would say is, it stinks when things get hacked - and they will. Not IF but WHEN - even if you follow all the rules....our enemy does not follow any rules and that is the age old problem facing not just the Internet community, but all humanity.

My one question is, if you remove all the files from the server, add this .ru host to an .htaccess for deny, then restore a backup that is verified not to have this junk in it, would that not restrict this particular IP or host from the root down, provided the .htaccess was in the root? Then nothing about blocking routers, adding/modify the route using shell access (most shared accounts don't offer shell access anyway - and getting support depts. to do this is like having half your teeth pulled). If you have access to the server, dump it - then do the .htaccess for it and that should block them while you get things in order.

First thing I would do though is verify all current versions are running on the server (kernel, php, mysql, perl, ssh, etc) when changing, updating or getting a new hosting account, which after an attack such as this seems the only logical thing to do (at the bare minimum get a new IP address for your domain if possible and definitely change all username/passwords and file locations).

Well anyways, I love to ramble....sorry

 

I've seen that on Apache 1.3.x when there were config file problems (and they can be as simple as the lack of a directory specified in a VirtualHost directive). Not had it with Apache 2, so I'm hoping the problem has gone away.

Welcome to the real world kid. Bricks and mortar shop keepers have to keep their stores secure against theives. We have to keep our sites secure against script kiddies. Personally I'd much rather it was this way than the risk of having a gun shoved in my face.

 

I've blocked the SSH port by IP, I'm the only one even seeing the door to knock on.

Is it possible to spoof IP for those purposes?

 

Sorry, I don't really follow you re spoofing - you mean for the attackers? No, but they're usually running the brute-forcing scripts from other machines they've already hacked anyway.

If your SSH is firewalled so only your IP can connect to it you're pretty safe. The 'door knockers' are trying to get in by brute force, trying random usernames/passwords. I like to be able to connect from wherever I might be, so I used key based logins - there's no way for them to brute force me because password logins aren't allowed.

 

There's only a very small chance I would ever need SSH remotely and if I do, I can ring the host, do the verification business, and add the IP I'm on there and then. Within minutes.

I was just wondering whether IP spoofing was possible similar to how you have these FF extensions to spoof user agent and IP.

That monit seems pretty useful. I'll check it out.

 

Simple answer, no. The FF extensions just send a different 'User-Agent' string to spoof the user agent, and any 'IP spoofing' that's done just uses anonymous proxies. As long as you don't add anonymous proxy IPs to your allowed SSH hosts (or run an anonymous proxy on your machine) you'll be fine.