Fișiere Log cPanel & WHM: Referința Tehnică Completă pentru Administratorii de Server

cPanel & WHM menține o arhitectură de jurnalizare cuprinzătoare, pe mai multe niveluri, care înregistrează fiecare eveniment semnificativ în serviciile web, livrarea e-mailurilor, autentificare, baze de date și operațiuni de sistem. Fiecare fișier jurnal are o locație, un format și un scop de diagnosticare distinct — a ști ce jurnal să consulți și cum să-l analizezi eficient face diferența dintre o remediere de cinci minute și o investigație de mai multe ore a unei întreruperi.

Acest ghid acoperă fiecare fișier jurnal critic dintr-un mediu de producție cPanel & WHM, inclusiv căile fișierelor, formatele jurnalelor, cazuri de utilizare de diagnosticare din lumea reală și tehnici de linie de comandă pe care administratorii de sistem experimentați le folosesc efectiv.

De ce fișierele jurnal cPanel & WHM necesită atenția dumneavoastră

Fișierele jurnal nu sunt doar o pistă de audit — ele sunt instrumentul principal de diagnosticare pentru orice stivă de hosting bazată pe Linux. Într-un mediu cPanel în mod specific, suprafața de jurnalizare acoperă Apache/LiteSpeed, Exim, MySQL/MariaDB, PHP-FPM, ProFTPd, Pure-FTPd, cPHulk și stratul de aplicație cPanel/WHM în sine.

Administratorii care tratează jurnalele reactiv — verificându-le doar după o defecțiune — ratează în mod constant semnalele de avertizare timpurie: epuizarea treptată a memoriei, campanii incrementale de forță brută, acumularea de interogări lente și eșecuri de livrare legate de certificate. Analiza proactivă a jurnalelor detectează aceste tipare înainte ca ele să devină incidente.

Trei obiective operaționale de bază conduc analiza jurnalelor în mediile cPanel:

• Diagnosticarea cauzei principale: Corelarea marcajelor de timp din jurnalele Apache, PHP și MySQL pentru a identifica punctul exact de eșec dintr-un lanț de cereri.
• Stabilirea liniei de bază a performanței: Identificarea interogărilor lente, a răspunsurilor HTTP cu latență ridicată și a proceselor care consumă multe resurse înainte ca acestea să satureze capacitatea serverului.
• Criminalistică de securitate: Reconstituirea cronologiilor atacurilor din jurnalele de autentificare SSH, înregistrările cPHulk și jurnalele de respingere Exim pentru a determina amploarea și pașii de remediere.

Fișiere jurnal Apache

Apache este serverul web implicit în mediile cPanel, deși LiteSpeed este din ce în ce mai comun ca înlocuitor direct. Ambele scriu jurnale în formate compatibile la aceleași căi convenționale.

Jurnalul de erori Apache

Locație: /usr/local/apache/logs/error_log

Acesta este cel mai consultat jurnal în orice sesiune de depanare cPanel. Captează fiecare eroare pe care Apache o generează: erori fatale PHP (când PHP rulează ca modul), eșecuri de sintaxă .htaccess, nepotriviri de reguli mod_rewrite, refuzuri de permisiuni, eșecuri de handshake SSL și erori de proxy upstream.

Un detaliu critic pe care multe ghiduri îl omit: jurnalele de erori per domeniu există de asemenea și sunt adesea mai imediat utile decât jurnalul global de erori. Acestea se află la:

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

Aceste jurnale per-VirtualHost izolează erorile la un singur cont, reducând dramatic zgomotul atunci când diagnosticați un site specific pe un server partajat.

Tipar de diagnosticare comun — buclă de rescriere .htaccess:

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

Tipar de diagnosticare comun — erori fatale PHP pe domeniu:

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

Jurnalul de acces Apache

Locație: /usr/local/apache/logs/access_log

