cPanel & WHM Pliki Logów: Kompletny Techniczny Przewodnik dla Administratorów Serwerów

cPanel & WHM utrzymuje kompleksową, wielowarstwową architekturę logowania, która rejestruje każde istotne zdarzenie w usługach webowych, dostarczaniu poczty, uwierzytelnianiu, bazach danych i operacjach systemowych. Każdy plik dziennika ma odrębną lokalizację, format i cel diagnostyczny — wiedza o tym, który dziennik sprawdzić i jak go efektywnie analizować, to różnica między pięciominutową naprawą a wielogodzinnym dochodzeniem w sprawie awarii.

Ten przewodnik obejmuje każdy krytyczny plik dziennika w środowisku produkcyjnym cPanel & WHM, w tym ścieżki plików, formaty dzienników, rzeczywiste przypadki diagnostyczne oraz techniki wiersza poleceń, z których faktycznie korzystają doświadczeni administratorzy systemów.

Dlaczego pliki dzienników cPanel & WHM wymagają Twojej uwagi

Pliki dzienników to nie tylko ścieżka audytu — są one podstawowym narzędziem diagnostycznym dla każdego stosu hostingowego opartego na Linux. W środowisku cPanel powierzchnia logowania obejmuje Apache/LiteSpeed, Exim, MySQL/MariaDB, PHP-FPM, ProFTPd, Pure-FTPd, cPHulk oraz samą warstwę aplikacji cPanel/WHM.

Administratorzy, którzy traktują dzienniki reaktywnie — sprawdzając je dopiero po awarii — konsekwentnie przegapiają wczesne sygnały ostrzegawcze: stopniowe wyczerpywanie pamięci, narastające kampanie brute-force, akumulację wolnych zapytań i błędy dostarczania związane z certyfikatami. Proaktywna analiza dzienników wychwytuje te wzorce, zanim staną się incydentami.

Trzy podstawowe cele operacyjne napędzają analizę dzienników w środowiskach cPanel:

• Diagnoza przyczyn źródłowych: Korelowanie znaczników czasu w dziennikach Apache, PHP i MySQL w celu wskazania dokładnego punktu awarii w łańcuchu żądań.
• Ustalanie punktów odniesienia wydajności: Identyfikowanie wolnych zapytań, odpowiedzi HTTP o wysokim opóźnieniu i procesów pochłaniających zasoby, zanim nasycą pojemność serwera.
• Kryminalistyka bezpieczeństwa: Rekonstruowanie osi czasu ataków z dzienników uwierzytelniania SSH, rekordów cPHulk i dzienników odrzuceń Exim w celu określenia zakresu i kroków naprawczych.

Pliki dzienników Apache

Apache jest domyślnym serwerem webowym w środowiskach cPanel, choć LiteSpeed jest coraz częściej stosowany jako zamiennik. Oba zapisują dzienniki w kompatybilnych formatach do tych samych konwencjonalnych ścieżek.

Dziennik błędów Apache

Lokalizacja: /usr/local/apache/logs/error_log

Jest to najczęściej sprawdzany dziennik w każdej sesji rozwiązywania problemów z cPanel. Rejestruje każdy błąd generowany przez Apache: fatalne błędy PHP (gdy PHP działa jako moduł), błędy składni .htaccess, niezgodności reguł mod_rewrite, odmowy uprawnień, błędy uzgadniania SSL i błędy upstream proxy.

Krytyczny szczegół, który wiele przewodników pomija: dzienniki błędów per-domena również istnieją i często są bardziej bezpośrednio użyteczne niż globalny dziennik błędów. Znajdują się pod adresem:

/home/username/logs/domain.com-ssl_error_log
/home/username/logs/domain.com-error_log

Te dzienniki per-VirtualHost izolują błędy do jednego konta, znacznie redukując szum podczas diagnozowania jednej konkretnej witryny na serwerze współdzielonym.

Typowy wzorzec diagnostyczny — pętla przepisywania .htaccess:

grep "RewriteRule" /usr/local/apache/logs/error_log | tail -50

Typowy wzorzec diagnostyczny — fatalne błędy PHP według domeny:

grep "PHP Fatal" /home/username/logs/domain.com-error_log | tail -30

Dziennik dostępu Apache

Lokalizacja: /usr/local/apache/logs/access_log

Globalny dziennik dostępu rejestruje każde żądanie HTTP/HTTPS w domyślnym formacie Combined Log Format:

