2015-10-13 17:25 GMT+03:00 Sergey Myasoedov sergey@devnull.ru:

Всем привет!

Я получил письмо от участника ENOG, который предлагает к обсуждению идею. Он хотел было поднять вопрос на конференции, но у нас вообще-то еще не было сессии для высказывания мнений (вроде Birds of a Feather - BoF) по вопросу противодействия DDoS. В чем-то предложение наивно, но такой подход не должен быть предметом критики.

==================

Есть распределенная атака. С ней обычно борются на финальной точке, естественно, не справляются. Но зачем боротся с водопадом, когда можно перекрыть краник в начале?

Таким образом нужна система межоператорского взаимодействия (ANTIDDOS), возможно на основе RIPE.

RIPE предпочтителен, ибо к нему есть доверие у самих операторов. Система представляет из себя WEB интерфейс с простеньким софтом, который умеет проверять адреса на принадлежность к оператору и рассылать операторам письма. Операторы заводят в ней аккаунты (защищенные паролями, ключами и т.д.), и оставляют контактные данные.

Таким образом, усмирение атаки сводится к простому алгоритму:

1. Атакуемый оператор составляет список атакующих его адресов и загружает в систему.
2. Система проверяет принадлежность адресов различным операторам и рассылает им уведомления.
3. Операторы, из сети которых ведется атака, получают письма от системы со списком адресов и

перекрывают этим адресам доступ в сеть, высылают им уведомления о необходимости проверки своих ПК и т.д.. Все, атака захлебнулась.... =)))

Добрый день,

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

DNS/NTP amp, при условии тотального внедрения, эта система через пару лет наверное отбивать сможет. Без системы распределенного анализа наподобие существующего в Radware и, соответственно, активных участников, являющихся одновременно игроками операторского рынка и разработчиками, опять же, очень сильные сомнения в жизнеспособности такого решения.

On Tue, Oct 13, 2015 at 05:53:22PM +0300, Andrey Korolyov wrote:

2015-10-13 17:25 GMT+03:00 Sergey Myasoedov sergey@devnull.ru:

...

Всем привет!

Я получил письмо от участника ENOG, который предлагает к обсуждению идею. Он хотел было поднять вопрос на конференции, но у нас вообще-то еще не было сессии для высказывания мнений (вроде Birds of a Feather - BoF) по вопросу противодействия DDoS. В чем-то предложение наивно, но такой подход не должен быть предметом критики.

==================

Есть распределенная атака. С ней обычно борются на финальной точке, естественно, не справляются. Но зачем боротся с водопадом, когда можно перекрыть краник в начале?

Таким образом нужна система межоператорского взаимодействия (ANTIDDOS), возможно на основе RIPE.

RIPE предпочтителен, ибо к нему есть доверие у самих операторов. Система представляет из себя WEB интерфейс с простеньким софтом, который умеет проверять адреса на принадлежность к оператору и рассылать операторам письма. Операторы заводят в ней аккаунты (защищенные паролями, ключами и т.д.), и оставляют контактные данные.

Таким образом, усмирение атаки сводится к простому алгоритму:

1. Атакуемый оператор составляет список атакующих его адресов и загружает в систему.
2. Система проверяет принадлежность адресов различным операторам и рассылает им уведомления.
3. Операторы, из сети которых ведется атака, получают письма от системы со списком адресов и

перекрывают этим адресам доступ в сеть, высылают им уведомления о необходимости проверки своих ПК и т.д.. Все, атака захлебнулась.... =)))

Добрый день,

есть несколько моментов:

• много маломощных источников (1...50к),
• спуф,
• невозможность полного отсечения трафика вкупе с хоть какой-то

ненулевой сложностью атаки,

• участие не-подавляющей доли операторов в инициативе (иными словами,

необязательным порядком) сведет пользу в ноль.

DNS/NTP amp, при условии тотального внедрения, эта система через пару лет наверное отбивать сможет. Без системы распределенного анализа

