Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have a website built on an old pigg version (from 2006). The site is hosted on dreamhost shared server. This morning I found that the main database of my site was completely erased.

How can I confirm whether it was a hacker or something else has caused it? What can I do to prevent it from happening again? I cannot switch to a new version of pligg as I made many customizations to the original version.

Any advice is highly appreciated.

share|improve this question
    
Do you have SSH access to the server? Or do you just have acess via a control panel? –  Mark Davidson Aug 11 '09 at 12:37
    
I have SSH access –  Niro Aug 11 '09 at 12:38
1  
Not being able to patch the application seems like a big problem that's hard to do anything about without making your modifications in a way that will allow you to keep the base application up to date... –  Oskar Duveborn Aug 11 '09 at 12:40
    
Thanks everyone for the helpful answers. –  Niro Aug 16 '09 at 5:48
add comment

9 Answers 9

up vote 7 down vote accepted
  • Check your access log and database query logs (if you log them)
  • Check with your hosting provider to see if maybe the database server has crashed and they missed restoring yours.
  • Search for vulnerabilities that your version of pligg is affected by.
  • Use a stronger database password and isolate privileges to least possible.
share|improve this answer
1  
+1 Check with the provider –  Oskar Duveborn Aug 11 '09 at 12:40
add comment

If you cannot switch to the latest version of pligg then you will need to backport any security updates made in the last three years to the version you have. I would suggest that updating your customisations to work with the latest version would be a lot less complicated.

In order to stop it happening again (or at least minimising the risk as much as possible) you need to ensure that everything is kept up-to-date with security updates. You really can't short-cut this if you need the site to be publicly available.

Also, to mitigate the damage caused if it does happen again, you need to setup a decent automated backup regime.

share|improve this answer
1  
That's assuming it wasn't the customisations that introduced the security hole... –  Rowland Shaw Aug 11 '09 at 13:16
    
Fair point, though using a 2006 vintage version of the base code means that it is likely to have had many updates if it is an actively maintained project. –  David Spillett Aug 11 '09 at 14:26
add comment

I cannot switch to a new version of pligg as I made many customizations to the original version.

I'm not a server genius so I can't help you with tracking down how it was hacked, but I can offer you some advice. You should be manually patching your installation with the new security fixes that come out.

share|improve this answer
3  
Don't know why you are being modded down; you make a very obvious point. When you run insecure software that is easily externally accessible, it is a matter of time before a botnet/kiddy/cracker comes along and blows your house down. The OP should definitely be trying to keep up with the latest exploits in all software externally accessible. –  David Rickman Aug 11 '09 at 12:59
    
He's being modded down because manually patching your software to keep it up to date is a poor solution, compared to simply porting your own code (that you most likely know much better) forward to new versions. Or better yet, use a good framework with a solid API that doesn't require porting when new versions come out. –  Lee B Oct 8 '09 at 18:20
add comment

I'd take a look at the exploits for pligg if you really can't upgrade I'd still look into intergrating fixes for these specific vulnerabilites. As they are all quite nasty and involve SQL injection and remote code execution. It might be a case of just adding some additional validation in some places.

share|improve this answer
add comment

Are there any log files you can read? Perhaps you can see some errant querystring that resulted in a SQL injection attack?

share|improve this answer
    
I believe that log files are availabe. could you point me to some further information on how to use the log files to find the culprit? –  Niro Aug 16 '09 at 5:49
    
What I would do is manually examine the files. Look for any SQL commands that are in the URL. The commands could be URL encoded, so you may need to decode the log file (google URLDecode). –  Joe Aug 16 '09 at 15:27
add comment

Log files, assuming they've not been altered

You simply can't be sure of anything I'm afraid

My guess would be that if you're using some older software, then some script kiddie has run some tool to exploit. What they've exploited, you may never know

You may be able to contact Dreamhost to see if they can offer any insight, but I would guess they can't

share|improve this answer
add comment

I would start by filing a ticket with via Dreamhost portal and see what they can find out for you. Although if the point of entry was not your through the web application, they might not be that forthcoming (not a judgment on them in particular, just a cynic view of people in general).

If you can't update it, can you limit who has access to it? Maybe move to a vps so you can use iptables to restrict access to certain IP address.

share|improve this answer
add comment

Exploits of pligg . It is sometimes useful to check script-kiddy sites for exploits . Most of them have comments, how they have been made possible, so you can:

a)Patch source

b)Use mod_security to filter requests (http://www.modsecurity.org/).

share|improve this answer
add comment

Assuming you find out that the problem is with pligg (seems likely, as you've said it's an old version, and I've never heard of it, so it's probably not got a lot of eyes looking for bugs in its code)...

You're going to be very limited. As damage control:

  • Look through the logs, figure out what happened (talk to experts if necessary), and patch up at least that hole. Ban the hacker's IPs using firewalls or webserver access control rules. As others have said, try to backport anything that fixes the attack vector, if you can track down their entry point, and find a bug fix for it in newer pligg versions. Whatever you can reasonably (or even with hard work) do to prevent that exact same thing happening again. BUT, I really wouldn't try to "update" your version by backporting all security fixes. That would be a nightmare.

  • You can run log analysers/active IDS systems to actively identify and ban hackers. Fail2ban, for instance, does this sort of thing.

Mid-term:

  • Get a pristine copy of the old pligg version you installed (a copy without your changes)
  • Use a version control system like git to apply your changes on top, and git a diff of everything you've changed since the pristine version
  • Get the latest version of pligg, and apply your diff to it. It probably won't work, but you'll only need to change the minimum to get it working. Consult the changelogs and particularly the upgrade notes for pligg, which should help you to port your code.

A better, more long-term solution:

Get away from pligg, since it seems to have failed you. Having to customise software so much that it's no longer upgradeable to new versions means that it's badly designed. Get better software to base your code on, making sure you can write clean, portable code in it that doesn't alter the code of the product. Upgrades should then be clean and compatible, barring any small and infrequent necessary changes that the product release notes explain.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.