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

2 комментария /

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

На самом деле, про маршрутизаторы будет разговор, куда же без них.

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

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

  • Записи ACL (Access Control List) — 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;
  • Помнить, что трафик создаваемый внутри устройства (самим маршрутизатором) не фильтруется исходящими ACLs;
  • Стандартные ACLs размещать как можно ближе к месту назначения;
  • Расширенные ACLs размещать как можно ближе к источнику;
  • Помнить про внутренний алгоритм стандартных списков: ACE для хостов перед ACE для диапазонов.

Если есть сомнения в правильном понимании, лучше повторить. Основы ACL списков для маршрутизатора можно посмотреть во 2 части курса CCNA R&S.

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

Существует различных 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.
ACL на коммутаторах CISCO

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

Не все коммутаторы 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. Порядок отработки ACLs:

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

Обращаю внимание на направление трафика, оно однозначно определено. Если на SVI настроено 2 RACLs: и in, и out, то сработает только один. В зависимости от направления трафика:

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

Логирование отдельных ACE (то есть опция log на конце ACE) всегда происходит с утилизацией CPU коммутатора. Полезно будет проконтролировать загрузку 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
...

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

Для упрощения допустим, что других ACLs нет. Только 1 входящий ACL (in) и 1 исходящий ACL (out) на 1 интерфейсе SVI A. Всё.

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

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

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

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

Без established

В чём разница? В первом случае, правило для обратного трафика должно быть указано в out-списке в явном виде:

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

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

С established

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

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

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

VACL

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

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

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

vlan access-map VACL 10
 match ip address LIST_DENY_ALL - тут бабахаем что нужно запретить
 action drop
vlan access-map VACL 20
 action forward - тут безусловно разрешаем всё
!

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

Пример

На граничном роутере ACL висит на интерфейсе в сторону интернета. Поэтому трафик с интернета входящий, для него работает ACL in:

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
..

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

Как работает 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 интерфейсе коммутатора.

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

Пример 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)# switchport - эту команду можно не вводить, подчеркнул что интерфейс 2 уровня
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), пример нежизненный и смысловой нагрузки в нём мало.

Пример 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 (платформа 3550?). Будет возможность, проверю на свежем железе.

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

VACL

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

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

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

  • forward;
  • drop [log];
  • redirect (только для коммутаторов Catalyst 6500).

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

3550-1(config-access-map)# action forward ?
  <cr>
3550-1(config-access-map)# action drop ?
  log  Log dropped packets
  <cr>

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

  1. Создание Стандартного или Расширенного IP ACL (или Расширенного Именованного MAC ACL);
  2. Создание записи Access Map (карты классов), куда добавлен ACL с помощью команды match и действие с помощью команды action;
  3. Подобно ACL в конце карты классов есть неявная запись с запретом типа deny all. Поэтому или прописывать в ACL весь трафик в обе стороны, что сильно затруднительно по понятным причинам и его разрешать. Весь остальной трафик при этом заблочится. Или же вешать дополнительную запись access-map в самом конце с безусловным разрешением всего трафика;
  4. Задаётся целевая VLAN с помощью команды vlan filter с указанием имени карты классов.
Пример 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, по одной записи access-map на один список доступа. В этом случае после имени для access-map указывается число (10; 20; 30..), которое определяет порядок обработки этой access-map по отношению к остальным. Похоже на вхождение ACE в ACL, роль ACE тут выполняет access-map. А если запись одна, номер не нужен;
3550-1(config)# vlan access-map VLAN1_MAP_IP ?
  <0-65535>  Sequence to insert to/delete from existing vlan access-map entry
  <cr>
  • В 3 этапе целевая VLAN может быть: single VLAN (10), range of VLANs (10-20), list of multiple VLANs (1,3-5,7);
  • Попробовал на EVE-NG, только у образов IOL (разумеется L2) есть такой функционал.
Пример 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, 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 уровня), то схема RACL на SVI наверное самая подходящая для продакшена;
  • IP PACL — аппаратный, будет полезным, если нужно ограничить конкретному компьютеру доступ куда-то внутри его VLAN. Если трафик идёт дальше, то проще воспользоваться ACL на интерфейсе 3 уровня;
  • MAC PACL — непонятная довольно-таки вещь, по крайней мере на том оборудовании, что есть у меня. Кроме того количество фильтруемых протоколов ограничено;
  • VACL — аппаратная штука для контроля трафика внутри VLAN. То есть может особенно пригодится когда трафик не ходит через интерфейсы 3 уровня.

В VACL может быть определено несколько списков доступа и несколько карт классов. Фильтр может быть добавлен одновременно для нескольких VLANs. Нужно применять очень аккуратно, иначе можно случайно заблокировать часть полезного трафика (или весь).

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

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

2 комментария к “ACL на коммутаторах CISCO”

Оставьте комментарий

Прокрутить вверх
%d такие блоггеры, как: