Database keeps getting attacked from malicious PHP
I had finally managed to get a very successful business running, however I have been constantly attacked. The attacker was getting shell access to parts of the site and managed to create/edit my PHP files to send update queries to my database.
I had help from sitelock to secure the site and I even paid them extra to carefully go through code and make sure there are no vulnerabilities. The attacker managed to succeed again, and brought me entire business down.
Now here is what I need: The users need to be able to view the database, and I also have a cron job to update the users "balances" every 20 minutes. Sometimes I need to administrate the site, which means adding new information to the database.
Then I had a great idea (I thought), but sitelock didn't think it was smart: The main database would be set to VIEWING only. There would be no password available anywhere on the main site that would allow UPDATE or INSERT queries to be sent. Meanwhile, I would have a secret site on another server from which I do the updates from. I would run my PHP script (with my cron job) to remotely access the MAIN database with a more priviledged database user.
Sitelock claims that accessing the database remotely could cause even more risks, but I don't see how it would. Assuming that my secret site doesn't get hacked as well, I don't see why this would be so dangerous. Can someone explain why it would be?
Due to lacking of vital information, it is quite hard to provide an answer. Nevertheless, I'll give it a try.
Being unter attack is normal.
Let me note, that most websites are unter attack all the time. Since you can't disable attacks, you need to protect your system ad your WebApp. It's important
- to keep the operating system and its configuration current
- write code, that doesn't expose attackable points
- probably install protective system components.
But let me explain, what you might wish to do:
First of all, disable your site and collect evidence related data!
Disable your site, in a fundamental way:
- Cut the internet connection.
- At least disable each and any script [less good].
Don't just disable the index.php script! Intruder does know other vulnerable points of your WebApp! Use .htaccess to disable each script in each folder!
Then, backup the server's state to your local machine. Vital technical artifacts are in these classes of files:
- Your PHP scripts.
- The databases / table of your database server.
- The server's log files.
- The server's configuration files [notably /etc].
In case enough bandwidth is available, backup the whole server to your local machine!
For sure, run the backup through ssh only!
Next, figure out, how intruder managed to access your site. Intruder might have obtained access at the operating system level [e.g. telnet] or at the web application level.
Your intruder may have changed not only your web-application, but as well other parts of your server's software or system configuration.
While you focus on the front-end, the actual problem might be at another location.
Check your system for root kits.
Note, in case you set up a new system, a permanent installation of a root kit hunting tool would be useful anyway.
General rule of thumb: Security by obscurity is worthless.
If you use a secret site to perform certain task, intruder may identify the remote too - and probably break into that site - in case the remote site or it's access part to the main site, might have the previous vulnerability too.
Enhance the security level of your site.
- Disable each and any service, that isn't permanently required.
- Add and enable Apache's mod_security module to automatically reject certain potentially dangerous request.
- Enable PHP's safe_mode in case you run PHP prior of release 5.3.0. This PHP option disables certain dangerous features.
- Follow the guidelines described in OWASP's PHP security Cheat Sheet
- Access your operating system's shell using ssh. No other way is secure!
- Protect your site against man in the middle attacks using https.
Protect user sessions using https.
If your site uses http [not https], an attacker might grab the session ID of a legal user of the site. If attacker own the ID, attacker has all those right, that the legal user has.
Don't forget, that grabbing session IDs is simple, if legal user uses
- an insecure [public] WiFi network
- a non-switched Ethernet
- a compromised PC
A virus/trojaner infiltrated system might grab each and any information that legal user exchanges. Thus, most technical measures might fail.
Don't believe, that automated security checks do find each and any security problem.
While SiteLock might find certain classes of problems of web-applications, certain others are far beyond the scope of any automated security check. Automated security checks are incomplete by nature.
Your need specialists for each technical domain.
To protect your site, you need an operating system / admin specialist and a PHP specialist.