cPanel & WHM Лог Файлове: Пълното Техническо Ръководство за Сървърни Администратори

cPanel & WHM поддържа цялостна, многопластова архитектура за логване, която записва всяко значимо събитие в уеб услугите, доставката на поща, удостоверяването, базите данни и системните операции. Всеки лог файл има отделно местоположение, формат и диагностична цел — знанието кой лог да се провери и как да се анализира ефективно е разликата между поправка за пет минути и разследване на прекъсване, продължаващо часове.

Това ръководство обхваща всеки критичен лог файл в производствена среда на cPanel & WHM, включително пътища до файловете, формати на логовете, реални диагностични случаи на употреба и техники за командния ред, които опитните системни администратори действително използват.

Защо лог файловете на cPanel & WHM изискват вашето внимание

Лог файловете не са просто одитна следа — те са основният диагностичен инструмент за всеки хостинг стек, базиран на Linux. В среда на cPanel конкретно, повърхността за логване обхваща Apache/LiteSpeed, Exim, MySQL/MariaDB, PHP-FPM, ProFTPd, Pure-FTPd, cPHulk и самия приложен слой на cPanel/WHM.

Администраторите, които третират логовете реактивно — проверявайки ги само след повреда — последователно пропускат ранни предупредителни сигнали: постепенно изчерпване на паметта, нарастващи кампании за груба сила, натрупване на бавни заявки и неуспехи при доставка, свързани със сертификати. Проактивният анализ на логовете улавя тези модели, преди да се превърнат в инциденти.

Три основни оперативни цели движат анализа на логовете в среди на cPanel:

• Диагностика на първопричината: Корелиране на времеви отпечатъци в логовете на Apache, PHP и MySQL за точно определяне на точката на повреда в верига от заявки.
• Базово измерване на производителността: Идентифициране на бавни заявки, HTTP отговори с висока латентност и процеси, изразходващи много ресурси, преди да наситят капацитета на сървъра.
• Криминалистика на сигурността: Реконструиране на времеви линии на атаки от SSH лог за удостоверяване, записи на cPHulk и лог за отхвърляния на Exim за определяне на обхвата и стъпките за отстраняване.

Лог файлове на Apache

Apache е уеб сървърът по подразбиране в среди на cPanel, въпреки че LiteSpeed все по-често се използва като директна замяна. И двата записват логове в съвместими формати на едни и същи конвенционални пътища.

Лог за грешки на Apache

Местоположение: /usr/local/apache/logs/error_log

Това е единственият най-консултиран лог при всяка сесия за отстраняване на проблеми в cPanel. Той улавя всяка грешка, генерирана от Apache: фатални грешки на PHP (когато PHP работи като модул), неуспехи в синтаксиса на .htaccess, несъответствия на правила в mod_rewrite, откази за разрешения, неуспехи при SSL ръкостискане и грешки на upstream прокси.

Критичен детайл, който много ръководства пропускат: лог за грешки за всеки домейн също съществува и често е по-непосредствено полезен от глобалния лог за грешки. Те се намират на:

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

Тези логове за всеки VirtualHost изолират грешките до един акаунт, драматично намалявайки шума, когато диагностицирате един конкретен сайт на споделен сървър.

Общ диагностичен модел — цикъл на пренасочване .htaccess:

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

Общ диагностичен модел — фатални грешки на PHP по домейн:

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

Лог за достъп на Apache

Местоположение: /usr/local/apache/logs/access_log

Глобалният лог за достъп записва всяка HTTP/HTTPS заявка в Combined Log Format по подразбиране:

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

Логовете за достъп за всеки домейн се съхраняват на /home/username/logs/domain.com-access_log и са правилният източник за анализ на трафика на отделни акаунти.

Практически случаи на употреба:

• Идентифициране на DDoS или кампания за скрейпинг по честота на IP:

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

• Намиране на всички грешки от серия 500 през последния час (изисква времевите отпечатъци на лога да са скорошни):

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

• Откриване на скенери за уязвимости по низ на потребителски агент:

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

Краен случай: На сървъри с активиран piped logging в WHM, логът за достъп може да е празен или минимален, защото логовете се пренасочват директно към демон за обработка на логове. Проверете WHM > Apache Configuration > Global Configuration за директивата CustomLog, ако намерите неочаквано празен лог за достъп.

