Attackers with reasonable experience tend to mess with the application and system logs of the compromised machine. Goerge's point is that logs on a compromised system (which you say in the second paragraph below, is your case) are not to be taken as reliable. As an alternative, apache could store logs on a different machine over, perhaps, syslog. That way, if the apache machine is compromised, it does not necessarily mean that the log server is also compromised, and hence the logs are more reliable. But, of course, what he has suggested is for the future. On Wed, Jul 27, 2011 at 2:46 PM, ESGLinux <esggrupos@xxxxxxxxx> wrote: > hi, > > This looks like interesting. As you say for my actual problem is not a > solution, but it is interesting to use in other systems. > > My logs, I think, aren´t compromissed because they are not stored in the > same machine that is running Apache. So I thnk I can rely on them... > > greetings and thanks for your help > > ESG > > > 2011/7/27 Georgios Magklaras <georgios@xxxxxxxxxxxxx> > > > On 07/27/2011 08:24 AM, ESGLinux wrote: > > > >> Hi All, > >> > >> I have a problem with a RHEL server and I want to ask you for some > advice. > >> I´m not a security expert so I don´t know which can be the best aproach > to > >> solve my problem. > >> > >> The problem is that I have several GigaBytes of Apache logs and I need > to > >> look for attacks on it to check if the server has been compromised. > >> > >> I can manually check some possible attack urls and looking for them on > the > >> logs, but I´m sure there must be tools or technics to do these in the > >> correct way. > >> > >> So, any idea that can help me? > >> > >> Thank you very much in advance, > >> > >> ESG > >> > > The tools the others suggested are fine, however, normally, the culprit > > with this approach is that you should not rely on the application logs > > (experience often shows that logs that stay on the suspected compromised > > system) might be tampered/compromised. This is contrary to the idea of > > forensics, where you should have at a minimum something off the client > > system to ensure some level of confidence in a post mortem examination. > > > > In the future, please do take a look at LUARM: > > http://luarm.sourceforge.net/ . > > Make sure you get the latest version of it from svn by doing a: > > > > svn co https://luarm.svn.sourceforge.**net/svnroot/luarm< > https://luarm.svn.sourceforge.net/svnroot/luarm>luarm > > > > and then follow the README for setup instructions. A case where I used > > LUARM to detect a botnet compromised LAMP > > is here: > > > > http://epistolatory.blogspot.**com/2011/02/catching-** > > undesired-guest-in-penguin-**tmp.html< > http://epistolatory.blogspot.com/2011/02/catching-undesired-guest-in-penguin-tmp.html > > > > > > Please do feel free to pass feedback. > > > > GM > > > > -- > > -- > > George Magklaras PhD > > RHCE no: 805008309135525 > > > > Senior Systems Engineer/IT Manager > > Biotek Center, University of Oslo > > EMBnet TMPC Chair > > > > http://folk.uio.no/georgios > > > > Tel: +47 22840535 > > > > -- > > redhat-list mailing list > > unsubscribe mailto:redhat-list-request@**redhat.com< > redhat-list-request@xxxxxxxxxx> > > ?subject=unsubscribe > > https://www.redhat.com/**mailman/listinfo/redhat-list< > https://www.redhat.com/mailman/listinfo/redhat-list> > > > -- > redhat-list mailing list > unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe > https://www.redhat.com/mailman/listinfo/redhat-list > -- Muhammad Saqib Ilyas PhD Student, Computer Science and Engineering Lahore University of Management Sciences -- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
