Доброго времени суток. В данной статье рассказ пойдет о нескольких возможных атаках на сетевое оборудование, защититься от которых поможет правильная конфигурация коммутаторов.
Вся терминология и конфигурационные команды приведены в соответствии с документацией компании 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 <x>
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) Включаем port-security на интерфейсе:
SW(config-if)#switchport port-security
2) Ограничиваем число MAC-адресов на интерфейсе:
SW(config-if)switchport port-security maximum <x>
3) Выбираем способ изучения MAC-адресов коммутатором (статический, sticky): Отличие статического адреса от sticky адреса состоит в том, что статические адреса необходимо прописывать руками, а sticky выучиваются автоматически и сохраняются в конфигурационный файл.
SW(config-if)#switchport port-security mac-address <mac-address | sticky>
4) Задаем тип реагирования на превышение числа разрешенных 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 <x>
Данная команда ограничивает количество 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-адресов у любого коммутатора ограничен. При переполнении старые адреса удаляются, заменяясь новыми (FIFO).
Таким образом необходимо всего лишь сгенерировать большое количество адресов и заставить коммутатор записать их в свою таблицу, чтобы реальные адреса реальных устройств вышли из нее. В таком случае коммутатор начнет, рассылать кадры, адресованные конкретному получателю на все порты, находящиеся в том же 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-таблицу для VLAN10 и отправляет кадр в соответствующий 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 port-security
SW(config-if)#switchport port-security mac-address 0000.1111.1111
Смотрим на таблицу:
И видим, что теперь MAC-адрес статически закреплен за интерфейсом Eth0/0. Теперь PC2, находящийся за портом Eth0/1 недоступен, и атаку можно считать отбитой.
Автор: Avtandilko