Jurnalul global de acces înregistrează fiecare cerere HTTP/HTTPS în Combined Log Format în mod implicit:

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

Jurnalele de acces per domeniu sunt stocate la /home/username/logs/domain.com-access_log și reprezintă sursa corectă pentru analiza traficului pe conturi individuale.

Cazuri de utilizare practice:

• Identificarea unei campanii DDoS sau de scraping prin frecvența IP:

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

• Găsirea tuturor erorilor din seria 500 din ultima oră (necesită ca marcajele de timp ale jurnalului să fie recente):

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

• Detectarea scanerelor de vulnerabilități prin șirul user-agent:

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

Caz limită: Pe serverele cu piped logging activat în WHM, jurnalul de acces poate fi gol sau minimal deoarece jurnalele sunt direcționate direct către un daemon de procesare a jurnalelor. Verificați WHM > Apache Configuration > Global Configuration pentru directiva CustomLog dacă găsiți un jurnal de acces neașteptat de gol.

Jurnalul SSL/TLS Apache

Locație: /usr/local/apache/logs/ssl_error_log

Acest jurnal captează eșecurile de negociere TLS, erorile de validare a certificatelor și nepotrivirile suitelor de cifrare. Este esențial la depanarea problemelor de conectivitate HTTPS care nu apar în jurnalul principal de erori. Căutați aici mai întâi când utilizatorii raportează avertismente SSL în browser sau când reînnoirea automată a certificatelor prin AutoSSL eșuează silențios.

Jurnalele aplicației cPanel și WHM

Jurnalul de acces cPanel

Locație: /usr/local/cpanel/logs/access_log

Înregistrează fiecare cerere HTTP făcută către interfața cPanel (portul 2082/2083). Fiecare intrare include numele de utilizator autentificat, acțiunea efectuată și IP-ul de origine. Acest jurnal este sursa principală pentru auditarea a ceea ce a făcut un utilizator specific în contul său cPanel.

Găsiți toate acțiunile efectuate de un utilizator specific:

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

Jurnalul de erori cPanel

Locație: /usr/local/cpanel/logs/error_log

Captează erorile interne din stratul de aplicație cPanel — apeluri API eșuate, plugin-uri cPanel defecte, erori de script Perl în backend-ul cPanel și eșecuri de randare a șabloanelor. Dacă interfața cPanel generează erori 500 sau anumite funcții sunt defecte, acesta este primul jurnal de verificat.

Jurnalul de autentificare WHM

Locație: /usr/local/cpanel/logs/login_log

Înregistrează toate evenimentele de autentificare WHM — autentificări reușite, tentative eșuate, provocări de autentificare cu doi factori și utilizarea token-urilor API. Acest jurnal este critic pentru detectarea accesului administrativ neautorizat.

Găsiți toate tentativele eșuate de autentificare WHM:

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

Jurnalul de protecție împotriva forței brute cPHulk

Locație: /usr/local/cpanel/logs/cphulkd.log

Acesta este un jurnal pe care majoritatea ghidurilor îl omit complet, dar este unul dintre cele mai importante din punct de vedere operațional. cPHulk este daemonul de protecție împotriva forței brute integrat în cPanel. Monitorizează tentativele de autentificare SSH, FTP, cPanel și WHM și blochează automat IP-urile care depășesc limitele de prag.

Când un administrator legitim este blocat din WHM sau SSH, răspunsul se află aproape întotdeauna în acest jurnal. Puteți de asemenea interoga direct baza de date cPHulk:

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

Pentru a debloca un IP specific din linia de comandă:

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

Jurnalul de actualizare și instalare cPanel

Locație: /var/cpanel/updatelogs/

Fiecare rulare de actualizare cPanel generează un fișier jurnal cu marcaj de timp în acest director. Când o actualizare cPanel defectează un serviciu sau o funcție dispare după o actualizare, acest director conține ieșirea completă a procesului de actualizare, inclusiv orice erori care au apărut în timpul instalării pachetelor sau migrării configurației.

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

