Безопасность в сетях Cisco (начало)

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

либо это может быть 1С. И зарплату вам платят именно за то, чтобы компания получала эту самую услугу. Если вдруг случится что-то, что повлияет на доступность этой услуги, то, соответственно, компания будет терять деньги, скорее всего. И безопасность в широком смысле — это как раз как сделать так, чтобы компания не потеряла деньги. Это не обязательно злобный злоумышленник, который подкрадывается тёмной ночью, с монтировкой в руках, как защититься от него. Это в широком смысле — как сделать так, чтобы компания не теряла деньги на IT. Всегда, когда мы говорим про безопасность, мы должны будем понимать, что могут произойти определённые события, которые повлекут за собой потерю денег, и мы не можем, как правило, сделать так, чтобы такие события в принципе не происходили. В определённых ситуациях мы это можем сделать, но чаще всего мы это сделать не можем. Что мы сделать можем? Мы можем снизить вероятность возникновения определённых событий, или мы можем её не снижать, но можем с такими событиями как-то иначе бороться.

В любом случае мы должны будем определить, что конкретно может пойти не так. Выделить риски, с которыми мы работаем. После того как мы выделили эти самые риски, выписали их, условно говоря, на бумажке, дальше мы должны будем с этими рисками что-то сделать. Каждый риск будет состоять из двух составляющих. Если хотя бы одной из этих составляющих нет, то риска на самом деле тоже нет. Первая составляющая — это уязвимость. Это что в вашей системе позволяет чему-нибудь пойти не так. Давайте сначала на каком-то более жизненном примере, а потом перейдём к IT. Если у вас есть танк, у нас есть риск того, что этот танк подобьют. Что будет являться уязвимостью, что будет являться угрозой? Уязвимостью будет являться то, что броня у этого танка достаточно слабенькая, и, допустим, противотанковый снаряд её может пробить.

А что такое угроза? Угроза — это то, что кто-то может этим самым противотанковым снарядом выстрелить в танк, и тем самым наш танк подобьётся. Если хотя бы одного из этих пунктов нет, либо наша броня достаточно толстая для того, чтобы её не пробивал никакой снаряд, либо у нас абсолютно исключена вероятность того, что кто-то в этот танк будет стрелять, то риска того, что наш танк подобьют, нет. Та же самая история и с IT. Если у нас есть что-то, чего мы боимся гипотетически, то мы должны будем понять, что является уязвимостью, что является угрозой. Например, мы боимся того, что наши серверы возьмёт и затопит вода, и мы потеряем данные. Что является уязвимостью? Уязвимостью является, например, то, что наша серверная стойка стоит под батареей, если эту батарею прорвёт, то, соответственно, на серверы прольётся вода, которая вызовет короткое замыкание, и у нас что-то произойдёт с самими серверами. Угроза — это, соответственно, то, что саму батарею может прорвать.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Он лишь раскладывает входящие сущности на две кучки. Вы даете разные сущности, и он вам их раскладывает. В одну кучку те, которые вы сказали да, в другую кучку те, на которые вы сказали нет. Почему изначально вот эти вот термины были выбраны? Дело в том, что самые-самые первые реализации вот этого механизма списков контроля доступа использовалась для простейшей пакетной фильтрации. И, соответственно, первые пакеты, первая пакетная фильтрация, которая в ЦИСке сделана была, она была сделана на интерфейсе, и вы с помощью такой пакетной фильтрации могли пропустить некоторые пакеты, если они вам нравились, или не пропустить некоторые пакеты через интерфейс, если они вам не нравились. Ну и, как следствие, там permit и deny термины имели смысл. После чего этот механизм стал намного более мощным, намного более расширенным по сравнению с обычной пакетной фильтрацией, и фактически списки контроля доступа отделились от механизма фильтрации. У вас есть отдельный

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

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

объект, с которым вы будете сравнивать некий объект. У нас, соответственно, есть что-то, что к нам пришло, и мы должны будем ответить на вопрос «да» или «нет». Соответственно, вот наш классификатор, пытаюсь нарисовать лупу Шерлока Холмса, который в эту лупу смотрит. Вот, ну, какой-то такой Шерлок Холмс, да, и вот он должен сказать либо «да», либо «нет». Вот к нам пришел объект, и мы «да» или «нет» можем выдать в зависимости от того, похож ли этот объект на некоторые другие объекты с некоторыми известными нам свойствами. Соответственно, в каждой строке мы говорим «похож ли этот объект на слона?» Ну, и дальше мы должны сказать, в каком смысле похож на слона. Ну, например, такой же ли у него хобот, как у слона? Или, например, такой же серый этот объект,

как и слон? Или, похож ли этот объект своим весом, как на слона? То есть, такой же ли у него вес, как у слона? Поэтому у нас в каждой строке должен быть эталон, с которым ведется сравнение. Вот слон, например, да, это объект, некий объект, с которым мы сравниваем. Второй элемент, который должен быть в каждой строке, это критерий сравнения. В какой части с эталоном должен совпадать некий объект, чтобы мы поняли, что он похож? Например, вот мы говорим, такой же хобот у этого объекта, как у слона. Вот критерий сравнения в этом случае будет, соответственно, хобот. Или вес, если мы говорим, такой же тяжелый этот объект, как слон. Ну, значит, вес будет критерием сравнения. И если вдруг мы обнаружили, что у нас по заданному критерию объект, который мы изучаем, похож на эталон, то мы выносим некий вердикт. И вердикт, если мы определили, что у нас есть совпадение, что наш изучаемый объект

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

в частности, своей серостью. Второй вопрос. Оно так же хорошо плавает, как дельфин? Мы говорим нет, оно не так же хорошо плавает, как дельфин. Оно не похоже на дельфина по критерию плавания. Третья строчка. У него столько же хвостов, как у мыши? Мы говорим да, вот по количеству хвостов оно похоже на мышь. И у тигра один хвост, и у мыши один хвост. Поэтому у нас в третьей строчке есть совпадение. Все остальные строчки, которые у нас, возможно, есть, мы даже не проверяем, то есть нам они неинтересны. Мы с известным эталоном по известному критерию нашли совпадение, и мы выносим вердикт, который написан в этой строчке. Здесь важно именно понять, что мы проверяем сначала первую строчку, ищем совпадение. Если есть совпадение, остальные уже не проверяем. Если совпадения нет, переходим ко второй. Опять же, ищем совпадение во второй. Если есть, останавливаемся. Дальше уже остальное не проверяем. Если совпадения нет, переходим к следующей. Дальше вы мне можете сказать, слушай, какой детский сад развел мышки, кошки, тигры, слоны.

Давай пройти, да? И вот мы переходим уже плавненько к тем объектам, которые мы можем действительно проверять в цисках. Если мы говорим про циски, в первую очередь access control list изначально были придуманы для сравнения IPv4. объектов. Что за объекты в IPv4? Пакеты. И для того, чтобы сравнивать пакеты с некоторыми эталонными вещами, в цисках изначально использовалась ровно одна вещь. То есть у нас можно было сравнивать только один IP-адрес в каждом пакете. И этот IP-адрес можно было брать только IP-шник источника. То есть у нас пакетная фильтрация выполнялась только по IP-шнику источника. Потом этот механизм допилили, и он стал намного более продвинутым. Но изначально оно могло делать именно так. То есть у нас объекты, которые приходили к нам на изучение, это IP-адрес. Соответственно, с чем можно IP-адрес сравнить? Ну, с другим IP-адресом. Поэтому эталон у нас тоже был IP-шник.

И как два IP-шника можно сравнивать? Ну, понятное дело, по битово. То есть у нас IP-шник один состоит из отдельных битиков, и IP-шник другой состоит из отдельных битиков. И когда нас интересует совпадение по какому-то критерию этих самых IP-шников, мы должны будем просто сказать, какие конкретно биты мы должны сравнить, чтобы сказать, один IP-шник похож на другой. И для того, чтобы сравнивать IP-адреса, у нас будет использоваться новая вещь, новая концепция. Это 32-битовая маска. Тут вы мне можете сказать, слушай, как-то не похоже на то, что 32-битовая маска — это что-то новое. Мы уже видели 32-битовые маски. Они у нас использовались для того, чтобы определить, что два IP-шника относятся к одной сети. И тут вы будете абсолютно правы. Действительно, в IP-мире маски определяют, совпадают ли IP-шники по левой части или нет. Но для access control list нужно было, по крайней мере, по задумке создателей, разрешать сравнивать между собой IP-адреса не только по начальным битам.

Гипотетически, сказали разработчики, может быть, кому-то интересно сравнивать IP-шники по совершенно произвольным битам. Например, нас интересует, чтобы первый и последний октет у изучаемого нами IP-шника совпадал с первым и последним октетом эталонного адреса. А второй и третий октет могут быть любыми. С помощью классических масок такое сделать нельзя. Это в качестве примера. Мы должны будем сказать, что у нас есть эталонный IP-шник, он 10.0.0.10. И все IP-шники, которые начинаются на десятку и заканчиваются на десятку, мы должны на них сказать «да». Не важно, что там в серединке. На 10.10.10.10 мы скажем «да», у него начинается на десятку и заканчивается на десятку. На 10.20.20.10 мы тоже скажем «да», у него тоже начинается и заканчивается на десятку. Но на 10.10.10.20 мы должны будем сказать «нет», потому что по заданному критерию сравнения первый и последний октет наш изучаемый образец на эталон не похож.

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

что некоторый адрес совпадает по некоторым начальным битам с некоторым эталоном, например, у нас есть адрес эталонный 192.168.0.0, и мы хотим сказать, что все адреса, которые начинаются на 192.168, мы на них должны сказать, допустим, «да». Если бы мы использовали нормальные прямые маски, мы бы нарисовали маску 255.255.0.0. Эти биты указывали бы на принадлежность к определённой сети. Network ID, левые 16 бит, мы бы указали таким образом. И все узлы, которые находятся в этой сети, они такие же левые биты бы и имели. Но если у нас прямая маска используется, то там, где требуется совпадение, у нас стоят единички. А там, где совпадение не требуется, у нас стоят нолики. А у кривых масок, обратных масок или wildcard масок, логика обратная.

Там, где нам не требуется совпадение, стоит единичка. А там, где требуется — нолик. Поэтому такая маска, которая делает ровно то же самое, что и обычная маска 255.255.0.0, будет задом наперёд смотреться. Она будет 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0. А дальше все единицы. То есть эта маска будет выглядеть как 0.0.255.255. Отсюда и термин «обратная» в русском языке. В английском языке это называется wildcard маска. Термин не совсем понимаю, откуда взялся, но тем не менее — wildcard. Дальше. В IPv6 потом тоже этот механизм зародился. Там уже, к счастью, этих кривых масок нет.

В IPv6 access-листах есть просто сети. Когда мы говорим, что нам нужно определить принадлежность адреса к некоторой сети, там мы используем просто обычные указания на сеть. И сделать отдельно сравнение, допустим, начала и конца IP-шника, середину не проверять, в IPv6 уже нельзя. Это вполне разумное явление, учитывая, что никому в здравом уме это обычно не нужно. Проверять какие-то биты из серединки адреса, но не проверять все остальные из начала. Давайте попробуем посмотреть на конкретном примере, как работают эти самые маски. У нас есть некий эталонный адрес. 00001010 — это число 10. Дальше. 00000000 — это число 0. 00010001. Я так сильно подозреваю, это число 17. И 00000000 — это число 0.

Это эталонный наш IP-шник. 10, 0, 17, 0. Мы хотим, чтобы мы говорили «да» на все IP-шники, которые тоже начинаются на 10, и у которых в третьем октете 17. Но при этом не важно, что содержится во втором и четвёртом октете. Поэтому мы указываем маску. Первый октет нам важен. Мы весь первый октет выставляем в 8 битов нулей. И третий октет нам важен. Мы его выставляем, опять же, в 8 битов нулей. Второй октет и четвёртый октет нам не важны. Мы их выставляем в единицы. И у нас получается 00000000, 11111111, 00000000, 11111111. Вот такая маска. И эта маска будет, если записывать её в привычном IP-шном виде, 0.255.0.255. Если мы указываем такую маску, то мы требуем у изучаемого нами IP-шника совпадения первого и третьего октета с некоторым эталоном. Опять же, отдельная маска, висящая в воздухе,

бессмысленна, так же как в мире IP-сетей. Она имеет смысл только рядышком с чем-то ещё, с тем адресом, с которым производится сравнение. У нас IP-шник 10, 0, 17, 0 как эталон, и критерий сравнения — wildcard-маска 0, 255, 0, 255, они как раз задают указание на то, что мы проверяем у неких образцов совпадение первого октета с десяткой, а третьего октета с семнадцатью. Если мы, допустим, берём на вход, подаём такому классификатору IP-шник 10.1.17.1, он скажет, окей, первый октет десятка, третий октет семнадцать, у нас всё хорошо, у нас есть совпадение. Если там будет 10.17.10.17, мы скажем, нет, у нас совпадения нет, потому что в третьем октете число не семнадцать. Да, у нас два других октета с семнадцатью,

но в том, в котором надо, семнадцати нет. Поэтому по сути своей работает эта штука почти так же, как нормальная маска, но битовое значение для ноликов и единичек в ней перевёрнуто. Ноль там, где требуется совпадение, единица там, где совпадение не требуется. Давайте ещё один пример приведу. У нас есть вот такая хитрая маска. 255, 255, 255, 254. Она состоит из кучи единичек и одного последнего нолика. Есть, опять же, разумное предположение, что если есть такая маска, она должна не просто так в воздухе висеть, она должна записываться рядом с эталоном. И если мы говорим, что у нас есть некий, который мы заранее сейчас ещё пока не знаем, эталон, с которым мы хотим проводить сравнение непонятно чего, что нам на вход подадут. И мы говорим, неважно, какие первые 31 бит будут,

нам интересно только, чтобы 32-й бит совпадал с неким эталоном, то у этого эталонного адреса неважно, какие будут первые 31 бит. Есть рекомендация, которая просто как правило хорошего тона: если вы записываете эталонный адрес, то те биты, которые вам не требуется проверять, вам рекомендуется записывать в нулевом виде. В принципе, всё равно, что вы там напишете. Любой эталонный адрес, у которого любые первые 31 бит будут, он подойдёт здесь. Но учитывая, что мы не требуем совпадения первых 31 бита вообще ни с чем, будет логично, если вы здесь запишете везде нули. И единственный бит, который будет на что-то влиять, это самый последний битик. Здесь мы требуем совпадения с нулём. Такой эталонный адрес 0.0.0.0 с маской 255, 255, 255, 254 будет проверять чётность IP-шника. На чётном IP-шнике он будет говорить, что есть совпадение.

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

для того, чтобы проверить нечётность адреса, чтобы вынести какой-то вердикт для нечётных адресов и не выносить его для чётных. Давайте попробуем разобраться с тем, как определить нечётность адреса. Если у нас есть необходимость сказать либо «да», либо «нет» на нечётные адреса, это значит, что нам нужно проверить самый последний битик, потому что все остальные битики на нечётность не влияют. Поэтому маска останется та же самая, 255, 255, 255, 254. И вся разница будет фактически только в эталоне, потому что раз маска такая же, то что-то же должно отличаться, да? Поэтому, в принципе, уже даже этой информации достаточно для того, чтобы соорудить готовый результат. Все эти битики неважно какие, и единственный битик, в котором мы можем что-то поменять, это здесь поставить единицу. Давайте докажем,

что именно там единица должна стоять. Дело в том, что если мы хотим, чтобы у нас выносился вердикт на нечётные адреса, мы должны требовать совпадения последнего битика адреса, который мы изучаем, с единицей. Поэтому здесь мы вместо нолика должны требовать совпадения с единицей. Тогда у нечётных адресов мы требуем совпадения последнего бита с последним битом эталонного адреса. Маска та же самая, 255, 255, 255, 254, а эталонный IP-шник будет 0.0.0.1. Для некоторых случаев нам будут нужны специальные красивые маски. Первая маска, которая нас будет интересовать, это маска 0.0.0.0. Как видно, она состоит целиком из нулей, поэтому она требует равенства всех битов изучаемого образца

всем битам эталона. И если у вас есть такая маска, то она может записываться в короткой форме: host и дальше пробел, эталонный IP-шник. Если у вас маска не такая, она какая-то кривая, то вам придётся отдельно записывать эталон и отдельно, соответственно, маску. А если у вас маска именно такая, то фактически она говорит, Что да, мы говорим или нет, мы говорим только в случае, если у нас ровно один айпишник идет на вход. Это будет работать только для одного единственного айпишника. Соответственно, если у нас маска произвольная, то будет 0.0.0.1 по маске 255.255.255.254. Пример, который у нас только что был. Мы отдельно записали эталон и отдельно записали маску. Если маска 0.0.0.0, то мы можем записать хост 10.0.0.1. Ровно один айпишник нас будет интересовать.

Если изучаемый образец совпадает с этим айпишником, то мы выносим вердикт либо да, либо нет. Если не совпадает, идем дальше. И еще одна специальная маска — это 255.255.255.255. Понятно, маска из всех нулей — это один единственный айпишник нас интересует, а маска из всех единиц говорит, что можно не сравнивать вообще ни один бит с эталоном. В принципе, неважно, какой образец будет, все равно совпадение есть. Понятное дело, что для такой маски имеет смысл записать эталонный адрес как 0.0.0.0, потому что мы не требуем совпадения вообще ни с чем. И поэтому все биты эталона произвольные. Соответственно, комбинация 0.0.0.0 по маске 255.255.255.255 может быть записана в форме слова any. Не писать эту колбасу, а вместо нее написать просто any. Это экономия калорий.

И для того, чтобы сократить вам жизнь, эти два сокращения сделаны. any, чтобы не писать 0.0.0.0 255.255.255.255. И хост, чтобы не писать 0.0.0.0. В машине все это дело в любом случае преобразуется в одни и те же битовые конструкции. Поэтому такие записи нужны только для человека. Только для того, чтобы человеку было удобно. Исторически, когда-то давным-давно, аксесс-листы умели циски использовать только для одного единственного явления. Это пакетная фильтрация. И самые первые аксесс-листы, которые умели фильтровать трафик, ориентировались только на IP-адрес источника в пакете. Такие аксесс-листы были единственными возможными, и, соответственно, никто их специально не именовал, но потом появились другие аксесс-листы. И те,

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

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

Если у нас есть аксесс-лист, нам нужно как-то его определять, что это за аксесс-лист. Каким-то образом каждому аксесс-листу дать название или номер, или что-то еще. И самые первые аксесс-листы, которые были в цисках, были стандартные, были нумерованные. Их было всего 100 штук, точнее 99 штук. Они имели номера с 1 по 99. Под них было, если хотите, фиксированное количество слотов. И вы могли некоторые слоты занимать, некоторые не занимать, но в любом случае за пределы этого количества 99 аксесс-листов вы выпрыгнуть не могли. Связано это было с тем, что аксесс-листы были аппаратные, они работали на аппаратном уровне, и, соответственно, количество места в аппаратной ускоренной микросхеме было ограничено. Но потом появились расширенные аксесс-листы, и, соответственно, под них тоже требовалось сделать отдельную нумерацию. И циска придумала сделать такую вещь, что стандартных аксесс-листов будет 99 штук с 1 по 99,

и расширенных аксесс-листов будет с 100 по 199, уже 100 штук. Идея была, конечно, красивая, но очевидны были проблемы с тем, что делать, если вдруг зачем-то окажется нужно больше аксесс-листов. И очень скоро оказалось, что таки да, нужно больше аксесс-листов, потому что 100 штук не так много, как может показаться. И крупные провайдеры, и некоторые предприятия сказали, а нам нужно больше, сильно больше. И циска сказала, что я могу сделать? Номера уже забиты с 1 по 99 стандартные, дальше 100 уже нельзя поставить, потому что 100 уже расширенные. Они по типу разные, одни быстрые, другие медленные. Никак не получается сделать больше аксесс-листов. Тут клиенты сказали, слушай, циска, мы денег заплатим. И похрустели зелеными бумажками. И циска сказала, поняли, давайте сделаем больше аксесс-листов, раз нужно. Но поскольку номера под новые аксесс-листы были уже заняты, пришлось делать нумерацию под дополнительные диапазоны аксесс-листов в кривом месте.

Соответственно, 700 штук перед второй тысячей, с 1300 по 1999, это 700 штук аксесс-листов, которые циска потом добавила, нумерованных стандартных аксесс-листов. В итоге общий диапазон будет такой: с 1 по 99 и с 1300 по 1999. Всего получается почти 800 штук. И, соответственно, 700 штук после второй тысячи. Это с 2000 по 2699, это расширенные нумерованные аксесс-листы. Клиенты сказали, ой, как хорошо, на тебе, циска, твои деньги. Циска сказала, ой, как хорошо, вот вам, клиенты, аксесс-листы. И все немножко радовались. Но радовались немножко, потому что потом снова пришли клиенты и сказали, циска, а нам бы еще, еще, давай. Циска на это сказала, ребят, вы видите, уже вообще никак не вариант добавить вам еще стандартных аксесс-листов. Прям совсем никак. Потому что делать три разных диапазона с такими кривыми значениями, как эти, это уже будет совсем наркомания даже для нас.

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

На самом деле они тоже именованные, просто у них имя состоит из цифр. И аксесс-лист с номером 1 — это просто именованный аксесс-лист с именем 1. Это уже больше не номер. Но старый синтаксис, опять же, тоже остался. И вы можете создать нумерованный список доступа и потом работать с ним как с именованным списком, просто с именем единичка. Под что диапазон с 200 по 1299? Там под много разных вещей. Там есть под MAC аксесс-листы, там есть под IPX аксесс-листы, там есть под NetBEUI аксесс-листы. Короче, там много всего. AppleTalk. Что-то из этого до наших времен уже не дошло, потому что это прям совсем не актуально. Циска в актуальных версиях IOS это просто не поддерживает. Но MAC аксесс-листы, например, есть. И под них тоже там нумерация отводится своя. Такая штука. По факту сегодня все аксесс-листы, которые есть, именованные и расширенные.

Но работать с ними как с нумерованными мы можем и работать с ними как со стандартными мы можем. Единственное, что если вы объявили аксесс-лист как стандартный, то потом к нему как к расширенному обратиться уже не получится. Но если вы объявили аксесс-лист как нумерованный, то как к именованному потом вы все равно можете обратиться. И это даже часто будет использоваться для кое-каких задач. Каким образом создается стандартный аксесс-лист? Вы указываете строчки одна за одной, и формат у этих строчек будет: аксесс-лист, дальше номер аксесс-листа, вердикт, эталон и маска. Если маска у вас будет 0.0.0.0, то вы можете вместо эталона и маски 0.0.0.0 написать слово хост и этот айпишник, как я вам показывал пару слайдов назад. Если вы работаете именно со стандартным аксесс-листом, то если у вас маска 0.0.0.0, то вы можете написать хост,

а можете вообще ничего не писать, просто оставить как есть. В нашем случае первая самая строчка как раз такой пример. Permit и дальше айпишник 10.0.0.1. На самом деле это эквивалент того, что здесь будет маска 0.0.0.0 и эквивалент того, что здесь было бы написано хост 10.0.0.1. Все три строчки будут одинаковы по смыслу. В машинной памяти они будут храниться все три одинаково. Разница только в чтении для человеков, мешков с костями. Вторая строчка. У нас опять же аксесс-лист с точно таким же номером, вердикт, слово хост и дальше айпишник. Понятно, да, что имеется в виду 10.0.0.2 эталон и маска 0.0.0.0. Третья строчка, опять же, указывается вердикт, эталон, маска. Четвертая строчка. Вердикт, эталон, маска. Пятая строчка. Вердикт, эталон, маска. И шестая строчка. Permit any. Если мы работаем со стандартным аксесс-листом,

то если мы где-то делаем permit any, то это должна быть самая последняя строчка, или deny any. Смысл в том, что никогда, ни при каких условиях в стандартном аксесс-листе после строчки с any уже никакая другая строчка не сработает. Поэтому есть смысл any делать самым последним. Еще один момент заключается в том, я забыл вам сказать, что мы проверяем все строчки одну за одной. Сначала первую, если нет срабатывания, вторую, если нет срабатывания, третью, если нет срабатывания, четвертую. И если ни одна строчка не сработает, то выносится неявный вердикт deny. Нет. Это называется implicit deny. Implicit deny. То, что ни одна строчка не сработала, и в конце любого access-листа есть невидимая строчка deny any. Мы её никогда не пишем, но она есть. Это тот самый implicit deny. И если у вас есть последняя строчка, которая содержит слово any, то в случае со стандартным access-листом есть смысл писать только permit any.

Потому что если вы напишете в явном виде deny any, то вы зря потратите калории. Это в любом случае последняя строчка, и если вы её не напишете, то следующий неявный запрет, неявный deny всё равно отработает точно так же. Поэтому со стандартными access-листами есть смысл писать только permit any, и всё. Порядок строк очень важен. Вы должны будете наиболее специфичные условия ставить в начало, а наиболее общие условия ставить в конец. Понятно, что any — это наиболее общее условие, более общего уже не придумаешь. Но чем более специфичное условие, тем оно должно быть выше. Проблема, которая решается этим правилом, заключается вот в чём. Если вы сначала сделаете более общее сравнение и вынесете вердикт, то потом до более частного условия вы уже не дойдёте. Пример, который здесь можно привести. У нас есть компания. В этой компании есть много-много-много людей.

Среди них, например, есть продажники. Они работают в отделе продаж. У продажников есть начальник. И мы хотим написать правило, можно ли ходить в интернет или нельзя. Мы хотим всех сотрудников разделить на две кучки — на тех, кому можно, и на тех, кому нельзя ходить в интернет. И всем работникам в компании мы хотим сказать, что им ходить в интернет можно, потому что у нас компания, которая позволяет использовать интернет на работе в личных целях. Но продажникам интернет использовать нельзя, потому что они вместо того, чтобы работать, сидят во Вконтактике, тупят и не работают. Но начальнику продажников ходить в интернет можно. Тогда наиболее специфичное условие — это начальник продажников. Потому что он и продажник тоже. Соответственно, если сначала мы скажем, что продажникам в интернет ходить нельзя, то начальника продажников мы накроем точно так же. Поэтому сначала должны идти наиболее специфичные условия — это начальник продажников. Потом следующее, чуть более общее условие — это все остальные продажники, но уже кроме начальника, потому что начальник обработан на предыдущем этапе.

И потом все остальные пользователи — это все, кроме продажников. Опять же, потому что продажники обработаны на предыдущем этапе. И конкретно здесь у нас пример примерно такой же. У нас есть Permit 10.0.0.1. Это, условно говоря, начальник продажников. Permit Host 10.0.0.2 — это заместитель начальника продажников. Этим двум, 10.0.0.1 и 10.0.0.2, ходить в интернет можно. Дальше. Deny 10.0.0.0 по маске 0.0.0.255. Что такая маска делает? 0.0.0.255. Она требует совпадения у изучаемого IP-адреса по первым трём октетам с эталоном 10.0.0.0. Любой IP-адрес, начинающийся на 10.0.0, а в четвёртом октете неважно что, я поставлю там x. Это как раз будет здесь срабатывать. Это правило. И на IP-адрес 10.0.0.1 первая строчка скажет «да». На IP-адрес 10.0.0.2 вторая строчка скажет «да».

А на все остальные IP-адреса с 10.0.0.3 по 10.0.0.255, или сколько, 10.0.0.254, третья строчка скажет «нет». Четвёртая строчка скажет «да» на все IP-адреса, которые начинаются на десятку. Потому что мы требуем совпадения первого октета с десяткой, а все остальные октеты неважно какие. Это как раз сотрудники компании. Дальше мы можем сказать deny 192.168.0.0 по /16 маске. Мы не требуем совпадения последних двух октетов ни с чем, а первые два октета должны быть 192.168. И permit any. Все остальные могут делать всё, что угодно. Наиболее общие условия в конце, наиболее частные условия в начале. Если мы записываем расширенный access-лист, то формат будет похожий. Мы опять же пишем с одним и тем же номером access-листа строчки: access-list, пробел, номер, дальше вердикт.

Но в случае со стандартным access-листом после вердикта мы писали эталон и маску. А в случае с расширенным access-листом у нас будет немножко более сложный синтаксис. Сначала access-list чего-то там, потом вердикт permit или deny, потом мы указываем протокол, для которого ведётся правило. Это либо весь IP в целом, либо мы указываем тип вложения в IP — TCP или UDP. Затем мы указываем эталон и маску источника трафика, IP-адрес источника, и эталон и маску получателя трафика. Возможно, будут какие-то дополнительные ограничения, которые связаны с тем, что для некоторых конкретных протоколов мы можем это дополнительное ограничение ввести. Например, если мы работаем с TCP, у нас есть такая штука, как порты. И мы здесь дополнительно к IP-адресу и маске можем дописать ограничения на порты источника или ограничения на порты получателя.

Но только если здесь у нас TCP или UDP. Там, где у нас порты есть. Если у нас есть что-то, что не работает с портами, например ICMP. У ICMP портов нету. Поэтому дополнительные ограничения на порт для ICMP мы накладывать права не имеем. Но при этом мы можем сказать, что у ICMP, например, есть типы и коды. И мы можем сделать дополнительные ограничения на тип или на код сообщения. Но в любом случае это уже конкретная связка конкретного протокола с тем, какие дополнительные ограничения можно для протокола наложить. Если мы не хотим, мы можем не указывать эти дополнительные ограничения. Пример. У нас есть access-лист 101. Первая строчка — выносим вердикт. Permit. Для какого протокола? Да для любого. IP означает, что вы не накладываете дополнительных ограничений вообще никаких. Любой IP-пакет будет под это условие попадать. Дальше.

Указываем ограничение на источник. Host 10.0.0.1 указывает на то, что источник должен быть ровно 10.0.0.1. И any — это ограничение на назначение, указание IP-адреса назначения. Такая строчка будет говорить «да» на любые пакеты от 10.0.0.1 куда угодно. Это фактически как будто бы мы использовали стандартный access-лист. Такая строчка работает. Мы не накладываем никакие ограничения ни на вложение, ни на IP-адрес получателя. Мы накладываем ограничения только на адрес источника. Вторая строчка. С тем же самым номером будет работать, тоже выносим вердикт. Дальше указываем, какой протокол нас интересует. Протокол в нашем случае TCP. Не любые уже IP-пакеты будут попадать под правило, а только те, которые содержат TCP-вложения, у которых в поле протокола стоит шестёрка. Дальше. Указываем ограничение на IP-адрес источника. 192.168.0.0 по маске 0.0.255.255.

Это эквивалентно тому, что мы требуем совпадения 192.168 с первыми двумя октетами изучаемого образца. Это на самом деле сетка 192.168.0.0/16. И вторая часть — any eq 80 — это указание на получателя. У нас эталон и маска получателя, и здесь как раз встречается дополнительное ограничение. Any обозначает IP-адрес, и мы говорим, неважно какой IP-адрес. А eq 80 обозначает номер порта получателя. Эта строчка будет говорить, что любые узлы из сети 192.168.0.0/16 могут подключаться по TCP на 80-й порт получателя. Если порт получателя точно равен 80-му, тогда можно. Если бы мы хотели наложить ограничение на порт источника, мы бы его сделали вот здесь.

Мы бы здесь сказали, например, eq 100. Но мы не делаем ограничение на порт источника, потому что классический пример использования 80-го порта — это когда ваш браузер генерирует динамический номер порта источника, и он из-под случайного порта, который заранее неизвестен, подключается на 80-й хорошо известный порт на известном ему адресе сервера. Поэтому в этой ситуации ограничение на порт источника не нужно. И ограничение на адрес и порт получателя у нас выглядит таким образом. Здесь у нас ничего нет дополнительного. Третья строчка указывает deny — она говорит «нет». На пакеты, которые проходят с типом вложения UDP, которые идут из-под той же самой сети 192.168.0.0/16, на адреса 10.0.0.0/8.

