URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 5077
[ Назад ]

Исходное сообщение
"OpenNews: Спамерский софт научился рассылать спам через сервер провайдера"

Отправлено opennews , 03-Фев-05 13:23 
В сети обнаружен новый вид троянского ПО, предназначенного для рассылки спама. Главное отличие от предыдущих реализаций - возможность рассылки спама через почтовый сервер интернет-провайдера, клиентом которого является владелец зараженной машины.

Антиспамерские организации зафиксировали резкий всплеск спама, исходящего от крупных 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


Содержание

Сообщения в этом обсуждении
"Спамерский софт научился рассылать спам через сервер провайдера"
Отправлено unk , 03-Фев-05 13:23 
В конфигурациях с 2-мя и более MX'ами anvil(8) не может работать вообще. Для postfix 2.x такие ограничения лучше делать через check_policy_service.

"Спамерский софт научился рассылать спам через сервер провайд..."
Отправлено Maxim Chirkov , 03-Фев-05 13:50 
Точно, уже готовый сервер check_policy_service выпустили:
http://opennix.com/email/postfix/policy/ratelimit.html

"Спамерский софт научился рассылать спам через сервер провайд..."
Отправлено Maxim Chirkov , 03-Фев-05 13:57 
Беру свои слова обратно, по той ссылке абсолютно несерьезная система, на каждый запрос дергающая MySQL.
Есть ли нормальные готовые решения для  check_policy_service ?

Стоит ли смотреть на policyd (http://archives.neohapsis.com/archives/postfix/2004-12/0867....)


"Спамерский софт научился рассылать спам через сервер провайд..."
Отправлено unk , 03-Фев-05 13:58 
>Беру свои слова обратно, по той ссылке абсолютно несерьезная система, на каждый
>запрос дергающая MySQL.
>Есть ли нормальные готовые решения для  check_policy_service ?
У нас свой - проприетарный :(
Посмотрите это: http://archives.neohapsis.com/archives/postfix/2004-12/att-0...


"Спамерский софт научился рассылать спам через сервер провайд..."
Отправлено Maxim Chirkov , 03-Фев-05 14:10 
>Посмотрите это: http://archives.neohapsis.com/archives/postfix/2004-12/att-0...

Посмотрел. Тоже, только на Си. Дергать СУБД на каждое письмо и держать специально для этого MySQL, не решение.

Где-то валяется самописная perl библиотека для rate-limit'ов в CGI скриптах, использующая для работы файлы флажки/очереди. Если приспичит, думаю можно написать плагин к amavisd-new.


"Спамерский софт научился рассылать спам через сервер провайд..."
Отправлено unk , 03-Фев-05 14:14 
>Посмотрел. Тоже, только на Си. Дергать СУБД на каждое письмо и держать
>специально для этого MySQL, не решение.
Т.е. хочется обойтись только кэшем?


"Спамерский софт научился рассылать спам через сервер провайд..."
Отправлено vasili , 03-Фев-05 15:20 
не вижу ничего страшного в этом. сколько у тебя тысяч в день писем?

"Спамерский софт научился рассылать спам через сервер провайд..."
Отправлено unk , 03-Фев-05 15:26 
>не вижу ничего страшного в этом. сколько у тебя тысяч в день
>писем?
Вы меня или Максима спрашиваете?


"Спамерский софт научился рассылать спам через сервер провайд..."
Отправлено vasili , 03-Фев-05 16:31 
Максима :)

"Спамерский софт научился рассылать спам через сервер провайд..."
Отправлено Maxim Chirkov , 03-Фев-05 15:36 
>не вижу ничего страшного в этом. сколько у тебя тысяч в день
>писем?

Вчера было тысяч 300, на первом попоавшемся под руку релее :-)
Но дело не в этом, приход спама идет волнами, в пике сколько дашь - столько сожрут, к более сотни одновременным сесииям в момент рассылки спама я уже привык. Использовать для этого MySQL как стрелять из пушки по воробъям.
Что будет с вашей машиной при 150 висящих MySQL, главное  сколько при этом потребуется памяти :-)

PS. Уже третий день наблюдаю как спамерские трояны по тупому перебирают адреса в одном домене,  такие переборы дают прибавку в пару сотен Мб к размеру лога в день. Самое пакостное, что бороться с этим DDoS невозмонжно, адреса у каждого запроса разные :-(


"Спамерский софт научился рассылать спам через сервер провайд..."
Отправлено unk , 03-Фев-05 16:00 
>Вчера было тысяч 300, на первом попоавшемся под руку релее :-)
>Но дело не в этом, приход спама идет волнами, в пике сколько
>дашь - столько сожрут, к более сотни одновременным сесииям в момент
>рассылки спама я уже привык. Использовать для этого MySQL как стрелять
>из пушки по воробъям.
Это все чудесно, но речь то о лимитах для своих клиентов.

>Что будет с вашей машиной при 150 висящих MySQL, главное  сколько
>при этом потребуется памяти :-)
Ни чего страшного. Для postfix это будет легче чем скажем cidr или hash.


"Спамерский софт научился рассылать спам через сервер провайд..."
Отправлено Maxim Chirkov , 03-Фев-05 16:28 
>Это все чудесно, но речь то о лимитах для своих клиентов.

А что, свои клиенты массой подхватив вирус не могут обеспечить такую нагрузку ?

>>Что будет с вашей машиной при 150 висящих MySQL, главное  сколько
>>при этом потребуется памяти :-)
>Ни чего страшного. Для postfix это будет легче чем скажем cidr или
>hash.

Для postfix, но не для MySQL с разросшейся таблицей IP'шек. Пусть даже он будет держать целикиком ее в памяти - нагрузка от него будет горяздо больше, чем от postfix на том почтовом сервере. Итого имеем необходимость использовать монстра, из-за нежелания потратить пару часов на написание оптимального кода. Там где очень много параллельных update/insert MySQL дохнет и затыкается на локах.


"Спамерский софт научился рассылать спам через сервер провайд..."
Отправлено unk , 03-Фев-05 16:58 
>>Это все чудесно, но речь то о лимитах для своих клиентов.
>
>А что, свои клиенты массой подхватив вирус не могут обеспечить такую нагрузку
>?
Могут конечно, но я говорю это к тому, что выставив лимиты только для своих мы резко снижаем общее количество запросов.

Давайте я расскажу как сделано у нас:
Лимиты на сессию только для "своих", история конектов за 5 минут держится только в памяти, остальное в postgres. Работает на отдельной машине, обслуживает 3 MX-а.


"Спамерский софт научился рассылать спам через сервер провайд..."
Отправлено Maxim Chirkov , 03-Фев-05 21:13 
>Давайте я расскажу как сделано у нас:
>Лимиты на сессию только для "своих", история конектов за 5 минут держится,
>остальное в postgres

Вот 5-и минутное агрегирование и сглаживает нагрузку на базу. Подозреваю, что в базу у вас больше для аккаунтинга данные пишутся, чем для лимитирования.

Я пока шел домой, решил если приспичит, делать старым проверенным способом:
простой скрипт, обособленно от postfix, периодически (cron) или постоянно (демон) следящий за хвостом лога и при превышении заложенных лимитов, добавляющего клиента во временный блэклист, в котором он будет висеть до того как истечет таймаут. Мгновенное реагирование по сути не требуется, блокирование в течении минуты после превышения вполне приемлимо.


"Спамерский софт научился рассылать спам через сервер провайд..."
Отправлено unk , 03-Фев-05 22:00 
>простой скрипт, обособленно от postfix, периодически (cron) или постоянно (демон) следящий за
>хвостом лога и при превышении заложенных лимитов, добавляющего клиента во временный
>блэклист, в котором он будет висеть до того как истечет таймаут.
Что-то я вас не понимаю... Вы считаете, что парсить лог дешевле, чем тем же самым скриптом/демоном получать IP на блюдечке от postfix через smtpd_*_restrictions???

"Спамерский софт научился рассылать спам через сервер провайд..."
Отправлено Maxim Chirkov , 04-Фев-05 09:17 
>Что-то я вас не понимаю... Вы считаете, что парсить лог дешевле, чем
>тем же самым скриптом/демоном получать IP на блюдечке от postfix через
>smtpd_*_restrictions???

Думаю нет особой разницы парсить скриптом запрос postfix'а или записи в логе (записи в логе парсятся очень быстро, за минуту можно десять раз лог за день пропарсить не говоря о минутной выборке). Но лог обрабатывается линейно одним процессом никаким образом не влияя на надежность подсистемы postfix, и позволяет не вешать cкрипт/демон привязанный к postfix, не добавляя лишнее звено в критичную систему.

Если смотреть на пики, то в момент единовременного наплыва запросов postfix+демон может захлебнуться. Анализатор лога работает блочно, не проверяет лимиты на каждый запрос, а вначале суммирует данные за небольшой период, а уже потом оценивает состояние (т.е. на 100 запросов с одного IP в минуту будет сделана одна проверка, а для postfix+демона - 100).

