В сети обнаружен новый вид троянского ПО, предназначенного для рассылки спама. Главное отличие от предыдущих реализаций - возможность рассылки спама через почтовый сервер интернет-провайдера, клиентом которого является владелец зараженной машины.Антиспамерские организации зафиксировали резкий всплеск спама, исходящего от крупных ISP. Бороться с такими рассылками, можно только через контекстную фильтрацию, черные и серые списки, в данной ситуации полностью теряют актуальность.
Аналитики прогнозируют, что объем спама в этом году вырастет до 95%. В конце января увеличение объема спам рассылок пользователи могли ощутить невооруженным глазом. За несколько недель его объем вырос на 40% и достиг рекорда - 90% от общего объема почты.
Выход видится в введении провайдерами обязательной SMTP аутентификации и ограничений на число передаваемых от пользователя писем в единицу времени. Например, для postfix, реализация "rate-limit" для отдельных IP (anvil (http://www.postfix.org/anvil.8.html) в postfix 2.1) имеет статус экспериментальной подсистемы не рекомендована для "production" применения.URL: http://zdnet.ru/?ID=475141
Новость: http://www.opennet.me/opennews/art.shtml?num=5023
В конфигурациях с 2-мя и более MX'ами anvil(8) не может работать вообще. Для postfix 2.x такие ограничения лучше делать через check_policy_service.
Точно, уже готовый сервер check_policy_service выпустили:
http://opennix.com/email/postfix/policy/ratelimit.html
Беру свои слова обратно, по той ссылке абсолютно несерьезная система, на каждый запрос дергающая MySQL.
Есть ли нормальные готовые решения для check_policy_service ?Стоит ли смотреть на policyd (http://archives.neohapsis.com/archives/postfix/2004-12/0867....)
>Беру свои слова обратно, по той ссылке абсолютно несерьезная система, на каждый
>запрос дергающая MySQL.
>Есть ли нормальные готовые решения для check_policy_service ?
У нас свой - проприетарный :(
Посмотрите это: http://archives.neohapsis.com/archives/postfix/2004-12/att-0...
>Посмотрите это: http://archives.neohapsis.com/archives/postfix/2004-12/att-0...Посмотрел. Тоже, только на Си. Дергать СУБД на каждое письмо и держать специально для этого MySQL, не решение.
Где-то валяется самописная perl библиотека для rate-limit'ов в CGI скриптах, использующая для работы файлы флажки/очереди. Если приспичит, думаю можно написать плагин к amavisd-new.
>Посмотрел. Тоже, только на Си. Дергать СУБД на каждое письмо и держать
>специально для этого MySQL, не решение.
Т.е. хочется обойтись только кэшем?
не вижу ничего страшного в этом. сколько у тебя тысяч в день писем?
>не вижу ничего страшного в этом. сколько у тебя тысяч в день
>писем?
Вы меня или Максима спрашиваете?
Максима :)
>не вижу ничего страшного в этом. сколько у тебя тысяч в день
>писем?Вчера было тысяч 300, на первом попоавшемся под руку релее :-)
Но дело не в этом, приход спама идет волнами, в пике сколько дашь - столько сожрут, к более сотни одновременным сесииям в момент рассылки спама я уже привык. Использовать для этого MySQL как стрелять из пушки по воробъям.
Что будет с вашей машиной при 150 висящих MySQL, главное сколько при этом потребуется памяти :-)PS. Уже третий день наблюдаю как спамерские трояны по тупому перебирают адреса в одном домене, такие переборы дают прибавку в пару сотен Мб к размеру лога в день. Самое пакостное, что бороться с этим DDoS невозмонжно, адреса у каждого запроса разные :-(
>Вчера было тысяч 300, на первом попоавшемся под руку релее :-)
>Но дело не в этом, приход спама идет волнами, в пике сколько
>дашь - столько сожрут, к более сотни одновременным сесииям в момент
>рассылки спама я уже привык. Использовать для этого MySQL как стрелять
>из пушки по воробъям.
Это все чудесно, но речь то о лимитах для своих клиентов.>Что будет с вашей машиной при 150 висящих MySQL, главное сколько
>при этом потребуется памяти :-)
Ни чего страшного. Для postfix это будет легче чем скажем cidr или hash.
>Это все чудесно, но речь то о лимитах для своих клиентов.А что, свои клиенты массой подхватив вирус не могут обеспечить такую нагрузку ?
>>Что будет с вашей машиной при 150 висящих MySQL, главное сколько
>>при этом потребуется памяти :-)
>Ни чего страшного. Для postfix это будет легче чем скажем cidr или
>hash.Для postfix, но не для MySQL с разросшейся таблицей IP'шек. Пусть даже он будет держать целикиком ее в памяти - нагрузка от него будет горяздо больше, чем от postfix на том почтовом сервере. Итого имеем необходимость использовать монстра, из-за нежелания потратить пару часов на написание оптимального кода. Там где очень много параллельных update/insert MySQL дохнет и затыкается на локах.
>>Это все чудесно, но речь то о лимитах для своих клиентов.
>
>А что, свои клиенты массой подхватив вирус не могут обеспечить такую нагрузку
>?
Могут конечно, но я говорю это к тому, что выставив лимиты только для своих мы резко снижаем общее количество запросов.Давайте я расскажу как сделано у нас:
Лимиты на сессию только для "своих", история конектов за 5 минут держится только в памяти, остальное в postgres. Работает на отдельной машине, обслуживает 3 MX-а.
>Давайте я расскажу как сделано у нас:
>Лимиты на сессию только для "своих", история конектов за 5 минут держится,
>остальное в postgresВот 5-и минутное агрегирование и сглаживает нагрузку на базу. Подозреваю, что в базу у вас больше для аккаунтинга данные пишутся, чем для лимитирования.
Я пока шел домой, решил если приспичит, делать старым проверенным способом:
простой скрипт, обособленно от postfix, периодически (cron) или постоянно (демон) следящий за хвостом лога и при превышении заложенных лимитов, добавляющего клиента во временный блэклист, в котором он будет висеть до того как истечет таймаут. Мгновенное реагирование по сути не требуется, блокирование в течении минуты после превышения вполне приемлимо.
>простой скрипт, обособленно от postfix, периодически (cron) или постоянно (демон) следящий за
>хвостом лога и при превышении заложенных лимитов, добавляющего клиента во временный
>блэклист, в котором он будет висеть до того как истечет таймаут.
Что-то я вас не понимаю... Вы считаете, что парсить лог дешевле, чем тем же самым скриптом/демоном получать IP на блюдечке от postfix через smtpd_*_restrictions???
>Что-то я вас не понимаю... Вы считаете, что парсить лог дешевле, чем
>тем же самым скриптом/демоном получать IP на блюдечке от postfix через
>smtpd_*_restrictions???Думаю нет особой разницы парсить скриптом запрос postfix'а или записи в логе (записи в логе парсятся очень быстро, за минуту можно десять раз лог за день пропарсить не говоря о минутной выборке). Но лог обрабатывается линейно одним процессом никаким образом не влияя на надежность подсистемы postfix, и позволяет не вешать cкрипт/демон привязанный к postfix, не добавляя лишнее звено в критичную систему.
Если смотреть на пики, то в момент единовременного наплыва запросов postfix+демон может захлебнуться. Анализатор лога работает блочно, не проверяет лимиты на каждый запрос, а вначале суммирует данные за небольшой период, а уже потом оценивает состояние (т.е. на 100 запросов с одного IP в минуту будет сделана одна проверка, а для postfix+демона - 100).
К томуже у меня уже работает подобный парсер лога (мониторинг) к которому привернуть лишнюю проверку не так трудно.
>Если смотреть на пики, то в момент единовременного наплыва запросов
>postfix+демон может захлебнуться.
Нет. Дальше лимита выставленного в master.cf дело просто не пойдет.>а вначале суммирует данные за небольшой период, а уже потом оценивает
>состояние (т.е. на 100 запросов с одного IP в минуту будет
>сделана одна проверка, а для postfix+демона - 100).
Вот что у вас получается:
1. парсер лога
2. перестроение таблицы
3. Те же 100 запросов - ведь должен же postfix смотреть блэк лист
И вы хотите сказать, что это дешевле...
>К томуже у меня уже работает подобный парсер лога (мониторинг) к которому
>привернуть лишнюю проверку не так трудно.
Так и говорите: "Мне так проще"
>>Если смотреть на пики, то в момент единовременного наплыва запросов
>>postfix+демон может захлебнуться.
>Нет. Дальше лимита выставленного в master.cf дело просто не пойдет.Если лимит будет значительно меньше чем у smtpd, то в пике будет простой запросов и рост очереди smtpd.
>>а вначале суммирует данные за небольшой период, а уже потом оценивает
>>состояние (т.е. на 100 запросов с одного IP в минуту будет
>>сделана одна проверка, а для postfix+демона - 100).>Вот что у вас получается:
>1. парсер лога
>2. перестроение таблицы
>3. Те же 100 запросов - ведь должен же postfix смотреть блэк
>лист
>И вы хотите сказать, что это дешевле...Парсер лога (1) не самое ресурсоемкое звено, агрегирование на этапе парсинга существенно сокращает число перестроений таблиц (2). Смотрением постфикса в хэш (3) можно пренебречь, задержка на лукапах пренебрежима мала по сравнению с другими операциями. Тем более что hash лукапы кешируются.
>Если лимит будет значительно меньше чем у smtpd, то в пике будет
>простой запросов и рост очереди smtpd.
Давайте считать, то что система настроена, иначе разговор не имеет смысла.>Парсер лога (1) не самое ресурсоемкое звено, агрегирование на этапе
>парсинга существенно
>сокращает число перестроений таблиц (2).
В этой схеме все упирается в действительное количество перестроений таблицы,
в пике вам придется делать это раз в минуту - это слишком часто для hash.>Тем более что hash лукапы кешируются.
Можно нарваться на max_use...Кстати, а что делать будете если клиент в 1 сессию отправит 1K писем и каждое на 10bcc?
>В этой схеме все упирается в действительное количество перестроений таблицы,
>в пике вам придется делать это раз в минуту - это слишком
>часто для hash.В том то и дело, что результирующий хэш в 99% случаев (когда нет флуда) будет пустым и трогать еге не будет необходимости. Когда есть флуд, хэш не будет пустым, но список будет неизменен. Итого трогаем файл с хэшем только когда появляется или исчезает новый флудер.
>Кстати, а что делать будете если клиент в 1 сессию отправит 1K
>писем и каждое на 10bcc?За минуту не отправит, между письмами в потоке идет задержка и лимитируется число писем в рамках одной сессии.
>В том то и дело, что результирующий хэш в 99% случаев (когда
>нет флуда) будет пустым и трогать еге не будет необходимости. Когда
>есть флуд, хэш не будет пустым, но список будет неизменен. Итого
>трогаем файл с хэшем только когда появляется или исчезает новый флудер.
Вас интересуют не лимиты для клиентов, а только борьба со флудом.
Мне же нужно лимитировать не только число сессий, но и количество писем в единицу времени.>>Кстати, а что делать будете если клиент в 1 сессию отправит 1K
>>писем и каждое на 10bcc?
>За минуту не отправит, между письмами в потоке идет задержка и лимитируется
>число писем в рамках одной сессии.
1K было просто для примера (как дефолт postfix)
А что за задержка?
Вы сново скажите, что парсить лог для отлова таких ситуаций дешевле чем повесить хук на smtpd_*_restrictions?
>Вчера было тысяч 300, на первом попоавшемся под руку релее :-)
>Но дело не в этом, приход спама идет волнами, в пике сколько
>дашь - столько сожрут, к более сотни одновременным сесииям в момент
>рассылки спама я уже привык. Использовать для этого MySQL как стрелять
>из пушки по воробъям.
>Что будет с вашей машиной при 150 висящих MySQL, главное сколько
>при этом потребуется памяти :-)Да.... у меня 2000-3000 в день в обе стороны. MySQL справиться я так думаю :) Если объемы будут расти, то поставлю postgre или буду искать более быстрое решение без использования СУБД.
А как в CGP поставить лимит на кол-во сообщений с одного IP?
Это через админ интерфейс
SMTP->Receiving->Limits
Non-Client Sender: Limited to:2 per: 30 seconds
Помойму так!
может эффективнее было бы заодно и уведомлять клиента, что от него градом сыпется спам, т.е. приймите меры, т.к. спам-агент еще кроме первичной задачи ворует частную информацию, удаляет у вас все с диска Ж:, шкрябает сидюки, ламает колесико в мышке и т.д. - поставте 20 антивирусных програм, перезапустите винду 40 раз, отформатируте винт - 20...
всех спасет принудительный smtp auth :-)
я уже давно практикую на своих почтовых серверах обязательную аутентификацию на релеях. пользователи ничего, привыкнут.
Ага, с расчетом на то, что клиент - параноик, и не хранит логин/пассворд в конфиге мейл-программы, а вводит его каждый раз ручонками. В конце концов даже при таком подходе можно доработать зебат, чтобы вместе с настоящим мылом юзверя отправлял пачку революционных листовок
Ну, в таком случае, мы будем точно знать кто это, и либо свободен, либо антитроян + антивирус в студию.
А может вместо MySQL использовать BerkeleyDB?
>А может вместо MySQL использовать BerkeleyDB?А смысл?
Ребяты, откуда вы на самом деле такого низкого мнения о mysql?я пару месяцев назад игрался с ним, и получил на _грамотно_постоенной_базе_ 200000 insert/s.
update-ов без перестроения ключей еще раз в 10 больше.
join по ключу на таблице 800000 записей отработался за 0.0004s.Аккуратнее нужно подходить к базе данных, и все у вас получится.
>я пару месяцев назад игрался с ним, и получил на _грамотно_постоенной_базе_ 200000У вас нет понимания того, что ваши синтетические тесты в реальных ситациях малопригодны. Как пример, попробуте добавить ваши 200000 в 10-100 параллельных потоков, без отложенных insert'ов. С блокировками у MySQL не все в порядке.
> update-ов без перестроения ключей еще раз в 10 больше.Апдейтов не может быть больше, так как update по сути это тот же insert.