Возможна ли DoS/DDoS атака на устойство слушающее SPAN-порт?

Question

[Studencheskaya32]

Сразу скажу я не сетевик. Поэтому вопрос может быть совсем глупый.
Есть некий комплекс который для своей работы требует подключения к SPAN порту core-свича сети.
Возможно ли вообще в принципе завалить SPAN порт трафиком так чтобы устройство перестало с ним справляться?
На сколько я понимаю технологию зеркалирования вопрос перегрузки SPAN-порта трафиком (и как следствие любого устройства подключенного к нему) вообще не имеет смысла т.к. зеркалить можно только заранее аппаратно-определенный поток или вообще только один какой-то порт. Так ли это? Прошу развернутый ответ по возможности.
Второй вопрос. опять если я все правильно понимаю, можно зеркалировать только грубо говоря порт-в-порт (ну или группу портов, не суть важно), Как мы тогда можем весь трафик видеть который идет через свич? Очевидно ответ мы не можем видеть весь. Тогда в чем смысл вообще, если мы что-то важное можем пропустить?

Answer 1

[throughtheether]

Возможна ли DoS/DDoS атака на устойство слушающее SPAN-порт?

Атака возможна на что угодно. Другой вопрос, насколько эффективна она будет.

Возможно ли вообще в принципе завалить SPAN порт трафиком так чтобы устройство перестало с ним справляться?

Без уточнения, о каком устройстве идет речь, ответ дать трудно. В общем, если вы подключились в гигабитный порт, и устройство обработает 1.5 миллиона фреймов в секунду, то есть надежда на устойчивую его работу.

На сколько я понимаю технологию зеркалирования вопрос перегрузки SPAN-порта трафиком (и как следствие любого устройства подключенного к нему) вообще не имеет смысла

SPAN-порт (в роли destination) не сможет пропустить трафика больше, чем физически возможно (этот предел задан скоростью среды и размерами буферов). Пример - вы копируете трафик с 3 портов (каждый загружен на 400 Мбит/с в среднем) в один гигабитный (1000 Мбит/с) порт. Примерно одну шестую трафика (3*400 Мбит/с - 1000 Мбит/с =200 Мбит/с) вы будете терять.

т.к. зеркалить можно только заранее аппаратно-определенный поток или вообще только один какой-то порт.

Как правило, копировать трафик можно с порта (иногда с фильтрацией по вланам), группы портов, из влана - в другой порт.

Тогда в чем смысл вообще, если мы что-то важное можем пропустить?

Часто, например, через SPAN мониторят трафик, приходящий на процессор. Увеличение объема такого трафика, как правило, ничего радостного не сулит.

Как мы тогда можем весь трафик видеть который идет через свич?

Если бы я сейчас реализовывал подобный проект (т.е. необходимо видеть "весь" трафик), я бы обратил внимание на продукцию Gigamon (если много денег) или бы поэкспериментировал с пассивными оптическими разветвителями (логично их устанавливать на линки с интересующим нас трафиком).

Вкратце, неясно, какую задачу вы пытаетесь решать. Если вы ее опишете, можно будет говорить более конкретно.

Answer 2

[Studencheskaya32]

Добрый вечер. Спасибо за подробные разъяснения. Задача - внедрение IDS системы. отсюда собственно все вопросы. т.е. как эта IDS система будет реагировать на инциденты, если есть теоретическая вероятность drop'а пакетов из-за перегрузки SPAN порта который эта система слушает?

Comments

[throughtheether]

>Задача - внедрение IDS системы.
Это промышленное решение или курсовая/дипломная работа? Если первое, то зачем вам IDS? Для прохождения аудита? Далее, какой именно трафик необходимо анализировать (есть ли группа потенциально уязвимых серверов, например, если да, то можно попытаться выделить ее в отдельный влан)

>как эта IDS система будет реагировать на инциденты, если есть теоретическая вероятность drop'а пакетов
По формулировке вашего вопроса я понимаю, что вы догадываетесь, что работать она будет не лучшим образом.

[throughtheether]

Кстати, IDS имеют свои уязвимости, обусловленные дизайном (www.rootsecure.net/content/downloads/pdf/dos_via_a... раздел 4.3).

[Studencheskaya32]

Промышленное решение. Внедряется в рамках построения комплексной системы ИБ в компании.
Посоветовался тут с технарями. Действительно мониторить надо отдельные типы трафика. но не по критерию src\dct а по критерию протоколов. т.е. грубо говоря репликацию больших объемов данных можно и не мониторить. Технари предлагают выделить интересующие протоколы в отдельный VLAN. На сколько это вообще распространенное решение и на сколько оно может повлиять на архитектуру сети (логическую\физическую)? У технарей не спросил это, т.к. был webex на английском и через телефон с человеком который похоже в машине ехал.. x)
Второй предложный вариант был зеркалировать trunk-порт который идет от "distribution layer switch" в "core switch". Чисто логически мне этот вариант представляется более простым и технологичным.

[throughtheether]

>Технари предлагают выделить интересующие протоколы в отдельный VLAN.
Фактически это сведение к фильтрации по хостам. Оценить влияние на архитектуру без ознакомления с нею затрудняюсь.
>Второй предложный вариант был зеркалировать trunk-порт
Поддерживаю этот вариант, в данном случае, чем проще, чем меньше вносимые изменения, тем лучше.