Linux – How to analyse logs after the site was hacked

apache-2.2hackinglinuxloggingSecurity

One of our web-projects was hacked. Malefactor changed some template files in project and 1 core file of the web-framework (it's one of the famous php-frameworks).
We found all corrupted files by git and reverted them. So now I need to find the weak point.

With high probability we can say, that it's not the ftp or ssh password abduction. The support specialist of hosting provider (after logs analysis) said that it was the security hole in our code.

My questions:

1) What tools should I use, to review access and error logs of Apache? (Our server distro is Debian).

2) Can you write tips of suspicious lines detection in logs? Maybe tutorials or primers of some useful regexps or techniques?

3) How to separate "normal user behavior" from suspicious in logs.

4) Is there any way to preventing attacks in Apache?

Thanks for your help.

Best Answer

Like HopelessNOOb, I'd recomend getting some professional help with this.

When you know that a system has been compromised you can't rely on any data stored on it. Further, if the compromise was via HTTP, then there's probably not enough information in the standard logs to be able to isolate what hapenned. This is why people who are serious about webserver security will use something like mod_security to get much more detailed logs, and run a host based IDS to detect compromises.

The support specialist of hosting provider (after logs analysis) said that it was the security hole in our code

If he/she can make that claim then he/she must already know the answer to your question - either that or the claim is not substantiated and they really mean to say that they couldn't find anything wrong with their stuff.

Your objective should be to get your site back online and secure. To make a site secure, you need to plug every hole - but to compromise a site you only need to find one hole: you know you have at least one hole in your site, but you need to fix any which exist - which means you need to take a very different approach to your site security. Even of you can identify and fix the vulnerability which was exploited this time, the evidence shows that you don't have the processes and skills in place to have any sort of confidence that this was an isolated incident.