идея/предложение обсудить - систему противодействия DDoS
Всем привет!
Я получил письмо от участника ENOG, который предлагает к обсуждению идею. Он хотел было поднять вопрос на конференции, но у нас вообще-то еще не было сессии для высказывания мнений (вроде Birds of a Feather - BoF) по вопросу противодействия DDoS. В чем-то предложение наивно, но такой подход не должен быть предметом критики.
==================
Есть распределенная атака. С ней обычно борются на финальной точке, естественно, не справляются. Но зачем боротся с водопадом, когда можно перекрыть краник в начале?
Таким образом нужна система межоператорского взаимодействия (ANTIDDOS), возможно на основе RIPE.
RIPE предпочтителен, ибо к нему есть доверие у самих операторов. Система представляет из себя WEB интерфейс с простеньким софтом, который умеет проверять адреса на принадлежность к оператору и рассылать операторам письма. Операторы заводят в ней аккаунты (защищенные паролями, ключами и т.д.), и оставляют контактные данные.
Таким образом, усмирение атаки сводится к простому алгоритму: 1) Атакуемый оператор составляет список атакующих его адресов и загружает в систему. 2) Система проверяет принадлежность адресов различным операторам и рассылает им уведомления. 3) Операторы, из сети которых ведется атака, получают письма от системы со списком адресов и перекрывают этим адресам доступ в сеть, высылают им уведомления о необходимости проверки своих ПК и т.д.. Все, атака захлебнулась.... =)))
-- Kind regards, Sergey Myasoedov
Всем привет!
Данная тема уже давно реализована ребятами из CymRu: http://www.team-cymru.org/UTRS/
2015-10-13 17:25 GMT+03:00 Sergey Myasoedov sergey@devnull.ru:
Всем привет!
Я получил письмо от участника ENOG, который предлагает к обсуждению идею. Он хотел было поднять вопрос на конференции, но у нас вообще-то еще не было сессии для высказывания мнений (вроде Birds of a Feather - BoF) по вопросу противодействия DDoS. В чем-то предложение наивно, но такой подход не должен быть предметом критики.
==================
Есть распределенная атака. С ней обычно борются на финальной точке, естественно, не справляются. Но зачем боротся с водопадом, когда можно перекрыть краник в начале?
Таким образом нужна система межоператорского взаимодействия (ANTIDDOS), возможно на основе RIPE.
RIPE предпочтителен, ибо к нему есть доверие у самих операторов. Система представляет из себя WEB интерфейс с простеньким софтом, который умеет проверять адреса на принадлежность к оператору и рассылать операторам письма. Операторы заводят в ней аккаунты (защищенные паролями, ключами и т.д.), и оставляют контактные данные.
Таким образом, усмирение атаки сводится к простому алгоритму:
- Атакуемый оператор составляет список атакующих его адресов и загружает в систему.
- Система проверяет принадлежность адресов различным операторам и рассылает им уведомления.
- Операторы, из сети которых ведется атака, получают письма от системы со списком адресов и
перекрывают этим адресам доступ в сеть, высылают им уведомления о необходимости проверки своих ПК и т.д.. Все, атака захлебнулась.... =)))
-- Kind regards, Sergey Myasoedov _______________________________________________ discuss mailing list discuss@enog.org http://www.enog.org/mailman/listinfo/discuss
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...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...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
И если адрес подменён, то это не помогает. А так реализовано большинство DDoS атак.
-----Original Message----- From: Sergey Myasoedov [mailto:sergey@devnull.ru] Sent: Tuesday, October 13, 2015 5:26 PM To: discuss@enog.org Subject: [ENOG discuss] идея/предложение обсудить - систему противодействия DDoS
Всем привет!
Я получил письмо от участника 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
Всем привет!
Хороший контингент собрался :)
Имхо, раз мы тут собрались и дата центры и операторы, то решать нужно наши проблемы.
Медленные и application layer флуды - это проблемы оконечников, которые в подавляющем большинстве случаев оператор заметить не в силах и они не представляют опасности.
А вот огромные амплификации, юдп флуды со спуфингом и син флуды - могут вывести из игры почти любого, вопрос в деньгах вложенных в реализацию атаки. И их митигация крайне занятный вопрос.
2015-10-13 17:55 GMT+03:00 Крупко Роман Александрович rakrupko@mts.ru:
И если адрес подменён, то это не помогает. А так реализовано большинство DDoS атак.
-----Original Message----- From: Sergey Myasoedov [mailto:sergey@devnull.ru] Sent: Tuesday, October 13, 2015 5:26 PM To: discuss@enog.org Subject: [ENOG discuss] идея/предложение обсудить - систему противодействия DDoS
Всем привет!
Я получил письмо от участника ENOG, который предлагает к обсуждению идею. Он хотел было поднять вопрос на конференции, но у нас вообще-то еще не было сессии для высказывания мнений (вроде Birds of a Feather - BoF) по вопросу противодействия DDoS. В чем-то предложение наивно, но такой подход не должен быть предметом критики.
==================
Есть распределенная атака. С ней обычно борются на финальной точке, естественно, не справляются. Но зачем боротся с водопадом, когда можно перекрыть краник в начале?
Таким образом нужна система межоператорского взаимодействия (ANTIDDOS), возможно на основе RIPE.
RIPE предпочтителен, ибо к нему есть доверие у самих операторов. Система представляет из себя WEB интерфейс с простеньким софтом, который умеет проверять адреса на принадлежность к оператору и рассылать операторам письма. Операторы заводят в ней аккаунты (защищенные паролями, ключами и т.д.), и оставляют контактные данные.
Таким образом, усмирение атаки сводится к простому алгоритму:
- Атакуемый оператор составляет список атакующих его адресов и загружает в систему.
- Система проверяет принадлежность адресов различным операторам и рассылает им уведомления.
- Операторы, из сети которых ведется атака, получают письма от системы со списком адресов и
перекрывают этим адресам доступ в сеть, высылают им уведомления о необходимости проверки своих ПК и т.д.. Все, атака захлебнулась.... =)))
-- Kind regards, Sergey Myasoedov _______________________________________________ discuss mailing list discuss@enog.org http://www.enog.org/mailman/listinfo/discuss _______________________________________________ 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 будет из сети этого же оператора. Тут уже есть шанс найти. Отдельный вопрос с магистралами, но это меньшие количественные (в пользователях) объёмы.
Третий вариант в голову не приходит.
Приветствую !
К сожалению не вариант. Я последнее время все больше замечаю именно совсем маломощные источники, которые при этом еще и меняются. Т.е. слегка усложнить возможно, но полностью отрезать, да еще и чтобы атака не была действенной - не получится, просто маломощных источников будет еще больше.
Вычищать их тоже не вариант, потому что провайдеры поменять рутера всем своим клиентам не смогут, а если и смогут - то на что ? Софт для 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 интерфейс с простеньким софтом, который умеет проверять адреса на принадлежность к оператору и рассылать операторам письма. Операторы заводят в ней аккаунты (защищенные паролями, ключами и т.д.), и оставляют контактные данные.
Таким образом, усмирение атаки сводится к простому алгоритму:
- Атакуемый оператор составляет список атакующих его адресов и загружает в систему.
- Система проверяет принадлежность адресов различным операторам и рассылает им уведомления.
- Операторы, из сети которых ведется атака, получают письма от системы со списком адресов и
перекрывают этим адресам доступ в сеть, высылают им уведомления о необходимости проверки своих ПК и т.д.. Все, атака захлебнулась.... =)))
-- Kind regards, Sergey Myasoedov _______________________________________________ discuss mailing list discuss@enog.org http://www.enog.org/mailman/listinfo/discuss
On Tuesday 13 October 2015, Sergey Myasoedov wrote:
- Операторы, из сети которых ведется атака, получают письма от системы
со списком адресов и перекрывают этим адресам доступ в сеть, высылают им уведомления о необходимости проверки своих ПК и т.д..
Тут вот видится слабое место. Иногда возникает необходимость достучаться до abuse@. Задача, далеко не всегда, решается тривиально. Хотя когда-то, лет так 15 назад, всё это работало. Но пришёл большой и массовый бизнес, и деньги стали сильно важнее, чем чтение какого-то там abuse@. Да и, вообще, изучение RFC 2142 (Mailbox Names for Common Services, Roles and Functions).
Hi!
On 13.10.2015 21:25, Sergey Myasoedov wrote:
Таким образом, усмирение атаки сводится к простому алгоритму:
- Атакуемый оператор составляет список атакующих его адресов и загружает в систему.
- Система проверяет принадлежность адресов различным операторам и рассылает им уведомления.
- Операторы, из сети которых ведется атака, получают письма от системы со списком адресов и
перекрывают этим адресам доступ в сеть, высылают им уведомления о необходимости проверки своих ПК и т.д.. Все, атака захлебнулась.... =)))
Вы забыли про четвёртый пункт:
4. Отключенный клиент уходит к другому провайдеру.
Проходили это на своём опыте. Сначала тех.поддержка звонила заражённому клиенту и предупреждала о проблеме, рекомендовали установить антивирус. 95% абонентов просто забивала на это. Пробовали отключать особо заражённых клиентов - посыпались жалобы и угрозы уйти (и уходы) к другому провайдеру. У нас SCE, пробовали заражённым клиентам показывать страничку с предупреждением - тоже игнорировали.
Сейчас ограничили общую полосу NTP и DNS трафика, так что если и будет штормить, то не во всю мощь.
Всем привет!
Люто двачую за рейт лимитинг амплифицирующих портов от клиентов и жму руку.
Это очень эффективный и при этом недеструктивный способ сокращения потоков зловредного трафика летящих из сетей.
Аналогичный подход можно использовать и для входящего трафика, чтобы не заливать уровень аксеса гигабитами паразитного трафика.
On Wednesday, 14 October 2015, Yura Scheglyuk yura-ml@rikt.ru wrote:
Hi!On 13.10.2015 21:25, Sergey Myasoedov wrote:
Таким образом, усмирение атаки сводится к простому алгоритму:
- Атакуемый оператор составляет список атакующих его адресов и загружает
в систему. 2) Система проверяет принадлежность адресов различным операторам и рассылает им уведомления. 3) Операторы, из сети которых ведется атака, получают письма от системы со списком адресов и перекрывают этим адресам доступ в сеть, высылают им уведомления о необходимости проверки своих ПК и т.д.. Все, атака захлебнулась.... =)))
Вы забыли про четвёртый пункт:
- Отключенный клиент уходит к другому провайдеру.
Проходили это на своём опыте. Сначала тех.поддержка звонила заражённому клиенту и предупреждала о проблеме, рекомендовали установить антивирус. 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-ов - не взлетит.
Вот буквально только что узнал о существовании такой штуки, как https://www.pch.net/services/INOC_DBA
Спасибо коллегам по ENOG-у.
-- Cheers, Sergey
Вместе с тем я полностью поддерживаю идею лучшей связности между NOC-ами и удивляюсь, почему RIR-ы еще не обязывают LIR-ов иметь обязательный зарегистрированный канал связи с другими LIR-ами с гарантированным ответом. Периодически появляются идеи на тему "а как бы сделать так, чтобы абузы читали, и noc отвечал", но пока это не будет обязаловкой для всех LIR-ов - не взлетит.
Как не так давно обсуждали в 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-ов - не взлетит.
не летает уже
On Oct 14, 2015, at 4:18 PM, Stepan Kucherenko twh@megagroup.ru wrote:
Как не так давно обсуждали в 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-ов - не взлетит.
discuss mailing list discuss@enog.org http://www.enog.org/mailman/listinfo/discuss
Всем привет. На мой взгляд, самое простое и в то же время эффективное решение - настройка сигнатур на стороне провайдерских/датацентровских IDS для исходящего трафика. Главным образом - рейтлимит вот этого : https://www.us-cert.gov/ncas/alerts/TA14-017A Ну и, разумеется, запрет спуфинга + мониторинг своей сети на предмет аномалий наряду с адекватной настройкой лимитов. И не нужны никакие дополнительные телодвижения и решения вроде Cloud-based DDoS Mitigation от Arbor :)
14.10.2015, 11:03, "Yura Scheglyuk" yura-ml@rikt.ru:
Hi!
On 13.10.2015 21:25, Sergey Myasoedov wrote:
Таким образом, усмирение атаки сводится к простому алгоритму: 1) Атакуемый оператор составляет список атакующих его адресов и загружает в систему. 2) Система проверяет принадлежность адресов различным операторам и рассылает им уведомления. 3) Операторы, из сети которых ведется атака, получают письма от системы со списком адресов и перекрывают этим адресам доступ в сеть, высылают им уведомления о необходимости проверки своих ПК и т.д.. Все, атака захлебнулась.... =)))
Вы забыли про четвёртый пункт:
- Отключенный клиент уходит к другому провайдеру.
Проходили это на своём опыте. Сначала тех.поддержка звонила заражённому клиенту и предупреждала о проблеме, рекомендовали установить антивирус. 95% абонентов просто забивала на это. Пробовали отключать особо заражённых клиентов - посыпались жалобы и угрозы уйти (и уходы) к другому провайдеру. У нас SCE, пробовали заражённым клиентам показывать страничку с предупреждением - тоже игнорировали.
Сейчас ограничили общую полосу NTP и DNS трафика, так что если и будет штормить, то не во всю мощь.
-- С уважением, Щеглюк Юрий
discuss mailing list discuss@enog.org http://www.enog.org/mailman/listinfo/discuss
On 10/14/15 10:59 AM, Yura Scheglyuk wrote:
Вы забыли про четвёртый пункт:
- Отключенный клиент уходит к другому провайдеру.
Проходили это на своём опыте. Сначала тех.поддержка звонила заражённому клиенту и предупреждала о проблеме, рекомендовали установить антивирус. 95% абонентов просто забивала на это. Пробовали отключать особо заражённых клиентов - посыпались жалобы и угрозы уйти (и уходы) к другому провайдеру. У нас SCE, пробовали заражённым клиентам показывать страничку с предупреждением - тоже игнорировали.
Сейчас ограничили общую полосу NTP и DNS трафика, так что если и будет штормить, то не во всю мощь.
Как мне кажется, наиболее адекватным решением является не отключение (поскольку приводит к озлоблению, скандалу и, в конечном итоге, потере этого долбо^H^H^H^H^H клиента), а ограничение пропускной полосы для всего трафика (или - дропанье каждого пятого TCP/80 пакета :) ) с соответствующей периодической переадресацией на портал. То есть клиент должен начать чувствовать дискомфорт, чтобы начать шевелиться, при этом диагностирование проблемы должно быть более сложным, чем уровень знаний подключенных клиентов (к счастью, по нынешним временам это не проблема ;-) ).
И тут уже должен подключаться маркетинг - позиционирование себя как провайдера, который care about your security and so fscking on, не держится за всех клиентов подряд, а беспокоится о спокойной работе всех остальных, и даже монетизировать "чудесное спасение" клиентов или привлекать этим месіджем других абонентов, взамен уходящих.
Ну то есть монетизировать и капитализировать ситуацию не просто нужно, но и можно :)
Впрочем, воспринимайте это как фантазии человека, несколько лет не работающего в SP и понятия не имеющего, как нынче строятся отношения с дорогими клиентами :)
Я вот другого не понимаю, средний платеж с клиента в хостинге в сотни раз больше чем у любого шпд провайдера. Но при этом у любого хостера есть кнопка пожаловаться, которая будет обработана в разумные сроки. И тут почему-то вполне нормально требовать даже от очень платящих клиентов срочного решения проблем. Так что с доводом про маркетологов носящихся за каждым клиентом условно по 400 рублей не уверен, что согласен.
On Wednesday, 14 October 2015, Volodymyr Litovka doka.ua@gmail.com wrote:
On 10/14/15 10:59 AM, Yura Scheglyuk wrote:
Вы забыли про четвёртый пункт:
- Отключенный клиент уходит к другому провайдеру.
Проходили это на своём опыте. Сначала тех.поддержка звонила заражённому клиенту и предупреждала о проблеме, рекомендовали установить антивирус. 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
Так вот я как раз и говорю - незачем бояться ухода абонентов. Они всё равно волнами шляются туда-сюда.
Маркетинг должен повышать ревеню. То есть маркетинг бессмысленен, если клиенты платят по 400р. Маркетинг должен сделать так, чтобы клиенты платили 800р, а лучше - 1600р. Разумеется, для этого у провайдера должна быть техническая база, но почва подготовлена - Касперский и Госдура уже сделали своё дело и средний обыватель считает Интернет не даром божьим, а дьявольской приманкой ;-) этим надо пользоваться и маркетировать свой доступ, как обработанный если не святой водой, то хотя бы серебрянными фильтрами :)
On 10/14/15 2:06 PM, Pavel Odintsov wrote:
Я вот другого не понимаю, средний платеж с клиента в хостинге в сотни раз больше чем у любого шпд провайдера. Но при этом у любого хостера есть кнопка пожаловаться, которая будет обработана в разумные сроки. И тут почему-то вполне нормально требовать даже от очень платящих клиентов срочного решения проблем. Так что с доводом про маркетологов носящихся за каждым клиентом условно по 400 рублей не уверен, что согласен.
On Wednesday, 14 October 2015, Volodymyr Litovka <doka.ua@gmail.com mailto: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
Есть «сарафанное радио», которое превращается в репутацию. Отмыться потом будет почти невозможно. Клиенты хостер-провайдеров – технические специалисты, либо имеющие таковых в своём штате. Они адекватно воспринимают проблему и могут её решить. Клиенты 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
Проблема воздействия оператора на клиентов по таким вопросам как 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:
Вы забыли про четвёртый пункт:
- Отключенный клиент уходит к другому провайдеру.
Проходили это на своём опыте. Сначала тех.поддержка звонила заражённому клиенту и предупреждала о проблеме, рекомендовали установить антивирус. 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
On Wednesday 14 October 2015, Мартынов Дмитрий Федорович wrote:
Вы будете виноваты в том, что у юзера возникла проблема, вы его не уберегли, а поэтому будете добры выехать на место и решить проблему, причём бесплатно.
Это плохо, что они так думают. И мы сами до этого довели. Хотя вот, лично я, всегда разъясню клиенту, кто тут крайний (если так получается, что мне таки приходится общаться с клиентом ;-) ).
Хороший, кстати, действующий пример - это автомобиль и необходимость выучить и соблюдать ПДД. Можно купить авто, но надо иметь необходимые навыки для управления вне зависимости от своей основной специальности, или нанимать водителя. С компьютером, который подключен в глобальную сеть, совершенно аналогично - или учись, или нанимай сисадмина.
Иначе он уйдет на соседний плинт в распредкоробке к другому провайдеру и расскажет пяти друзьям/подругам.
Разъяснять клиентам зону ответственности надо всем вместе. Провайдер, который забьёт на жалобы, будет, конечно, в несколько более выгодной позиции (если всякие чёрные списки не учитывать, правда). А вот если все будут говорить об ответственности одно и то же, пользователь будет понимать, что "здесь вам не тут". Кто-то туда-сюда побегает, конечно, но это быстро устаканится.
Если же какой-то оператор сможет наладить службу бесплатной поддержки при современных тарифах, это я хотел бы посмотреть, на какие средства.
Добрый день
15.10.2015, 15:38, "Sergey Afonin" asy@kraft-s.ru:
позиции (если всякие чёрные списки не учитывать, правда).
Возможно как-раз чёрными списками и можно решить проблему, с почтой же работает, а что если "прикрутить" их к DNS например.
Возможно больше помогут "серые" списки или некий аналог SPF, попадание запросов в низко-приоритетную очередь, например.
В любом случае в ситуации с почтой они заставляют реагировать и операторов и конечных пользователей.
MX записи меняются немного реже чем адреса в Dynamic NAT если я вас правильно понял
On 15 Oct 2015, at 15:50, Konstantin V Bekreyev enog-discuss@bekreyev.ru wrote:
Добрый день
15.10.2015, 15:38, "Sergey Afonin" asy@kraft-s.ru:
позиции (если всякие чёрные списки не учитывать, правда).
Возможно как-раз чёрными списками и можно решить проблему, с почтой же работает, а что если "прикрутить" их к DNS например.
Возможно больше помогут "серые" списки или некий аналог SPF, попадание запросов в низко-приоритетную очередь, например.
В любом случае в ситуации с почтой они заставляют реагировать и операторов и конечных пользователей.
-- С уважением, Бекреев Константин Валерьевич Internet Society, Russia http://isocru.org/
discuss mailing list discuss@enog.org http://www.enog.org/mailman/listinfo/discuss
Best Regards, Yaroslav
participants (16)
-
Alexandre Snarskii -
Andrey Korolyov -
Burkov Dmitry -
Konstantin V Bekreyev -
Pavel Lunin -
Pavel Odintsov -
Sergey Afonin -
Sergey Myasoedov -
Sergey Y. Afonin
-
Stepan Kucherenko -
Volodymyr Litovka -
Yaroslav -
Yura Scheglyuk -
Але -
Крупко Роман Александро вич -
Мартынов Дмитрий Федоро вич