Как настроить acl на коммутаторе в cisco packet tracer

Обновлено: 06.07.2024

Списки доступа (access-lists) используются в целом ряде случаев и являются механизмом задания условий, которые роутер проверяет перед выполнением каких-либо действий. Маршрутизатор проверяет каждый пакет и на основании вышеперечисленных критериев, указанных в ACL определяет, что нужно сделать с пакетом, пропустить или отбросить. Типичными критериями являются адреса отправителя и получателя пакета, тип протокола. Каждый критерий в списке доступа записывается отдельной строкой. Список доступа в целом представляет собой набор строк с критериями, имеющих один и тот же номер (или имя). Порядок задания критериев в списке существенен. Проверка пакета на соответствие списку производится последовательным применением критериев из данного списка (в том порядке, в котором они были введены). Пакет, который не соответствует ни одному из введенных критериев будет отвергнут. Для каждого протокола на интерфейс может быть назначен только один список доступа. Как пример ниже приведена таблица списка управления доступом по умолчанию:

Без ACL - по умолчанию при создании конечной точки ей все разрешено.

Разрешить - при добавлении одного или нескольких диапазонов "разрешения" все остальные диапазоны по умолчанию запрещаются. Только пакеты из разрешенного диапазона IP -адресов смогут достичь конечной точки виртуальной машины.

Запретить - при добавлении одного или нескольких диапазонов "запретить" все другие диапазоны трафика по умолчанию разрешаются.

Сочетание разрешения и запрета - можно использовать сочетание правил "разрешить" и "запретить", чтобы указать вложенный разрешенный или запрещенный диапазон IP -адресов.

Рассмотрим два примера стандартных списков:

Практическая работа 9-1. Создание стандартного списка доступа

Списки доступа бывают нескольких видов: стандартные, расширенные, динамические и другие. В стандартных ACL есть возможность задать только IP адрес источника пакетов для их запретов или разрешений.

На рис. 9.1 показаны две подсети: 192.168.0.0 и 10.0.0.0.

Постановка задачи

Требуется разрешить доступ на сервер PC1 с адресом 192.168.0.12, а PC0 c адресом 192.168.0.11 – запретить ( рис. 9.2).

Соберем данную схему и настроим ее. Настройку PC0 и PC1 выполните самостоятельно.

Настройка R0

Интерфейс 0/0 маршрутизатора1841 настроим на адрес 192.168.0.1 и включим следующими командами:

Второй интерфейс маршрутизатора (порт 0/1) настроим на адресом 10.0.0.1 и так же включим:

Настройка сервера

Настройки сервера приведены на рис. 9.3.

Диагностика сети

Проверяем связь ПК из разных сетей ( рис. 9.4).

Приступаем к решению задачи

Правило запрета и разрешения доступа будем составлять с использованием стандартных списков доступа (ACL). Пока не задан список доступа на интерфейсе всё разрешено (permit). Но, стоит создать список, сразу действует механизм "Всё, что не разрешено, то запрещено". Поэтому нет необходимости что-то запрещать (deny) – указываем что разрешено, а "остальным – запретить" подразумевается автоматически. По условиям задачи нам нужно на R0 пропустить пакеты с узла 192.168.0.12 на сервер ( рис. 9.5).

Применяется данное правило на интерфейс в зависимости от направления (PC1 расположен со стороны порта Fa0/0) – рис. 9.6. Эта настройка означает, что список доступа (правило с номером 1) будет действовать на интерфейсе fa0/0 на входящем (in) от PC1 направлении.

ACL на коммутаторах CISCO — списки контроля доступа рассматриваются обычно в разрезе маршрутизаторов: пакетная фильтрация на интерфейсе, QoS, NAT, VPN, динамические протоколы маршрутизации. Ну а как же коммутаторы? Здесь ACL тоже применяются.

Основы ACL ( Access Control List ) списков для маршрутизатора можно посмотреть во 2 части курса CCNA. Предполагается хорошее понимание основ ACL для работы с ACLs коммутатора.

Немного теории

Быстро пробежимся по наиболее важным моментам:

Записи ACL — ACE ( Access Control Entry ) обрабатываются сверху вниз, при совпадении происходит отработка ACE и выход из ACL;
Последняя запись всегда неявный запрет deny [any | ip any any](это концепция CISCO, она широко распространена, но есть и другие концепции);
Новая запись добавляется вниз списка (перед неявным запретом);
Чтобы довить запись в конкретное место списка нужно в явном виде указать номер строки;
Строки нумеруются 10, 20, 30. соответственно чтобы добавить новую строку между первой и второй, нужно указать в явном виде номер 15 (или 11, 12. 19) перед ACE;
Для интерфейса только 1 ACL для каждого протокола (IPv4 и IPv6) и для каждого направления (in и out);
Создать ACL в режиме глобальной конфигурации, потом применить на интерфейсе;
Убедиться, что наиболее важные (подробные, с наибольшим числом параметров, они же самые длинные) записи находятся в верхней части списка ACL;
Помнить, что трафик создаваемый внутри устройства (самим коммутатором) не фильтруется исходящими ACL;
Стандартные ACL размещать как можно ближе к месту назначения ;
Расширенные ACL размещать как можно ближе к источнику ;
Помнить про внутренний алгоритм стандартных списков: ACE для хостов перед ACE для диапазонов.

Если есть сомнения в правильном понимании, лучше повторить.

Способы контроля трафика коммутаторов

Существует различных 3 способа контролировать трафик коммутаторов с помощью ACL:

Router ACL (RACL) — применяется на маршрутизаторе либо на коммутаторе (на логическом интерфейсе SVI для коммутатора);

Port ACL (PACL) — применяется на коммутаторе (на физическом интерфейсе);

VLAN ACL (VACL) — применяется на коммутаторе (без интерфейса, с указанием номера VLAN).

Попробую выполнить каждый способ на железе. Конфигурация следующая:

На коммутаторе WS-C3550-24-EMI создан SVI на VLAN 1 с IP 192.168.64.251;
К порту FastEthernet 0/18 этой VLAN подключён мой компьютер с IP 192.168.64.1 и MAC 7085.C275.E38F;
К коммутатору WS-C3550 подключен коммутатор WS-C2950 создан SVI на VLAN 1 с IP 192.168.64.253.

Модельный ряд

Не все коммутаторы CISCO одинаково умеют использовать ACLs. В основном полная поддержка всех видов ACLs доступна для коммутаторов L3. Для коммутаторов L2 могут быть и есть ограничения. Так например, для модельного ряда 2950 есть два набора функционала: стандартный и расширенный. Набор функционала жёстко привязан к платформе. Мои WS-C2950-24 со стандартным функционалом практически ничего не умеют в плане ACLs (да ещё много других ограничений). Поэтому всё и рассматривается на коммутаторе L3 WS-C3550.

Порядок применения ACL

Схема такая: с хоста A, который находится во VLAN A, трафик идёт на хост B во VLAN B на этом же коммутаторе. На коммутаторе настроены SVI для VLANs A, B и маршрутизация между VLANs A,B:

PACL A;
VACL A;
RACL на SVI VLAN A во входящем направлении;
RACL на SVI VLAN B в исходящем направлении;
VACL B.

Обращаю внимание на направление трафика:

Inbound (in) — трафик идёт с компьютера на интерфейс коммутатора;
Outbound (out) — с интерфейса коммутатора на компьютер.

При большом количестве ACL и особенно при применении логирования отдельных ACE, полезно будет проконтролировать загрузку CPU и памяти коммутатора: Zabbix, NOC, другое ПО и конечно с помощью команд:

Обратный трафик

На картинке выше было указано прохождение пакета в прямом направлении от компьютера A к компьютеру B. Но B ответит A. Важно не забывать, чтобы обратный трафик был разрешён. Когда это нужно:

Когда на интерфейсе SVI A (и/или SVI B) коммутатора настроен и inbound, и outbound RACL.

Трафик проходит от компьютера A через интерфейс SVI A. Срабатывает in-список доступа. Приходит ответ от компьютера B, срабатывает out-список на интерфейсе SVI A. Поэтому нужно чтобы обратный трафик от компьютера B был разрешён:

В явном виде в списке out на SVI A;
В неявном виде с помощью параметра established в списке out на SVI A;

Параметр established можно применять только для расширенного списка и только для TCP-трафика. Потому что только TCP устанавливает сессию. И только в этом случае сессию можно отследить, а значит разрешить обратный трафик.

В чём разница? Допустим, что других ACL нет. Только 1 входящий ACL (in) и 1 исходящий ACL (out) на 1 интерфейсе SVI A. В первом случае, правило для обратного трафика должно быть указано в out-списке "в явном виде":

Любой трафик TCP, UDP, ICMP, IP;
Для источника трафика обычно указывается в явном виде IP и маска

При этом пакеты (удовлетворяющие спискам доступа in, out) будут свободно ходить через интерфейс SVI A как от компьютера A к B, так и от компьютера B к A. При этом неважно какой из компьютеров инициировал подключение.

Во втором случае, правило для обратного трафика указывается в out-списке "в неявном виде", то есть с помощью established:

Только TCP трафик;
Вместо IP и маски источника обычно указывается ANY;
Завершающий параметр ESTABLISHED

При этом пакеты могут быть отправлены только с A. Обратный трафик будет автоматически разрешён. Таким образом только компьютер A может инициировать сессию TCP. А компьютер B нет. Для этого и было придумано. Этот метод прапрадедушка Stateful Firewalls:

На граничном роутере ACL висит на интерфейсе в сторону интернета. Первые 2 правила в явном виде разрешают доступ из интернета до 187.187.197.239/240 по указанным портам, два следующих разрешают обратный TCP трафик, который инициировали хосты 187.187.197.239/240.

Ещё случай, когда нужно разрешить обратный трафик:

Поскольку VACL не имет направления, обратные пакеты будут тоже проверены. Немного забегая вперёд скажу, на самом деле VACL удобно использовать чтобы заблокировать часть трафика, а весь остальной разрешить. Тогда карта классов будет выглядеть примерно так:

Тогда никакой обратный трафик разрешать не надо.

Как работает Established

Можно подумать что роутер ведёт какую-то таблицу соединений. Нет, ничего такого. То что пакет принадлежит уже установленному соединению роутер понимает по флагам в заголовке TCP:

Почитать в оригинале. Поэтому возможна ситуация когда TCP сессия была инициирована через один роутер R1 (один провайдер), а ответы приходят на другой роутер R2 (другой провайдер). Если R2 имеет ACE с established для этого трафика, он увидит установленный флаг ACK и пропустит пакеты. Он не знает и ему неважно, что это не его сессия. Вот такой интересный момент. Возвращаемся к коммутаторам.

RACL — в сущности обычный ACL:

Применяется на интерфейсе 3 уровня, в основном на сабинтерфейсе транкового канала маршрутизатора;
Может использоваться во входящем и исходящем направлении (inbound/outbound);
Нужен чтобы контролировать трафик между VLANs;
Для RACL поддерживаются Стандартные и Расширенные ACL.

Router on a stick: пакет приходит из какой-то VLAN, маршрутизируется на роутере и уходит в другую VLAN. Соответственно RACL может быть применён на сабинтерфейсе исходной VLAN во входящем направлении до маршрутизации или на сабинтерфейсе целевой VLAN в исходящем направлении после маршрутизации.

Также RACL может применяться на SVI интерфейсе коммутатора.

Пример 1 RACL

