https://www.opennet.ru/openforum/vsluhforumID3/58151.html Администраторы больших сетей регулярно получают жалобы на исходящий из них спам. Получив жалобу, <br>можно найти виновного и устранить проблему. Но нехорошо узнавать о таких делах только от чужих людей. <br>Спамеров вполне можно вычислить самому, и принять меры раньше, чем кто-то пострадает.<br><br>Чисто интуитивно достаточно запустить tcpdump на исходящем канале, и посмотреть, какие IP-адреса больше в<br>сего посылают SYN-пакетов на 25 порт.<br><br> tcpdump -ni bridge0 'tcp[tcpflags] & tcp-syn != 0 and dst port 25'<br><br>В идеале это был бы ваш SMTP-сервер. В действительности вы увидите в основном IP-адреса простых пользователей, <br>"одержимых бесами". Дело в том, что обычный спамбот создает SMTP-соединений во много раз больше <br>вашего почтового сервера. Причем с разными IP-адресами.<br><br>В наши дни все нормальные почтовые сервера имеют PTR-запись DNS. Простые клиенты, напротив, <br>такой записи обычно не имеют. Если почтовый сервер может устанавливать SMTP-соединения <br>со множеством IP-адресов, то для простого клиента эта велич https://www.opennet.ru/openforum/vsluhforumID3/58151.html#41 Mon, 16 Jan 2012 11:53:02 GMT #Время записи в журнал<br>client_connection_status_update_time = 5m<br># Задаём промежуток времени, на который будем опираться, тут - 10 минут<br>anvil_rate_time_unit =600s<br># Кол-во получателей для одного авторизованного пользователя в установленный промежуток времени <br>#(или сколько можно указать RCPT TO для одного авторизованного клиента вне зависимости от кол-ва соединений/сессий).<br>smtpd_client_recipient_rate_limit=200<br># Кол-во соединений для одного ip адреса. При переборе соединений, пользователь получит отказ в соединении с <br># ошибкой "Too many connections from ip". Параметр может иметь исключения, задаваемые параметром smtpd_client_event_limit_exceptions (по умолчанию равен $mynetworks)<br>smtpd_client_connection_rate_limit=200<br># Кол-во отправленных писем авторизованным клиентом вне зависимости от кол-ва сессий (были ли отправки за одну сессию или за несколько). <br>#При переборе параметра, клиент получит ошибку "Too many messages".<br>smtpd_client_message_rate_limit=200<br># Исключения<br>smtpd_client_event_limit https://www.opennet.ru/openforum/vsluhforumID3/58151.html#40 Thu, 03 Sep 2009 07:32:04 GMT То же самое, только чуть короче :)<br>http://sources.homelink.ru/spamblock/<br> https://www.opennet.ru/openforum/vsluhforumID3/58151.html#39 Wed, 26 Aug 2009 21:03:21 GMT &gt;Скажим так expiretable - это расширение к pf, как ipset расширение к iptables. :)<br><br>Если уж быть строгим и занудным до конца, то и iptables, и ipset - это всего лишь интерфейсы к netfilter, как pfctl - интерфейс к pf :)<br> https://www.opennet.ru/openforum/vsluhforumID3/58151.html#38 Wed, 26 Aug 2009 20:25:01 GMT Скрипт, думаю, будет полезен.<br>Он хорошо подходит, когда нужно оповещать пользователя о том, что с него сыплется спам.<br><br>Могу посоветовать прикрутить к нему отправлялку писем пользователям.<br>Типа "Это автоматическое сообщение - у вас на компе вирус. Можете скачать антивирус с нашего фтп (ссылка), обновить его бесплатно с нашего фтп (ссылка)."<br>Ещё можно ссылку на пошаговое описание, как что делать.<br>А описание в картинках)<br>Думаю, это может ещё больше уменьшить звонки в суппорт.<br><br>Ещё могу посоветовать анализировать dns запросы типа MX - они тоже обычно генерятся именно спамописателями.<br>Вылавливать такие запросы тоже можно с помощью tcpdump.<br><br>Ещё в свое время заметил, что размер "окна" (параметр такой в ip или tcp заголовке) у спамописем равен 24000.<br>Помнится, даже после долгого наблюдения не заметил ничего другого, кроме спама, с таким окном.<br>Но это уже не так однозначно.<br><br>А ещё могу посоветовать:<br>ipfw add 1 skipto 4 tcp from table(x) to not me 25<br>ipfw add 2 skipto 4 tcp from any to not me 25 limi https://www.opennet.ru/openforum/vsluhforumID3/58151.html#37 Wed, 26 Aug 2009 12:46:10 GMT &gt;Мой друг, это же классика :) <br><br>Естественно. :)<br>И применимая в текущей задаче.<br><br>&gt;Кстати, в отношении таймаутов ipset немного удобнее таблиц pf - не нужно <br>&gt;прикручивать всякие expiretable, механизм таймаутов реализован нативно: <br>&gt;ipset -N spambots iptree --timeout 79200 <br>&gt;Так записи будут автоматически удаляться через 22 часа. <br>&gt;Причем таймаут хранится для каждой записи отдельно. <br><br>Так и в pf таймауты в таблице выставляются для каждой записи индивидуально. expiretable нужно вызывать только для очистки устаревших записей. Конечно, хотелось бы обходиться без него.<br>Скажим так expiretable - это расширение к pf, как ipset расширение к iptables. :)<br> https://www.opennet.ru/openforum/vsluhforumID3/58151.html#36 Wed, 26 Aug 2009 11:52:11 GMT &gt;Я бы предложил анализировать коннтраки с ASSURED на 25 порту. <br><br>Кстати вопрос: ctstatus анализирует все подключения или только related по conntrack?<br> https://www.opennet.ru/openforum/vsluhforumID3/58151.html#35 Wed, 26 Aug 2009 11:47:49 GMT &gt;Так записи будут автоматически удаляться через 22 часа. <br><br>Причем таймаут хранится для каждой записи отдельно.<br> https://www.opennet.ru/openforum/vsluhforumID3/58151.html#34 Wed, 26 Aug 2009 11:46:21 GMT &gt;у меня на шеле в 5 строк влезло. <br><br>У меня на iptables 3-4. У товарища выше на pf - 3. Что вы там так длинно пишете? ;)<br> https://www.opennet.ru/openforum/vsluhforumID3/58151.html#33 Wed, 26 Aug 2009 11:44:17 GMT &gt;НЕ работают "три-четыре строчки на iptables и pf". НЕ работают.<br><br>Полагаю, проблема не у "iptables и pf", а у вас. Где-то в области /dev/hands либо /dev/brain. Возможно, обусловлено ошибками при сборке ДНК :)<br>