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), зміни стану мережевого інтерфейсу та події завантаження модулів ядра — усе це відображається тут. Це перший журнал для перевірки, коли сервер стає недоступним або несподівано перезавантажується.

Перевірити події вбивці OOM (сервер тихо вбиває процеси через вичерпання пам’яті):

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

Агрегація журналів із пересиланням 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.