Разрешил подключение во входящем направлении для своего компьютера и сижу через SSH. Смотрю статистику, есть попадания, значит ACL работает.

Второй способ контролировать работу ACL — дополнять правило ACE параметром log, тогда попадание будет выводится в консоль и отправляться на SYSLOG-сервер:

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

И наблюдаю результат:

Теперь добавляю запрет на всё в явном виде:

Меняю на компьютере адрес на 64.2, подключение SSH недоступно. Возвращаю IP, подключаюсь, смотрю статистику:

Есть попадания, RACL работает. После проверки убираю RACL, чтобы он не мешал при проверке следующих ACL.

PACL — применяется на интерфейсе 2 уровня, то есть на интерфейсе коммутатора. Имеются различия на разных платформах, но основные характеристики PACL:

Обрабатывается аппаратно;
Может использоваться только во входящем направлении;
Может быть 2 видов: MAC PACL или IP PACL;
На 1 интерфейсе можно использовать максимально 1 IP и 1 MAC PACL (совместно или по отдельности);
Не фильтрует трафик 2 уровня CDP, VTP, DTP, UDLD и STP, потому что этот трафик обрабатывается до применения PACL.

Контролирует IP трафик (IP PACL) или non-IP трафик (MAC PACL).

IP PACL

Контролирует прохождение кадров на основе IP адреса в IP заголовке пакета. Полезная штука (на мой взгляд).

Пример 2 IP PACL

Разрешил IP своего компьютера на порту, куда он подключен.

Меняю на компьютере IP адрес на 64.2, SSH подключения нет, IP PACL в действии. Возвращаю IP, подключение снова работает. Особенность — попадания кадров не отображаются при выводе show access-lists. В консоль тоже ничего не выводится, скорее особенность моего оборудования.

После проверки убираю IP PACL.

MAC PACL

Если поискать в интернете, то все примеры сводятся к блокировке AppleTalk Address Resolution Protocol (AARP), пример нежизненный и смысловой нагрузки в нём мало.

Пример 3 MAC PACL

Запретил весь поддерживаемый PACL трафик 2 уровня.

Собственно для MAC PACL поддерживается не так уж много протоколов, поэтому наверное не такая уж полезная фича, опять же на мой взгляд:

Пробую по-другому: удаляю единственную ACE из ACL с тотальным запретом и добавляю:

То есть разрешаю в явном виде только запросы ARP, остальное запрещено. Всё снова работает. Можно почистить кеш ARP — работает. Теперь похоже на правду.

В теории ARP запросы не блокируется, но на практике вот иначе. Попробовал несколько раз, повторяемость результата присутствует.

Может быть зависит от конкретного железа и версии IOS (платформа 3550?). Возможно. Хотел продублировать на 2950, там функционала IP/MAC PACL нет. Будет возможность, проверю ещё на свежем железе. Хотелось бы разобраться.

Успешные попадания кадров не отображаются при выводе show access-lists.

После проверки убираю MAC PACL.

VACL — также известные как VLAN Maps, применяются на VLANs, фильтруют все типы трафика, который перемещается внутри VLAN, маршрутизируется из/во VLAN. VACL не имеет направления, для задания направления указывается конкретный адрес источника или назначения. Для удобства можно считать что у каждого VACL есть сразу два направления (inbound+outbound).

Не имеет значения как трафик попадает во VLAN: через Access-порт, через Trunk-порт или через маршрутизируемый порт — VACL будет применён.

VACL обрабатываются аппаратно, что является значительным преимуществом. VACL может осуществлять следующие действия:

Поэтому по сути только Разрешить или Запретить. Для отбрасываемых пакетов/кадров можно включить логирование.

Настройка VACL происходит в 4 этапа:

Создание Стандартного или Расширенного IP ACL (или Расширенного Именованного MAC ACL);
Создание записи Access Map (карты классов), куда добавлен ACL с помощью команды match и действие с помощью команды action;
Подобно ACL в конце карты классов есть неявная запись с запретом типа "deny all". Поэтому или прописывать в ACL весь трафик в обе стороны, что сильно затруднительно по понятным причинам и его разрешать. Весь остальной трафик при этом заблочится. Или же вешать дополнительную запись access-map в самом конце с безусловным разрешением всего трафика;
Задаётся целевая VLAN с помощью команды vlan filter с указанием имени карты классов.

Пример 4 VACL с IP ACL

Запускаю пинг 192.168.64.253 и ввожу следующие команды, этапы выделяю цветом:

Пинг прерывается. Почему так происходит? Сначала пинг идёт с IP адресом моего компьютера 64.1 в качестве источника, проходит через 64.251, VACL успешно проверяет пакеты и форвардит их, 64.253 получает пакеты и отвечает, но IP адрес источника становится уже 64.253 , VACL пакеты блокирует. Пинга нет. Добавляю в ACL строчку:

Пинг появляется. Убираю VACL.

Тут надо ещё отметить:

В 1 этапе для списка доступа всегда используется permit, чтобы отобрать нужный трафик;
В 1 этапе может быть определено несколько списков доступа. Тогда во 2 этапе создаётся также несколько записей access-map, по одной записи access-map на один список доступа. В этом случае после имени для access-map указывается число (10; 20; 30..), которое определяет порядок обработки этой access-map по отношению к остальным. Похоже на вхождение ACE в ACL, роль ACE тут выполняет access-map. А если запись одна, номер не нужен;

В 3 этапе целевая VLAN может быть: single VLAN, range of VLANs (10-20), list of multiple VLANs (1,3-5,7);
Попробовал на EVE-NG, только у образов IOL (разумеется L2) есть такой функционал.

Пример 5 VACL с MAC ACL

Пробую аналогично предыдущему примеру следующее:

Где 000a.b8da.d140 MAC 64.253. Ну так с виду всё работает (CDP, STP), убираю:

Ожидаемо отваливается SSH и пинг. Если отключить 1 из оставшихся правил, идёт перерасчёт STP, но после STP, CDP в порядке. Ожидаемо.

Как я увидел, работа VACL с MAC ACL довольно-таки схожа с MAC PACL.

Для проверки VACL используются следующие команды:

Показывает Что применяется и Как применяется.

Показывает Где применяется.

Выводы

Обычно все эти 3 типа ACL применяются совместно.

Обобщу, что удалось выяснить:

RACL — ACL со стандартным применением и назначением. Поскольку сама CISCO рекомендует осуществлять маршрутизацию между VLANs силами коммутатора с поддержкой маршрутизации (даже 2960 может это делать, необязательно коммутатор 3 уровня — как позже выяснилось из-за того, что модель 2960 имеет много модификаций, зависит от модели), то схема RACL на SVI наверное самая подходящая для продакшена;
IP PACL — аппаратный, будет полезным, если нужно ограничить конкретному компьютеру доступ куда-то внутри его VLAN, если трафик идёт дальше, то проще воспользоваться стандартным ACL на интерфейсе 3 уровня;
MAC PACL — непонятная пока довольно-таки вещь, по крайней мере на том оборудовании, что есть у меня, кроме того количество фильтруемых протоколов ограничено;
VACL — аппаратная штука для контроля трафика внутри VLAN, то есть может особенно пригодится когда трафик не ходит через интерфейсы 3 уровня. К примеру, для пользовательского VLAN, чтобы пользователи не могли подсоединяться друг к другу и таким образом блокируются атаки с одного пользовательского компьютера на другой. Может быть определено несколько списков доступа и несколько access-map. Фильтр может быть добавлен одновременно для нескольких VLANs. Нужно применять очень аккуратно, иначе можно случайно заблокировать часть полезного трафика (или весь).

Что тут ещё? Есть Downloadable ACLs (dACLs), это разновидность PACL. Применяется на порту динамически, после удачной аутентификации доступа 802.1X и скачивается этот dACL с RADIUS сервера (например, ISE). Если на порту уже присутствует PACL, он будет перезаписан.

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

В этом документе объясняется принцип применения списков контроля доступа (ACL) IP для фильтрации сетевого трафика. Также в нем содержатся краткие описания типов IP ACL, доступности функций и примеры использования в сети.

RFC 1700 содержит назначенные номера общеизвестных портов. RFC 1918 содержит выделение адресов для частных Интернет- и IP-адресов, которые не должны отображаться в Интернете.

Предварительные условия

Требования

Для данного документа нет особых требований. Обсуждаемые ключевые понятия справедливы для программного обеспечения Cisco IOS ® Releases 8.3 и выше. Это указано ниже каждой функции в списке доступа.

Используемые компоненты

В данном документе обсуждаются различные типы списков ACL. Некоторые из них существуют с версии Cisco IOS Releases 8.3, а другие были внедрены в более поздних программных версиях. Это указано в обсуждении каждого типа списков.

Данные для документа были получены в специально созданных лабораторных условиях. При написании данного документа использовались только устройства с пустой (стандартной) конфигурацией. В рабочей сети необходимо изучить потенциальное воздействие всех команд.

Условные обозначения

Ключевые понятия ACL

В этом разделе описываются ключевые понятия списков ACL.

Маски

Маски используются с IP-адресами в IP-списках ACL для выбора разрешенных и запрещенных элементов. Маски предназначены для настройки IP-адресов на интерфейсах, начинающихся с 255 и имеющих большие значения в левой части, например, IP-адрес 209.165.202.129 с маской 255.255.255.224. Маски, используемые для списков доступа для IP, являются обратными (например, маска 0.0.0.255). Это иногда называется инвертированной маской или шаблоном маски. Когда значение маски разбивается на двоичный код (нули и единицы), результаты определяют, какие биты адреса следует учитывать при обработке трафика. Значение 0 указывает, что биты адреса необходимо учитывать (точное соответствие); 1 в маске означает "безразличный" разряд. В этой таблице ключевые понятия объясняются более подробно.

сетевой адрес (трафик, который необходимо обрабатывать)

сетевой адрес (двоичный)

00001010.00000001.00000001.00000000

00000000.00000000.00000000.11111111

На основе двоичной маски можно увидеть, что первые три набора (октета) должны точно соответствовать указанному двоичному сетевому адресу (00001010.00000001.00000001). Единицы последнего набора цифр (байт) означают "безразличные" разряды (.11111111). Поэтому учитывается весь трафик, который начинается с 10.1.1., так как последний октет может быть любым. Поэтому с данной маской обрабатываются сетевые адреса с 10.1.1.1 до 10.1.1.255 (10.1.1.x).

Для определения обратной маски ACL вычтите обычную маску из 255.255.255.255. Пример определения обратной маски для сетевого адреса 172.16.1.0 с обычной маской 255.255.255.0:

255.255.255.255 - 255.255.255.0 (обычная маска) = 0.0.0.255 (обратная маска)

Учтите эти эквиваленты ACL.

IP-адрес источника/маска подсети 0.0.0.0/255.255.255.255 означает "любой"

Источник и маска 10.1.1.2/0.0.0.0 аналогичны "host 10.1.1.2"

Уплотнение ACL

Примечание. Маски подсетей можно также представить в виде записи фиксированной длины. Например, 192.168.10.0/24 соответствует 192.168.10.0 255.255.255.0.

В данном списке указан принцип уплотнения диапазона сетей в единую сеть для оптимизации списка ACL. Учитывайте такие сети.

Первые два октета и последний октет одинаковы для каждой сети. Данная таблица служит пояснением принципа уплотнения сетей в единую сеть.

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

