[Sysadmins] postfix: smtpd_helo_restrictions bug ???

[Sysadmins] postfix: smtpd_helo_restrictions bug ???

[Владимир]

Здравствуйте.

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

Закономерность следующая. Если спамер выдерживает достаточно большой
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=<yael94yu_ti@abnamrocraigs.com> to=<admin@mmascience.ru> 
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=<20080525044252.6D2114DCBE@smtp.mmascience.ru>
May 25 08:42:53 ns postfix/qmgr[26890]: 6D2114DCBE: 
from=<vitiali@deep2000.ru>, 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=<SSqS84uiA61MWY@ns.cafedra.ru>
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] <vitiali@deep2000.ru> -> 
<fmfm@mmascience.ru>, quarantine: spam-qS84uiA61MWY.gz, Message-ID: 
<20080525044252.6D2114DCBE@smtp.mmascience.ru>, 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
fmfm@mmascience.ru
fmfm@mma.ru

Re: [Sysadmins] postfix: smtpd_helo_restrictions bug ???

[MadAdmin]

В сообщении от Monday 26 May 2008 15:39:00 Владимир написал(а):
<skip>
> Вопрос традиционный, кто виноват и что делать?
Под рукой нет the book of postfix, но сколько помнится  разница в том куда 
проверки помещать есть ровно в том на каком этапе диалога с клиентом эти 
проверки выполняются. Т.е. если проверять после того как helo уже было...
Если перенести проверки в smtpd_recipient_restrictions - что получается?

Re: [Sysadmins] postfix: smtpd_helo_restrictions bug ???

[Владимир]

MadAdmin пишет:
> В сообщении от Monday 26 May 2008 15:39:00 Владимир написал(а):
> <skip>
>   
>> Вопрос традиционный, кто виноват и что делать?
>>     
> Под рукой нет the book of postfix, но сколько помнится  разница в том куда 
> проверки помещать есть ровно в том на каком этапе диалога с клиентом эти 
> проверки выполняются. Т.е. если проверять после того как helo уже было...
> Если перенести проверки в smtpd_recipient_restrictions - что получается?
>
>   

В документации написано, какие правила в каких цепочках используются и
иное, даже если сработает, будет "недокументированной возможностью",
которая при любом upgrade может исчезнуть.
Во-вторых, "перегружать" smtpd_recipient_restrictions, которые являются
ключем к openrelay?.. Даже пробовать не буду.
В-третьих, это не та проблема, чтобы "пробовать" иные варианты.
Спама - мизер, уже при том что есть. Но есть желание и
это перекрыть, если кто то может поделится проверенным
и работающим вариантом.


-- 
Vladimir Kholmanov
fmfm@mmascience.ru
fmfm@mma.ru

Re: [Sysadmins] postfix: smtpd_helo_restrictions bug ???

[Vladimir V. Kamarzin]

>>>>> On 26 May 2008 at 17:39 "f" == fmfm  writes:

f> А теперь как это работает "необычным порядком":

f> May 25 08:40:42 ns postfix/smtpd[7249]: connect from
f> 209-111-207-82.ip.ukrtel.net[82.207.111.209]
f> May 25 08:42:52 ns postfix/smtpd[7249]: 6D2114DCBE:
f> client=209-111-207-82.ip.ukrtel.net[82.207.111.209]
f> May 25 08:42:53 ns postfix/cleanup[7537]: 6D2114DCBE:
f> message-id=<20080525044252.6D2114DCBE@smtp.mmascience.ru>

f> То есть, между подключением (08:40:42) и helo (08:42:52) выдержан
f> timeout в 130 секунд

Нет, это промежуток времени между коннектом и посылкой RCPT TO
(включительно). Следующая стадия - завершение DATA - присвоено
message-id=<20080525044252.6D2114DCBE@smtp.mmascience.ru>.

f> (больше, чем sleep) и postfix-2.4.7, вопреки записи в helo_access,
f> разрешил соединение для 209-111-207-82.ip.ukrtel.net

Очень странно.

f> Вопрос традиционный, кто виноват и что делать?

Из предоставленных данных нельзя однозначно сказать, почему у вас так
происходит. Изучите DEBUG_README, воспользуйтесь debug_peer_list, смотрите в
лог.

-- 
vvk

Postfix page on f.i: http://freesource.info/wiki/Dokumentacija/Postfix

Russian Postfix irc: irc.freenode.net #postfix-ru