MAC-Flood и дешевый неуправляемый switch
 

Всем привет!

Решил немного повысить свою квалификацию в сетевых технологиях. Начал с Layer 2, т.е. с обычных коммутаторов. Насколько известно, в них есть таблица соответствия MAC-адресов и портов. Она "обучается" по принципу сопоставления адреса источника и порта. Таблица не резиновая. И соответственно коммутатор подвержен атаке вида MAC-Flood. Если переполнить таблицу, то можно будет "слушать" трафик всего сегмента сети. Проверяю на практике. Собрал следующий стенд:

- 8 портовый дешевый неуправляемый свитч и в него подключены:
- Мой компьютер с Win 7
- Два компьютера с CentOS 6

На компьютере с Win 7 стоит виртуальная машина в Virtual Box с ОС Backtrack. Виртуалка соединена мостом. ВСЕ узлы стенда между собой успешно пингуются.

Суть эксперимента:

1) На одной из линуксовых машин ставлю постоянный пинг другой.
2) На компьютере с Win 7 запускаю Wireshark и мониторю весь трафик, который не предназначен виндовой машине, и который она не порождает (т.е. все, кроме себя). Снифер не показывает пакетов пинга между линуксами, что есть правильно.
3) В Backtrack запускаю macof -n 100000, т.е. выполню MAC-Flood атаку.
4) Снифер регистрирует все 100000 пакетов с подложными адресами, т.к. атака успешно попала в сегмент сети.
5) После окончания атаки продолжаю мониторить снифер. На данном этапе таблица свича должна быть переполнена и я должен увидеть пакеты пингов между линуксами. Но их нет! Почему? Получается, что данный свитч не подвержен этой атаке. Но это противоречит логике работы коммутатора 2го уровня. Или я чего-то не понимаю?

VladDV, не факт что при переполнении таблицы свитч становится хабом, банально могут стираться более старые записи и записываться новые

Возможно. Но ведь перед тем, как новая запись снова добавится, один пакет должен же уйти на все порты верно? А в снифер не попадает ни одного пакета.

с чего вдруг? при отсутствии записи никуда не пойдет/встанет в очередь/умрет, т.е. свитч будет "тупить"

Есть конечно мысль, что в таблицу перестают добавляться новые записи, но старые-то записи остаются. И свитч использует их, когда они есть, и шлет на все порты в случае отсутствия записи. Завтра на работе проверю эту гипотезу. Отключу кабель из одной линуксовой машины, перезагружу свич, чтобы очистить таблицу, потом проведу атаку и подключу кабель обратно. Если гипотеза верна, то адрес не сможет добавиться и начнет слать пакеты на все порты.

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

VladDV, что за свитч?

Блин, если честно, то даже не посмотрел. Либо длинк, либо 3ком, либо что-то аналогичное. Из серии тех, которые килограммами меряют :) Завтра гляну, напишу точно.

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

Вообще такая стратегия выглядит самой разумной. Если свитч не затирает старые записи и сохраняет их до перезагрузки, тогда он практически гарантированно защитит от атаки этого вида. Вероятность, что через один порт свича в нормальной сети пройдет за время его работы более 8000 новых мак-адресов стремится к нулю. Поэтому все, что переполнит таблицу, можно смело считать вредоносным трафиком и не работать с ним.

Switch DLINK DES1008A, 8 портов.

Эксперимент провел. Действительно, таблица заполняется и все новые записи отбрасываются. Я смог перехватить пакеты вновь подключенного после заполнения таблицы компьютера. При этом от компьютеров, которые были подключены до проведения атаки, пакетов на снифер не поступает.

Вот интересно, есть ли какое-то правило, какие свичи как себя ведут в этой ситуации? Например, циско, судя по статьям в интернете, после заполнения таблицы начинает работать как хаб и рассылает ВСЕ пакеты ВСЕХ узлов сети. Получается, что дешевый длинк в этом вопросе оказался надежней :)

есть всякие port security от этой атаки.

Ну это только на хороших управляемых свичах, на тех же цисках. И эту функцию нужно настраивать. В этом и был интерес эксперимента. Насколько разные конфигурации подвержены этой и другим сетевым атакам, и соответственно какие защитные функции рекомендуется учитывать при покупке и настройке оборудования. Вот если брать конкретно этот вид атаки, то оказывается, что тут и нет надобности в навороченном оборудовании со всякими защитами.