Обновить
4
0
Трофимов Велемир Сергеевич@tws

Пользователь

Отправить сообщение
А можно и не придумывать. Есть, например, «Луна — суровая хозяйка» Роберта Хайнлайна (1966 год). Там и сюжет достаточно близок к первой половине набросанного.
Странный получается диалог… Ну, например, контроллер может сортировать записи по степени активности и при заполнении таблиц удалять самые «пассивные». То есть ваш флуд будет забивать сам себя. Если вы надеетесь забить управляющий канал и будете настаивать что можете, то это приведёт к задержкам при установлении новых соединений.

И при чём здесь sdn? Что остальные варианты построения сети устойчивы к такому виду атак?
Если у вашей сети один порт для интернета и если у школьника проплаченный канал шире, чем у вашей сети, то да, будет временно забанен интернет. Хотя может быть отключён и только доступ извне к атакуемому серверу, с сохранением его для остальных машин сети. Всё зависит от баланса фантазии автора программы контроллера сети и вашего «школьника».
В упрощённом виде: все коммутаторы запускаются с одним правилом — все неизвестные пакеты (или их заголовки) отправлять контроллеру. Получив их, он добавляет необходимые правила для обработки, в идеале со временем действия. Кроме того, предусмотрены счётчики для измерения потоков (по портам, по правилам и т.п.) и оповещение контроллера о превышениях заданных порогов. При правильном наборе правил, простите за тафтологию, источник флуда будет временно отключён, с необходимыми корректировками остальных маршрутов, и не повредит сети в целом. Но отдельные порты или диапазоны адресов конечно можно блокировать такими атаками.
Возможно не совсем правильно понял, что подразумевается под flow в данном вопросе. Но, что касается самой идеологии SDN, то всё зависит от реализации контроллера сети. Если вопрос стоит в том, чтобы обязательно обработать всё, что приходит, то заткнуть можно всё что угодно. Если же говорить об устойчивости, то в SDN заложены богатые возможности по обнаружению «засранцев» и минимизации ущерба для нормальных пользователей. Вплоть до блокировки адресов и даже физических портов и перераспределения трафика между оставшимися. То есть при правильном контроллере почти все 150k (или даже 1000k) от «засранца» будут отброшены, а с контроллером ничго не случится.
Спасибо, интересное изложение. Очень похоже на то, что я пытался применять, правда в приложении к програвмно-аппаратным комплексам. Хотя никогда не думал о том что делал так системно. Всегда считал это во многом отсебятиной, так как никогда не получалось добиться полного описания как должно быть на этапе проектирования, только нескоторые ключевые моменты. По мере же работы с системой, встретив новое поведение, решали правильно ли, ну и добавляли новые состояния/переходы по мере необходимости. А тут прямо бальзам на душу — оказывается это можно делать с полным научным обоснованием. С нетерпением буду ждать дальнейших подробностей.

Информация

В рейтинге
Не участвует
Откуда
Минск, Минская обл., Беларусь
Дата рождения
Зарегистрирован
Активность

Специализация

Инженер встраиваемых систем, ML разработчик
Ведущий
Git
Linux
C
Docker
Python
C++
Многопоточность
Оптимизация кода
Алгоритмы и структуры данных
Разработка программного обеспечения