Опять же, здесь мы требуем совпадение первого октета с десяткой. Здесь нет никаких ограничений на номера портов, любые UDP-подключения нам здесь не нравятся. И последнее — permit ip any any. Здесь вообще никаких ограничений. Permit ip any any. Если есть, то это самая последняя строчка. Может быть такое, что будет не последняя строчка. Например, permit tcp any any. Если UDP мы хотим дальше отдельно как-то обработать, может быть такое, что permit tcp any any будет где-то в серединке. Но permit ip any any — это вообще никаких ограничений ни на что, нигде. И поэтому это, если есть такая строчка, то самая последняя. Опять же, в конце любого access-листа есть ограничение, что всё остальное запретить. В случае с расширенными access-листами эта невидимая строчка была бы deny ip any any.

Ещё что я хотел сказать. Очень важен порядок строк. Сначала более специфичные, потом более общие. И очень важно здесь не ошибаться и нигде не писать те строчки, которые вы не хотели бы писать. Cisco, когда придумала этот механизм access control lists, забыла к нему прикрутить нормальный редактор. Поэтому если вы где-нибудь в access-листе, в любой из строчек, напишете ошибку, или у вас в access-листе была какая-то строчка, но она вас перестала устраивать, если этот access-лист нумерованный, то вы с этим ничего не можете сделать, только удалить access-лист целиком. Поэтому будьте осторожны и не делайте ошибок в нём. Это будет очень обидно, если вы набьёте 10 строчек, особенно если они вот такие длинные, а потом обнаружите, что где-то допустили ошибку. Вам придётся весь access-лист удалить, а потом перенабить его заново. То ещё удовольствие.

Если вы работаете с именованными access-листами, то вы должны будете воспользоваться немножко другой конструкцией. Вы указываете ip, дальше access-list, указываете тип access-листа, потому что по названию access-листа непонятно, какого он типа, и указываете некое имя. Например, std-nacl. NACL — это named ACL, именованный access-лист. Когда вы такую команду вводите, у вас приглашение к вводу меняется, становится config std-nacl, и дальше вы вводите те же самые конструкции, которые вы использовали с нумерованными access-листами, только без указания слова access-list и номера access-листа. Сразу с вердикта начинаем. Что для стандартных, что для расширенных access-листов, это правило будет работать. Там, где у нас было access-list 1 permit чего-то, access-list 1 deny чего-то, access-list 1 permit any, здесь мы access-list 1 теперь больше не пишем. Всё, что происходит в субконтексте config std-nacl или config ext-nacl (extended access-list), всё это остаётся в этом самом access-листе.

И строчки находятся в том же самом порядке, в котором вы их забиваете. Так же, как и с нумерованными access-листами. Если вы хотите посмотреть, какие access-листы у вас есть, то есть команда show ip access-lists. И если вы используете эту команду, вы как раз увидите, что на самом деле, давайте я здесь трейдемарк поставлю, на самом деле, все аксесс-листы, которые есть в памяти современных аксесс-ок, они будут именованные. Даже если вы сделали, ну да, если вы сделали какой-то аксесс-лист, там, допустим, вот, стандартный аксесс-лист std-nuckle, у вас показывается, что есть такой аксесс-лист, и, соответственно, имя у него std-nuckle. И вот здесь вот, стандартный аксесс-лист номер один. Вот это, это имя. Ну и вы можете к этому аксесс-листу обратиться как к именованному аксесс-листу. Вы можете сказать, ip access list std-nuckle, std-nuckle, std-nuckle, std-nuckle, std-nuckle, то есть, ну, вообще,

конструкция, как будто мы хотим отредактировать именованный аксесс-лист, но вот это вот один, это будет имя аксесс-листа. И вы провалитесь в контекст config.std-nuckle и сможете его каким-то образом модифицировать. Вот. С стандартными аксесс-листами, которые нумерованы, равно как с расширенными нумерованными аксесс-листами, сделать ничего нельзя. Можно только их дополнить. в конце, но отредактировать, там, допустим, удалить какую-то конкретную строчку не получится. С нумерованными аксесс-листами нельзя, а с именованными можно. И вот этот вот хак, что мы можем к нумерованному аксесс-листу обратиться как к именованному, позволяет нам на самом деле редактировать содержимое нумерованных аксесс-листов. Содержимое можно редактировать следующим образом. Каждая строчка, которая у вас есть в именованном аксесс-листе, она имеет номер. И, соответственно, эта нумерация, она начинается с десятки, шаг нумерации будет 10. То есть первая строчка будет с номером 10, вторая — 20, третья — 30.

Если вдруг когда-то вы там программировали в детстве на Basic, то вот вы, наверное, знакомы с этой концепцией. Делается это для того, чтобы можно было в серединку между двумя строчками вставить какую-то еще одну строчку с номером посерединке. То есть между десятой и двадцатой хотим добавить на эту строчку, окей, это номер 15 будет. Но стандартная нумерация — это с шагом в 10, и, соответственно, вот у вас там всегда есть какой-то запас, чтобы можно было в серединку вставить довольно много чего. В нашем случае мы никакие номера не создавали, но мы видим, что они по факту как раз такие и создались. Десятый, двадцатый, тридцатый. Здесь тоже десятый, двадцатый, тридцатый. Здесь десятый, двадцатый. Тридцатого нет. Ну, десятый, двадцатый, тридцатый. Вот эти вот номера, они не случайные. Они, соответственно, позволяют вам работать с конструкцией самого Access List, убирая ненужные вам строчки и добавляя нужные строчки в нужное место. Если вы работаете с нумерованным Access List, нумерованный, нумерованный, прям по-честному, то никаких конфигураций, никаких модификаций, никаких ничего вы не можете с ним сделать.

Единственное, что можно сделать с нумерованным Access List, это его удалить. Вот. No Access List, дальше номер. Очень частая ошибка, на которую, наверное, все, кто работает с нумерованными Access Listами наталкивались, заключается в том, что у вас есть какой-то Access List. Ну, например, первый. Он состоит из какого-то количества строчек. Access List, там, Access List 1, Permit чего-то. Access List 1, там, Permit чего-то. Access List чего-то, там, 1, Deny чего-то. У нас большой-большой Access List, и вы в него добавляете новую строчку. Пишите Access List, Access List 1, Permit, и делаете какую-то ошибку. То есть, не знаю, Permit Any случайно набираете, хотели набрать что-то другое, случайно набрали Permit Any. Вот проблема заключается в том, что вы не можете удалить отдельную строчку из нумерованного Access List по-честному. Если вы сделаете привычную конструкцию в виде No Access List 1, Permit Any,

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

Не просто Access List с номером 1, а Access List с названием Access List для НАТО. Это сразу понятно, что это за Access List, зачем он используется. Если вы хотите удалить именованный Access List, то надо набрать no, а дальше ту же самую конструкцию, которую мы создаем его, ipaccess list, там, стандарт или extended, и дальше имя. Если вы хотите отредактировать существующий именованный Access List, то вы должны будете провалиться в субконтексте, соответствующий, там, вот, сказать, ipaccess list, стандарт, std, nuckle, или, там, ipaccess list, extended, extend, nuckle. И дальше можно будет всякое разное с ним сделать. Первое, что можно сделать, это можно удалить отдельную строчку. То, чего нельзя сделать с нумерованным Access Listом, вы можете сделать с именованным Access Listом. И если вы воспользуетесь конструкцией, допустим, создали Access List с номером 1 и случайно добавили в него вот эту вот строчку, там, permit any, которую вы не хотели добавлять, вы можете сказать, окей, мы не можем удалить отдельную строчку

из нумерованного Access List, но мы можем удалить отдельную строчку из именованного Access List с именем 1. Вы заходите в контекст ipaccess list стандарт 1, проваливаетесь в субконтекст config.st.denuckle, и там уже можно удалить отдельную строчку с нужным вам номером. Если вы хотите, вы можете добавить строчку с нужным номером. Опять же, работает даже с нумерованными Access Listами, которые вы похакали и зашли в контекст именованного Access List с номером вместо имени. И вот вы можете указать номер строчки, которую вы хотите добавить. Ну и, соответственно, если у вас там первая строчка была десятая, то вот если вы добавляете строчку с номером 5, она у вас встает, естественно, с самой первой. Иногда бывает такая задача, что вы должны будете постоянно добавлять новые строчки, например, в начало Access List. И даже если вы говорите, окей, у нас самая первая строчка имеет номер 10, вот мы закладываемся под то, чтобы у нас максимальное количество срочек

можно было добавить с самого начала. Делаем новую строчку с 9 номером, потом 8, потом 7. Рано или поздно все равно это все закончится. И рано или поздно вы столкнетесь с тем, что вы добавите новую строчку с номером 1, и новую строчку с номером 0 вы уже сделать не можете. И новую строчку с существующим номером тоже уже задействовать не получится. Поэтому есть команда, которая называется resequencing. Перенумерация Access List. И вы можете либо просто задать параметры по умолчанию, говорите IP, Access List, resequence, дальше название Access List. Либо можете указать отдельно шаг и стартовый номер, с которого начинается ренумерация. Ну, бывает нужно редко, но иногда бывает. Для IPv6 все то же самое, то есть те же самые принципы работают, только не нужно писать кривые маски, только нормальные они остаются. И в конце любого IPv6 Access List у вас есть неявное разрешение на работу Neighbor Discovery. То есть вместо неявного запрета на все остальное,

типа deny any, или any, any. В IPv6 Access List перед этим есть permit ICMP, any, any, eq, и дальше там, по-моему, nd, как называется. Ну, короче говоря, Neighbor Discovery отдельно невидимые две строчки разрешают. Почему я вам про это говорю? Если вы специально не запретите ICMP, просто скажете, разрешаем, допустим, TCP, разрешаем UDP, у вас Neighbor Discovery тоже будет работать. А если вы специально ICMP запретите, то есть вы скажете, допустим, перми, простите, deny, deny any в самом конце, вручками скажете deny any, или deny там IPv6 any, any, то вы вот эту вот строчку тоже сломаете. Она невидимая, и она в самом конце, соответственно, есть после уже того, как вы сами своими руками

вобьете какие-то конкретные строчки. Если вы скажете deny IPv6 any, не в самом конце своего Access List в явном виде, до вот этой невидимой строчки дело уже никогда не дойдет. Поэтому будьте осторожны и не поломайте Neighbor Discovery, без него работать не будет. В IPv4 у нас Neighbor Discovery происходил за счет ARPA, и ARPA поломать Access List с IPv4 было нельзя, потому что ARPA не вкладывается в IPv4, а ICMP v6 вкладывается в IPv6, поэтому под фильтры IPv6, соответственно, Neighbor Discovery попадает, и можно его поломать. Так.