LINUX.ORG.RU
решено ФорумAdmin

Найти источник спама

 , ,


0

1

Есть почтовый сервер на котором периодически происходят вспышки спама. Ранее я смотрел от какой учётной записи это отправляется и блокировал её, этого было достаточно. Сейчас идёт выход спама, но когда я отключил учётную запись из поля from спам не прекратился. Более того, в логах записи о письмах с тем же значением в from. Но я не могу понять как найти кто авторизуется для отправки. Куда стоит смотреть?

★★★★★

Более того, в логах записи о письмах с тем же значением в from

из лога возьми postfix queue id и грепни по нему. первая строка будет - откуда пришло письмо. если локально, то будет указан user id, с ним уже разбирайся

router ★★★★★
()

Не знаю, как в Postfix, но в Sendmail в milter передаётся переменная «auth_authen». Далее вопрос используемого фильтра, может ли он что-то куда-то вывести. Можно в X-header добавить, например. Postfix в milter умеет, но вот в каком объёме - не знаю. В mailfromd это может выглядеть как-то так:

if macro_defined("auth_authen")
  header_add("X-authenticated", "as \"" . ${auth_authen} . "\" on host \"" . $j . "\"", 0)
fi
$j тоже MTA в milter передаёт.

AS ★★★★★
()
Ответ на: комментарий от router

Postfix queue id это BCE0881EC6?

Feb 19 07:17:18 postfix.domain.tld postfix/qmgr[30131]: BCE0881EC6: from=<user@domain.tld>, size=2560, nrcpt=1 (queue active)

Это первая строка где оно появляется.

С логами ещё такое дело что они с какого-то момента пошли в journalctl и как переключить обратно я пока не знаю (хотя может у этого и достоинства есть).

Вообще, есть хорошая новость в том что этот сервер кажется от меня уйдёт. Хотя плохая в том, что подобное может случиться не только с ним, понять всё равно хотелось бы.

sin_a ★★★★★
() автор топика
Ответ на: комментарий от sin_a

Postfix queue id это BCE0881EC6?

да

Это первая строка где оно появляется.

тогда в том же grep BCE0881EC6 будет message-id

грепни по message-id, это внутренняя извращённая кухня факингового postfix, одно письмо может пройти через него несколько раз ( типа сначала приняли и послали через milter или ещё какой фильтр, а он вернул письмо уже как новое с новым queue id )

возможно, rsyslog или systemd отбрасывают логи, когда их слишком много. Загугли, нужно эту диверсию отключить. и потом снова смотри логи

router ★★★★★
()
Ответ на: комментарий от router

systemd journald:

Oct 3 11:20:06 vm-mail journal: Suppressed 235 messages from /system.slice/postfix.service

решается так:

# grep -i rate /etc/systemd/journald.conf
RateLimitInterval=0
RateLimitBurst=0

# systemctl daemon-reload
# systemctl restart systemd-journald

rsyslog:

/etc/rsyslog.d/rate-limit.conf

$SystemLogRateLimitInterval 0
$SystemLogRateLimitBurst 0
$IMUXSockRateLimitBurst 0
$IMUXSockRateLimitInterval 0
$IMUXSockRateLimitSeverity 7

systemctl restart rsyslog

router ★★★★★
()
Последнее исправление: router (всего исправлений: 1)
Ответ на: комментарий от router

Вижу только qmgr, но оно меняется:

Feb 19 07:17:18 postfix.domain.tld postfix/qmgr[30131]: BCE0881EC6: from=<user@domain.tld>, size=2560, nrcpt=1 (queue active)
Feb 19 07:19:18 postfix.domain.tld postfix/smtp[9153]: BCE0881EC6: to=<gkwalp37@gmail.cm>, relay=none, delay=150414, delays=150293/0.15/120/0, dsn=4.4.1, status=deferred (connect to gmail.cm[173.194.222.83]:25: Connection timed out)
Feb 19 08:27:18 postfix.domain.tld postfix/qmgr[30131]: BCE0881EC6: from=<user@domain.tld>, size=2560, nrcpt=1 (queue active)
Feb 19 08:27:40 postfix.domain.tld postfix/qmgr[13944]: BCE0881EC6: skipped, still being delivered
Feb 19 08:28:52 postfix.domain.tld postfix/qmgr[13944]: BCE0881EC6: skipped, still being delivered
Feb 19 08:29:18 postfix.domain.tld postfix/smtp[13523]: BCE0881EC6: to=<gkwalp37@gmail.cm>, relay=none, delay=154614, delays=154493/0.14/121/0, dsn=4.4.1, status=deferred (connect to gmail.cm[173.194.222.18]:25: Connection timed out)
Feb 19 08:30:10 postfix.domain.tld postfix/qmgr[13944]: BCE0881EC6: from=<user@domain.tld>, size=2560, nrcpt=1 (queue active)
Feb 19 08:32:10 postfix.domain.tld postfix/smtp[13967]: BCE0881EC6: to=<gkwalp37@gmail.cm>, relay=none, delay=154785, delays=154665/0/120/0, dsn=4.4.1, status=deferred (connect to gmail.cm[173.194.222.18]:25: Connection timed out)
Feb 19 09:42:41 postfix.domain.tld postfix/qmgr[13944]: BCE0881EC6: from=<user@domain.tld>, size=2560, nrcpt=1 (queue active)
Feb 19 09:44:42 postfix.domain.tld postfix/smtp[24703]: BCE0881EC6: to=<gkwalp37@gmail.cm>, relay=none, delay=159137, delays=159016/0.09/120/0, dsn=4.4.1, status=deferred (connect to gmail.cm[173.194.222.19]:25: Connection timed out)

