Технологии безопасности сети на 2-ом уровне OSI. Часть 1

[lovecraft]

А как же loopback protection?

[Dimi3]

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

[bebebe]

Вы серьезно замазываете номера вланов и портов на скриншотах? И не лень было?

[Slavon4ever]

Орфографию статьи было бы хорошо проверить. А в остальном годная статья ;)

[Dimi3]

Статью доработал. Спасибо за отзыв!

[Slavon4ever]

Да пока не за что. Лишние мягкие знаки остались на своих местах ((

[Faight]

А как же 802.1X?

[Dimi3]

Его тут уже предостаточно:
Использование стандарта IEEE 802.1x в сети передачи данных
Аутентификация беспроводных клиентов по учетным записям Active Directory

Если только поделиться опытом, но 802.1x в проводных сетях возводить не приходилось.

[aleksashka]

arp это уже не л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-клиент не обновит себе адрес.

[ksg222]

Не соглашусь с Вами по поводу бесполезности port security при «выжирании» DHCP пула. DHCP snooping не защитит нас от ситуации, когда хост будет генерить много DHCP-запросов, подменяя при этом MAC-адрес и в самом запросе, и в кадре Ethernet. Именно для защиты от подмены MAC-адреса в Ethernet-заголовке нам и пригодится port security. Поэтому для защиты от «выжирания» DHCP пула нам нужно будет использовать и DHCP snooping, и port security.

[ksg222]

Эта опция включена по умолчанию.

Что касается поля chaddr, которое как раз и проверяет DHCP snooping, туда записывается значение аппаратного адреса канального уровня (RFC 2131). Если у нас Ethernet, кроме как MAC адрес, ничего другого там быть не должно. Любые другие данные для идентификации хоста заносятся в поле client identifier.

[ksg222]

Это сеть, здесь никто никому ничего не должен и ничего не обязан.

Чтобы эта сеть работала, устройства должны поддерживать общепринятые (хотя бы в разрезе определённой группы) методы/протоколы/кодировки/и прочие правила. Иначе каждый будет гнать свою «пургу». При этом, если устройства разных производителей, поддержка общих правил позволяет всему этому «зоопарку» совместно работать. Для этого и придуманы RFC/IEEEE и прочие стандарты.

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

вендовый сервер удалённого доступа может выдавать клиентам адреса из дхцп пула

А на базе какой технологии подключаются клиенты при удалённом доступе? Если это, например, PPTP, в поле chaddr будет заноситься аппаратный адрес PPP. Но так как у PPP такого адреса фактически нет, в тех реализациях, которые видел я, подставляется MAC-адрес какого-нибудь интерфейса. В вашем случае, скорее всего удалённые пользователи имеют интерфейс Ethernet, поэтому в поле chaddr подставляется MAC-адрес именно его.

Более того, PPTP, как и другие технологии туннелирования, уже явно выходят за пределы контроля DHCP snooping на коммутаторах.

номер своего виртуального порта

Хотелось бы увидеть, как это выглядит, так как не совсем понимаю, о чём идёт речь.

В том же RFC 2131 нигде не указано что л2 по которому пришёл пакет должен точно тем же что и л2 инициатора запроса

Такого нет, так как пакет с DHCP запросом может легко прийти из другой сети по средствам, например, DHCP relay. В RFC указано лишь, что chaddr = client's hardware address.

с точки зрения этого рфк в chaddr можно писать что угодно.

Повнимательнее: раздел 4.4.1 — The client MUST include its hardware address in the 'chaddr' field.

Потому что на практике бывает что и маки одинаковые у кучи народа

Одинаковые MAC адреса — это уже не нормально, особенно в рамках одной сети. Почему-то мне кажется, что увидев два запроса DHCPREQUEST с одним и тем же chaddr (в случае отсутствия client identifier), DHCP-сервер выдаст один и тот же IP-адрес.

Мой дхцп сервер… парсить опцию82

А разве использование вашего DHCP-сервера и опции 82 отменяет port security и DHCP snooping? Нет. Ваш вариант защищает DHCP-сервер от «выжирания» адресного пула и, видимо, снимает некий «головняк» по поводу соответствия полей в зоголовке пакета. Но не имеет никакого отношения к противодействию атакам mitm или cam table overflow на коммутаторе.

Всё что присылает клиент оно логируется, ради интереса/дебага/суппорта но в логике работы участия не принимает.

А если за одним портом будет два клиента, желающих получить адрес по DHCP? Разве он не будет смотреть ещё на что-то кроме идентификатора коммутатора и порта?

ежесуточно мой код обслуживает в сумме более 100к абонентов

Это здорово и я за вас искренне рад.

[aleksashka]

Рейтлимит дхцп запросов таки глупость в плане защиты, разве что от дос.

Я выше так и написал – это от DoS.

и проверки что мак адрес в заголовке эзернет пакета совпадает с макс адресом в дхцп пакете обычно нет.

Команда ip dhcp snooping verify mac-address включена по умолчанию и как раз выполнят проверку (снова процессором) на соответствие MAC-адреса в Ethernet-заголовке MAC-адресу в DHCP-запросе. Т.е. при port security + DHCP snooping исчерпать DHCP-пул не получится, а задосить – можно. Тут и приходит на помощь limit rate.

Порознь каждая из «фич» может и так себе, но вместе – сила ;).

[ksg222]

Статья всё-таки про технологии, которые обеспечивают безопасность в рамках канального уровня. Поэтому уровень, на котором работают ARP, DHCP не так важен. DAI, DHCP snooping, ISG и пр., все они направлены на обеспечение защиты в том числе от атак, где происходит манипуляция с MAC-адресами. Поэтому их упоминание вполне уместно.
Что касается ARP, тут вообще интересный вопрос, к какому уровню его отнести. Это уже не L2 и ещё не L3 — некий уровень 2.5. Тут сложно однозначно ответить.

[aleksashka]

… тут вообще интересный вопрос, к какому уровню его отнести.

Вот полностью соглашусь: не вижу огромного смысла относить ВСЕ протоколы к какому-то конкретному уровню :).