Лог за SSL/TLS на Apache

Местоположение: /usr/local/apache/logs/ssl_error_log

Този лог улавя неуспехи при TLS договаряне, грешки при валидиране на сертификати и несъответствия на шифрови пакети. Той е от съществено значение при отстраняване на проблеми с HTTPS свързаност, които не се появяват в основния лог за грешки. Проверете тук първо, когато потребителите съобщават за SSL предупреждения в браузъра или когато автоматичното подновяване на сертификати чрез AutoSSL се проваля безшумно.

Лог файлове на приложенията cPanel и WHM

Лог за достъп до cPanel

Местоположение: /usr/local/cpanel/logs/access_log

Записва всяка HTTP заявка, направена към интерфейса на cPanel (порт 2082/2083). Всеки запис включва удостовереното потребителско име, извършеното действие и изходящия IP. Този лог е основният източник за одитиране на това, което конкретен потребител е направил в своя акаунт в cPanel.

Намиране на всички действия, извършени от конкретен потребител:

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

Лог за грешки на cPanel

Местоположение: /usr/local/cpanel/logs/error_log

Улавя вътрешни грешки от приложния слой на cPanel — неуспешни API извиквания, счупени плъгини на cPanel, грешки на Perl скриптове в бекенда на cPanel и неуспехи при рендиране на шаблони. Ако интерфейсът на cPanel генерира грешки 500 или конкретни функции са счупени, това е първият лог за проверка.

Лог за влизания в WHM

Местоположение: /usr/local/cpanel/logs/login_log

Записва всички събития за удостоверяване в WHM — успешни влизания, неуспешни опити, предизвикателства за двуфакторно удостоверяване и използване на API токени. Този лог е критичен за откриване на неоторизиран административен достъп.

Намиране на всички неуспешни опити за влизане в WHM:

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

Лог за защита от груба сила на cPHulk

Местоположение: /usr/local/cpanel/logs/cphulkd.log

Това е лог, който повечето ръководства напълно пропускат, но е един от най-оперативно важните. cPHulk е вграденият демон за защита от груба сила на cPanel. Той наблюдава опитите за влизане в SSH, FTP, cPanel и WHM и автоматично блокира IP адреси, надхвърлящи праговите ограничения.

Когато легитимен администратор е заключен от WHM или SSH, отговорът почти винаги е в този лог. Можете също да правите заявки директно към базата данни на cPHulk:

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

За деблокиране на конкретен IP от командния ред:

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

Лог за актуализации и инсталации на cPanel

Местоположение: /var/cpanel/updatelogs/

Всяко изпълнение на актуализация на cPanel генерира лог файл с времеви отпечатък в тази директория. Когато надграждане на cPanel счупи услуга или функция изчезне след актуализация, тази директория съдържа пълния изход от процеса на актуализация, включително всички грешки, възникнали по време на инсталиране на пакети или миграция на конфигурация.

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

Лог файлове за имейл

Имейлът е последователно най-сложната подсистема за отстраняване на проблеми в cPanel. Exim, MTA по подразбиране на cPanel, генерира три отделни потока от логове, всеки от които служи за отделна диагностична цел.

Основен лог на Exim

Местоположение: /var/log/exim_mainlog

Това е основният лог за имейл транзакции. Всяко съобщение, обработено от Exim — входящо или изходящо — генерира записи тук, обхващащи приемане, решения за маршрутизиране, опити за доставка и окончателно разпореждане (доставено, отложено или върнато).

Анатомия на запис в лога:

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 на съобщението (1rPqXY-0003aB-Kc) е ключът за проследяване на едно съобщение в целия лог:

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

Проследяване на цялата изходяща поща от конкретен акаунт (критично за разследване на спам):

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

Реален краен случай: Когато компрометирана инсталация на WordPress изпраща спам, основният лог на Exim ще показва изпращащия потребител като nobody (потребителят на процеса Apache), а не потребителско име на акаунт в cPanel. Филтрирайте конкретно за това:

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

Лог за отхвърляния на Exim

Местоположение: /var/log/exim_rejectlog