NTP amplification - может быть, но не DNS amplification.

Поясню на примере вашего xdel.ru: DNS-сервер, на который делегирована эта зона, корректно выдаёт 383 байтовый ответ на 53 байтовый запрос:

18:03:36.377293 IP (tos 0x0, ttl 64, id 61177, offset 0, flags [none], proto UDP (17), length 53, bad cksum 0 (->276b)!) 185.22.182.36.46527 > 185.22.60.2.53: 1348+ ANY? xdel.ru. (25) 18:03:36.389180 IP (tos 0x0, ttl 61, id 10114, offset 0, flags [none], proto UDP (17), length 383) 185.22.60.2.53 > 185.22.182.36.46527: 1348*- 11/0/0 xdel.ru. SOA nsu0.flops.ru. hostmaster.xdel.ru. 2015060500 86400 7200 2419200 900, xdel.ru. NS nsu0.flops.ru., xdel.ru. NS nsu1.flops.ru., xdel.ru. NS nsu2.flops.ru., xdel.ru. A 91.239.27.205, xdel.ru. MX aspmx3.googlemail.com. 10, xdel.ru. MX alt2.aspmx.l.google.com. 5, xdel.ru. MX aspmx.l.google.com. 1, xdel.ru. MX aspmx2.googlemail.com. 10, xdel.ru. MX alt1.aspmx.l.google.com. 5, xdel.ru. TXT "v=spf1 +a +mx ip4:91.239.27.205/32 include:google.com -all" (355)

amplification, конечно, так себе, всего семь к одному... Но доменов в мире очень много, и уже по enog.org удаётся получить почти десять к одному:

18:10:15.529857 IP (tos 0x0, ttl 64, id 46731, offset 0, flags [none], proto UDP (17), length 54, bad cksum 0 (->8ce7)!) 185.22.182.36.57524 > 199.212.0.53.53: 61350+ ANY? enog.org. (26) 18:10:15.662731 IP (tos 0x0, ttl 248, id 50285, offset 0, flags [DF], proto UDP (17), length 518) 199.212.0.53.53 > 185.22.182.36.57524: 61350*-| 2/0/0 enog.org. RRSIG, enog.org. RRSIG (490)

наподобие существующего в Radware и, соответственно, активных участников, являющихся одновременно игроками операторского рынка и разработчиками, опять же, очень сильные сомнения в жизнеспособности такого решения. _______________________________________________ discuss mailing list discuss@enog.org http://www.enog.org/mailman/listinfo/discuss

Приветствую !

К сожалению не вариант. Я последнее время все больше замечаю именно совсем маломощные источники, которые при этом еще и меняются. Т.е. слегка усложнить возможно, но полностью отрезать, да еще и чтобы атака не была действенной - не получится, просто маломощных источников будет еще больше.

Вычищать их тоже не вариант, потому что провайдеры поменять рутера всем своим клиентам не смогут, а если и смогут - то на что ? Софт для consumer устройств такое впечатление в основном написан китайскими студентами за еду, и о безопасности там вообще не думают.

Фильтровать dns/ntp/ssdp на абонентах было бы неплохо, но для этого провайдеру с такими источниками в сети нужен стимул, а если со всех его пользователей идет десяток-другой мегабит - то это даже и незаметно, потому что в приличную полосу это будет складываться уже на атакуемом.

Если распределенная система такого типа будет отлавливать подобную мелочь - то провайдер, в нее включившийся, столкнется с жалобами от легальных абонентов, и быстро передумает.

Вот если бы скажем Qrator со своей сканилкой начал еще и автоматические абузы со списками проблемных хостов...но и тогда скорее всего такие абузы просто начнут фильтровать :-)

On 13.10.2015 17:25, Sergey Myasoedov wrote:

Всем привет!

Я получил письмо от участника ENOG, который предлагает к обсуждению идею. Он хотел было поднять вопрос на конференции, но у нас вообще-то еще не было сессии для высказывания мнений (вроде Birds of a Feather - BoF) по вопросу противодействия DDoS. В чем-то предложение наивно, но такой подход не должен быть предметом критики.

==================

Есть распределенная атака. С ней обычно борются на финальной точке, естественно, не справляются. Но зачем боротся с водопадом, когда можно перекрыть краник в начале?

Таким образом нужна система межоператорского взаимодействия (ANTIDDOS), возможно на основе RIPE.

RIPE предпочтителен, ибо к нему есть доверие у самих операторов. Система представляет из себя WEB интерфейс с простеньким софтом, который умеет проверять адреса на принадлежность к оператору и рассылать операторам письма. Операторы заводят в ней аккаунты (защищенные паролями, ключами и т.д.), и оставляют контактные данные.

Таким образом, усмирение атаки сводится к простому алгоритму:

1. Атакуемый оператор составляет список атакующих его адресов и загружает в систему.
2. Система проверяет принадлежность адресов различным операторам и рассылает им уведомления.
3. Операторы, из сети которых ведется атака, получают письма от системы со списком адресов и

перекрывают этим адресам доступ в сеть, высылают им уведомления о необходимости проверки своих ПК и т.д.. Все, атака захлебнулась.... =)))

-- Kind regards, Sergey Myasoedov _______________________________________________ discuss mailing list discuss@enog.org http://www.enog.org/mailman/listinfo/discuss

On Tuesday 13 October 2015, Крупко Роман Александрович wrote:

И если адрес подменён, то это не помогает. А так реализовано большинство DDoS атак.

Это, как раз, не самая большая проблема. Вариантов подмены адреса не так много.

Вариант 1. Всякие amplification-атаки. Тут не найдёшь реального атакующего, но вот источник усиления посылает жертве трафик от своего имени. С этим, в теории, бороться можно, препятстве только в забивании многих на работу с abuse@.

Вариант 2. Зомби сеть. Трафик, изначально, генерируется с левым src ip. Тут вопрос, на сколько все придерживаются правила не выпускать наружу пакеты с src ip не своего диапазона. Если такого правила придерживаются многие, то такие пакеты не покинут сеть оператора, либо подстановка левого IP будет из сети этого же оператора. Тут уже есть шанс найти. Отдельный вопрос с магистралами, но это меньшие количественные (в пользователях) объёмы.

Третий вариант в голову не приходит.

Всем привет!

Люто двачую за рейт лимитинг амплифицирующих портов от клиентов и жму руку.

Это очень эффективный и при этом недеструктивный способ сокращения потоков зловредного трафика летящих из сетей.

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

On Wednesday, 14 October 2015, Yura Scheglyuk yura-ml@rikt.ru wrote:

            Hi!

On 13.10.2015 21:25, Sergey Myasoedov wrote:

Таким образом, усмирение атаки сводится к простому алгоритму:

...

1. Атакуемый оператор составляет список атакующих его адресов и загружает

в систему. 2) Система проверяет принадлежность адресов различным операторам и рассылает им уведомления. 3) Операторы, из сети которых ведется атака, получают письма от системы со списком адресов и перекрывают этим адресам доступ в сеть, высылают им уведомления о необходимости проверки своих ПК и т.д.. Все, атака захлебнулась.... =)))

Вы забыли про четвёртый пункт:

4. Отключенный клиент уходит к другому провайдеру.

Проходили это на своём опыте. Сначала тех.поддержка звонила заражённому клиенту и предупреждала о проблеме, рекомендовали установить антивирус. 95% абонентов просто забивала на это. Пробовали отключать особо заражённых клиентов - посыпались жалобы и угрозы уйти (и уходы) к другому провайдеру. У нас SCE, пробовали заражённым клиентам показывать страничку с предупреждением - тоже игнорировали.

Сейчас ограничили общую полосу NTP и DNS трафика, так что если и будет штормить, то не во всю мощь.

-- С уважением, Щеглюк Юрий

---

discuss mailing list discuss@enog.org http://www.enog.org/mailman/listinfo/discuss

