We have been under recent attacks from a hacker and we need to be able to stop all IP addresses from editing files except for the ones at our office. I know how to do this via an .htaccess file however I am at a loss when it comes to just a server side thing. Unfortunately we use a server at HostGator and they couldn't tell me much. I am not much of a server person, so I am not even sure if this is the best route.

Any guidance or help on the subject matter would be greatly appreciated.


  • 4
    How in the world are people from random IP addresses able to edit files on your server?!? You have much larger issues here than you let on... – EEAA Mar 10 '14 at 19:52
  • Are you actually the sysadmin of this system or are you on shared hosting at GoDaddy? If the latter, you need to talk with your sysadmin. – EEAA Mar 10 '14 at 19:54
  • I am not a sysadmin, I am a programmer, but I am the only one who should have access to the server. We are not on a shared hosting account as I stated we have a Hostgator account using a VPS. The server is a mess the original developer was really bad and so there are a lot of things that I am not even aware of why they are there... so it has been frustrating to say the least to debug. – Aaron Mar 10 '14 at 20:04
  • 3
    Sounds frustrating indeed. Well, the only advice I can give you is to spend a good amount of time reading and understanding the above-linked Question. You're going to need to take the server down and re-build it from scratch, using known-good sources. It's compromised now, and there is no possible way you can be sure of the system's integrity short of a complete re-install. If this is too much for you to take on, then bite the bullet and hire someone to help. – EEAA Mar 10 '14 at 20:06
  • okay thanks , I agree I just as the "Computer Guy" here get asked to do a lot fo things I am not so sure about. I guess my proposed solution isnt the best. I'll read and do some homework and make a choice what is best. Thanks for taking time to respond! – Aaron Mar 10 '14 at 20:08

aaron, you have been given some good guidance in the comments by EEAA and others. I would like to submit this as the answer that may best align with what you need. It is not guaranteed to help. I will explain what the un-addressed risks are afterwards.

  1. Capture a complete backup, mirror, image, what-have-you of the entire VPS server instance. 1.a. Also capture a complete backup of JUST the web-app related files, databases, etc. Make sure you have a copy, and a copy of the copy. In essence, be prepared.

  2. Request HostGator completely blow away, delete, remove, purge, scrub, whatever your VPS instance. Have them stand up a brand new pristine instance with the appropriate network settings. I would recommend against rolling back to a previous snapshot, if they offer something like that. Destroy the existing instance and get a fresh one. 2.a Recreate any system and user accounts, but USE DIFFERENT/BRAND-NEW AUTHENTICATION TOKENS, i.e. different passwords, certificates, etc.

  3. Reinstall FROM SOURCES, not from your backups, webserver, webapp packages, and any other required software.

  4. Re-implement the webapp on the brand new VPS instance. (Copy the webapp directory structure over from the backup. Will likely require a lot of config cross checking, but should be easier than rebuilding the whole thing from scratch.)

  5. If you get really, really lucky, profit.

The problem with this scenario is that it assumes the compromise to the VPS was somewhere within the system itself and not the webapp. In all likelihood, the webapp and/or webserver are what was compromised and allowed the unauthorized parties in. This is the case in a very large majority of external technical exploits to Internet connected systems. There is a big subset of the Security industry making money hand-over-fist consulting, scanning, and fixing webapp vulnerabilities across the Internet.

Now, if they used the webapp as the channel but exploited and compromised a local user account, then the new authentication tokens (you DID implement new auth-tokens like I said, right!?) will buy you SOME time. But if they did it once, they can probably do it again.

In all honesty, it is probably better to rebuild the server from scratch, and re-install the webapp from scratch, creating new configuration files for the webapp and re-populating any data from the backups. You will also want to do some THOROUGH webapp testing (see my previous bit about webapp scanning) and probably some code review. Management will likely not appreciate the costs this may incur, but then they have to decide if its okay to be pwned, or not.

As EEAA said, good luck, and I don't envy the position you've been handed. However, the good news part is you can't be blamed for CAUSING the problem... right? =)

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