D

laczego nie zawsze można ufać logom serwera WWW przedstawił Andrzej Broński na łamach serwisu sekurak. Podsumowując: jeśli używamy konfiguracji Apache (prefork MPM) + mod_php (która jest przestarzała i nie zalecana przez Apache), pozwalając w dodatku na wywołania niebezpiecznej funkcji exec może dojść do sytuacji, w której wywołanie skryptu PHP nie zostanie nigdzie zalogowane.

Jeśli wywołamy przykładowy skrypt:

<?php
$cmd_result = shell_exec('uname -a');
exec('kill -9 ' . getmypid());
?>

To w logach serwera będziemy mogli zobaczyć tylko wpis:

::1 - - [30/Jul/2018:20:28:25 +0000] "OPTIONS * HTTP/1.0" 200 126 "-" \
"Apache/2.4.29 (Ubuntu) (internal dummy connection)"

Internal dumy connection odnosi się do procesu, w którym serwer Apache zarządza swoimi wątkami. Jeśli koniecznie jest “obudzenie” kolejnego procesu do nasłuchiwania połączeń – wysyła on proste żądanie HTTP “na siebie”. Żądanie to pojawi się w access_logu, a jego adres źródłowy będzie ustawiony na interfejs zwrotny (ang. loop-back interface) – zazwyczaj 127.0.0.1 lub ::1 (jeśli protokół IPv6 jest skonfigurowany). Jako User-Agent zobaczymy sygnaturę serwera, a zaraz za nią napis: "(internal dummy connection)" (jak w przykładzie powyżej). Dzieje się tak ponieważ testowany skrypt PHP zabija nam procesy potomne, a zgodnie z polityką konfiguracji:

<IfModule mpm_prefork_module>
        StartServers           5
        MinSpareServers        5
        MaxSpareServers        10
        MaxRequestWorkers      150
        MaxConnectionsPerChild 0
</IfModule>

Ich liczba musi utrzymywać się na starcie w minimalnej ilości: 5. W jaki sposób więc wykryć taką anomalię? Otóż serwer Apache wyposażony jest także w moduł log_forensic. Służy on do logowania żądań klienta. Logowanie odbywa się przed i po przeprocesowaniu żądania przez serwer, więc logi tego typu posiadają dwa zapisy dla każdego żądania klienta. Po załadowaniu modułu konfiguracja jest bardzo prosta. Wskazujemy tylko gdzie dane logi mają być zapisane:

ForensicLog /var/log/apache2/full_traffic.log

Ponownie wywołajmy nasz “niewidzialny” skrypt: test.php, a następnie sprawdźmy nasze logi za pomocą narzędzia dostarczonego również z dystrybucją serwera Apache o nazwie check_forensic. Porównuje on w logu wszystkie żądania wejściowe i wyjściowe – pozwalając szybko zidentyfikować skrypty, które nigdy się nie zakończyły z powodu błędów klienta lub serwera:

root@stardust:~# check_forensic /var/log/apache2/full_traffic.log

+9778:5b5f74e4:2|GET /test.php HTTP/1.1|Host:192.168.56.101|User-Agent:Mozilla/5.0 
(Macintosh; Intel Mac OS X 10.13; rv%3a61.0) Gecko/20100101 Firefox/61.0|
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8|
Accept-Language:pl,en-GB;q=0.7,en;q=0.3|Accept-Encoding:gzip, deflate|
DNT:1|Connection:keep-alive|Upgrade-Insecure-Requests:1

Jak widać skrypt zabijający nam wątki został od razu namierzony. Podobnym modułem jest także mod_whatkilledus ( co nas zabiło?) – śledzi on aktualnie obsługiwane żądanie oraz loguje je, gdy tylko proces potomny ulega awarii.

Więcej informacji: Apache Module Index