Der kan være flere årsager til at ville kigge Apache i loggen, fælles for de fleste af dem er at man leder efter en lille bid information i en kæmpe fil, derfor har jeg samlet et par værktøjer her som kan hjælpe dig lidt på vej. Idag kigger vi på det som hedder petit.
Hvis du leder og du ikke rigtig ved hvad du leder efter kan du lede længe, derfor giver det mening at “hashe” en logfil, når du hasher en logfil sorterer du evt. støj fra og gruppere de enkelte forespørgsler, men først lad os få hentet værktøjet:
root@lab1:~# apt-get install petit
Derefter kører vi en petit’s hashing algoritme på apache’s logfil:
root@lab1:~# petit --hash /var/log/apache2/access.log
Lige for at illustrere kørte jeg flg. sammeligning:
root@lab1:~# petit --hash /var/log/apache2/access.log | wc -l 4512 root@lab2:~# cat /var/log/apache2/access.log | wc -l 31260
Som du kan se havde vi oprindeligt 31.000 linier og det er nu kortet ned til godt 5000 linier, jeg har redigeret lidt i outputtet:
8524: /wp-admin/admin-ajax.php
5753: *
1734: /wp-includes/js/tinymce/plugins/wordpress/img/trans.gif
1: /..%2F..%2F..%2F..%2F..%2F../winnt/repair/sam
1: ////////../../../../../../etc/passwd
1: /<script>alert('Vulnerable')</script>
Hver linie indeholder et tal, der modsvarer antallet af forespørgsler samt forespørgslen og dermed er det f.eks. relativt nemt at sortere alle med med færre end f.eks. 20 forespørgsler, og undersøge dem nærmere. Ovenstående er et testsite og derfor har jeg valgt at fokusere på de 3 linier med 1 gentagelse, det er tydeligt at en person der sender javascript, “/etc/passwd” og “/winnt/repair” efter vores server ikke har ret ment i posen.
Nu ville jeg typisk bruge min ny-erhvervede viden til at grave lidt dybere, nu er “passwd”, “alert” og “winnt” generelt gode søgefraser du vil identificere indbrudsforsøg, flg. kommando:
root@lab1:~# cat /var/log/apache2/access.log | egrep "sam|passwd|alert"
Giver mig en alenlang liste:
xx.xx.xx.10 - - [23/May/2012:23:40:36 +0200] "GET /iissamples/exair/howitworks/Code.asp HTTP/1.0" 404 11660 "-" "Mozilla/4.75 (Nikto/2.1.1) (Evasions:None) (Test:003352)"
xx.xx.xx.10 - - [23/May/2012:23:40:36 +0200] "GET /iissamples/exair/howitworks/Codebrw1.asp HTTP/1.0" 404 11660 "-" "Mozilla/4.75 (Nikto/2.1.1) (Evasions:None) (Test:003353)"
xx.xx.xx.10 - - [23/May/2012:23:40:36 +0200] "GET /pls/dadname/htp.print?cbuf=<script>alert('Vulnerable')</script> HTTP/1.0" 404 11660 "-" "Mozilla/4.75 (Nikto/2.1.1) (Evasions:None) (Test:003355)"
xx.xx.xx.10 - - [23/May/2012:23:40:37 +0200] "GET /pls/help/<script>alert('Vulnerable')</script> HTTP/1.0" 404 11660 "-" "Mozilla/4.75 (Nikto/2.1.1) (Evasions:None) (Test:003356)"
xx.xx.xx.10 - - [23/May/2012:23:40:37 +0200] "GET /pls/sample/admin_/help/..%255cplsql.conf HTTP/1.0" 404 11660 "-" "Mozilla/4.75 (Nikto/2.1.1) (Evasions:None) (Test:003359)"
xx.xx.xx.10 - - [23/May/2012:23:40:38 +0200] "GET /..%252f..%252f..%252f..%252f..%252f../windows/repair/sam HTTP/1.0" 404 11660 "-" "Mozilla/4.75 (Nikto/2.1.1) (Evasions:None) (Test:003361)"
xx.xx.xx.10 - - [23/May/2012:23:40:39 +0200] "GET /..%252f..%252f..%252f..%252f..%252f../winnt/repair/sam HTTP/1.0" 404 11660 "-" "Mozilla/4.75 (Nikto/2.1.1) (Evasions:None) (Test:003362)"
xx.xx.xx.10 - - [23/May/2012:23:40:39 +0200] "GET /..%252f..%252f..%252f..%252f..%252f../winnt/repair/sam._ HTTP/1.0" 404 11660 "-" "Mozilla/4.75 (Nikto/2.1.1) (Evasions:None) (Test:003363)"
xx.xx.xx.10 - - [23/May/2012:23:40:40 +0200] "GET /..%255c..%255c..%255c..%255c..%255c../windows/repair/sam HTTP/1.0" 404 11660 "-" "Mozilla/4.75 (Nikto/2.1.1) (Evasions:None) (Test:003364)"
Det er klart nu at der er tale om den Nikto scanning jeg selv udførte igår, men det er bestemt heller ikke noget jeg bryder mig om udført på min server, og jeg kunne nu f.eks. vælge at blokere synderens ip adresse.