Fișiere jurnal de e-mail

E-mailul este în mod constant cel mai complex subsistem de depanat în cPanel. Exim, MTA-ul implicit al cPanel, generează trei fluxuri de jurnal separate, fiecare servind unui scop de diagnosticare distinct.

Jurnalul principal Exim

Locație: /var/log/exim_mainlog

Acesta este jurnalul principal al tranzacțiilor de e-mail. Fiecare mesaj pe care Exim îl procesează — inbound sau outbound — generează intrări aici acoperind acceptarea, deciziile de rutare, tentativele de livrare și dispoziția finală (livrat, amânat sau respins).

Anatomia unei intrări de jurnal:

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

ID-ul mesajului (1rPqXY-0003aB-Kc) este cheia pentru urmărirea unui singur mesaj prin întregul jurnal:

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

Urmăriți tot e-mailul outbound de la un cont specific (critic pentru investigarea spam-ului):

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

Caz limită din lumea reală: Când o instalare WordPress compromisă trimite spam, jurnalul principal Exim va arăta utilizatorul expeditor ca nobody (utilizatorul procesului Apache) mai degrabă decât un nume de utilizator al contului cPanel. Filtrați specific pentru aceasta:

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

Jurnalul de respingere Exim

Locație: /var/log/exim_rejectlog

Înregistrează toate mesajele pe care Exim a refuzat să le accepte la etapa conexiunii SMTP — înainte ca acestea să fie chiar puse în coadă. Respingerile apar din cauza accesărilor listei negre RBL, eșecurilor SPF/DKIM/DMARC, șirurilor HELO invalide, refuzului de relay sau limitării ratei.

Acest jurnal este esențial pentru două scenarii: diagnosticarea motivului pentru care e-mailul inbound legitim este respins și auditarea eficacității regulilor de filtrare a spam-ului.

Găsiți cele mai comune motive de respingere:

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

Jurnalul de panică Exim

Locație: /var/log/exim_paniclog

Jurnalul de panică captează erorile fatale Exim — eșecuri de analizare a fișierului de configurare, incapacitatea de a se lega la portul 25, eșecuri de conexiune la baza de date și erori ale bibliotecii TLS. Dacă acest fișier nu este gol, Exim a experimentat o defecțiune critică. În multe cazuri, un jurnal de panică non-gol înseamnă că coada de e-mail a încetat complet procesarea.

# 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

Jurnalul Dovecot

Locație: /var/log/dovecot.log (și /var/log/dovecot-info.log pentru evenimentele informaționale)

Dovecot gestionează conexiunile IMAP și POP3 în mediile cPanel. Eșecurile de autentificare, limitele de conexiune, problemele de blocare a căsuței poștale și evenimentele de aplicare a cotelor apar toate aici. Când utilizatorii nu se pot conecta la clientul lor de e-mail, jurnalul Dovecot este locul corect de căutat — nu Exim.

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

Fișiere jurnal ale bazei de date

Jurnalul de erori MySQL/MariaDB

Locație: /var/lib/mysql/$(hostname).err

Acest jurnal înregistrează evenimentele de pornire și oprire MySQL/MariaDB, operațiunile de recuperare InnoDB, erorile de replicare, avertismentele de corupție a tabelelor și orice interogare care cauzează o eroare la nivel de server. Este sursa definitivă pentru diagnosticarea blocărilor bazei de date și a repornirilor neașteptate.

Recuperați calea reală în mod dinamic:

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

Verificați evenimentele de corupție InnoDB sau de recuperare după blocare:

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

Jurnalul de interogări lente MySQL

Locație: /var/lib/mysql/slowquery.log (când este activat)

Jurnalul de interogări lente este dezactivat implicit în majoritatea instalărilor cPanel. Activarea sa este una dintre acțiunile de optimizare a performanței cu cea mai mare valoare pe care le puteți face pe un server cu baze de date intensive.

