Это не баг, мы не ставили задачу знать всех провайдеров =). Но при этом — хорошая идея, отписался ниже, если поможете сделать такое соответствие — будет здорово.
За списком NS серверов нужно следить — это большая проблема. Опять же Вы правильно сказали — домены на других серверах есть не только у Вас, актуализировать информацию для ТОП 20 будет не очень сложно (далее сложнее), но это в любом случае ручная работа. Постоянно придется обновлять. В данном случае более корректно смотреть по количеству доменов на AS.
В текущей версии сайта — это вывод агрегированных данных из БД. Если есть желание, в понедельник могу набросать интерфейс для сопоставления NS, MX, сетей, AS c провайдером и предоставить его Вам =)
Проект открытый — его можно развивать и улучшать. Уже почти прикрутил историю скриншотов, среднее время отклика. Может получится уговорить Григория добивать его сервис проверки на вирусы =)
да, пользователям предоставляется все возможности tarantool, фактически запускается отдельная копия в docker контейнере Если его можно было бы использовать как прозрачную замену redis/memcache, даже без дополнительных возможностей, количество людей которые захотели бы его протестировать возросло. Целесообразность такого использования, как Вы заметили — уже другой вопрос.
Пол года назад начали тестировать Tarantool для внутренних проектов, потом выложили его как сервис на хостинге для своих клиентов. Но из-за отсутствия интеграции с CMS большим спросом он не пользовался. Я понимаю на текущий момент, он не совсем предназначается для рядовых пользователей, но планируется ли его использование/интеграция в популярные CMS?
Я не понимаю смысла RPF в данной ситуации, когда маршруты ко всем IP есть в таблице маршрутизации. Это тоже самое, что просто фильтр по src. Отлично — есть такая технология, только зачем ее применять данном контексте и как она поможет в данной ситуации? Заблокировать 200 IP адресов из ботнета в 1-10к машин, а потом послать IP в blackhole ?
Если трафик идет с подменой SRC на 1-10 серверов, Вы не сможете послать в blackhole все IP адреса серверов (все перестанет работать) локально, не локально разницы нет. Так же как и заблокировать рандомные адреса.
1) 200 хостов это мало
2) как раз, что бы не посылать в blackhole ip на котором располагается не один клиенты — мы увеличиваем емкость каналов (на текущий момент в 10 раз больше названного Вами значения) и делаем все возможное, что бы не посылать IP в blackhole. blackhole для нас не выход.
В любом случае статья не о том как заблокировать 200 IP или послать атакуемый IP в blackhole.
предположим, Ваша точка зрения правильная — маршрут до любого src есть и, фактически, это означает, что остается только правило "роут не указывает на null0 (если у отправителя next-hop discard (или null 0 на циске))". Что фактически превращается в кучу правил по маршрутизации src/dst. Даже если предположить, что нет подмены src и атака идет с большого ботнета, очень сильно разросшаяся таблица маршрутизации или фильтрации не принесен ничего хорошего.
По опыту полученных ddos'ов — довольно редко идёт подмена адреса источника.
— у меня совершенно другой опыт. И крайне редко идет без подмены src ip. Может кто собирал статистику?
На межоператорских стыках uRPF не включен — там асинхронная маршрутизация и полная связанность, то есть не факт, что пакет придя по одному каналу туда же и уйдет.
uRPF loose mode подразумевает — неважно откуда пришел пакет, если есть дорога обратно то он легитивен. У меня на роутере прилетает от пяти провайдеров full view, есть несколько маршрутов по умолчанию и т.д. то есть полная связанность. В данном случае uRPF мне не как не поможет.
syn flood идет с подменой адреса источника, не очень понял про "source-адреса флуда в комьюнити с локальным блэкхолом". DST IP можно отправить в blackhole, только не все IX принимают blackhole и в любом случае это приведет к большей недоступности чем данная блокировка.
В данном контексте — я не уверен, что IX и flow spec — это слова которые можно говорить в одном предложении. В России даже не все магистральные провайдеры его поддерживают.
1) Нет подобной возможности нету. И если честно, мы даже над ней не думали.
2) Для данной задачи больше подходят систему управления версиями (в планах было добавить поддержку git), нежели файловый менеджер. Там где это необходимо можно будет контролировать изменение файлов через git.
В текущей версии сайта — это вывод агрегированных данных из БД. Если есть желание, в понедельник могу набросать интерфейс для сопоставления NS, MX, сетей, AS c провайдером и предоставить его Вам =)
Если трафик идет с подменой SRC на 1-10 серверов, Вы не сможете послать в blackhole все IP адреса серверов (все перестанет работать) локально, не локально разницы нет. Так же как и заблокировать рандомные адреса.
1) 200 хостов это мало
2) как раз, что бы не посылать в blackhole ip на котором располагается не один клиенты — мы увеличиваем емкость каналов (на текущий момент в 10 раз больше названного Вами значения) и делаем все возможное, что бы не посылать IP в blackhole. blackhole для нас не выход.
В любом случае статья не о том как заблокировать 200 IP или послать атакуемый IP в blackhole.
В этом случае даже с этого источника другие сервисы будут работать. Но я еще раз повторюсь — это не идеальное решение, а только один из вариантов.
— у меня совершенно другой опыт. И крайне редко идет без подмены src ip. Может кто собирал статистику?
На межоператорских стыках uRPF не включен — там асинхронная маршрутизация и полная связанность, то есть не факт, что пакет придя по одному каналу туда же и уйдет.
uRPF loose mode подразумевает — неважно откуда пришел пакет, если есть дорога обратно то он легитивен. У меня на роутере прилетает от пяти провайдеров full view, есть несколько маршрутов по умолчанию и т.д. то есть полная связанность. В данном случае uRPF мне не как не поможет.
2) Для данной задачи больше подходят систему управления версиями (в планах было добавить поддержку git), нежели файловый менеджер. Там где это необходимо можно будет контролировать изменение файлов через git.