Комментарии 29
Сколько миллионов flow эта штука способна обработать в час?
Как контроллер — больше 100К flows/sec.
Как коммутатор — практически wire-speed.
Как коммутатор — практически wire-speed.
То есть если какой-то засранец сгенерирует, например, миллион flow в секунду,… ладно, 150к flow в секунду, что станет с контроллером?
Используйте внешний! :)
Если у вас есть план, как положить коммутатор нагрузкой — поделитесь, реализуем на практике и поделимся результатом с общественностью.
Если у вас есть план, как положить коммутатор нагрузкой — поделитесь, реализуем на практике и поделимся результатом с общественностью.
Начните с hping3 --flood --rand-source -p ++1 -S some_host
Как верно заметили ниже — флуд будет обрезан контроллером.
Я просил несколько другое — план решения, с нагрузкой от которого коммутатор не справится.
48 серверов, которые делают что-то полезное для общественности.
Я просил несколько другое — план решения, с нагрузкой от которого коммутатор не справится.
48 серверов, которые делают что-то полезное для общественности.
входящий флуд будет обрезание контроллером? При том, что контроллер 100к флоу, а хпинг делает больше 300? Если -p ++1 кажется заманчивым, замените на -p 80.
Все таки мы о разных вещах сейчас говорим.
Размещать контроллер SDN на коммутаторе можно, но не очень нужно, в нем стоит двухъядерный процессор.
Для того Control Plane и отвязывали от железки.
На коммутатор лучше разместить фаерволл, IPS и прочие задачи такого рода.
Размещать контроллер SDN на коммутаторе можно, но не очень нужно, в нем стоит двухъядерный процессор.
Для того Control Plane и отвязывали от железки.
На коммутатор лучше разместить фаерволл, IPS и прочие задачи такого рода.
я говорю про контроллер на несколько коммутаторов внутри периметра. Если его надо прикрывать файволами/ids, то получившееся может и выживет, но надо ли такое?
Вы рассматриваете сценарий, когда контроллер отслеживает каждый flow?
Зачем?
Такой вариант не масштабируется, будет медленным, да и пользы от отслеживания каждого flow не видно.
Составьте таблицу маршрутизации, дальше коммутатор съест любой поток.
Зачем?
Такой вариант не масштабируется, будет медленным, да и пользы от отслеживания каждого flow не видно.
Составьте таблицу маршрутизации, дальше коммутатор съест любой поток.
Нет, я хочу, чтобы вы мне попытались описать такую конструкцию (условного интернет-сайта) с использованием SDN, в котором бы не было сценария, при котором школьник может с помощью hping/ab заставить каждый новый запрос обрабатываться как новая flow с отправкой на инспекцию. В принципе, я понимаю что ab — это уже другой уровень. Так что давайте начнём с hping'а. Как будет выглядеть инсталляция SDN, которая будет обрабатывать трафик из интернета с участием контроллера (то есть не «у нас всюду маршрутизация/коммутация, а контроллер для красоты»), и при этом сможет избежать проблемы с инспекцией каждого specially-crafted пакета?
У меня, конечно, есть нехорошая интонация «да фигня это всё», но разобраться я хочу серьёзно, потому что flow-flood сейчас моё самое главное и основное возражение против SDN IRL.
У меня, конечно, есть нехорошая интонация «да фигня это всё», но разобраться я хочу серьёзно, потому что flow-flood сейчас моё самое главное и основное возражение против SDN IRL.
Сферический школьник в вакууме отправляет запросы на фронт-енд сайта, его не волнует то, как его запрос обрабатывается дальше. Внутреннюю сеть школьник не видит.
Под таблицей маршрутизации я как раз понимал таблицу flows в коммутаторах, а контроллер для изначальной задачи таблицы/обновления по мере необходимости (появления новых destination).
Удобство от централизации остается, проблемы масштабирования и флуда снимаются.
Зачем каждый пакет инспектировать контроллером?
Вот тут примерно такое же мнение описано.
Под таблицей маршрутизации я как раз понимал таблицу flows в коммутаторах, а контроллер для изначальной задачи таблицы/обновления по мере необходимости (появления новых destination).
Удобство от централизации остается, проблемы масштабирования и флуда снимаются.
Зачем каждый пакет инспектировать контроллером?
Вот тут примерно такое же мнение описано.
Перед тем, как будем разбирать пример, вы хотите сказать, что SDN не подходит для периметра сети, то бишь фронт-энда? (который принимает нефильтрованный трафик из интернетов)
Я, собственно, эту мысль и пытаюсь всё время донести: SDN — уютная игрушка для уютных задних сетей, а к реальной нагрузке оно не готово.
Проблема «flows в коммутаторе» сводится к тому, что мы либо из всех flow оставляем только dst_ip, который потом уже разбираем глубже внутри, либо мы должны мириться с невероятного размера флудом на контроллер.
Если мы весь SDN сводим к «dst-based policy», то это и есть обычная маршрутизация (с минусами внешнего контроллера), если пытаемся сделать что-то более умное — огребаем амплифицирующий само-DoS.
Я, собственно, эту мысль и пытаюсь всё время донести: SDN — уютная игрушка для уютных задних сетей, а к реальной нагрузке оно не готово.
Проблема «flows в коммутаторе» сводится к тому, что мы либо из всех flow оставляем только dst_ip, который потом уже разбираем глубже внутри, либо мы должны мириться с невероятного размера флудом на контроллер.
Если мы весь SDN сводим к «dst-based policy», то это и есть обычная маршрутизация (с минусами внешнего контроллера), если пытаемся сделать что-то более умное — огребаем амплифицирующий само-DoS.
Возможно не совсем правильно понял, что подразумевается под flow в данном вопросе. Но, что касается самой идеологии SDN, то всё зависит от реализации контроллера сети. Если вопрос стоит в том, чтобы обязательно обработать всё, что приходит, то заткнуть можно всё что угодно. Если же говорить об устойчивости, то в SDN заложены богатые возможности по обнаружению «засранцев» и минимизации ущерба для нормальных пользователей. Вплоть до блокировки адресов и даже физических портов и перераспределения трафика между оставшимися. То есть при правильном контроллере почти все 150k (или даже 1000k) от «засранца» будут отброшены, а с контроллером ничго не случится.
каким образом это поможет при внешнем флуде?
В упрощённом виде: все коммутаторы запускаются с одним правилом — все неизвестные пакеты (или их заголовки) отправлять контроллеру. Получив их, он добавляет необходимые правила для обработки, в идеале со временем действия. Кроме того, предусмотрены счётчики для измерения потоков (по портам, по правилам и т.п.) и оповещение контроллера о превышениях заданных порогов. При правильном наборе правил, простите за тафтологию, источник флуда будет временно отключён, с необходимыми корректировками остальных маршрутов, и не повредит сети в целом. Но отдельные порты или диапазоны адресов конечно можно блокировать такими атаками.
/facepalm.
Какой источник флуда? Интернет?
Если не поняли, повторяю: школьник на vds'ке запускает hping --flood --rand-source с целью на один из серверов внутри SDN. Кого куда что будет банить?
Какой источник флуда? Интернет?
Если не поняли, повторяю: школьник на vds'ке запускает hping --flood --rand-source с целью на один из серверов внутри SDN. Кого куда что будет банить?
Если у вашей сети один порт для интернета и если у школьника проплаченный канал шире, чем у вашей сети, то да, будет временно забанен интернет. Хотя может быть отключён и только доступ извне к атакуемому серверу, с сохранением его для остальных машин сети. Всё зависит от баланса фантазии автора программы контроллера сети и вашего «школьника».
Не-не, ну что вы передергиваете. Допустим, у школьника 50 мегабит. Входящий канал в сеть с контроллером — 10 гигабит.
И, допустим, школьник достаточно умный, чтобы не только --rand-source сделать, но и долбануть не по одному IP, а по всем адресам АС.
Я и хочу понять, как в этих условиях sdn жить будет, когда 300к flow ежесекундно новых.
Это моя претензия к технологии sdn.
И, допустим, школьник достаточно умный, чтобы не только --rand-source сделать, но и долбануть не по одному IP, а по всем адресам АС.
Я и хочу понять, как в этих условиях sdn жить будет, когда 300к flow ежесекундно новых.
Это моя претензия к технологии sdn.
Странный получается диалог… Ну, например, контроллер может сортировать записи по степени активности и при заполнении таблиц удалять самые «пассивные». То есть ваш флуд будет забивать сам себя. Если вы надеетесь забить управляющий канал и будете настаивать что можете, то это приведёт к задержкам при установлении новых соединений.
И при чём здесь sdn? Что остальные варианты построения сети устойчивы к такому виду атак?
И при чём здесь sdn? Что остальные варианты построения сети устойчивы к такому виду атак?
Так давайте начнём с более простого: контроллер просто не сможет обслуживать 300к запросов на новые флоу, то есть простой школьник с 20-50Мбит/с каналом сможет положить сеть почти любого размера.
Я ж это всё пишу не просто так. Старые версии openvswitch страдали ровно той же проблемой — флуд клал контроллер (который vswitchd) на колени при 15 мегабитах флуда. Это при том, что ядерный модуль был способен 7-10 гигабит перемолоть. В новой поправили, но так vswitchd — не полноценный openflow-контроллер, а всего лишь прослойка между нормальным контроллером или ручными правилами.
Я утверждаю, что из простенького 10G маршрутизатора и коммутатора могу изготовить решение, которое на 50Мбит пакетного флуда даже глазом не поведёт. И даже фильтровать не будет, а прямо до сервера донесёт (который тоже проигнорирует флуд).
Другими словами, SDN решение получается много более уязвимое, чем существующие технологии, и проблема тут не в реализации (конкретного вендора или софта), а в принципиальной идее «централизации обработки всех flow с отправкой образцов на инспекцию».
Я ж это всё пишу не просто так. Старые версии openvswitch страдали ровно той же проблемой — флуд клал контроллер (который vswitchd) на колени при 15 мегабитах флуда. Это при том, что ядерный модуль был способен 7-10 гигабит перемолоть. В новой поправили, но так vswitchd — не полноценный openflow-контроллер, а всего лишь прослойка между нормальным контроллером или ручными правилами.
Я утверждаю, что из простенького 10G маршрутизатора и коммутатора могу изготовить решение, которое на 50Мбит пакетного флуда даже глазом не поведёт. И даже фильтровать не будет, а прямо до сервера донесёт (который тоже проигнорирует флуд).
Другими словами, SDN решение получается много более уязвимое, чем существующие технологии, и проблема тут не в реализации (конкретного вендора или софта), а в принципиальной идее «централизации обработки всех flow с отправкой образцов на инспекцию».
>Мы приглашаем разработчиков сетевых приложений и компании, которые собираются тестировать/внедрять SDN решения для апробации >коммутатора в реальных задачах.
Куда и когда приглашаете? А может мы вас пригласим обсудить наш проект?
Мы сейчас на стадии разработки решения для наших ЦОД на базе OpenStack и у нас (taximaxim.ru) есть идеи, как использовать подобный продукт для своих нужд.
Куда и когда приглашаете? А может мы вас пригласим обсудить наш проект?
Мы сейчас на стадии разработки решения для наших ЦОД на базе OpenStack и у нас (taximaxim.ru) есть идеи, как использовать подобный продукт для своих нужд.
Написал личное сообщение.
Ребят, я понимаю, что тут не совсем место, но не могли бы вы попросить там своих маркетологов не использовать SMS-спам для завлечения клиентов?
А то у меня спам от вас пришёл спустя 10 часов после покупки новой сим-карты с новым номером. Я уже начал подозревать оператора в сговоре со спамерами :-/
А то у меня спам от вас пришёл спустя 10 часов после покупки новой сим-карты с новым номером. Я уже начал подозревать оператора в сговоре со спамерами :-/
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Software Defined Network (SDN) на основе открытой платформы Intel ONS