From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on sa.int.altlinux.org X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=AWL,BAYES_00,TVD_SPACE_RATIO autolearn=no version=3.2.3 X-Virus-Scanned: amavisd-new at localhost Message-ID: <483AA154.2020708@mmascience.ru> Date: Mon, 26 May 2008 15:39:00 +0400 From: =?UTF-8?B?0JLQu9Cw0LTQuNC80LjRgA==?= User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: sysadmins@lists.altlinux.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: [Sysadmins] postfix: smtpd_helo_restrictions bug ??? X-BeenThere: sysadmins@lists.altlinux.org X-Mailman-Version: 2.1.10b3 Precedence: list Reply-To: ALT Linux sysadmin discuss List-Id: ALT Linux sysadmin discuss List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2008 11:38:52 -0000 Archived-At: List-Archive: Здравствуйте. Некоторое время наблюдаю по журналу одну закономерность, каким образом спамерам удается преодолеть, казалось бы, плотно закрытую дверь. Интересует, есть ли что нибудь подобное у других и существуют ли штатные способы прикрыть дырку. Закономерность следующая. Если спамер выдерживает достаточно большой 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= to= 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=, 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= 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] -> , 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