Защищаем сеть L2 коммутаторами

  • Tutorial


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

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

Рассматриваться будут:

• Rogue DHCP Server
• DHCP starvation
• CAM-table overflow
• VLAN hopping
• MAC-spoofing

За основу взят видеоурок CBT nuggets из цикла CCNA security.

Rogue DHCP Server


Описание

Приведем упрощенную схему работы протокола DHCP:

Discover: клиент, не имеющий IP-адреса, посылает широковещательный запрос на адрес 255.255.255.255, в котором просит откликнуться имеющиеся в сети DHCP-серверы.
Offer: DHCP-серверы присылают ответ, в котором предлагают параметры конфигурации (IP-адрес, DNS-серверы, default gateway). Ответ отсылается на MAC адрес клиента.
Request: Клиент выбирает, с каким сервером (при наличии нескольких) ему удобнее работать и отправляет запрос адреса. Данный запрос также отправляется широковещательно, но в качестве одной из опций уже указывается IP-адрес конкретного сервера.
Acknowledgment: На данном этапе запрос подтверждается сервером. После получения этого пакета клиент конфигурирует свои сетевые параметры и процесс получения адреса можно считать состоявшимся.



Цель данной атаки – подмена DHCP-сервера. При одновременном нахождении в сети двух DHCP-серверов, один из которых «вражеский», некоторая часть клиентов сконфигурирует у себя неправильные адреса и прочие сетевые реквизиты.

Вследствие подмены шлюза по умолчанию неавторизованный DHCP-сервер получит возможность прослушивать весь трафик клиентов, перенаправляя в дальнейшем пакеты по назначению. Таким образом мы имеем простейшую реализацию атаки типа MitM (Man in the Middle), которая может быть осуществлена в большинстве современных сетей.

Стоит отметить, что чаще всего атака с подменой DHCP-сервера не является атакой, как таковой. Распространены случаи, когда по незнанию в сеть подключается SOHO роутер с настроенным DHCP-сервером, причем подключается он LAN-портом. После этого у клиентов, успевших получить у него IP-адреса, наблюдаются как минимум существенные потери скорости, а чаще всего полная невозможность использования локальных и глобальных ресурсов.

Методы защиты

Простейший способ защиты от атак подобного рода – включение на всех коммутаторах функции DHCP snooping. Далее необходимо определить два типа портов:

Доверенные – порты коммутатора, к которым подключается DHCP-сервер, либо другой коммутатор.
Недоверенные – порты для клиентских подключений, за которыми DHCP-сервер находиться не может, зато вполне может находиться атакующее устройство.

В данном случае DHCP snooping необходим для того, чтобы указать коммутатору, что следует обращать внимание на пакеты DHCP offer и acknowledgment, проходящие сквозь него, и не допускать прохождения данных пакетов с недоверенных портов. Также широковещательные запросы от клиента (discover и request) теперь будут перенаправляться только на доверенные порты. Выглядеть топология должна примерно так:

Для конфигурирования функции DHCP snooping необходимо:

1) Включить ее на коммутаторе:
SW(config)#ip dhcp snooping
2) Указать для каких VLAN требуется отслеживать пакеты:
SW(config)#ip dhcp snooping vlan
3) Указать доверенные порты на коммутаторе (все остальные по умолчанию становятся недоверенными):
SW(config-if)#ip dhcp snooping trust


Спасти трафик от прослушки также может шифрование на стороне клиента, например туннелирование в транспортном режиме.

DHCP starvation


Описание

Еще одна атака, осуществляемая при помощи протокола DHCP. DHCP-пул, из которого клиенты получают IP-адреса, ограничен. Например, это может быть 253 адреса (при маске 255.255.255.0). Для нормальной работы сети этого должно хватить всем клиентам, но атака DHCP starvation стремится изменить данную ситуацию. Как происходит действие:

