Na Debianie i Ubuntu Nginx zapisuje logi do /var/log/nginx/access.log i error.log, a Apache do /var/log/apache2/access.log i error.log. Na RHEL, Rocky i Alma, Apache używa /var/log/httpd/access_log i error_log z podkreśleniami i bez rozszerzenia. W kontenerach zbudowanych z oficjalnego obrazu Nginx nie ma w ogóle plików logów: wszystko idzie do stdout i stderr, więc docker logs to twój sposób eksportu.
Dziennik serwera WWW często jest pierwszym miejscem, w którym naruszenie bezpieczeństwa zostawia ślad: skaner szukający plików .env, ciąg wykorzystania, POST do pliku, który nie powinien istnieć. Prime Core posiada 812 reguł detekcji dla logów serwerów WWW, zmapowanych na 337 technik MITRE ATT&CK. Wśród nich: eksploatacja aplikacji nasłuchujących (T1190), web shell (T1505.003) i skanowanie podatności (T1595.002).
Zanim zaczniesz
Znajdź prawdziwe ścieżki. Wirtualne hosty często zapisują logi w niestandardowych miejscach. Zapytaj sam serwer:
# Nginx: wyświetl pełną skuteczną konfigurację i wybierz dyrektywy logów
sudo nginx -T 2>/dev/null | grep -E 'access_log|error_log'
# Apache
sudo apachectl -S
sudo grep -Ri -E 'CustomLog|ErrorLog' /etc/apache2/ /etc/httpd/ 2>/dev/null
Na Apache opartym na Debianie, wirtualne hosty bez własnej CustomLog trafiają do other_vhosts_access.log. Ludzie zawsze to przeoczają.
Sprawdź, czyjego IP logujesz. Za load balancerem, CDN lub reverse proxy, każde żądanie może wyglądać jakby pochodziło z proxy. Tak jest, chyba że serwer jest ustawiony, aby logować prawdziwego klienta: set_real_ip_from i real_ip_header w Nginx, mod_remoteip w Apache. Jeśli każda linia pokazuje te same kilka wewnętrznych adresów IP, adres atakującego jest tylko w X-Forwarded-For, jeśli to logujesz, lub w logach proxy.
Sprawdź format. Oba serwery domyślnie używają formatu 'combined’, ale wiele ustawień go dostosowuje (log_format w Nginx, LogFormat w Apache). Zwróć uwagę, jak wygląda twój zanim go prześlesz.
Uprawnienia. Na Debianie i Ubuntu te logi są czytelne przez root i grupę adm; gdzie indziej, wymagane będzie sudo.
Eksport z plików dzienników
Logi obracają się codziennie lub tygodniowo, więc dołącz obrócone pliki. zcat -f czyta zarówno zwykłe, jak i skompresowane pliki gzip:
# Nginx, aktualne i obrócone, od najstarszego
sudo zcat -f $(ls -tr /var/log/nginx/access.log*) > web-03_nginx_access.log
# Apache w RHEL
sudo zcat -f $(ls -tr /var/log/httpd/access_log*) > web-03_httpd_access.log
Dla jednego dnia, znaczniki czasu w formacie combined sprawiają, że grep wystarczy:
grep '19/Oct/2026' web-03_nginx_access.log > web-03_access_1019.log
Zbierz także dziennik błędów. Awaria upstream, błędy PHP i niektóre próby wykorzystania pojawiają się tylko tam.
Eksport z kontenerów
# Docker: stdout to dziennik dostępu, stderr to dziennik błędów
docker logs --since 2026-10-19T00:00:00 --until 2026-10-20T00:00:00 nginx > nginx_access.log 2> nginx_error.log
# Kubernetes
kubectl logs deploy/nginx --since=24h > nginx.log
Logi kontenerów znikają z kontenerem, chyba że ktoś je zbierze. Jeśli pod został zastąpiony, sprawdź dziennik klastru.
Czego szukać
| Wzór | Co to zwykle oznacza |
|---|---|
| Skoki 404 dla /.env, /.git/config, /wp-login.php, /phpmyadmin | Automatyczne skanowanie |
| ../, ${jndi:, union select, <script> w URL | Próby wykorzystania: travers, Log4Shell, SQL injection, XSS |
| 200 na POST do podejrzanego pliku w katalogu przesyłania | Możliwa web shell; sprawdź, co jeszcze ten IP zażądał |
| User agenci jak sqlmap, nikto, nuclei | Narzędzia, które nie próbowały się ukrywać |
| Skok 5xx tuż po dziwnych żądaniach | Coś się zepsuło, być może z powodu wykorzystania |
Prześlij, zanonimizuj i przejrzyj w LogTotal
- Prześlij. Otwórz logtotal.com i upuść plik.
- Anonimizuj. [what gets masked: client IPs, hostnames, usernames and tokens in URLs]. Look it over before you continue. Query strings often carry session tokens.
- Przejrzyj.
Kiedy coś pójdzie nie tak
| Objaw | Prawdopodobna przyczyna | Fix |
|---|---|---|
| Brak /var/log/nginx | Ścieżka niestandardowa lub działa w kontenerze | nginx -T lub docker logs |
| access.log istnieje, ale jest pusty | Logi idą do stdout lub access_log off | Sprawdź konfigurację i kontener |
| Każde żądanie pochodzi z tych samych IP | Proxy lub load balancer przed; prawdziwe IP nie skonfigurowane | Użyj X-Forwarded-For lub logów proxy |
| Tylko ostatnie kilka dni | Pozostawione obrócone pliki | Użyj polecenia zcat -f z globem * |
| Odmowa dostępu | Nie root, nie w adm | sudo |
FAQ
Który log jest ważniejszy, dziennik dostępu czy dziennik błędów?
Dziennik dostępu mówi ci, co zostało zażądane. Dziennik błędów mówi ci, co się popsuło. W przypadku eksploatacji, chcesz obu, obok siebie.
A co z IIS?
IIS domyślnie zapisuje logi W3C do C:inetpublogsLogFiles. To dostaje swój własny przewodnik.