Защита VLAN, CDP и списки контроля доступа (ACL)

Запись, мы начали. Сегодня у нас с вами 6 октября, уже пятый день нашего курса CCNA Security. Мы вчера с вами разобрали такое понятие как keychain — связка ключей. Это довольно важное понятие, будет у нас когда мы работаем с маршрутизаторами, с коммутаторами, с операционной системой Cisco IOS. В ней мы можем хранить ключи, которые будут в дальнейшем использоваться для подписи сообщений многих протоколов. Поэтому имеет смысл сразу учиться работать именно со связкой ключей — указывать те же самые ключи на интерфейсах отдельно для каждого протокола. Это очень удобно. Давайте посмотрим, как это всё настраивается, попробуем с вами — работает у нас

это или не заработает. Но для начала давайте OSPF поднимем быстренько. Так, интерфейс наш g0/1, просто всё в area 0, и этого достаточно. Я думаю, все OSPF подняли, соседи у нас видны, всё у нас работает. И теперь — что мы забыли? Мы забыли, надо хотя бы loopback создать, чтобы в этот OSPF поместить. Хотя это не так критично. Давайте создадим loopback с адресом — номер комплекта, и тоже поместим в area 0. Хотя это не обязательно, просто для красоты. У нас всё равно будут те же

hello-сообщения бегать подписанные, поэтому подпись мы проверим. Теперь давайте приступать к настройке того самого keychain — связки ключей. Как всё дело настраивается: этих keychain можно создать несколько. Можно создать, например, связку ключей для аутентификации протоколов, связку ключей для чего-нибудь ещё — для многих задач. Мы сделаем один keychain, посмотрим, что он у нас создался, и дальше настроим уже протоколы динамической маршрутизации с этими ключами. Настраивается элементарно. У нас есть команда key chain с каким-нибудь именем, например ROUTING_KEYCHAIN. А дальше один за другим мы будем добавлять в эту связку ключей собственно сами ключики. Это делается командой key, после которой нужно обязательно указать номер ключа. Они не обязательно должны

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

задать какой-то key-string. Key-string — здесь имеется в виду какая-то фраза, из которой будет формироваться наш ключ. Давайте напишем cisco — ничего более оригинального мне в голову не пришло, но и неважно. Что ещё можно задать? Можно задать криптографический алгоритм. По поводу умолчания я не скажу, какой криптографический алгоритм будет стоять по умолчанию. В старых версиях IOS это будет всё от версии зависеть, от платформы. В старых версиях был MD5, сейчас, по-моему, SHA-1 256. Но я могу набрать, мы можем проверить. Андрей спрашивает: если с одной стороны keychain в OSPF, с другой прописан пароль — не будет соседства? Нет, не будет, потому что если просто прописать пароль, то номер ключа не будет. Номер ключа передаётся.

Key-string — на самом деле это парольная фраза, на основе которой потом будет формироваться сам ключ. Будет запускаться математическая операция, брать как исходные данные этот самый key-string и получится ключ. На самом деле это не сам ключ. Можно задать key-string, написать единичку, и это не означает, что ключ, с помощью которого будет подпись, будет единичка. Нет, ключ будет большой. Размер ключа я вам не подскажу, который будет использоваться, но я думаю, что может быть 512 бит — он такой довольно стандартный. Давайте дальше. Криптографический алгоритм я не буду сейчас ставить, оставим по дефолту. Главное, чтобы у нас совпадал номер ключа и

собственно сам ключ, то есть парольная фраза — она должна быть тоже у нас с вами одинаковой. Как расшифровывается HMAC? HMAC расшифровывается Hash-based Message Authentication нет... Hash-based Message Authentication Code — вот так, вспомнил. HMAC — это стандартный механизм подписи сообщений. Код аутентификации — ещё можно назвать. Грубо говоря, то, что мы смотрели с вами на слайде — прогонять через воронку. Так. Что мы ещё можем здесь задать? Смотрите, по поводу времени. Мы можем указать две временные границы,

то есть время, на протяжении которого этот ключ мы будем принимать, либо время, когда мы будем отправлять этот ключ. Например, accept-lifetime, и мы можем здесь указать, начиная с какого времени мы начнём этот ключ принимать. Зачем это сделано — мы с вами смотрели на слайдах. Мы в принципе можем сейчас пользоваться одним ключом и запланировать смену ключей, скажем, которая будет у нас этой ночью. И мы можем сказать, что новый ключ, который мы сейчас забиваем, мы начнём принимать только начиная с 12 часов ночи. То же самое — мы можем сказать, что этот ключ мы начинаем отправлять только в 12 часов ночи. До 12 часов ночи этот ключ работать вообще не будет, а вместо него будет использоваться какой-то ключ, который у нас сейчас есть — старый. И в 12 часов ночи наш роутер начнёт и принимать новый ключ, и отправлять новый ключ. Мы можем

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

Криптографический алгоритм — алгоритм хэширования — мы уже обсуждали. Сейчас мы посмотрим, кстати, что у нас по умолчанию. Как просмотреть всё это дело — show key chain. Key chain у нас с вами покажет наш ключ. Если хочется поподробнее — по-моему, подробнее он не скажет. Он нам просто покажет, какие есть сейчас связки ключей и какие есть у нас ключи. Обратите внимание на такую вещь: когда мы просим роутер показать наши связки ключей, эти самые парольные фразы показываются в открытом виде. Если посмотреть в нашем running-config,

то здесь у нас тоже самое — всё это в открытом виде показывается. Если я не ошибаюсь, по-моему, service password-encryption их не шифрует... А нет, он их шифрует. Но прикол в том, что здесь всё равно у нас показывается в открытом виде. Кстати, я могу рассказать про интересный хак. При этом key chain он не шифрует. Интересный хак, связанный с седьмым методом шифрования, если кто-то не знает. Сейчас подождите, просто у нас система новая. Сейчас я хочу посмотреть...

Это так, жизненное маленькое замечание. Нет, сейчас он по MD5 шифрует. Знаете, для тех, кто не знает, например, если у вас зашифрованные пароли в системе с помощью так называемого обратимого, седьмого шифрования — обратимого, — то в принципе можно этот зашифрованный пароль вставить в keychain. Когда вы указываете строку для формирования ключа, вставить эту строку с указанием, что это шифрование типа 7. И потом show key chain вам покажет расшифрованный пароль. Есть такая, можно сказать, уязвимость в операционной системе. Например, сказать key chain ROUTING,

создать ключ 2, key-string — и сказать, что мы сюда вставляем зашифрованный пароль шифрованием типа 7, а потом сказать show key chain — и нам покажет. Вот он, ключ 2, который я создал — открытым текстом. Так что старайтесь не использовать шифрование типа 7. Это секрет Полишинеля — про это все давно знают. Но использовать его не будем. Дальше. Keychain мы настроили. К сожалению, я так и не сказал вам, какой метод хэширования у нас используется по умолчанию — алгоритм. Но если сейчас надо из него выйти...

Я, по-моему, не ошибусь, если скажу, что он использует MD5 по умолчанию. Если поставить что-то отличное от MD5, например SHA-1, то... Блин, он тоже не хочет показывать. Нет, я не прав. Ладно, по поводу алгоритма, с которым делается хэширование, — лучше вам ничего не врать. Я не знаю, какой по умолчанию в нашей, в данной системе. Раньше был MD5. Давайте дальше настраивать. С keychain разобрались. Как его создавать — мы знаем. Теперь давайте в OSPF настроим нашу подпись. Смотрите, делается это элементарно. Раньше, без использования keychain, нужно было вводить несколько команд. На интерфейсе настраивается

подпись сообщений для OSPF прямо на интерфейсе. Мы говорим — раньше надо было говорить ip ospf authentication, потом говорить message- digest. Обратите внимание: OSPF поддерживает MD5, а EIGRP, по-моему, поддерживает и SHA. Раньше надо было писать message-digest, потом задавать authentication key отдельно. Сейчас намного всё проще: мы говорим authentication key-chain и говорим просто имя нашей связки ключей. Всё. После этого нам не нужно даже перезапускать процесс OSPF, потому что

он, по-моему, подхватывает сам. Интерфейс GigabitEthernet 0/1 — если посмотреть информацию, как он работает на этом интерфейсе, то мы с вами увидим, что криптографическая аутентификация у нас включена, и он отправляет у нас ключ номер два. Ключ номер два он отправляет просто потому, что у него есть ключ номер два. Смотрите, это ещё одна небольшая демонстрация, про которую на слайде не сказано — надо дописать: он будет если есть несколько ключей, выбирать старший ключ — старший по номеру. Я сейчас создал ключ номер два, и у меня с вами ничего не срослось — у меня все соседства полетели, потому что просто у меня есть SHA-1, который не работает.

Сейчас я ключ номер два убью, если позволите. Команда на интерфейсе очень простая. Сейчас, подождите, команда на интерфейсе очень простая: ip ospf authentication — что же за клавиатура такая — key-chain — и просто указать keychain ROUTING_KEYCHAIN. У меня всё, больше на самом деле параметров никаких нет. Процесс OSPF сам подхватит этот keychain. Но он пишет, что неизвестный алгоритм. А потому что он не захотел подхватить без указания алгоритма. Всё-таки придётся

указать в связке ключей алгоритм, который я не хотел указывать. Cryptographic-algorithm — пусть будет MD5. Сделайте для ключа один указание алгоритма жёстко. Всё, теперь он подхватил, сказал, что MD5. Очень странно, потому что по умолчанию раньше ставился и так, но ключ создавался с MD5. Но я вижу, что всё подхватилось. Почти всё. Сейчас... Нет, Роман, я ещё раз говорю: номер ключа — он будет передаваться, поэтому у нас номера ключей должны совпадать. Единичка должна быть. Он, видите, говорит, какой ключ он посылает. Полезная команда, чтобы посмотреть это — show ip ospf interface и

собственно на каком интерфейсе. Ничего страшного, если кто не успевает — не волнуйтесь, я всех жду, и все остальные тоже ждут. Keychain настраивается так: сначала key chain с именем, потом мы создаём ключ номер один — номера ключей должны совпадать, — говорим ему key-string и указываем алгоритм MD5. В этой версии IOS он по умолчанию не ставился как MD5, и OSPF не понял. Больше для настройки keychain в принципе ничего не надо. Сейчас, секундочку... Олег, всё правильно — вам надо указать cryptographic-algorithm в связке ключей. У вас OSPF не знает, какой

ему используется алгоритм. Нет, там cryptographic-algorithm — это не выключено. По умолчанию просто всё зависит от версии операционной системы, потому что в некоторых версиях создаёшь keychain, просто ключ указываешь, и он автоматически MD5 указывается. Здесь, в этой версии, надо жёстко указать именно алгоритм, чтобы OSPF потом подхватил и сказал, что у нас криптографический алгоритм MD5. Соседи у нас — кто-то уже есть. Debug посмотреть — в момент чего? Я не думаю, что сейчас debug смотреть — хорошая идея, потому что их прикольно конечно почитать, но

не сейчас. Давайте посмотрим — ещё есть EIGRP. Настроим по-быстрому. Или не будем с EIGRP заморачиваться? Да, зачем... Начинается... Ладно, просто я покажу, как в EIGRP настраивается. В принципе настройка будет отличаться. Настройка в EIGRP — я поэтому сейчас и показываю настройки EIGRP, потому что там чуть-чуть отличается. В EIGRP в принципе всё похожим образом:

мы создаём также keychain, можем использовать тот же самый keychain — нам никто не запрещает. У нас есть keychain с MD5, и использовать тот же самый ключ для подписи, для аутентификации EIGRP-сообщений. Здесь, кто не успел настроить EIGRP — просто халтурный EIGRP настраивается двумя командами: создаётся процесс EIGRP. Обратите внимание — 100 автономную систему я написал: router eigrp 100 и network 0.0.0.0. Network 0.0.0.0, если кто-то забыл, указывает на то, что включить EIGRP вообще на всех интерфейсах для всех адресов. Но это так, халтурно. Андрей: а почему это незаконно? По-разному бывает. С

точки зрения, если прям такой уж нормальной безопасности — конечно, это не очень нормально. Нет, это законно, это никто не запрещает так настроить. EIGRP — на самом деле команда network, вы же знаете, вы должны знать, что команда network не указывает сети какие-то, она просто указывает, где искать, сейчас в каком диапазоне искать интерфейсы, на которых потом включить EIGRP. Включаются интерфейсы в EIGRP. Так вот, команда network 0.0.0.0 она просто говорит включить везде. Ничего в этом страшного нет, если мы на стенде это делаем, в тестовой среде. И в каких-то случаях, если у вас у роутера два интерфейса, и там и там соседи надёжные, и надо включать и там и там — быстрее network 0.0.0.0 забить. Или наоборот, когда у вас бывает так, что, например, 500 туннелей на роутере и они

все в одной адресации — можно так. Это халтура, это не очень красиво, хотя иногда нужно сделать именно так. Я помню, в своё время когда сдавал ещё экзамен CCIE, мне какая-то лаба была на EIGRP — с одной лабой там просидел полчаса почти, потому что надо было анонсировать с двух интерфейсов. Я там сидел считал, subnetting'ом занялся, думаю, как бы просчитать масочку красивую, чтобы два интерфейса включились и больше ничего не включилось. На самом деле я замучился, никак не мог это включить. Чуть ли не до слёз — у меня уже всё, обидно, потому что вроде лаба на экзамене и надо сделать обязательно. А потом оказалось, что надо было просто тупо взять /16 маски, всё это забить — всё заработало. Но это не реальная жизнь, это лаба на

экзамене. Так, как включается аутентификация EIGRP. На интерфейсе EIGRP будет включаться двумя командами, то есть сначала нам надо включить саму аутентификацию — вот так она включается: ip authentication mode eigrp 100. Просто сам факт, что у нас на этом интерфейсе будет аутентификация EIGRP работать. И потом указать keychain: ip authentication key-chain eigrp 100 — и имя нашего keychain указать. В принципе больше ничего для включения аутентификации EIGRP не надо. Десятый номер уже сделал? Посмотреть, как всё это работает: show ip eigrp interfaces detail. В этой простыне можно увидеть, что

аутентификация включена, подписываются у нас все сообщения по алгоритму MD5, и используется связка ключей ROUTING_KEYCHAIN. Всё, что мы настраивали в лабе, у нас есть на этих трёх слайдах. Это настройка keychain со временем — здесь есть пример. Keychain можно указать, когда мы его начинаем, и когда заканчиваем. Когда мы начинаем его, например, отправлять и когда перестаём отправлять. И то же самое с временем принятия — когда мы начинаем и когда мы заканчиваем. Дальше — проверку keychain мы обсудили. Здесь оговорка, что время, когда мы принимаем, нужно задавать с запасом. Мы лучше будем принимать

ключи ещё час после того, как они протухли — это нормальная практика, именно чтобы побороть расхождение часов. Аутентификация в OSPF — мы посмотрели, настраивается одной единственной командой на интерфейсе. Этого достаточно, но не забывать указать криптографический алгоритм, потому что не везде он подхватывается по умолчанию как MD5. Аутентификация в EIGRP двумя командами включается: сначала просто сказать, что здесь аутентификация для EIGRP должна работать, и потом просто указать связку ключей. Всё, больше никаких сложных телодвижений не нужно делать. Криптография включается, сообщения подписываются — и всё хорошо. На этом мы модуль про control plane, management plane закончили. Я загружаю новые слайды и новый модуль. Сейчас у нас будет следующая интересная тема. Смотрите, вчерашний разговор

по поводу интерфейсов — ещё раз проговорим, какой трафик в какой интерфейс подпадает. Короче, здесь на слайде, и не только на слайде, а везде указано, что в host-интерфейс у нас будет попадать то, что направлено к самому хосту, то, что имеет адресом назначения именно наше устройство. В transit-интерфейс — дело в том, что сюда будет — и про туннели было сказано — в transit-интерфейс попадает трафик, который не может быть прямо сейчас обработан CEF. Если помните небольшой рассказ из сессии NP или кто сейчас учится на сессии — MPLS уже обсуждали: у CEF есть такая операция punt — это когда он что-то не может обработать в данный момент, он отправляет на центральный процессор. Но это является именно

транзитным трафиком — просто отправил на центральный процессор, потому что, например, ещё нет ARP-записи. Пришёл пакетик, для него нет ARP-записи, не знаю куда отправить — отправляем на процессор. Процессор уже запустит процесс ARP, и дальше, когда будет ARP-запись, CEF уже будет просто обрабатывать трафик транзитный без обращения к процессору. И была оговорка здесь, что туннель, проходящий через роутер, — мы за неё вчера зацепились. Я вам попытался соврать, потому что сам неправильно понял эту фразу. Там написано в англоязычной документации: туннель, который не терминируется на роутере. Короче, я сегодня убил на это довольно много времени и перерыл всю документацию. Везде написано одна и та же фраза, но нигде не объясняется, что это за туннели такие, которые будут обрабатываться на процессоре —

транзитные туннели. Потому что транзитный трафик обрабатывается как обычные IP-пакеты. И единственное — даже на официальном форуме Learning Network — даже там ребята, у которых по четыре CCIE, они приводят выдержку из документации и ничего внятного сказать не могут. Короче, так и осталось это загадкой. Одно из предположений, которое я видел, — это тот трафик, который может быть идёт из одного туннельного интерфейса в другой туннельный интерфейс. Там он на процессоре может обрабатываться. В принципе, так что не цепляйтесь к этой фразе — именно «туннель, проходящий через роутер». Я взял её из официальных руководств, сам её неправильно понял. Так что я прошу прощения, что вчера ввёл в заблуждение. Не цепляйтесь к этой фразе, просто запомните, что в transit-интерфейс попадает

тот трафик, который обрабатывается на центральном процессоре — транзитный трафик, который мы не можем с помощью CEF обработать. Всё, я думаю, что на этом мы тему закроем. Давайте к следующему модулю переходить. Следующий модуль — Layer 3, это защита коммутации. Про control plane, management plane уже более-менее в первом приближении нам ясно. Здесь будет разговор про data plane, про коммутацию. Здесь необходимо сказать вот какую простую, казалось бы, очевидную вещь. Она на самом деле очевидна, но иногда просто выпускают из виду и не уделяют внимание. Дело в том, что если посмотреть на ту же самую модель OSI, становится совершенно ясным, что от

канального уровня, от data link уровня, будут зависеть все остальные уровни. И атаки на канальный уровень являются достаточно серьёзным, потому как, скомпрометировав данные на канальном уровне, все остальные уровни перестают быть защищёнными. Мы можем как угодно защищать наше приложение, как угодно мы можем строить защиту на сетевом уровне, но если у злоумышленника есть возможность устроить атаку на канальном уровне, то всё — пиши пропало. Во-первых, какие атаки — ладно, про атаки мы сейчас будем ещё разбираться, мы посмотрим самые очевидные и самые основные. Просто общий характер атак на канальном

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

кроме порта источника. А вот до полива внизу следует — не полива, это просто заимствованные слайды, то что мы не стали отрисовывать новые слайды про коммутацию, зачем — мы взяли из своих же слайдов с курса ICND1. Я думаю, что вы это всё должны хорошо знать: то, как работают коммутаторы, их процесс, что такое broadcasting, что такое unicast forwarding. Ничего нового в этом курсе мы не увидим. Рекламная отсылка, чтобы ещё раз записались на курсы CCNA. Всё правильно, Глеб Вадимович говорит про VLAN'ы. Мы тоже помним, мы же помним, как работают VLAN'ы, правда? Я думаю, что если для кого-то эта информация новая — поднимите руку, напишите много восклицательных знаков в чате, а то вдруг кто-то не знает, а я пролистываю слайды сейчас со спокойным сердцем. Нет, Андрей, про VxLAN'ы мы сейчас не будем разговаривать,

эта тема не для нашего курса, мы здесь по другому случаю собрались. Юрий расстроился, потому что не будем про VXLAN'ы говорить. Про метки VLAN вы тоже все знаете. Мы с вами немножечко коснёмся механизмов 802.1Q и того, как на них устраивается атака. Я думаю, что, кстати, кто учился на курсе Switch, могут знать тему, которую мы сейчас будем разбирать — там на курсе Switch что-то будет тоже говориться. В принципе эти слайды за ICND1 я сейчас спокойно пролистаю, и будем уже говорить, рассматривать с точки зрения безопасности. Как настраиваются порты, мы тоже все прекрасно помним: switchport mode на интерфейсе. Что вам сказать

про эту настройку — я думаю, что вы помните. Также из CCNA, что есть такой замечательный протокол DTP — Dynamic Trunking Protocol. Это проприетарный цисковский протокольчик, с помощью которого коммутаторы могут договориться друг с другом и согласовать транк. Андрей правильно сказал, что главная рекомендация в настройке интерфейсов на коммутаторе — это сразу сказать switchport nonegotiate, чтобы отключить этот самый протокол DTP. Он может привести к не очень хорошим последствиям, которые мы сейчас с вами рассмотрим дальше. Но сразу скажу, что использование протокола DTP не слишком оправдано, вообще не оправдано. Глеб правильно сказал — слоган, да, что есть технологии и

курсы, на которых рекомендуют технологии отключать. Сама Cisco рекомендует отключать этот протокол. Но его придумали — не то что сдуру, понятно, что на самом деле удобно и прикольно, когда есть большое какое-то коммутационное поле, в него добавить новый коммутатор куда-то в серединку — он сразу со всеми всё согласует. А ещё если VTP — так вообще красота, он ещё все VLAN'ы подтянет, здорово. Но с точки зрения безопасности так делать лучше не нужно. Дальше, про транки мы знаем, я прямо пролистываю. Про native VLAN мы тоже помним, да? Про концепцию, что изначально эта концепция придумывалась для поддержки абонентов в канальных средах, которые между коммутаторами, чтоб передавать какие-то

кадры нетегированные по транку. Сейчас, сегодня причин использовать native VLAN в принципе нет. На native VLAN есть атаки, мы сейчас эти атаки будем с вами разбирать. Для native VLAN нужно использовать неиспользованный VLAN, так что он не нужен. Давайте про атаки на VLAN чуть-чуть поговорим. Вообще, на самом деле эти атаки в реальном мире встречаются не так часто, но встретить их можно. Я даже не знаю, можете ли вы столкнуться с этим или нет, но раз они есть в курсах и из года в год, из курса в курс, из версии в версию постоянно про эти атаки на VLAN'ы рассказывается, значит, это где-то ещё до сих пор присутствует. Атака достаточно синтетическая, потому что должно быть соблюдено несколько условий, чтобы она прошла. Но надо

понимать, что она односторонняя. Эти атаки вида VLAN hopping — hopping — это перепрыгивание, когда атакующий может отправить какие-то кадры в другой VLAN, не в свой VLAN. Соответственно, вредоносными мы будем подразумевать трафик, такие кадры. Очень просто, на самом деле. Во-первых, что может сделать атакующий — этот самый DTP использовать, чтобы просто согласовать транк с коммутатором. Даже если вы поместили атакующего в такой-то VLAN, сделали switchport access VLAN 10, мы его поместили вроде бы как в 10-й VLAN, но не отключили DTP, то почему бы нет — он может поставить коммутатор с DTP либо запустить DTP как-то программно на своём компьютере и согласовать транк с помощью протокола DTP. В

таком случае согласуется транк, и он будет работать как транк, и в него можно спокойно посылать тегированные кадры с 802.1Q-меточкой. Таким образом получается VLAN hopping. Это даже не чистый VLAN hopping, не перепрыгивание из VLAN'а в VLAN — на этот порт перестаёт быть access-портом, здесь получается транк. Это первый способ, который можно использовать для того, чтобы перепрыгнуть в другой VLAN. Либо есть атака с двойным тегированием. Здесь тоже нужно, чтобы несколько условий было соблюдено, так сложились звёзды. Во-первых, ошибка проектирования — она существенная. Если атакующий может послать кадр с меткой VLAN такой же, как native VLAN между коммутаторами — это во-первых. Видите, тут условий

много. Во-первых, должен быть native VLAN. Если вдруг — не знаю зачем — это именно ошибки проектирования, зачем поставили native VLAN между коммутаторами. С другой стороны, надо знать VLAN жертвы — это другой вопрос, и в предыдущей атаке тоже надо было знать VLAN жертвы. Здесь именно задача стоит — перепрыгнуть уже в известный VLAN. Во-первых, должны быть кривые руки у тех, кто это настраивал, чтобы поставить номер VLAN, используемый как access, на native — не очень правильно, да. Атакующему должен быть известен native VLAN. Опять же, это посложнее узнать, но, наверное, можно. Правда, я не знаю как — native VLAN штука локальная,

и вклиниться теоретически можно в этот транк каким-то образом физически. Но с другой стороны, если физически сюда вклиниться, уже узнать native VLAN можно. Например, откуда передаётся native VLAN — кто-нибудь вспомнит? Есть такой протокол служебный у Cisco. Я уже всё сказал вам. Да, именно в протоколе CDP. Вот там найти VLAN — он как бы передаётся, его как-то можно узнать. Но ладно, согласовывать — прошу прощения — опять же, согласовывать транк здесь не обязательно вообще. Если у нас этот порт настроен как access-порт, то он не должен принимать тегированные кадры.

Но по факту на некоторых платформах access-порт совершенно спокойно будет принимать тегированные кадры и будет их обрабатывать. Имейте это в виду. Я не могу сейчас сказать точные модели коммутаторов. Мы с Накидом проверяли это и на виртуальных, и на железных коммутаторах. Мы это делали не две недели назад, а достаточно давно, когда мы обсуждали это. Так, не в этом году. И где-то мы совершенно точно видели — не на одной модели, а на нескольких — что такое может быть на некоторых платформах: на access-порту, если приходит тегированный кадр с меткой 802.1Q, он будет обрабатываться так же, как на транк-порту. Имейте в виду, эта штука такая интересная. Как происходит атака — происходит очень просто. Нужно сформировать —

атакующий, который сидит в десятом VLAN'е, либо согласует транк, либо, если ему повезло и коммутатор обрабатывает тегированные кадры, просто формирует кадр с двумя метками: с внешней меткой и с внутренней меткой. Когда первый коммутатор получает этот кадр, он смотрит, что внешняя метка у нас 10. Здесь надо было перевернуть — на картинке немножечко непонятно, но вы видите: вот это внешняя метка, это внутренняя метка, за ней идут данные. Так вот, коммутатор, получив из 10-го VLAN'а кадр, в котором стоит 10-й VLAN, он либо как транк это будет воспринимать, либо может быть согласован уже будет транк. Коммутатор посмотрит, что нужно его отправить без метки, так как у нас native VLAN 10. Всё,

что он получил из 10-го VLAN'а, он будет отправлять без метки и спокойно отправляет этот кадр другому коммутатору по транку. Вторую метку коммутатор не срезает — он не умеет сразу взять все метки 802.1Q и срезать, он работает именно с одной меткой, которую видит. Потому что после этой метки он не знает, что там дальше идёт, он не хочет разбираться, он так не работает. Он работает очень быстро на железе, и он увидел метку 802.1Q, раз — отсчитал 4 байта, всё, резанул, и дальше отправил. Всё, больше ничего. Поэтому кадр у нас благополучно поехал со второй вложенной меткой, которая у нас указывает на 20-й VLAN. И второй коммутатор, конечно же, получив кадр из транка с 20-й меткой — он же не знает, что там 10-й native, какая разница, native не native, 10 — кадр приехал с 20-й меткой, всё, надо отправить в 20-й VLAN.

Собственно, атака задокументированная. Она очень простая, но она действительно такая синтетическая, потому что надо много всего знать. Плюс атакующий что ещё должен знать — как вы думаете? Кроме VLAN'ов, он должен знать как минимум MAC-адрес в 20-м VLAN'е. Информация... Нет, L3 знать не обязательно, Андрей. На фига ему знать IP-адреса, если он просто хочет отправить Ethernet-кадр в 20-й VLAN? Адрес — зачем MAC? А как без MAC-то? Если этот коммутатор получит... Ну, либо MAC широковещательный. Ладно, в принципе можно не знать, да. Но с другой стороны, можно, да, можно не знать. В общем, вот такие синтетические довольно атаки на VLAN'ы.

Встретите ли вы их на практике или не встретите — я думаю, что не встретите. Как защититься от VLAN hopping? Рекомендации очень простые: всегда надо явно задавать тип порта — access или trunk, отключать протокол DTP, и native VLAN'ом ставить неиспользуемый и выключенный VLAN. Вот, всё, больше ничего. Native VLAN вообще не нужно использовать, это порочная практика. Если в транке между коммутаторами бегают какие-то кадры без 802.1Q-метки, значит, тут что-то пошло не так. Вообще, в нормальном мире, между двумя коммутаторами, если между ними транк... Бывает так, что между двумя коммутаторами может вся сеть быть в одном VLAN'е — там вообще транк можно не делать. Но если между двумя коммутаторами есть транк настроенный и в нём что-то там без

802.1Q-метки бегает, значит, что-то неправильно настроено. Назовём это так. Давайте дальше. Про протокол CDP буквально полслайда, буквально несколько слов. Про CDP вы прекрасно знаете, что протокол обнаружения устройств по умолчанию включён на устройстве. Он используется как средство траблшутинга, действительно он очень часто выручает, это классный протокол. Но в повседневной жизни он не нужен от слова вообще. Его можно использовать, когда, например, надо составить топологию неизвестной сети — я тоже такой фигнёй занимался, даже не так давно. Но в повседневной жизни — может быть, только для настройки телефонов. Единственное, для чего его можно и

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

Давайте повторим, что мы знаем про access-листы. Во-первых, access-листы — это инструмент классификации каких-то объектов. Он изучает эти объекты — в данном случае это будут у нас IP-адреса — и просто говорит «да» или «нет»: подпал — не подпал, permit — deny. Никаких действий сам по себе access-лист не предпринимает. Я уже говорил про то, что сам по себе access-лист — это просто кусок конфигурации, совершенно бесполезный. Это делают уже те механизмы, которые будут обращаться к access-листу, чтобы какую-то классификацию для себя уяснить. Access-лист — это просто последовательность строк, в каждой строке будет содержаться какое-то эталонное значение,

критерий сравнения и вердикт, который выносится в случае совпадения. Например, эталоном будет служить вот этот IP-адрес, потом критерий сравнения — это обратная маска, wildcard mask, и мы будем говорить, что вот этот IP-адрес, пожалуйста, сравни по вот этому образцу, и даём обратную масочку: подпал — не подпал. И вердикт: permit или deny. Permit — это «да», deny — это «нет». Надо рассматривать это именно как «да» и «нет», не «разрешить» и «запретить», а именно «да» и «нет», потому что бывает так, что к access-листу мы обращаемся, и эти permit и deny будут совершенно противоположное значение иметь. Например, route-map. Андрей правильно сказал, бывает. Да, в route-map мы пишем route-map что-то такое deny, а потом,

если access-лист сработал и там в нём оказался permit, то в результате мы что-то запрещаем какой-то адрес. Это вы все правильно помните. Сравнение выполняется построчно. Если у нас подпадение в строке не найдено, мы переходим к следующей строке. Если мы нашли какое-то совпадение, то дальше никуда не переходим, мы заканчиваем обработку этого access-листа, и следующие строки просто не смотрим. Если у нас совпадение не найдено ни в одной строке, мы всегда говорим «нет» — выносится вердикт «нет», deny. Это вы знаете. Критерии сравнения: что для IPv4 используются обратные маски. Если стоит 0, это значит,

мы этот бит должны сравнить — он должен совпадать. Если стоит единица, значит, нам всё равно — совпал, не совпал, без разницы. Если нужно проверить именно конкретный IP-адрес, то просто инвертируется маска. Так, в access-листах для IPv6 битовых масок как таковых нет, там просто сети. Дальше, про prefix-листы мы с вами здесь говорить не будем, мы всё-таки маршрутизацию изучать здесь не собираемся на этом курсе. Но prefix-листы — да, есть prefix-листы, это очень удобный инструмент, они будут использоваться в процессе маршрутизации, но здесь мы про них не разговариваем. Нам сейчас интересны только access-листы. Как работают обратные маски — все помнят? Скажите мне, нужно это сейчас всё проговаривать и повторять

или не нужно? Я просто думаю, что вы всё это помните — это же такие очень простые основы. Повторить не мешало бы. Как работают обратные маски. В обратных масках не как обычно, нет. Скажем так, маска — это просто шаблон, всего лишь навсего шаблон для сравнения. Как простая маска — в принципе это тоже просто шаблон, чтобы отделить биты сети от битов хоста. Здесь всё то же самое, только мы выясняем не где у нас биты, относящиеся к сети, а где биты, относящиеся к хосту, а просто: биты, которые нам интересны, которые должны совпасть, и

биты, на которые нам наплевать. Двоичный счёт мы не будем здесь повторять, это вы точно помните. В данном случае мы раскладываем какой-нибудь IP-адрес — здесь мы, конечно, работаем в первую очередь с IP-адресами, мы раскладываем адрес на биты, а дальше задаём какую-то маску и говорим, что, как в этом примере, первый и третий октет мы будем сравнивать — мы для этих октетов будем выставлять все нули. То есть 0 — это значит, бит должен подпадать под нашу масочку. А для другого октета мы ставим единички, например. Единичка говорит о том, что в этом бите может быть написано что угодно, и это просто — что угодно, какая разница.

Например, мы можем проверить чётность. Когда мы с вами говорим, что последний бит — задаём какой-то адрес, не важно какой, вообще адрес может быть задан любой, просто в конце будет нолик — чётный адрес — и говорим, что последний бит обязательно должен соответствовать тому, что мы задали. В изначальном адресе мы ставим нолик — значит, это будет чётно. Если мы здесь напишем в обратной маске единичку, то... То есть маска обратная 255.255.255.255, где будут все единицы, говорит о том, что этот адрес, который мы сравниваем, может быть вообще любым, каким угодно. Эта концепция освежилась в голове у вас, с обратными масками? Всё самое главное. Ничего такого сверхъестественного здесь нет, надо просто уметь

представлять адрес как битовую строку и понимать, как мы будем эти биты отбирать — говорить, какие нам нужны в работе, а какие нам не нужны в работе. Собственно, так они и будут работать. Как записываются: произвольная маска записывается — в эталон, здесь имеется в виду адрес, с которым мы будем сравнивать, записываем сначала эталон, потом маску. Маска — все нули — это значит, адрес должен полностью совпасть. Можно ещё записать host. Маска, где все единички — 255.255.255.255 — говорит, что адрес может быть любой, мы вообще ни один бит не сравниваем, нам всё равно. И можно записать как any. Это мы тоже с вами проговорили. Какие у нас есть типы access-листов, мы тоже помним. Есть стандартные access-листы,

где будет только IP-адрес отправителя фигурировать. Либо расширенные access-листы — весь заголовок IP вложить, то есть мы можем в расширенных access-листах сравнивать и IP-адреса, и протокол, и номера портов. По способу именования они бывают нумерованные и именованные. Нумерованные access-листы: первая сотня — 1–99, и потом 1300 до 2000. Именованные — вторая сотня, и 2000–2699. Нужно ли использовать нумерованные листы или именованные листы — я вам однозначно не скажу. Я скажу, что я нумерованные листы не использую вообще никогда и нигде, просто чтобы не запутаться в конфигурации, если у вас есть какая-то сложная конфигурация. где у вас 100 access-листов, не нужно делать нумерованные access-листы, вообще не нужно. Я понимаю, что это экономит место и

время, чтобы набить не имя access-листа длинное, а просто поставить цифру, там 120, но взглянув через год на эту конфигурацию, придётся ещё разбираться дополнительно. Я пишу всегда access-листы названием большими буквами в конфигурации, чтобы было понятно, что это access-лист. Считаю, это моя нормальная практика. Так, как записываются access-листы. Здесь у нас записываются стандартные нумерованные access-листы. Что из этого интересного можно сказать. Маску можно не писать, когда у нас точное совпадение, точное подпадение под access-лист. Как в первой строчке — можно помнить, что если 10.0.0.1 мы записали, wildcard-маска не обязательна, адрес должен весь совпасть.

Поменять порядок строк, удалить строку в таких access-листах, в нумерованных стандартных, нельзя. Нужно просто полностью удалять access-лист и набивать его заново. На самом деле это не так эффективно, не так удобно, поэтому хотя можно, но лучше это не делать. В расширенном access-листе мы должны будем писать — здесь будет слово host. 0.0.0.0 просто так не сработает уже, чтобы опускать. Я думаю, что с этим вы точно все знакомы. По поводу дополнительных ограничений — дополнительное ограничение имеется в виду номера портов. Если нужно

номера портов — когда мы говорим про протокол TCP или UDP, здесь можно сказать ещё дополнительные ограничения: имеется в виду либо 80-й порт, либо больше 80-го порта, либо не равен 80-му порту. Именованные access-листы намного приятнее для восприятия, с ними проще работать. Надо не забывать говорить, что это стандартный access-лист либо расширенный access-лист. Записываются они в своём контексте: мы сначала сказали создать access-лист стандартный такой-то, потом пошли писать. Можно начинать с номера строки, если нужно как-то его изменить. Можно зайти сначала — прошу прощения, не тот инструмент — если просто изменить, можно зайти

в контекст access-листа и где-то в серединке добавить с номером строки какую-то нужную строку. Редактировать их просто и приятно. Просмотр имеющихся access-листов — show ip access-list. На самом деле в современных IOS access-листы все именованы, если так разобраться. Если посмотреть — в том смысле, что они будут использовать номера, но с ними можно также, как с именованными, работать. Можно сказать ip access-list standard 91 и потом его редактировать точно так же, как именованные. Просто в классическом Cisco обычно говорилось, что нумерованные access-листы — с ними ничего нельзя делать, но в современных IOS точно так же можно их редактировать. Так что имейте в виду. По поводу — как удалить

нумерованный, удалить именованный access-лист, удалить строку в именованном, добавить строку с нужным номером — можно просто посмотреть access-листы, посмотреть номера строк и потом редактировать их, говорить: не нужна нам десятая строка, и добавить, например, 11-ю строку вот такую-то в access-лист. Это не так сложно. Иногда бывает нужно перенумеровать access-лист. Зачем это бывает — бывает так, что вы создаёте access-лист, там всё нумеруется, как в языке программирования BASIC: 10, 20, 30, 40, 50 и так далее. Бывает так, что вы редактируете access-лист, потом задумали в какое-то место добавить ещё 10 строк, и там добавляете 11, 12, 13, 14, 15 и так далее до 19, и вам уже некуда вставить, потому что вы не можете добавить строку номер один с половиной. Тогда можно взять и перенумеровать — есть команда resequence, которая вам

access-лист заново перенумерует. Строки останутся в том же порядке, она просто сделает опять 10, 20, 30, 40 и так далее — просто перенумерует строки. Можно указать параметры: сказать access-list 3 resequence и сказать начинать с номера 10 с шагом 20, и у вас тогда будут 10, 30, 50 — вот такая нумерация. Так что Роман, никто не отменяет того, что с access-листами нужно работать очень внимательно. По номеру строки можно не удалять. Бывает, когда путаешься, что не в том access-листе. Бывают разные ситуации, конечно, иногда последствия могут быть катастрофическими. По поводу IPv6 — в принципе в IPv6 у нас всё будет

похожим образом, за исключением того, что обратных масок нет. Вы понимаете, писать обратную маску 64 бита — это не очень радостно. Используется просто указание сети — /128. Я уже заговариваюсь, почему сказал 64, не знаю. Ладно, надо помнить, что в отличие от обычных IPv4 access-листов, в которых только одно последнее правило implicit deny, в access-листе IPv6 там три правила: последнее — deny IPv6, deny, плюс ещё правила, разрешающие neighbor discovery — neighbor solicitation. Это надо помнить. Плюс ARP и вообще лучше не запрещать, потому что neighbor discovery механизм просто перестанет работать. Имейте это в виду, это надо тоже держать в голове всё время.

Дальше. Теперь мы подходим к тому, что на CCNA вам не рассказывали и что в нашем контексте, в контексте безопасности канального уровня, нужно знать. Сейчас мы говорим про multilayer switch, и нужно сказать, что там есть несколько access-листов. Кроме обычных IP access-листов, которые мы можем повесить в принципе только на SVI, есть ещё некоторые виды access-листов. Давайте разбираться. Здесь нарисована такая схема. Multilayer switch в таком полупрозрачном виде представлен, чтобы мы понимали, что же происходит внутри свича. Когда у нас пакет приходит на интерфейс коммутатора — я сейчас говорю про multilayer switch — когда мы перекладываем из одного VLAN в другой, делаем простейшую маршрутизацию между сетями,

то этот пакет будет у нас продвигаться через несколько access-листов. Внутри у нас существует как бы виртуальный маршрутизатор. Эта концепция вам должна быть знакома — с виртуальными интерфейсами, между которыми и будет перекладываться пакет, чтобы попасть в другой VLAN. И вот почти на каждом из этих уровней можно делать определённую фильтрацию. Давайте сначала про виртуальные интерфейсы. Про SVI, который у нас называется VLAN номер такой-то — на них мы можем, так же как на обычный интерфейс роутера, вешать совершенно привычные нам access-листы, которые будут проверять IP-пакеты. Это же L3-интерфейс, это нормальный роутерный интерфейс. Как на входе в SVI, так и на выходе из SVI можно применить нормальный access-лист. Дальше, на входном интерфейсе —

на физическом интерфейсе коммутатора, прямо на L2, тоже можно повесить access-лист. Он будет называться port access-list. Сейчас — сейчас я договорю. Port access-list его можно повесить всегда на входном интерфейсе, на L2. Port access-list нельзя повесить на выходном интерфейсе — он будет работать только в одну сторону. И плюс ещё замечательные access-листы — это VACL, так называемый VLAN access-list. VLAN access-list применяется не на каком-то порту, здесь концепция не интерфейсов, а вообще для всего трафика, который будет бегать в определённом VLAN. У вас, например, есть 10 портов, которые в одном VLAN, и чтобы не вешать access-листы на каждый порт

на L2 — зачем так заморачиваться — можно просто на весь VLAN навесить access-лист, и весь трафик, который будет ходить в этом VLAN, независимо от направления, с какого порта на какой порт — совершенно неважно — весь трафик будет фильтроваться, будет обрабатываться access-листом. Штука невероятно удобная. Так, значит, на выходе из VLAN B — Андрей, ещё раз сформулируй вопрос. В смысле, что значит «на выходе из VLAN B»? У нас два VLAN на коммутаторе — VLAN A и VLAN B, у нас осуществляется маршрутизация. Как такой виртуальный маршрутизатор — вот эти SVI. Смотрите ещё раз — вот эти виртуальные интерфейсы, между которыми у нас будет маршрутизация таким образом осуществляться. На него можно повесить

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

маршрутизатор. Если просто представить себе такую физическую схему, самую элементарную, когда сначала приходит из одного VLAN, маршрутизатор берёт и перекладывает это в другой свой интерфейс и отправляет в другой VLAN, то есть в другой коммутатор — всё это же происходит внутри одного коммутатора. То, что здесь нарисовано, внутри одного коммутатора так и будет осуществляться — вот такая маршрутизация. Это так и работает, просто эти интерфейсы у виртуального роутера тоже виртуальные. Любой кадр, который будет адресован в другой VLAN — пакет — он будет проходить через вот эти самые интерфейсы и потом отправляться из этого интерфейса. Для использования VACL — конечно, можно, сейчас мы дальше про них будем говорить. Я расскажу теперь поподробнее про каждый тип access-листов. С обычными IP access-листами вы знакомы, мы сейчас их быстренько пробежались, повторили. Port access-list —

это списки доступа, которые применяются именно на физических интерфейсах коммутаторов. Прямо на L2-порт можно повесить access-лист. Можно их повесить только в направлении inbound — только входящий трафик в этот порт каким-то образом контролировать. Могут отбирать трафик как на основании IP-заголовка, как обычный access-лист, так и по MAC-адресам. Бывают ещё access-листы, которые MAC-адреса контролируют — это же L2, коммутация, поэтому мы можем создать access-лист, прямо такой, он называется MAC access-list. И сказать, что только с такого MAC-адреса — он extended — мы можем вообще круто написать: только с такого MAC-адреса на такой MAC-адрес можно отправлять кадры. И потом повесить этот MAC access-лист на интерфейс, осуществлять коммутацию на уровне

MAC, на канальном уровне. Порт с улицы можно заменить до port security, в принципе можно и таким образом осуществить, почему нет — ограничить нужные MAC на порту не с помощью механизма port security, а с помощью такого access-листа. С другой стороны, port security всё-таки более гибкая система, с ней удобнее работать. И строк в конфигурации больше, Андрей правильно говорит. Просто не очень удобно это — придётся на каждом порту вешать такие access-листы. В принципе да. Как забанить MAC — что такое забанить MAC на коммутаторе? Вот таким способом можно запретить: сказать deny такой-то host MAC-адрес, или на каждом порту для всех портов повесить этот MAC access-лист. Просто на интерфейс, на диапазон портов. А вот

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

уже сказал, применяется ко всему трафику, который проходит через этот VLAN в рамках коммутатора. Явного направления здесь нет, его нельзя сказать — входящий трафик в этот VLAN или трафик, который исходит из этого VLAN. Нет, здесь так нельзя указать — просто весь трафик, который бегает в этом VLAN, он будет подпадать под этот access-лист. Направление можно обозначить в качестве адресов источника и получателя, сказать: с адреса такого-то на адрес такой-то передавать трафик нельзя. И всё будет понятно — все пакеты, которые будут бегать в этом VLAN, будут фильтроваться этим access-листом. Конфигурируется немножечко поинтереснее. Будет такой VLAN access-map — такая структура, очень похожая на route-map, если кто-то знает. Работает похожим образом: точно так же мы

сначала ищем совпадение с помощью access-листа, а потом для этого совпадения будем какое-то действие применять. Записи — они работают похоже, эти VLAN access-map и route-map похоже будут работать. Там есть три действия: forward, drop и redirect. Forward — это разрешить пакет, отправить его куда он шёл по своему пути. Drop — понятно, дропнуть. И redirect — это только на Nexus работает, это перенаправить пакет. Здесь мы не будем рассматривать. Значит, порядок поиска совпадений также, как в route-map, важен. Кто не знает route-map — поднимите руку, пожалуйста. Также, как в route-map, он будет отбрасывать все пакеты, которые ни под одно вхождение не подпали — он их бросит. Если не знаете route-map — сейчас увидите всё, как это настраивать. Смотрите, как это всё настраивается. Здесь тоже никакой

магии нет. Для начала — три действия, которые нужно сделать, чтобы настроить VLAN access-list. Во-первых, это определить access-лист — просто access-лист. Можно использовать MAC access-list, и по MAC-адресам тоже никто не запрещает. Просто в этом примере — IP access-лист. Мы определили два access-листа сразу: два — разрешить веб-трафик, там permit TCP any eq 80, 443. И второй access-лист мы написали, что Telnet-трафик — deny, зарубать. Дальше мы с вами будем именно этот access-map создавать. Мы говорим: match IP address permit-http — подпадает то, что подпадает под access-лист permit-http, мы будем применять к нему действие forward. Что подпадает под —

прошу прощения — дальше мы создаём вторую строчку VLAN access-map. То, что подпадает под access-лист drop-telnet, мы будем всё это дропить. Получается вот такая структура. Сейчас надо чёрточку нарисовать — вот так я нарисую чёрточку. Первое условие, а за ним идёт второе условие. Мы определили условия и определили, что собственно делать с этим. Так, секундочку. На CCNP Security на это хорошая лаба. Так, почему Telnet дропнулся бы — у нас здесь ошибка на слайде. Также, как в route-map — здесь смотрите, кстати, в принципе он и так бы дропнулся,

явного permit у нас здесь нет, в конце будет всё равно drop. И здесь у нас — секундочку, и на CCIE тоже лаба. Ладно, тема на самом деле не такая сложная — это работа подобно route-map, здесь ничего сложного нет. И последнее действие, которое нужно сделать — это привязать созданный нами этот access-map к какому-то VLAN либо к пачке VLAN. Мы просто говорим: VLAN filter, наша map к такому-то VLAN. Всё, после этого весь трафик, проходящий через, вообще бегающий в этом VLAN, будет с помощью этой конструкции фильтроваться. Так, почему —

да, он дропнется здесь, просто не дописано. У нас получается access-лист, в котором разрешён только веб. Но я могу сказать, где применяются такие access-листы и где я, например, их применяю в реальной жизни. Когда вы создаёте какой-то VLAN служебный для совершенно конкретного типа трафика — например, у вас в отдельном VLAN бегает трафик iSCSI или в отдельном VLAN у вас только syslog- трафик бегает — вот в таком случае, это уже такая дополнительная перестраховка. Нужно ли это делать, не

нужно — но как дополнительное средство безопасности это сделать можно. Если у вас есть серверная ферма, отдельный выделенный VLAN для конкретного трафика — например, трафик хранилища, iSCSI передаёт, или NFS, или что-то такое — мы точно знаем, какой трафик там должен быть, другого там быть не должно. Можно в этом VLAN в принципе запретить всё, кроме этого трафика, и вы будете спать спокойно, будете уверены, что никто там не будет ломиться в этот секретный VLAN. Вот как одно из применений. В принципе, другого применения-то и нет. Проверка VACL — она тоже несложная. У нас есть две команды: посмотреть содержимое VLAN access-map и посмотреть

привязку этого самого access-map к VLAN или к группе VLAN. Вот это что касается access-листов. Инструмент прикольный, инструмент несложный. Запутаться в нём тоже не так сложно. Кто писал route-map — знает, что там тоже запутаться, конечно, можно во всём, даже в access- листе из трёх строчек, и даже если ты работаешь программистом в компании Cisco, как мы убедились вчера. Но я не думаю, что вы в этом запутаетесь. Теперь немножко поговорим про атаки на коммутацию. Защитных механизмов на коммутационном уровне у нас не так много будет, но они есть, и ими пренебрегать не стоит. Сначала про атаки. Мы с вами говорили про разные типы спуфинга, помните, все эти

reflection, amplification. Мы рассматривали, когда один единственный пакет ping посылают, а в ответ на жертву приходит лавина ответов. Про directed broadcast было — для кого-то новая тема. То же самое — спуфинг, подмена — можно делать и на канальном уровне. Это тоже бывает, это в жизни встречается, и кстати, встречается, наверное, даже часто. MAC-спуфинг — это подмена MAC-адреса с целью получения чужих кадров. Я уже говорил, что все атаки на канальном уровне, все, которые мы здесь разбираем, точно будут иметь своей целью организовать man-in-the-middle, завернуть на себя весь трафик. Злоумышленник будет именно к этому стремиться — получить чужие кадры. Самое простое, что можно сделать — это MAC-спуфинг. Когда

у нас — давайте на картинке смотреть — у коммутатора есть три порта: 1, 2, 3. Злоумышленник у нас имеет за вторым портом MAC-адрес B. Всё хорошо, будет ходить между компьютером и сервером, у которых A и C MAC-адреса, до тех пор, пока злоумышленник просто не отправит какой-то кадр поддельный, с чужим source MAC-адресом жертвы. Он скажет: «Hello, вот тебе кадр, у меня MAC-адрес источника A». После этого коммутатор перезапишет просто свою таблицу и будет думать, что MAC-адрес A у него за вторым портом. Соответственно, весь трафик, адресованный серверу, этот нехороший человек будет забирать на себя. Это самый простейший спуфинг, самый элементарный. Дело в том, что до тех пор, пока сервер снова не отправит

кадр со своим настоящим MAC, до этих пор коммутатор не перезапишет свою таблицу коммутации и так и будет отправлять все кадры, адресованные серверу, нехорошему человеку. С другой стороны, этот нехороший человек может тысячу раз в секунду отправлять кадры с чужим MAC, и коммутатор просто не будет успевать переписывать свою таблицу, и никакие нужные кадры до сервера просто не дойдут. Вот такая штука. Как предотвращать такие атаки? 802.1X — прекрасный механизм, который занимается аутентификацией на портах коммутатора, или port security. Про port security мы тоже поговорим немного, и про 802.1X у нас тоже будет пару слов. 802.1X в нашем курсе не рассматривается, мы совершенно поверхностно просто скажем, что это такое. Лабу на 802.1X мы точно не будем делать.

Нет. 802.1X рассматривается в старшем курсе — CCNP Security. Там по нему, я не помню, все SAS — по моему, огромная такая тема. Там это сложный протокол, и его разбирать очень долго. В рамках CCNA Security мы можем с ним только познакомиться, сказать, что он есть. Андрей, это то же самое: понимаете, тоже там было BGP в новом CCNA включили же BGP. Вы же понимаете, что BGP — протокол, по которому целый курс раньше был у провайдера, и он и сейчас есть, просто переименован. Там огромный пласт знаний. В подготовке к CCIE он занимает там полкнижки такой толстенной. Нельзя же обижаться, что на CCNA вам не рассказывают про весь BGP. То же самое — на CCNA Security мы не можем

про каждую тему говорить подробно, нормально. Поэтому 802.1X справедливо отложен на уровень CCNP Security. Он не простой, там очень много всего прикольного и очень много того, что с ним связано для дальнейшей обработки трафика. В общем, я вас разочаровал, может быть кого-то, может быть кого-то обрадовал, что мы не будем, мы не сломаем себе мозг окончательно. Почему не надо говорить «прикольного»? Так, переполнение CAM-таблицы. Здесь тоже — цель такая же, я уже не буду повторяться, цель везде — получение чужих кадров. Как можно сделать это следующим способом. Мы знаем, что у коммутаторов таблица MAC-адресов не резиновая, не бесконечная, что рано или поздно она заканчивается, когда у нас

слишком много адресов в таблице. На это есть атака. Что делает коммутатор — любой нормальный коммутатор, когда у него будет переполнена CAM-таблица? Нормальные коммутаторы при переполнении CAM-таблицы — понятно, что они будут ругаться, сыпать ошибками в syslog, — но чтобы сохранить свою работоспособность, обычно коммутатор продолжает передавать кадры. Но так как таблица его переполнена и он не знает, в какой порт отправить кадр, он будет делать unknown unicast flooding — он будет просто рассылать это во все порты. Этим можно воспользоваться с точки зрения злоумышленника. Атакующий будет просто переполнять CAM-таблицу. А как её переполнить — надо отправить очень-очень много кадров с поддельными MAC-адресами, вообще с произвольными, неважно с какими — просто чтобы

коммутатор запомнил, что на этом порту у него там 50 тысяч MAC-адресов. После этого коммутатор скажет: «Всё, я понял, больше не могу» — и начнёт делать unknown unicast flooding. После этого атакующий будет получать все кадры, вообще все кадры от этого коммутатора, в том числе и интересный ему трафик, чего он и добивался. Здесь именно он не заворачивает, не пропускает через себя трафик — не классический такой man-in-the-middle, это будет именно получение копии всего трафика. Но это очень хорошая цель, к которой стремится злоумышленник — получить весь трафик конкретного коммутатора на себя. Так что переполнение CAM-таблицы — как предотвратить? Тот же самый механизм port security,

который будет ограничивать количество MAC-адресов за данным портом. Механизм очень действенный, и он работает, он правда работает. Так, у Романа вопрос — или давайте дальше. Ограничить количество пакетов с порта — я подозреваю, что это можно сделать, но нет, нельзя ограничить. Нет, storm control не подойдёт, Андрей. Он — unknown unicast flooding. Так, про storm control можно подумать, но дело в том, что если он переполнит — нет, это будет, всё зависит уже от конкретного сценария, потому что нет, это не то. Storm control — что он делает? Он будет резать... хотя нет, не будет. Port security и выключить неиспользуемые

порты — да. В общем, просто проще всего port security. Со storm control надо подумать, потому что здесь он не будет выглядеть как unknown unicast. Почему? Злоумышленник будет отправлять кадры — нет, почему? Он может отправлять кадры на легитимного получателя, он будет подделывать source MAC-адрес, чтобы коммутатор запомнил. Цель-то — чтобы коммутатор запоминал эти MAC-адреса за этим портом. Так что storm control тут особо не поможет ничем — он режет unknown unicast, но это не unknown unicast. Он может поставить в качестве получателя нормальный легитимный адрес. Так что здесь port security. На самом деле port security — простая вещь, мы сейчас будем рассматривать: ограничить количество MAC-адресов за

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

почему этот слайд оказался здесь? Он будет дальше. Давайте его пропустим. У нас ещё будет про ARP spoofing, мы ещё вернёмся, я обещаю, и про отравление кэша ARP поговорим. Там тоже не сложно, в принципе. По поводу port security — давайте выясним, вспомним, если знаем, или узнаем, если никогда про это не слышали. Что такое port security? На каждом порту мы можем ввести белый список MAC-адресов источника. Количество записей в этом белом списке задаётся администратором. Вот мы сейчас говорили про переполнение — мы можем бороться с этим, просто задать количество записей. Адреса в список можно заносить либо вручную из конфигурации — startup-конфига, при загрузке будут браться адреса, либо вручную набивать, либо автоматически — port security может формировать этот белый список автоматом — sticky,

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

хранится этот белый список — он хранится в отдельной памяти, не в running-config. Вы его в running-config не увидите, он будет виден в running-config, но хранится не там — это совсем отдельный тип памяти. Значит, в этом списке, мы уже говорили, могут быть статические или sticky-адреса. Sticky- адрес — это тот адрес, который будет сохраняться в конфигурацию. Здесь надо не путать: есть динамические адреса, есть sticky-адреса. Сейчас мы про это поговорим. Sticky — это те адреса, которые будут копироваться в running-config, и потом, когда вы делаете сохранение конфигурации, они запишутся навсегда в конфиг, как статические, как будто вы их руками записали. Вот это sticky-адрес. Динамический адрес — это когда мы получили кадр, записали в наш белый список, и потом он через какое-то время либо оттуда удалился сам, либо

после перезагрузки в этом списке ничего нет. Как настраивается эта штука — на CCNA было. Настройка — мы сейчас просто поговорим ещё раз, вспомним какие-то, может быть, забытые вещи и двинем дальше. Работает это всё только на портах, которые настроены жёстко — либо access, либо trunk. В динамическом режиме это на портах работать не будет, там, где DTP у нас занимается настройкой порта — там port security не работает. Запоминайте такую штуку. Это, кстати, бывает — иногда бывает такое, когда настраивают порт, потом на него вешают port security и удивляются, почему же он не работает — потому что он у нас в динамическом режиме. Дальше, немножечко хотелось бы заострить про violation — какие у нас бывают. Посмотрите, мы можем

настроить поведение в случае нарушения. В случае нарушения у нас может быть несколько действий. По умолчанию действие shutdown применяется — просто положить порт. Он даже не в shutdown, а в состояние err-disabled переходит. Если говорить про состояние err-disabled — на CCNA, по-моему, это не разбирается, но на CCNP точно разбирается. Такое состояние порта, из которого в принципе может он выйти сам. Чем он отличается от shutdown? Если сделать shutdown, то надо руками обязательно его включать. А err-disabled — у него есть recovery. Но понятно, что по умолчанию recovery отключено для err-disabled. Да, всё правильно. Но просто придумано такое состояние, из которого порт может сам по истечении времени выйти — есть восстановление. Поэтому все механизмы кладут порт в err-disabled — не только port

security, этих механизмов на самом деле много. Значит, какие могут быть действия у port security? Действия могут быть либо shutdown, как я сказал, либо есть ещё действие protect и restrict. Вот, кстати, это может быть вопрос, который встретится на экзамене и который может быть кто-то не знает. Знаете все это про restrict и про protect? Restrict — состояние protect: просто фрейм будет убиваться, просто drop, ничего не будет происходить. Restrict — будет точно так же фрейм отбрасываться, но ещё будет SNMP trap, syslog-сообщение, и счётчик увеличится. Так что вот есть три таких действия при нарушении port security. Дальше, по поводу sticky-

адресов. Я сказал: в этом примере у нас мы говорим mac-address sticky, мы говорим, что если у нас приходит какой-то кадр с новым MAC-адресом, мы этот MAC-адрес добавляем в белый список и потом записываем в конфигурацию. Если не говорить mac-address sticky, либо не задавать вручную MAC-адреса, то будет просто динамическое добавление. Мы сказали: максимум два адреса — значит, два адреса будут в белом списке храниться и потом оттуда будут удаляться. Как будут удаляться — мы можем задать aging time. Aging time — это время, после которого мы удалим MAC-адрес из этого белого списка. Aging time можно задать либо inactivity — это если мы не получали кадры с этим MAC-адресом, то

по истечении 180 секунд мы его удаляем списка либо абсолют абсолют это значит мы по-любому удалим этот мак адрес из белого списка через 180 секунд из конфига не будет удаляться только именно из белого списка так чтобы порт security работал надо отключить дтп но у них решишь на самом деле но у них решишь но не решишь хороших конечно вообще надо всегда но по моему достаточно сказать свитч порт мод акцесс или свитч порт мод трак он заработает а вот но не решишь на дополнительная команда чтобы вообще отключить согласование в старых системах не было вообще же но не пишешь на команды еще там несколько лет назад

такой команда не было то есть это дополнительно отключает просто передачу сообщений дтп эта команда так как посмотреть это шоу порт security для такого интерфейса где у нас и порт статус будет и в общем вся информация и что дело в случае нарушений то что все что мы настроили все настройки здесь будут здесь будет будут счетчики мак адресов сконфигурированных массам мак адресов то есть информации там достаточно для того чтобы понимать работает эта штука или не работает надо не забыть после всех этих настроек обязательно сказать просто switch порт порт security эта штука такая про которую иногда забывают то есть сначала все все все настроили и потом еще сказать switch порт порт security вот только тогда это штуковина

заработает иногда можно забыть еще несколько команд которые нужны для проверки просто show порт security у нас покажет такую сводную табличку по интерфейсом где это технология у нас будет работать и счетчики покажут и есть show порт security адрес который покажет там все адреса системе обратите внимание стики адрес у него и джек тайм будет не будет счетчик тикать потому что он не удаляется он стики дальше я наверное даже соглашусь что здесь настройка с и джек тайм это просто в качестве примера но в данном случае она не очень интересно потому что здесь адреса стики но смысл нет настраивать можно это просто как пример

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

