Угрозы и проблемы в работе коммутаторов

Теперь, когда мы разобрались с проблемой, как настроить коммутатор, давайте поговорим о том, что может пойти не так. Мы обобщим общую тему с названием «Угрозы». Но угроза — это не обязательно, что придёт какой-то злобный хакер, который вас будет хакать или что-то ещё делать. Это что может пойти не так в общем случае: как может оно поломаться, что может получиться, если вдруг что-то пойдёт не так, и как с этим, главное, бороться. Абсолютно все коммутаторы подвержены общей проблеме. А проблема заключается в том, что коммутатор прикидывается шлангом, то есть толстым жёлтым коаксиалом, с той или иной степенью успешности. И на процедуру того, как он прикидывается толстым жёлтым коаксиалом, можно устроить всякие разные каверзные вещи. Первое, что можно сделать, — это заставить коммутатор перестать понимать, где он, кто он и что он.

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

И третья, самая простая, самая очевидная проблема — это петля, которая связана с тем, что в классическом Ethernet никаких петель быть в принципе не могло, потому что Ethernet с петлями в принципе не мог работать вообще никак. Он не мог это сделать именно от слова «не мог». На физическом уровне петли запрещались. Если бы были петли, то сигнал, который прошёл бы по двум разным трассам, наложился бы друг на друга, и у вас просто не работало бы ничего. Если вы используете сеть с коммутаторами, то петля в Ethernet будет проблемой, и проблема будет с тем, что оно немножко поработает, а потом сдохнет. Разберёмся, как это происходит. Все три проблемы сейчас разберём. Самое первое — это переполнение таблицы MAC-ов. Я про неё уже всё рассказал. Вы, как атакующий, — у нас узел А, — хотите сделать так, чтобы ваш коммутатор перестал запоминать, кто где сидит.

Вы отправляете ему кучу-кучу-кучу кадров из-под разных MAC-адресов. Не обязательно два MAC-адреса. Главное, чтобы они были разные. Вы можете этих кадров наплодить довольно много. Если у вас 10-мегабитный интерфейс, вы можете отправить 10 миллионов бит в секунду. Это приблизительно 1 миллион байт. Если мы берём кадры по 100 байт, это приблизительно 10 тысяч кадров в секунду. Если у вас будет 100-мегабитный интерфейс, это будет порядка 100, а точнее даже 150 тысяч кадров в секунду. Если у вас будет гигабитный интерфейс, сами понимаете, всё умножается на 10. Если вы будете отправлять столько кадров в секунду, вы можете даже не целиком занять ваш канал. Потому что на самом деле миллион байт — это не 10 тысяч кадров, по большому счёту это где-то 12,5 тысяч, примерно так.

Даже если вы будете столько отправлять, ещё место останется под то, чтобы какой-то боевой трафик отправлять. Вы столько кадров мусора нагенерите, отправляете их на свой коммутатор, и, как уже говорилось, объём таблицы коммутации на каждом свиче небольшой. Для типичных свичей, которые вы в предприятии увидите, это примерно, например, 8 тысяч записей. Это ещё хороший коммутатор. Начальная Cisco, например, столько имеет. У вас на свиче больше, чем 8 тысяч MAC-адресов, в принципе не может храниться. А вы 10 тысяч кадров в секунду отправляете из-под разных MAC-ов, и каждый MAC надо в этой таблице запомнить. К чему это приведёт? Правильно, к тому, что даже на 10-мегабитном интерфейсе вы меньше чем за секунду все боевые MAC-и выбьете из этой таблицы, и ваш свич точно перестанет про них знать. А даже если они какой-то кадр отправят, то не позже чем через секунду эта информация потеряется совсем. Если у вас будет 100-мегабитный интерфейс, то вы будете выбивать полностью всю таблицу коммутации свича меньше чем за одну десятую секунды. Поэтому, если вы отправляете кучу разных кадров из-под кучи разных MAC-ов, не своих собственных, а просто случайных, то ваш коммутатор не знает, кто где сидит, и весь трафик, который будет ходить через него, он будет разбрасывать на все порты.

Процедура Unicast Forwarding не будет работать, вместо неё будет происходить разбрасывание кадров на все порты, то есть Unknown Unicast Flooding. У нас узел B хочет отправить кадр на узел C. Если бы коммутатор знал, где сидит C, он бы отправил трафик только ему, а на остальных портах заблокировал бы передачу. Но поскольку атакующий узел А выбил всю таблицу коммутации, узел B отправляет кадр, и этот кадр попадает и атакующему, и на узел C, и на узел D, который не ожидал ничего увидеть. D зажмуривается, говорит: это не мне, мне не интересно. C говорит: о, мне тут кадр пришёл, всё хорошо, я его читаю. А узел А говорит: о, как интересно, я вижу какой-то кадр, который мне не предназначен, но я очень любопытный узел, и мне очень интересно, что там другие передают. Поэтому этот кадр тоже читает. И он видит кадр, который пришёл от узла B на узел C. С помощью такой атаки вы можете перехватывать чужие кадры достаточно незаметно для получателя.

Как бороться с этим? Бороться с этим можно с использованием, например, ограничения количества MAC-адресов, которые коммутатор имеет право залёрнить. Если у вас есть коммутатор, и на нём есть порт, и на этом порту сидит атакующий, то вся эта процедура, которую атакующий может устроить, — это подсылается куча-куча-куча, как правило, мелких кадров из-под разных MAC-адресов. Если вы скажете, что мы будем ограничивать количество MAC-адресов, которые залёрнятся за этот порт, до 10 — 10 можно MAC-ов залёрнить, а больше уже нельзя, — то первые 10 кадров, которые пройдут, они залёрнятся. MAC-и залёрнятся из них. А когда вы 11-й кадр отправите из-под нового случайного MAC-а, ваш свич скажет: стоп, тут что-то пошло не по плану, и мы дальше такие кадры обрабатывать не будем. Можно либо заблокировать этот отдельный кадр, либо целиком порт прибить, заморгает лампочка, приедет специальный отряд реагирования и каким-то образом на это всё отреагирует.

Вот таким образом вы можете бороться с переполнением таблицы MAC-адресов. Второй механизм, который здесь нам может быть интересен, — это дублирование MAC-адресов. Если у нас по каким-то причинам на свиче образуются два разных пользователя с одинаковыми MAC-адресами, — это может произойти неумышленно или, напротив, умышленно, когда злоумышленник просто берёт себе MAC какого-то другого пользователя, — то в этом случае происходить будет следующее. Мы не можем запомнить два разных порта для одного и того же MAC-а. Каждый MAC мы знаем только за одним портом. Если мы атакующий и мы хотим, чтобы трафик на узел C не приходил, а мы бы как раз этот трафик получали, то мы можем отправить кадр и сказать, что мы узел C.

Отправляем на какой-нибудь MAC-адрес, неважно какой. Может, бродкаст отправляем, может, просто какой-то случайный MAC. Кадр такой приходит на свич, свич говорит: о, я теперь знаю, где сидит узел C. Узел C сидит за первым портом. И даже если раньше узел C был известен за третьим портом, информация всё равно перебивается, и теперь узел C находится за первым портом. Если узел B захочет послать кадр узлу C, он посылает этот кадр на свич, свич смотрит табличку, говорит: узел C сидит за первым портом, и направляет этот кадр на атакующего, на узел A. Сам C в этом случае не получает такой кадр, он даже не знает, что он был отправлен. Вы можете отправить кадр из-под чужого MAC и таким образом будете получать весь трафик вашей жертвы. Жертва этот кадр при этом не получит. Как бороться? Тяжело бороться. С атакой на подмену MAC прямо тяжело-тяжело бороться. Фактически вы можете сказать либо, что будете вести в явном виде список разрешённых MAC-ов, которые на порту могут быть.

У вас будет коммутатор, и на этом коммутаторе вы говорите: вот у нас есть порт, на этом порту сидит Вася, и MAC Васи вы в явном виде разрешаете. У него MAC-адрес, допустим, A. И вы говорите: если кадры приходят от MAC-а Васи, мы их разрешаем. Если приходят какие-то другие MAC-и, мы их запрещаем. Есть более продвинутые механизмы, которые не требуют в явном виде указания, какие MAC-и на порту будут. Пример такой технологии — это 802.1X. Заключается она в следующем. У вас есть некий узел, и этот узел пытается подключиться к сети. Switch ему говорит: ты кто такой. Там используется специальный протокол обмена аутентификационной информацией — EAP, и он отвечает: я — это я. Он каким-то образом показывает, что он действительно — это он. Например, сертификат показывает. И в этом случае он декларирует, что он — это он, и на порту происходит так называемая аутентификация, и порт становится авторизован для приёма трафика из-под определённого MAC, потому что владелец этого MAC показал сертификат, что он — это он.

Если у вас будет какой-то другой порт, на котором кто-то другой пытается сказать, что он тоже узел А, ему спросят: а ты кто вообще такой, покажи сертификат. Сертификат уже не сможет показать. Или он покажет сертификат, что он — это он, но тогда оригинальный узел в этом случае не получит доступа. Но в нормальной ситуации у вас не может быть такого, что два узла показывают одинаковые сертификаты. Это, конечно, более удобно, потому что у вас есть некое централизованное хранилище, которое будет отвечать за сертификаты, — AAA какой-то, RADIUS или что-то ещё. Каким-то образом будет всё это делать централизованно. Это не потребует от вас необходимости заводить списки MAC-адресов на каждом отдельном порту, что реально невозможно просто делать, если у вас большая сеть. На конечных узлах потребуется поддержка этого самого протокола EAP. Поэтому не очень удобно это тоже.

Простого лёгкого механизма защититься от атаки на подмену MAC-а нету вообще никак. Последняя проблема, которая у нас в списке была, — это петли. Коммутация может работать, если у нас всё делается по правилам, если у нас всё делается по стандарту и никто нас не атакует. Если у нас в какой-то момент нарушаются эти требования, — либо нас кто-то атакует, либо у нас возникает петля в Ethernet, — то коммутация перестаёт работать корректно, потому что эта процедура вида «каждый коммутатор прикидывается толстым жёлтым коаксиалом» не предполагает, что у вас где-то что-то может пойти не по плану. Если у вас всё хорошо, то между любыми двумя узлами должен быть ровно один путь доставки трафика. Не может быть такого, что у нас есть узел и между ними есть вот так вариант пройти и вот так вариант пройти. Коммутация так работать не может. Может быть только так, что у нас есть один способ доставить трафик от одного узла до другого. Он может быть каким угодно, кривым, косым, по какому-то такому маршруту идти, но он должен быть один.

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

Стопроцентная загрузка будет требоваться для обработки совершенно ненужных никому кадров. А на боевые кадры останется примерно 0%. Нестабильность базы MAC-ов будет приводить к тому, что трафик, даже если он пройдёт через перегруженные интерфейсы, через перегруженные матрицы коммутации, всё равно уйдёт в неправильном направлении. Практически гарантировано, что боевой трафик до конечного хоста просто физически не сможет дойти. Все свичи все свои оставшиеся силы, которые останутся после шторма, будут направлять трафик в неправильную сторону. Они будут тратить силы на то, чтобы трафик направлять неправильно. И те кадры, которые будут всё-таки проходить — не обязательно правильные, но просто какие-то кадры — они будут доставляться много-много-много раз на хосты, и у вас ещё и хосты в стопроцентную нагрузку уйдут. Тем самым сетка просто моментально начинает козлить, и все сетевые ресурсы перестают быть доступны. По-русски выражаясь, всё дохнет. Именно не просто деградирует, а дохнет.

Первая проблема — это шторм. Выглядит это следующим образом. У нас есть узел А, он хочет отправить какой-то кадр, и он говорит: я, узел А, отправляю широковещательный кадр, FFFF. Не буду писать все FF, но сами понимаете — бродкаст. И мы такой бродкаст отправляем. Что делает свич, когда видит бродкаст? Он его разбрасывает на все порты. Например, он отбросит его вот сюда. Также бросит сюда, но мы про это отдельно поговорим потом. Дальше. Что делает этот свич, когда видит бродкаст? Правильно, он его бросает на все порты. Сюда. Что делает вот этот свич, когда получает этот бродкаст? Он его разбрасывает на все порты. Сюда. Мы получаем на этом свитче кадр из петли. Что мы делаем с ним? Мы его бросаем на все порты. Например, сюда. И дальше он начинает в этой петле бесконечно бегать. Ничто его не может остановить до тех пор, пока существует петля. Сама процедура коммутации вида «разбросаем копии кадра на все порты, кроме некоторых портов, куда бросать не надо», она заставляет коммутаторы таким образом себя вести.

Дальше. Я уже сказал, что у нас первый коммутатор будет разбрасывать копию кадра и в одну сторону, и в другую. У нас один кадр закрутится вот так, а другая копия этого же кадра закрутится в другом направлении. И у нас создастся две копии кадра, которые будут в этой петле бегать бесконечно. Даже один кадр, который будет ходить, он будет навечно зависать в петле в двух направлениях, и на обработку этих кадров потребуются какие-то ресурсы. Отправили один бродкаст, он завис в виде двух копий. Отправили еще один бродкаст, у вас еще две копии зависло. Отправили еще — и не только уже один этот узел отправляет бродкаст, этот тоже периодически отправляет, этот периодически отправляет. Все узлы периодически отправляют бродкасты. ARP, какие-то еще кадры. И все они зависают в петле. Если у вас сеть не очень быстрая, узлы отправляют бродкасты редко, а петля достаточно большая по размеру, то есть количество узлов в этой петле достаточно большое, то времени на то, чтобы сеть полностью насытилась этими бродкастами, если хотите, сдохла, может быть довольно много.

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

Но нас сейчас интересует один из этих экземпляров, который в одном направлении начинает бегать. Сюда отправляется, сюда отправляется, сюда отправляется, сюда отправляется и так далее. Каждый раз, когда эта копия кадра проходит через каждый из свитчей, она отправляется на все порты. Один раз прошёл через свитч — отправилась на все порты. Тот же самый кадр прошёл через петлю и ещё раз отправился на все порты. Тот же самый кадр прошёл через петлю и ещё раз отправился на все порты. У вас бесконечно много кадров будет доходить до абонентов. Абонентские линки уйдут в стопроцентную загрузку ещё быстрее, чем это случится в петле. И ваши линки до абонентов, вместо того чтобы отправлять боевой трафик, будут получать копии всех этих бродкастов по сто-пятьсот-миллионному разу. Каналы до абонентов полностью забиваются. Как правило, бродкастовый трафик абоненты вынуждены читать, потому что это им тоже адресовано, и у них процессор тоже, особенно если процессор слабенький, если это старые какие-то машины, падает в 100% загрузку.

Боевой трафик не ходит, вместо него ходит мусорный трафик, который загружает ваши процессоры. Последняя проблема — нестабильность базы MAC-адресов. Представим себе, что узел А отправил какой-то бродкаст, соответственно, FFF. Бродкаст ушёл на свитч, дальше свитч отправил сюда, свитч отправил сюда, свитч отправил сюда, свитч отправил сюда, свитч отправил сюда, и наоборот — свитч отправил туда, свитч отправил туда, свитч отправил туда. Этот бродкаст постоянно бегает в петле. Постоянно — это значит, что с вероятностью единица, если вдруг какой-то узел, например, B, захочет отправить кадр узлу А, он его отправит на свитч. Свитч может быть отправит сюда, может быть отправит сюда, неважно, куда он отправит. Главное, что каким-то образом этот кадр дойдёт всё-таки до свитча, на котором действительно узел А находится. Но куда этот свитч направит трафик, который идёт до узла А? Он его никогда

и ни за что не отправит сюда. Потому что из петли с намного большей вероятностью только что пришёл какой-то кадр из-под MAC-адреса А. Вот он, этот кадр от адреса А на бродкаст. Он постоянно бегает, бегает, бегает. Он тысячи раз в секунду пробегает через этот свитч. Может быть, даже миллионы. Поэтому с вероятностью единица он либо в этот порт его отправит, либо в этот. Он сюда пришёл и дальше туда отправил. И дальше снова может быть он пройдёт по кругу, но никогда и ни при каких обстоятельствах этот свитч не отправит копию кадра на узел А настоящий. Если только у него таблица MAC-адресов не забилась полностью. Итак, три проблемы. Шторм, нестабильность базы MAC-адресов и множественная доставка кадров. Они приводят к тому, что у вас в 100% загрузку уходят линки, в 100% загрузку уходят матрицы коммутации, в 100% загрузку уходят процессоры на компьютерах,

на самих свитчах. Вы не можете к ним подключиться телнетом и посмотреть, что там происходит. Они в 100% загрузке лежат точно так же, потому что они точно так же ловят этот бродкаст. И боевой трафик на абонентов никогда не приходит в принципе. Боевой трафик не приходит, приходят всякие левые бродкасты. Сетка дохнет. Что делать? Ничего особо не делать, страдать. Есть протоколы, которые на самом деле являются частью процедуры коммутации. Гипотетически, если вы реализуете свитч по стандарту IEEE 802.1D, это процедура коммутации, она этому стандарту должна соответствовать, то там автоматически предполагается, что вы должны использовать технологию Spanning Tree для того, чтобы защититься от петель. Эта технология будет работать следующим образом. Она, отправляя специальные пакетики, будет определять, где возникла петля, где не возникла. И она сначала блокирует всё,

а потом там, где петля не возникла, она разблокирует коммутацию на этих интерфейсах. А там, где она обнаружила петлю, она продолжает блокировать. Смысл протокола Spanning Tree в том, что он некоторые порты для некоторых кадров будет блокировать, а некоторые нет. И это нам даёт дополнительные условия для коммутаторов: любой коммутатор никогда не отправляет трафик назад в тот же порт, любой коммутатор никогда не отправляет кадры на те интерфейсы, за которыми точно не сидит получатель, любой коммутатор никогда не отправляет кадры определённого VLAN на те порты, которые не подключены к данному VLAN, и любой коммутатор не отправляет кадры в те порты, которые заблокированы с помощью Spanning Tree. Понятное дело, можно не пользоваться Spanning Tree, можно взять и разорвать петлю вручную. Я вам скажу, как это выглядит. У вас падает сетка, потому что кто-то устроил петлю. Либо вы сами догадываетесь, что сетка сдохла, потому что у вас всё перестаёт работать. Либо у вас начинаются звонки, если у вас только не IP-телефония, что, знаешь, у нас как-то плохо всё работает,

не мог бы ты подойти посмотреть. И, как правило, таких звонков приходит одновременно штук 10–20. Одновременно звонит начальник, говорит, ты знаешь, у меня тоже что-то не работает, не мог бы ты подойти посмотреть или прислать кого-нибудь. Одновременно у вас все системы мониторинга начинают ругаться. И вы бежите в серверную комнату или в коммуникационную комнату и начинаете пытаться понять, что произошло. На всех свитчах у вас одновременно горят все индикаторы активности на всех портах, потому что все порты лежат в 100% нагрузке. Они, если моргают, то моргают синхронно. Дальше вы понимаете — о, случилась петля. Вытаскиваете первый провод, петля не пропала. Вставляете первый, вытаскиваете второй. Петля не пропала. Вставляете второй, вытаскиваете третий. Только так это работает. Можно на уровне целиком свитчей. Если у вас много свитчей, то вы выключаете первый свитч. Проблема на нём, если петля разорвалась, если у вас активность немедленно пропала. Но если не пропала, значит, зря выключили свитч. Включаете свитч и выключаете второй. И так до тех пор, пока не найдёте свитч, который устраивает петлю. Дальше на этом свитче уже дёргаете первый, второй, третий порт.

Если у вас красиво уложенные косички с проводами, то это не всегда легко сделать. Плюс всё это дело сопровождается тем, что на вас давит холодный пот, плюс у вас разрывается мобильный телефон, плюс все недовольны. Так себе удовольствие. С петлями лучше бороться всё-таки автоматизированным образом. И за это как раз Spanning Tree неплохо и отвечает. Спасибо. Спасибо.