antiCisco blogs


блоги по технологиям и оборудованию cisco от инструкторов

Опубликовано 5 Август , 2012

Хоть мы с Вами ранее уже и познакомились с технологией ZFW, но ее предшественником был CBAC. Поскольку данная тема входит в трек CCIE Security v4.0, то надеюсь, что данная статья будет кому-то полезна.

CBAC – фича Cisco IOS, которая позволяет маршрутизатору выступать в качестве сетевого фаирволла. Работает он примерно следующим образом: прилетает пакет на входной интерфейс (т.е. некий хост из внутренней сети пытается установить сессию с хостом из внешней сети), если на нем настроено правило фаирволла и пакет под это правило попадает, то маршрутизатор сохраняет подробную информацию о таком пакете (например – IP-адреса источника и пункта назначения, tcp/udp порты и пр.) и далее этот пакет вылетает во внешний мир. Через какое-то время приходит ответ на только что улетевший пакет и даже если на интерфейсе стоит правило типа deny any, то ответный пакет пропускается (т.к. запись о сессии хранится в памяти маршрутизатора).

Настраивается CBAC в несколько шагов:

— дается команда ip inspect name <NAME> <PROTOCOL>, где PROTOCOL – протокол, который необходимо инспектировать.

— политика inspect применяется на интерфейс командой ip inspect <NAME> <in|out>

Рассмотрим на примере. Имеется следующая топология:

Необходимо разрешить доступ от R1 к R3 по TCP-портам 23 и 80 (telnet и http), а также ping.

Значимая базовая настройка на R2 следующая:

ip access-list extended ACL_OUTSIDE-IN
 900 deny ip any any log-input
interface Serial 1/0
 ip access-group ACL_OUTSIDE-IN in

Первым делом включаем инспекцию telnet, http и icmp-трафика

ip inspect name CBAC_IN-OUT telnet
ip inspect name CBAC_IN-OUT http
ip inspect name CBAC_IN-OUT icmp

Применяем политику фаирволла.

interface Serial 1/0
 ip inspect CBAC_IN-OUT out

Попробуем инициировать пробные пакеты с R1:

R1#150.1.3.3
Trying 150.1.3.3 ... Open
R1#150.1.3.3 80
Trying 150.1.3.3, 80 ...
% Connection refused by remote host

 

R1#ping 150.1.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/72/100 ms

Как видим, все работает. Если попытаться инициировать соединение по протоколу, который не указан в правиле  ip inspect, то увидим, что связи нет. (Тут у Вас могут появиться вопросы по поводу telnet на 80 порт – отвечаю сразу, что в таком случае Cisco IOS посылает команду GET).

R1#150.1.3.3 90
Trying 150.1.3.3, 90 ...
% Connection timed out; remote host not responding
R2#
*Aug  5 00:19:02.595: %SEC-6-IPACCESSLOGP: list ACL_OUTSIDE-IN denied tcp 150.1.3.3(90) (Serial1/0 ) -> 136.1.12.1(20818), 1 packet

Если хотите в режиме реального времени наблюдать за работой CBAC, то необходимо дать команду ip inspect audittrail

В этом случае, если пакет попадает под действие правила фаирволла, увидим примерно следующее:

R1#150.1.3.3
Trying 150.1.3.3 ... Open
R2(config)#
*Aug  5 00:22:23.503: %FW-6-SESS_AUDIT_TRAIL_START: Start telnet session: initiator (136.1.12.1:65085) -- responder (150.1.3.3:23)
R3>logout
[Connection to 150.1.3.3 closed by foreign host]
R2(config)#
*Aug  5 00:22:43.279: %FW-6-SESS_AUDIT_TRAIL: Stop telnet session: initiator (136.1.12.1:65085) sent 32 bytes -- responder (150.1.3.3:23) sent 41 bytes

Посмотреть статистику пакетов можно командой show ip inspect statistics

R2#show ip inspect statistics
Packet inspection statistics [process switch:fast switch]
  tcp packets: [5:97]
  icmp packets: [0:10]
Interfaces configured for inspection 1
Session creations since subsystem startup or last reset 5
Current session counts (estab/half-open/terminating) [0:0:0]
Maxever session counts (estab/half-open/terminating) [1:1:1]
Last session created 00:02:06
Last statistic reset never
Last session creation rate 0
Maxever session creation rate 3
Last half-open session total 0
TCP reassembly statistics
  received 0 packets out-of-order; dropped 0
  peak memory usage 0 KB; current usage: 0 KB
  peak queue length 0

Какие протоколы инспектируются, можно увидеть следующим образом

R2#show ip inspect name CBAC_IN-OUT
Inspection name CBAC_IN-OUT
    telnet alert is on audit-trail is on timeout 3600
    http alert is on audit-trail is on timeout 3600
    icmp alert is on audit-trail is on timeout 10

И если Вы сомневаетесь туда ли повесили правило CBAC, в том ли направлении, то полезной будет команда show ip inspect interfaces

R2#show ip inspect interfaces 
Interface Configuration
 Interface Serial1/0
  Inbound inspection rule is not set
  Outgoing inspection rule is CBAC_IN-OUT
    telnet alert is on audit-trail is on timeout 3600
    http alert is on audit-trail is on timeout 3600
    icmp alert is on audit-trail is on timeout 10
  Inbound access list is ACL_OUTSIDE-IN
  Outgoing access list is not set