Поскольку первые пять бит совпадают, предыдущие восемь сетей могут быть уплотнены в единую сеть (192.168.32.0/21 или 192.168.32.0 255.255.248.0). Все восемь возможных сочетаний этих трех бит младших разрядов соответствуют диапазону рассматриваемых сетей. Данная команда определяет список ACL, разрешающий данную сеть. Если вычесть 255.255.248.0 (обычную маску) из 255.255.255.255, результат будет равен 0.0.7.255.

Запомните этот набор сетей для дальнейшего рассмотрения.

Первые два октета и последний октет одинаковы для каждой сети. Данная таблица служит пояснением принципа уплотнения этих сетей.

Эти сети, в отличие от предыдущего примера, невозможно уплотнить в единую сеть. Необходимо как минимум две сети. Предыдущие сети можно уплотнить в следующие две сети:

Для сетей 192.168.146.x и 192.168.147.x совпадают все биты за исключением одного, представляющего "безразличный" разряд. Это может быть записано следующим образом: 192.168.146.0/23 (или 192.168.146.0 255.255.254.0);

Для сетей 192.168.148.x и 192.168.149.x совпадают все биты за исключением одного, представляющего "безразличный" разряд. Это может быть записано следующим образом: 192.168.148.0/23 (или 192.168.148.0 255.255.254.0).

Эти выходные данные определяют уплотненный список ACL для вышеуказанных сетей.

Обработка списков ACL

Трафик, поступающий на маршрутизатор, сравнивается с записями ACL на основе очередности появления записей в маршрутизаторе. Новые записи добавляются в конец списка. Маршрутизатор продолжает поиск до нахождения соответствия. Если маршрутизатор доходит до конца списка, не найдя соответствий, трафик не принимается. По этой причине наиболее часто используемые записи должны располагаться в начале списка. Существует неявный запрет на трафик, который не разрешен. Список ACL с единственной записью “deny” приводит к запрету всего трафика. Необходимо использовать как минимум одну разрешающую запись ACL, иначе весь трафик будет блокироваться. Результаты применения этих двух списков ACL (101 и 102) аналогичны.

В этом примере достаточно последней записи. В первых трех записях нет необходимости, поскольку протокол TCP содержит протокол Telnet, а протокол IP содержит протоколы TCP, UDP и ICMP.

Маршрутизатор может отображать описательный текст по некоторым общеизвестным портам. Используйте команду ? для получения справки.

Применение списков ACL

Можно определить ACL без их применения. Но эффекта от списков ACL не будет до тех пор, пока они не применены к интерфейсу маршрутизатора. Рекомендуется применять ACL на интерфейсе, который ближе других расположен к источнику трафика. Как отображено в следующем примере, при попытке блокировать трафик от источника до места назначения можно применить входящий список ACL до E0 на маршрутизаторе A вместо исходящего списка E1 на маршрутизаторе C.

Определение входа, выхода, источника и места назначения

Термины "вход", "выход", "источник" и "место назначения" используются относительно маршрутизатора. Трафик в маршрутизаторе можно сравнить с трафиком на магистрали. Предположим, вы сотрудник правоохранительных органов в Твери и хотите остановить автомобиль, который движется из Москвы в Петербург. Источником фургона является Москва, а местом назначения - Петербург. Можно организовать контрольно-пропускной пункт на границе Тверской области и Ленинградской области (на въезде) или на границе Московской и Тверской области (на выезде).

Относительно маршрутизатора данные термины имеют указанные значения.

Выход – трафик, который уже прошел через маршрутизатор и уходит с интерфейса. Источник, где он находился, на другой стороне маршрутизатора, и место назначения, куда он направляется.

Изменение списков ACL

При изменении списка ACL требуется особое внимание. Например, при попытке удалить указанным ниже образом определенную строку из нумерованного списка ACL будет удален весь список ACL.

Для редактирования нумерованных списков ACL скопируйте конфигурацию маршрутизатора на сервер TFTP или в текстовый редактор, например, блокнот. Затем внесите нужные изменения и скопируйте конфигурацию обратно на маршрутизатор.

Также можно сделать следующее.

Удаляемые элементы вырезаются из списка ACL, а необходимые дополнения вставляются в конец списка.

Также можно добавлять строки в стандартные нумерованные списки ACL или расширенные нумерованные списки ACL с помощью их порядковых номеров в Cisco IOS. Пример конфигурации:

Настройте расширенный список ACL следующим образом:

Введите команду show access-list для просмотра записей ACL. Также отобразятся порядковые номера, такие как 10, 20 и 30.

Добавьте запись для списка доступа 101 с порядковым номером 5.

В выходных данных команды show access-list порядковый номер 5 добавляется в качестве первой записи для списка доступа 101.

Аналогичным образом можно настроить стандартный список доступа:

Основным отличием стандартного списка доступа является то, что Cisco IOS добавляет записи по убыванию IP-адресов, а не порядковых номеров.

В данном примере отображены различные записи, в т.ч. для разрешения IP-адреса (192.168.100.0) или сетей (10.10.10.0).

Добавьте запись в список доступа 2 для разрешения IP-адреса 172.22.1.1:

Данная запись добавляется сверху списка для указания приоритета конкретного IP-адреса, а не сети.

Примечание. Предыдущие версии списков ACL не поддерживаются программными средствами Security Appliance, например брандмауэром ASA/PIX.

Поиск и устранение неисправностей

Как удалить список ACL из интерфейса?

Перейдите в режим настройки и введите no перед командой access-group, как показано в данном примере, для удаления списка ACL из интерфейса.

Что делать, когда слишком большое количество трафика отвергается?

Если отвергается слишком большое количество трафика, то проанализируйте принципы существующего списка для определения и применения расширенного списка. Команда show ip access-lists выводит счетчик пакетов, отображающий, к какой записи списка ACL выполняется обращение.