Записва всички съобщения, които Exim е отказал да приеме на етапа на SMTP връзка — преди дори да са поставени в опашка. Отхвърлянията се случват поради попадания в черния списък на RBL, неуспехи на SPF/DKIM/DMARC, невалидни HELO низове, отказ за релей или ограничаване на скоростта.

Този лог е от съществено значение за два сценария: диагностициране защо легитимна входяща поща се отхвърля и одитиране на ефективността на вашите правила за филтриране на спам.

Намиране на най-честите причини за отхвърляне:

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

Лог за паника на Exim

Местоположение: /var/log/exim_paniclog

Логът за паника улавя фатални грешки на Exim — неуспехи при анализиране на конфигурационен файл, невъзможност за свързване към порт 25, неуспехи при свързване с база данни и грешки на TLS библиотека. Ако този файл не е празен, Exim е претърпял критична повреда. В много случаи непразен лог за паника означава, че опашката за поща е спряла да се обработва изцяло.

# 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

Лог на Dovecot

Местоположение: /var/log/dovecot.log (и /var/log/dovecot-info.log за информационни събития)

Dovecot обработва IMAP и POP3 връзки в среди на cPanel. Неуспехи при удостоверяване, ограничения на връзките, проблеми с блокиране на пощенска кутия и събития за прилагане на квоти се появяват тук. Когато потребителите не могат да се свържат с имейл клиента си, логът на Dovecot е правилното място за проверка — не Exim.

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

Лог файлове на базата данни

Лог за грешки на MySQL/MariaDB

Местоположение: /var/lib/mysql/$(hostname).err

Този лог записва събития за стартиране и спиране на MySQL/MariaDB, операции за възстановяване на InnoDB, грешки при репликация, предупреждения за повреда на таблици и всяка заявка, причиняваща грешка на ниво сървър. Той е окончателният източник за диагностициране на сривове на базата данни и неочаквани рестартирания.

Динамично извличане на действителния път:

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

Проверка за повреда на InnoDB или събития за аварийно възстановяване:

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

Лог за бавни заявки на MySQL

Местоположение: /var/lib/mysql/slowquery.log (когато е активиран)

Логът за бавни заявки е деактивиран по подразбиране в повечето инсталации на cPanel. Активирането му е едно от действията за настройка на производителността с най-висока стойност, които можете да предприемете на сървър с интензивна работа с бази данни.

Активиране на лога за бавни заявки по време на изпълнение (без необходимост от рестартиране):

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

След активиране, използвайте mysqldumpslow за агрегиране и класиране на най-лошите нарушители:

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

Това извежда топ 10 заявки по общо време за изпълнение — най-приложимата отправна точка за оптимизиране на заявки.

Критичен нюанс: long_query_time от 1 секунда е разумен начален праг за повечето приложения, но сайтовете с висок трафик трябва да обмислят 0,5 секунди или дори 0,25 секунди, за да уловят заявки, които са индивидуално бързи, но кумулативно скъпи при натоварване.

Лог за общи заявки на MySQL

Местоположение: Конфигурируемо, обикновено /var/lib/mysql/general.log

Логът за общи заявки записва всеки SQL израз, изпратен до сървъра. Не активирайте това в производство без конкретна, ограничена по време диагностична причина. На натоварен сървър този лог може да расте с гигабайти на час и сам по себе си ще причини деградация на производителността. Активирайте го за кратко, възпроизведете проблема, след което незабавно го деактивирайте.

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

Системни лог файлове

Лог за системни съобщения

Местоположение: /var/log/messages

Логът за съобщения на ядрото и системния демон. Хардуерни грешки (неуспехи при дисков I/O, грешки в паметта ECC), събития на убиеца OOM (Out of Memory), промени в състоянието на мрежовия интерфейс и събития за зареждане на модули на ядрото се появяват тук. Това е първият лог за проверка, когато сървърът стане неотзивчив или се рестартира неочаквано.

Проверка за събития на убиеца OOM (сървър, безшумно убиващ процеси поради изчерпване на паметта):

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

Проверка за грешки при дисков I/O, които могат да показват повреда на устройството:

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

Лог за сигурно удостоверяване

Местоположение: /var/log/secure

