Всем доброго дня!
В этой статье я бы хотел поговорить про возможности Cisco IOS Access Control Lists (ACLs). Тема многим из вас должна быть знакомой, поэтому мне хочется обобщить информацию по разным типам ACLs. Я кратко пробегусь по основам, а затем поговорим про специальные типы ACLs: time-based (на основе времени), reflexive (отражающие), dynamic (динамические). Итак, начнем…
Основы: Вспомнить все…
Быстренько пробежимся по основным понятиям, синтаксису, чтобы потом проще можно было перейти к более интересным вещам. ACL’ы на роутерах Cisco позволяют решать две группы задач:
- фильтрация трафика;
- классификация трафика.
Эта статья посвящена в основном фильтрации, т.е. использованию ACL в качестве firewall. Классификация позволяет вам отобрать пакеты, для последующей обработки. Например, шифровать только определенный трафик при создании VPN, применять политики качества обслуживания, транслировать только определенные адреса и т.д.
ACL’ы можно отнести к брандмауэрам пакетной фильтрации (packet filtering firewall). Т.е. они позволяют выполнять фильтрацию пакетов по пяти параметрам:
- IP адрес источника
- IP адрес назначения
- Протокол, инкапсулированный в IP-пакет
- Порт источника
- Порт назначения
ACL’ы делятся на 2 типа:
- Стандартные (Standard)
- Расширенные (Extended)
Стандартные ACL’ы позволяют фильтровать трафик по одному единственному критерию – IP адрес источника. Расширенные ACL’ы фильтруют по всем пяти перечисленным параметрам.
ACL состоит из набора правил. В каждом правиле вы определяете параметры фильтрации (адреса, порты и т.д.) и действие, выполняемое над пакетом, если он соответствует всем критериям правила. Действий два: разрешить (permit) и запретить (deny). При разрешении пакет обрабатывается дальше, при запрете – сбрасывается. Правила проверяются последовательно, пока не будет найдено то, которому соответствует пакет. Над пакетом выполняется действие (permit/deny) и дальнейшая проверка правил прекращается. В конце любого ACL неявно находится правило, запрещающее весь трафик. Т.е. используется ограничивающий (restrictive) контроль доступа: запрещено все, что явно не разрешено.
Синтаксис
Два способа создания ACL:
- «Старый» синтаксис. Для идентификации ACL используются номера. За стандартными ACL закреплены номера 1-99 и 1300-1999, за расширенными – 100-199 и 2000-2699.
- Синтаксис именованных ACL. Для идентификации используется имя, выбранное администратором.
Второй способ более удобен. Во-первых, для идентификации ACL вы используете имя, а не номер, т.е. по имени можно будет понять, для чего вы используете ACL. Во-вторых, в поименованных листах используется собственный конфигурационный режим, позволяющий вам более удобно редактировать ACL.
Приведу несколько примеров стандартных ACL:
access-list 1 permit 192.168.1.0 0.0.0.255
!
access-list 2 permit any
!
access-list 3 permit host 10.1.1.1
!
access-list 4 permit 10.1.1.0 0.0.0.15
access-list 4 permit 192.168.0.0 0.0.31.255
Первый ACL (1) разрешает трафик из сети 192.168.1.0/24. Второй (2) ACL разрешает весь трафик. Третий (3) разрешает трафик от хоста 10.1.1.1. И последний четвертый, в первой строке разрешает трафик от хостов 10.1.1.0 – 10.1.1.15, во второй строке разрешает трафик из сетей 192.168.1.0 – 192.168.31.0. Обращаю внимание, что здесь приведены примеры четырех разных ACL’а, а не 5 правил одного ACL.
И несколько расширенных ACL:
access-list 100 permit tcp 10.1.1.0 0.0.0.255 any eq 80
access-list 101 permit udp host 1.1.1.1 eq 500 host 2.2.2.2 eq 555
access-list 102 permit icmp any any echo
access-list 103 permit ip any any
ACL 100 разрешает TCP-трафик из сети 10.1.1.0/24 в любые сети, порт назначения 80. Т.е. разрешаем веб-серфинг из локальной сети. ACL 101 разрешает UDP трафик с хоста 1.1.1.1, порт 500 на хост 2.2.2.2, порт 555. ACL 102 разрешает «пинги» откуда угодно, куда угодно. И, наконец, последний ACL 103 разрешает весь трафик.
Аналогичные стандартные и расширенные ACL’ы, но уже с использованием нового синтаксиса:
ip access-list standard LIST1
permit 192.168.1.0 0.0.0.255
!
ip access-list standard LIST2
permit any
!
ip access-list standard LIST3
permit host 10.1.1.1
!
ip access-list standard LIST1
permit 10.1.1.0 0.0.0.15
permit 192.168.0.0 0.0.31.255
!
ip access-list extended LIST100
permit tcp 10.1.1.0 0.0.0.255 any eq 80
!
ip access-list extended LIST101
permit udp host 1.1.1.1 eq 500 host 2.2.2.2 eq 555
!
ip access-list extended LIST102
permit icmp any any echo
!
ip access-list extended LIST103
permit ip any any
Редактирование ACL стало намного удобнее, начиная я IOS 12.3,. Если вы дадите команду:
show access-list
Вы увидите список ACL’ов и их содержимое:
R0(config-ext-nacl)#do sh access-li
Standard IP access list LIST1
<b> 10</b> permit 192.168.1.0, wildcard bits 0.0.0.255
<b> 20</b> permit 10.1.1.0, wildcard bits 0.0.0.15
<b> 30</b> permit 192.168.0.0, wildcard bits 0.0.31.255
Standard IP access list LIST2
10 permit any
Standard IP access list LIST3
10 permit 10.1.1.1
Extended IP access list LIST100
10 permit tcp 10.1.1.0 0.0.0.255 any eq www
Extended IP access list LIST101
10 permit udp host 1.1.1.1 eq isakmp host 2.2.2.2 eq 555
Extended IP access list LIST102
10 permit icmp any any echo
Extended IP access list LIST103
10 permit ip any any
Обратите внимание, что строки ACL пронумерованы. Для добавления новых строк в определенную позицию, войдите в режим редактирования нужного ACL и перед вводом нового правила укажите номер строки:
ip access-list standard LIST1
25 permit …
Причем не играет роли, как вы создавали ACL – с помощью старого синтаксиса или по-новому, просто вместо имени ACL укажите его номер. Добавление и удаление строк выполняется абсолютно аналогично.
Для удаления строк используется команда no с указанием номера строки:
ip access-list standard LIST103
no 25
Вы можете выполнить перенумерацию строк:
ip access-list resequence LIST103 10 50
В приведенном выше примере, для ACL с именем LIST103 будет выполнена перенумерация и номер первой строки будет 10, а последующие строки нумеруются с шагом 50. Т.е. 10, 60, 110, 160 …
И, наконец, после создания ACL его необходимо будет применить в соответствии с вашими целями и задачами. То что, касается фильтрации, то ACL применяется на интерфейсе. При применении надо будет указать направление фильтрации: in (вход) – трафик приходит с провода на интерфейс роутера, out (выход) – трафик с интерфейса уходит на провод. В примере, ACL применяется для фильтрации входящего трафика:
interface fa0/0
ip access-group LIST103 in
Все это, я надеюсь, известные вещи. Если есть какие-то вопросы, задавайте, я постараюсь ответить. Если вопросов наберется много, то можно будет сделать отдельный пост. Теперь давайте посмотрим на дополнительные возможности, которыми обладают ACL на роутерах Cisco.
Time-based ACLs
Начнем с ACLs, в которых вы можете использовать время, как дополнительный критерий, по которому будет фильтроваться или классифицироваться трафик. К примеру, в рабочее время веб-серфинг запрещен, а в обеденное время и после работы – пожалуйста. Что требуется для создания time-based ACL? Все очень просто:
- Создать один или несколько «календарей» — временных диапазонов;
- Использовать эти «календари» в правилах расширенных ACL.
Для создания «календаря» используется команда time-range, в которой указывается произвольное имя, присваиваемое календарю. На это имя вы будете впоследствии ссылаться в правилах ваших ACL. В примере я создаю «календарь» с именем WORK_DAYS:
time-range WORK_DAYS
absolute start 00:00 01 January 2012 end 23:59 31 December 2012
periodic weekdays 9:00 to 18:00
periodic ?
Friday Friday
Monday Monday
Saturday Saturday
Sunday Sunday
Thursday Thursday
Tuesday Tuesday
Wednesday Wednesday
daily Every day of the week
weekdays Monday thru Friday
weekend Saturday and Sunday
В режиме конфигурирования «календаря» вы определяете временные диапазоны. Два типа диапазонов:
- Абсолютный (указываются конкретные даты и время).
- Периодический (указываются дни недели, рабочие или выходные дни, но без привязки к конкретной дате).
В приведенном выше примере создаются два временных интервала: абсолютный (определяет время с 00:00 01 Января 2012 года по 23:59 31 декабря 2012 года) и относительный (определяет дни с понедельника по пятницу, с 9:00 по 18:00). Для периодических интервалов, как видите, вы можете использовать названия дней недели, daily – ежедневно, weekdays – рабочие дни, weekend – выходные.
Для просмотра созданных «календарей» дайте команду show time-tange:
R0#sh time-range
time-range entry: WORK_DAYS <b>(active)</b>
absolute start 00:00 01 January 2012 end 23:59 31 December 2012
Слово active рядом с названием «календаря» говорит о том, что он активен, т.е. время «календаря» соответствует сейчас текущему времени на роутере.
Теперь давайте используем наш «календарь» в правилах ACL:
ip access-list extended TIME_BASED_ACL
permit tcp 10.0.0.0 0.255.255.255 any eq www <b>time-range WORK_DAYS</b>
permit tcp 10.0.0.0 0.255.255.255 any eq ftp-data <b>time-range ANOTHER_RANGE</b>
Как видите, вы можете использовать разные «календари» для разных правил одного ACL’а. «Календари» вы можете использовать только в расширенных ACL.
Reflexive ACL
Отражающие или зеркальные ACL позволяют несколько расширить возможности фильтрации. По сути, они превращают ACL из packet filtering в stateful inspection брандмауэр. Т.е. теперь роутер будет отслеживать состояние сессий, инициированных из внутренней сети компании, и создавать соответствующие возвратные правила.
Поясню на примере типичной ситуации. Есть внутренняя сеть 192.168.1.0/24. Разрешаем доступ из этой сети в интернет (http) – «зеленый» ACL. Т.е. с помощью этого ACL мы определяем политики выхода из внутренней сети во внешнюю сеть. С помощью второго, «красного» ACL мы защищаем внутреннюю сеть от вторжений извне. Но необходимо разрешить ответы на сессии, инициированные из внутренней сети, поэтому разрешаем возвратный трафик. Вроде бы все логично: разрешили запросы туда, разрешили ответы оттуда. Но при такой конфигурации, мы сильно раскрываем внутреннюю сеть. Любой TCP пакет с 80 порта беспрепятственно попадает во внутреннюю сеть. Добро пожаловать, атакам типа SYN Flood и прочим. Данная проблема легко решается с помощью stateful inspection firewall (CBAC или IOS Firewall), но что делать, если ваша редакция IOS не поддерживает этот функционал? На помощь приходят зеркальные ACL.
Идея состоит в том, что теперь из одного ACL (обычно, «зеленый» — внутренний), пакеты прошедшие проверку будет зеркалироваться или отражаться в правила специального временного ACL, который в свою очередь будет проверяться внешним («красным») ACL.
Посмотрите пример. Для определенных правил в «зеленом» ACL мы используем параметр reflect и указываем имя временного ACL (в примере, MIRROR), куда будут отражаться правила. В «красном» ACL мы проверяем временный зеркальный ACL: команда evaluate. Можете рассматривать эту команду, как возможность проверить один ACL внутри другого, т.е. команда будет заменена набором правил из временного ACL.
Пока не открыты сессии из внутренней сети, зеркальный ACL пустой, не содержит никаких правил:
Extended IP access list EXTERNAL
10 evaluate MIRROR
20 deny ip any any log
Extended IP access list INTERNAL
10 permit ip any any reflect MIRROR (2 matches)
Reflexive IP access list MIRROR
Но как только будут открываться сессии, зеркальный ACL начнет заполняться:
R1#sh access-li
Extended IP access list EXTERNAL
10 evaluate MIRROR
20 deny ip any any log (5 matches)
Extended IP access list INTERNAL
10 permit ip any any reflect MIRROR (36 matches)
Reflexive IP access list MIRROR
permit icmp host 2.2.2.2 host 192.168.1.1 (19 matches) (time left 289)
permit tcp host 192.168.2.1 eq telnet host 192.168.1.1 eq 62609 (30 matches) (time left 286)
permit ospf host 224.0.0.5 host 192.168.1.1 (6 matches) (time left 297)
В примере из внутренней сети с адреса 192.168.1.1 был запущен пинг на адрес 2.2.2.2, затем открыто telnet-соединение с внутреннего адреса 192.168.1.1 на внешний адрес 192.168.2.1. На примере telnet-соединения хорошо видна выполненная последовательность действий:
- Внутренний хост инициирует соединение с адреса 192.168.1.1 и случайно выбранного порта 62609 на адрес внешнего хоста 192.168.2.1, порт 23 (telnet).
- Пакеты проверяются INTERNAL ACL, разрешены строкой: 10 permit ip any any reflect MIRROR
- Отражаются в MIRROR ACL: permit tcp host 192.168.2.1 eq telnet host 192.168.1.1 eq 62609
- Ответы извне проверяются EXTERNAL ACL, содержащим ссылку на MIRROR ACL: evaluate MIRROR.
Возвратный трафик в итоге разрешен. Если бы произошла попытка отрыть любое соединение до внутренней сети извне, то оно было бы запрещено: deny ip any any log.
В общем, легким движением руки ACL почти превратился в stateful inspection firewall.
Dynamic (Lock-and-Key) ACLs
Следующая категория ACL – динамические. В основном, эти ACL используются для удаленных подключений к сети компании, но можете и использовать их тогда, когда подключение к различным ресурсам требует предварительной аутентификации. Представьте, что администраторам требуется постоянные подключения к сети компании, но подключаться они будут из разных мест, с разных IP-адресов. Идея динамических ACL, состоит в том, что человек должен сначала пройти аутентификацию и только в случае успеха будет применен ACL, разрешающий доступ к ресурсам сети. Алгоритм следующий:
Пользователь подключается к роутеру с любого (настраивается) адреса.
Пользователь проходит аутентификацию.
После успешной аутентификации, на интерфейсе активируются специальные правила динамического ACL.
Правила остаются активными в течение настраиваемого периода времени.
Что требуется для конфигурации динамических ACL:
- Создать расширенный ACL, разрешающий telnet или SSH подключения к роутеру. Эти протоколы будут использоваться для подключения к роутеру.
- Определить параметры аутентификации. Поддерживается локальная аутентификация, AAA, пароль на vty портах.
- Настроить параметры динамического ACL.
Давайте все разберем на следующем примере:
Пользователю требуется подключение к серверу 192.168.1.1 на порт 80 во внутренней сети. Адреса, с которых будет происходить подключение, нам не известны. Первым делом, создаем расширенный ACL, разрешающий telnet подключения к роутеру (адрес 1.1.1.1) и содержащий записи динамического ACL, затем применяем его на нужный интерфейс:
ip access-list extended TELNET-IN
permit tcp any host 1.1.1.1 eq telnet (1)
dynamic DYNAMIC-ACL-NAME permit tcp any host 192.168.1.1 eq www (4)
deny ip any any
!
int s0/0
description CONNECTED TO EXTERNAL NETWORK
ip address 1.1.1.1 255.255.255.0
ip access-group TELNET-IN in
Следующим шагом настраиваем аутентификацию. Я буду использовать локальную аутентификацию, поэтому создаю пользователя root и включаю локальную аутентификацию на vty портах:
username root secret USERS_PASSWORD (2)
!
line vty 0 4
login local (2)
autocommand access-enable host timeout 10 (3)
Команда autocommand access-enable активирует аутентификацию и включает записи динамического ACL. Параметр host является опциональным. При его использовании any в качестве IP-адреса источника в динамическом ACL будут заменены на адрес, с которого пользователь подключается. Параметр timeout определяет период бездействия в минутах для данной сессии, по умолчанию — бесконечен.
Как будет происходить процесс получения доступа в приведенном примере:
- Пользователь открывает telnet подключение к роутеру на адрес 1.1.1.1. Разрешено правилом расширенного ACL (1).
- Фаза локальной аутентификации (2).
- В случае успешной аутентификации, автоматически выполняется команда access-enable (3), активирующая правила динамического ACL (4). Telnet соединение закрывается.
- Пользователь получает доступ в соответствии с правилами динамического ACL.
Заключение
Как видите ACL в Cisco IOS обладают очень интересными возможностями, учитывая, что это базовый функционал фактически любого IOS. Очень многое конечно осталось за кадром: ACL и QoS, rate limits. И тем более, такие темы как CBAC, Zone-based Firewall и д.р. Спасибо за прочтение.
Автор: softline_education
