Со временем обрывки знаний и умений становится все труднее удержать в голове. Они расползаются по уголкам памяти заполняя все свободное место. Извлекать необходимое на свет становится все сложнее. Этот блог - рабочая записная книжка.

Sunday, March 30, 2008

Modular policy

0. Официальная документация
http://www.cisco.com/en/US/docs/security/asa/asa80/configuration/guide/mpc.html
http://www.cisco.com/en/US/docs/security/asa/asa80/configuration/guide/inspect.html

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

С помощью сервисных политик можно сделать достаточно много интересных вещей например это может быть

- различные операции на уровне TCP/IP;
- отправка трафика на модули ASA - CSC или IPS;
- различные виды QoS;
- инспекция трафика на уровне приложений.

Поскольку активация всех этих прелестей выполняется никак не одной командой, необходимо разбить весь процесс настройки на несколько этапов:
- определение трафика к которому будут применяться правила дополнительной обработки;

- описание действий которые необходимо производить с отобранным трафиком (создание политики);
- привязывание политики к конкретному интерфейсу или глобально.


1. Определение 
Определение трафика подлежащего обработке производиться с помощью конструкции class-map.
Параметров у команды достаточно много, потому просто приведу пару примеров.

// Определенный хост/подсеть, да и вообще всё что можно описать с помощью acl.
// Например создадим class-map для выделения трафика определённого клиента.
ciscoasa(config)# access-list web01 permit ip any host 10.10.12.2 log
ciscoasa(config)# class-map cmap_web01
ciscoasa(config-cmap)# match access-list web01

// class-map отлавливающий весь проходящий http трафик
ciscoasa(config)# class-map cmap_http
ciscoasa(config-cmap)# match port tcp eq 80

Это конечно самые простые способы выделить трафик из общего потока, также можно использовать:
- DSCP;
- RTP;
- tunnel-group, выделяет трафик относящийся к определенному vpn-туннелю;
- весь трафик;
... и некоторые другие


2. Время действий. Обрабатываем трафик.
Самый интересный пожалуй шаг. Для ранее определенного трафика можно начинать выполнять разные действия.
Релизуется это с помощью политик (policy-map), в рамках которой для каждого вышеопределенного class-map
можно задавать необходимые ограничения. Каждая политика может содержать несколько class-map.


Начнем с простого – ограничим скорость закачки по http до 8000 bit/s.
Логично было бы создать политику для интерфейса inside и установить лимит на иходящий трафик
либо политику для интерфейса outside и установить лимит на входящий трафик.
На деле всё иначе.
Вышеуказанный лимит реализуется двумя способами: либо определить политику для интерфейса inside и установить лимит
на входящий трафик либо путем создания политики для интерфейса outside и установки лимита на исходящий трафик.
Выглядит это нелогично, согласитесь. Более того, несмотря на указанные в документации и в подсказке bit/s.я так и не
понял, в чем указывается значение лимита. В моём случае при указании 8000 bit/s я ожидал увидеть ограничение не 8 килобайт в секунду,
однако wget упорно качал с скоростью около 54 килобайт в секунду.
Для любителей конкретики: это было проверено на двух версиях прошивки 7.23 и 8.02.


Вот так могут выглядеть примеры конфигурации:

// Определяем политику
ciscoasa(config)# policy-map pmap_inside

// В рамках политики выделяем class-map над которым будем производить действия, их может быть несколько.

ciscoasa(config-pmap)# class cmap_http

// В рамках конкретного class-map применяем действие, а данном случае лимит на 8000 bit/s.

ciscoasa(config-pmap-c)# police input 8000

//Аналогично для второго описанного случая
ciscoasa(config)# policy-map pmap_outside
ciscoasa(config-pmap)# class cmap_http
ciscoasa(config-pmap-c)# police output 8000

Конечно же всё выяснилось. Проблема описанная выше встречается только если выделять трафик с по определённому порту.
В данном случае это был порт 80. Если же указать на трафик с помощью acl по адресам, всё начинает работать как и было описано в документации.


//Например
access-list inside_host extended permit ip any host 10.10.11.2 log
class-map cmap_down
match access-list inside_host
policy-map pmap_outside
class cmap_down
police input 8000
service-policy pmap_outside interface outside


Действительно устанавливается лимит на 1 килобит.

В качестве примера манипуляций с TCP/IP приведу пример уже знакомый постоянным читателям блога.
В заметке о конфигурации NAT я рассказывал как firewall может
бороться с SYN-flood атаками перехватывая сессии до полной завершения установки соединения.
Проведем те же манипуляции, только обойдемся без NAT, который нужен далеко не всегда.

// Включение перехвата установки соединений, для всего трафика определённого в class-map cmap_BigClient
ciscoasa(config)# policy-map pmap_outside
ciscoasa(config-pmap)# class cmap_web01
ciscoasa(config-pmap-c)# set connection embryonic-conn-max 1

Фактически с помощью данного способа можно реализовать достаточно широкий функционал как
различного вида лимитированием так и нормализацией потока tcp.
Тема достаточно большая, возможно позже я напишу отдельную заметку по этому поводу.




3. Применение к интерфейсу
Конкретная политика применяется с помощью команды service policy, синтаксис следующий:

// применение политики pol_out к интерфейсу outside
ciscoasa(config)# service-policy pol_out interface outside

Зоркий глаз опытного цисковода конечно обратит внимание, что команда по сути аналогична
по действиям команде access-group привязывающей конкретный acl к интерфейсу.
Так это и есть, отличие в том, что политика может быть глобальной. Кроме конкретных политик для интерфейсов
существует одна, большая, для всех сразу. Конечно её можно менять по своему усмотрению.

// изменение глобальной политики
ciscoasa(config)# service-policy pol_global global

Глобальная политика единственная, для которой существуют параметры по-умолчанию.

Нераскрытой осталась тема фильтрации трафика на более высоких уровнях модели OSI, так называемый application
inspection. Это отдельная большая тема, хотя команды конфигурирования похожи.


4 comments:

xumuk said...

день добрый.
занимаюсь настройкой ASA 5510 -ASA 8.04 .
правила на прохождение между интерфейсами настроил.
стали проверять. всё работает.
если удалить дефолтную инспекцию трафика то трафик отказывается ходить и по PT и на реальном моделировании.
Везде встречал лишь то что для ICMP необходимо включать инспекцию если хотим не создавать 2 правила на in и out.
Но нигде не сказано, что если не будет вообще какой либо инспекции то трафик не будет вообще ходить между интерфейсами.
Проверяли на ftp и MS SQL протоколах.
Если несложно не могли бы пояснить этот момент.
В книжке cisco-asa-pix-and-fwsm-firewall-handbook - не нашёл вообще про это. Судя по ней досточно просто правила in но так точно не хочет работать. Хотя мало ли может не коректная настройка.

Спасибо

pablo said...

xumuk, я так понимаю, что вы смотрите на прохождение трафика с inside на outside?
Т.е. с интфейса с большим значением security-level на интерфейс с меньшим. В этом случае не нужен acl, а пакеты будут инспектироваться согласно dafault policy. При этом для протоколов использующих несколько портов (например ftp, и похоже ms sql) необходимо указывать инспекцию явно. Для простых (http например) этого не требуется. Для них сработает стандартный stateful механизм. В случае того же ftp (active если я их не путаю опять. :) ), требуется два порта - 21/tcp на сторне сервера и один из динамически открываемых "высоких" портов на стороне клиента. В случае выключеной инспекции ftp, второе соединение (от сервера к клиенту) будет заблокированно асой. То же самое и в случае icmp. Echo-request будет переслан, а вот ответы будут заблокированы.
Надеюсь я правильно понял вопрос и более-менее внятно объяснил. :)

xumuk said...

pablo именно то. это меня и интересовало.
но вот допустим MS SQL. это прсото включить инспекцию по порту 1433 ?
Тогда получается он просто будет следить за данным портом непонимая кто это и что делает, но будет разрешать динамически выделяемые порты, т.к. существуют предопределённые инспекции т.е. виды трафика о которых знает ASA и с которыми умеет себя вести определённым образом.
И в итоге имеем картину:
Есть сервис фиг знает какой, если он не работает то необходимо настраивать для него инспекцию, либо изучать механихм его работы и тогда решать включать инспекцию или нет.
Спасибо за разъяснения, мои предположения подтвердились. Буду изучать вопрос глубже.

pablo said...

xumuk, в общем случае специальная инспекция нужна для протоколов с динамически выделяемыми портами и соединениями инициируемыми со стороны сервера. Если протокол использует всего один порт, то обычного stateful хватает.
В случае если вам необходим дополнительный контроль, например инспекция sql запросов, для этого существуют специальные железяки. АСА всего лишь, интегрированое решение подходящее для большинства типичных задач.
Босюь ошибиться, но вроде бы, Cisco ACE умеет делать полноценную инспекцию sql (с защитой от SQL injection например).