[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