Is there a server/website specific malware scanner? [closed]

Question

I have multiple Linux CentOS servers that are scanned with the Google Webmaster Tools, and when it finds some malicious code on my servers(shared/dedicated), the ranking of those site drops. What I am looking for is a server scanner that scanns for php, js, etc malware finder, so that I can react before Google drops the ranking of that site.

I already found a php malware scanner, still trying to get it to work, but I would like to find a more complete solution, to increase the security of my servers.

• nbs-system/php-malware-finder: Detect potentially malicious PHP files

Answer 1

If there is malware on your server, somebody put it there so you need to look at prevention first. :) It will also, often, be put in a place not referenced from elsewhere on the server, so simply spidering your site will not find it. Google will find it if/when somebody reports the exact URL, or it is linked from another compromised site.

I recommend taking another approach: host-based intrusion detection. To detect that somebody has put something on your server that shouldn't be there, periodically run a script (using cron) that checks that nothing under your document root has changed. If there have been changes, send yourself an alert by e-mail.

If you don't want to write your own script, there is software that can do it for you, as well. The original file integrity checker is called Tripwire, and there is an open source alternative called AIDE (on CentOS, run yum install aide as root). Some configuration required, but it can do just what you need.

Answer 2

The long-term solution to this sort of stuff is doing things in a way that is more secure. Because no scanner is ever going to find every custom-written hack that gets dropped on your sites. Here's what I'm thinking:

• Only develop to and deploy from version control. It's very common to start off just pushing code to the server, even working over SSH+screen. I've done it, I'm sure loads of us do... But —besides all the other benefits of version control— we want a codebase that we know came from us (or at least our development machines) and wasn't the result of a code dropper.

• Only let your code write to places it needs to write to. Firstly this means running the code as somebody else, most commonly www-data. Then you have to make sure you only allow that user to write to places it needs to write to. For most people this is what? A database file (if SQLite) and a media directory if you allow uploads. Allowing group and other writes (eg lazy chmod -r 777) is really bad form. Find any of that and fix it.

  The problem this will cause is things like Wordpress won't be able to automatically update, download themes, etc. Given the tiny amount of time it takes to do those things manually (or with a script), I know which I'm happier with.

• Don't let code run from directories your code can write to. That's how injection works. If you have an upload script (for example), make sure your web server isn't going to let execute code for its product.

Put those together and you have a system where you are relatively sure that the only code being run on your system is the code you send via version control. And if you're ever unsure, you just have to check against the copy in your VCS.

---

This is obviously alongside other system-based security fences and deterrents. This answer just deals with code injection attacks.