IP - username [timestamp] "METHOD /path HTTP/version" status_code bytes_sent "referer" "user_agent"

Dzienniki dostępu per-domena są przechowywane pod adresem /home/username/logs/domain.com-access_log i są właściwym źródłem do analizy ruchu na poszczególnych kontach.

Praktyczne przypadki użycia:

• Identyfikowanie kampanii DDoS lub scrapingu według częstotliwości IP:

awk '{print $1}' /usr/local/apache/logs/access_log | sort | uniq -c | sort -rn | head -20

• Znajdowanie wszystkich błędów serii 500 w ciągu ostatniej godziny (wymaga aktualnych znaczników czasu w dzienniku):

grep " 5[0-9][0-9] " /usr/local/apache/logs/access_log | tail -200

• Wykrywanie skanerów podatności według ciągu user-agent:

grep -i "sqlmap|nikto|masscan|nmap" /usr/local/apache/logs/access_log

Przypadek brzegowy: Na serwerach z włączonym piped logging w WHM dziennik dostępu może być pusty lub minimalny, ponieważ dzienniki są przesyłane bezpośrednio do demona przetwarzającego dzienniki. Sprawdź WHM > Apache Configuration > Global Configuration pod kątem dyrektywy CustomLog, jeśli znajdziesz nieoczekiwanie pusty dziennik dostępu.

Dziennik SSL/TLS Apache

Lokalizacja: /usr/local/apache/logs/ssl_error_log

Ten dziennik rejestruje błędy negocjacji TLS, błędy walidacji certyfikatów i niezgodności zestawów szyfrów. Jest niezbędny podczas debugowania problemów z łącznością HTTPS, które nie pojawiają się w głównym dzienniku błędów. Sprawdź go w pierwszej kolejności, gdy użytkownicy zgłaszają ostrzeżenia SSL przeglądarki lub gdy automatyczne odnawianie certyfikatów przez AutoSSL kończy się niepowodzeniem bez komunikatu.

Dzienniki aplikacji cPanel i WHM

Dziennik dostępu cPanel

Lokalizacja: /usr/local/cpanel/logs/access_log

Rejestruje każde żądanie HTTP wysłane do interfejsu cPanel (port 2082/2083). Każdy wpis zawiera uwierzytelnioną nazwę użytkownika, wykonaną akcję i źródłowy adres IP. Ten dziennik jest podstawowym źródłem do audytowania tego, co konkretny użytkownik zrobił w swoim koncie cPanel.

Znajdź wszystkie akcje wykonane przez konkretnego użytkownika:

grep "username" /usr/local/cpanel/logs/access_log | grep -v "GET /favicon"

Dziennik błędów cPanel

Lokalizacja: /usr/local/cpanel/logs/error_log

Rejestruje wewnętrzne błędy warstwy aplikacji cPanel — nieudane wywołania API, uszkodzone wtyczki cPanel, błędy skryptów Perl w backendzie cPanel i błędy renderowania szablonów. Jeśli interfejs cPanel zwraca błędy 500 lub określone funkcje nie działają, jest to pierwszy dziennik do sprawdzenia.

Dziennik logowania WHM

Lokalizacja: /usr/local/cpanel/logs/login_log

Rejestruje wszystkie zdarzenia uwierzytelniania WHM — udane logowania, nieudane próby, wyzwania uwierzytelniania dwuskładnikowego i użycie tokenów API. Ten dziennik jest krytyczny do wykrywania nieautoryzowanego dostępu administracyjnego.

Znajdź wszystkie nieudane próby logowania do WHM:

grep "FAILED" /usr/local/cpanel/logs/login_log | awk '{print $NF}' | sort | uniq -c | sort -rn

Dziennik ochrony przed atakami brute-force cPHulk

Lokalizacja: /usr/local/cpanel/logs/cphulkd.log

Jest to dziennik, który większość przewodników całkowicie pomija, a mimo to jest jednym z najważniejszych operacyjnie. cPHulk to wbudowany demon ochrony przed atakami brute-force w cPanel. Monitoruje próby logowania przez SSH, FTP, cPanel i WHM oraz automatycznie blokuje adresy IP, które przekraczają limity progowe.

Gdy uprawniony administrator zostaje zablokowany w WHM lub SSH, odpowiedź prawie zawsze znajduje się w tym dzienniku. Możesz również bezpośrednio zapytać bazę danych cPHulk:

