Тем не менее при корректном подходе к контролю уровня доступа можно существенно осложнить упомянутые процедуры. При этом грамотно подготовленная сетевая инфраструктура, заметив зловредную аномалию, об этом своевременно сообщит, что поможет снизить ущерб.
Под катом перечень механизмов, которые помогут выполнить данную функцию.
Хотелось бы привести общую выжимку без лишних Вики-обоснований, но с описанием вариаций конфигурации, тем не менее иногда отступаю в ликбез, что бы стороннему читателю статья показалась более дружелюбной.
Статья выходила объемной, и, по-моему, слишком большие статьи не читаются, а складываются в долгий ящик с мыслью «как-нибудь осилю». Поэтому материал пришлось разделить, и при должном успехе составлю вторую часть с менее распространенными (по крайней мере у нас) технологиями.
Содержание:
Технологии описаны на базе коммутатора Cisco, конкретно моя тестовая модель и версия следующие:
Предполагаю, что данный вендор самый процентуально распространенный, да и самый информационно богатый, и вызывает бОльшую заинтересованность у начинающих изучать подобные темы.
Тем не менее, уверен, что после усвоения каждой конкретной технологии на циске, корректно составить конфигурацию у другого вендора не составит труда, если у Вас есть 30 мин. и обычный User Guide.
Считаю, что информация не дублирует уже существующую на хабре, хотя что-то похожее можно встретить тут и тут.
Port Security
Описание
Технология предназначена для контроля подключенных к коммутатору устройств и предотвращения аномалий или атак, нацеленных на переполнения таблицы MAC-адресов (CAM table overflow).
С помощью Port Security устанавливается максимальное количество MAC адресов на конкретный свитчпорт (сетевой порт, оперирующий на 2-ом уровне OSI) или VLAN, и контролируется доступ по заданным MAC-адресам.
Способы работы с MAC-адресами:
- Dynamic — пропускает и запоминает (на заданный период времени) любые MAC-адреса, пока не достигнет разрешенного максимума;
- Static — пускает только заранее введенный руками MAC-адрес (может быть использовано вместе с Dynamic типом);
- Sticky — учит новые MAC-адреса, записывая их в конфигурацию;
Действия в случае превышения полномочий:
- Potect — в случае лишних или не заданных МАС-адресов не пускает новые, не генерирует сислог или SNMP трап, не роняет интерфейс;
- Restrict — то же, что и Protect, но плюс лог и/или SNMP трап. А еще отчитывается в счетчик под
show port-security interface <name>:
- Shutdown (выбран по умолчанию) — предыдущее действие, но плюс интерфейс переходит в статус errdisable и перестает передавать трафик;
- Shutdown VLAN — как и предыдущее, только в errdisable переходят все интерфейсе в данном VLAN'е;
Конфигурация
Port-Security может быть активирован только, если тип свитчпорта явно задан (т.е. или Access, или Trunk). Если порт динамический (что уже неправильно), Port-Security на нем включить не получиться.
Access порты
Технология задается посредством команды switchport port-security… в режиме конфигурации конкретного интерфейса, доступные опции:
- aging — задается временной интервал, после которого динамический МАС-адрес может быть переписан;
- mac-address — дает доступ к следующей ветке:
т.е. задаем разрешенные/запрещенные адреса или говорим железке их учить;
- maximum — указываем лимит разрешенных адресов.
- violation — задаем действие из перечисленных ранее.
Устанавливаем что нужно, что не нужно пропускаем. В конце активируем технологию командой
switchport port-security без опций.В результате все выглядит примерно так:
— Если хотим разрешить неизвестно какие маки, лимитируя их количество 5-ю, ставим максимум на 5 и не задаем ничего статически. Опционально указываем время жизни.
— Если известно, что за устройство стоит на втором конце провода и больше ничего там не будет и быть не должно — максимум=1, адрес прописываем статически.
— Если ждем нового работника с новым ПК или лень узнавать MAC-адрес, ставим Sticky, после подключения перепроверяем.
Trunk порты
То же самое, только можно указывать поведение не относительно физического интерфейса, а конкретного VLAN'а. Для этого к каждой из предыдущих команд в конце добавляется vlan .
Проверка
Не прибегая к show run информация касательно Port-Security может быть найдена:
show port-security— отображает суммарно информацию об интерфейсах, их статус, количество адресов;show interface <name> switchport— более детальная информация (счетчики, отдельные опции);show mac address-table ..плюс опция, список ниже:
Команда проводит проверку актуальной информации о таблице MAC-адрессов. Например, нынешнее количество записей в таблице для конкретного VLAN'a и объем доступных записей проверяется посредствомshow mac address-table count vlan <id>:
DHCP snooping
Описание
Технология предотвращает использование не авторизированного DHCP сервера в сети, что позволяет например произвести атаку человек-посередине (man-in-the-middle, MITM). Еще защищает сеть от атак на истощение DHCP (DHCP starvation/exauction), которая имхо не особо актуальна.
Технология следит за DHCP коммуникацией в сети, которая (в основном) состоит из четырех пакетов:
- DHCP Discover — отправляет только клиент, запрос на получения IP по DHCP;
- DHCP Offer — отправляет только сервер, предложение конфигурации от DHCP сервера;
- DHCP Request — отправляет только клиент, выбор конкретной конфигурации и сервера;
- DHCP ACK — отправляет только сервер, окончательное подтверждение;
Перед активацией DHCP snooping нужно обязательно указать «доверенный» порт(ы), за которым находится DHCP сервер. Только доверенные порты будут передавать DHCP Offer и DHCP ACK (пакеты от сервера). В связи с чем ни одно устройство за другими интерфейсами этого коммутатора не сможет производить работу DHCP сервера, предлагая свои варианты сетевой конфигурации.
Очень немаловажно, что после активации DHCP snooping, коммутатор начинает следить за DHCP коммуникацией в сети и отождествлять выданные IP адреса с MAC-адресами запрашивающих устройств, складируя данную информацию в таблицу DHCP snooping binding.
Конфигурация
Под доверенным интерфейсом вводится команда
ip dhcp snooping trust:
Для предотвращения DHCP starvation под не доверенными интерфейсами указывается частота получаемых клиентских запросов с помощью
ip dhcp snooping limit rate <nr>:
Важно не занизить данную характеристику, чтобы не порезать валидный трафик. Циска советует использовать число «10».
После этого указываем конкретный VLAN для работы DHCP snooping'a и включаем непосредственно саму технологию командой без опций:
(config)# ip dhcp snooping vlan <id>
(config)# ip dhcp snoopingПроверка
- show ip dhcp snooping — отображает доверенные порты и VLAN'ы, на которых включен DHCP snooping;
- show ip dhcp snooping binding — показывает ту самую таблицу, где фигурирует привязка IP-MAC внутри VLAN'ов с включенным DHCP snooping'ом:
Dynamic ARP inspection
Описание
Технология предназначена для предотвращения ARP spoofing/poisoning атак, которая является базовым способом организации перехвата трафика (опять же атака человек-посередине/MITM), находясь в одном широковещательном домене с жертвой.
Конфигурация
Что бы эффективно предотвратить ARP spoofing, коммутатор должен иметь информацию о связке MAC-адрес/IP-адрес. Как упоминалось выше, данная информация хранится в таблице DHCP snooping. По этому корректная конфигурация эти две технологии практически всегда использует вместе.
При совместном использовании с DHCP snooping, технология активируется в режиме глобальной конфигурации командой:
(config)# ip arp inspection vlan <id>После этого в данном VLAN'е будет разрешен трафик только тех устройств, которые фигурируют в таблице DHCP snooping.
В случае, если устройства НЕ используют DHCP, необходимо проводить дополнительные меры. ARP inspection позволяет использовать статические записи. Для этого создаются списки доступа ARP, создается который из режима глобальной конфигурации командой:
(config)# arp access-list <name>Синтаксис отдельной записи ниже:
По-моему, это ужасный костыль и мир сошел с ума, но если по другому никак..
Под таким arp access-list'ом указываются все необходимые статические записи. Далее технология активируется не как прежде, а с опцией filter:
Отдельный интерфейс(ы) можно пометить как доверенные. На этих интерфейсах ARP inspection проводиться не будет:
Практически всегда доверенными устанавливаются Trunk порты (главное об этом не забыть перед активированием всего механизма). Но в этом случае важно поднять установленный по умолчанию лимит ARP сообщений — он равен 15, и может быть слишком узким, особенно для транка. Советую поставить 100-ку:
Опционально можно добавить дополнительные проверки на соответствие MAC адресов в заголовках ARP и Ethernet. Делается это командой
ip arp inspection validate <option>:
Функционал по каждой опции отдельно можно прочитать тут.
Проверка
Проверить статус технологии, включена ли, использует ли список доступа, статус проверки дополнительных опций и т.п. информацию:
show ip arp inspection vlan <id>Полезные опции у предыдущей команды (добавить в конце строки) — statistics (показывает счетчики дропов и т.п.) и interfaces (доверенные интерфейсы, лимиты ARP сообщений).
Source Guard
Описание
В случае, если нет нужды проверять всю подсеть по ARP inspection, но хотелось бы защитить от подобных угроз пару-тройку узлов, можно использовать Source Guard. На практике их функционал дублирует друг друга, хотя и есть нюансы.
Технология привязывает заданные IP-MAC к конкретному физическому интерфейсу. В результате тоже предотвращает ARP спуфинг, а также один узел сети не сможет отправить трафик от имени другого, подменив IP и MAC адреса источника (в случае ARP inspection это возможно, хотя и не является критичным).
Конфигурация
Source Guard тоже использует таблицу DHCP snooping. Она содержит не только связку IP-MAC, но и еще интерфейс, за которым находится конкретный узел.
Если узлы опять же не используют DHCP, в режиме глобальной конфигурации создается мануальная запись:
(config)# ip source binding <mac.add.ress> vlan <id> <IP.add.re.ss> interface <name>Source Guard активируется непосредственно на интерфейсе:
(config-if)# ip verify source port-securityПроверка
Проверка записей, которые использует технология, проводится командой:
show ip source binding
Что полезно, команда выводит как мануальные записи, так и взятые из таблицы DHCP snooping.
Список интерфейсов, на которых Source Guard активирован, выводится командой:
show ip verify source
Думаю, пока что хватит
В следующий раз покажу, какие еще списки доступа бывают на свичах и зачем они нужны; как контролировать коммуникацию в пределах одной подсети; попробую осветить тонкости перехода интерфейса в статус errdisable и может получиться понять, нужен ли вообще MACsec.
Комментарии (18)
bebebe
27.10.2016 21:21+1Вы серьезно замазываете номера вланов и портов на скриншотах? И не лень было?
Slavon4ever
27.10.2016 21:55Орфографию статьи было бы хорошо проверить. А в остальном годная статья ;)
Faight
28.10.2016 00:17А как же 802.1X?
Dimi3
29.10.2016 09:40Его тут уже предостаточно:
Использование стандарта IEEE 802.1x в сети передачи данных
Аутентификация беспроводных клиентов по учетным записям Active Directory
Если только поделиться опытом, но 802.1x в проводных сетях возводить не приходилось.
Ivan_83
30.10.2016 03:06Кошатники не знают что такое л2 :)
arp это уже не л2, это л3 протокол, ровно как и IP, dhcp вообще L5.
Формально л2 это портсек и лупбак детект, всё остальное это парсинг содержимого данных(пейлоада) эзернет пакета, по сути л3.
Пора уже начать забывать про ARP и писать про NDP, а то никакой новизны в материале.
DHCP snooping — у длинков называется скринингом, по сути это банальный ACL шаблон который навешивается на определённые порты дабы дропать UDP пакеты с заданными портами, ip и mac адресами, хотя последнее не обязательно указывать. Короче, примитивный оффсет матчинг, с таким же успехом на свиче можно давить uTP и многие другие протоколы.
Касательно рейтлимита на дхцп запросы — глупость полная: никто не мешает атакующему спокойно выжирать весь пул адресов даже на низкой скорости, подумаешь вместо нескольких секунд всё закончится за пару минут.
В своё время в неуправляемых сетях левые дхцп сервера убивали как раз простенькой прогой/скриптом, которая у всех найденых «левых» дхцп серверов забивала все пулы фиктивными арендами адресов.
Сейчас от этого легко защитится с помощью релей агента на клиентских портах и дхцп сервера обученного больше хх адресов в один порт не выдавать. В качестве дхцп сервера можно юзать мой перловый (у меня в вики выложен), там любая логика легко впиливается и 82 опцию он умеет разбирать.
Dynamic ARP inspection — провайдеры (те те это массово использует) не хвалили, бывают глюки.
Про 802.1x ни слова, хотя там л2 точно примазать не получится.
Ровно как и в авторизации при присоединении к мультикаст группам через радиус, эта фишка есть у длинков.
Из забавного вспомнилось что у кошек был GVRP, который в старых моделях не отключался и был на всех портах. В результате любой желающий мог включить у себя на порту любой/все вланы. После такого уже не важно чего там админ наконфигурял в дхцп, арп и пр.
aleksashka
01.11.2016 17:28arp это уже не л2, это л3 протокол
Согласно Вики ARP работает всё-таки на канальном уровне. Да, анализ содержимого фрэймов/пакетов/сегментов (тот же DHCP Snooping) выходит за пределы L2, но я всё же думаю, что автор поста имел в виду функционал, поддерживаемый L2-коммутаторами для защиты от атак реализуемых в рамках L2-участка сети.
Касательно рейтлимита на дхцп запросы — глупость полная: никто не мешает атакующему спокойно выжирать весь пул адресов даже на низкой скорости, подумаешь вместо нескольких секунд всё закончится за пару минут.
Limit rate нисколько не глупость. Чтобы атакующий не смог «выжрать» пул нужен port security (а не limit rate, на заметку автору поста), тогда с одним MAC-адресом атакующий сможет «выжрать» всего один адрес. А вот «задосить» процессор коммутатора с помощью большого количества DHCP-запросов (эта обработка не перекладывается в ASIC'и) атакующий может без особых проблем, вот тут и приходит на помощь limit rate.
Dynamic ARP inspection — провайдеры (те те это массово использует) не хвалили, бывают глюки.
Вроде нигде не говорилось о провайдерах. При упоминании Cisco я бы, в первую очередь, подумал о корпоративном секторе. К слову, о проблеме DAI – может получиться пичалька, если коммутатор хранить ip dhcp binding в RAM, а не на ftp/tftp/flash (ip dhcp snooping database). В этом случае после перезагрузки список binding'ов пуст и легитимные ARP-запросы невинных пользователей будут дропаться до тех пор, пока DHCP-клиент не обновит себе адрес.Ivan_83
01.11.2016 21:35В вики арп отнесли к линк леер потому что он за пределы не выходит.
Рейтлимит дхцп запросов таки глупость в плане защиты, разве что от дос.
Портсек нисколько не поможет от выжирания пула дхцп сервера потому что дхцп сервер смотрит мак адрес в дхцп заголовке а не в эзернет, и проверки что мак адрес в заголовке эзернет пакета совпадает с макс адресом в дхцп пакете обычно нет.
Коммутатор гонит дхцп запросы только если включён релей агент или одна из фич типа динамик арп инспекшин, во всех остальных случаях коммутатору плевать на дхцп, он их гонит как всё остальные пакеты.
Да, вот из за потери таблицы, из за того что оно может заваливать CPU свича и прочих глюков эта фича не пользуется популярностью.
ksg222
02.11.2016 10:37Не соглашусь с Вами по поводу бесполезности port security при «выжирании» DHCP пула. DHCP snooping не защитит нас от ситуации, когда хост будет генерить много DHCP-запросов, подменяя при этом MAC-адрес и в самом запросе, и в кадре Ethernet. Именно для защиты от подмены MAC-адреса в Ethernet-заголовке нам и пригодится port security. Поэтому для защиты от «выжирания» DHCP пула нам нужно будет использовать и DHCP snooping, и port security.
Ivan_83
04.11.2016 06:05Без опции из следующего комента оно работать не будет.
Кроме того, в дхцп пакете в качестве идента клиента можно писать не только мак адрес но и что угодно, как бы кошки от такого с ума не посходили :)
В любом случае мне больше нравится вариант с опцией82 и умным дхцп сервером: опция82 есть везде а «ip dhcp snooping verify mac-address» как минимум в длинках я не видел, да и мозги у сервера обычно по сильнее в плане рейтлимитингов и пр.
2 aleksashka
Да, в длинках такой опции не видел.
В таком случае кто то положит коммутатор, если рейтлимит там тоже на проц приходится.ksg222
04.11.2016 21:45Эта опция включена по умолчанию.
Что касается поля chaddr, которое как раз и проверяет DHCP snooping, туда записывается значение аппаратного адреса канального уровня (RFC 2131). Если у нас Ethernet, кроме как MAC адрес, ничего другого там быть не должно. Любые другие данные для идентификации хоста заносятся в поле client identifier.Ivan_83
06.11.2016 07:00Должно кому?)
Меня всегда поражает вот это «должно» из которого проистекают эпические баги и дыры.
Прямо ограниченность мышления какая то.
Это сеть, здесь никто никому ничего не должен и ничего не обязан. RFC это из области как делать чтобы скорее всего заработало, это не закон физики который просто так нарушить нельзя.
«по умолчанию» может внезапно меняться в разное время на разных железках.
Из практики: вендовый сервер удалённого доступа может выдавать клиентам адреса из дхцп пула, естественно у него нет никакого эзернет адреса клиента и он туда пишет текстом номер своего виртуального порта к которому клиенту подключён.
В том же RFC 2131 нигде не указано что л2 по которому пришёл пакет должен точно тем же что и л2 инициатора запроса, те даже с точки зрения этого рфк в chaddr можно писать что угодно.
И там далее по всему рфк размазана мысль о том что сервер должен как нибудь извернутся и сочинить уникальный идентификатор из chaddr, client identifier и ещё чего нибудь.
Потому что на практике бывает что и маки одинаковые у кучи народа и клиентидентифиры.
Например опенврт и прочие альтернативыне прошивки когда то давали такой эффект.
Ещё бывали партии кетайских сетевух у которых одинаковый мак.
Поэтому проще включить опцию82 и уже на дхцп сервере выдавать один и тот же IP на все запросы с конкретного порта.
Разница в подходе тут в том, что на информацию которую клиент может изменить никто не смотрит, и даже самые кривые клиенты и самые злонамеренные таки будут работать а не долбится в уши суппорту/СБ.
Мой дхцп сервер на перле ровно для этого и написан: получать запрос, парсить опцию82, дальше из бд вытягивать IP адрес который сопоставлен с этим коммутатором + портом и отдавать его клиенту. Всё что присылает клиент оно логируется, ради интереса/дебага/суппорта но в логике работы участия не принимает. Кроме одного исключения: запросы с юзерклассом RRAS дропаются.
Тема в провайдерах популярная и поскольку оно опернсорс то разошлось по россии и снг, думаю ежесуточно мой код обслуживает в сумме более 100к абонентов.
aleksashka
02.11.2016 16:04Рейтлимит дхцп запросов таки глупость в плане защиты, разве что от дос.
Я выше так и написал – это от DoS.
и проверки что мак адрес в заголовке эзернет пакета совпадает с макс адресом в дхцп пакете обычно нет.
Командаip dhcp snooping verify mac-addressвключена по умолчанию и как раз выполнят проверку (снова процессором) на соответствие MAC-адреса в Ethernet-заголовке MAC-адресу в DHCP-запросе. Т.е. при port security + DHCP snooping исчерпать DHCP-пул не получится, а задосить – можно. Тут и приходит на помощь limit rate.
Порознь каждая из «фич» может и так себе, но вместе – сила ;).
ksg222
01.11.2016 22:24Статья всё-таки про технологии, которые обеспечивают безопасность в рамках канального уровня. Поэтому уровень, на котором работают ARP, DHCP не так важен. DAI, DHCP snooping, ISG и пр., все они направлены на обеспечение защиты в том числе от атак, где происходит манипуляция с MAC-адресами. Поэтому их упоминание вполне уместно.
Что касается ARP, тут вообще интересный вопрос, к какому уровню его отнести. Это уже не L2 и ещё не L3 — некий уровень 2.5. Тут сложно однозначно ответить.aleksashka
02.11.2016 16:07+1… тут вообще интересный вопрос, к какому уровню его отнести.
Вот полностью соглашусь: не вижу огромного смысла относить ВСЕ протоколы к какому-то конкретному уровню :).
lovecraft
А как же loopback protection?
Dimi3
Обычно методы, которые скрываются под этим названием, дружно забываются, так как необходимость в них не высокая. Но именно по этому, их стоило бы осветить. Спасибо за наводку!