этими коммутаторами портами либо за этими портами находится еще какие-то отдельные сети в случае там провайдера вот их неплохо бы изолировать друг от друга как можно выкрутиться ну выкрутиться можно разными способами например нарезать каждому отдельный вилан ну почему бы нет было бы здорово отдельно отдельный вилан предполагает отдельную подсеть хорошо если 20-30 у нас абонентов можно нарезать отдельные подсети но когда в провайдер ских решениях счет этих абонентов идет на тысячи и десятки тысяч то там просто не хватит парт номеров виланов поэтому нарезать каждому отдельный вилан и отдельную под сеть это довольно сложно и будет распухать таблицы маршрутизации на устройствах потому что будут несколько тысяч под сетей просто так созданы в результате можно поступить по-другому

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

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

ну достаточно гибкую очень схему взаимодействий именно на уровне интерфейсов не раздавая вилана можем создать например там сейчас у нас к например какой-то группы портов и объединить их в так называемый комьюнити вилан они смогут общаться только друг с другом вот между этими комьюнити виланами никакой трафик не разрешен как тут все наглядно либо могут быть какие-то совершенно изолированной виланы вот они у нас такого красивого сиреневого цвета это те интерфейс которые принадлежат к этим вилана могут общаться друг с другом не могут общаться вообще ни с кем не могут общаться единственные с кем они могут общаться это с теми портами так называемый промишес порт и до общие вот эти порты которые входят в их родительский вилан не знаю насколько понятно вам сейчас вот эта идея дело в том что вообще правят виланы

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

он в принципе неплох он удобен если у нас большое поле коммутации вот именно или два какая-то большая инфраструктура то там витепи оправдан и удобен по поводу нужно ли растаскивать вот эту информацию о приватных виланах на другие коммутаторы однозначно ответить нельзя наверное кому-то это нужно и где-то это используется я этого никогда в жизни не видел я видел приватные виланы они работают это нормальная практика их использовать но так чтобы намного коммутатор врата растаскивать мне кажется с точки зрения дизайна мне так просто мое личное мнение что мне не нравится есть еще один способ ограничить взаимодействие между портами он более простой чем вот эта концепция приват виланов так называемые пивилан

это что с приват вилан edge это механизм который похож на приват вилан но там нет комьюнити портов то есть у нас есть промежу спорт и в которые можно которые могут общаться со всеми остальными и все остальные могут передавать трафик в их направлении но вот именно комьюнити виланов нет то есть нельзя создавать еще такие маленькие вилан чеки по два по три интерфейса в рамках одного большого вилана то есть пивилан edge наверное даже чаще используется он называется по-разному он есть у многих вендоров называется там название много всяких то есть не только в циске эта штука есть так называемый протектот порты их еще называют то есть и вот изолированные порты там называются протектот коммутатор между этими протектот портами никакой трафик не передает между обычными портами и вот этими

защищенными портами весь трафик передается то есть если упростить вот эту схему которая была у нас на рисуночке да то вот между обычным портом и протект от портами весь трафик ходит без ограничений между ними точно также никакого трафика не ходит это более простая схема и там не фигурирует никакие номера виланов нет никакой привязки родительских виланов дочерних виланов то есть с которыми на курсе свеч люди запутываются очень быстро и потом приходится тратить много усилий и времени чтобы все еще разобраться с этим вот эта система она много более простая то есть пивилан edge можно использовать очень очень несложно настраивается намного проще работает в пределах одного коммутатора витя здесь не будет растаскивать никакой информации на какая информация как зачем

другому коммутатору знать какие есть протектов порты на соседнем коммутаторе никакого смысла нет передавать эту информацию и растаскивать по всей сети поэтому здесь это все в рамках одного коммутатора она служит в первую очередь для предотвращения атак между соседними хостами то есть арп поезонинг про который будет разговор у нас и всякие вот этого на края петит то есть то что работает в рамках одной канальной среды это все эти все вещи они тоже с помощью этого мы можем как-то придавить придушить по поводу конфигов на nexus ах почему нет я не работаю просто с нексусами каждый день и на никогда на них протектов порты не станет настраивал но я думаю что конечно есть эта

технология достаточно простая как все это дело конфигурируется конфигурируется это одной единственной командой вот специально для андрея который жаждал конфигов как вот он собственный конфиг который будет заключаться в том что необходимо на интерфейсе сказать switchport protected после этого этот интерфейс не сможет никаким образом то есть общаться но в кавычках общаться с такими же другими протектов портами с обычными портами где нет этой настройки как бы общаться мы можем передачи трафика между ними будет вот специально специально кстати не нужно указывать вот на портах что это там про меньше спорт все просто switchport protected на том порту который мы хотим ограничить общение с соседями и проверка

если посмотреть шоу интерфейс switchport то в куче куче сведений про канально уровне этого порта я думаю что сессийные помните административ мод оперейшнам мод то будет написано что он протектов так что вот эту технологию вы можете использовать она эффективно и достаточно и в современной сети даже не обязательно в провайдерская просто в сети предприятия она оправдана потому что в сети современного предприятия вот если построена работа в инфраструктуре правильно то хосты друг с другом общаться ты не должны я не знаю вот давно уже не видели да это стоп сто лет назад было когда там передавались какие-то файлы

между компьютерами да там шарили сетевые папки сейчас как правило модель построена сетевое взаимодействие по-другому есть клиент есть сервер и все клиенты между собой общаться не должны принтер сетевой это концепция сервера сетевой принтер можно поставить за обычным портом не протектов и к нему смогут все обращаться вот так что это нормально а вот просто на обычных пользовательских портах лучше конечно это все зарубить вы отсечете сразу целый класс атак те же самые вирусы которые будут вот как последний нужно шумевшие все эти вона края петь они же они работают там по smb1 скажем раньше от когда помеха механизм этот назывался сетевое окружение да когда вы заходите у вас там весь ваш брат каст домен все было видно все компьютеры в сети с протекта портами это работать не будет это очень удобно прокси атака

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

с адреса 10123 нужно передать какие-то пакеты на адрес 10122 напрямую мы знаем про так тот порт и это ничего работать не будет даже если он будет знать о мак-адрес коммутатор не передаст из этого порта в этот порт никакой кадр не нужно никаких и 7 передиректоров не нужно ничего вообще нужно просто сформировать пакет в котором айпи адрес будет жертвы а мак-адрес назначение будет адрес маршрутизатора что сделать маршрутизатор ну собственно как это работать будет маршрутизатор примет этот пакет посмотрит да это пришло на мой адрес на мой мак-адрес отлично значит я буду обрабатывать этот пакет он посмотрит destination айпи айпи увидит что айпи адрес не его но он знает этот айпи адрес он не в connected сети есть и тупо возьмет и отправит пакетов по адресу назначения

со своим исходным мак-адресом и смак адресом правильным мак-адресом назначений вот и все в этом атака атака примитивная простая ну понятно что ее нужно специально готовить ответ атакующему не придет скорее всего потому что ну если будет ответный пакет то здесь жертва наш не умеет формировать такие кривые кадры она возьмет запакует со своим мак-адресом источника и мак-адрес назначения она будет выяснять по айрп вот и она просто его не выяснит вот и все потому что айрп здесь тоже не будет работать если я все правильно помню ну не должно сейчас накиньте поправить меня вот реализации именно ты правоответный пакет а в принципе но

это все будет зависеть от реализации если закэширует сама к адрес ну да в принципе на тот же мак он и отправит тогда да тогда и ответный придет я не подумал об этом в общем вот обойти пивилан обойти протектов порты на самом деле можно просто обычный закэшируется на компьютере жертвы он же получит получит кадр в котором будет и мак и айпи он может его закэширует но это от реализации зависит это уже будет зависеть от операционной системы этого компьютера то есть он от него получил кадр за чею все и занес кэш айрп а дальше уже ну кто знает тут уже будет все от этого компьютера зависит а чё свечу

обновлять таблицу то он же от роутера получил все мак адреса легитимные здесь пуфинга спуфинга нет понимаете с чего я начал это абсолютно легитимное поведение стандартная здесь нет никакого спуфинг это подделка адреса отправителя когда атакующий выдает себя за другого за другую систему а здесь пуфинга нет здесь все нормально что тут обновлять он взял совершенно легитимно отправил это к роутеру роутер точно также посмотрел все передал в свою connected сеть другую почему он должен сказать что роман так что мак адрес со стороны роутера они атакующего нет а роутер отправит же такую атакующую вообще смотрите атакующий ничего не подменяет он со своим мак адресом и отправил

вот source мак адрес то есть ой прошу прощения нет миш здесь имеется ввиду и на кенте правильно сказал что жертва отправит на роутер ответный пакет с маком роутера на фига им точно также жертва отправит на мак роутера ответ сама того не подозревая и все роутер честно перешлет обратно на атакующего то есть если жертва не будет а rp запускать если это у нее есть вот а закеширует там на какое-то время и не нужно будет запускать а rp то все обратно тоже пойдет то есть все до всех это дошло как это работает

это обычная атака единственное что требуется это чтобы атакующий формировал формировал кадры с мак адресом назначения не жертвы а на роутер ну например дефолт гейтвы и свой и все так что если же ну если брать сеть l3 то но тогда ну а как я если они будут разных иван в тагане сработать естественно потому что порты протектов но здесь говорится что они в одном вилане протектов порты они в одной подсети так что штука удобная арп прокси здесь вообще ни при чем миш здесь нет никакого арп прокси еще раз здесь

не запрашиваются никакие чужие адреса ничего арп прокси просто отдает ответы на любой арп запрос он будет говорить что это мой адрес это мой адрес держи тебе мак адрес вот этого и пишника все будет собой представляться отключение арп прокси тоже не поможет атакующий же не запрашивает у него адрес атакующий уже ну всего лишь просто отправлять на другой мак это нормальная работа протоколов вот такая интересная вещь как совершенно никак не бороться а как вы с этим поборетесь бороться можно только фильтрации айпи фильтрации и все у меня здесь не написано кстати как бороться с помощью акцесс листов а вот написано же единственное что можно сделать это только акцесс листы писать

вот и все то есть сказать что с этого адреса на этот адрес ничего передавать нельзя и повесить акцесс лист куда-то здесь на роутере ну или то есть не обязательно акцесс лист просто фильтрация фильтрация сделать фильтрацию на роутере сказать ему дорогой роутер не нужно передавать вот от этого компьютера этому компьютеру никакие пакеты и ну вот единственный вариант как уберечься вот такие пироги поехали дальше или еще у вас вопросы если компов сети много то практически ну как писать большие правила фильтрации только так потому что здесь никакого криминала то нет и ну либо да от каждого на каждого только вот только таким образом потому что если был бы какой-то криминал

никакой обмены мака ничего не будет здесь криминального ничего в этой схеме нет понимаете нормальная работа сети когда вот этот чувак отправляет в интернет пакеты он же пишет mac адрес роутера правильно роутер маршрутизирует их в интернет а это просто не в интернет а к соседнему компьютеру в свою же сеть и роутер точно так же промашутизирует еще какие то есть предложения предложение злоумышленник пройдет до а злоумышленника а я думаю писать ливона край проект тоже все знает наверное но здесь только фильтрация на роутере почему мак соседа миш мак соседа здесь вообще нигде не используется и этот компьютер может не знать мак соседа

на кентика справедливо спросил нет просто и на кентик тут пошел разговор если там тысячи этих абонентов что на роутере устанешь писать правил фильтрации вот и все ладно давайте дальше на самом деле вот такие самые простые решения они больше всего конечно интереса вызывают потому что вроде все легитимно вроде все правильно но блин ну чё сделать но что-то не так все равно ой давайте дальше про спарник 3 немножко поговорим спарник 3 то мы все помним или не помню мы будем мы не будем сейчас разбирать работу спарник 3 потому что мы знаем что протокол сложный вы его несомненно все любите и он вам нравится я уверен поэтому мы разберем только его защитные функции

все что касается защиты мст мы здесь не будем разбирать зачем значит ну главная атака на спанинг 3 вообще какие можно придумать атаки нас на спанинг 3 у мст все то же самое самое главное это единственное что вот приходит на ум это когда злоумышленник может стать рут коммутатором это это стопроцентные мэн эндзе мидал получается когда злоумышленник становится рутом забирает на себя весь трафик ну собственно и все как это осуществляется просто отправляется бы пдушка с приоритетом 0 мы все помним да про приоритеты чем ниже у нас число тем выше приоритет нулевой приоритет обозначает что все я теперь рут и весь трафик давайте-ка на меня заворачивайте все коммутаторы скажут о отлично мы на тебя трафик сейчас весь перешлю