On 14.10.2015 11:03, Pavel Odintsov wrote:

Люто двачую за рейт лимитинг амплифицирующих портов от клиентов и жму руку.

Это очень эффективный и при этом недеструктивный способ сокращения потоков зловредного трафика летящих из сетей.

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

Ограничили на доступе клиенту мегабит исходящего dns/ntp/ssdp трафика, на выходе вылилась сотня-две мегабит, на входе атакуемому все равно десятки гигабит, потому что провайдер не один. Ботнеты щас весьма развесистые, куда той клюкве.

Поможет, но только против самых бакланистых ддосеров с парой подломанных машин.

On 14.10.2015 08:30, Sergey Afonin wrote:

Вот потому и отключать, что, во-первых, пониженная скорость не спасёт жертву (когда атака будет идти с сотен и тысяч хостов, они сделают плохо и на маленькой скорости), а, во-вторых, многие просто не будут торопиться что-от делать.

Вот именно поэтому.

On 14.10.2015 11:04, Валерий Солдатов wrote:

Антиспуф контролировать несложно, а польза от него большая.

On 14.10.2015 11:05, Sergey Myasoedov wrote:

BCP38/BCP84 - это не война с абонентами, это гигиена в собственной сети.

Сильно зависит от реализации. Если спуфленые пакеты фильтровать еще на доступе - то да, польза большая. А если просто на выходе из своей сети дропать пакеты с не своим src - то тогда просто спуф пойдет по всему адресному пространству этого оператора, я такое уже встречал.

On 14.10.2015 11:16, Але wrote:

На мой взгляд, самое простое и в то же время эффективное решение - настройка сигнатур на стороне провайдерских/датацентровских IDS для исходящего трафика.

Любые stateful устройства не масштабируются на более-менее крупных обьемах трафика, а маленькие и не заметят. Анализ sflow помогает, но только уже когда обьемы достаточно заметны.

Вообще самая лучшая защита от ддоса - это некомпетентность ддосеров, в 95% случаев при наличии грамотных специалистов и подготовленной реакции ддосы не являются такой уж огромной проблемой. Но в оставшихся 5% случаев простых решений нет и, боюсь, принципиально быть не может. Или почти во всех случаях, если к этому не готовились заранее.

Вместе с тем я полностью поддерживаю идею лучшей связности между NOC-ами и удивляюсь, почему RIR-ы еще не обязывают LIR-ов иметь обязательный зарегистрированный канал связи с другими LIR-ами с гарантированным ответом. Периодически появляются идеи на тему "а как бы сделать так, чтобы абузы читали, и noc отвечал", но пока это не будет обязаловкой для всех LIR-ов - не взлетит.

Я вот другого не понимаю, средний платеж с клиента в хостинге в сотни раз больше чем у любого шпд провайдера. Но при этом у любого хостера есть кнопка пожаловаться, которая будет обработана в разумные сроки. И тут почему-то вполне нормально требовать даже от очень платящих клиентов срочного решения проблем. Так что с доводом про маркетологов носящихся за каждым клиентом условно по 400 рублей не уверен, что согласен.

On Wednesday, 14 October 2015, Volodymyr Litovka doka.ua@gmail.com wrote:

On 10/14/15 10:59 AM, Yura Scheglyuk wrote:

...

Вы забыли про четвёртый пункт:

4. Отключенный клиент уходит к другому провайдеру.

Проходили это на своём опыте. Сначала тех.поддержка звонила заражённому клиенту и предупреждала о проблеме, рекомендовали установить антивирус. 95% абонентов просто забивала на это. Пробовали отключать особо заражённых клиентов - посыпались жалобы и угрозы уйти (и уходы) к другому провайдеру. У нас SCE, пробовали заражённым клиентам показывать страничку с предупреждением - тоже игнорировали.

Сейчас ограничили общую полосу NTP и DNS трафика, так что если и будет штормить, то не во всю мощь.