Записва всички събития за удостоверяване, базирани на PAM: SSH влизания (успешни и неуспешни), изпълнение на команди sudo, опити su и удостоверяване, инициирано от cron. Това е основният лог за криминалистика на SSH сигурността.

Идентифициране на топ атакуващи IP адреси по брой неуспешни SSH влизания:

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

Одитиране на всички команди sudo, изпълнени на сървъра:

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

Реален краен случай: На сървъри с UseDNS yes в sshd_config, записите за неуспешно влизане могат да показват имена на хостове вместо IP адреси, което нарушава модела awk за извличане на IP по-горе. Проверете настройката си sshd_config и коригирайте индекса на полето съответно.

Буфер на пръстена на ядрото

Местоположение: Само по време на изпълнение — достъпен чрез dmesg

Буферът на пръстена на ядрото не е постоянен файл, но е от съществено значение за диагностициране на хардуерни събития, настъпващи при или малко след зареждане, преди syslog да се инициализира. На системи, базирани на systemd (CentOS 7+, CloudLinux 7+), постоянните логове на ядрото са достъпни чрез:

journalctl -k --since "1 hour ago"

Лог файлове за FTP

Лог на ProFTPd

Местоположение: /var/log/proftpd/proftpd.log

ProFTPd е FTP демонът по подразбиране в среди на cPanel. Този лог записва всички FTP сесийни събития: опити за удостоверяване, обхождане на директории, качване на файлове, изтегляния и прекъсвания на връзката.

Намиране на всички неуспешни опити за FTP влизане:

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

Идентифициране на качвания на големи файлове (потенциално стадиране на зловреден софтуер):

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

Лог на Pure-FTPd

Местоположение: /var/log/pureftpd.log

Логовете на Pure-FTPd се записват в syslog по подразбиране при някои конфигурации, което означава, че записите могат да се появят в /var/log/messages вместо в специален файл. Проверете активната дестинация за логване:

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

PHP и лог файлове на ниво приложение

Лог за грешки на PHP

Грешките на PHP в среди на cPanel могат да се логват на множество места в зависимост от използвания PHP манипулатор:

Пътят на лога на PHP-FPM пула включва номера на версията на PHP. За PHP 8.2, управляван от EasyApache 4:

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

Логването на грешки на PHP за всеки акаунт може да се активира чрез добавяне на следното към php.ini или .htaccess на акаунта:

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

Логове за услуги и сигурност, специфични за cPanel

Лог на мениджъра на услуги на cPanel

Местоположение: /usr/local/cpanel/logs/safeapacherestart_log

Записва всяко събитие за рестартиране на Apache, задействано от мениджъра на услуги на cPanel, включително причината за рестартирането и дали е успяло. Полезен за корелиране на престоя на Apache с промени в конфигурацията.

Лог за архивиране на cPanel

Местоположение: /usr/local/cpanel/logs/cpbackup/

Всяко изпълнение на архивиране генерира лог файл за всеки акаунт в тази директория. Когато архивирането се проваля безшумно, тази директория съдържа конкретната грешка — дали е бил проблем с дисковото пространство, неуспех при дъмп на базата данни или проблем с разрешенията.

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

Лог за AutoSSL на cPanel

Местоположение: /var/cpanel/logs/autossl/

AutoSSL е автоматизираната система за предоставяне на сертификати Let’s Encrypt / Sectigo на cPanel. Когато подновяването на SSL сертификат се провали, подробната причина — неуспех на DCV, ограничаване на скоростта, несъответствие при валидиране на домейн — се записва тук. Този лог е критичен за диагностициране на проблеми с изтичане на HTTPS сертификати, преди да причинят предупреждения в браузъра.

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

Ако управлявате SSL сертификати в множество домейни или се нуждаете от сертификати извън това, което AutoSSL предоставя, SSL сертификати от специализиран доставчик предлагат разширено валидиране и wildcard опции, които Let’s Encrypt не предоставя.

Справочник за сравнение на лог файлове

Техники за анализ на логове от командния ред

Основни команди за анализ в реално време и исторически анализ

Следване на лог в реално време (най-честият работен процес на системния администратор):

tail -f /var/log/exim_mainlog

Едновременно следване на множество логове с multitail (инсталирайте чрез yum install multitail):

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

