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

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 перед 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) — применяется на коммутаторе (на физическом интерфейсе).

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

  • На коммутаторе 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.

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


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

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

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

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

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

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

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

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

При большом количестве ACL и особенно при применении логирования отдельных ACE, полезно будет проконтролировать загрузку 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*
...

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

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

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

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

  1. В явном виде в списке out на SVI A;
  2. В неявном виде с помощью параметра established в списке out на SVI A (тут год, а может и больше вместо out стояло in — и никто не поправил, никто не написал: "у тебя здесь неверно". Ребята, найдёте ошибку, пишите плз в коммент);

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

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

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

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

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

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

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

ip access-list extended INTERNET_ACL_IN
..
  1002 permit tcp any host 187.187.197.239 eq 443 3337
  1003 permit tcp any host 187.187.197.240 eq 443 www
  1004 permit tcp any host 187.187.197.239 established
  1005 permit tcp any host 187.187.197.240 established
..

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

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

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

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

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

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

The established keyword indicates that packets belong to an existing connection if the Transmission Control Protocol (TCP) datagram has the Acknowledgment (ACK) or Reset (RST) bit set.

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


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 PACL (совместно или по отдельности);
  • 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 поддерживается не так уж много протоколов, поэтому наверное не такая уж полезная фича, опять же на мой взгляд:

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

Теперь проверка. Тут интересно. Очищаю 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 этапа:

  1. Создание Стандартного или Расширенного IP ACL (или Расширенного Именованного MAC ACL);
  2. Создание Access Map, куда добавлен ACL с помощью команды match и действие с помощью команды action;
  3. Задаётся целевая 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.

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

2 мысли о “ACL на коммутаторах CISCO”

Добавить комментарий