форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка

Вариант для распечатки		Архивированная нить - только для чтения!  Пред. тема | След. тема
Форумы Разговоры, обсуждение новостей (Public)
Изначальное сообщение		[Проследить за развитием треда]

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

Сообщение от opennews (ok) on 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

Cообщить модератору | Наверх | ^

Сообщения по теме

[Сортировка по времени, UBB]

1. "Спамерский софт научился рассылать спам через сервер провайд..."

Сообщение от unk (ok) on 03-Фев-05, 13:23

В конфигурациях с 2-мя и более MX'ами anvil(8) не может работать вообще. Для postfix 2.x такие ограничения лучше делать через check_policy_service.

Cообщить модератору | Наверх | ^

	2. "Спамерский софт научился рассылать спам через сервер провайд..."
	Сообщение от Maxim Chirkov (ok) on 03-Фев-05, 13:50
	Точно, уже готовый сервер check_policy_service выпустили: http://opennix.com/email/postfix/policy/ratelimit.html
	Cообщить модератору | Наверх | ^

	3. "Спамерский софт научился рассылать спам через сервер провайд..."
	Сообщение от Maxim Chirkov (ok) on 03-Фев-05, 13:57
	Беру свои слова обратно, по той ссылке абсолютно несерьезная система, на каждый запрос дергающая MySQL. Есть ли нормальные готовые решения для  check_policy_service ? Стоит ли смотреть на policyd (http://archives.neohapsis.com/archives/postfix/2004-12/0867.html)
	Cообщить модератору | Наверх | ^

	4. "Спамерский софт научился рассылать спам через сервер провайд..."
	Сообщение от unk (ok) on 03-Фев-05, 13:58
	>Беру свои слова обратно, по той ссылке абсолютно несерьезная система, на каждый >запрос дергающая MySQL. >Есть ли нормальные готовые решения для  check_policy_service ? У нас свой - проприетарный :( Посмотрите это: http://archives.neohapsis.com/archives/postfix/2004-12/att-0867/policyd-v1.38.tar.gz
	Cообщить модератору | Наверх | ^

	5. "Спамерский софт научился рассылать спам через сервер провайд..."
	Сообщение от Maxim Chirkov (ok) on 03-Фев-05, 14:10
	>Посмотрите это: http://archives.neohapsis.com/archives/postfix/2004-12/att-0867/policyd-v1.38.tar.gz Посмотрел. Тоже, только на Си. Дергать СУБД на каждое письмо и держать специально для этого MySQL, не решение. Где-то валяется самописная perl библиотека для rate-limit'ов в CGI скриптах, использующая для работы файлы флажки/очереди. Если приспичит, думаю можно написать плагин к amavisd-new.
	Cообщить модератору | Наверх | ^

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

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

	9. "Спамерский софт научился рассылать спам через сервер провайд..."
	Сообщение от unk (ok) on 03-Фев-05, 15:26
	>не вижу ничего страшного в этом. сколько у тебя тысяч в день >писем? Вы меня или Максима спрашиваете?
	Cообщить модератору | Наверх | ^

	13. "Спамерский софт научился рассылать спам через сервер провайд..."
	Сообщение от vasili on 03-Фев-05, 16:31
	Максима :)
	Cообщить модератору | Наверх | ^

	10. "Спамерский софт научился рассылать спам через сервер провайд..."
	Сообщение от Maxim Chirkov (ok) on 03-Фев-05, 15:36
	>не вижу ничего страшного в этом. сколько у тебя тысяч в день >писем? Вчера было тысяч 300, на первом попоавшемся под руку релее :-) Но дело не в этом, приход спама идет волнами, в пике сколько дашь - столько сожрут, к более сотни одновременным сесииям в момент рассылки спама я уже привык. Использовать для этого MySQL как стрелять из пушки по воробъям. Что будет с вашей машиной при 150 висящих MySQL, главное  сколько при этом потребуется памяти :-) PS. Уже третий день наблюдаю как спамерские трояны по тупому перебирают адреса в одном домене,  такие переборы дают прибавку в пару сотен Мб к размеру лога в день. Самое пакостное, что бороться с этим DDoS невозмонжно, адреса у каждого запроса разные :-(
	Cообщить модератору | Наверх | ^

	11. "Спамерский софт научился рассылать спам через сервер провайд..."
	Сообщение от unk (ok) on 03-Фев-05, 16:00
	>Вчера было тысяч 300, на первом попоавшемся под руку релее :-) >Но дело не в этом, приход спама идет волнами, в пике сколько >дашь - столько сожрут, к более сотни одновременным сесииям в момент >рассылки спама я уже привык. Использовать для этого MySQL как стрелять >из пушки по воробъям. Это все чудесно, но речь то о лимитах для своих клиентов. >Что будет с вашей машиной при 150 висящих MySQL, главное  сколько >при этом потребуется памяти :-) Ни чего страшного. Для postfix это будет легче чем скажем cidr или hash.
	Cообщить модератору | Наверх | ^

	12. "Спамерский софт научился рассылать спам через сервер провайд..."
	Сообщение от Maxim Chirkov (ok) on 03-Фев-05, 16:28
	>Это все чудесно, но речь то о лимитах для своих клиентов. А что, свои клиенты массой подхватив вирус не могут обеспечить такую нагрузку ? >>Что будет с вашей машиной при 150 висящих MySQL, главное  сколько >>при этом потребуется памяти :-) >Ни чего страшного. Для postfix это будет легче чем скажем cidr или >hash. Для postfix, но не для MySQL с разросшейся таблицей IP'шек. Пусть даже он будет держать целикиком ее в памяти - нагрузка от него будет горяздо больше, чем от postfix на том почтовом сервере. Итого имеем необходимость использовать монстра, из-за нежелания потратить пару часов на написание оптимального кода. Там где очень много параллельных update/insert MySQL дохнет и затыкается на локах.
	Cообщить модератору | Наверх | ^

	17. "Спамерский софт научился рассылать спам через сервер провайд..."
	Сообщение от unk (ok) on 03-Фев-05, 16:58
	>>Это все чудесно, но речь то о лимитах для своих клиентов. > >А что, свои клиенты массой подхватив вирус не могут обеспечить такую нагрузку >? Могут конечно, но я говорю это к тому, что выставив лимиты только для своих мы резко снижаем общее количество запросов. Давайте я расскажу как сделано у нас: Лимиты на сессию только для "своих", история конектов за 5 минут держится только в памяти, остальное в postgres. Работает на отдельной машине, обслуживает 3 MX-а.
	Cообщить модератору | Наверх | ^

	20. "Спамерский софт научился рассылать спам через сервер провайд..."
	Сообщение от Maxim Chirkov (ok) on 03-Фев-05, 21:13
	>Давайте я расскажу как сделано у нас: >Лимиты на сессию только для "своих", история конектов за 5 минут держится, >остальное в postgres Вот 5-и минутное агрегирование и сглаживает нагрузку на базу. Подозреваю, что в базу у вас больше для аккаунтинга данные пишутся, чем для лимитирования. Я пока шел домой, решил если приспичит, делать старым проверенным способом: простой скрипт, обособленно от postfix, периодически (cron) или постоянно (демон) следящий за хвостом лога и при превышении заложенных лимитов, добавляющего клиента во временный блэклист, в котором он будет висеть до того как истечет таймаут. Мгновенное реагирование по сути не требуется, блокирование в течении минуты после превышения вполне приемлимо.
	Cообщить модератору | Наверх | ^

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

	22. "Спамерский софт научился рассылать спам через сервер провайд..."
	Сообщение от Maxim Chirkov (ok) on 04-Фев-05, 09:17
	>Что-то я вас не понимаю... Вы считаете, что парсить лог дешевле, чем >тем же самым скриптом/демоном получать IP на блюдечке от postfix через >smtpd_*_restrictions??? Думаю нет особой разницы парсить скриптом запрос postfix'а или записи в логе (записи в логе парсятся очень быстро, за минуту можно десять раз лог за день пропарсить не говоря о минутной выборке). Но лог обрабатывается линейно одним процессом никаким образом не влияя на надежность подсистемы postfix, и позволяет не вешать cкрипт/демон привязанный к postfix, не добавляя лишнее звено в критичную систему. Если смотреть на пики, то в момент единовременного наплыва запросов postfix+демон может захлебнуться. Анализатор лога работает блочно, не проверяет лимиты на каждый запрос, а вначале суммирует данные за небольшой период, а уже потом оценивает состояние (т.е. на 100 запросов с одного IP в минуту будет сделана одна проверка, а для postfix+демона - 100). К томуже у меня уже работает подобный парсер лога (мониторинг) к которому привернуть лишнюю проверку не так трудно.
	Cообщить модератору | Наверх | ^

	23. "Спамерский софт научился рассылать спам через сервер провайд..."
	Сообщение от unk (ok) on 04-Фев-05, 09:41
	>Если смотреть на пики, то в момент единовременного наплыва запросов >postfix+демон может захлебнуться. Нет. Дальше лимита выставленного в master.cf дело просто не пойдет. >а вначале суммирует данные за небольшой период, а уже потом оценивает >состояние (т.е. на 100 запросов с одного IP в минуту будет >сделана одна проверка, а для postfix+демона - 100). Вот что у вас получается: 1. парсер лога 2. перестроение таблицы 3. Те же 100 запросов - ведь должен же postfix смотреть блэк лист И вы хотите сказать, что это дешевле... >К томуже у меня уже работает подобный парсер лога (мониторинг) к которому >привернуть лишнюю проверку не так трудно. Так и говорите: "Мне так проще"
	Cообщить модератору | Наверх | ^

	24. "Спамерский софт научился рассылать спам через сервер провайд..."
	Сообщение от Maxim Chirkov (ok) on 04-Фев-05, 10:50
	>>Если смотреть на пики, то в момент единовременного наплыва запросов >>postfix+демон может захлебнуться. >Нет. Дальше лимита выставленного в master.cf дело просто не пойдет. Если лимит будет значительно меньше чем у smtpd, то в пике будет простой запросов и рост очереди smtpd. >>а вначале суммирует данные за небольшой период, а уже потом оценивает >>состояние (т.е. на 100 запросов с одного IP в минуту будет >>сделана одна проверка, а для postfix+демона - 100). >Вот что у вас получается: >1. парсер лога >2. перестроение таблицы >3. Те же 100 запросов - ведь должен же postfix смотреть блэк >лист >И вы хотите сказать, что это дешевле... Парсер лога (1) не самое ресурсоемкое звено, агрегирование на этапе парсинга существенно сокращает число перестроений таблиц (2). Смотрением постфикса в хэш (3) можно пренебречь, задержка на лукапах пренебрежима мала по сравнению с другими операциями. Тем более что hash лукапы кешируются.
	Cообщить модератору | Наверх | ^

	25. "Спамерский софт научился рассылать спам через сервер провайд..."
	Сообщение от unk (ok) on 04-Фев-05, 11:24
	>Если лимит будет значительно меньше чем у smtpd, то в пике будет >простой запросов и рост очереди smtpd. Давайте считать, то что система настроена, иначе разговор не имеет смысла. >Парсер лога (1) не самое ресурсоемкое звено, агрегирование на этапе >парсинга существенно >сокращает число перестроений таблиц (2). В этой схеме все упирается в действительное количество перестроений таблицы, в пике вам придется делать это раз в минуту - это слишком часто для hash. >Тем более что hash лукапы кешируются. Можно нарваться на max_use... Кстати, а что делать будете если клиент в 1 сессию отправит 1K писем и каждое на 10bcc?
	Cообщить модератору | Наверх | ^

	26. "Спамерский софт научился рассылать спам через сервер провайд..."
	Сообщение от Maxim Chirkov (ok) on 04-Фев-05, 12:23
	>В этой схеме все упирается в действительное количество перестроений таблицы, >в пике вам придется делать это раз в минуту - это слишком >часто для hash. В том то и дело, что результирующий хэш в 99% случаев (когда нет флуда) будет пустым и трогать еге не будет необходимости. Когда есть флуд, хэш не будет пустым, но список будет неизменен. Итого трогаем файл с хэшем только когда появляется или исчезает новый флудер. >Кстати, а что делать будете если клиент в 1 сессию отправит 1K >писем и каждое на 10bcc? За минуту не отправит, между письмами в потоке идет задержка и лимитируется число писем в рамках одной сессии.
	Cообщить модератору | Наверх | ^

	27. "Спамерский софт научился рассылать спам через сервер провайд..."
	Сообщение от unk (ok) on 04-Фев-05, 13:55
	>В том то и дело, что результирующий хэш в 99% случаев (когда >нет флуда) будет пустым и трогать еге не будет необходимости. Когда >есть флуд, хэш не будет пустым, но список будет неизменен. Итого >трогаем файл с хэшем только когда появляется или исчезает новый флудер. Вас интересуют не лимиты для клиентов, а только борьба со флудом. Мне же нужно лимитировать не только число сессий, но и количество писем в единицу времени. >>Кстати, а что делать будете если клиент в 1 сессию отправит 1K >>писем и каждое на 10bcc? >За минуту не отправит, между письмами в потоке идет задержка и лимитируется >число писем в рамках одной сессии. 1K было просто для примера (как дефолт postfix) А что за задержка? Вы сново скажите, что парсить лог для отлова таких ситуаций дешевле чем повесить хук на smtpd_*_restrictions?
	Cообщить модератору | Наверх | ^

	14. "Спамерский софт научился рассылать спам через сервер провайд..."
	Сообщение от vasili on 03-Фев-05, 16:38
	>Вчера было тысяч 300, на первом попоавшемся под руку релее :-) >Но дело не в этом, приход спама идет волнами, в пике сколько >дашь - столько сожрут, к более сотни одновременным сесииям в момент >рассылки спама я уже привык. Использовать для этого MySQL как стрелять >из пушки по воробъям. >Что будет с вашей машиной при 150 висящих MySQL, главное  сколько >при этом потребуется памяти :-) Да.... у меня 2000-3000 в день в обе стороны. MySQL справиться я так думаю :) Если объемы будут расти, то поставлю postgre или буду искать более быстрое решение без использования СУБД.
	Cообщить модератору | Наверх | ^

