Защита от проблем в Ethernet на коммутаторах Cisco

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

Это очень тяжело и очень накладно в смысле времени, в смысле поддержания его в актуальном состоянии. Либо есть второй вариант — ввести белый список, но пополнять его автоматически. Просто сказать, что у нас на порту может быть 10 разрешённых адресов, и первые 10 адресов, которые мы увидим, будут разрешены, а 11-й уже нет. Или можно комбинировать — сказать, что максимальное количество адресов на порту — 10, из них 5 мы задаём вручную, 5 можно распознать автоматически. Штука эта называется Port Security. Она будет вести белый список на каждом порту, и вы можете задавать размер белого списка. И вы можете заносить адреса в этот список либо вручную, либо автоматически — если коммутатор видит кадр, который приходит из-под нового мака, которого в белом списке нет, но при этом в белом списке ещё есть свободное место. Если приходит кадр от мака, которого нету в списке, и места в белом списке тоже нет, то возникает так называемое нарушение безопасности,

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

и после перезагрузки этот адрес у вас будет сохраняться, постоянно будет в этом белом списке находиться. Либо вы можете сказать, что адрес добавится в белый список автоматически, но это не произойдёт в конфигурации. Это произойдёт в специальную отдельную быструю память. Рядом с таблицей коммутации будет отдельно эта память с белым списком находиться, потому что её надо проверять постоянно. И она не может находиться в конфигурации. Если у вас динамические адреса распознаны, то после ребута списки этих динамических адресов потеряются. Если вы хотите, чтобы динамические адреса не терялись, то вы как раз включаете режим sticky, и происходит следующее. Когда коммутатор выучивает новый MAC, он его дополнительно добавляет в running config. В виде просто отдельной строчки, как будто администратор вручную добавил новый MAC-адрес. И в конфиге появляется новая запись. Если вы сохраните конфигурацию, то после перезагрузки эти sticky-адреса,

которые прилипают к running config, если хотите, они повторно будут занесены в конфигурацию. Такие динамические адреса, которые на лету становятся статическими. Как всё это дело настраивается? Всё это происходит в контексте switchport port-security на интерфейсах Ethernet. Начну сразу с того, что включить эту штуку можно только на портах в стабильном режиме. Вы не можете включить это на портах, на которых у вас работает DTP. Можно включить на access-порту, можно включить на транковом порту, но аккуратно. На транках это допустимо делать. Это задизайнено под транки, которые смотрят на конечных абонентов. Весь смысл port-security в том, что вы её не включаете на портах, которые смотрят на соседние свитчи. Только на порту, который смотрит на конечного абонента. Или в крайнем случае на порту, на котором вы смотрите на какой-то совсем маленький тупенький свитч,

за которым сидит очень небольшое количество абонентов. Это не надо делать на транзитных портах. Если у вас access switch, access switch, distribution switch, то здесь или здесь port-security включать не нужно. А вот тут нужно и тут нужно. Дальше. Фиксируем режим работы порта — switchport mode access. Можно включать на транках, но только если у вас как раз ситуация вида: стоит гипервизор, и на нём виртуалки крутятся. И вы хотите сказать, что да, мы включаем port-security на этом интерфейсе, но мы понимаем, что это транковый порт, потому что на него смотрит конечный сервер. Там нет соседнего свитча, поэтому в некоторых случаях это включить можно. Дальше. Вы указываете команду switchport port-security для включения самого механизма. Рекомендуется сначала настроить port-security, а потом только его включать.

Эту команду есть смысл выполнять самой последней, после того как вы сделаете все остальные настройки. То, что вы задаёте настройки следующими командами, оно не включает автоматически сам режим. Вы можете сначала задать максимум количества адресов в списке, задать адреса, указать что случится при нарушении безопасности, и только потом сказать switchport port-security, тем самым включив этот движок. Почему так рекомендуется делать? Дело в том, что ваш свитч может смотреть не на конечного пользователя, а на маленький, тупенький, глупенький трёхпортовый свитчик, на котором сидят три абонента. И вы управлять этим трёхпортовым свитчиком не можете, а защититься от атаки всё равно можете. И вы в этой ситуации можете сказать: включаем port-security на таком интерфейсе, начинаем его анализировать. Но у нас на этом порту может приходить кадр от одного узла, от другого, от третьего. Короче говоря, три разных мака там может быть. По умолчанию, если вы включаете port-security,

настройка будет такая, что на порту разрешён только один мак-адрес. Поэтому если вы просто включаете switchport port-security в этой ситуации, у вас порт сразу пристрелится с криками о нарушении. Поэтому, чтобы этого не произошло, вы можете сначала настроить весь контекст switchport port-security, а только потом сказать саму команду и тем самым включить движок с теми настройками, которые вы задали. Какие настройки имеет смысл задавать? Первое — это количество мак-адресов в белом списке: switchport port-security maximum и дальше цифра. Это просто сколько места в этом белом списке есть, включая статические, динамические, все подряд адреса. Если вы хотите включить режим sticky, чтобы ваши маки, которые вы динамически распознали, автоматически попадали и в конфигурацию тоже — не просто в эту быструю память для белого списка, а ещё и в конфиг, чтобы после ребута, при условии что конфиг сохранился, они бы возобновлялись автоматически, — то даётся switchport port-security mac-address sticky.

И все динамически распознанные адреса, которые будут заново распознаваться, будут прилипать к running config, и если вы будете сохранять их, то при перезагрузке будут вспоминаться. Если вы хотите мак-адреса какие-то вручную внести в белый список, то вы указываете switchport port-security mac-address и дальше указываете адреса. При этом, естественно, вы занимаете одно место в списке. Ещё одна полезная штука — это указание того, что произойдёт в случае проблемы. Если у нас случится нарушение безопасности — придёт кадр из-под нового мака, и места в белом списке нету, не новый кадр, а кадр из-под нового мака, места в белом списке нету, — то у нас происходит нарушение безопасности, и есть три варианта, что делать в этом случае. Задаётся командой switchport port-security violation и дальше либо shutdown, либо restrict, либо protect. Shutdown — это когда порт падает в состояние так называемое err-disable. В этом состоянии никакая коммутация не происходит до тех пор, пока состояние err-disable не снимется. Это довольно удобная штука.

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

другие режимы. Режим restrict и режим protect. Разница между ними заключается в том, что порт в restrict и protect, в отличие от shutdown, не будет падать в err-disable. Коммутация на этом порту в принципе будет возможна. В err-disable коммутация вообще невозможна. Вы должны выключить порт командой shutdown и включить его снова, чтобы он завёлся. Если restrict или protect, то такого жёсткого события, типа пристрелить целиком порт, сразу выстрел в голову — такого нет. В restrict и protect новые кадры, которые у вас будут отправляться из-под неправильных маков, будут дропаться, они не будут коммутироваться. Но при этом кадры из-под тех маков, которые в белом списке, будут нормально работать. Если у вас кто-то взял, поменял мак, коммутация из-под нового мака ходить не будет. Но если вы вернёте мак на старый, то у вас всё будет нормально работать. Разница между restrict и protect заключается в том, что в restrict вы

не обрабатываете кадры из-под новых маков, при этом старые маки вы обрабатываете, и у вас случается нарушение безопасности. У вас начинают расти счётчики, у вас начинает оповещаться система мониторинга, у вас начинает работать SNMP-трап. Если вы администратор, который приходит раз в неделю посмотреть, что случилось, разобраться с какими-то проблемами, и в том числе смотрит логи системы мониторинга, то вы можете включить режим restrict, и вы тем самым защититесь от атаки на переполнение мак-адресов, защититесь от атаки на подмену маков, но вы узнаете о том, что это произошло, потому что у вас ведутся журналы. Если вы точно знаете, что никто никогда эти логи смотреть не будет — например, потому что вы даже не приходящий администратор, а какой-нибудь сотрудник компании-интегратора, и к вам пришёл клиент, говорит: «Постройте мне сеть, и потом я вам платить деньги не буду,

я буду сам эту сеть как-то обслуживать, у меня будет менеджер по продажам периодически смотреть, что лампочка правильно горит». Он никогда не будет читать логи, и в этом смысле нет смысла даже пытаться логи эти вести, нет смысла включать счётчик нарушений, никто на него никогда смотреть не будет. В этом случае вы можете включить protect — то же самое, что restrict, только не ябедничать никому, просто тихо дропать все кадры и всё. Shutdown — это жёсткий вариант, restrict и protect — это мягкий вариант. Restrict — ябедничать админу, protect — просто защищать, никому не ябедничать, тихо, мирно делать свою работу. Как мониторится всё это дело? show port-security interface и название интерфейса. Первая строчка — включён ли port-security на порту. Вторая строчка — в каком состоянии прямо сейчас порт. Secure Up — значит, всё работает хорошо, port-security на нём взведён, капкан в актуальном состоянии, в него можно наступить,

и вам зажмёт ногу. Но пока ещё не зажала. Violation Mode — Shutdown: что произойдёт, если случится нарушение безопасности? Вот оно — Shutdown. Это поведение по умолчанию. При срабатывании, при нарушении безопасности порт выключится целиком, но физика останется живой. Лампочка гореть будет, а при этом порт работать по факту не будет. И он останется в этом состоянии до тех пор, пока вы не выключите его по-настоящему командой shutdown и не скажете No Shutdown. При этом, естественно, Shutdown и No Shutdown имеет смысл делать только тогда, когда вы разобрались в проблеме. Если вы просто видите, порт в AirDisable упал, просто Shut No Shut сделаете, он снова упадёт. Скорее всего, проблемный MAC никуда не делся. Дальше. Максимум MAC-адресов. Количество адресов в белом списке, которое может быть по факту, может быть гипотетически. Total MAC Addresses — это сколько по факту сейчас прямо есть. Это максимум, а это факт,

сколько прямо сейчас. Configured MAC Addresses — это сколько статических адресов задано. Sticky MAC-адресов — сколько динамических адресов попало в конфиг как sticky. Соответственно, если вы знаете, что у вас всего MAC-адресов прямо сейчас в списке одна штука, и из них один, допустим, законфигуренный, то вы понимаете, что просто динамических, которые не sticky, их ноль. Последний кадр, который был виден на этом порту, штатно или нештатно, показывается в таком формате с началом MAC-адреса через двоеточие VLAN. И счётчик нарушения безопасности: если вдруг случается нарушение безопасности, если вы отслеживаете эти счётчики в режиме restrict, то у вас показывается, сколько именно этих нарушений безопасности было. Если у вас, понятное дело, режим shutdown стоит, то одно нарушение безопасности, и ваш порт пристрелился, соответственно, security violation count будет один, и здесь будет secure shutdown. Далее.

Show port security address покажет список всех адресов, которые находятся во всех белых списках на всех портах. Есть нюанс. Место в белых списках, в этой табличке белых списков, оно ограничено. И показывается максимальный размер для вашей платформы, сколько адресов вы в принципе можете хранить. Загвоздка заключается вот в чём. У вас есть ещё неучтённое место, куда вы можете положить MAC-адреса для белых списков. На каждом порту — у вас есть свитч, у него есть, допустим, я нарисую 4 порта, и есть отдельная табличка, куда вы можете положить эти самые MAC-адреса. 4096 MAC-адресов вы можете сюда положить. Плюс ещё один адрес можно хранить на каждом порту бесплатно, но только для этого порта. Поэтому, если у нас здесь, например, есть три MAC-адреса, которые наша система залернила, и она допускает, что это адреса хорошие, белые, пушистые, два из них на GigabitEthernet 0/0, и один на GigabitEthernet 0/1,

то получится, что на GigabitEthernet 0/0 мы этот адрес, первый самый, положили в бесплатное место для этого порта. И соответственно, второй адрес для GigabitEthernet 0/0 нам уже придётся класть в эту кучку за деньги, своего рода за деньги, с выеданием лимита в 4096 адресов. Порт GigabitEthernet 0/1 для этого адреса тоже имеет одну свободную дырочку, мы тоже туда положили свободный адрес. Поэтому по факту получилось, что у нас в системе три адреса хранится, три адреса, место из кучки мы съели только под один адрес, потому что ещё два адреса хранятся на двух портах в кавычках бесплатно. И поэтому total addresses in system показывает, что у нас один адрес из 4096 по факту съеден. Такой хитрый момент. Вы можете посмотреть те адреса, которые сейчас залернились,

и это show port security address. Если вас интересуют только sticky-адреса, то вы можете посмотреть show running-config, interface GigabitEthernet 0/0, и соответственно, все MAC-адреса, которые sticky залернились, они попадают в конфигурацию почти так же, как MAC-адреса статические. MAC-адрес, адрес, 5000.0001.0001. Так выглядят статические адреса без слова sticky. Это то, что администратор ручками сделал. А если вы включаете MAC-адрес sticky на порту, то MAC-адрес sticky показывает как раз, что этот адрес был залернен и попал в конфигурацию из-за того, что он липкий, из-за того, что он прилип к running-config. После того, как если вдруг захотим перезагрузиться, мы можем сказать copy running-config startup-config, и эта штука попадёт в startup-config. И после ребута соответственно она автоматически пополнит наш список белых адресов.

Как следствие, если вдруг мы перезагружаемся, то у нас табличка белых адресов восстанавливается в своё исходное состояние, несмотря на то, что сама табличка физически хранится в энергозависимой памяти. Если вы просто без сохранения конфига дёрнете питание, у вас все динамические адреса потеряются. Даже sticky потеряются. А если вы включаете sticky, сохраняете конфиг и перезагружаетесь, то все адреса, которые вы динамически залернили, они у вас сразу будут в конфиге, и они сразу будут в этой самой быстрой памяти находиться. Никакие адреса не потеряются. Sticky-адреса — это неплохой способ провести стартовое наполнение базы маков. Если вы хотите, вы можете включить sticky-адреса, вы можете включить просто на всех интерфейсах port security, и в предположении, что у вас на каждом коммутаторе, на каждом порту физически подключен только один компьютер и больше ничего, то у вас залернится один-единственный MAC, который этому компьютеру соответствует,

и он попадёт в стартовую конфигурацию. И соответственно, после ребута, если вы сохраните конфигу, у вас эти адреса будут фактически статикой прописаны. Если вдруг вы меняете компьютер, у него меняется MAC-адрес, то соответственно вам потребуется дополнительно выполнить секретное действие. Вы должны будете зайти на этот коммутатор, удалить старый MAC-адрес из белого списка и добавить новый. Так. В чём проблема с этими белыми списками? Их офигенно тяжело вести. Restrict, protect и shutdown, я про них уже всё рассказал. Так вот, их очень тяжело вести. Если вдруг у вас на порту организуется какой-то кадр из-под неправильного MAC-а, и у вас работает режим shutdown, то у вас падает целиком порт. У меня был случай, я пришёл в новую компанию работать, и у меня, соответственно, первый рабочий день, мне сказали: вот смотри, вот твоё рабочее место,

вот тебе компьютер, вот тебе список заданий каких-то, вжиться в роль в компании, и мне сказали: попробуй на этом компьютере поднять сервер виртуальных машин. И соответственно, вот как это всё дело выглядело. У нас есть комната, в этой комнате сидят компьютеры пользователей. Раз — компьютер какого-то администратора, два — компьютер администратора, тут начальник сидит, и соответственно, здесь я сижу. Мне дали компьютер, сказали: попробуй на нём виртуалки поднять. Всё это дело физически было подключено к свитчу. Вот у нас тут свитчик на 4 порта. Дальше. Этот свитчик был подключен к какой-то ведущей Cisco. На ней был включён port security. Первый рабочий день. Мне говорят: вот тебе порт, вот тебе компьютер, поднимай на нём виртуалку. Я поднял.

Что получилось с точки зрения этого свитча? Да ничего, просто новые кадры какие-то появились, начали бегать из-под новых маков. Что произошло на этой ведущей Cisco? Появился новый MAC, которого раньше не было. И она дропнула этот порт. Она его выключила в shutdown. Естественно, благодаря тому, что этот чувак был цискарём, он пошёл на эту Cisco, разобрался, включил порт. Но пока он этого не сделал, весь этот линк лежал. И соответственно, вся эта наша зона была обособлена от всей остальной сети. И здесь, конечно, было нарушение с точки зрения дизайна, потому что это плохой дизайн, когда у вас port security включается на транзитный свитч. Так делать не надо. Если port security включать, его надо на этом свитче включать на конечников, на портах, которые смотрят на конечных пользователей. Если бы даже гипотетически предположить, что здесь было бы так и сделано, мы выключили бы вот этот порт мне. И соответственно, я бы только поднял новую виртуалку, она отправила бы самый первый кадр из-под мака, который виртуальной машине бы соответствовал.

Помимо того, что там ещё и бегают кадры из-под физических маков. И соответственно, выключили бы мой просто порт. Не все порты, не весь порт, который смотрит на всех абонентов, а только мой собственный порт. Так что port security — это тяжёлая штука, особенно если у вас есть ситуация, когда может быть такое, что обычный компьютер пользователя начинает посылать кадры из-под нескольких разных маков. Виртуальные машины — это только один пример. На самом деле, если посмотреть на то, как устроены современные рабочие места пользователей, достаточно часто можно увидеть, что виртуалки там могут запускаться сами по себе. Хороший пример, наверное, в Windows 7 была технология, называлась она MAP, что ли, как-то так, забыл название. Смысл заключался в том, что вы могли запустить некое приложение внутри виртуалки,