завернем в общем какие есть защитные механизмы так называемый спаринг 3 tool kit защита ставит своей целью размещение в домене стп нелегитимных коммутаторов то есть именно злоумышленник либо защиту от кривых рук и ошибочный выбор корневого коммутатора даже не от кривых рук а просто от того что кто-то об этом не позаботился я видел я видел недавно настраивал сеть вот как в наш системный интегратор бы обратились заказчик я вот недавно там ковырялся в сети где там порядка 80 коммутаторов и они там спанинг 3 не настроен вообще но он же там есть по ник 3 по умолчанию включен просто мне был выбран рут коммутатор некоторые вот так оставляют это вообще на самотек

ну а здесь удивительного ничего нет потому что в данном случае заказчик это учебное заведение в котором нет специалистов занимающихся сетью которые заказали у системного интегратора у другого проект им поставили сеть настроили все вроде бы работает все нормально и а потом началось спанинг перестроение спанинг 3 там выключается какой-нибудь рут коммутатор который был ошибочно выбран и там и все и все лежит и все тормозит и непонятно что вот так инакентий сказал примерно правильно то есть бывают такие сети и это не редкость я вот к чему веду разговор так что ошибочный выбор корневого коммутатора это не сказки это реальность и это встречается очень часто к сожалению но смотрите

какие механизмы есть направлены на защиту спанинг 3 их не так много во-первых порт fast порт fast порт fast это так называемый режим edge порт когда этот порт будет у нас подниматься немедленно я помните же про порт fast или на на сиси и нер нужны это не рассказывают да мы с накид тем в разных интегратор кстати имеете ввиду рассказывать на синий ну да то есть порт fast включает режим edge порт немедленно в 10 этот форвардинг как только бы подушка на порту пришла то порт становится обычным нормальным портом без порт fast а механизм порт fast у нас отключается он будет просто нормально функционировать второй механизм это bpdu guard он у нас нужен для того чтобы исключить какие-то левые коммутаторы когда мы включаем

этот механизм на порту то при получении бы подушки порт у нас блокируется более корректная наверное штука которую лучше наверное наверное лучше все таки использовать вместо бы буду guard и это бы поду фильтр который просто отключает bpdu на порту просто спаник 3 ну здесь в практическом применении бы поду guard он слишком жесткий и бывают такие ситуации с которым я например сталкивался когда бпду guard не очень хорошо себя ввел он ну когда например вот когда провайдер включает в бпду guard на своих портах в бизнес-центре а клиент ставит нот от провайдера берет линк и ставит туда свой коммутатор

всего лишь один единственный коммутатор там нет никакой петли у клиента ничего просто коммутаторы в него чтобы воткнуть два роутера бывает же такое повсеместно бывает вот а провайдер провайдерский коммутатор увидев и одну единственную бпдушку прибежавший на свой порт сразу блочит порт вот в таком случае бпду guard лучше не использовать я за это имею ввиду чтобы под угар дне не обязательно включать везде прям на всех портах нужно понимать что если за этим портом может появиться какой-то коммутатор легитимный нормальный то лучше обойтись бпду фильтром бпду фильтр будет просто фильтровать бпдушки к ним он будет к нему будут приходить бпду но ничего происходить не будет так что это немножко разные механизмы и ну если это коммутатор чужой

до смысле где обход но мисты про что право бпду фильтр но это единственное решение иногда бывает да я я скажу что вот эта ситуация с провайдером из коммутатором было как раз у миши на работе когда когда он еще там не работал то есть пример то есть пример такой жизни когда провайдер просто взял в рубил из дебу пту guard все прекрасно все классно а потом мне предшественник михаила системный администратор звонил и не мог объяснить что происходит и как так почему работает почему не работает то есть но вот система администратор просто не понимает он включает напрямую link вот провайдерский провод в роутер включает все работает через коммутатор подключать не работает и все так что вот так как настраивать защитные функции слушайте на самом деле

есть некоторые подводные камни в настройке этих функций некоторые подводные карты камни здесь есть но мы сейчас разберем простые применения порт фаст у нас включается просто команды портфаст на по на одиночном интерфейсе на на всех портах есть возможность включить на всех портах которые в акцессе работают спаник 3 портфаст edge дефолт вот раньше не нужно было вот эту edge и по моему сейчас она тоже не обязательно хотя инакентий подскажет прям про свежак про свежайшие коммутаторы она не показывается и и по моему ну можно без нее то есть принимается команда но по-новому сейчас вот так имейте ввиду что спаник 3 портфаст

edge дефолт она включит только на акцесс портах если вы хотите включить еще портфаст и на тронг портах хотя это не очень хорошая идея но иногда это бывает нужно здесь нужно еще будет указывать параметр тронг можно и так сделать зачем нужно включать портфаст на тронках просто надо помнить что тронки они бывают не только между коммутаторами двумя физическими но между коммутаторами и например сервером почему нет сервер может смотреть в несколько виланов современные сетевые карты позволяют обрабатывать тегированные кадры это это таким механизмом уже тысячи лет так что не обязательно вот тронковый порт будет смотреть на другой коммутатор он может смотреть и на сервер и на обычный компьютер если вдруг там сидит какой-то чувак которому мало одного вилана я таких чуваков

знаю например разработчики то который работает с многими там виртуальными системами одновременно там бывают такие требования так что можно и на транк портах включить выпаду арт выпаду guard включается похожим образом либо на интерфейсе он включается либо можно также на всех портах включить то есть а бы по 2 guard он будет включаться и на акцессах и на транках по умолчанию если попросить вот так включится бы поду фильтр у нас умеет на интерфейсе включаться и у нас дальше есть продолжение и можно включить его по моему глобально сейчас на кенте меня поправят как человека который с коммутации не сталкивался давно вот на слайдах здесь бы буду guard default потерялась да да

вроде вроде бы я его писал может быть когда это вставляла вставлялся то давайте я допишу вот здесь должна быть должно быть так что касается root guard root guard это механизм защиты от неправильного выбора корневого коммутатора вот миш при глобальном включении поведения оба пдву фильтра да там значит инакентий расскажи ты ты лучше меня это помнишь можешь дополнение сделать могу он будет работать не не всегда как фильтр ну он будет отключаться просто сейчас на кенте будет работать как фильтр но он будет при включении

этого механизма не безусловно включаться на порту потому что безусловное включение предполагает что мы не отправляем в подушки непринимаемых случае если вы включаете в пдв фильтр дефолт у вас на порту он включается в условном режиме он начинает работать отправляет 10 подушек если ничего не получает то в этом случае на порту действительно дальше начинает работать бы поду фильтр безусловно то есть он не отправляет ничего не не принимает но если вы включаете бы поду фильтр дефолт и у вас на порту кто-то вам пришлет до подушку этот фильтр по факту на порту не активируется поэтому плохая идея включать буду фильтр дефолт включать его ручками да все спасибо большое я просто он все я вспомнил 10 сначала 10 бы подушек отправляет если тишина все хорошо он включается но это если глобально только вот кто будет сдавать экзамен по коммутации там вот вот такие приколы будут обязательно вот там вот таких нюансов почему

вы считается экзамен switch более сложный чем road хотя это не обязательно так просто на экзамене switch вот именно вот про такие мелочи про такие нюансы очень много вопросов вот михаил сдавал switch неоднократно вот вот эти нюансы старайтесь где-то себе может быть конспектировать потому что они важны они для экзаменов больше важны всегда так всегда можно документацию заглянуть а вот это вот такие поведения а на интерфейсе все будет нормально на интерфейсе включаешь и он там просто работает по поводу root guard а root guard это защитная функция спаник 3 от выбора нелегитимного корневого коммутатора работать на следующим образом если на этот порт приходит более более лучшее бы подушка здесь надо

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

так как все эти функции проверить включенные шоу спарник 3 самаре есть команда которая покажет включенные функции по дефолту если мы что-то включаем по дефолту глобально на коммутаторе то все это работает как видите в мст вот это все работает в мальчик паник 3 эти слайды были сделаны самосточного коммутатора как посмотреть на порту на порту мы посмотрели как посмотрели как включать просто посмотреть шоу спарник 3 на конкретном интерфейсе detail там будет все показано это что касается обзора таких защитных функций стп атаки с подменой сущности еще немножечко про атаки спутин

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

штука тоже 10 пили штука довольно старая основная задача предоставление конечным узлам настроек необходимых для сети мы знаем что выдается очень много параметров можно выдавать в принципе можно выдавать практически любую информацию просто поймет ли это клиент и нужно ли это клиенту вопрос другой можно гибко управлять и адресами выдавать узлам адреса в аренду те которые не используются в данный момент на какой-то фиксированный срок срока помечать их как не используемые если аренда не продлена либо выдавать адреса по каким-то критериям например по привязке mac адрес и ip адрес это все будет зависеть от реализации 10 пи сервера реализации очень много там можно напридумывать в принципе в реализации

10 пи сервера дофига я думаю все помнят про дичь себе к отсутствие конклик конфликтов протокол не гарантирует да то что будут одинаковые какие-то адреса опять же от реализации потому что некоторые сервера дичь себе будут проверять возможность конфликта когда выдавать адрес они там будут проверки делать cisco например делают некоторые сервера там этого не делают это все вопрос реализации как работает 10 помним вот эта схема дара discover offer request ок нам самое главное просто сейчас вспомнить примерно как у нас когда discover посылается до в брат кастом offer это все точно мы помним потому что это нам нужно сейчас держать в голове давайте дальше самая основная боль дичь себе то что он уязвим к атаке

дичь себе сервер спутинг когда атакующий злоумышленник может притвориться дичь себе сервером и таким образом выдать какую-то не ненужную информацию какую-то нелегитимную информацию нашим клиентам здесь будет здесь будет играть очень большой вопрос именно временной интервал насколько быстро будет успевать атакующий подсовывать свои нелегитимные ответы но это может сработать андрей сейчас попозже просто рвешь как все это работает когда жертва отправлять дисковер дисковер свой брат кастом то атакующий может опередить сервер и отправить свой оффер после этого жертва система будет общаться уже с атакующим она ему

реквест отправит и соответственно атакующие отправит ок вот это атака построена только на том что быстрее попытаться от попытаться ответить быстрее чем это сделает настоящий сервер то есть может быть еще такая подготовка как дичь себе starvation что такое 10 писар старышен это исчерпание пулу доступных адресов у сервера можно подвести вот провести такую подготовку когда сейчас андрей объяснил смыслов можно придумать много в этой атаке сейчас давайте просто рвешь я пару слов скажу что такое действие 10 степи starvation это когда атакующий может запросить у сервера все возможные адреса он будет просто посылать discover от разных якобы клиентов на сервер при каждом discovery сервер перед тем как отправить оффер перед

тем он будет адрес в своей базе помечать как уже предложенный он будет его уже резервировать поэтому достаточно просто в принципе отправить отправить пачку discover of такую пожирнее и у сервера все адреса будут помечены как уже предложенные то есть он сначала помечает у себя в базе уже как используем адрес ну он адрес будет не как выданный а как вот потенциально использованы потому что сервер пометил отправил offer и будет еще какое-то время ждать request на этот адрес то есть если реквеста не дождется в течение какого-то времени он просто потом освободит уже адрес то есть в принципе достаточно discover of но атакующий может точно также получить и дайте до а когда пройти весь механизм дура то есть исчерпание именно

свободных адресов как только сервер пометит все свои адреса как выданные как либо до offer их зарезервирует сервер уже не будет отвечать оффером и после этого атакующий может сам притвориться дичь и пи сервером и выдавать свои адреса жертвы в чем смысл выдавать раньше сервера адреса ну во-первых атакующий может выдать себя как дефолт гейтвей и опять же завернуть на себя весь трафик это же понимаете да здесь можно придумать много всего интересного может свои опции какие-то выдать до днс можно подменить таким образом мы с вами помните говорили про сейчас одну секундочку помните мы говорили с вами до про фишинг тот же самый фарминг когда подменяются ответа днс можно взять и подсунуть нелегитимный днс

то есть опции можно придумать много можно да не знаю блин можно и пи телефон и взять и подсунуть им на опцию 66 до которая говорит откуда им загружаться и загрузить все телефоны в сети с левого сервера и и все за не там зарегистрируются и прослушивать разговор ну то есть вообще вот такое подмена дичь и пи сервера это довольно серьезная штука потому что можно проявить такую творческую смекалку если в случае с спанинг 3 просто там атакующий подсовывает нелегитимный коммутатор заворачивать на себя трафик то здесь можно завернуть не не просто трафик на себя а уже такое будет гранулированная атака так что дичь и пи нужно

охранять и беречь это очень очень полезная вещь может что угодно может быть ладно эту тему развивать как можно без кодове бесконечности придумывать все новые и новые и новые какие-то какие-то применения как от этого защититься ну совершенно стандартный механизм это дичь и пи сну пинг который есть на коммутаторах ну наверное всех производителей это открытая технология каждый и реализовывает по-своему но смысл у всех будет одинаковое самое главное как работает 10 пи сну пинг администратор определяет доверенные порты и недоверенные порты то есть только доверенные порты могут передавать offer и ок то есть мы говорим что только за этими портами может у нас находиться дичь и пи сервер это не просто

когда как например на картинке у нас такой развесистый домен коммутации и тогда надо на транках будет ранкин делать доверенными портами то есть вот чтобы точно offer и прилетали от дичь и пи сервера но это можно сделать например хорошей практикой будет все акции спорт и все порты доступа сделать сразу недоверенными в механизм действий пи сну пинг мы будем точно уверены что ни на каком пользовательском порту не появится лево действий пи сервер с серверными сегментами там намного сложнее скажем виртуальной среде там конечно будет посложнее там но все равно дипи дипи серверов в нормальной сети их конечное количество и действий пи сервер не может возникнуть из ниоткуда именно на этом все и базируется то есть

недоверенные порты мы говорим какие доверенные какие недоверенные недоверенные порты могут передавать только либо discover ребрик ли либо request все больше ничего они передавать не могут что еще делать и ищите пи сну пинг дичь и пи сну пинг делает очень полезную штуку он будет строить таблицу соответствии mac адресов айпи адресов но виланы портойди то есть это можно сказать не основной механизм 10 пи сну пинга все-таки основным ну как ему второй основной механизм то есть первую очередь наверное 10 пи сну пинг признан защищать от нелегитимных серверов 10 2 его функция он будет строить так называемую базу дичь и пи сну пинга свою таблицу а куда будет записывать в каком вилане за каким портом какой у нас

mac адрес сидит и какой api адрес сидит это очень важная штука потому что эта база может использоваться другими механизмами мы сейчас тоже поэт про это поговорим давайте про настройка чуть поговорим 10 теперь сну пинг он запускается и на l2 и на l3 коммутаторах как прикрыться от starvation интересный вопрос здесь себе сну пингом то есть здесь смотрите здесь будет очень много зависеть от реализации дичь и пи сервера в принципе ну порт security может помочь да когда мы можем сказать что столько там акадресов но теоретически злоумышленник может отправлять дискаверы в принципе от одного и

того же мака может быть и такое либо ну просто помог адресом не очень хорошая идея здесь все забуд все будет зависеть от реализации все таки сервера если будет атакующий отправлять только от своего mac адреса дискаверы том я допускаю что какие-то реализации 10 серверов все равно будут адрес уже резервировать перед выдачей все новые новый адрес но на разные клиента иди может быть да опять же как вот на этой картинке дичь и пи сервер может располагаться совершенно другом сегменте и невозможно будет подсчитать количество mac адресов ну как когда здесь огромная сеть а серверный сегмент расположен здесь кто знает сколько тут mac адресов может быть на этих портах это опасно поэтому у нас есть 10 пи

snooping можно лимитрейт опять же в крупной сети или мелит лимитрейт не особо поможет если у вас сеть в которой несколько тысяч хостов и блин и мам моргнул свет и все хосты перегрузились 1 почти одновременно то будет довольно большой трафик где ищите пи в этот момент но любой школьник не может сделать одежде пи старвейшин здесь дело в том что вот он где ищите пиступинг собственно с помощью него защища защищаемся там и но вот от старвейшина нет старвейшина в самом действии пи тогда делать дело в том что в действии пи если делать жесткую привязку айпи маг да то есть привязать адрес там 190 там

студент 2 6 811 к одному mac адресу 12 во втором а к адресу то эти адресу эти адреса он не будет резервировать вообще но это уже не настолько гибкая да я согласен вообще привязка макайпи найди и степи она в условиях предприятия оправдана может быть только в случае принтеров сетевых вот таких железок или айпи камер а в случае простых компьютеров конечно нет секунд умеешь но тут миш можно спорить долго оправдана она не оправдана ящик ну мое мнение что не оправдан всегда удобно но не знаю я я не знаю я от этого отказался когда сеть там начинает еще больше потом расти но не знаю это кому как нравится кому-то это нужно кому-то это не очень нужно так что можно много аргументов

приводить за и против мы давать не будем это обсуждать сейчас по можно потом поболтать когда будет время как настраиваться 10 пи сну пинг 10 пи сну пинг настраивается довольно просто он включается глобально он настраивается основные настройки у него глобальные мы его включаем мы его настраиваем для конкретных виланов потому что в некоторых виланах он просто не нужен ну там в серверном каком сегменте где мы где у нас есть пять серверов в одном вилане со статическими опять адресами зачем там 10 пи сно пинг это необязательная штука вот вне в некоторых местах поэтому можно включить только для конкретных виланов вернее нужно указать виланы обязательно можно указать где он будет хранить эту базу данных можно хранить на флэше можно хранить удаленно

есть смысл в удаленном хранении несомненно потому что когда железо перегружается то эту базу можно быстро подтянуть и не восстанавливать вот она все таки эта база строится на основе дичь себе а если у на предприятии какое-нибудь долгое время аренда ну я не помню умолчание скажем windows сервере но по моему это восемь часов для обычных клиентов то после перезагрузки или восемь дней даже могу путать я у меня нет дичь себе на windows и ну это долгое время аренды понимаем и поэтому перезагрузив коммутатор моим базу можем в принципе не обновить моментально вот так что база пополняется не быстро можно указать

где и хранить хранить удаленно хорошая идея доверенные порты у нас настраиваются просто зайдя на конкретный порт и также на портах неплохо было бы включить вот этот лимитрейт лимитрейт это количество запросов к серверу на недоверенных портах то есть если будет чаще чем 10 раз в секунду у нас эти запросы то они просто будут фильтроваться посмотреть настройки можно команды шоу дичьи пиа пи дичьи пи сну пинг который ну как он у нас настроен на каких виланах и посмотреть что у нас с портами и какие рейт лимит заданы проверка работы действий пи сну пинг посмотреть базу данных просто я так буду проговаривать команды шоу и пи дичьи пи сну пинг датабейс в котором это не база данных в виде

списка просто статистика по базе данных статистика по вообще работе полезная команда statistics есть шоу и пи дичьи пи снопинг statistics который просто показывает что происходит с пакетами сколько всего было передано сколько было дропов на недоверенных портах то есть заглядывать в эту статистику иногда надо даже если у вас все здорово классно настроена посмотреть эту статистику либо автоматически чтобы она там проверялась раз не знаю в неделю к вам на почту приходила либо руками там иногда зайти и подглядеть очень полезно потому что здесь могут быть сюрпризы эта штука я честно скажу я не знаю умеет ли действий пи сну пинг нет умеет отправлять саном петра по по моему умеет вот но все слоги это тоже можно увидеть

опять же я возвращаюсь к тому что все эти вещи в логе их блин только автоматически обрабатывать сообщение от системы дичьи пи сну пинга они они очень много дадут в плане безопасности потому что можно там месяцами ничего не слышать своей сети но если дичьи пи сну пинг вдруг ругнулся на что-то вам какой-то лог пришел либо вы там вручную счетчики посмотрели значит уже что-то не так значит ну не может просто так вот просто так офферы посылать в нормальной сети что-то если в нормальной сети кроме дичьи пи сервера кто-то отдает offer ну значит что-то уже не так надо уже ковырять и нужно начинать суетиться нужно расследовать это дело нет штука важная мы поговорили да сколько можно всего завязать

на дичьи пи до огромное количество атак там до хрена привязку адресов мак адресов айпи адресов можно посмотреть шоу и пиде ищи пи биндинг а все у нас больше здесь нет да ну можно надо сказать о том здесь команды не показаны я думаю что их не нужно мне для экзамена запоминать не так есть возможность задать это соответствие вручную потому что очень много адресов все равно остаются в сети статической можно задать их и вручную так я вернулся вот к этому слайду просто это слайд у нас два раза нарисован про арп кэш пояснинг отравление кэша а rp теперь что касается арп здесь теперь мы уже поговорили что касается арп ну кэш арп штука достаточно уязвимая почему она уязвимая механизм

арп на конечных хостах он не имеет вообще никак никаких средств защиты то есть арп обычный который работает на windows и например ну он ничего не знает о о безопасности там это не предусмотрено протокол арп проектировался сто лет назад и тогда тогда вообще с безопасностью было все по-другому тогда сети просто считались безопасными хотя бы по той простой причине что к ним не мог подключиться любой желающий да как вот все протоколы которые мы сейчас рассматриваем да там ethernet айпед все было придумано очень и очень давно ethernet 80 году вышел какая там безопасность там блин компьютер ты еще не у всех был так что все механизмы появлялись уже потом то же самое с арп ты а рп можешь скормить любую

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

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

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

просто со своим мак адресом и с любыми совершенно совершенно произвольными айпи адресами и все компьютеры которые будут получать конечные хосты которые будут получать эти эту информацию они будут в свой арп кэш заносить что адреса там 1001 1002 3 и так далее он хоть весь диапазон переберет и они все ссылаются на совершенно конкретный мак адрес си си си си все так что механизмов чтобы вот это все проверить просто но не существует в протоколе арп что придет какой-то ли ну ну блин не предполагали ребята 30 лет назад что найдется какой-то чувак который выберет весь диапазон адресов и поставят свой мак адрес вот такая неприятная штука запретить его нельзя вообще запретить арп достаточно сложно

зафильтровать арп например на коммутаторе не получится или на машутизаторе вот так с листами никак не закроешь арп просто просто всегда работает вот так как от этого защититься а защититься можно только соответственно механизмом от гарп какая панация может быть это же то а и пивы 6 в ай пивы 6 да там чуть все по-другому но мы говорим про и пиве 4 про арп как древний что делать с арп как защитить арп ну динамика rp inspection да и то есть ди и ай есть такая аббревиатура это специально придуманный механизм чтобы защититься от таких плохих парней опять же здесь определяются интерфейсы доверенные

и недоверенные на доверенных интерфейсах мы ничего не будем проверять вот там все нормально за этим интерфейсом у нас стоит один-единственный сервер мы точно знаем что он никогда не сойдет с ума и все будет с ним нормально а интерфейс и которым мы меньше доверяем ну например все интерфейс доступа access мы их определяем как недоверенные и тогда на этих интерфейсах будут будет инспекция пакеты оберт пакета rp будут проверяться а действительно ли мак адрес и ip адрес который едет в этом пакете соответствует правде как это будет проверяться по базе действий при сну пинг которая была собрана раньше с помощью дичь себе когда я говорил что база нужна не только для сну пинга вот собственно она здесь и и нужно а для вот такой проверки то есть едет а рп пакет там написано что мак адрес написано пи адрес

а рп инспекция будет его проверять в базе действий при сну пинг плюс можно задавать статические соответствия адресов если у нас как я говорил есть хост и какие-то со статическими и пи адресами которые никогда в жизни не не обращаются по dhcp к серверу и не получают адресов там дичь себе вообще может не быть отключен или вообще не установлен клиент то для таких хостов можно занести статическое соответствие что вот хост с таким-то маком и такой type ему соответствует дальше записи имеет срок действия они посмотреть в базе действий пи сну пинга их можно в роли в ранних конфиге их нет они хранятся как мы уже сказали да в отдельном файле

локальном на флэш либо удаленном и их в ранних конфиге они не будут 10 пи ай пиве 6 защититься сейчас то механизм работы 10 такой же вы продаете теперь говорите или про ней бар дисковери роутера роутер сели си тэй шин прору нет да это я два вопроса задал и и рс и ра честно скажу не знаю и рс и ра можно у меня поставили в тупик это очень хороший вопрос у глеба вадимович все на пиво 6 уже глеба единственный что человек с ай пиво 6 живым

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

определяться доверенный порт просто вот на цисковских коммутаторах надо почитать посмотреть задавать доверенный порт для и рэй так нам записать где-нибудь вы мне в чатике напомнить если что так давайте дальше про динамика рп inspection не договорил что еще можно задать можно есть еще такие а рп акцесс лист которые мы в конфиге будем писать в принципе это похоже на то как на то как мы будем прописывать это в 10 пи снопинг в базе задавать статические соответствия но можно но это именно 10 пи снопинг а можно для а рп инспекции написать именно а рп еще

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

В ARP-кэше будут светиться только те, кто за доверенными портами, там дальше доверенный порт на коммутаторе. Например, роутер — роутера он будет видеть, у него будет он в ARP-кэше, больше ничего не будет.