Здравствуйте.
Некоторое время наблюдаю по журналу одну закономерность,
каким образом спамерам удается преодолеть, казалось бы, плотно
закрытую дверь. Интересует, есть ли что нибудь подобное у других и
существуют ли штатные способы прикрыть дырку.
Закономерность следующая. Если спамер выдерживает достаточно большой
timeout между соединением и передачей helo команды, то правила в
smtpd_helo_restrictions игнорируюся. Причем, если через sleep увеличить
лимит времени на прохождение правила (по умолчанию 1 сек), то отдельные
спамеры
адекватно увеличивают timeout и все равно преодолевают такой "усиленный"
барьер.
Смотрится это так.
В mail.cf (после долгой "борьбы" sleep задрал очень высоко):
smtpd_helo_required = yes
smtpd_helo_restrictions =
permit_mynetworks,
check_helo_access
cdb:/etc/postfix/helo_access,
sleep 121,
reject_non_fqdn_helo_hostname,
reject_invalid_helo_hostname,
reject_unknown_helo_hostname,
sleep 6,
check_helo_access
cdb:/etc/postfix/helo_post_access,
sleep 2,
permit
В helo_access, в частности, имеется:
ip.ukrtel.net REJECT
А теперь две "вырезки" из вчерашнего /var/log/mail/all.
Сначало как это работает "обычным порядком":
May 25 14:14:30 ns postfix/smtpd[9676]: connect from
175-123-207-82.ip.ukrtel.net[82.207.123.175]
May 25 14:14:30 ns postfix/smtpd[9676]: NOQUEUE: reject: RCPT from
175-123-207-82.ip.ukrtel.net[82.207.123.175]: 554 5.7.1
<175-123-207-82.ip.ukrtel.net>: Helo command rejected: Access denied;
from=<[EMAIL PROTECTED]> to=<[EMAIL PROTECTED]>
proto=ESMTP helo=<175-123-207-82.ip.ukrtel.net>
May 25 14:14:31 ns postfix/smtpd[9676]: lost connection after DATA from
175-123-207-82.ip.ukrtel.net[82.207.123.175]
May 25 14:14:31 ns postfix/smtpd[9676]: disconnect from
175-123-207-82.ip.ukrtel.net[82.207.123.175]
То есть все правильно. Между подключением и helo прошло меньше секунды
и 175-123-207-82.ip.ukrtel.net получил "Access denied" согласно записи в
helo_access
А теперь как это работает "необычным порядком":
May 25 08:40:42 ns postfix/smtpd[7249]: connect from
209-111-207-82.ip.ukrtel.net[82.207.111.209]
May 25 08:42:52 ns postfix/smtpd[7249]: 6D2114DCBE:
client=209-111-207-82.ip.ukrtel.net[82.207.111.209]
May 25 08:42:53 ns postfix/cleanup[7537]: 6D2114DCBE:
message-id=<[EMAIL PROTECTED]>
May 25 08:42:53 ns postfix/qmgr[26890]: 6D2114DCBE:
from=<[EMAIL PROTECTED]>, size=6059, nrcpt=1 (queue active)
May 25 08:42:53 ns postfix/smtpd[7249]: disconnect from
209-111-207-82.ip.ukrtel.net[82.207.111.209]
May 25 08:42:55 ns postfix/smtpd[7541]: connect from
test.fwd.mmascience.ru[127.0.0.1]
May 25 08:42:55 ns postfix/smtpd[7541]: D15F44DE13:
client=test.fwd.mmascience.ru[127.0.0.1]
May 25 08:42:55 ns postfix/cleanup[7537]: D15F44DE13:
message-id=<[EMAIL PROTECTED]>
May 25 08:42:56 ns postfix/smtpd[7541]: disconnect from
test.fwd.mmascience.ru[127.0.0.1]
May 25 08:42:56 ns amavis[5308]: (05308-05) Blocked SPAM,
[82.207.111.209] [202.105.182.87] <[EMAIL PROTECTED]> ->
<[EMAIL PROTECTED]>, quarantine: spam-qS84uiA61MWY.gz, Message-ID:
<[EMAIL PROTECTED]>, mail_id: qS84uiA61MWY,
Hits: 6.51, size: 6057, 2887 ms
То есть, между подключением (08:40:42) и helo (08:42:52) выдержан
timeout в 130 секунд
(больше, чем sleep) и postfix-2.4.7, вопреки записи в helo_access,
разрешил соединение для 209-111-207-82.ip.ukrtel.net
Таких примеров в журнале можно найти достаточно много, правда после
использования
sleep количество спама и нагрузка на amavis резко сократились.
Вопрос традиционный, кто виноват и что делать?
--
Vladimir Kholmanov
[EMAIL PROTECTED]
[EMAIL PROTECTED]
_______________________________________________
Sysadmins mailing list
Sysadmins@lists.altlinux.org
https://lists.altlinux.org/mailman/listinfo/sysadmins