К томуже у меня уже работает подобный парсер лога (мониторинг) к которому привернуть лишнюю проверку не так трудно.


"Спамерский софт научился рассылать спам через сервер провайд..."
Отправлено unk , 04-Фев-05 09:41 
>Если смотреть на пики, то в момент единовременного наплыва запросов
>postfix+демон может захлебнуться.
Нет. Дальше лимита выставленного в master.cf дело просто не пойдет.

>а вначале суммирует данные за небольшой период, а уже потом оценивает
>состояние (т.е. на 100 запросов с одного IP в минуту будет
>сделана одна проверка, а для postfix+демона - 100).
Вот что у вас получается:
1. парсер лога
2. перестроение таблицы
3. Те же 100 запросов - ведь должен же postfix смотреть блэк лист
И вы хотите сказать, что это дешевле...

>К томуже у меня уже работает подобный парсер лога (мониторинг) к которому
>привернуть лишнюю проверку не так трудно.
Так и говорите: "Мне так проще"


"Спамерский софт научился рассылать спам через сервер провайд..."
Отправлено Maxim Chirkov , 04-Фев-05 10:50 
>>Если смотреть на пики, то в момент единовременного наплыва запросов
>>postfix+демон может захлебнуться.
>Нет. Дальше лимита выставленного в master.cf дело просто не пойдет.

Если лимит будет значительно меньше чем у smtpd, то в пике будет простой запросов и рост очереди smtpd.


>>а вначале суммирует данные за небольшой период, а уже потом оценивает
>>состояние (т.е. на 100 запросов с одного IP в минуту будет
>>сделана одна проверка, а для postfix+демона - 100).

>Вот что у вас получается:
>1. парсер лога
>2. перестроение таблицы
>3. Те же 100 запросов - ведь должен же postfix смотреть блэк
>лист
>И вы хотите сказать, что это дешевле...

Парсер лога (1) не самое ресурсоемкое звено, агрегирование на этапе парсинга существенно сокращает число перестроений таблиц (2). Смотрением постфикса в хэш (3) можно пренебречь, задержка на лукапах пренебрежима мала по сравнению с другими операциями. Тем более что hash лукапы кешируются.


"Спамерский софт научился рассылать спам через сервер провайд..."
Отправлено unk , 04-Фев-05 11:24 
>Если лимит будет значительно меньше чем у smtpd, то в пике будет
>простой запросов и рост очереди smtpd.
Давайте считать, то что система настроена, иначе разговор не имеет смысла.

>Парсер лога (1) не самое ресурсоемкое звено, агрегирование на этапе
>парсинга существенно
>сокращает число перестроений таблиц (2).
В этой схеме все упирается в действительное количество перестроений таблицы,
в пике вам придется делать это раз в минуту - это слишком часто для hash.

>Тем более что hash лукапы кешируются.
Можно нарваться на max_use...

Кстати, а что делать будете если клиент в 1 сессию отправит 1K писем и каждое на 10bcc?


"Спамерский софт научился рассылать спам через сервер провайд..."
Отправлено Maxim Chirkov , 04-Фев-05 12:23 
>В этой схеме все упирается в действительное количество перестроений таблицы,
>в пике вам придется делать это раз в минуту - это слишком
>часто для hash.

В том то и дело, что результирующий хэш в 99% случаев (когда нет флуда) будет пустым и трогать еге не будет необходимости. Когда есть флуд, хэш не будет пустым, но список будет неизменен. Итого трогаем файл с хэшем только когда появляется или исчезает новый флудер.

>Кстати, а что делать будете если клиент в 1 сессию отправит 1K
>писем и каждое на 10bcc?

За минуту не отправит, между письмами в потоке идет задержка и лимитируется число писем в рамках одной сессии.



"Спамерский софт научился рассылать спам через сервер провайд..."
Отправлено unk , 04-Фев-05 13:55 
>В том то и дело, что результирующий хэш в 99% случаев (когда
>нет флуда) будет пустым и трогать еге не будет необходимости. Когда
>есть флуд, хэш не будет пустым, но список будет неизменен. Итого
>трогаем файл с хэшем только когда появляется или исчезает новый флудер.
Вас интересуют не лимиты для клиентов, а только борьба со флудом.
Мне же нужно лимитировать не только число сессий, но и количество писем в единицу времени.

>>Кстати, а что делать будете если клиент в 1 сессию отправит 1K
>>писем и каждое на 10bcc?
>За минуту не отправит, между письмами в потоке идет задержка и лимитируется
>число писем в рамках одной сессии.
1K было просто для примера (как дефолт postfix)
А что за задержка?
Вы сново скажите, что парсить лог для отлова таких ситуаций дешевле чем повесить хук на smtpd_*_restrictions?


"Спамерский софт научился рассылать спам через сервер провайд..."
Отправлено vasili , 03-Фев-05 16:38 
>Вчера было тысяч 300, на первом попоавшемся под руку релее :-)
>Но дело не в этом, приход спама идет волнами, в пике сколько
>дашь - столько сожрут, к более сотни одновременным сесииям в момент
>рассылки спама я уже привык. Использовать для этого MySQL как стрелять
>из пушки по воробъям.
>Что будет с вашей машиной при 150 висящих MySQL, главное  сколько
>при этом потребуется памяти :-)

Да.... у меня 2000-3000 в день в обе стороны. MySQL справиться я так думаю :) Если объемы будут расти, то поставлю postgre или буду искать более быстрое решение без использования СУБД.


"Спамерский софт научился рассылать спам через сервер провайдера"
Отправлено Аноним , 03-Фев-05 14:45 
А как в CGP поставить лимит на кол-во сообщений с одного IP?

"Спамерский софт научился рассылать спам через сервер провайд..."
Отправлено mira , 03-Фев-05 19:13 
Это через админ интерфейс
SMTP->Receiving->Limits
Non-Client Sender:    Limited to:2   per: 30 seconds
Помойму так!

"Спамерский софт научился рассылать спам через сервер провайдера"
Отправлено mirya , 03-Фев-05 16:47 
может эффективнее было бы заодно и уведомлять клиента, что от него градом сыпется спам, т.е. приймите меры, т.к. спам-агент еще кроме первичной задачи ворует частную информацию, удаляет у вас все с диска Ж:, шкрябает сидюки, ламает колесико в мышке и т.д. - поставте 20 антивирусных програм, перезапустите винду 40 раз, отформатируте винт - 20...

"Спамерский софт научился рассылать спам через сервер провайдера"
Отправлено robin zlobin , 03-Фев-05 16:48 
всех спасет принудительный smtp auth :-)
я уже давно практикую на своих почтовых серверах обязательную аутентификацию на релеях. пользователи ничего, привыкнут.

"Спамерский софт научился рассылать спам через сервер провайд..."
Отправлено mirya , 03-Фев-05 17:32 
Ага, с расчетом на то, что клиент - параноик, и не хранит логин/пассворд в конфиге мейл-программы, а вводит его каждый раз ручонками. В конце концов даже при таком подходе можно доработать зебат, чтобы вместе с настоящим мылом юзверя отправлял пачку революционных листовок

"Спамерский софт научился рассылать спам через сервер провайд..."
Отправлено Rick , 04-Фев-05 22:14 
Ну, в таком случае, мы будем точно знать кто это, и либо свободен, либо антитроян + антивирус в студию.

"Спамерский софт научился рассылать спам через сервер провайдера"
Отправлено Аноним , 05-Фев-05 15:29 
А может вместо MySQL использовать BerkeleyDB?

"Спамерский софт научился рассылать спам через сервер провайд..."
Отправлено ShadoFF , 07-Фев-05 14:37 
>А может вместо MySQL использовать BerkeleyDB?

А смысл?


"Спамерский софт научился рассылать спам через сервер провайд..."
Отправлено zyxman , 23-Фев-05 01:52 
Ребяты, откуда вы на самом деле такого низкого мнения о mysql?

я пару месяцев назад игрался с ним, и получил на _грамотно_постоенной_базе_ 200000 insert/s.
update-ов без перестроения ключей еще раз в 10 больше.
join по ключу на таблице 800000 записей отработался за 0.0004s.

Аккуратнее нужно подходить к базе данных, и все у вас получится.


"Спамерский софт научился рассылать спам через сервер провайд..."
Отправлено uldus , 23-Фев-05 08:24 
>я пару месяцев назад игрался с ним, и получил на _грамотно_постоенной_базе_ 200000

У вас нет понимания того, что ваши синтетические тесты в реальных ситациях малопригодны. Как пример, попробуте добавить ваши 200000 в 10-100 параллельных потоков, без отложенных insert'ов. С блокировками у MySQL не все в порядке.


> update-ов без перестроения ключей еще раз в 10 больше.

Апдейтов не может быть больше, так как update по сути это тот же insert.