1) Атакующее устройство запрашивает себе IP-адрес у DHCP-сервера и получает его;
2) MAC-адрес атакующего устройства изменяется и оно запрашивает следующий, уже другой IP-адрес, маскируясь под нового клиента;
3) Такие действия повторяются до тех пор, пока весь пул IP-адресов на сервере не будет исчерпан.

Далее возможны два последствия, в зависимости от того, что является целью атаки:

• Отказ в обслуживании. IP-адреса исчерпаны, и новые хосты не могут получить их. Таким образом, их взаимодействие с сетью на этом закончится.
• Подмена DHCP-сервера. DHCP starvation отлично комбинируется с предыдущей атакой. Так как на основном DHCP-сервере свободных адресов не осталось, он выбывает из игры, и 100% клиентов достается вражескому атакующему DHCP-серверу.

Методы защиты

Самый простой способ защиты – ограничение числа MAC-адресов на порту коммутатора. Реализуется это с помощью функции port-security:

1) Переводим порт в access режим:
SW(config-if)#switchport mode access
2) Включаем port-security на интерфейсе:
SW(config-if)#switchport port-security
3) Ограничиваем число MAC-адресов на интерфейсе:
SW(config-if)switchport port-security maximum
4) Выбираем способ изучения MAC-адресов коммутатором (статический, sticky): Отличие статического адреса от sticky адреса состоит в том, что статические адреса необходимо прописывать руками, а sticky выучиваются автоматически и сохраняются в конфигурационный файл.
SW(config-if)#switchport port-security mac-address <mac-address | sticky>

5) Задаем тип реагирования на превышение числа разрешенных MAC-адресов:
protect – после переполнения все пакеты, отправленные с других MAC-адресов отбрасываются.
restrict – то же самое, но с уведомлением в syslog или по SNMP.
shutdown – порт выключается до автоматического или ручного его поднятия, также отправляются уведомления.
SW(config-if)#switchport port-security violation <protect | restrict | shutdown>

Таким образом атакующее устройство просто не сможет исчерпать лимит IP-адресов DHCP-пула, так как коммутатор не позволит ему безнаказанно изменять свой MAC-адрес.

Также здесь может помочь все тот же DHCP snooping, а именно команда
SW(config-if)ip dhcp snooping limit rate

Данная команда ограничивает количество DHCP пакетов в секунду на порт (рекомендуется не более 100 pps), а при превышении данного ограничения переводит порт в состояние err-disable, то есть временно выключает его. Обычный клиент не превысит данный лимит, а вот атакующее устройство, генерирующее сотни MAC-адресов в секунду, будет обнаружено.

СAM-table overflow


Описание

Для того, чтобы понять, как работает данная атака, необходимо понимать принцип работы коммутатора.


Представим новый коммутатор SW, к которому подключены два хоста PC1 (MAC 0000.1111.1111) и PC2 (MAC 0000.2222.2222). На них уже настроены IP-адреса (10.0.0.1 и 10.0.0.2) и они хотят общаться друг с другом. Так как они располагаются в одной подсети, наличие маршрутизатора не требуется и весь обмен пакетами будет происходить с помощью коммутатора. Итак, какова последовательность установления их общения:

1) PC1 хочет обратиться к PC2 по IP-адресу. Тем не менее MAC-адрес PC2 ему неизвестен, поэтому PC1 использует протокол ARP. Отправляется широковещательный запрос: «Компьютер с IP-адресом 10.0.0.2, сообщите пожалуйста свой MAC-адрес компьютеру с адресом 10.0.0.1, чтобы я мог общаться с вами».
2) Коммутатор пересылает запрос на все свои порты, но записывает соответствие MAC-адреса отправителя (0000.1111.1111) и порта, теперь все кадры, адресованные данному получателю он будет пересылать непосредственно, а не наугад во все доступные интерфейсы.
3) PC2 получает адресованный ему пакет, понимает что должен ответить, и сообщает свой MAC-адрес PC1. Коммутатор при этом заносит в CAM-таблицу (таблицу MAC-адресов) запись вида: (интерфейс gig1/2 – MAC 0000.2222.2222). Теперь, когда компьютеры будут обмениваться информацией, задействоваться будут только два порта, за которыми они расположены. На другие информация пересылаться не будет.

