Безопасность (часть 1)

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

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

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

мака всегда одни и те же маки указываются мак адрес отправителя естественно мак адрес получать или не кастовой того кого надо но вы вы никаким образом на свече не обязуетесь обрабатывать кадры только из под этого мак пришедшие из под вот определенного порта может быть такое что атакующий возьмет и начнет на вас посылать кадры из-под разных мак афф о будет посылать мусорные данные или будет послать какие-то полезные данные и действительно до того адреса которому он хочет посылать данные но он будет проставлять левые mac адреса левые mac адреса значит совсем совсем левые но то есть он просто будет допустим рандомным образом брать и говорить вот этот кадр и отправляй из под мака 00 000�arin вот этот из под бака 00 00 но 002 и так вот мелкие кадры он будет посылать много-много таких кадров ему тут чего в В принципе, несложно придумать много кадров, содержащие совершенно любую информацию, допустим, браткастовые, из-под очередного придуманного мака.

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

Давно, это, допустим, одну десятую секунду назад пришел кадр, но все левые кадры пришли быстрее. Следовательно, мы должны выкинуть легитимный мак того узла, который на самом деле существует, и забыть про него. И следующие кадры, которые будут идти на легитимный мак, будут Unicast Flatic. Атакующий тем самым сможет, кстати, услышать, что будет передаваться в сторону атакуемого мака. Ну, то есть все узлы услышат, включая атакующего. Но главное, начнет резко проседать производительность сети, потому что все интерфейсы будут загружены всем трафиком, трафик будет разбрасываться по вообще всем портам, эффективность сети будет резко падать, эффективность коммутации будет резко падать. В общем, неприятная атака, и вы должны будете с ней, конечно, бороться. Вот. Каким образом с ней можно будет бороться? Можно будет сказать вашему коммутатору, что количество мак-адресов или не просто количество,

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

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

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

на котором сидит там, допустим, 10 абонентов, надо будет понимать, что 10 абонентов формируют, ну как минимум, 10 маков. А есть еще, возможно, какие-то другие мак-адреса, которые тоже, возможно, существуют на этом порту, там виртуалки или что-то еще. Поэтому вы всегда должны количество мак-адресов по-хорошему делать с небольшим запасом, если вы используете технологию, которая сравнима с порт секьюрити по механизму действия. То есть вы говорите, допустим, вот если один абонент, а один абонент точно не отправляет кадры с больше, чем 10 разными маками, он в реальности отправляет, скорее всего, все из-под одного мака. Но может быть ситуация, когда там будет 2, 3, 4, 5. Вот пока там меньше 10, все в порядке. В реальности сильно меньше, но пусть будет просто меньше. Если 10 маков случилось, это точно аномалия. Поэтому вот в этом случае мы точно там предпринимаем какие-то действия. Может быть, выключаем порт целиком. Может быть, допустим, мы можем сделать другое. Мы можем сказать, мы блокируем только те мак-адреса, которые вызвали нарушение безопасности.

Вот мы сказали, допустим, на порту может быть не более 10 маков, а если приходят кадры новые, то это будет нарушение безопасности. Такие кадры коммутировать нельзя, но те кадры, которые приходят все еще из-под старых маков, которые не вызывали в свое время нарушение безопасности, мы их продолжаем коммутировать. Соответственно, это будет влияние на механизм коммутации. То есть вы должны понимать, что это все будет завязано на движок коммутации, и все это дело будет происходить в момент принятия коммутационного решения. Вы смотрите на то, вызвал мак проблему или нет. Если кадр вызвал проблему, то коммутация должна принять решение. Сбрасываем такой кадр. Физически на коммутаторах на самом деле происходит одновременно несколько сразу механизмов проверки и, скажем, классификации, определения того, что за кадр. Одновременно выполняется процедура коммутации. То есть одновременно вы мак-адрес от приходящего кадра засовываете в матрицу коммутации, которая будет проверять его по таблице мак-адресов.

Одновременно вы этот же кадр, ну или информацию об этом кадре засовываете в какие-то другие движки. То есть эти движки работают параллельно, на друга они не завязаны, все это дело параллельно прекрасно. Мак-адрес отдаете на матрицу коммутации, мак-адрес отдаете на отдельный движок Port Security, отдельно кадр, допустим, отдаете на движок Quality of Service, который говорит, этот кадр надо будет отнести к вот такому-то классу трафика, и класс трафика должен отнестись, допустим, к приоритетной очереди. Вот все эти движки, они работают параллельно, и если все движки сказали, да, можно коммутировать кадр, можно коммутировать его непросто, а вот с такими-то свойствами, допустим, через приоритетную очередь его пропустить, то вы кадр коммутируете. Если матрица коммутации сказала, мы не знаем, куда этот кадр одевать, или, допустим, мы знаем, куда этот кадр одевать, причем у меня написано, что кадры на этот маг надо сбрасывать, ну, потому что этот кадр, приходящий из-под вот этого порта, они должны быть отправлены обратно в этот же порт, и, следовательно, мы не можем этот кадр прокоммутировать, потому что вот мы никогда не отправляем кадры обратно в ту же самую дырку,

из которой они пришли. Либо может быть такое, что, допустим, какой-то другой движок, ну, типа того же самого порт Securities сказал, что этот кадр не надо коммутировать. Тогда не важно, что сказала матрица коммутации, не важно, что сказал Quality of Service. Суммарное решение, мы этот кадр не коммутируем. И вы можете в случае, если у вас случается нарушение безопасности, вот, допустим, для примера порт Securities, вы можете сказать, мы не коммутируем вообще никакие кадры, или мы не коммутируем только те кадры, которые пришли из-под тех маков, которые не попали под правило не больше 10 маков на порт. Вот вы сказали 10 маков на порт, можно. Первые 10 маков, которые пришли на порту, мы их пометили зелененьким, и все кадры из-под этих мак-адресов могут быть прокоммутированы. А все остальные, которые приходят, новые, они просто не коммутируются и проблем не вызывают в этом случае. Технология вида порт Securities, да, там она проще всего закрывает вашу таблицу коммутации от атаки на переполнение маков.

Есть и другие варианты. То есть можно использовать какие-то другие технологии, которые в качестве побочного решения будут защищать ваш свитч от переполнения. Тот же самый 802.1X, простите, он тоже так или иначе косвенно защищает вас от переполнения маков. Но вот порт Securities, она дубовая, она надежная, и до тех пор, пока вы не занимаетесь всякими странными вещами вида белого списка мак-адресов на порту, она надежно вас защищает от всего, что именно может быть устроено на вас, неприятного с помощью отправки совершенно левых кадров из-под вашего порта. То, что выключить его, но опять же надо понимать, что если вы его выключаете, то вы должны включить что-то взамен. Ну то есть тот же самый 802.1X, да, он сходным образом работает, только он намного сложнее работает. И он требует поддержки со стороны пользователя. То есть на вашем пользователе должен быть процесс 802.1X-супликанта, который не всегда, не везде будет доступен.

Если вы взяли, купили какой-нибудь принт-сервер и хотите принтер подключить к сети, ну вот с вероятностью близкой к единице на принт-сервере 802.1X не будет работать. Поэтому на таком порту, который служебный, на котором нету пользователя, но который тем не менее дает вам право подключения к сети, вы можете включить порт security, он там не повредит, и тем самым повысить уровень вашей безопасности. Защититься, например, от сценария вида пришел к вам злодейский злодей, вытащил порт принтера, воткнулся вместо него своим ноутбуком, прописал тот же, допустим, Mac, или не прописывал тот же Mac, и нафигачил вам левых Mac в таблицу коммутации, и тем самым устроил переполнение. Да, то есть вы должны будете понимать, в каких случаях вы можете использовать мудрые технологии, в каких случаях можно использовать какие-то простые, дешевые и абсолютно дубловые тупые методы, которые тем не менее дают нужный результат.

Вполне себе это неплохая технология, которую можно будет использовать. Если говорить про цисковскую именно порт security, циска, когда рассказывает про эту технологию, она делает упор не на то, что это технология защиты от переполнения таблицы Mac-адресов, а на то, что это технология защиты доступа к сети, что это действительно самый простой и самый дешевый способ сказать, что те, кто, в общем, имеют право подключаться к сети, тех мы будем коммутировать, а тех, кто не имеет право подключаться к сети, тех мы коммутировать не будем. И заключается это в следующем, что вы на каждом порту прописываете белый список Mac-адресов, которые имеют право присылать вам кадры. И на самом деле физически это будет выглядеть так, что вы говорите, на этом порту не более одного MAC-адреса может быть, и рядышком прописываете, что тот, который может быть, он вот такой вот. То есть вы одновременно и ограничения по количеству настраиваете, и говорите, что вот это вот самое количество будет заполнено не теми MAC-адресами,

которые в кадрах будут приходить в качестве source-адреса, а вот явно заданный список. Если вы скажете, что, допустим, вот у нас белый список состоит из одного адреса, а максимальное количество два адреса, то тогда из двух адресов, которые может быть на порту, один сразу заполняется, а второй может быть тем, который придет в MAC-адрес источника на порту. Да, действительно, если злодей у себя пропишет такой же MAC-адрес, как у принтера, порт-секьюрити в этой ситуации не спасет. MAC-адрес прописывается очень легко, и Local Administrative Adress прописать на любой железке не составляет вообще никаких проблем. Поэтому порт-секьюрити в таком сценарии, как его описывает Cisco в своих слайдах, она совершенно не спасает ни от чего. То есть слишком легко ее обойти именно для того, чтобы получить доступ к сети, неавторизованному устройству, если единственное, с помощью чего вы защищаетесь, это защита с помощью белого списка MAC-адресов. И аксесс-листы на самом деле могут не спасти. То есть чем вас аксесс-лист спасет? Если вы поменяете MAC-адрес, поменяете IP-шник на тот же самый, который был у принтера,

покажете, ну разве только что, кто куда может ходить, что IP-шник принтера не может выходить в интернет. Ну да, но все равно кто-то же к IP-шнику принтера будет иметь доступ. Вот тогда вы к узлам, которые имеют доступ к принтеру, получите, соответственно, обратный канал, тоже рабочий, что злоумышленник может взять, подключиться в порт принтера, поменять MAC-адрес на принтера, поменять IP-шник на принтера и похакать ваших пользователей. То есть аксесс-лист тоже в этой ситуации не спасет. Если говорить про то, что борьба должна быть с неавторизованным доступом, тогда лучше использовать 802.1x. В этом случае, как я уже говорил, работать оно будет примерно следующим образом. У вас есть свитч, на этом свитче есть физический порт. На этом физическом порту, когда вы втыкаетесь физически в этот самый порт, вы можете посылать нолики-единечки, вы можете посылать вольты, какие хотите в этот порт, но свитч сидит на попе ровно и ничего не коммутирует. Он говорит, этот порт не авторизован. То есть этот порт присылает какие-то биты, какие-то вольты присылает, импульсы.

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

Кадрик этот ловится, и в ответ посылается, ну очень условно говоря, в ответ посылается какая-то ваша идентификационная информация, например, ваш логин и пароль какой-нибудь, либо, например, посылается ваш сертификат, ну опять же условно, там физически, естественно, не сертификат посылается, там приходит вам челлендж, и вы шифруете своим открытым ключом, этим челлендж, отправляете в ответ, ну в общем, здесь уже не суть важна. Смысл именно такой, что вы каким-то образом подтверждаете, что вы это вы. И вот этот вот процесс подтверждения того, что вы это вы, это не штатная фича Ethernet, это какой-то дополнительный костыль, который на вас должен работать и на свитче должен работать. Свитч после того, как он видит подтверждение того, что вы действительно это вы, он его, как правило, сам не расковыривает, он его прямо в неизменном виде отсылает в сторону радиус сервера. Радиус сервер говорит, да, я вижу, тут пришел логин и пароль, и в этом логине написано, что это Вася, пароль 123, я проверил, это действительно, у Васи есть пароль,