Извличане и броене на уникални стойности от конкретно поле:

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

Търсене в компресирани архиви на ротирани логове:

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

Филтриране на записи в лога в рамките на конкретен времеви прозорец:

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

Броене на разпределението на HTTP статус кодове:

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

Ротация на логове в cPanel

cPanel използва logrotate за управление на размерите на лог файловете. Конфигурацията за ротация на управляваните от cPanel логове е в /etc/logrotate.d/. Логовете на Apache се ротират от собствения механизъм splitlogs на cPanel, който също разделя глобалния лог за достъп на файлове за всеки домейн.

Проверка на текущата конфигурация на logrotate за конкретна услуга:

cat /etc/logrotate.d/syslog

Ръчно задействане на ротация на логове за тестване:

logrotate -f /etc/logrotate.d/syslog

Критичен капан: Ако ротацията на логовете е неправилно конфигурирана или дисковото пространство е изчерпано, лог файловете могат да нараснат до запълване на целия дял, причинявайки едновременен срив на всички услуги. Наблюдавайте използването на диска на дяла, съдържащ /var/log и /usr/local/apache/logs, като стандартна оперативна практика.

Централизирано управление на логове и сигнализиране

За производствени среди — особено на VPS хостинг или Dedicated сървър — разчитането на ръчна проверка на логове е недостатъчно в мащаб. Приложете един от следните подходи:

Агрегиране на логове с препращане rsyslog: Конфигурирайте /etc/rsyslog.conf да препраща логове към централизиран syslog сървър или SIEM платформа. Това запазва логовете дори ако самият сървър е компрометиран.

ELK стек (Elasticsearch, Logstash, Kibana): Поглъщайте логовете на cPanel чрез агенти Filebeat, анализирайте ги с конвейери на Logstash и визуализирайте модели в Kibana. Този подход позволява пълнотекстово търсене в месеци история на логовете за секунди.

Интеграция с Fail2ban: Fail2ban чете /var/log/secure и /var/log/exim_mainlog и автоматично създава правила iptables за блокиране на атакуващи IP адреси. Той работи независимо от cPHulk и осигурява допълнителен защитен слой.

GoAccess за анализ на логове на Apache: GoAccess е анализатор на логове в реално време, базиран на терминал, който генерира HTML отчети от логовете за достъп на Apache без необходимост от пълно внедряване на ELK:

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

Администраторите, управляващи множество акаунти в cPanel или настройки за препродавачи на VPS с cPanel, се възползват значително от централизирана видимост на логовете, тъй като логовете на отделните акаунти иначе са изолирани под всяка домашна директория.

Корелация на логове за имейл инфраструктура

Една от най-подценяваните диагностични техники в среди на cPanel е кръстосаното препращане на логовете на Exim с логовете на Dovecot и системния лог за удостоверяване за проследяване на пълния жизнен цикъл на инцидент с имейл сигурност.

Сценарий: Потребител съобщава, че акаунтът му изпраща спам, който не е написал.

Стъпка 1 — Идентифициране на ID на съобщенията на Exim, свързани с акаунта:

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

Стъпка 2 — Проверка дали изпращането е произлязло от уеб приложение (PHP mail()) или удостоверен SMTP:

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

P=esmtpa показва удостоверено SMTP подаване. P=local или P=pipe показва локален скрипт (вероятно компрометирано уеб приложение).

Стъпка 3 — Ако P=esmtpa, намерете изходящия IP от лога за удостоверяване на Dovecot или Exim:

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

Стъпка 4 — Кръстосано препращане на този IP срещу /var/log/secure за SSH активност и срещу лога за достъп до cPanel за влизания в контролния панел.

Тази четиристъпкова техника за корелация дава окончателен отговор дали компрометирането е кражба на идентификационни данни, уязвимо уеб приложение или SMTP акаунт, атакуван с груба сила — и това разграничение изцяло определя пътя за отстраняване.

За организации, управляващи собствена имейл инфраструктура, правилно конфигурирана среда за имейл хостинг с специализирано наблюдение на логове осигурява необходимата изолация за предотвратяване на щети върху репутацията на пощата между акаунти.

Съображения за логове, свързани с домейни и DNS