7. "Спамерский софт научился рассылать спам через сервер провайд..."

Сообщение от Аноним on 03-Фев-05, 14:45

А как в CGP поставить лимит на кол-во сообщений с одного IP?

Cообщить модератору | Наверх | ^

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

15. "Спамерский софт научился рассылать спам через сервер провайд..."

Сообщение от mirya on 03-Фев-05, 16:47

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

Cообщить модератору | Наверх | ^

16. "Спамерский софт научился рассылать спам через сервер провайд..."

Сообщение от robin zlobin on 03-Фев-05, 16:48

всех спасет принудительный smtp auth :-) я уже давно практикую на своих почтовых серверах обязательную аутентификацию на релеях. пользователи ничего, привыкнут.

Cообщить модератору | Наверх | ^

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

	28. "Спамерский софт научился рассылать спам через сервер провайд..."
	Сообщение от Rick (??) on 04-Фев-05, 22:14
	Ну, в таком случае, мы будем точно знать кто это, и либо свободен, либо антитроян + антивирус в студию.
	Cообщить модератору | Наверх | ^

29. "Спамерский софт научился рассылать спам через сервер провайд..."

Сообщение от Аноним on 05-Фев-05, 15:29

А может вместо MySQL использовать BerkeleyDB?

Cообщить модератору | Наверх | ^

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

	31. "Спамерский софт научился рассылать спам через сервер провайд..."
	Сообщение от zyxman on 23-Фев-05, 01:52
	Ребяты, откуда вы на самом деле такого низкого мнения о mysql? я пару месяцев назад игрался с ним, и получил на _грамотно_постоенной_базе_ 200000 insert/s. update-ов без перестроения ключей еще раз в 10 больше. join по ключу на таблице 800000 записей отработался за 0.0004s. Аккуратнее нужно подходить к базе данных, и все у вас получится.
	Cообщить модератору | Наверх | ^

	32. "Спамерский софт научился рассылать спам через сервер провайд..."
	Сообщение от uldus (ok) on 23-Фев-05, 08:24
	>я пару месяцев назад игрался с ним, и получил на _грамотно_постоенной_базе_ 200000 У вас нет понимания того, что ваши синтетические тесты в реальных ситациях малопригодны. Как пример, попробуте добавить ваши 200000 в 10-100 параллельных потоков, без отложенных insert'ов. С блокировками у MySQL не все в порядке. > update-ов без перестроения ключей еще раз в 10 больше. Апдейтов не может быть больше, так как update по сути это тот же insert.
	Cообщить модератору | Наверх | ^

Удалить

Индекс форумов | Темы | Пред. тема | След. тема