Все что мы с Вами рассмотрели выше – так называемая базовая настройка CBAC. Теперь поговорим о его тюнинге. А если быть точнее, то как с его помощью защищаться от DoS-атак. Но сначала немного «вводной».

Полуоткрытыми TCP соединениями называют сессии, которые не прошли полностью через рукопожатие SYN-SYN/ACK-ACK. Большое количество таких соединений может указывать на зловредную активность в вашей сети, например на DoS-атаку. Один из видов атак – SYN атаки, в которых злоумышленник посылает большое количество SYN-пакетов на сервер с подделанными IP-адресами источниками. Естественно, такие сессии подвисают в полуоткрытом состоянии, поскольку атакуемый сервер будет ждать финального подтверждения ACK.

Также Cisco IOS понимает «незакрытые» UDP сессии. В терминах IOS это такая сессия, в рамках которой трафик идет только в одну сторону, но не в обратную.

Технология CBAC позволяет ограничивать количество различных сессий, для защиты конечных серверов от DoS.

Первыми полезными командами будут

ip inspect max-incomplete high <A>
ip inspect max-incomplete low <B>

Читать эту запись следует так: если общее количество полуоткрытых сессий (как TCP так и UDP в сумме) будет выше, чем число <A>, то фаирволл начинает отбрасывать «старые» запросы на установление сессий чтобы передать новый запрос до тех пор, пока число полуоткрытых сессий не опустится до числа <B>. Указанные пороги задаются либо глобально, либо на vrf-таблицу. При превышении высшего порога, генерируется syslog-сообщение.

Также можно указать фаирволлу следить не только за количеством полуоткрытых сессий, но и отслеживать их частоту (за минуту) командами ip inspect oneminute high <A> и ip inspect oneminute low <B>.

Довольно часто DoS-атака направлена не целиком на сеть, а на конкретный хост внутри нее. Можно отслеживать количество полуоткрытых сессий, которые висят на одном IP-адресе (только для TCP). Для этого служит команда ip inspect tcp max-incomplete host <A>. Опциональным параметром этой команды является blocktime <B>, который интерпретируется следующим образом: при достижении host-лимита на число полуоткрытых сессий, фаирволл удаляет все существующие незавершенные TCP-сессии и блокирует любые новые запросы на установление сессии на период времени <B>. Однако, если параметр времени установлен в значение “0”, то логика работы несколько иная: при поступлении нового запроса на соединение, фаирволл удаляет самую старую запись о полуоткрытом соединении и перенаправляет пришедший запрос по направлению.

Наверное при прочтении статьи до указанного места, у вас мог возникнуть вопрос: а сколько же фаирволл будет ждать завершения установления TCP-сессии? Команда ip inspect tcp synwaittime определяет как долго Cisco IOS будет ждать установления TCP-сессии перед её дропом. Таймер начинает считать время после того, как фаирволл заметит SYN-пакет инициализации сессии.

Иногда бывают ситуации, при которых сессия установилась, вроде все идет в порядке и тут хост отправляет FIN-флаг, но подтверждение с удаленной стороны все не приходит. Сколько же времени фаирволлу следует держать информацию о сессии у себя в памяти в таблице состояний (state table)? Это время определяется командой ip inspect tcp finwait-time.

Помимо всего прочего, CBAC следит за тем, жива ли установленная TCP сессия. Если Cisco IOS видит, что в течение определенного времени в рамках установленной сессии нет пакетов, то фаирволл прекращает обслуживать данную сессию. Период такого времени задается командой ip inspect tcp idle-timeout.

Похожий параметр есть и для UDP-сессий. Однако, поскольку UDP является протоколом без установления соединения, то и логика CBAC в данном случае несколько иная. Когда фаирволл видит UDP-пакет, для которого настроена инспекция, то заносится запись в таблицу состояний о новой «сессии». Если CBAC не видит пакетов в рамках такой сессии в течении определенного времени, то соответствующая запись удаляется из таблицы. Указанный период времени задается командой ip inspect udp idletimeout.

Прим. Для DNS-запросов таймаут задается отдельно командой ip inspect dnstimeout

Если фаирволл работает в прозрачном режиме, то полезной может быть команда ip inspect L2-transparent dhcppassthrough. Данная команда позволяет проходить DHCP-пакетам через фаирволл, даже если в списке доступа стоит строчка deny any.

 

Метки:
Опубликовано: Безопасность cisco , Маршрутизаторы и коммутаторы

 

2 комментария “Context-Based Access Control”

comment rss - Trackback

  1. Леш, поправь меня, если ошибаюсь.

    Я всегда считал, что max-incomplete high
    задает порог, когда надо начать УДАЛЯТЬ старые полуоткрытые сессии. И удалять их надо до нижнего порога
    max-incomplete low

    Т.е. если high — 500, а low — 400, то при превышении 500 полуоткрытых циска режет старые, пока не останется 400. Тоже и про one-minute

  2. fantas1st0:

    Сереж, конечно.
    Там агрессивный режим работает.
    Фиксед 🙂

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

Вы должны войти чтобы прокомментировать.