Activați jurnalul de interogări lente la runtime (fără repornire necesară):

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';"

Odată activat, utilizați mysqldumpslow pentru a agrega și clasifica cei mai problematici ofensatori:

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

Aceasta afișează primele 10 interogări după timpul total de execuție — cel mai acționabil punct de plecare pentru optimizarea interogărilor.

Nuanță critică: Un long_query_time de 1 secundă este un prag de pornire rezonabil pentru majoritatea aplicațiilor, dar site-urile cu trafic ridicat ar trebui să ia în considerare 0,5 secunde sau chiar 0,25 secunde pentru a detecta interogările care sunt individual rapide, dar cumulativ costisitoare sub sarcină.

Jurnalul general de interogări MySQL

Locație: Configurabil, de obicei /var/lib/mysql/general.log

Jurnalul general de interogări înregistrează fiecare instrucțiune SQL trimisă serverului. Nu activați aceasta în producție fără un motiv de diagnosticare specific, limitat în timp. Pe un server ocupat, acest jurnal poate crește cu gigabytes pe oră și va cauza el însuși degradarea performanței. Activați-l pe scurt, reproduceți problema, apoi dezactivați-l imediat.

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';"

Fișiere jurnal de sistem

Jurnalul de mesaje de sistem

Locație: /var/log/messages

Jurnalul de mesaje al kernelului și daemonului de sistem. Erorile hardware (eșecuri I/O de disc, erori ECC de memorie), evenimentele OOM (Out of Memory) killer, schimbările de stare ale interfeței de rețea și evenimentele de încărcare a modulelor kernelului apar toate aici. Acesta este primul jurnal de verificat când un server devine iresponsiv sau repornește neașteptat.

Verificați evenimentele OOM killer (un server care ucide silențios procese din cauza epuizării memoriei):

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

Verificați erorile I/O de disc care pot indica defecțiunea unității:

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

Jurnalul de autentificare securizată

Locație: /var/log/secure

Înregistrează toate evenimentele de autentificare bazate pe PAM: autentificări SSH (reușite și eșuate), execuția comenzii sudo, tentative su și autentificare inițiată de cron. Acesta este jurnalul principal pentru criminalistică de securitate SSH.

Identificați IP-urile atacatoare de top după numărul de autentificări SSH eșuate:

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

Auditați toate comenzile sudo executate pe server:

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

Caz limită din lumea reală: Pe serverele cu UseDNS yes în sshd_config, intrările de autentificare eșuată pot afișa nume de gazdă în loc de adrese IP, ceea ce strică tiparul awk de extragere IP de mai sus. Verificați setarea sshd_config și ajustați indexul câmpului în consecință.

Buffer-ul inel al kernelului

Locație: Doar la runtime — accesat prin dmesg

Buffer-ul inel al kernelului nu este un fișier persistent, dar este esențial pentru diagnosticarea evenimentelor la nivel hardware care apar la sau imediat după pornire, înainte ca syslog să se inițializeze. Pe sistemele bazate pe systemd (CentOS 7+, CloudLinux 7+), jurnalele persistente ale kernelului sunt disponibile prin:

journalctl -k --since "1 hour ago"

Fișiere jurnal FTP

Jurnalul ProFTPd

Locație: /var/log/proftpd/proftpd.log

ProFTPd este daemonul FTP implicit în mediile cPanel. Acest jurnal înregistrează toate evenimentele sesiunii FTP: tentative de autentificare, traversarea directoarelor, încărcări de fișiere, descărcări și deconectări.

Găsiți toate tentativele eșuate de autentificare FTP:

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

Identificați încărcările de fișiere mari (potențială pregătire de malware):

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

Jurnalul Pure-FTPd

Locație: /var/log/pureftpd.log

Jurnalele Pure-FTPd sunt scrise în syslog implicit în unele configurații, ceea ce înseamnă că intrările pot apărea în /var/log/messages mai degrabă decât într-un fișier dedicat. Verificați destinația de jurnalizare activă:

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

Jurnale PHP și la nivel de aplicație

Jurnalul de erori PHP

Erorile PHP în mediile cPanel pot fi jurnalizate în mai multe locații în funcție de handler-ul PHP utilizat:

Calea jurnalului pool-ului PHP-FPM include numărul versiunii PHP. Pentru PHP 8.2 gestionat de EasyApache 4:

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

Jurnalizarea erorilor PHP per cont poate fi activată prin adăugarea următoarelor în php.ini sau .htaccess al contului:

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

Jurnale de servicii și securitate specifice cPanel

Jurnalul managerului de servicii cPanel

Locație: /usr/local/cpanel/logs/safeapacherestart_log

Înregistrează fiecare eveniment de repornire Apache declanșat de managerul de servicii cPanel, inclusiv motivul repornirii și dacă a reușit. Util pentru corelarea timpilor de nefuncționare Apache cu modificările de configurare.

Jurnalul de backup cPanel

Locație: /usr/local/cpanel/logs/cpbackup/

Fiecare rulare de backup generează un fișier jurnal per cont în acest director. Când un backup eșuează silențios, acest director conține eroarea specifică — fie că a fost o problemă de spațiu pe disc, un eșec de dump al bazei de date sau o problemă de permisiuni.

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

Jurnalul AutoSSL cPanel

Locație: /var/cpanel/logs/autossl/

AutoSSL este sistemul automat de provizionare a certificatelor Let’s Encrypt / Sectigo al cPanel. Când reînnoirea certificatelor SSL eșuează, motivul detaliat — eșec DCV, limitare a ratei, nepotrivire de validare a domeniului — este înregistrat aici. Acest jurnal este critic pentru diagnosticarea problemelor de expirare a certificatelor HTTPS înainte ca acestea să cauzeze avertismente în browser.

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

Dacă gestionați certificate SSL pe mai multe domenii sau aveți nevoie de certificate dincolo de ceea ce oferă AutoSSL, Certificatele SSL de la un furnizor dedicat oferă opțiuni de validare extinsă și wildcard pe care Let’s Encrypt nu le oferă.

Referință comparativă a fișierelor jurnal

Tehnici de analiză a jurnalelor din linia de comandă

Comenzi esențiale pentru analiza în timp real și istorică

Urmăriți un jurnal în timp real (cel mai comun flux de lucru al administratorului de sistem):

tail -f /var/log/exim_mainlog

Urmăriți mai multe jurnale simultan folosind multitail (instalați prin yum install multitail):

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

Extrageți și numărați valorile unice dintr-un câmp specific:

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

Căutați în arhivele de jurnale rotite comprimate:

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

Filtrați intrările de jurnal într-o fereastră de timp specifică:

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

Numărați distribuția codurilor de stare HTTP:

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

Rotația jurnalelor în cPanel

cPanel folosește logrotate pentru a gestiona dimensiunile fișierelor jurnal. Configurația de rotație pentru jurnalele gestionate de cPanel se află în /etc/logrotate.d/. Jurnalele Apache sunt rotite de mecanismul propriu splitlogs al cPanel, care împarte de asemenea jurnalul global de acces în fișiere per domeniu.

Verificați configurația curentă logrotate pentru un serviciu specific:

cat /etc/logrotate.d/syslog

Declanșați manual rotația jurnalelor pentru testare:

logrotate -f /etc/logrotate.d/syslog

Capcană critică: Dacă rotația jurnalelor este configurată greșit sau spațiul pe disc este epuizat, fișierele jurnal pot crește până la umplerea întregii partiții, cauzând eșecul simultan al tuturor serviciilor. Monitorizați utilizarea discului pe partiția care conține /var/log și /usr/local/apache/logs ca practică operațională standard.