mysql -u root cphulkd -e "SELECT ip, user, type, timestamp FROM brutes ORDER BY timestamp DESC LIMIT 20;"

Aby odblokować konkretny adres IP z wiersza poleceń:

/usr/local/cpanel/bin/cphulk_pam_ctl --unblock=192.168.1.1

Dziennik aktualizacji i instalacji cPanel

Lokalizacja: /var/cpanel/updatelogs/

Każde uruchomienie aktualizacji cPanel generuje plik dziennika z sygnaturą czasową w tym katalogu. Gdy aktualizacja cPanel uszkodzi usługę lub funkcja zniknie po aktualizacji, ten katalog zawiera pełne dane wyjściowe procesu aktualizacji, w tym wszelkie błędy, które wystąpiły podczas instalacji pakietu lub migracji konfiguracji.

ls -lt /var/cpanel/updatelogs/ | head -5

Pliki dzienników poczty e-mail

Poczta e-mail jest konsekwentnie najbardziej złożonym podsystemem do rozwiązywania problemów w cPanel. Exim, domyślny MTA cPanel, generuje trzy oddzielne strumienie dzienników, z których każdy służy odrębnemu celowi diagnostycznemu.

Główny dziennik Exim

Lokalizacja: /var/log/exim_mainlog

Jest to podstawowy dziennik transakcji e-mail. Każda wiadomość przetwarzana przez Exim — przychodząca lub wychodząca — generuje tutaj wpisy obejmujące akceptację, decyzje dotyczące routingu, próby dostarczenia i ostateczną dyspozycję (dostarczona, odroczona lub odrzucona).

Anatomia wpisu dziennika:

2024-01-15 14:23:01 1rPqXY-0003aB-Kc <= sender@example.com H=mail.example.com [203.0.113.10] P=esmtps S=4821 id=<abc123@example.com>
2024-01-15 14:23:02 1rPqXY-0003aB-Kc => recipient@domain.com R=virtual_user_delivery T=virtual_userdelivery_pipe
2024-01-15 14:23:02 1rPqXY-0003aB-Kc Completed

Identyfikator wiadomości (1rPqXY-0003aB-Kc) jest kluczem do śledzenia pojedynczej wiadomości przez cały dziennik:

grep "1rPqXY-0003aB-Kc" /var/log/exim_mainlog

Śledź całą pocztę wychodzącą z konkretnego konta (krytyczne dla dochodzenia w sprawie spamu):

grep "U=username" /var/log/exim_mainlog | grep "<=" | awk '{print $7}' | sort | uniq -c | sort -rn | head -20

Rzeczywisty przypadek brzegowy: Gdy skompromitowana instalacja WordPress wysyła spam, główny dziennik Exim będzie pokazywał użytkownika wysyłającego jako nobody (użytkownik procesu Apache) zamiast nazwy użytkownika konta cPanel. Filtruj to konkretnie:

grep "U=nobody" /var/log/exim_mainlog | grep "<=" | tail -50

Dziennik odrzuceń Exim

Lokalizacja: /var/log/exim_rejectlog

Rejestruje wszystkie wiadomości, których Exim odmówił przyjęcia na etapie połączenia SMTP — zanim zostały nawet umieszczone w kolejce. Odrzucenia następują z powodu trafień na czarną listę RBL, błędów SPF/DKIM/DMARC, nieprawidłowych ciągów HELO, odmowy przekazywania lub ograniczania szybkości.

Ten dziennik jest niezbędny w dwóch scenariuszach: diagnozowanie, dlaczego legalna poczta przychodząca jest odrzucana, oraz audytowanie skuteczności reguł filtrowania spamu.

Znajdź najczęstsze przyczyny odrzuceń:

grep "rejected" /var/log/exim_rejectlog | grep -oP "(?<=: ).*" | sort | uniq -c | sort -rn | head -10

Dziennik paniki Exim

Lokalizacja: /var/log/exim_paniclog

Dziennik paniki rejestruje fatalne błędy Exim — błędy parsowania pliku konfiguracyjnego, niemożność powiązania z portem 25, błędy połączenia z bazą danych i błędy biblioteki TLS. Jeśli ten plik nie jest pusty, Exim doświadczył krytycznej awarii. W wielu przypadkach niepusty dziennik paniki oznacza, że kolejka poczty całkowicie przestała być przetwarzana.

# Check if the panic log has content — a non-zero exit means there are critical errors
[ -s /var/log/exim_paniclog ] && echo "CRITICAL: Exim panic log has entries" && tail -20 /var/log/exim_paniclog

Dziennik Dovecot

Lokalizacja: /var/log/dovecot.log (i /var/log/dovecot-info.log dla zdarzeń informacyjnych)

Dovecot obsługuje połączenia IMAP i POP3 w środowiskach cPanel. Błędy uwierzytelniania, limity połączeń, problemy z blokowaniem skrzynek pocztowych i zdarzenia egzekwowania limitów przydziału pojawiają się tutaj. Gdy użytkownicy nie mogą połączyć się z klientem poczty e-mail, dziennik Dovecot jest właściwym miejscem do sprawdzenia — nie Exim.

grep "auth failed" /var/log/dovecot.log | awk '{print $NF}' | sort | uniq -c | sort -rn | head -10

Pliki dzienników baz danych

Dziennik błędów MySQL/MariaDB

Lokalizacja: /var/lib/mysql/$(hostname).err

Ten dziennik rejestruje zdarzenia uruchamiania i zamykania MySQL/MariaDB, operacje odzyskiwania InnoDB, błędy replikacji, ostrzeżenia o uszkodzeniu tabel i wszelkie zapytania powodujące błąd na poziomie serwera. Jest to definitywne źródło do diagnozowania awarii baz danych i nieoczekiwanych restartów.

Dynamiczne pobieranie rzeczywistej ścieżki:

mysql -u root -e "SHOW VARIABLES LIKE 'log_error';"

Sprawdź zdarzenia uszkodzenia InnoDB lub odzyskiwania po awarii:

grep -i "crash|corrupt|recovery|innodb" /var/lib/mysql/$(hostname).err | tail -30

Dziennik wolnych zapytań MySQL

Lokalizacja: /var/lib/mysql/slowquery.log (gdy włączony)

Dziennik wolnych zapytań jest domyślnie wyłączony w większości instalacji cPanel. Jego włączenie jest jedną z najbardziej wartościowych czynności dostrajania wydajności, jakie możesz wykonać na serwerze z intensywnym użyciem baz danych.

Włącz dziennik wolnych zapytań w czasie wykonywania (bez konieczności restartu):

mysql -u root -e "SET GLOBAL slow_query_log = 'ON'; SET GLOBAL long_query_time = 1; SET GLOBAL slow_query_log_file = '/var/lib/mysql/slowquery.log';"

Po włączeniu użyj mysqldumpslow do agregowania i rankingowania najgorszych przypadków:

mysqldumpslow -s t -t 10 /var/lib/mysql/slowquery.log

Wyświetla to 10 najgorszych zapytań według łącznego czasu wykonania — najbardziej użyteczny punkt wyjścia do optymalizacji zapytań.

Krytyczna kwestia: long_query_time wynoszący 1 sekundę to rozsądny próg początkowy dla większości aplikacji, ale witryny o dużym ruchu powinny rozważyć 0,5 sekundy lub nawet 0,25 sekundy, aby wychwycić zapytania, które są indywidualnie szybkie, ale zbiorczo kosztowne pod obciążeniem.

Ogólny dziennik zapytań MySQL

Lokalizacja: Konfigurowalna, zazwyczaj /var/lib/mysql/general.log

Ogólny dziennik zapytań rejestruje każdą instrukcję SQL wysłaną do serwera. Nie włączaj tego w środowisku produkcyjnym bez konkretnego, ograniczonego czasowo powodu diagnostycznego. Na zajętym serwerze ten dziennik może rosnąć w tempie gigabajtów na godzinę i sam w sobie spowoduje degradację wydajności. Włącz go na krótko, odtwórz problem, a następnie natychmiast go wyłącz.

mysql -u root -e "SET GLOBAL general_log = 'ON'; SET GLOBAL general_log_file = '/var/lib/mysql/general.log';"
# ... reproduce the issue ...
mysql -u root -e "SET GLOBAL general_log = 'OFF';"

Systemowe pliki dzienników

Dziennik komunikatów systemowych

Lokalizacja: /var/log/messages

Dziennik komunikatów jądra i demona systemowego. Błędy sprzętowe (błędy I/O dysku, błędy ECC pamięci), zdarzenia zabójcy OOM (Out of Memory), zmiany stanu interfejsu sieciowego i zdarzenia ładowania modułów jądra pojawiają się tutaj. Jest to pierwszy dziennik do sprawdzenia, gdy serwer przestaje odpowiadać lub nieoczekiwanie się restartuje.

Sprawdź zdarzenia zabójcy OOM (serwer po cichu zabija procesy z powodu wyczerpania pamięci):

grep -i "oom|killed process|out of memory" /var/log/messages | tail -20

Sprawdź błędy I/O dysku, które mogą wskazywać na awarię napędu:

grep -i "I/O error|blk_update_request|ata.*error" /var/log/messages | tail -20

Dziennik bezpiecznego uwierzytelniania

Lokalizacja: /var/log/secure

Rejestruje wszystkie zdarzenia uwierzytelniania oparte na PAM: logowania SSH (udane i nieudane), wykonywanie poleceń sudo, próby su i uwierzytelnianie inicjowane przez cron. Jest to podstawowy dziennik do kryminalistyki bezpieczeństwa SSH.

Zidentyfikuj najczęściej atakujące adresy IP według liczby nieudanych logowań SSH:

grep "Failed password" /var/log/secure | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head -20

Audytuj wszystkie polecenia sudo wykonane na serwerze:

grep "sudo:" /var/log/secure | grep "COMMAND" | tail -50

Rzeczywisty przypadek brzegowy: Na serwerach z UseDNS yes w sshd_config, wpisy nieudanych logowań mogą pokazywać nazwy hostów zamiast adresów IP, co psuje wzorzec awk ekstrakcji IP powyżej. Sprawdź ustawienie sshd_config i odpowiednio dostosuj indeks pola.

Bufor pierścieniowy jądra

Lokalizacja: Tylko w czasie wykonywania — dostępny przez dmesg

Bufor pierścieniowy jądra nie jest trwałym plikiem, ale jest niezbędny do diagnozowania zdarzeń na poziomie sprzętowym, które występują podczas lub wkrótce po uruchomieniu, zanim syslog się zainicjuje. W systemach opartych na systemd (CentOS 7+, CloudLinux 7+) trwałe dzienniki jądra są dostępne przez:

journalctl -k --since "1 hour ago"

Pliki dzienników FTP

Dziennik ProFTPd

Lokalizacja: /var/log/proftpd/proftpd.log

ProFTPd jest domyślnym demonem FTP w środowiskach cPanel. Ten dziennik rejestruje wszystkie zdarzenia sesji FTP: próby uwierzytelniania, przeglądanie katalogów, przesyłanie plików, pobieranie i rozłączenia.

Znajdź wszystkie nieudane próby logowania FTP:

grep "USER|PASS" /var/log/proftpd/proftpd.log | grep -i "failed|incorrect" | tail -30

Zidentyfikuj duże przesyłanie plików (potencjalne przygotowanie złośliwego oprogramowania):

grep "STOR" /var/log/proftpd/proftpd.log | awk '{print $NF, $0}' | sort -rn | head -20

Dziennik Pure-FTPd

Lokalizacja: /var/log/pureftpd.log

Dzienniki Pure-FTPd są domyślnie zapisywane do syslog w niektórych konfiguracjach, co oznacza, że wpisy mogą pojawiać się w /var/log/messages zamiast w dedykowanym pliku. Zweryfikuj aktywne miejsce docelowe logowania:

grep "VerboseLog|AltLog" /etc/pure-ftpd.conf

Dzienniki PHP i na poziomie aplikacji

Dziennik błędów PHP

Błędy PHP w środowiskach cPanel mogą być rejestrowane w wielu lokalizacjach w zależności od używanego handlera PHP:

Ścieżka dziennika puli PHP-FPM zawiera numer wersji PHP. Dla PHP 8.2 zarządzanego przez EasyApache 4:

tail -f /opt/cpanel/ea-php82/root/usr/var/log/php-fpm/error.log

Logowanie błędów PHP per-konto można włączyć, dodając następujące elementy do php.ini lub .htaccess konta:

log_errors = On
error_log = /home/username/logs/php_errors.log

Dzienniki usług i bezpieczeństwa specyficzne dla cPanel

Dziennik menedżera usług cPanel

Lokalizacja: /usr/local/cpanel/logs/safeapacherestart_log