Неуспехите при DNS резолюция често се проявяват като грешки в логовете на приложенията, а не в специален DNS лог. Named (BIND), който cPanel използва за DNS, логва в /var/log/messages по подразбиране.

Проверка за грешки на BIND:

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

Когато проблемите с разпространението на DNS засягат новорегистрирани или прехвърлени домейни, корелирането на лога на BIND с конфигурацията на домейна в cPanel помага да се изолира дали проблемът е грешка в зонов файл или забавяне на разпространение на ниво регистратор. Ако управлявате регистрацията на домейни и DNS чрез една и съща платформа, регистрацията на домейни с интегрирано управление на DNS опростява тази диагностична верига.

Практическа матрица за решения: Кой лог да проверите първо

Ключови технически изводи

• Винаги проверявайте първо логовете за всеки домейн (/home/username/logs/) преди глобалните логове на Apache — те съдържат същите данни с драматично по-малко шум.
• Непразен /var/log/exim_paniclog е инцидент от ниво P1 — Exim може да е спрял да обработва опашката за поща изцяло.
• Логът на cPHulk на /usr/local/cpanel/logs/cphulkd.log е правилната първа спирка при всеки сценарий на заключване, а не /var/log/secure.
• Активирайте лога за бавни заявки на MySQL (long_query_time = 1) на всеки производствен сървър с бази данни — разузнаването за производителността, което предоставя, си заслужава минималните разходи.
• Кръстосано корелирайте полето P= на Exim с логовете за удостоверяване на Dovecot, за да определите окончателно дали инцидент със спам е произлязъл от кражба на идентификационни данни или компрометирано уеб приложение.
• Неправилната конфигурация на ротацията на логовете е безшумен режим на повреда — пълен дял /var/log ще срине всички услуги едновременно без предупреждение.
• zgrep работи на ротирани архиви .gz — историческият анализ на логовете не изисква ръчно декомпресиране на файлове.
• Централизираното препращане на логове чрез rsyslog е минималната жизнеспособна позиция за сигурност за всеки сървър, обработващ чувствителни данни — локалните логове могат да бъдат изтрити от атакуващ, получил root достъп.

Често задавани въпроси

Къде се намират лог файловете за грешки на cPanel?

Основният лог за грешки на приложението cPanel е на /usr/local/cpanel/logs/error_log. Грешките на уеб сървъра Apache са на /usr/local/apache/logs/error_log, а PHP грешките за всеки акаунт са в /home/username/logs/domain.com-error_log. Всяка услуга поддържа собствен лог файл на отделен път.

Как да проследя конкретно имейл съобщение в логовете на Exim?

Всяко съобщение, обработено от Exim, получава уникален ID на съобщение, видим в /var/log/exim_mainlog. Изпълнете grep "MESSAGE_ID" /var/log/exim_mainlog, за да извлечете всеки запис в лога, свързан с това съобщение, от приемането до окончателната доставка или връщане.

Защо логът за паника на Exim не е празен и какво трябва да направя?

Непразен /var/log/exim_paniclog показва, че Exim е срещнал фатална грешка — обикновено неуспех при анализиране на конфигурация, проблем с TLS библиотека или невъзможност за свързване към порт 25. Прочетете записите в лога за паника, след което проверете синтаксиса на конфигурацията на Exim с exim -bV и проверете дали порт 25 не е блокиран от друг процес с ss -tlnp | grep :25.

Как да намеря кой PHP скрипт изпраща спам чрез Apache?

Филтрирайте основния лог на Exim за съобщения, изпратени от потребителя на Apache: grep "U=nobody" /var/log/exim_mainlog. След това кръстосано препратете времевите отпечатъци с записите в лога за достъп на Apache, за да идентифицирате URL адреса, задействал функцията за поща. Заглавката X-PHP-Originating-Script (ако е активирана в php.ini) също ще идентифицира точния скрипт файл.

Какъв е най-бързият начин да проверя дали сървърът е под SSH атака с груба сила?

Изпълнете grep "Failed password" /var/log/secure | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head -10, за да видите топ атакуващите IP адреси по брой опити. След това проверете дали cPHulk вече ги е блокирал, като проверите /usr/local/cpanel/logs/cphulkd.log или правите заявки директно към базата данни на cPHulk.