возможно, rsyslog или systemd отбрасывают логи, когда их слишком много

Спасибо, это поищу.

sin_a ★★★★★
() автор топика
Ответ на: комментарий от sin_a

Feb 19 08:27:40 postfix.domain.tld postfix/qmgr[13944]: BCE0881EC6: skipped, still being delivered

есть ещё вариант, что письмо несколько дней висит в очереди и postfix время от времени поднимает его и пытается доставить

Если уверен, что journald и rsyslog не отбрасывают логи, посмотри логи за предыдущие дни по тому же queue id

router ★★★★★
()
Ответ на: комментарий от router

Это systemctl status systemd-journald ? У меня там Suppressed нет.

Вообще в /etc/systemd/journald.conf поставил ForwardToSyslog=yes но эффекта вроде не дало.

sin_a ★★★★★
() автор топика
Ответ на: комментарий от router

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

sin_a ★★★★★
() автор топика
Ответ на: комментарий от sin_a

Хотя похоже что одна из черепашек п..реувеличивает.

CT-138 log# mailq
/var/spool/mqueue is empty
                Total requests: 0
CT-138 log# du -sh  /var/spool/postfix/
8.3G    /var/spool/postfix/
CT-138 log# 
sin_a ★★★★★
() автор топика
Ответ на: комментарий от sin_a

Это systemctl status systemd-journald ? У меня там Suppressed нет.

egrep -i ‘(suppress|limit)’ /var/log/messages /var/log/syslog

в debian syslog, в rhel messages

router ★★★★★
()
Ответ на: комментарий от router

В /var/log весь набор из /etc/logrotate.d/syslog пуст. А в systemctl status rsyslogd есть подозрительное:

rsyslogd[31153]: sd_journal_get_cursor() failed: 'Cannot assign requested address'  [v8.24.0-34.el7]

Хотя это какой-то старый баг: https://bugzilla.redhat.com/show_bug.cgi?id=1615014

sin_a ★★★★★
() автор топика
Ответ на: комментарий от sin_a

я бы сказал, что хост скомпрометирован

Если есть возможность, отложи дамп диска за угол ( для последующего изучения ) и заменяй почтовый сервер на новый

router ★★★★★
()
Ответ на: комментарий от router

Спасибо, похоже на это.

sin_a ★★★★★
() автор топика
Ответ на: комментарий от sin_a

С логами ещё такое дело что они с какого-то момента пошли в journalctl и как переключить обратно я пока не знаю

Это не сложно. В journald.conf написать ForwardToSyslog=yes, поставить и настроить какой-нибудь syslog с учётом https://lists.freedesktop.org/archives/systemd-devel/2012-January/004188.html

AS ★★★★★
()
Ответ на: комментарий от sin_a

Вообще в /etc/systemd/journald.conf поставил ForwardToSyslog=yes но эффекта вроде не дало.

Вот из предыдущего сообщения моего ссылку глянь. Там несовсем туда форвард, куда надо. Что ещё от systemd ждать-то... В общем работать-то оно должно.

AS ★★★★★
()
Ответ на: комментарий от AS

Это параметр стоял закомментированным и вероятно такой (yes) по умолчанию. И запись в системные логи шла, работает rsyslogd. Это CentOS, там логами пренебрегают редко. Но с некоторого момента они пусты. В общем склоняюсь что предыдущий вердикт отражает.

sin_a ★★★★★
() автор топика
Последнее исправление: sin_a (всего исправлений: 1)
Ответ на: комментарий от sin_a

И запись в системные логи шла, работает rsyslogd

Знаю, что syslog-ng с какой-то из уже не очень свежих версий сам умеет как-то из journal логи выгребать, вне зависимости от ForwardToSyslog=yes. Вероятно и rsyslogd обучили. Тогда да, отсутствие странно.

AS ★★★★★
()
Ответ на: комментарий от AS

Всё таки размещение веб интерфейса к почте на том же хосте было легкомысленным решением…

sin_a ★★★★★
() автор топика

Может проще почитать заголовки спамерского письма?

/etc/postfix/sender_bcc

spamer@mydomen.ru  postmaster@mydomen.ru

Bootmen ☆☆☆
()
Ответ на: комментарий от Bootmen

На будущее, может быть. Здесь всё понятно, всё заменить.

sin_a ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.