У маленьких хостингов нет своих сетей, они берут в аренду IP адреса у тех же дата-центров. У более или менее больших — почти всегда есть своя AS.
Без своей AS невозможно управлять связанностью, балансировать мощные DDOS, оптимизировать маршруты, создавать CDN, решать проблемы плохих маршрутов. Я уже не говорю о банальном переезде в другой ДЦ. На определенной стадии развития хостингу необходима собственная AS и если посмотреть статистику у всех крупных хостингов есть своя AS. Это один из компонентов качества услуги.
Это не баг, мы не ставили задачу знать всех провайдеров =). Но при этом — хорошая идея, отписался ниже, если поможете сделать такое соответствие — будет здорово.
За списком 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 — это слова которые можно говорить в одном предложении. В России даже не все магистральные провайдеры его поддерживают.
Без своей AS невозможно управлять связанностью, балансировать мощные DDOS, оптимизировать маршруты, создавать CDN, решать проблемы плохих маршрутов. Я уже не говорю о банальном переезде в другой ДЦ. На определенной стадии развития хостингу необходима собственная AS и если посмотреть статистику у всех крупных хостингов есть своя AS. Это один из компонентов качества услуги.
В текущей версии сайта — это вывод агрегированных данных из БД. Если есть желание, в понедельник могу набросать интерфейс для сопоставления 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 мне не как не поможет.