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-рукопожатия и ошибки обратного прокси.

Важная деталь, которую многие руководства упускают: логи ошибок для отдельных доменов также существуют и зачастую более полезны, чем глобальный лог ошибок. Они расположены по адресу:

/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

• Обнаружение сканеров уязвимостей по строке user-agent:

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

Идентификатор сообщения (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

Лог сообщений ядра и системных демонов. Аппаратные ошибки (сбои дискового ввода-вывода, ошибки ECC памяти), события OOM (Out of Memory) killer, изменения состояния сетевых интерфейсов и события загрузки модулей ядра — всё это отображается здесь. Это первый лог для проверки, когда сервер перестаёт отвечать или неожиданно перезагружается.

Проверить события OOM killer (сервер незаметно завершает процессы из-за исчерпания памяти):

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

Проверить ошибки дискового ввода-вывода, которые могут указывать на сбой диска:

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-адресов, что нарушает паттерн извлечения IP с помощью awk выше. Проверьте настройку 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-хостинге или выделенном сервере — полагаться на ручную проверку логов недостаточно в масштабе. Реализуйте один из следующих подходов:

Агрегация логов с пересылкой rsyslog: Настройте /etc/rsyslog.conf для пересылки логов на централизованный syslog-сервер или платформу SIEM. Это сохраняет логи даже в случае компрометации самого сервера.

ELK Stack (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 — Определить идентификаторы сообщений 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, получает уникальный идентификатор, видимый в /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.