https://www.opennet.ru/openforum/vsluhforumID3/5077.html В сети обнаружен новый вид троянского ПО, предназначенного для рассылки спама. Главное отличие от предыдущих реализаций - возможность рассылки спама через почтовый сервер интернет-провайдера, клиентом которого является владелец зараженной машины.<br><br>Антиспамерские организации зафиксировали резкий всплеск спама, исходящего от крупных ISP. Бороться с такими рассылками, можно только через контекстную фильтрацию, черные и серые списки, в данной ситуации полностью теряют актуальность.<br><br><br>Аналитики прогнозируют, что объем спама в этом году вырастет до 95%. В конце января увеличение объема спам рассылок пользователи могли ощутить невооруженным глазом. За несколько недель его объем вырос на 40% и достиг рекорда - 90% от общего объема почты.<br><br><br>Выход видится в введении провайдерами обязательной SMTP аутентификации и ограничений на число передаваемых от пользователя писем в единицу времени. Например, для postfix, реализация "rate-limit" для отдельных IP (anvil (http://www.postfix.org/anvil.8.html) в postfix 2.1) имее https://www.opennet.ru/openforum/vsluhforumID3/5077.html#32 Wed, 23 Feb 2005 05:24:35 GMT &gt;я пару месяцев назад игрался с ним, и получил на _грамотно_постоенной_базе_ 200000 <br><br>У вас нет понимания того, что ваши синтетические тесты в реальных ситациях малопригодны. Как пример, попробуте добавить ваши 200000 в 10-100 параллельных потоков, без отложенных insert'ов. С блокировками у MySQL не все в порядке.<br><br><br>&gt; update-ов без перестроения ключей еще раз в 10 больше. <br><br>Апдейтов не может быть больше, так как update по сути это тот же insert. https://www.opennet.ru/openforum/vsluhforumID3/5077.html#31 Tue, 22 Feb 2005 22:52:45 GMT Ребяты, откуда вы на самом деле такого низкого мнения о mysql?<br><br>я пару месяцев назад игрался с ним, и получил на _грамотно_постоенной_базе_ 200000 insert/s.<br>update-ов без перестроения ключей еще раз в 10 больше.<br>join по ключу на таблице 800000 записей отработался за 0.0004s.<br><br>Аккуратнее нужно подходить к базе данных, и все у вас получится.<br> https://www.opennet.ru/openforum/vsluhforumID3/5077.html#30 Mon, 07 Feb 2005 11:37:38 GMT &gt;А может вместо MySQL использовать BerkeleyDB? <br><br>А смысл? <br><br> https://www.opennet.ru/openforum/vsluhforumID3/5077.html#29 Sat, 05 Feb 2005 12:29:53 GMT А может вместо MySQL использовать BerkeleyDB? https://www.opennet.ru/openforum/vsluhforumID3/5077.html#28 Fri, 04 Feb 2005 19:14:55 GMT Ну, в таком случае, мы будем точно знать кто это, и либо свободен, либо антитроян + антивирус в студию. https://www.opennet.ru/openforum/vsluhforumID3/5077.html#27 Fri, 04 Feb 2005 10:55:53 GMT &gt;В том то и дело, что результирующий хэш в 99% случаев (когда <br>&gt;нет флуда) будет пустым и трогать еге не будет необходимости. Когда <br>&gt;есть флуд, хэш не будет пустым, но список будет неизменен. Итого <br>&gt;трогаем файл с хэшем только когда появляется или исчезает новый флудер. <br>Вас интересуют не лимиты для клиентов, а только борьба со флудом.<br>Мне же нужно лимитировать не только число сессий, но и количество писем в единицу времени.<br><br>&gt;&gt;Кстати, а что делать будете если клиент в 1 сессию отправит 1K <br>&gt;&gt;писем и каждое на 10bcc? <br>&gt;За минуту не отправит, между письмами в потоке идет задержка и лимитируется <br>&gt;число писем в рамках одной сессии.<br>1K было просто для примера (как дефолт postfix)<br>А что за задержка?<br>Вы сново скажите, что парсить лог для отлова таких ситуаций дешевле чем повесить хук на smtpd_*_restrictions?<br> https://www.opennet.ru/openforum/vsluhforumID3/5077.html#26 Fri, 04 Feb 2005 09:23:07 GMT &gt;В этой схеме все упирается в действительное количество перестроений таблицы, <br>&gt;в пике вам придется делать это раз в минуту - это слишком <br>&gt;часто для hash. <br><br>В том то и дело, что результирующий хэш в 99% случаев (когда нет флуда) будет пустым и трогать еге не будет необходимости. Когда есть флуд, хэш не будет пустым, но список будет неизменен. Итого трогаем файл с хэшем только когда появляется или исчезает новый флудер.<br><br>&gt;Кстати, а что делать будете если клиент в 1 сессию отправит 1K <br>&gt;писем и каждое на 10bcc? <br><br>За минуту не отправит, между письмами в потоке идет задержка и лимитируется число писем в рамках одной сессии.<br><br><br> https://www.opennet.ru/openforum/vsluhforumID3/5077.html#25 Fri, 04 Feb 2005 08:24:49 GMT &gt;Если лимит будет значительно меньше чем у smtpd, то в пике будет <br>&gt;простой запросов и рост очереди smtpd. <br>Давайте считать, то что система настроена, иначе разговор не имеет смысла.<br><br>&gt;Парсер лога (1) не самое ресурсоемкое звено, агрегирование на этапе<br>&gt;парсинга существенно <br>&gt;сокращает число перестроений таблиц (2).<br>В этой схеме все упирается в действительное количество перестроений таблицы,<br>в пике вам придется делать это раз в минуту - это слишком часто для hash.<br><br>&gt;Тем более что hash лукапы кешируются.<br>Можно нарваться на max_use...<br><br>Кстати, а что делать будете если клиент в 1 сессию отправит 1K писем и каждое на 10bcc? https://www.opennet.ru/openforum/vsluhforumID3/5077.html#24 Fri, 04 Feb 2005 07:50:14 GMT &gt;&gt;Если смотреть на пики, то в момент единовременного наплыва запросов<br>&gt;&gt;postfix+демон может захлебнуться.<br>&gt;Нет. Дальше лимита выставленного в master.cf дело просто не пойдет. <br><br>Если лимит будет значительно меньше чем у smtpd, то в пике будет простой запросов и рост очереди smtpd.<br><br><br>&gt;&gt;а вначале суммирует данные за небольшой период, а уже потом оценивает <br>&gt;&gt;состояние (т.е. на 100 запросов с одного IP в минуту будет <br>&gt;&gt;сделана одна проверка, а для postfix+демона - 100).<br><br>&gt;Вот что у вас получается: <br>&gt;1. парсер лога <br>&gt;2. перестроение таблицы <br>&gt;3. Те же 100 запросов - ведь должен же postfix смотреть блэк <br>&gt;лист <br>&gt;И вы хотите сказать, что это дешевле... <br><br>Парсер лога (1) не самое ресурсоемкое звено, агрегирование на этапе парсинга существенно сокращает число перестроений таблиц (2). Смотрением постфикса в хэш (3) можно пренебречь, задержка на лукапах пренебрежима мала по сравнению с другими операциями. Тем более что hash лукапы кешируются.<br>