Основной смысл в том, что если коммутатор видит адрес получателя в своей CAM-таблице, он пересылает кадр в конкретный порт. Если не видит – устраивает широковещательную рассылку, в надежде, что кадр все-таки найдет адресата.

На основании этого правила и работает рассматриваемая атака. Дело в том, что размер таблицы MAC-адресов у любого коммутатора ограничен. При переполнении новые адреса реальных клиентов уже не смогут пробиться в таблицу.

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

Следует заметить, что все коммутаторы, подключенные к атакованному также подхватят фальшивые MAC-адреса и начнут вести широковещательную рассылку всех кадров.

Методы защиты

1) Port-security на всех access-портах с лимитированием максимального количество MAC-адресов.
2) Шифрование трафика – в таком случае хоть все кадры и будут рассылаться широковещательно, а производительность сети сильно ухудшится, информация, попавшая в чужие руки, не будет прочитана.

VLAN hopping


Описание

Следующая атака базируется на возможности коммутаторов автоматически согласовывать тип своего порта - access или trunk.

Немного теории о том, чем access порт отличается от trunk порта:

Как известно, протокол 802.1Q повсеместно используется во всех современных сетях. Суть его состоит в том, что он слегка расширяет ethernet кадр, добавляя туда несколько полей (в частности поле VLAN Identifier, VID). На основании данного поля коммутатор способен определить, какой группе портов адресован тот или иной кадр.



Благодаря полю VID, к одному коммутатору можно подключить клиентов из нескольких разных подсетей, тем самым ограничив широковещательный домен. Также появляется возможность объединить клиентов, подключенных к разным коммутаторам в одну логическую сеть.

По сути 802.1Q - очень гибкий механизм для создания необходимой логической топологии поверх уже существующей физической.
Рассмотрим процесс передачи кадра в сети с протоколом 802.1Q.



1) PC1 подключен к access-порту fa2/1 коммутатора SW1 в 10 VLAN’е. Это означает, что при попадании кадра на порт коммутатора, в него будет добавлен 802.1Q header с информацией о принадлежности к VLAN10.
2) SW1 пересылает тегированный кадр на SW2 через trunk-порт.
3) SW2 получает кадр, смотрит в свою CAM-таблицу и отправляет кадр в соответствующий access-порт, заголовок 802.1Q снимается.

При этом можно выделить следующие особенности:

• Клиенты ничего не знают о своей принадлежности к определенному VLAN и работают с нетегированными кадрами, заголовок 802.1Q появляется только при прохождении кадра через access-порт;
• Порт может быть нетегирован (access) только в одном VLAN (верно для коммутаторов Cisco);
• Через тегированный (trunk) порт можно передавать кадры, принадлежащие к разным VLAN.
• Существует так называемый native VLAN – при попадании на trunk-порт кадра без тега, он автоматически будет причислен к native VLAN. Как правило native VLAN’ом по умолчанию считается VLAN1 (изменяемо).
При этом кадры, принадлежащие native VLAN и попавшие в access-порт, передаваться через trunk-порт будут без тега.

Перейдем к самой атаке:

Как уже было сказано, VLAN hopping основан на том, что коммутаторы имеют возможность автоматически согласовывать тип порта. Используется для этого проприетарный протокол компании Cisco DTP (Dynamic Trunking Protocol). При его использовании (а он включен по умолчанию) возможны следующие состояния порта: dynamic auto, dynamic desirable, static access, static trunk. Предоставим сводную таблицу, как согласуются состояния двух портов, подключенных друг к другу:



Как мы видим, при определенных условиях, а именно в режимах dynamic auto и dynamic desirable порт коммутатора может согласовать свою работу в режиме trunk. Это значит, что если атакующее устройство будет вести себя как порт в режиме desirable оно согласует на себя trunk-порт и получит доступ к трафику всех VLAN’ов, которыми оперирует коммутатор.

Основная проблема заключается в том, что на коммутаторах Cisco все порты по умолчанию находятся в режиме auto. Поэтому даже если порт настроен в режиме access/auto при получении запроса на согласование его состояние может измениться на trunk/auto.

Методы защиты

Решение данной проблемы очень простое, но многие при конфигурировании коммутаторов забывают его использовать. Командой
SW(config-if)#switchport nonegotiate

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

Описание

Еще один возможный вектор атаки VLAN hopping – использование native VLAN и добавление второго тега. Работает он только в том случае, если атакующее устройство находится в том VLAN, который является native VLAN для trunk-порта.



Исходя из определения native VLAN, кадр, пришедший на порт fa2/1, находящийся в VLAN1, будет передаваться через trunk-порт нетегированным, но, так как злоумышленник PC1 присвоил ему два заголовка, на выходе он окажется с тегом VLAN2 и дойдет до атакуемого клиента, чего при нормальной ситуации быть не должно.

Следует заметить, что такая атака является однонаправленной, так как невозможно по такой же схеме передать кадр обратно.

Методы защиты

Защититься можно следующим образом:

Назначаем на всех trunk-портах неиспользуемый VLAN в качестве native.
SW(config-if)# switchport trunk native vlan 999

Теперь атака неосуществима, так как VLAN 999 не относится ни к одному из access-портов.

MAC-Spoofing


Описание

Суть данной атаки заключается в подмене MAC-адреса на сетевой карте компьютера, что позволяет ему перехватывать пакеты, адресованные другому устройству, находящемуся в том же широковещательном домене.

В таблице MAC-адресов коммутатора запись с атакованным MAC-адресом будет соотнесена с интерфейсом, на котором в последний раз был идентифицирован кадр с данным source MAC. Таким образом, до поступления кадра с атакуемого устройства, все данные коммутатор, на основании своей CAM-таблицы, будет пересылать на атакующий компьютер.

Посмотрим атаку на практике. Использовать будем следующую топологию:



Таблица SW:



Добиться воспроизведения не удалось, т.к. коммутатор при включении порта на PC2 сразу перебивал MAC на интерфейс Eth0/1, и даже при пинге с PC1 на R в дебаге на SW наблюдалась такая картина:



Практически сразу после того, как пакет с MAC-адресом приходил с интерфейса Eth0/0 коммутатор вновь привязывал данный MAC к интерфейсу Eth0/1. Объяснение этому можно найти здесь:
SW# debug ethernet interface



Связано это, как я понимаю, с реализацией эмулятора IOU и является своеобразным аналогом keepalive сообщений. Как видно, обмен пакетами с интерфейсом Eth0/1 происходит позже, чем с интерфейсом Eth0/0, соответственно, в CAM-таблицу всегда попадает Eth0/1.

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

Методы защиты

Официально рекомендуемый метод – включение port-security на интерфейсе коммутатора:

SW(config-if)#switchport mode access
SW(config-if)#switchport port-security
SW(config-if)#switchport port-security mac-address 0000.1111.1111

Смотрим на таблицу:



И видим, что теперь MAC-адрес статически закреплен за интерфейсом Eth0/0. Теперь PC2, находящийся за портом Eth0/1 недоступен, и атаку можно считать отбитой.
Поделиться публикацией
Комментарии 16
    +5
    >Самый простой способ защиты – ограничение числа MAC-адресов на порту коммутатора. Реализуется это с помощью функции port-security
    Прибивание мака гвоздями к порту — кошмарно неудобное решение, потому практически не используется.

    >Дело в том, что размер таблицы MAC-адресов у любого коммутатора ограничен. При переполнении старые адреса удаляются, заменяясь новыми (FIFO)
    Нет.

    Алгоритм таков. При получении пакета проверяется наличие smac в CAM таблице. Если присутствует, то обнуляется счетчик. Если отсутствует, то проверяется наличие свободной банки. Если банка есть, то записываем, иначе пропускаем этот шаг и ничего не делаем. Таким образом, если легитимный хост шлет пакеты чаще чем по одному за aging time, то его не вытеснят.

    >Поэтому даже если порт настроен в режиме access/auto при получении запроса на согласование его состояние может измениться на trunk/auto.
    Обычно принято говорить «switchport mode access». Это исключает согласование в транк.
    Switchport noneg — другое. Это значит, что свитч не будет слать DTP. И если режим порта dynamic, то включить noneg не получится.

    >Еще один возможный вектор атаки VLAN hopping – использование native VLAN и добавление второго тега
    Атака сугубо теоретическая. На современных каталистах (как минимум) не должна работать.
      0
      Спасибо за уточнения.
      По поводу port-security — как минимум для небольших сетей с редкими миграциями сотрудников не самый плохой вариант, хотя бы из-за того, что разом решает несколько проблем.
      0
      del
        0
        Неоднократно встречал в домосетях и мелких провайдерах на «мыльницах», когда с помощью второй проблемы борются с первой, даже инструмент специальный есть dhcdrop, так что иногда второй вид атаки это «фича а не бага». А вообще общеизвестные это инструменты, вы бы еще loopback detect описали. Все векторы атаки, кроме (VLAN hopping) решаются связкой opt82+DHCP-Snoop, а сам hopping на современном железе не воспроизвести.
          +1
          По поводу подмены мака — какой-то «рекомендованный» способ так себе — у каталистов есть ip verify source, который будет сравнивать мак и ip отправителя с записью в таблице dhcp snooping для данного порта и отбросит все пакеты, не подходящие под этот критерий.
            0
            Traffic segmentation и запрет общения клиентов между собой на l2 — ещё один способ защиты от описанных атак. Правда не во всех случаях применим, но тем не менее…
              0
              switchport protected? Да, полезная фича, дополнительно позволяет от вирусов всяких, которые между клиентами ползают, защищаться.
              0
              мне одному кажется что вместо DNS-сервера должен быть DHCP?
              0
              > Шифрование трафика – в таком случае хоть все кадры и будут рассылаться широковещательно…
              Таблицы маков — это L2, а шифрование — это аж L6. Как эти вещи связаны? Как шифрование траффика поможет защититься от перезаполнения таблиц маков??
              Кстати, коммутаторы хранят не совсем таблицу. Хранится хэш по паре мак-порт. так поиск работает быстрее
                0
                Таблицы маков — это L2, а шифрование — это аж L6.

                Откройте для себя шифрование на уровне L2 — MACSec.

                Кстати, коммутаторы хранят не совсем таблицу. Хранится хэш по паре мак-порт. так поиск работает быстрее

                Понятное дело, что они не перебором ищут :) Но и таблицу тоже хранят, из которой строится хеш.
                  0
                  Думаю, имелось в виду, что при шифровании на L6-L7 атаки на низлежащих уровнях могут привести к отказу в обслуживании, но не к перехвату трафика или MITM.

                  О существовании реализаций macsec на участке между свитчем и клиентом мне слышать не доводилось.
                    0
                    О существовании реализаций macsec на участке между свитчем и клиентом мне слышать не доводилось.

                    Так эта, максек это как раз оно же. А для шифрования свитч-свитч у цыски есть вариация на тему под названием, вроде, TrustSec.
                    0
                    Открыл, спасибо.
                    А разве MACSec доступен в РФ? там ж вроде лицензия ФСБ требуется.
                      0
                      В теории, конечно, наверное, да :)
                      Но на практике проблем особых нет, ограничения чисто программные и несложно в большинстве случаев обходятся.
                  0
                  рекомендую рассмотреть(странно что Вы сами это не упомянули):
                  1) для DHCP использовать DHCP relay + opt.82
                  2) ddos protection, acl, arp spoofing pervention, loopdetect, filted netbios/extnetbios
                  3) кстати, почему нет фильтрации мультикастов? /злобный смех/

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

                  Самое читаемое