это действительно пароль 123, и более того, у Васи есть право на доступ к сети Ethernet. Я авторизую доступ к сети Ethernet, ты можешь Васю пустить. То есть процедура аутентификации показала, что Вася это Вася, процедура авторизации со стороны радиус сервера говорит, что Васю можно пустить в сеть. Да, далее свитч начинает Васины кадры пропускать в сеть. То есть после того, как порт авторизовался, вы говорите, да, Вася действительно показал, что он это он, Вася предъявил соответствующие учетные данные, нам авторизовали операцию доступа к сети со стороны радиус сервера, но я при этом запоминаю, что Вася это не просто Вася, Вася авторизовался, сказав, что вот у него вот такой вот мак. И кадры из-под его мака начинают дальше коммутироваться. Здесь начинаются аспекты, вы можете по-разному сказать, что должен свитч делать. Можно сказать, любые кадры на физическом порту авторизованы, либо сказать, только из определенного мака кадры будут авторизованы.

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

или, скажем, даже более общо, кадры из-под неправильных маков, принадлежащих неправильным железкам, или, скажем, не принадлежащих правильным железкам, не имеют права коммутироваться в сети. Вот если вы захотите, вы можете 802.1x развернуть. Да, для этого потребуется либо радиус сервер, либо так как с плюс сервер, либо какой-нибудь там диаметр, если вы эстет, но, тем не менее, все равно это все достаточно такая большая тяжелая операция. Да, может быть, кто-то, кто скажет, да, что там на 5 минут на скриптах все это сделать. Нет, это не 5 минут на скриптах. Для того, чтобы это все сделать правильно, задокументировать правильно, это совсем не 5 минут. Там одной документации будет страниц на 10. Есть люди, которые говорят, да что там, блин, двустороннее ТЛС поднять на серверы банка, этого самого онлайн-банка. Нет, это все чуть более сложно, на самом деле, чем взять и повключать соответствующую фичу на железе. Для того, чтобы это все правильно работало, гарантированно выполняя свои задачи

и было хорошо задокументировано, это чуточку подольше, чуточку побольше сил нужно будет. Железки с диаметром, ну, я, скажем, не видел промышленной реализации диаметра, потому что радиус банальный, всех устраивает. Задачи, которые требовали бы диаметра, мне пока не приходилось видеть. А так, ради интереса, ну, да, радиус, радиус, в принципе, часто где используется, и для Wi-Fi в том числе. Если вы будете работать в какой-нибудь компании, которая, ну, сколько-нибудь серьезно относится к IT, вам радиус, ну, обязательно понадобится. По-любому. Было норм, ну, да. Так, если вы это сделали именно для цели чисто потестировать технологию, это круто, то есть это хорошо. Сказать, что прям любая домашняя сеть обязательно требует радиус? Нет, не требует. Если говорить про Wi-Fi, Wi-Fi чаще всего реализуется с помощью пришарятки

в маленьких домашних сетях. То есть когда вы приходите, говорите пароль, и вас система пускает. Пароль это PSK, пришарятки. Если говорить, соответственно, про большую компанию, там пришарятки не работает, потому что если кому-то вы одному сказали, то все остальные сотрудники того человека, который знает пароль, тоже получается, ну, как бы практически гарантированно. Тот же сам пароль знают и получает доступ к сети. Если вдруг вы, соответственно, берете и увольняете какого-то сотрудника, вам потребуется сменить пароль и рассказать всем новым, всем оставшимся в организации сотрудникам, чтобы пароль на Wi-Fi сменился. Поэтому в крупных организациях Wi-Fi с помощью пришарятки не делается, потому что это просто банально неудобно. А вот, да, аутентифицироваться с помощью логина и пароля, причем логин и пароль у каждого индивидуальный, и он, естественно, может быть выключен, доступ через логин и пароль для конкретного пользователя, через, допустим, Active Directory, это намного более штука удобная.

Так, па-па-па-па-пам. Вот, ну да, в любом случае оба варианта, что с Port Security, что с 802.1x, они прекрасно друг друга дополняют, то есть никто не обязывает вас на всех портах 802.1x поднимать. Для того, чтобы 802.1x работал, вам понадобится обязательно субликант. Субликанта может не быть на конкретной железке. То есть print server пример такой железки, где субликанта может не быть. Поэтому, если железка поддерживает 802.1x, если вы знаете, что на конкретном порту есть железка, которая точно его поддерживает, и не может быть ситуации, когда на порту появится кто-то, кто его не поддерживает, тогда вы на порту просто включаете 802.1x, и все вас устраивает. Если вы знаете, что за конкретным портом сидит железка, которая точно и гарантированно не имеет субликанта живого рабочего, Тогда вы можете закрыть конкретно этот порт, порт security, и он тоже будет неплохо работать. Захотите, пропишите белый список MAC-адресов, если вы точно знаете, что на 17 порту стоит принт-сервер.

Вот вы очень редко будете брать и втыкаться в этот самый порт какими-то другими железками. Пропишите просто один MAC, скажите, вот он, один MAC может быть на этом порту, это ровно MAC принт-сервера. Ни при каких обстоятельствах там другие MAC не будут. Тем самым вы закроете какие-то возможные атаки. Но возможно когда-нибудь потом там появится пользователь, он воткнется в этот порт и будет переживать, что у него ничего не работает, а вы будете бегать, забудете, что там порт security есть, и у вас просто ничего не будет работать, и вы будете опять бегать кругами. Если вы не хотите так бегать кругами, пропишите просто 10 адресов, неважно каких, по крайней мере от переполнения MAC вы будете защищены. Так. Да. Вторая проблема, которая может быть в абсолютно любой коммутируемой сети, это дублирующиеся MAC адреса. Это, соответственно, ситуация вида. У нас есть узел, который имеет MAC определенный, и есть другой какой-то узел, который отправляет данные из-под этого MAC.

Это может быть ситуация вида атакующий специально хочет отправить кадр из-под существующего MAC, или ситуация вида админ прошляпил настройку правильной сети и сделал так, что у вас просто случилось два узла с одинаковыми MAC. То есть, такой достаточно типичный сценарий, это вы берете компьютер, у которого драйвер сетевой карты хранит MAC адрес на жестком диске. То есть, у него нет как такового burn-in адреса, у него любой адрес будет locally administered. Есть такие сетевые карты. То есть, я такие сетевые карты видел, что вы берете, устанавливаете операционную систему на компьютере, а сетевая карточка, которая прошита на материнке, она настолько тупая, что у нее нету своей микросхемы, на которой хранится MAC. Она этот MAC генерит на лету, по предсказуемому правилу, и записывает на жесткий диск. Вот если, допустим, с такого компьютера взять, снять образ и потом его разлить на другую машину, то получится следующая штука.

Получится, что у вас дублируются MAC адреса. То есть, вы взяли старый компьютер, оставили живой новый компьютер, с которого сняли образ, разлили на него копию жесткого диска старого. И получается, что тот самый MAC адрес, который хранится на жестком диске в свойствах драйвера, он как-то одинаковый. Ситуация исключительно редкая. Большинство сетевых карт хранят именно на своей микросхеме свой MAC адрес, прошитый на заводе, и операционная система его никак не модифицирует. Но вот такое может быть. Ну или может быть такое, что вам не повезло, вы купили две железки одного производителя. И вообще-то говоря, если вы помните, как MAC адрес на заводе прошивается, там левая половина, левые 24 бита, они фиксированы. И у всех устройств в пределах одной серии одного и того же производителя они будут одинаковые. А правые 24 бита, они будут разные. Ну и соответственно 24 бита это не так много, как может показаться.

Примерно 10 в 10 степени, ну там 10 в 8 степени, то есть приблизительно миллиард, плюс-минус километр. Если вы возьмете и посчитаете, что какова вероятность того, что у двух совершенно произвольных железок, купленных из одной серии, будет вероятность того, что вот MAC адреса будут одинаковые, она кажется пусть и маленькой, но не нулевой. Вот. То есть она, да, она не будет нулевой. Если вы будете покупать две железки, да, вот она совсем маленькая. Если вы купите, допустим, тысячу железок, вероятность того, что из миллиона устройств в одной партии, из 10 миллионов выпущенных, вот тысяча железок, которые к вам приедут, будут содержать две железки с одинаковым MAC, она как бы есть. Да, и получится вот ситуация, то, что у нас здесь на картинке нарисовано, у нас есть два узла, которые отправляют данные из-под одного и того же MAC.

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

Поэтому, если допустим у вас есть злобный хакер в сети, который хочет сделать так, чтобы к нему пришел трафик допустим 1С, а у вас есть бухгалтер, который там 1С запускает. То вы можете относительно легко постоянно шарашить MAC этой самой 1С, браткастами в сеть. И ваша сеть будет перенаправлять кадры этой самой 1С в сторону вас. На слайде какие хасты с одинаковыми MAC? На слайде у нас узел на первой картинке. Узел А отправляет MAC адрес от MAC адреса, в смысле отправляет кадр от MAC адреса компьютера С. А атакующий, С жертва. И соответственно А отправляет допустим браткаст с указанием MAC адреса жертвы в качестве MAC адреса источника. И все свечи, ну на картинке всего один свеч, говорят, мы видим MAC адрес компьютера С сидящий за портом 1. Следующий, второй шаг.

Узел Б хочет отправить данные узлу С. Вот у нас, как это происходит. У нас первый шаг. А отправляет данные из-под MAC адреса С. Свеч записывает, С сидит за первым портом. И следующий шаг. Б отправляет в сторону С. Свеч говорит, окей, я знаю, что С сидит за первым портом. Я отправляю С на первый порт эти самые данные. С в этом случае вообще кадр никакой не получает. Хотя она легитимный получатель. Но из-за того, что логика коммутации использует достаточно небезопасный способ пополнения таблицы коммутации, у вас можно перенаправить трафик жертвы на себя. Без особых проблем. Единственный способ от этого защититься, это не пускать кадры из-под неверных MAC в сеть. То есть это либо порт security с белым списком, либо 802.1x. Это как раз дублирующиеся MAC. Если вы возьмете и скажете, что у нас у MAC адрес вот этого узла и MAC адрес вот этого узла одинаковые, картинка не изменится. То есть что А, допустим, отправляет данные из-под своего дублирующегося MAC, что С.

Главное, что Switch в любом случае записывает, что только один порт будет реально обладать MAC адресом С. Вот кто из них последний прислал данные, какие-то кадры, тот и молодец. Когда в следующий раз придет на этот самый дублирующийся MAC какой-то кадр, этот кадр будет отправлен в сторону ровно одного порта. В сторону того самого порта, из-под которого кадр приходил последним из-под нужного MAC. Да, то есть дублированные MAC на А и С могут быть умышленно продублированы, когда А умышленно устраивает атаку на С. Или неумышленно, когда просто вы случайно взяли, добавили два компьютера с одинаковыми MAC'ами. Результат один и тот же. Например, один из узлов с действительно легитимным MAC'ом может не получить кадры, которые идут на этот MAC. И да, с этим никак невозможно бороться, кроме как не пускать кадры из-под неправильных MAC'ов. А для того, чтобы не пускать кадры из-под неправильных MAC'ов, вы должны знать, какие кадры неправильные и какие правильные.

