ACL на коммутаторах CISCO

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

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

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

Наиболее важные моменты:

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

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

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

Router ACL (RACL) — применяется на маршрутизаторе либо на коммутаторе;
Port ACL (PACL) — применяется на коммутаторе;
VLAN ACL (VACL) — применяется на коммутаторе.

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

На коммутаторе WS-C3550 создан 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.

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

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

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

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

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

Между VLANs ACL не применяется и трафик ходит свободно.

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

3550-1#sh proc cpu
CPU utilization for five seconds: 1%/0%; one minute: 1%; five minutes: 0%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
1 0 7 0 0.00% 0.00% 0.00% 0 Chunk Manager
2 0 43 0 0.00% 0.00% 0.00% 0 Load Meter
...

3550-1#sh proc mem
Processor Pool Total: 33490068 Used: 17518728 Free: 15971340
I/O Pool Total: 8388608 Used: 3437384 Free: 4951224
PID TTY Allocated Freed Holding Getbufs Retbufs Process
0 0 24684028 5500012 17154868 0 0 *Init*
0 0 13264 176132 13264 0 0 *Sched*
...

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

Важно не забывать, чтобы обратный трафик был разрешён. Когда это нужно:

Когда на интерфейсе коммутатора настроен и inbound, и outbound RACL.

Трафик проходит от компьютера-источника через интерфейс. Срабатывает in-список доступа. Приходит ответ от компьютера-назначения, срабатывает out-список. Поэтому нужно чтобы обратный трафик от компьютера-назначения был разрешён в явном виде или в явном виде с помощью параметра esteblished. Параметр established можно применять только для расширенного списка и только для TCP-трафика (это концепция CISCO, она широко распространена, но есть и другие концепции).

В чём разница? Допустим, что других ACL нет. Только входящий и исходящий на 1 интерфейсе. В первом случае пакеты будут свободно ходить через интерфейс как от компьютера-источника, так и от компьютера-назначения. При этом неважно какой из компьютеров инициировал подключение. Во втором случае только компьютер-источник может инициировать сессию. И только пакеты, которые являются ответными в этой сессии будут пропущены через интерфейс обратно. Сам компьютер-назначения не сможет первым отправить пакет. Пакет будет отброшен. Этот метод прапрадедушка Stateful Firewalls.

В случае использования VACL.

Поскольку VACL не имет направления, обратные пакеты будут тоже проверены.

RACL

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

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

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

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

Пример 1 RACL

3550-1(config)#access-list 1 permit 192.168.64.1
3550-1(config)#interface vlan 1
3550-1(config-if)#ip access-group 1 in
3550-1(config-if)#end
3550-1#sh ip access-lists 1
Standard IP access list 1
10 permit 192.168.64.1 (96 matches)

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

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

3550-1(config)#access-list 1 permit 192.168.64.1 log

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

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

3550-1#terminal monitor

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

00:09:11: %SEC-6-IPACCESSLOGS: list 1 permitted 192.168.64.1 65 packets

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

3550-1(config)#access-list 1 deny any

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

3550-1#sh access-lists 1
Standard IP access list 1
10 permit 192.168.64.1 (311 matches)
20 deny any (33 matches)
3550-1#

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

PACL

PACL — применяется на интерфейсе 2 уровня, то есть на интерфейсе коммутатора:

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

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

IP PACL

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

Пример 2 IP PACL

3550-1(config)#ip access-list extended IP_ACL
3550-1(config-ext-nacl)#permit ip host 192.168.64.1 any
3550-1(config-ext-nacl)#exit
3550-1(config)#interface fastEthernet 0/18
3550-1(config-if)#ip access-group IP_ACL in

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

Проверяем:

3550-1#sh run | begin FastEthernet0/18
interface FastEthernet0/18
switchport mode access
ip access-group IP_ACL in
spanning-tree portfast
spanning-tree bpduguard enable
!

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

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

MAC PACL

Контролирует прохождение кадров на основании MAC-адреса. Не может контролировать IP или MPLS трафик и сообщения ARP. Используется только Расширенный Именованный список.

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

Пример 3 MAC PACL

Пробую следующее:

3550-1(config)#mac access-list extended MAC_ACL
3550-1(config-ext-macl)#deny any any
3550-1(config-ext-macl)#exit
3550-1(config)#interface fastEthernet 0/18
3550-1(config-if)#mac access-group MAC_ACL in

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

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

Теперь проверка. Тут интересно. Очищаю ARP кеш на компьютере arp -d. SSH не работает, пинг не проходит, в кеше ARP 192.168.64.251 нет. В чём дело? По идее компьютер должен отправить ARP запрос с адресом 192.168.64.251, получить MAC адрес 64.251, так как запросы ARP не блокируются MAC PACL и успешно установить SSH соединение, успешно пинговать 64.251, поскольку IP трафик, но этого не происходит.

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

3550-1(config-ext-macl)#permit any host FFFF.FFFF.FFFF

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

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

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

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

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

VACL

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

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

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

Forward;
Drop;
Redirect (только для коммутаторов Catalyst 6500).

Поэтому по сути только Разрешить или Запретить.

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

Создание Стандартного или Расширенного IP ACL (или Расширенного Именованного MAC ACL);
Создание Access Map, куда добавлен ACL с помощью команды match и действие с помощью команды action;
Задаётся целевая VLAN с помощью команды vlan filter с указанием имени Access Map.

Пример 4 VACL с IP ACL

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

3550-1(config)#access-list 2 permit 192.168.64.1
3550-1(config)#vlan access-map VLAN1_MAP_IP
3550-1(config-access-map)#match ip address 2
3550-1(config-access-map)#action forward
3550-1(config-access-map)#exit
3550-1(config)#vlan filter VLAN1_MAP_IP vlan-list 1

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

3550-1(config)#access-list 2 permit 192.168.64.253

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

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

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

Пример 5 VACL с MAC ACL

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

3550-1(config)#mac access-list extended ALLOW_64.253
3550-1(config-ext-macl)#permit host 7085.C275.E38F host 000a.b8da.d140
3550-1(config-ext-macl)#permit host 000a.b8da.d140 host 7085.C275.E38F
3550-1(config-ext-macl)#permit any host FFFF.FFFF.FFFF
3550-1(config-ext-macl)#exit
3550-1(config)#vlan access-map VLAN1_MAP_MAC
3550-1(config-access-map)#match mac address ALLOW_64.253
3550-1(config-access-map)#action forward
3550-1(config-access-map)#exit
3550-1(config)#vlan filter VLAN1_MAP_MAC vlan-list 1

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

3550-1(config-ext-macl)#permit any host FFFF.FFFF.FFFF

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

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

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

3550-1#show vlan access-map
Vlan access-map "VLAN1_MAP_IP" 10
Match clauses:
ip address: 2
Action:
forward

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

3550-1#show vlan filter
VLAN Map VLAN1_MAP_IP is filtering VLANs:
1

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

Выводы

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

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

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

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

Сайт ARNY.RU