[saaremaa]

По своему опыту: DNS flood не представляет проблемы для оборудования, его опасность только в забивании канала.

Интересно пообщаться и ознакомиться с вашим опытом на эту тему.

Да собственно опыта не особо. По этой причине и страдаем.

DNS flood действительно не проблема - мы просто запретили размещать своим клиентам(физлица) DNS и блокируем dst.port=53 из магистрали.

По остальным сделали так. Контролируем на магистрали pps и количество соединений с одного ip(это очень дорогая операция в отношении процессорного времени) при превышении определенных значений src.ip заносится в list на блокировку.

 

• TCP -> reject
  
• UDP -> message "port unreachable"
  

 

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

[snvoronkov]

По своему опыту: DNS flood не представляет проблемы для оборудования, его опасность только в забивании канала.

Интересно пообщаться и ознакомиться с вашим опытом на эту тему.

Плохой опыт. Не всякий PPPoE-BRAS пережует несколько сот тысяч пакетов в секунду без деградации сервиса.

А с PPPoE не слезть пока никак. Операторов, предоставляющих выход в сеть альтернативными методами пользователи просто держат за маргиналов.

Defacto, в городе все предоставляют выход в сеть именно через него.

[snvoronkov]

DimaM, по зрелому размышлению, достаточно было-бы предложить в СКАТ Complete кроме полисинга по полосе еще и полисинг по PPS.

[DimaM]

достаточно было-бы предложить в СКАТ Complete кроме полисинга по полосе еще и полисинг по PPS

 

как вариант возможно, но имеет недостаток: наряду с атакующими пакетами будут выкинуты хорошие

[snvoronkov]

достаточно было-бы предложить в СКАТ Complete кроме полисинга по полосе еще и полисинг по PPS

 

как вариант возможно, но имеет недостаток: наряду с атакующими пакетами будут выкинуты хорошие

Их и при ограничении по полосе выкинут. А так можно было бы и лимит DNS пакетов классом ввести - пусть амплификаторы удавятся. :-)

[snvoronkov]

По флуду, который меня достал: лупят в клиента udp с рандомных ip (не верю я в ботнет из 500000+ узлов для замачивания игрунчика в контру) пакетом в 85 байт.

 

На СКАТ инструмента блокировки нет. Тоска.

[DimaM]

По флуду, который меня достал: лупят в клиента udp с рандомных ip

 

Вы уверены, что это dns? Пришлите в ТП pcap с записью атаки.

[snvoronkov]

По флуду, который меня достал: лупят в клиента udp с рандомных ip

 

Вы уверены, что это dns? Пришлите в ТП pcap с записью атаки.

Уверен, что нет.

 

Флуд идёт с рандомных ip/port в ip клиента и один какой-то порт. Идёт с одного из московских узлов обмена, по информации апстрима. Мощность - от 120 до 1500 mbps пакетом до 100 байт.

[DimaM]

Очень хотелось-бы увидеть что-то типа такого (ограничения по pps до различных маршрутизаторов)

00:11:11:00:11:12 udp * 53 10000

------------

Не всякий PPPoE-BRAS пережует несколько сот тысяч пакетов в секунду

------------

По флуду, который меня достал: лупят в клиента udp с рандомных ip

Вы уверены, что это dns?

Уверен, что нет.

 

53 порт - это dns.

На всякий случай - речь уже о другой атаке или все о той же?

 

Флуд идёт с рандомных ip/port в ip клиента и один какой-то порт

 

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

 

PS

Странно, что спустя 15 лет после RFC2827 и RFC3704 все еще находятся провайдеры, который не блокируют IP Source Address Spoofing. Это же просто, а не блокировать подделку адресов - это как себе в ногу стрелять, не говоря про неуважением и вредительство другим провайдерам. Найти бы этого прова, да по голове настучать.

 

Идёт с одного из московских узлов обмена

 

Точки обмена трафиком тоже должны от подмены IP защищать. На своих конференциях тот же MSK-IX преподносит это как преимущество IX.

Надо хотя бы с точкой обмена связаться, узнать почему они такое допускают.

[snvoronkov]

53 порт - это dns.

На всякий случай - речь уже о другой атаке или все о той же?

Это пример хотелок. :-)

...все еще находятся провайдеры, который не блокируют IP Source Address Spoofing.

Дмитрий, Вы, видимо, неисправимый оптимист. :-)))

 

Они не находятся, они такими специально создаются.

 

Точки обмена трафиком тоже должны от подмены IP защищать. На своих конференциях тот же MSK-IX преподносит это как преимущество IX.

Надо хотя бы с точкой обмена связаться, узнать почему они такое допускают.

После несколько более пристрастного распроса апстрима выяснил, что таки не с IX (а он, кстати, не обязательно MSK-IX), а от одного из их аплинков. К ним самим оттуда уже прилетало. В тот раз крайней точкой, докуда оттрассировали флуд, был "Великий Китайский Фаервол".

[saaremaa]

Пришло от Вас письмо. Прокомментируйте пожалуйста абзац:

Фильтрация по ФЗ не является основным применением нашего решения, наша миссия дать операторам связи качественный отечественный DPI.

 

На всякий случай весь текст для понимания общего контекста.

Добрый день, благодарим вас за интерес к продукту СКАТ.

 

Как Вы знаете, 7 октября 2015 года Роскомнадзор внес изменения в правила ограничения доступа к ресурсам сети интернет (распоряжение от 23 июля 2013 г. № 18), дополнив Рекомендации пунктами 5 - 7 следующего содержания:

 

5. При наличии в выгрузке информации об указателе страницы сайта в сети «Интернет», доменном имени и сетевом адресе операторам связи рекомендуется ограничивать доступ непосредственно к указателю страницы сайта в сети «Интернет».

Необходимо фильтровать по URL в случае HTTP.

6. При наличии в выгрузке информации о доменном имени и сетевом адресе и отсутствии информации об указателе страницы сайта в сети «Интернет», операторам связи рекомендуется ограничивать доступ ко всему информационному ресурсу, включая доменные имена нижестоящего уровня относительно доменного имени, указанного в выгрузке. При этом ограничение доступа к доменным именам вышестоящего уровня не осуществляется.

Блокировать все URL, которые находятся в определённом домене.

7. При наличии в записи выгрузки информации о сетевом адресе, либо ip-подсети (заданный диапазон сетевых адресов), и отсутствии информации о доменном имени и указателе страницы сайта в сети «Интернет», операторам связи рекомендуется ограничивать доступ к указанному сетевому адресу, либо ip-подсети, включая все сетевые порты.

Блокировать любые связки IP-порт, а не только 80 и 443.

Ранее мы делали обзор последней версии СКАТ 3.0, в которой поддерживается выполнение всех этих требований.

 

Фильтрация по ФЗ не является основным применением нашего решения, наша миссия дать операторам связи качественный отечественный DPI.

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

[DimaM]

Фильтрация по ФЗ не является основным применением нашего решения, наша миссия дать операторам связи качественный отечественный DPI

 

Этот текст вижу впервые, но все-равно прокомментирую:

1) сообщение носит информационный характер, на случай если кто-то пропустил последние нововведения

2) некоторые из клиентов используют dpi в самом "бесполезном и ненужном" виде - для фильтрации по реестру РКН,

такое неполноценное использование dpi не выгодно ни нам, ни вам (см. обсуждение к статье "Экономика DPI") но .. мысль автора скомкалась и оборвалась в связи с окончанием рабочего дня, наверное продолжение следует :)

Изменено 8 декабря, 2015 пользователем DimaM

[DimaM]

DimaM (24 ноября 2015 - 11:56) писал:

Странно, что спустя 15 лет после RFC2827 и RFC3704 все еще находятся провайдеры, который не блокируют IP Source Address Spoofing.

 

Дмитрий, Вы, видимо, неисправимый оптимист. :-)))

Они не находятся, они такими специально создаются.

 

Анонимно проверил 5 крупных российских провайдеров, и всего 1 защищает от спуфинга.

Похоже я действительно оптимист, но если провайдеры сами не делают даже элементарные вещи,

позволяя, чтобы их коллег и в итоге их самих атаковали досеры, то сами и дураки. НЕ?

[snvoronkov]

Похоже я действительно оптимист, но если провайдеры сами не делают даже элементарные вещи,

позволяя, чтобы их коллег и в итоге их самих атаковали досеры, то сами и дураки. НЕ?

Лентяи (фильтры писать) и жмоты (меньше нагрузка - меньше железа) просто.

 

А вчера вон пожаловались, что из-за таких вот с 30-го на 1-ое рутовые сервера почти положили. (Новость на опеннете -https://www.opennet.ru/opennews/art.shtml?num=43494)

 

P.S.: Про инструмент-то для ограничения PPS не думали?

[man781]

1. Умеет ли СКАТ среди прочего осуществлять функции типа "родительского контроля".

Типа юзер в кабинете выбирает категории фильтрации самостоятельно. (и эти категории постоянно кто-то наполняет/актуализирует) (Кто ?:)

 

2. И если п.1 = да, то каким образом интеграция с биллингом (хотя бы чтобы юзерский ип взять при логине (юзерские ипы белые динамические, терминируются на BRAS SE600))

 

3. При выборе СКАТ на какой трафик ориентироваться (входящий или исходящий) ? (для функции фильтрации по спискам, DPI)

 

4. QoS по типу трафика внутри полосы юзера работает только если СКАТ выступает в роли BRAS (трафик юзеров идет через СКАТ), или зеркалированный траф с другого BRAS тоже можно ?

[DimaM]

1. Умеет ли СКАТ среди прочего осуществлять функции типа "родительского контроля".

Типа юзер в кабинете выбирает категории фильтрации самостоятельно. (и эти категории постоянно кто-то наполняет/актуализирует) (Кто ?:)

 

Когда то пытались продавать "родительский контроль", но это оказалось абсолютно непродаваемой вещью.

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

(но это больше подойдет для "школьного интернет", т.к. списки DIY). Категоризация сайтов появится где-то в 2016 г.

 

2. И если п.1 = да, то каким образом интеграция с биллингом (хотя бы чтобы юзерский ип взять при логине (юзерские ипы белые динамические, терминируются на BRAS SE600))

 

Интеграция осуществляется по логину, актуальный IP извлекается методом прослушивания Radius трафика.

 

3. При выборе СКАТ на какой трафик ориентироваться (входящий или исходящий) ? (для функции фильтрации по спискам, DPI)

 

Для фильтрации достаточно исходящего или даже зеркалированного исходящего. Но лучше слушать обе стороны, т.к. тогда возможна фильтрация

без привязки к IP (по сертификатам).

 

4. QoS по типу трафика внутри полосы юзера работает только если СКАТ выступает в роли BRAS (трафик юзеров идет через СКАТ), или зеркалированный траф с другого BRAS тоже можно ?

 

Для QOS СКАТ нужно включать в линию после терминации (если это не IPoE) в дополнение или вместо BRAS.

PS Зеркалированный трафик тоже можно отполисить или разметить, вот только что потом с ним делать, это же дубликат ? :)

[man781]

У нас и сейчас есть родительский контроль. И он даже бесплатный не взлетает вообще. Да и обходится легко. Основан на фильтрации днс. Вот и думаем что-то то более крутое.

Но ставить софтовый тазик в разрыв стремно. Точка откази и проблем. А так железный брас молотит и в ус не дует.

Так вот уточнение. Можно ли обойтись только зеркалированием чтобы хотя бы от фильтровать чёрные списки и поджать торрент в чнн

Для справки - входящий трафик приближается к 10 гигам в сек

[DimaM]

Можно ли обойтись только зеркалированием чтобы хотя бы от фильтровать чёрные списки и поджать торрент в чнн

 

отфильтровать на зеркале можно, поджать торрент нет

 

Но ставить софтовый тазик в разрыв стремно. Точка откази и проблем. А так железный брас молотит и в ус не дует.

 

Железные брасы не торт, правильные операторы используют приоретизацию по протоколам

в абонентской полосе, которую дает dpi (там же тоже своя "полка", в которую легко упрется абонент

когда начнет что-то качать). С точки зрения абонентов такой интернет "более качественный",

а это уже конкурентное преимущество.

Как пример http://vasexperts.ru/sevstar-uspeh.php 3 x СКАТ-40

[man781]

Железные брасы не торт

Это спорный момент.

Кроме приоритезации в абонентской полосе есть куча нюансов обслуживания.

Когда мы слезли с десятка тазиков на один брас - я вздохнул с облегчением.

Конфигурить одну железку - это прелестно.

Настроил один раз - и она год молотит.

Ни одно ребута.

 

Как-то я не готов снова на тазики....

[alibek]

Как-то я не готов снова на тазики....

Разумеется что производитель будет предлагать свое решение повсюду.

Но справедливости ради, тут не идет речь о том, чтобы переносить абонентов на тазики.

DPI трафик в первую очередь классифицирует. А кто и как будет этот трафик шейпить (СКАТ в разрыве линка или маршрутизатор/бордер) это уже дело второе.

[man781]

ну так сверху уже ответили - для использования qos/шейпинга - трафик нужно пропускать через скат

(т.е. такая нехилая точка отказа и неожиданных граблей/нюансов)

И если бы трафика было гиг-два - то нестрашно через тазик пускать, а так уже 10Г, и пока каждый год удвоение.

[DimaM]

Конфигурить одну железку - это прелестно.

Настроил один раз - и она год молотит.

Ни одно ребута.

 

 

Это же про СКАТ :)

10Г входящего это почти ни о чем, выше приводил пример оператора с 3мя СКАТ-40

[man781]

вы и мертвого уговорите

(как сааб95 на микротики :)

[Inp]

1. Умеет ли СКАТ среди прочего осуществлять функции типа "родительского контроля".

Типа юзер в кабинете выбирает категории фильтрации самостоятельно. (и эти категории постоянно кто-то наполняет/актуализирует) (Кто ?:)

 

Когда то пытались продавать "родительский контроль", но это оказалось абсолютно непродаваемой вещью.

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

(но это больше подойдет для "школьного интернет", т.к. списки DIY). Категоризация сайтов появится где-то в 2016 г.

 

 

 

Подскажите, как скоро выйдет декабрьский релиз с фильтрацией по индивидуальным спискам

[DimaM]

вы и мертвого уговорите

 

за "тазики" обидно :)

PS на Северо-Западе СКАТ обслуживает 1,5 млн абонентов