Rejestruje każde zdarzenie restartu Apache wyzwolone przez menedżera usług cPanel, w tym powód restartu i czy się powiódł. Przydatny do korelowania przestojów Apache ze zmianami konfiguracji.

Dziennik kopii zapasowych cPanel

Lokalizacja: /usr/local/cpanel/logs/cpbackup/

Każde uruchomienie kopii zapasowej generuje plik dziennika per-konto w tym katalogu. Gdy kopia zapasowa kończy się niepowodzeniem bez komunikatu, ten katalog zawiera konkretny błąd — czy był to problem z miejscem na dysku, błąd zrzutu bazy danych, czy problem z uprawnieniami.

ls -lt /usr/local/cpanel/logs/cpbackup/ | head -10
grep -i "error|fail" /usr/local/cpanel/logs/cpbackup/username.log

Dziennik AutoSSL cPanel

Lokalizacja: /var/cpanel/logs/autossl/

AutoSSL to zautomatyzowany system udostępniania certyfikatów Let’s Encrypt / Sectigo w cPanel. Gdy odnowienie certyfikatu SSL kończy się niepowodzeniem, szczegółowy powód — błąd DCV, ograniczenie szybkości, niezgodność walidacji domeny — jest tutaj rejestrowany. Ten dziennik jest krytyczny do diagnozowania problemów z wygaśnięciem certyfikatów HTTPS przed wystąpieniem ostrzeżeń przeglądarki.

ls -lt /var/cpanel/logs/autossl/ | head -5
tail -100 /var/cpanel/logs/autossl/$(ls -t /var/cpanel/logs/autossl/ | head -1)

Jeśli zarządzasz certyfikatami SSL w wielu domenach lub potrzebujesz certyfikatów wykraczających poza to, co zapewnia AutoSSL, Certyfikaty SSL od dedykowanego dostawcy oferują rozszerzoną walidację i opcje wildcard, których Let’s Encrypt nie zapewnia.

Tabela porównawcza plików dzienników

Techniki analizy dzienników w wierszu poleceń

Podstawowe polecenia do analizy w czasie rzeczywistym i historycznej

Śledzenie dziennika w czasie rzeczywistym (najczęstszy przepływ pracy administratora systemu):

tail -f /var/log/exim_mainlog

Jednoczesne śledzenie wielu dzienników przy użyciu multitail (instalacja przez yum install multitail):

multitail /usr/local/apache/logs/error_log /var/log/exim_mainlog

Wyodrębnianie i zliczanie unikalnych wartości z określonego pola:

awk '{print $1}' /usr/local/apache/logs/access_log | sort | uniq -c | sort -rn | head -20

Przeszukiwanie skompresowanych, rotowanych archiwów dzienników:

zgrep "keyword" /var/log/exim_mainlog.*.gz

Filtrowanie wpisów dziennika w określonym oknie czasowym:

awk '/15/Jan/2024:14:00/,/15/Jan/2024:15:00/' /usr/local/apache/logs/access_log

Zliczanie rozkładu kodów statusu HTTP:

awk '{print $9}' /usr/local/apache/logs/access_log | sort | uniq -c | sort -rn

Rotacja dzienników w cPanel

cPanel używa logrotate do zarządzania rozmiarami plików dzienników. Konfiguracja rotacji dla dzienników zarządzanych przez cPanel znajduje się w /etc/logrotate.d/. Dzienniki Apache są rotowane przez własny mechanizm splitlogs cPanel, który również dzieli globalny dziennik dostępu na pliki per-domena.

Sprawdź bieżącą konfigurację logrotate dla określonej usługi:

cat /etc/logrotate.d/syslog

Ręczne wyzwolenie rotacji dzienników do testowania:

logrotate -f /etc/logrotate.d/syslog

Krytyczna pułapka: Jeśli rotacja dzienników jest błędnie skonfigurowana lub miejsce na dysku jest wyczerpane, pliki dzienników mogą urosnąć do wypełnienia całej partycji, powodując jednoczesną awarię wszystkich usług. Monitoruj użycie dysku na partycji zawierającej /var/log i /usr/local/apache/logs jako standardową praktykę operacyjną.

Scentralizowane zarządzanie dziennikami i alerty

W środowiskach produkcyjnych — szczególnie na Hostingu VPS lub Serwerze Dedykowanym — poleganie na ręcznej inspekcji dzienników jest niewystarczające w skali. Zaimplementuj jedno z następujących podejść:

Agregacja dzienników z przekazywaniem rsyslog: Skonfiguruj /etc/rsyslog.conf do przekazywania dzienników do scentralizowanego serwera syslog lub platformy SIEM. Zachowuje to dzienniki nawet jeśli sam serwer zostanie skompromitowany.

Stos ELK (Elasticsearch, Logstash, Kibana): Pobieraj dzienniki cPanel za pomocą agentów Filebeat, parsuj je za pomocą potoków Logstash i wizualizuj wzorce w Kibana. To podejście umożliwia pełnotekstowe wyszukiwanie w miesiącach historii dzienników w ciągu sekund.

Integracja Fail2ban: Fail2ban odczytuje /var/log/secure i /var/log/exim_mainlog i automatycznie tworzy reguły iptables do blokowania atakujących adresów IP. Działa niezależnie od cPHulk i zapewnia dodatkową warstwę obrony.

GoAccess do analizy dzienników Apache: GoAccess to działający w czasie rzeczywistym analizator dzienników oparty na terminalu, który generuje raporty HTML z dzienników dostępu Apache bez konieczności pełnego wdrożenia ELK:

goaccess /usr/local/apache/logs/access_log --log-format=COMBINED -o /var/www/html/report.html

Administratorzy zarządzający wieloma kontami cPanel lub konfiguracjami resellera na VPS z cPanel znacznie korzystają na scentralizowanej widoczności dzienników, ponieważ dzienniki poszczególnych kont są w przeciwnym razie odizolowane w każdym katalogu domowym.

Korelacja dzienników infrastruktury poczty e-mail

Jedną z najbardziej niedocenianych technik diagnostycznych w środowiskach cPanel jest wzajemne odwoływanie się do dzienników Exim z dziennikami Dovecot i systemowym dziennikiem uwierzytelniania w celu prześledzenia pełnego cyklu życia incydentu bezpieczeństwa poczty e-mail.

Scenariusz: Użytkownik zgłasza, że jego konto wysyła spam, którego nie napisał.

Krok 1 — Zidentyfikuj identyfikatory wiadomości Exim powiązane z kontem:

grep "U=username|from=<.*@userdomain.com>" /var/log/exim_mainlog | grep "<=" | head -20

Krok 2 — Sprawdź, czy wysyłanie pochodzi z aplikacji webowej (PHP mail()) czy uwierzytelnionego SMTP:

grep "1rPqXY-0003aB-Kc" /var/log/exim_mainlog | grep -E "P=esmtpa|P=local"

P=esmtpa wskazuje na uwierzytelnione przesyłanie SMTP. P=local lub P=pipe wskazuje na lokalny skrypt (prawdopodobnie skompromitowana aplikacja webowa).

Krok 3 — Jeśli P=esmtpa, znajdź źródłowy adres IP z dziennika uwierzytelniania Dovecot lub Exim:

grep "username" /var/log/dovecot.log | grep "Login" | tail -20

Krok 4 — Skrzyżuj ten adres IP z /var/log/secure pod kątem aktywności SSH i z dziennikiem dostępu cPanel pod kątem logowań do panelu sterowania.

Ta czterokrokowa technika korelacji definitywnie odpowiada na pytanie, czy kompromitacja była kradzieżą danych uwierzytelniających, podatną aplikacją webową czy kontem SMTP złamanym metodą brute-force — a to rozróżnienie całkowicie determinuje ścieżkę naprawczą.

Dla organizacji prowadzących własną infrastrukturę poczty, odpowiednio skonfigurowane środowisko Hostingu Poczty E-mail z dedykowanym monitorowaniem dzienników zapewnia izolację potrzebną do zapobiegania uszkodzeniu reputacji poczty między kontami.

Kwestie dotyczące dzienników związanych z domenami i DNS

Błędy rozwiązywania DNS często manifestują się jako błędy w dziennikach aplikacji, a nie w dedykowanym dzienniku DNS. Named (BIND), którego cPanel używa do DNS, domyślnie rejestruje do /var/log/messages.

Sprawdź błędy BIND:

grep "named" /var/log/messages | grep -i "error|failed|refused" | tail -20