Как мне кажется, наиболее адекватным решением является не отключение (поскольку приводит к озлоблению, скандалу и, в конечном итоге, потере этого долбо^H^H^H^H^H клиента), а ограничение пропускной полосы для всего трафика (или - дропанье каждого пятого TCP/80 пакета :) ) с соответствующей периодической переадресацией на портал. То есть клиент должен начать чувствовать дискомфорт, чтобы начать шевелиться, при этом диагностирование проблемы должно быть более сложным, чем уровень знаний подключенных клиентов (к счастью, по нынешним временам это не проблема ;-) ).

И тут уже должен подключаться маркетинг - позиционирование себя как провайдера, который care about your security and so fscking on, не держится за всех клиентов подряд, а беспокоится о спокойной работе всех остальных, и даже монетизировать "чудесное спасение" клиентов или привлекать этим месіджем других абонентов, взамен уходящих.

Ну то есть монетизировать и капитализировать ситуацию не просто нужно, но и можно :)

Впрочем, воспринимайте это как фантазии человека, несколько лет не работающего в SP и понятия не имеющего, как нынче строятся отношения с дорогими клиентами :)

-- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

---

discuss mailing list discuss@enog.org http://www.enog.org/mailman/listinfo/discuss

Есть «сарафанное радио», которое превращается в репутацию. Отмыться потом будет почти невозможно. Клиенты хостер-провайдеров – технические специалисты, либо имеющие таковых в своём штате. Они адекватно воспринимают проблему и могут её решить. Клиенты ISP – простые жители домохозяйств, реакция которых на ущемление их ожиданий от оплаченных 400 рублей будет совершенно другая. Вы будете виноваты в том, что у юзера возникла проблема, вы его не уберегли, а поэтому будете добры выехать на место и решить проблему, причём бесплатно. Иначе он уйдет на соседний плинт в распредкоробке к другому провайдеру и расскажет пяти друзьям/подругам. Маркетологи тут правы. Это давно уже наша проблема, абонент про неё знать даже не хочет, да и не может.

Дмитрий Мартынов

From: Pavel Odintsov [mailto:pavel.odintsov@gmail.com] Sent: Wednesday, October 14, 2015 2:06 PM To: Volodymyr Litovka Cc: discuss@enog.org Subject: Re: [ENOG discuss] идея/предложение обсудить - систему противодействия DDoS

Я вот другого не понимаю, средний платеж с клиента в хостинге в сотни раз больше чем у любого шпд провайдера. Но при этом у любого хостера есть кнопка пожаловаться, которая будет обработана в разумные сроки. И тут почему-то вполне нормально требовать даже от очень платящих клиентов срочного решения проблем. Так что с доводом про маркетологов носящихся за каждым клиентом условно по 400 рублей не уверен, что согласен.

On Wednesday, 14 October 2015, Volodymyr Litovka <doka.ua@gmail.commailto:doka.ua@gmail.com> wrote:

On 10/14/15 10:59 AM, Yura Scheglyuk wrote: Вы забыли про четвёртый пункт:

4. Отключенный клиент уходит к другому провайдеру.

Проходили это на своём опыте. Сначала тех.поддержка звонила заражённому клиенту и предупреждала о проблеме, рекомендовали установить антивирус. 95% абонентов просто забивала на это. Пробовали отключать особо заражённых клиентов - посыпались жалобы и угрозы уйти (и уходы) к другому провайдеру. У нас SCE, пробовали заражённым клиентам показывать страничку с предупреждением - тоже игнорировали.

Сейчас ограничили общую полосу NTP и DNS трафика, так что если и будет штормить, то не во всю мощь.

Как мне кажется, наиболее адекватным решением является не отключение (поскольку приводит к озлоблению, скандалу и, в конечном итоге, потере этого долбо^H^H^H^H^H клиента), а ограничение пропускной полосы для всего трафика (или - дропанье каждого пятого TCP/80 пакета :) ) с соответствующей периодической переадресацией на портал. То есть клиент должен начать чувствовать дискомфорт, чтобы начать шевелиться, при этом диагностирование проблемы должно быть более сложным, чем уровень знаний подключенных клиентов (к счастью, по нынешним временам это не проблема ;-) ).