Gestionarea centralizată a jurnalelor și alertare

Pentru mediile de producție — în special pe un Hosting VPS sau Server Dedicat — bazarea pe inspecția manuală a jurnalelor este insuficientă la scară. Implementați una dintre următoarele abordări:

Agregarea jurnalelor cu redirecționare rsyslog: Configurați /etc/rsyslog.conf pentru a redirecționa jurnalele către un server syslog centralizat sau o platformă SIEM. Aceasta păstrează jurnalele chiar dacă serverul în sine este compromis.

ELK Stack (Elasticsearch, Logstash, Kibana): Ingerați jurnalele cPanel prin agenți Filebeat, analizați-le cu pipeline-uri Logstash și vizualizați tiparele în Kibana. Această abordare permite căutarea full-text în luni de istoric al jurnalelor în câteva secunde.

Integrare Fail2ban: Fail2ban citește /var/log/secure și /var/log/exim_mainlog și creează automat reguli iptables pentru a bloca IP-urile atacatoare. Funcționează independent de cPHulk și oferă un strat suplimentar de apărare.

GoAccess pentru analiza jurnalelor Apache: GoAccess este un analizor de jurnale în timp real bazat pe terminal care produce rapoarte HTML din jurnalele de acces Apache fără a necesita o implementare ELK completă:

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

Administratorii care gestionează mai multe conturi cPanel sau configurații de reseller pe un VPS cu cPanel beneficiază semnificativ de vizibilitatea centralizată a jurnalelor, deoarece jurnalele conturilor individuale sunt altfel izolate sub fiecare director home.

Corelarea jurnalelor infrastructurii de e-mail

Una dintre tehnicile de diagnosticare cel mai subevaluate în mediile cPanel este încrucișarea jurnalelor Exim cu jurnalele Dovecot și jurnalul de autentificare a sistemului pentru a urmări ciclul de viață complet al unui incident de securitate a e-mailului.

Scenariu: Un utilizator raportează că contul său trimite spam pe care nu l-a scris.

Pasul 1 — Identificați ID-urile mesajelor Exim asociate cu contul:

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

Pasul 2 — Verificați dacă trimiterea a provenit dintr-o aplicație web (PHP mail()) sau SMTP autentificat:

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

P=esmtpa indică trimitere SMTP autentificată. P=local sau P=pipe indică un script local (probabil o aplicație web compromisă).

Pasul 3 — Dacă P=esmtpa, găsiți IP-ul de origine din jurnalul de autentificare Dovecot sau Exim:

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

Pasul 4 — Încrucișați acel IP cu /var/log/secure pentru activitatea SSH și cu jurnalul de acces cPanel pentru autentificările în panoul de control.

Această tehnică de corelare în patru pași răspunde definitiv dacă compromiterea a fost un furt de credențiale, o aplicație web vulnerabilă sau un cont SMTP forțat prin forță brută — iar această distincție determină în întregime calea de remediere.

Pentru organizațiile care rulează propria infrastructură de e-mail, un mediu de Hosting E-mail configurat corespunzător cu monitorizarea dedicată a jurnalelor oferă izolarea necesară pentru a preveni deteriorarea reputației de e-mail între conturi.

Considerații privind jurnalele legate de domenii și DNS

Eșecurile de rezoluție DNS se manifestă adesea ca erori în jurnalele aplicațiilor mai degrabă decât într-un jurnal DNS dedicat. Named (BIND), pe care cPanel îl folosește pentru DNS, jurnalizează în /var/log/messages implicit.

Verificați erorile BIND:

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

Când problemele de propagare DNS afectează domeniile nou înregistrate sau transferate, corelarea jurnalului BIND cu configurația domeniului cPanel ajută la izolarea dacă problema este o eroare a fișierului de zonă sau o întârziere de propagare la nivel de registrar. Dacă gestionați înregistrarea domeniului și DNS prin aceeași platformă, Înregistrarea domeniului cu gestionare integrată DNS simplifică acest lanț de diagnosticare.

Matrice de decizie practică: Ce jurnal să verificați mai întâi

Concluzii tehnice cheie

• Verificați întotdeauna mai întâi jurnalele per domeniu (/home/username/logs/) înainte de jurnalele globale Apache — conțin aceleași date cu mult mai puțin zgomot.
• Un /var/log/exim_paniclog non-gol este un incident P1 — Exim poate fi oprit complet din procesarea cozii de e-mail.
• Jurnalul cPHulk la /usr/local/cpanel/logs/cphulkd.log este prima oprire corectă pentru orice scenariu de blocare, nu /var/log/secure.
• Activați jurnalul de interogări lente MySQL (long_query_time = 1) pe orice server de baze de date de producție — informațiile de performanță pe care le oferă merită overhead-ul minimal.
• Încrucișați câmpul P= al Exim cu jurnalele de autentificare Dovecot pentru a determina definitiv dacă un incident de spam a provenit din furtul de credențiale sau o aplicație web compromisă.
• Configurarea greșită a rotației jurnalelor este un mod de eșec silențios — o partiție /var/log plină va bloca toate serviciile simultan fără avertisment.
• zgrep funcționează pe arhivele .gz rotite — analiza istorică a jurnalelor nu necesită decomprimarea manuală a fișierelor.
• Redirecționarea centralizată a jurnalelor prin rsyslog este postura minimă viabilă de securitate pentru orice server care gestionează date sensibile — jurnalele locale pot fi șterse de un atacator care obține acces root.

Întrebări frecvente

Unde se află jurnalele de erori cPanel?

Jurnalul principal de erori al aplicației cPanel se află la /usr/local/cpanel/logs/error_log. Erorile serverului web Apache se află la /usr/local/apache/logs/error_log, iar erorile PHP per cont se află în /home/username/logs/domain.com-error_log. Fiecare serviciu menține propriul fișier jurnal la o cale distinctă.

Cum urmăresc un mesaj de e-mail specific prin jurnalele Exim?

Fiecare mesaj pe care Exim îl procesează primește un ID de mesaj unic vizibil în /var/log/exim_mainlog. Rulați grep "MESSAGE_ID" /var/log/exim_mainlog pentru a recupera fiecare intrare de jurnal asociată cu acel mesaj, de la acceptare până la livrarea finală sau respingere.

De ce jurnalul meu de panică Exim nu este gol și ce ar trebui să fac?

Un /var/log/exim_paniclog non-gol indică faptul că Exim a întâlnit o eroare fatală — de obicei un eșec de analizare a configurației, o problemă cu biblioteca TLS sau incapacitatea de a se lega la portul 25. Citiți intrările din jurnalul de panică, apoi verificați sintaxa configurației Exim cu exim -bV și verificați că portul 25 nu este blocat de un alt proces folosind ss -tlnp | grep :25.

Cum găsesc ce script PHP trimite spam prin Apache?

Filtrați jurnalul principal Exim pentru mesajele trimise de utilizatorul Apache: grep "U=nobody" /var/log/exim_mainlog. Apoi încrucișați marcajele de timp cu intrările din jurnalul de acces Apache pentru a identifica URL-ul care a declanșat funcția de e-mail. Antetul X-PHP-Originating-Script (dacă este activat în php.ini) va identifica de asemenea fișierul script exact.

Care este cel mai rapid mod de a verifica dacă un server este sub un atac SSH prin forță brută?

Rulați grep "Failed password" /var/log/secure | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head -10 pentru a vedea adresele IP atacatoare de top după numărul de tentative. Apoi verificați dacă cPHulk le-a blocat deja verificând /usr/local/cpanel/logs/cphulkd.log sau interogând direct baza de date cPHulk.