Gdy problemy z propagacją DNS dotykają nowo zarejestrowanych lub przeniesionych domen, korelowanie dziennika BIND z konfiguracją domeny cPanel pomaga ustalić, czy problem jest błędem pliku strefy czy opóźnieniem propagacji na poziomie rejestratora. Jeśli zarządzasz rejestracją domen i DNS przez tę samą platformę, Rejestracja Domen ze zintegrowanym zarządzaniem DNS upraszcza ten łańcuch diagnostyczny.

Praktyczna macierz decyzyjna: który dziennik sprawdzić jako pierwszy

Kluczowe wnioski techniczne

• Zawsze najpierw sprawdzaj dzienniki per-domena (/home/username/logs/) przed globalnymi dziennikami Apache — zawierają te same dane ze znacznie mniejszym szumem.
• Niepusty /var/log/exim_paniclog to incydent P1 — Exim mógł całkowicie przestać przetwarzać kolejkę poczty.
• Dziennik cPHulk pod /usr/local/cpanel/logs/cphulkd.log jest właściwym pierwszym przystankiem dla każdego scenariusza blokady, nie /var/log/secure.
• Włącz dziennik wolnych zapytań MySQL (long_query_time = 1) na każdym produkcyjnym serwerze baz danych — informacje o wydajności, które dostarcza, są warte minimalnego narzutu.
• Skrzyżuj pole P= Exim z dziennikami uwierzytelniania Dovecot, aby definitywnie ustalić, czy incydent spamowy pochodzi z kradzieży danych uwierzytelniających czy skompromitowanej aplikacji webowej.
• Błędna konfiguracja rotacji dzienników to cichy tryb awarii — pełna partycja /var/log spowoduje jednoczesną awarię wszystkich usług bez ostrzeżenia.
• zgrep działa na rotowanych archiwach .gz — historyczna analiza dzienników nie wymaga ręcznego dekompresowania plików.
• Scentralizowane przekazywanie dzienników przez rsyslog to minimalna wykonalna postawa bezpieczeństwa dla każdego serwera obsługującego wrażliwe dane — lokalne dzienniki mogą zostać usunięte przez atakującego, który uzyska dostęp root.

Często zadawane pytania

Gdzie znajdują się dzienniki błędów cPanel?

Główny dziennik błędów aplikacji cPanel znajduje się pod adresem /usr/local/cpanel/logs/error_log. Błędy serwera webowego Apache są pod adresem /usr/local/apache/logs/error_log, a błędy PHP per-konto są w /home/username/logs/domain.com-error_log. Każda usługa utrzymuje własny plik dziennika pod odrębną ścieżką.

Jak śledzić konkretną wiadomość e-mail przez dzienniki Exim?

Każda wiadomość przetwarzana przez Exim otrzymuje unikalny identyfikator wiadomości widoczny w /var/log/exim_mainlog. Uruchom grep "MESSAGE_ID" /var/log/exim_mainlog, aby pobrać każdy wpis dziennika powiązany z tą wiadomością, od akceptacji przez ostateczne dostarczenie lub odrzucenie.

Dlaczego mój dziennik paniki Exim nie jest pusty i co powinienem zrobić?

Niepusty /var/log/exim_paniclog wskazuje, że Exim napotkał fatalny błąd — zazwyczaj błąd parsowania konfiguracji, problem z biblioteką TLS lub niemożność powiązania z portem 25. Przeczytaj wpisy dziennika paniki, następnie sprawdź składnię konfiguracji Exim za pomocą exim -bV i zweryfikuj, czy port 25 nie jest zablokowany przez inny proces używając ss -tlnp | grep :25.

Jak znaleźć, który skrypt PHP wysyła spam przez Apache?

Filtruj główny dziennik Exim pod kątem wiadomości wysłanych przez użytkownika Apache: grep "U=nobody" /var/log/exim_mainlog. Następnie skrzyżuj znaczniki czasu z wpisami dziennika dostępu Apache, aby zidentyfikować adres URL, który wyzwolił funkcję mail. Nagłówek X-PHP-Originating-Script (jeśli włączony w php.ini) również zidentyfikuje dokładny plik skryptu.

Jaki jest najszybszy sposób sprawdzenia, czy serwer jest atakowany atakiem brute-force SSH?

Uruchom grep "Failed password" /var/log/secure | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head -10, aby zobaczyć najczęściej atakujące adresy IP według liczby prób. Następnie sprawdź, czy cPHulk już je zablokował, sprawdzając /usr/local/cpanel/logs/cphulkd.log lub bezpośrednio zapytując bazę danych cPHulk.