Ключевое слово log в конце отдельных записей ACL отображает помимо информации о порте номер ACL и факт разрешения или отвержения пакета.

Примечание. Ключевое слово log-input существует в ПО Cisco IOS Release 11.2 и выше, а также в некоторых типах ПО на основе Cisco IOS Release 11.1, созданных специально для рынка поставщиков услуг. Старое ПО не поддерживает это ключевое слово. Использование этого ключевого слова предполагает отображение, по возможности, входного интерфейса и MAC-адреса источника.

Как отладить уровень пакетов, использующий маршрутизатор Cisco?

В данной процедуре объясняется процесс отладки. Прежде всего, необходимо убедиться в отсутствии действующих списков ACL, в наличии списка ACL и в активации режима быстрой коммутации.

Примечание. Будьте предельно осторожно при отладке системы с высокой информационной загрузкой. Используйте список ACL для отладки определенного трафика. Но будьте осторожны с процессом и потоком трафика.

Используйте команду access-list для получения необходимых данных.

В данном примере получение данных настроено на адрес места назначения 10.2.6.6 или исходный адрес 10.2.6.6.

Отключите быструю коммутацию на вовлеченных интерфейсах. Если быстрая коммутация не отключена, видимым будет только первый пакет.

Введите команду debug ip packet 101 или debug ip packet 101 detail, чтобы начать процесс отладки.

Используйте команду no debug all в режиме "enable" и команду interface configuration, чтобы прервать процесс отладки.

Типы списков ACL для IP

В данном разделе документа описываются типы списков ACL.

Схема сети

Стандартные списки ACL

Стандартные списки ACL - это самый старый тип ACL. Их появление датируется выпуском ПО Cisco IOS Release 8.3. Стандартные списки ACL управляют трафиком, сравнивая адрес источника IP-пакетов с адресами, заданными в списке.

Ниже приведен формат синтаксиса команд стандартного списка ACL.

Во всех версиях программного обеспечения номер access-list-number может варьироваться от 1 до 99. В ПО Cisco IOS Release 12.0.1 стандартные списки ACL начали использовать дополнительные номера (от 1300 до 1999). Эти дополнительные номера относятся к расширенным спискам ACL для IP. Программное обеспечение Cisco IOS Release 11.2 предоставило возможность использовать имя списка (поле name) в стандартных ACL.

Параметр source/source-wildcard, равный 0.0.0.0/255.255.255.255, можно указать как any. В случае, когда используются только нули, шаблон можно опустить. Поэтому сервер 10.1.1.2 0.0.0.0 аналогичен серверу 10.1.1.2.

После определения списка ACL его нужно применить к интерфейсу (входящему или исходящему). В более ранних версиях программного обеспечения "out" (выход) было значением по умолчанию, если не было задано ключевое слово "out" или "in" (вход). В более поздних версиях программного обеспечения необходимо указывать направление.

Ниже приведен пример использования стандартного списка ACL для блокирования всего трафика за исключением трафика из источника 10.1.1.x.

Расширенные списки ACL

Расширенные списки ACL появились в ПО Cisco IOS Release 8.3. Расширенные списки ACL управляют трафиком, сравнивая адреса источника и места назначения IP-пакетов с адресами, заданными в списке.

Ниже приведен формат синтаксиса команд расширенных списков ACL. Некоторые строки были обрезаны из соображений размещения.

Если вы считаете, что её стоило бы доработать как можно быстрее, пожалуйста, скажите об этом.

Автор: Наташа Самойленко

Содержание

Именованные ACL могут быть стандартные и расширенные. У них немного отличается синтаксис с нумерованными:

В конце любого ACL есть невидимое правило deny ip any any.

Стандартный ACL позволяет указывать только IP-адрес отправителя:

Применение ACL на интерфейсе:

Пример стандартного нумерованного ACL, который запрещает хосту 10.0.3.2 доступ в сегмент сервера, но разрешает всем остальным:

Применение ACL на интерфейсе (если применить ACL на интерфейсе fa0/0 в направлении in, то он заблокирует и доступ хоста 10.0.3.2 в интернет):

Тот же пример только с именованным ACL:

Применение ACL на интерфейсе:

К vty ACL применяется другой командой:

Для ограничения доступа к маршрутизатору, по протоколам telnet или SSH, можно использовать стандартный ACL и применить его к vty.

Данный пример ACL разрешает подключаться к маршрутизатору только с адреса 4.4.4.4:

Расширенный ACL, при указании протоколов IP, ICMP и др., позволяет указывать IP-адреса отправителя и получателя:

Расширенный ACL, при указании протоколов TCP или UDP, позволяет указывать и порты отправителя и/или получателя:

Задание для расширенного ACL:

Пример расширенного нумерованного ACL:

Применение ACL на интерфейсе:

Расширенный именованный ACL:

Применение ACL на интерфейсе:

Создание обычного ACL (в нём разрешён telnet для того чтобы пользователи могли пройти аутентификацию):

Создание динамического ACL:

Если необходимо чтобы параметр any при применении ACL был заменен на IP-адрес инициатора telnet-соединения, то в команде access-enable host необходимо указать параметр host.

Дополнительно можно настроить временной интервал, после которого динамическая запись будет удалена независимо от активности пользователя:

Применение ACL на интерфейсе:

Настройка доступа telnet:

Команда access-enable host активирует динамический ACL:

Проверка связи до активирования динамического ACL:

Просмотр информации на dyn1 до активирования динамического ACL:

После активирования динамического ACL (qua7 пингуется, а интерфейс dyn1 по-прежнему нет):

Просмотр информации на dyn1 после активирования динамического ACL:

Если команда access-enable указана без параметра timeout, то запись будет оставаться постоянно. Удалить её можно с помощью команды clear ip access-template. Например, очистить запись в динамическом ACL:

Reflexive ACl могут быть настроены только с расширенными именованными ACL. Сами RACL не применяются к интерфейсу, они применяются к ACL.

Схема сети такая же как и для динамических ACL.

Создание ACL для исходящего трафика:

Создание ACL для входящего трафика:

Значение глобального таймера по умолчанию 300 секунд:

Изменение значения глобального таймера:

Можно для каждой записи указать своё значение таймера, например:

Если настроены и глобальный и специфический таймер для записи, то приоритет у более специфического таймера.

Применение временных интервалов к правилам ACL может быть полезно, например, в таких случаях:

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

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

Пример настройки временного интервала для рабочих дней:

Пример настройки временного интервала для выходных дней:

Просмотр информации о настроенных временных интервалах (второй интервал неактивен, так как сейчас рабочий день):

Второй интерфейс маршрутизатора (0/1) настроен с адресом 10.0.0.1 и так же включен.

Ну и сервер, настроен с адресом 10.0.0.100, маска подсети 255.255.255.0 и адрес шлюза по-умолчанию 10.0.0.1.

Проверяем запросом Ping с любого узла на адрес сервера. Всё должно проходить свободно.

Если вдруг пакеты не доходят, проверьте следующие параметры:

Шлюз по-умолчанию совпадает с адресом ближайшего интерфейса маршрутизатора;
Интерфейс маршрутизатора поднят;
IP-настройки верны;

Поскольку ломаться тут, собственно говоря, нечему, будем считать, что достигли рабочей конфигурации. Итак, стандартные списки доступа.

Задача. Разрешить доступ на сервер только узлу с адресом 192.168.0.12, остальным запретить.

Важно запомнить, что пока не задан список доступа на интерфейсе (который можно повесить только один, кстати), всё разрешено. Но стоит повесить хотябы один список, то действует механизм (сверху вниз) “Всё, что не разрешено, то запрещено”. То есть нам нет необходимости создавать в конце правило типа “остальным – запретить”, оно подразумевается автоматически. Итак, раз нам нужно пропустить пакеты с узла 192.168.0.12, то его и зададим в качестве источника.

Общий вид правила Standart ACL выглядит так:

Итак, мы разрешили прохождение пакетов с адресом источника 192.168.0.12. Негласно, ниже прописалось невидимое правило deny всё остальное, поэтому запрещающее правило можно не создавать.

Применяется правило на интерфейс в зависимости от направления.

Эта настройка означает, что список правил с номером 1 будет действовать на интерфейсе fa0/0 на входящем направлении.

После проверки легко убедиться в том, что теперь только узел с адресом 192.168.0.12 может посылать ping-запрос и получать ответ от сервера. Остальные узлы не могут.

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

А для того, чтобы просмотреть созданные ACL, воспользуемся командой show access-lists

Кстати, эта команда даёт нам весьма ценную информацию (11 match(es)), это значит, что прошло 11 пакетов, попадающих под это правило. Ну чем не статистика?

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

В данной статье мы рассмотрим простые типовые конфигурации для списков управления доступом на базе Cisco ACL, которые фильтруют IP-пакеты в зависимости от следующих данных:

адрес источника (source address);
адрес назначения (destination address);
тип пакета (протокол верхнего уровня);

Маршрутизатор проверяет каждый пакет и на основании вышеперечисленных критериев, указанных в ACL определяет, что нужно сделать с пакетом, пропустить или отбросить.

Что такое Access Control List?

IP ACL – последовательный набор правил разрешающих или запрещающих прохождение пакета. Маршрутизатор последовательно проверяет каждый пакет на соответствие правилам. После первого же совпадения принимается решение и дальше правила не обрабатываются.

Если ни одно из правил не подошло, то пакет отбрасывается из-за неявного последнего правила deny all.

Какие бывают ACL?

Можно выделить следующие виды списков контроля доступа:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 107ms, Maximum = 125ms, Average = 116ms

Запрещаем FTP трафик.

Задача: разрешить доступ к FTP для узла 192.168.1.2 и запретить для узла 192.168.1.3.

На сервере 10.0.1.3 поднят FTP сервис (дефолтные cisco:cisco). Убедимся, что узел доступен и FTP работает.

Subnet Mask. 255.255.255.0
Default Gateway. 192.168.1.1

Trying to connect. 10.0.1.3
Connected to 10.0.1.3
220- Welcome to PT Ftp server
Username:cisco
331- Username ok, need password
Password:
230- Logged in
(passive mode On)
ftp>dir

0 : c1841-advipservicesk9-mz.124-15.T1.bin 33591768
1 : c1841-ipbase-mz.123-14.T7.bin 13832032
2 : c1841-ipbasek9-mz.124-12.bin 16599160
3 : c2600-advipservicesk9-mz.124-15.T1.bin 33591768
4 : c2600-i-mz.122-28.bin 5571584
5 : c2600-ipbasek9-mz.124-8.bin 13169700
6 : c2800nm-advipservicesk9-mz.124-15.T1.bin 50938004
7 : c2800nm-ipbase-mz.123-14.T7.bin 5571584
8 : c2800nm-ipbasek9-mz.124-8.bin 15522644
9 : c2950-i6q4l2-mz.121-22.EA4.bin 3058048
10 : c2950-i6q4l2-mz.121-22.EA8.bin 3117390
11 : c2960-lanbase-mz.122-25.FX.bin 4414921
12 : c2960-lanbase-mz.122-25.SEE1.bin 4670455
13 : c3560-advipservicesk9-mz.122-37.SE1.bin 8662192
14 : pt1000-i-mz.122-28.bin 5571584
15 : pt3000-i6q4l2-mz.121-22.EA4.bin 3117390
ftp>quit

PC>221- Service closing control connection.

Команды и настройка FTP-сервера есть на нашем сайте тут.

Убедимся, что доступ есть как с узла 192.168.1.2, так и с 192.168.1.3. У меня всё по плану. Если у вас вдруг нет доступа, убедитесь, что каждому узлу назначен IP и маска, а так же прописан шлюз по-умолчанию. И не перепутали ли вы интерфейсы?

Здесь мы видми по 2 разрешающих и по 2 запрещающих правила для указанных направлений и портов 21 и 20. Это служба FTP, передача команд и данных.

А теперь применяем наш список к интерфейсу со стороны сети 192.168.1.0/24 на вход (потому что трафик ВХОДИТ на роутер со стороны интерфейса 192.168.1.1):

Как видите, мы просто применили наше правило с номером 101.

Проверяем коннект. С узла 192.168.1.3 видим следующее:

Trying to connect. 10.0.1.3

А с узла 192.168.1.2 по прежнему коннект!

Всему своё время, а мы рассмотрим самое распространённое – стандартные и расширенные списки контроля доступа.

Стандартные списки ACL

Формат синтаксиса команды стандартного ACL выглядит так:

permit – пропускаем пакет.
deny – отбрасываем пакет.
host – конкретный IP-адрес узла
sourcesource-wildcard – IP и его обратная маска. Надо несколько слов сказать про обратную маску. Здесь применяется инвертированная маска сети, которая показывает, какие биты изменяются.
any – любой хост.

Стандартные ACL управляют трафиком, сравнивая адрес источника пакетов с адресами, заданными в списке.

Ну и чтобы лучше понять параметры, приведу несколько примеров:

Задача: разрешаем прохождение трафика от узла 10.0.0.10

Задача: запрещаем прохождение пакетов из подсети 10.0.1.0/24

Задача: разрешить доступ только админу (10.0.0.9), остальным запретить.

И здесь очень важно написать правила именно в таком порядке. Я не зря сказал, что правила проверяются последовательно, до первого совпадения.

Здесь, если пакет принадлежит IP 10.0.0.9, то первая строчка соответствует и пакет пропустится.

А если написать правила в обратном порядке, то первой же строкой будет deny any, что отбросит любой пакет (даже 10.0.0.9) и дальше правила применяься не будут. Поэтому нужно быть очень внимательным в этом.

Расширенные списки ACL

Расширенные списки управляют трафиком, сравнивая адреса источника и назначения пакетов с адресами, заданными в списке. Это более тонкая фильтрация трафика по следующим критериям:

протокол;
номер порта;
значение DSCP;
приоритет;
состояние бита SYN;

Синтаксис расширенных списков ACL.

Уже представляю ваши глаза “О_О”. Да, вот такой расширенный список, действительно, параметров немного больше.

Примеры расширенных ACL

Я составил типовую конфигурацию в Cisco Packet Tracer, две подсети 10.0.1.0/24 и 192.168.1.0/24.

Узлы подсети 10.0.1.0/24 имеют шлюз по умолчанию 10.0.1.1, а 192.168.1.0/24 соответственно 192.168.1.1.

Настраиваем роутер.

Аналогично настраиваем и второй инерфейс (fast 0/1), только в качестве адреса указываем не 10.0.1.1, а 192.168.1.1.

Приступим к настройке ACL-ов.

Сначала убедимся, что сеть коммутируется и все узлы доступны друг для друга:

Pinging 10.0.1.3 with 32 bytes of data:

Reply from 10.0.1.3: bytes=32 time=125ms TTL=127
Reply from 10.0.1.3: bytes=32 time=107ms TTL=127
Reply from 10.0.1.3: bytes=32 time=125ms TTL=127
Reply from 10.0.1.3: bytes=32 time=109ms TTL=127

Ping statistics for 10.0.1.3:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 107ms, Maximum = 125ms, Average = 116ms

Запрещаем FTP трафик.

Задача: разрешить доступ к FTP для узла 192.168.1.2 и запретить для узла 192.168.1.3.

На сервере 10.0.1.3 поднят FTP сервис (дефолтные cisco:cisco). Убедимся, что узел доступен и FTP работает.

PC>ipconfig
IP Address………………….: 192.168.1.2
Subnet Mask…………………: 255.255.255.0
Default Gateway……………. 192.168.1.1

PC>ftp 10.0.1.3
Trying to connect…10.0.1.3
Connected to 10.0.1.3

220- Welcome to PT Ftp server

331- Username ok, need password

Password:
230- Logged in

(passive mode On)
ftp>dir

Listing /ftp directory from 10.0.1.3:
0 : c1841-advipservicesk9-mz.124-15.T1.bin 33591768
1 : c1841-ipbase-mz.123-14.T7.bin 13832032
2 : c1841-ipbasek9-mz.124-12.bin 16599160
3 : c2600-advipservicesk9-mz.124-15.T1.bin 33591768
4 : c2600-i-mz.122-28.bin 5571584
5 : c2600-ipbasek9-mz.124-8.bin 13169700
6 : c2800nm-advipservicesk9-mz.124-15.T1.bin 50938004
7 : c2800nm-ipbase-mz.123-14.T7.bin 5571584
8 : c2800nm-ipbasek9-mz.124-8.bin 15522644
9 : c2950-i6q4l2-mz.121-22.EA4.bin 3058048
10 : c2950-i6q4l2-mz.121-22.EA8.bin 3117390
11 : c2960-lanbase-mz.122-25.FX.bin 4414921
12 : c2960-lanbase-mz.122-25.SEE1.bin 4670455
13 : c3560-advipservicesk9-mz.122-37.SE1.bin 8662192
14 : pt1000-i-mz.122-28.bin 5571584
15 : pt3000-i6q4l2-mz.121-22.EA4.bin 3117390
ftp>quit

Packet Tracer PC Command Line 1.0
PC>221- Service closing control connection.

Читайте также: