The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

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

03.02.2005 13:08

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

Антиспамерские организации зафиксировали резкий всплеск спама, исходящего от крупных ISP. Бороться с такими рассылками, можно только через контекстную фильтрацию, черные и серые списки, в данной ситуации полностью теряют актуальность.

Аналитики прогнозируют, что объем спама в этом году вырастет до 95%. В конце января увеличение объема спам рассылок пользователи могли ощутить невооруженным глазом. За несколько недель его объем вырос на 40% и достиг рекорда - 90% от общего объема почты.

Выход видится в введении провайдерами обязательной SMTP аутентификации и ограничений на число передаваемых от пользователя писем в единицу времени. Например, для postfix, реализация "rate-limit" для отдельных IP (anvil в postfix 2.1) имеет статус экспериментальной подсистемы не рекомендована для "production" применения.

  1. Главная ссылка к новости (http://zdnet.ru/?ID=475141...)
  2. Postfix: Measures against clients that make too many connections
Лицензия: CC-BY
Тип: Тема для размышления
Короткая ссылка: https://opennet.ru/5023-spam
Ключевые слова: spam, virus, postfix
Поддержать дальнейшую публикацию новостей на OpenNET.


Обсуждение (32) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, unk (ok), 13:23, 03/02/2005 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    В конфигурациях с 2-мя и более MX'ами anvil(8) не может работать вообще. Для postfix 2.x такие ограничения лучше делать через check_policy_service.
     
     
  • 2.2, Maxim Chirkov (ok), 13:50, 03/02/2005 [^] [^^] [^^^] [ответить]  
  • +/
    Точно, уже готовый сервер check_policy_service выпустили:
    http://opennix.com/email/postfix/policy/ratelimit.html
     
     
  • 3.3, Maxim Chirkov (ok), 13:57, 03/02/2005 [^] [^^] [^^^] [ответить]  
  • +/
    Беру свои слова обратно, по той ссылке абсолютно несерьезная система, на каждый запрос дергающая MySQL.
    Есть ли нормальные готовые решения для  check_policy_service ?

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

     
     
  • 4.4, unk (ok), 13:58, 03/02/2005 [^] [^^] [^^^] [ответить]  
  • +/
    >Беру свои слова обратно, по той ссылке абсолютно несерьезная система, на каждый
    >запрос дергающая MySQL.
    >Есть ли нормальные готовые решения для  check_policy_service ?
    У нас свой - проприетарный :(
    Посмотрите это: http://archives.neohapsis.com/archives/postfix/2004-12/att-0867/policyd-v1.38

     
     
  • 5.5, Maxim Chirkov (ok), 14:10, 03/02/2005 [^] [^^] [^^^] [ответить]  
  • +/
    >Посмотрите это: http://archives.neohapsis.com/archives/postfix/2004-12/att-0867/policyd-v1.38

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

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

     
     
  • 6.6, unk (ok), 14:14, 03/02/2005 [^] [^^] [^^^] [ответить]  
  • +/
    >Посмотрел. Тоже, только на Си. Дергать СУБД на каждое письмо и держать
    >специально для этого MySQL, не решение.
    Т.е. хочется обойтись только кэшем?

     
  • 4.8, vasili (?), 15:20, 03/02/2005 [^] [^^] [^^^] [ответить]  
  • +/
    не вижу ничего страшного в этом. сколько у тебя тысяч в день писем?
     
     
  • 5.9, unk (ok), 15:26, 03/02/2005 [^] [^^] [^^^] [ответить]  
  • +/
    >не вижу ничего страшного в этом. сколько у тебя тысяч в день
    >писем?
    Вы меня или Максима спрашиваете?

     
     
  • 6.13, vasili (?), 16:31, 03/02/2005 [^] [^^] [^^^] [ответить]  
  • +/
    Максима :)
     
  • 5.10, Maxim Chirkov (ok), 15:36, 03/02/2005 [^] [^^] [^^^] [ответить]  
  • +/
    >не вижу ничего страшного в этом. сколько у тебя тысяч в день
    >писем?

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

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

     
     
  • 6.11, unk (ok), 16:00, 03/02/2005 [^] [^^] [^^^] [ответить]  
  • +/
    >Вчера было тысяч 300, на первом попоавшемся под руку релее :-)
    >Но дело не в этом, приход спама идет волнами, в пике сколько
    >дашь - столько сожрут, к более сотни одновременным сесииям в момент
    >рассылки спама я уже привык. Использовать для этого MySQL как стрелять
    >из пушки по воробъям.
    Это все чудесно, но речь то о лимитах для своих клиентов.

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

     
     
  • 7.12, Maxim Chirkov (ok), 16:28, 03/02/2005 [^] [^^] [^^^] [ответить]  
  • +/
    >Это все чудесно, но речь то о лимитах для своих клиентов.

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

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

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

     
     
  • 8.17, unk (ok), 16:58, 03/02/2005 [^] [^^] [^^^] [ответить]  
  • +/
    Могут конечно, но я говорю это к тому, что выставив лимиты только для своих мы р... текст свёрнут, показать
     
     
  • 9.20, Maxim Chirkov (ok), 21:13, 03/02/2005 [^] [^^] [^^^] [ответить]  
  • +/
    Вот 5-и минутное агрегирование и сглаживает нагрузку на базу Подозреваю, что в ... текст свёрнут, показать
     
     
  • 10.21, unk (ok), 22:00, 03/02/2005 [^] [^^] [^^^] [ответить]  
  • +/
    Что-то я вас не понимаю Вы считаете, что парсить лог дешевле, чем тем же самы... текст свёрнут, показать
     
     
  • 11.22, Maxim Chirkov (ok), 09:17, 04/02/2005 [^] [^^] [^^^] [ответить]  
  • +/
    Думаю нет особой разницы парсить скриптом запрос postfix а или записи в логе за... текст свёрнут, показать
     
     
  • 12.23, unk (ok), 09:41, 04/02/2005 [^] [^^] [^^^] [ответить]  
  • +/
    Нет Дальше лимита выставленного в master cf дело просто не пойдет Вот что у ва... текст свёрнут, показать
     
     
  • 13.24, Maxim Chirkov (ok), 10:50, 04/02/2005 [^] [^^] [^^^] [ответить]  
  • +/
    Если лимит будет значительно меньше чем у smtpd, то в пике будет простой запросо... текст свёрнут, показать
     
     
  • 14.25, unk (ok), 11:24, 04/02/2005 [^] [^^] [^^^] [ответить]  
  • +/
    Давайте считать, то что система настроена, иначе разговор не имеет смысла В это... текст свёрнут, показать
     
     
  • 15.26, Maxim Chirkov (ok), 12:23, 04/02/2005 [^] [^^] [^^^] [ответить]  
  • +/
    В том то и дело, что результирующий хэш в 99 случаев когда нет флуда будет пу... текст свёрнут, показать
     
     
  • 16.27, unk (ok), 13:55, 04/02/2005 [^] [^^] [^^^] [ответить]  
  • +/
    Вас интересуют не лимиты для клиентов, а только борьба со флудом Мне же нужно л... текст свёрнут, показать
     
  • 6.14, vasili (?), 16:38, 03/02/2005 [^] [^^] [^^^] [ответить]  
  • +/
    >Вчера было тысяч 300, на первом попоавшемся под руку релее :-)
    >Но дело не в этом, приход спама идет волнами, в пике сколько
    >дашь - столько сожрут, к более сотни одновременным сесииям в момент
    >рассылки спама я уже привык. Использовать для этого MySQL как стрелять
    >из пушки по воробъям.
    >Что будет с вашей машиной при 150 висящих MySQL, главное  сколько
    >при этом потребуется памяти :-)

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

     

  • 1.7, Аноним (7), 14:45, 03/02/2005 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А как в CGP поставить лимит на кол-во сообщений с одного IP?
     
     
  • 2.19, mira (?), 19:13, 03/02/2005 [^] [^^] [^^^] [ответить]  
  • +/
    Это через админ интерфейс
    SMTP->Receiving->Limits
    Non-Client Sender: Limited to:2   per: 30 seconds
    Помойму так!
     

  • 1.15, mirya (?), 16:47, 03/02/2005 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    может эффективнее было бы заодно и уведомлять клиента, что от него градом сыпется спам, т.е. приймите меры, т.к. спам-агент еще кроме первичной задачи ворует частную информацию, удаляет у вас все с диска Ж:, шкрябает сидюки, ламает колесико в мышке и т.д. - поставте 20 антивирусных програм, перезапустите винду 40 раз, отформатируте винт - 20...
     
  • 1.16, robin zlobin (?), 16:48, 03/02/2005 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    всех спасет принудительный smtp auth :-)
    я уже давно практикую на своих почтовых серверах обязательную аутентификацию на релеях. пользователи ничего, привыкнут.
     
     
  • 2.18, mirya (?), 17:32, 03/02/2005 [^] [^^] [^^^] [ответить]  
  • +/
    Ага, с расчетом на то, что клиент - параноик, и не хранит логин/пассворд в конфиге мейл-программы, а вводит его каждый раз ручонками. В конце концов даже при таком подходе можно доработать зебат, чтобы вместе с настоящим мылом юзверя отправлял пачку революционных листовок
     
     
  • 3.28, Rick (??), 22:14, 04/02/2005 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, в таком случае, мы будем точно знать кто это, и либо свободен, либо антитроян + антивирус в студию.
     

  • 1.29, Аноним (7), 15:29, 05/02/2005 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А может вместо MySQL использовать BerkeleyDB?
     
     
  • 2.30, ShadoFF (?), 14:37, 07/02/2005 [^] [^^] [^^^] [ответить]  
  • +/
    >А может вместо MySQL использовать BerkeleyDB?

    А смысл?

     
     
  • 3.31, zyxman (?), 01:52, 23/02/2005 [^] [^^] [^^^] [ответить]  
  • +/
    Ребяты, откуда вы на самом деле такого низкого мнения о mysql?

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

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

     
     
  • 4.32, uldus (ok), 08:24, 23/02/2005 [^] [^^] [^^^] [ответить]  
  • +/
    >я пару месяцев назад игрался с ним, и получил на _грамотно_постоенной_базе_ 200000

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


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

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

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:
    При перепечатке указание ссылки на opennet.ru обязательно



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2022 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру