да, пользователям предоставляется все возможности 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.
В 2010 году мы не смогли найти двухпанельный web файловый менеджер, который нас так или иначе устраивал. Я не исключаю, возможно плохо искали. Единственно, что понравилось — это запуск web консоли и mc внутри, но это не совсем то, что нам было нужно. Перечислять аналоги NetFTP не вижу особого смысла.
На текущий момент около 1500 тестовых аккаунтов (за 2 дня). На хостинге в день до 1000 человек в FM заходят. По тестированию и безопасности сильно помогли, хорошая обратная связь. Спасибо !
Почему кнопка обновления на лого РКН похожа, кстати?
Не обращал на это внимание, но не думаю что РКН будет возражать =)
также хотел заметить, одна из TODO — это добавить web терминал, который будет работать с правами пользователя. Но, в любом случае, будем рады, если присоединитесь к разработке и поможете нам сделать Sprut.IO лучше.
Если трафик идет с подменой 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.
Не обращал на это внимание, но не думаю что РКН будет возражать =)