Это сработает только в случае либо отсутствия порт security и белого списка адресов. Потому что может быть такое, что вы нашли просто порт, на котором список адресов пустой. И вы сказали, что на этом порту может быть 10 MAC'ов. Вот вы нашли порт, на котором ни одного MAC'а пока нет. И вы взяли, воткнулись и отправили первый кадр с криками «Я компьютер бухгалтерии». И все. Все свитчи теперь знают, что компьютер бухгалтерии – это вы, на вас присылают данные. То есть порт security в просто режиме защиты от переполнения таблицы MAC'а адресов от этой атаки не спасает. Порт security в режиме белого списка, когда известен точно список MAC'а адресов, которые на порту есть, и никто больше на этом порту не разрешен, от этой атаки позволят спастись. Вот именно от этой. Но, соответственно, порт security в режиме белого списка – это очень-очень неудобно. Это технология, которую реально использовать не нужно. Она катастрофически административно сложная.

Поэтому в ситуации, если вы хотите защититься от вот этой атаки, от подмены MAC'а адреса фактически, или от того, что у вас будут дублирующиеся MAC'а адреса, вы должны будете использовать 802.1x. Если это просто совпадение, при прочих равных трафик будет идти на оба узла в среднем, если у вас оба узла примерно одинаково отправляют трафик с одинаковой частотой. Может быть такое, что, допустим, один почаще отправляет, второй порежет. Тогда вот на того, кто почаще отправляет, трафика будет идти больше. Если это атака, да, атакующий, скорее всего, будет херачить кадрами из-под левого MAC'а постоянно. И вы постоянно будете видеть в таблице коммутации указание, что MAC'а атакуемого сидит за портом атакующего. И тогда все кадры, приходящие на MAC'а адрес атакуемого жертвы, они будут идти на порт атакующего. При прочих равных, да. То есть, если у вас это случайная ситуация, то, скорее всего, они примерно будут одинаково параллелиться. Вот как я и говорил, ситуация вида дублирующейся MAC'ов, она траблшутится довольно тяжело,

потому что очень нерегулярное явление, то, что в какой-то момент порт работает, а в какой-то момент он перестает работать, а потом снова работает, а потом снова перестает. То есть, вы там пытаетесь потраблшутить IP, пытаетесь пинги запустить. Там два пинга проходят, три пинга не проходят, два пинга проходят, три пинга не проходят. Я когда с этим делом в первый раз столкнулся, я, наверное, с полчаса гломал голову, потому что там было оборудование, которое неуправляемое свечи, и не было возможности взять, зайти на них и посмотреть, что за фигня. Я смотрю пинги, вот то есть, то нет. Думаю, может, это самый порт дохлый. Взял, переткнул, патч-корд длинный подключил, просто напрямки в порт свеча, без всяких промежуточных розеток в стене, там чего-то еще. Та же самая картина. Я думаю, может, интерфейс дохлый. Да, что-то с интерфейсом я тогда... У меня не было возможности взять, переткнуть сетевую карту. Ну, в общем, я так посмотрел, вроде воткнул в другое место, вроде оно как-то там работает, напрямки в другой компьютер воткнул, не интерфейс, вроде живой.

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

У вас абонент прыгает на другой порт, надо взять, со старого порта его стереть, на новый порт его добавить. У вас там свитч меняется, надо вообще все Mac'и поменять. То есть, слишком тяжело это все дается, и поддерживать это в актуальном состоянии реально очень тяжело. Как всегда, работа администратора, она, ей свойственно порождать ошибки, поэтому если вы где-то там что-то накосячите, у вас порт внезапно выключится, все будут очень недовольны. И учитывая, что вероятность возникновения ошибки высокая, вероятность того, что все будут недовольны, она тоже будет высокая. Поэтому намного интереснее будет, если вы будете использовать какую-то технологию, которая будет проверять подлинность Mac автоматически. То есть, вот 802.1x это прекрасная технология, которая, тем не менее, достаточно сложная, которая предполагает, что вы хорошо понимаете, что происходит при коммутации, и которая предполагает, что у вас есть отдельный сервер, который умеет сообщать, да или нет, когда вы предоставляете MAC адрес и пароль на анализ. Вот она будет говорить,