и это всё происходило абсолютно прозрачно для вас. Для вас, как для пользователей Windows, вы просто нажимали ярлычок, он запускался, а физически это происходило из-за того, что у вас внутри вашего компьютера запускалась виртуальная машина, в которой запускался отдельный процесс. И это было изолировано, всё там — песочница, безопасность, всё дела. Но, естественно, эта виртуальная машина отправляла бы кадры уже из-под своего собственного отдельного мака, и всё это дело точно так же не проходило бы проверку Port Security. Поэтому вести учёт в современной сети всех мак-адресов, которые могут зародиться за каждым из портов, просто тяжело. Поэтому если говорить про реальное использование Port Security, нет смысла в современной сети защищаться с помощью Port Security от подмены мака. С помощью Port Security сегодня можно защищаться от того, что кто-то устроит атаку на переполнение таблицы мак-адресов. Он 8 тысяч маков не нальёт на вас, или там 5 тысяч маков, или даже тысячу маков не нальёт.

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

В то же время, если мы знаем, что на порту у нас точно есть какой-то маленький свитчик, и там могут быть какие-то пользователи, которые, например, виртуалки запускают, мы говорим, окей, каждый пользователь может там десять маков использовать. И этих пользователей у нас там три штуки. Значит, максимальный лимит на этом порту будет там пятьдесят маков. Больше, чем пятьдесят маков уже подозрительно. Выключаем порт, разбираемся. Это очень расслабленные настройки, но тем не менее они вас в большинстве случаев в современной сети спасут от того, что какой-то целый отдел, например, ваших пользователей внезапно остался без связи. Или отдельный даже пользователь, знаете, может быть такое, что кто-то там, Вася, Петя, который начальник отдела продажников, не самая высокая персона в организации, взял и решил вместо своего рабочего компьютера воткнуть домашний ноутбук. В принципе, ничего плохого он не имел в виду. Но сеть-то не знает про то, что если вы там включили точное отслеживание мак-адресов, что он ничего плохого не имел в виду. Она порт целиком заблокировала. И режим shutdown в такой ситуации будет явно не очень хорошей идеей.

Либо вы указываете какое-то разумное количество мак-адресов, которое может быть на порту, и указываете мягкие режимы restrict, protect, либо вы указываете с очень большим запасом количество мак-адресов и включаете shutdown. Чтобы shutdown происходил точно только тогда, когда прям идёт атака. Но защищаться именно от атаки на подмену мака с помощью Port Security просто неудобно. Если вдруг вы увидите, как это работает, на слайде, да, я здесь рисовал много всякого разного. Здесь как раз показан пример того, как происходит нарушение безопасности. Первое событие. У нас на порту разрешено три максимума адреса, получен новый кадр от незнакомого мака. Происходит событие, Port Security срабатывает, и порт кладёт в состояние err-disabled. Если show interface посмотреть, будет написано, что порт, там, FastEthernet 0/1 или GigabitEthernet 0/0, в нашем случае, да, is down, line protocol is down и в скобочках err-disabled.

Его тогда надо командой shutdown погасить, а потом снова включить после того, как вы разберётесь с проблемой Port Security. Дальше показывает сообщение, что проблема была вызвана вот таким странным MAC-адресом на порту GigabitEthernet 0/0, и произошло это в первом VLAN-е. И show port-security на интерфейсе показывает, что на порту у нас случилось событие нарушения безопасности, порт перешёл в shutdown. Счётчик вырос на единичку, последний MAC-адрес, который был виден, вот такой. Если вы указываете мягкий режим, restrict или protect, то здесь вы, скорее всего, будете видеть разрешённые MAC-и. У вас здесь показывается действительно последний-последний кадр с последним MAC-ом, с последним VLAN-ом, который вы видели. Если у вас есть свитч, на нём есть некий Вася, который отправлял когда-то плохие кадры и не вызвал нарушения безопасности, а потом продолжает отправлять хорошие, хорошие, хорошие, то здесь, скорее всего, последний виденный кадр будет именно хорошим.

Есть ли за access-портами серверы, и там, возможно, виртуалки. Есть ли смысл включать Port Security? На мой взгляд, есть. Если вы не можете это сделать на уровне виртуального свитча на вашем гипервизоре, то тогда есть смысл включать Port Security на порту, который смотрит на сервер, но при этом вы должны отчётливо понимать, что этих виртуалок может быть довольно много. Поэтому включите там, не знаю, 100, 200, 500 маков. При этом с запасом, чтобы в нормальной ситуации ваш порт не погасили. Если вдруг там внезапно организуется 500 маков, то, да, там что-то перестанет работать. Это будет неприятно. Но максимальное количество маков у вас в табличке довольно большое, поэтому если вы разрешаете там 500 маков на порту, то, скорее всего, с очень большой вероятностью, если вдруг на порту действительно нарисуется столько маков, то это будет именно атака, и вы тем самым, да, выключаете порт,

а что делать? Так. Да, рекомендации по Port Security: не прописывайте все мак-адреса вручную. В крайнем случае включайте sticky для базового наполнения таблицы, сохраняйте конфигу, и у вас будут прописаны эти самые мак-адреса. Но поддерживать в актуальном состоянии этот список прям реально совсем тяжело, я вам не рекомендую это делать, однажды пробовал, это задолбаться можно. Если вам нужно будет защищаться от того, что кто-то будет маки менять или вставлять в порт какие-то неавторизованные устройства, используйте ту технологию, которая специально для этого заточена, 802.1X. Вам потребуется очень сложная инфраструктура для всего этого дела. Это сразу RADIUS, это сразу какие-то там, допустим, либо аутентификация по логину и паролю, либо по сертификатам. Это тяжело делать, но тем не менее оно того стоит, хотя бы потому, что если у вас много свитчей, и вы прописываете маки вручную,

вам надо на каждом свитче вести отдельную базу разрешённых маков. Если вы используете 802.1X, то вам потребуется в одном месте держать эту самую базу актуальных разрешённых узлов. Например, вы поднимаете RADIUS-сервер и на RADIUS-е говорите, используем там сертификаты. И у вас база сертификатов всех компьютеров, она есть. Там Active Directory, к примеру, он может автоматически всем компьютерам в домене выдавать эти самые сертификаты. Появился новый компьютер в домене, вы в Active Directory завели, у вас автоматически на него выписался сертификат, автоматически этот сертификат используется для доступа к сети. Хочет кто-то подключить новый компьютер к сети, у него ничего не выйдет до тех пор, пока вы ему ручками не пропишете сертификат отдельно. Это довольно удобно. Но, опять же, да, 802.1X — это штука, она большая, она объёмная. И поэтому просто так в маленькой сети её использовать, конечно, неразумно. Разумная рекомендация — защищайте вашу таблицу от переполнения,

прописывайте максимум в 10–50 маков на абонентском порту, и тем самым никто вас не поломает в смысле переполнения мак-адресов вообще. Последнее, что сегодня хочется сказать, это про Spanning Tree. Очень большой, очень толстый протокол. Мы с вами будем его смотреть на CCNA 2 чуть-чуть, а ещё более детально на курсе по свитчингу, где про него будет практически, не сказать, часов 20, наверное, много, да? Но про него можно сказать одно, что если вы его хотя бы включаете, это уже сильно лучше, чем если вы его не включаете. На цисках он по умолчанию работает, и он вас защищает от петли. Работает он таким образом, что он сначала блокирует все, здесь неправильно написано, это неправильно, сначала заблокировать всё, потом обнаружить факт возникновения петли и те интерфейсы, которые формируют петлю, оставить заблокированными, всё остальное разблокировать. Он сначала всё блокирует, если у него возникает подозрение на то,

что может случиться петля, а потом потихоньку разблокирует то, что нужно. Spanning Tree нужно настраивать, но грамотная его настройка — это занятие долгое и требует достаточно много знаний. В принципе, если вы его не настраиваете и просто включаете, это тоже не так уж и плохо. Это явно лучше, чем не настраивать его и не включать его. Ну и да. На цисках по умолчанию работает. Если у вас не циски, включаете его, хоть в каком режиме, он всё равно будет лучше, чем без него. Если вы работаете с цисками, есть смысл на старых цисках перевести его в так называемый «быстрый» режим, команда spanning-tree mode rapid-pvst. На новых цисках это делать не надо, это и так по умолчанию есть, но на экзамене предполагается, что эту команду вы должны будете примерно знать. Детальный рассказ про Spanning Tree, как уже было сказано, будет на курсе CCNA 2 и ещё более детальный на курсе по свитчингу. Это всё,

что в нашем курсе про Spanning Tree есть. Это всё, что касалось безопасности. Я предлагаю на этом с Ethernet закончить и перейти к следующей теме.