И тут уже должен подключаться маркетинг - позиционирование себя как провайдера, который care about your security and so fscking on, не держится за всех клиентов подряд, а беспокоится о спокойной работе всех остальных, и даже монетизировать "чудесное спасение" клиентов или привлекать этим месіджем других абонентов, взамен уходящих.

Ну то есть монетизировать и капитализировать ситуацию не просто нужно, но и можно :)

Впрочем, воспринимайте это как фантазии человека, несколько лет не работающего в SP и понятия не имеющего, как нынче строятся отношения с дорогими клиентами :)

-- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

_______________________________________________ discuss mailing list discuss@enog.orgmailto:discuss@enog.org http://www.enog.org/mailman/listinfo/discuss

-- Sincerely yours, Pavel Odintsov

Как не так давно обсуждали в NANOG-овой рассылке, идея хорошая но не взлетевшая, мало кто зарегистрировался и почти никогда не используется.

И пока это дело добровольное, а не принудительное - так и будет, зарегистрированы будут только те, кто и так общается с коллегами в рассылках, конференциях и так далее, а остальные и знать не будут.

On 14.10.2015 15:42, Sergey Myasoedov wrote:

Вот буквально только что узнал о существовании такой штуки, как https://www.pch.net/services/INOC_DBA

Спасибо коллегам по ENOG-у.

-- Cheers, Sergey

...

Вместе с тем я полностью поддерживаю идею лучшей связности между NOC-ами и удивляюсь, почему RIR-ы еще не обязывают LIR-ов иметь обязательный зарегистрированный канал связи с другими LIR-ами с гарантированным ответом. Периодически появляются идеи на тему "а как бы сделать так, чтобы абузы читали, и noc отвечал", но пока это не будет обязаловкой для всех LIR-ов - не взлетит.

Проблема воздействия оператора на клиентов по таким вопросам как DDoS (и не только) не в том месте, в котором ее коллеги выше искали. У оператора нет страха отключить единичного абонента или как-то еще его «потерять».

Взаимодействие оператора с клиентами — это конвейер, всякого рода формальные и неформальные процедуры, однотипные действия, обработка заявок и т. д. И процедура типа «надавать по башке клиенту, за то что от него летит» — нестандартная работа, требующая отступления от типовых действий, вникания в детали, эскалации на уровень десижн-мейкеров и т. д. Не говоря уже о том, что стандартные клиентские договора как правило толком не регламентируют такого взаимодействия с клиентом. В них обычно написана какая-нибудь обтекаемая фигня вроде «в случае нарушения Абонентом законодательства РФ Оператор оставляет за собой право…», но понятно, что это нерабочая в практическом смысле формулировка, и никакой менеджер по работе с клиентами в здравом уме не пойдет добровольно доказывать клиенту, что тот нарушил закон (помимо всего, это объективно спорно).

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

Теоретически это могло бы решаться наличием в операторе специальных служб, которые бы занимались такого рода взаимодействиями с клиентами (привет Муслиму Меджлумову), но во-первых это уже дорого: требуется довольно высокая квалификация, плюс отлаживание процедур, во-вторых «ни у кого нет, а нам зачем?», в-третьих в реальной жизни большинство попыток ввести такую практику оканчивается спихиванием этой деятельности на разного рода ИБ-службы, в которых сидят классические ибэшники со всеми вытекающими.

-- Pavel Lunin Senetsy

14 октября 2015 г., 14:31 пользователь Мартынов Дмитрий Федорович < dfmarty1@mts.ru> написал:

Есть «сарафанное радио», которое превращается в репутацию. Отмыться потом будет почти невозможно.

Клиенты хостер-провайдеров – технические специалисты, либо имеющие таковых в своём штате. Они адекватно воспринимают проблему и могут её решить.

Клиенты ISP – простые жители домохозяйств, реакция которых на ущемление их ожиданий от оплаченных 400 рублей будет совершенно другая. Вы будете виноваты

в том, что у юзера возникла проблема, вы его не уберегли, а поэтому будете добры выехать на место и решить проблему, причём бесплатно. Иначе он уйдет на соседний плинт

в распредкоробке к другому провайдеру и расскажет пяти друзьям/подругам.

Маркетологи тут правы. Это давно уже наша проблема, абонент про неё знать даже не хочет, да и не может.

Дмитрий Мартынов

*From:* Pavel Odintsov [mailto:pavel.odintsov@gmail.com] *Sent:* Wednesday, October 14, 2015 2:06 PM *To:* Volodymyr Litovka *Cc:* discuss@enog.org *Subject:* Re: [ENOG discuss] идея/предложение обсудить - систему противодействия DDoS

Я вот другого не понимаю, средний платеж с клиента в хостинге в сотни раз больше чем у любого шпд провайдера. Но при этом у любого хостера есть кнопка пожаловаться, которая будет обработана в разумные сроки. И тут почему-то вполне нормально требовать даже от очень платящих клиентов срочного решения проблем. Так что с доводом про маркетологов носящихся за каждым клиентом условно по 400 рублей не уверен, что согласен.

On Wednesday, 14 October 2015, Volodymyr Litovka doka.ua@gmail.com wrote:

On 10/14/15 10:59 AM, Yura Scheglyuk wrote:

Вы забыли про четвёртый пункт:

4. Отключенный клиент уходит к другому провайдеру.

Проходили это на своём опыте. Сначала тех.поддержка звонила заражённому клиенту и предупреждала о проблеме, рекомендовали установить антивирус. 95% абонентов просто забивала на это. Пробовали отключать особо заражённых клиентов - посыпались жалобы и угрозы уйти (и уходы) к другому провайдеру. У нас SCE, пробовали заражённым клиентам показывать страничку с предупреждением - тоже игнорировали.

Сейчас ограничили общую полосу NTP и DNS трафика, так что если и будет штормить, то не во всю мощь.

Как мне кажется, наиболее адекватным решением является не отключение (поскольку приводит к озлоблению, скандалу и, в конечном итоге, потере этого долбо^H^H^H^H^H клиента), а ограничение пропускной полосы для всего трафика (или - дропанье каждого пятого TCP/80 пакета :) ) с соответствующей периодической переадресацией на портал. То есть клиент должен начать чувствовать дискомфорт, чтобы начать шевелиться, при этом диагностирование проблемы должно быть более сложным, чем уровень знаний подключенных клиентов (к счастью, по нынешним временам это не проблема ;-) ).

И тут уже должен подключаться маркетинг - позиционирование себя как провайдера, который care about your security and so fscking on, не держится за всех клиентов подряд, а беспокоится о спокойной работе всех остальных, и даже монетизировать "чудесное спасение" клиентов или привлекать этим месіджем других абонентов, взамен уходящих.

Ну то есть монетизировать и капитализировать ситуацию не просто нужно, но и можно :)

Впрочем, воспринимайте это как фантазии человека, несколько лет не работающего в SP и понятия не имеющего, как нынче строятся отношения с дорогими клиентами :)

-- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

---

discuss mailing list discuss@enog.org http://www.enog.org/mailman/listinfo/discuss

-- Sincerely yours, Pavel Odintsov

---

discuss mailing list discuss@enog.org http://www.enog.org/mailman/listinfo/discuss

Добрый день

15.10.2015, 15:38, "Sergey Afonin" asy@kraft-s.ru:

позиции (если всякие чёрные списки не учитывать, правда).

Возможно как-раз чёрными списками и можно решить проблему, с почтой же работает, а что если "прикрутить" их к DNS например.

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

В любом случае в ситуации с почтой они заставляют реагировать и операторов и конечных пользователей.