да, окей, можно, или нет, окей, нет, не окей, нельзя. Вопросы того, как настраивать сервер, для того, чтобы 802.1x работал, ну, он выходит за рамки практически любого курса, кроме CCNP Security, если говорить про цисковское образование, там вот есть отдельный рассказ про то, как ISE настраивать. такой, типа, цисковский аналог радиус сервера, он и радиус, и так, и все на свете одновременно. Вот там можно сказать, как именно этот самый сервер должен принимать решение о том, можно или нельзя пускать определенного пользователя с определенным MAC, с определенным логином, паролем, или с определенным сертификатом в сеть. Для того, чтобы 802.1x работала, требуется поддержка и на клиенте, и его тоже. Ну, как правило, современная операционная система для более-менее серьезных компьютеров, то есть, там, Windows, начиная с Windows XP, Mac OS и прочее, они все это дело поддерживают, то есть, то, что в предприятии может быть использовано, оно, скорее всего,

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

которые имеют 802.1x-супликант, и везде поголовно этот самый 802.1x используется. Если какие-то узлы не умеют поддерживать 802.1x, то они могут жить, допустим, в отдельном Вилане, и они могут быть защищены с помощью Port Security. И с помощью аксесс-листов дополнительно вы скажете, что вот из этого Вилана куда-то там еще не просто кадры не обрабатывать, а IP-пакеты, которые внутри будут содержаться, они могут идти только в очень определенном направлении. Такие маленькие железочки, как правило, вы можете их все описать, взаимодействие, которым требуется, тоже можно описать, и аксесс-листами все взаимодействие таких железочек закрыть. Опять же, для того, чтобы это все сделать, вы должны будете правильно понимать политику безопасности. Все действия, связанные с безопасностью, должны плясать от бумажки. То есть, не просто мне показалось, что было бы здорово запретить print-серверу вообще куда-либо ходить, кроме вот компьютера А, А, А, А, А, А, А, А, Нет, у вас должна быть бумага, в которой написано, что есть компьютеры,

которые там представились с помощью 802.1x, мы их пускаем туда-то, туда-то и туда-то, все остальные места запрещают. Если есть железки, которые мы не можем проверить с помощью 802.1x, мы должны их проверить с помощью порт security. В этом случае есть правило доступа к порту, есть правило работы с таким портом, и мы будем, соответственно, с такими железками работать как-то по-другому, и, соответственно, будем ограничивать такие железки намного сильнее, чем 802.1x. То есть, позволенным таким железкам будет еще меньше. Сначала всегда пишите бумагу, почему оно должно быть так сделано, как правильно могло бы быть сделано с этой технологией, а потом уже реализуйте это, и если у вас получилось все реализовать по бумажке, то хорошо, если у вас где-то что-то не получилось, вы в особенностях реализации в конкретном вашем проекте будете писать, что вот по-хорошему надо было сделать так, но пришлось отклониться от проекта, потому что вот так.

Опять же, да, никаких рыб стандартных таких документов не бывает, потому что это все завязано очень сильно на конкретную сеть, поэтому просто пишите, что вот в нашем случае нужно то-то, то-то и то-то, предлагаемая технология реализации, такая-то, такая-то, такая-то, попробовали реализовать, получилось вот с оговорками такими, такими, такими. Да. И понимаете, если не получилось очень сильно, то это нарушение требований изначального документа, то, следовательно, документ был изначально неправильный, следовательно, нужно его поменять. Ну, оформляете change request, и дальше с этим change request что-то делаете. Да, как-то так. Наконец, петля. Вот, про петли проговорим завтра, потому что про них хочется рассказать подробно, и хочется иметь чуть побольше времени на рассказ про них, рассказать про какие-то технологии, которые есть, скажем, популярные для защиты от петель, непопулярные для защиты от петель,

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