Перейти к содержанию

Logwatch

Привет! Я пробежался по отчёту logwatch за 2026-Feb-15 (detail level = 10) и вот что реально заслуживает внимания, а что можно смело “укоротить” в ежедневной рассылке.

На что обратить внимание (важное)

1) Массовые попытки подбора паролей к почте (Dovecot/Postfix)

  • Dovecot auth failures: очень много неуспешных логинов по типовым именам (oracle, root, admin, sales, test, …) и куча “Unknown Account”.

  • Postfix: 620 SASL authentication failed с нескольких IP (например 45.144.212.70, 77.83.39.121, 77.83.39.164, 77.83.39.50, плюс ещё).
    Это выглядит как типичный bruteforce по SMTP AUTH/IMAP/POP. Даже если пароли не подбирают — шум и риск блокировок/нагрузки.

Что бы я сделал:

  • включил/проверил fail2ban для dovecot и postfix (sasl) + бан по повторяющимся попыткам;

  • убедился, что SMTP AUTH доступен только там, где нужно (например, ограничение по сетям/VPN, если это применимо);

  • проверил, что нет “слабых”/тестовых ящиков и что политики паролей адекватные.

2) Ошибки Dovecot: “auth client … disconnected … Connection reset by peer”

48 раз за сутки.
Часто это сопутствует bruteforce/сканерам или проблемам с backend’ом аутентификации/сокетами. На фоне 620 SASL fails — похоже на входящие попытки, которые рвутся.

3) Apache: попытки эксплуатации/сканирование + странный mod_proxy

  • “Attempts to use known hacks” (path traversal ../../..) от 4 хостов.

  • Много 404 на типовые уязвимости (/.env, /.git/config, phpunit eval-stdin.php, и т.п.).
    Это нормально для публичного сервера — постоянный фон сканеров.

  • Но отдельно выделяется: “Connection attempts using mod_proxy: 130.12.180.52 -> api.ipify.org:443: 8 Time(s)” + 405 на api.ipify.org:443.
    Вот это стоит проверить: похоже, кто-то пытается использовать ваш сервер как прокси (или у вас реально есть endpoint, который проксирует наружу). Если у вас не должно быть forward-proxy, проверь конфиг ProxyRequests, mod_proxy правила, и запрети всё лишнее.

4) PHP warning/deprecated в /var/www/e2/system/core.php

Undefined array key "HTTP_HOST" и deprecated explode(null, …) — 2 раза.
Это не критично само по себе, но:

  • может всплывать из-за мусорных запросов (без Host header);

  • если это ваше приложение — лучше поправить обработку HTTP_HOST/null.

5) lm_sensors: подозрительные ALARM и “температуры” 127.5°C/114°C/108°C

В блоке датчиков видно CPUTIN 127.5°C ALARM, AUXTIN1/2 >100°C, плюс intrusion1: ALARM.
При этом coretemp показывает нормальные ~49°C по CPU package/cores.
Очень похоже на криво читаемые/неподдерживаемые датчики (типично для некоторых плат/чипов) или неверные пороги.

Что сделать:

  • сверить показания с sensors -u и/или BIOS/ILO, посмотреть, стабильно ли “127.5” (часто это “невалидное значение”);

  • если это мусор — можно исключить lm_sensors из logwatch или настроить игнор алертов (чтобы не зашумлять отчёт);

  • intrusion1 ALARM часто означает “открыта крышка”/нет датчика — тоже может быть ложным.

Что выглядит нормально (не тревожит само по себе)

  • RAID /dev/md0 : clean (OK).

  • Диски по месту: / 9%, /mnt/storage 45%, /mnt/raid 46% — запас хороший.

  • Cron/nextcloud cron.php много раз — похоже на ожидаемую периодику (если у вас так настроено).

  • HTTP роботы/краулеры — стандартно.

Стоит ли “укоротить” ежедневный logwatch? Да — сейчас слишком подробно

Сейчас у тебя Detail Level: 10 — из-за этого:

  • огромный список 404/сканов;

  • многословная детализация SASL фейлов по каждому логину/IP.

Практичный вариант настроек “короче, но информативно”

  1. Понизить детализацию до 5–6

  2. В большинстве случаев дневной отчёт станет в разы короче, но сохранит “сводки” и топовые события.

Пример запуска:

logwatch --detail 6 --range yesterday --service all --output mail
  1. Оставить в ежедневном отчёте только ключевые сервисы
    Тебе важны: httpd, sshd (если есть), dovecot, postfix, cron, disk space, mdadm.
    Остальное можно выключить/уменьшить.

Пример:

logwatch --detail 6 --range yesterday \
  --service http --service postfix --service dovecot --service sshd \
  --service cron --service disk --service mdadm \
  --output mail

  1. Вынести “шумные” вещи в отдельный (weekly) отчёт

  2. Например, httpd на detail 10 раз в неделю, а ежедневно — только summary.

  3. То же самое для больших списков 404/ботов.

  4. Смысловая фильтрация
    Если хочешь реально полезный ежедневный сигнал:

  5. оставь только 4xx/5xx “топы”, а не сотни уникальных URL (особенно phpunit, /.env, /.git и т.п.);

  6. оставь агрегацию по IP (топ атакующих), а не простыню.

Мой итог по твоему отчёту

Главные “красные флаги” тут:

  • bruteforce на почтовые сервисы (Dovecot/Postfix SASL)

  • попытки использовать mod_proxy / проксирование наружу к api.ipify.org

  • “сенсоры” с ALARM (скорее всего ложные, но стоит подтвердить)

Если хочешь, я могу предложить конкретный шаблон для /etc/logwatch/conf/logwatch.conf (daily vs weekly) под твой набор сервисов и чтобы “атаки” были в виде короткой сводки (топ IP/топ событий), а не простынёй.