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

Showing posts with label theory. Show all posts
Showing posts with label theory. Show all posts

Monday, June 30, 2008

Мы будем жить теперь по новому! (zone-based firewall)

0. Ссылки
http://www.cisco.com/en/US/products/sw/secursw/ps1018/products_tech_note09186a00808bc994.shtml
http://www.cisco.com/en/US/products/sw/secursw/ps1018/products_configuration_example09186a00809492a4.shtml

Начиная с версии IOS 12.4(6)T в рутерах Cisco появилась функциональность называемая Zone-Based Firewall, именно она призвана заменить собой классический firewall (CBAC). В чем отличие, какие основные возможности я и попробую ответить в этой заметке.

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

Основное отличие модели ZBF от CBAC в том, что первый, как очевидно из названия, оперирует на уровне зон, второй на уровне интерфейсов. Второе значительное улучшение -позможность применения политики в определенному трафику. Дело в то том, что в классическом CBAC невозможно применять к различные политики к различным группам трафика в пределах одного интерфейса. К примеру, если за внутренним интерфейсом находиться не одна сеть, а несколько, то в случае CBAC применять для них различные политики инспектирования
не представляется возможным. С ZBF же это достаточно тривиальная задача.
Синтаксис конфигурации, называемый Cisco Policy Language (CPL) достаточно похож на MPF в устройствах ASA.

Несколько фактов облегчающих понимание "как это работает".
- Зона может состоять из интерфейса или нескольких интерфейсов.
- Политика применяется к направлению между зонами. Т.е. inside-outside и outside-inside это две разных политики.
- Важное изменение, политика по умолчанию - deny any any.
- Можно использовать CBAC и ZBF одновременно, но на разных интерфейсах.
- Если два интерфейса не принадлежат ни к одной зоне - трафик разрешен.
- Если один из интерфейсов принадлежит к какой-либо зоне, другой нет - трафик запрещен.
- Если два интерфейса принадлежат к разным зонам - трафик запрещен до явного разрешения.
- Трафик в пределах одной зоны не подвергается инспектированию.

Элементы конфигурации:
class-map - служит для выделения конкретного трафика из потока, например с помощью acl или выделение по протоколам. Может быть вложенным, т.е. можно выделить трафик с source 192.168.0.0/24 по протоколу http.
policy-map - применение политики, Существует всего три возможных действия - drop, pass, inspect.


Стенд


Конфигурация сети следующая:
insideA - 10.10.11.1/24
insideB - 10.10.12.1/24
outside - 10.10.10.1/24
dmzA - 10.10.20.1/24

2. Базовая модель

Начнем с простейшей конфигурации. Забудем пока о наличии ДМЗ и решим самую типичную задачу - предоставление доступа в интернет с инспектированием трафика. Все, остальные конфигурации по сути своей будут строиться на этой как на базовой. Здесь же удобно рассмотреть основные командыконфигурирования, комментарии по тексту.

// определим зоны безопасности, в данном случае только две интернет и интранет
// никакого применения политик пока нет - просто имена.
R1(config)#zone security outside
R1(config-sec-zone)#description Big and Scary internet

R1(config)#zone security inside
R1(config-sec-zone)# description Shy and modest intranet

// назначим интерфейсы в зоны, необходимо учитывать,
// что сразу после
этого шага любой трафик между зонами будет запрещен
// ouside
R1(config)#interface FastEthernet0/0
R1(config-if)#zone-member security outside
R1(config-if)#description ouside

//inside, растянутый на два интерфейса
R1(config)#interface FastEthernet0/1.800
R1(config-subif)#description insideB
R1(config-subif)#zone-member security inside

R1(config)#interface FastEthernet0/1.900
R1(config-subif)#description insideA
R1(config-subif)#zone-member security inside

Ну вот и отлично, всё что можно запретили - безопасность на уровне. :)
Теперь займемся разрешением.

// определение протоколов по которым пользователям разрешен в интернет,

// например, http, smtp, dns
// class-map может быть двух типов - с логикой AND и с логикой OR. В
// данном случае OR - любой из трех протоколов
R1(config)#class-map type inspect match-any cm_http-dns-smtp
R1(config-cmap)#match protocol http
R1(config-cmap)#match protocol smtp
R1(config-cmap)#match protocol dns

// это пример class-map с логикой AND. Данная карта выбирает
// фильтрует трафик с source 10.10.12.0/24 и любым из протоколов http, dns, smtp
R1(config)#access-list 120 permit ip 10.10.12.0 0.0.0.255 any
R1(config)#class-map type inspect match-all cm_insideB_web
R1(config-cmap)#match class-map cm_http-dns-smtp
R1(config-cmap)#match access-group 120

//создание политики
R1(config)#policy-map type inspect in-out
R1(config-pmap)#class type inspect cm_insideB_web
R1(config-pmap-c)#inspect

// Момент истины, создадим цепочку inside -> outside и наделим
// интернетом счастливых пользователей insideB
R1(config)#zone-pair security inside-outside source inside destination outside
R1(config-sec-zone-pair)#service-policy type inspect in-out

Еще раз хочу обратить внимание, при всей этой конфигурации трафик в
пределах зоны, т.е. между интерфейсами insideA и insideB разрешен.

3. Усложненная конфигурация.

Усложняется она использованием ДМЗ, все остальные параметры остаются теми же.

//Определим новую зону и назначим её интерфейсу
R1(config)#zone security dmz
R1(config-sec-zone)#description Controlled DMZ
R1(config)#int fa0/1.700
R1(config-subif)#zone-member security dmz


//выделим сервер или группу подлежащую публикации
R1(config)#access-list 199 remark Publishing web server
R1(config)#access-list 199 permit ip any host 10.10.20.2


//определим по каким протоколам серверы будет виден снаружи
R1(config)#class-map type inspect match-all pub-web
R1(config-cmap)#match access-group 199
R1(config-cmap)#match protocol http


//создадим политику разрешающую доступ
R1(config)#policy-map type inspect www-dmz
R1(config-pmap)#class type inspect pub-web
R1(config-pmap-c)#inspect

//создадим цепочку outside -> dmz
R1(config)#zone-pair security out-dmz source outside destination dmz

Теперь сервер 10.10.20.2 доступен в интернет по протоколу http, если
необходимо добавить еще один сервер достаточно просто изменить acl 199

Wednesday, January 23, 2008

Много-в-одном

Среди множества возможностей устройств PIX/ASA есть довольно интересные. Одна из таких - разделение одного физического firewall на несколько виртуальных. Количество, собственно, зависит от приобретенной лицензии. Т.е. прямой зависимости между мощностью железяки и количеством виртуальных firewall нет. Конечно есть табличка в которой примерно обозначены рекомендуемые нагрузки для каждой модели из серии, но всё же это больше зависит от количества денег.
Допустимое количество контекстов можно увидеть с помощью команды show version.

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

1. А зачем?
В терминологии Cisco виртуальные firewall называются контекстами. В дальнейшем будем использовать именно эту терминологию. Режимы работы называются соответственно одноконтекстный и мультиконтекстный. Посмотреть текущий режим можно командой showmode. В режиме поддержки виртуальных firewall не поддерживаются некоторые возможности:
- динамические протоколы маршрутизации;
- виртуальные частные сети;
- мультикаст рутинг;
- обнаружение угроз (сканирование портов, TCP SYN flood, прочие).

Как видно многие приятные и удобные функциональные возможности становятся недоступными в мультиконтекстном режиме. Что же заставляет пользователей выбирать этот режим работы? Сама компания Cisco Отвечает на это вопрос следующим образом видит такие сферы применения:
- сервисный провайдер который предлагает дополнительные услуги своим клиентам. Вплоть до отдачи управления виртуальным firewall;
- большое предприятие либо студенческий кампус, желающий разделять трафик различных подразделений;
- большое предприятие использующее различные политики безопасности для разных департаментов.

2. Что внутри?
Переходим от маркетинга к практике. Контексты бывают трех видов:
- системный
Системное пространство в котором создаются виртуальные контексты и задаются их параметры. Здесь же настраиваются ассоциации интерфейсов с пользовательскими контекстами. Не имеет никакой сетевой конфигурации и не может использоваться как обычный контекст. При необходимости доступа к сетевым ресурсам использует административный контекст.
- административный
Полноценный виртуальный firewall, но используется в основном для управления физическим устройствам и остальными контекстами. Может использоваться как обычный контекст, но не рекомендуется его использование как пользовательского поскольку пользователь имеющий права доступа к административному контексту по сути имеет права для доступа к любому другому.
- пользовательский
Собственно то ради чего всё это и затевалось. Полноценный виртуальный firewall с отдельной политикой безопасности и выделенными интерфейсами.
Практически всё что может быть настроено на физическом устройстве в одноконтекстном режиме может быть настроено в данном виртуальном.

Каждый пакет поступающий на интерфейсы физического устройства необходимо классифицировать для определения в какой именно виртуальный firewall его отправить. В случае если интерфейс закреплен только за одним виртуальным firewall это проблем не вызывает. Однако при использовании разделенных интерфейсов возникает дополнительная обработка с своими правилами.
Для определения контекста назначения используется специальный классификатор занимающийся определением. В случае разделенных интерфейсов классификатор зачастую не может однозначно определить пункт назначения, однако предусмотрен ряд "подсказок" помогающий определить где находятся искомые сети.
- уникальные МАС-адреса
Есть возможность назначить одному интерфейсу разные МАС адреса в пределах одного контекста. Также можно использовать команду mac-address auto для автоматического назначения адресов.
- NAT
Может использоваться как конфигурация с nat/global так и обыкновенный static, ожидаемо, что в первом случае входящие соединения будут невозможны.

3. Рассмотрим пример
В качестве примера выбрана типичная конфигурация с общим (разделенным) внешним интерфейсом и уникальными внутренними. Два клиента А и В, у клиента А также присутствуетweb-сервер для которого решено организовать демилитаризованную зону.
Итак существующие интерфейсы:
ethernet 0/0 - admin_outside - 10.10.3.1/26
ethernet 0/0 - outsideA - 10.10.3.129/26
ethernet 0/0 - outsideB - 10.10.3.65/26
ethernet 0/1.11 - dmzA - 10.1.1.1/24
ethernet 0/2.21 - insideA - 10.2.1.1/24
ethernet 0/2.22 - insideB - 10.2.2.1/24


3.1. Внимание! Переключаю!

Первым делом необходимо изменить режим функционирования устройства с помощью команды mode <режим>

ciscoasa(config)# mode multiple
WARNING: This command will change the behavior of the device
WARNING: This command will initiate a Reboot
Proceed with change mode? [confirm]
Convert the system configuration? [confirm]

При переходе в другой режим работы железяка предлагает сконвертировать конфигурацию в новый режим. При этом настройки всех интерфейсов активных в обычном режиме будут перенесены без изменений в административный контекст. Т.е. операцию можно проводить удалённо, потери соединения не будет. В данном случае при подготовке к миграции была удалена вся конфигурация кроме конфигурации интерфейса ethernet 0/0 который в дальнейшем будет выполнять роль разделенного outside. После перезагрузки и миграции конфигурации:

$ ssh admin@10.10.3.1
admin@10.10.3.1's password:
Type help or '?' for a list of available commands.
ciscoasa/admin> en
Password:
ciscoasa/admin#

Первым визуальным признаком работы в мультиконтекстном режиме является измененный вид приглашения, кроме hostname отображается название текущего контекста. Также режим работы можно просмотреть с помощью команды show mode:

ciscoasa/admin# sh mode
Security context mode: multiple

3.2. Системный контекст

Для перехода между контекстами используется команда changeto context <имя контекста>. Как упоминалось раньше создание сабинтерфейсов и ассоциация их с виртуальными firewall выполняется из системного контекста. Переходим в него и создаем интерфейсы описанные выше.

ciscoasa/admin# changeto system
ciscoasa# conf t

ciscoasa(config)# interface ethernet 0/1.11
ciscoasa(config-subif)# vlan 11
ciscoasa(config-subif)# description DMZ for customer A
ciscoasa(config-subif)# no sh

ciscoasa(config-subif)# exit
ciscoasa(config)# interface ethernet 0/2.21
ciscoasa(config-subif)# vlan 21

ciscoasa(config-subif)# description inside for customer A
ciscoasa(config-subif)# no sh

ciscoasa(config-subif)# exit
ciscoasa(config)# interface ethernet 0/2.22
ciscoasa(config-subif)# vlan 22
ciscoasa(config-subif)# description inside for customer B
ciscoasa(config-subif)# no sh

ciscoasa(config-subif)# exit


Переходим к активной фазе - создаем контексты и ассоциируем их с виртуальными устройствами.
Команды выполняются из системного контекста.

//Создадим контексты
ciscoasa(config)# context CustA
Creating context 'CustA'... Done. (2)

ciscoasa(config-ctx)# context CustB
Creating context 'CustB'... Done. (3)

// Необходимо указать где хранить конфигурацию контекста. Для этого служит команда config-url. Параметры достаточно разнообразны - tftp, http, прочие.
// В данном случае будем хранить конфигурацию на flash. При указании конфига firewall пытается его загрузить. Если не находит пытается создать.
ciscoasa(config-ctx)# config-url flash:/CustA.cfg
INFO: Converting flash:/CustA.cfg to disk0:/CustA.cfg
WARNING: Could not fetch the URL disk0:/CustA.cfg
INFO: Creating context with default config

ciscoasa(config-ctx)# config-url flash:/CustB.cfg
INFO: Converting flash:/CustB.cfg to disk0:/CustB.cfg
WARNING: Could not fetch the URL disk0:/CustB.cfg
INFO: Creating context with default config


// Следующий шаг - ассоциация созданных интерфейсов. Необходима команда - allocate-interface <физический интерфейс> <виртуальное имя>.
// Дополнительным параметром invisible/visible можно указать будет ли физическое имя интерфейса видно из виртуального контекста.
// Например, в данном случае нет никакого желания, чтобы пользователь видел номер его vlan. Значение по-умолчанию invisible.

ciscoasa(config)# context CustA
ciscoasa(config-ctx)# allocate-interface Ethernet0/0 outside
ciscoasa(config-ctx)# allocate-interface Ethernet0/1.11 dmzA
ciscoasa(config-ctx)# allocate-interface Ethernet0/2.21 insideA
ciscoasa(config-ctx)# exit
ciscoasa(config)# context CustB
ciscoasa(config-ctx)# allocate-interface Ethernet0/0 outside
ciscoasa(config-ctx)# allocate-interface Ethernet0/2.22 insideB
ciscoasa(config-ctx)# exit


Проверить текущую конфигурацию можно командой show context. В данном случае видно какие контексты созданы и какие интерфейсы им выделены.

ciscoasa# sh context
Context Name Class Interfaces URL
*admin default Ethernet0/0 disk0:/admin.cfg
CustA default Ethernet0/0,Ethernet0/1.11, disk0:/CustA.cfg
Ethernet0/2.21
CustB default Ethernet0/0,Ethernet0/2.22 disk0:/CustB.cfg

Total active Security Contexts: 3

3.3. Конфигурация виртуальных контекстов

Настройка сетевой конфигурации в контексте CustA.

ciscoasa/CustA# conf t
ciscoasa/CustA(config)# int outside
ciscoasa/CustA(config-if)# nameif outside
INFO: Security level for "outside" set to 0 by default.
ciscoasa/CustA(config-if)# ip address 10.10.3.2 255.255.255.0
ciscoasa/CustA(config-if)# no sh
ciscoasa/CustA(config-if)# exit
ciscoasa/CustA(config)# int insideA
ciscoasa/CustA(config-if)# security-level 100
ciscoasa/CustA(config-if)# nameif insideA
ciscoasa/CustA(config-if)# ip addre 10.2.1.1 255.255.255.0
ciscoasa/CustA(config-if)# no sh
ciscoasa/CustA(config-if)# exit
ciscoasa/CustA(config)# int dmzA
ciscoasa/CustA(config-if)# nameif dmzA
ciscoasa/CustA(config-if)# security-level 50
ciscoasa/CustA(config-if)# ip addre 10.1.1.1 255.255.255.0
ciscoasa/CustA(config-if)# no sh
ciscoasa/CustA(config-if)# exit

// При такой конфигурации работать ничего не будет. Необходимо перейти в системный контекст и настроить уникальные адреса
ciscoasa(config)# mac-address auto

// Исходящий трафик благополучно уходит. Подобного же эффекта можно добится с помощью команд NAT в контексте CustA.
ciscoasa/CustA# conf t
ciscoasa/CustA(config)# global (outside) 1 interface
ciscoasa/CustA(config)# nat (dmzA) 1 10.1.1.0 255.255.255.0
ciscoasa/CustA(config)# nat (insideA) 1 10.2.1.0 255.255.255.0

// Для почтового сервера находящегося в dmzA необходимо установить статическую трансляцию
static (dmzA,outside) 10.10.3.130 10.1.1.2 netmask 255.255.255.255

// Если в dmz находятся хосты с реальными адресами на интерфейсах можно поступить следующим образом.
ciscoasa/CustA(config)# static (dmzA,outside) 100.100.100.0 100.100.100.0 netmask 255.255.255.0

3.4. "Вам не положено!". Кратко и лимитах.

Для каждого виртуального контекста есть возможность задавать лимиты различного типа. Например ограничение на количество сессий ssh или ASDM.
Также интересным вариантом может быть ограничение на количество осуществленных трансляций, соединений внутренних хостов. Указывать можно в абсолютных величинах либо в процентном отношении.
Конфигурируется это достаточно просто.
// Для начала надо создать класс обслуживания.
ciscoasa(config)# class bronze

// Введем некоторые ограничения. Например не более двух сессий ssh.
ciscoasa(config-class)# limit-resource ssH 2

// Применим к определенному контексту
ciscoasa(config)# context CustA
ciscoasa(config-ctx)# member bronze

Monday, November 19, 2007

ASA Firewall operation


Что происходит с пакетом попадающим внутрь PIX/ASA firewall, по каким параметрам принимается решение пропускать пакет дальше или нет?

Прежде всего, замечу, что минимальными требованиями к пакету являются:
- настроеная трансляция адресов между интерфейсми. Конечно, это требование можно отключить с помощью команды no nat-control, однако поведение по умолчанию именно такое;
- политика доступа (access-list) разрешающая доступ.

Минимальные условия это конечно здорово, но жизнь была бы слишком скучна, правда? :)
Попробуем разобратся, что происходит на каждом шаге.
К сожалению я не нашел подобной информации на сайте производителя. Зато под рукой оказалась замечательная книга "Cisco ASA PIX and FWSM Handbook" из которой и почерпнута это информация.

1. Initial Checking

Базовые проверки на целостность пакета, допустимые опции и прочее.
Именно на этом этапе проводится проверка Reverse Path Forwarding про которую я уже рассказывал.
Отмечу, что RPF будет полноценно работать только в случае спуфинга адресов между интерфейсами. В классическом случае outside - ASA - inside спуфинг на outside интерфейсе определить он не сможет.

2. Xlate lookup (outbound)

Именно сейчас проверяется одно из минимальных условий - трансляция адресов между интерфейсами.
Совершенно неважно будет это статическая трансляция one to one или динамическая с применением overload.
Сначала firewall попытается найти уже существующую трансляцию (можно посмотреть по show xlate), в случае неудачи пытается создать, если конечно политика это предусматривает.

Этот шаг происходит на разных этапах в случае входящего/исходящего соедининия.
Проверка осуществляется на втором шаге в случае исходящего соединения.
Этому есть логичное объясниение - адрес источника будет переписан и именно он должен фигурировать в дельнейших проверках (acl).

Повторюсь. Это поведение можно выключить используя no nat-control. Однако, до версии прошивки 7.1 этого сделать было нельзя.

Также именно здесь firewall проверяет такие параметры как:
- лимиты на количество активных соединений;
- лимиты на количество полу-открытых соединений (embryonic);
- таймауты на соединение.


3. Connection lookup

Поскольку firewall у нас "умный" и знает, что такое stateful фильтрация, ему необходимо когда-то проверять состояние соединения. Почему бы не на этом этапе? :)
Литературы по stateful фильтрации достаточно, описывать еще раз не буду.

4. ACL lookup

Именно на этом этапе происходит что-то знакомое. Как видно из названия проверяется политика доступа - поиск соответствующего access-list
По умолчанию никаких acl не применено. Трафик разрешен с более безопасного интерфейса на менее безопасный. Уровень безопасности определяется значением security level.

5. Xlate lookup (inbound)

Происходит та же проверка, что и на шаге 2. Но только для входящего трафика.

6. Uauth lookup

В случае если firewall используется как cut-through authentication proxy на этом шаге проверяются логин/пароль пользователя для его аутентификации.
Если это не первое соединение инициируемое пользователем проверяется таймер аутентификации.

7. Inspection

На последнем шаге осуществляется инспекция протокола. Конкретные действия выполняемые в этом случае очень сильно зависят от инспектируемого протокола.
Про самые интересные постараюсь рассказать в следующих заметках.

Tuesday, September 11, 2007

Фазы (этапы) IPSec

Сырая версия, но ньансов настолько много, что хочеться записать то что помниться, чтобы потом дополнять.
Итак, поговорим о ipsec. Знать это полезно при траблшутинге проблем связаных с установлением VPN туннеллями.

1. Определение трафика подлежащего шифрованию.
Чаще всего используеются так называемые crypto acl.

2. Первая фаза IKE.
2.1. Аутентификация обоих концов туннеля.
2.2. Создается IKE SA которая используется для защиты процесса IKE.
2.3. Выполняется алгоритм Диффи-Хелмана, который гарантирует, что на каждом конце туннеля будет использоватся одинаковый shared secret, без пересылания этого shared secret.
2.4. Создается туннель для работы второй фазы IKE.


Первая фаза IKE может проходить в двух режимах:
- Main mode
проходит в три этапа:
- согласование используемых алгоритмов
- обе стороны используеют алгоритм Диффи-Хелмана для определения ключей
- используя ключи стороны аутентифицируют друг-друга.
- Aggressive mode
Все что посылается в Main mode в три этапа, посылается в одном пакете. Основная проблема, что стороны обмениваются информацией до того как безопасное соединение будет установлено.

3. Вторая фаза IKE.
Основаня задача этого этапа подготовить IPSec SA которые будут использоватся непосредственно для шифрования трафика. Сюда входит согласование параметров и собственно установка.
IPSec может переходить из фазы 4 к фазе 4 и назад в нескольких случаях:

- каждая SA имеет определенное время жизни (например 1 час в Checkpoint), соостветственно по истечении этого часа необходимо пересоздать SA.
При этом для создания новой SA используется тот же shared secret, что и раньше.
- использование perfect forward secrecy (PFS). Алгоритм PFS гарантирует, что при создании новой SA предыдущий shared secret использоватся не будет, более того не будет никакой корреляции между старым и новым shared secret. Для реализации PFS используется алгоритм Диффи-Хелмана в quick mode.

Quick mode: для ренерации новой SA используется текущая SA (нет отброса на первую фазу IKE).


4. Нормальная работа.
На этой фазе туннель работает в нормальном режиме шифруя и расшифровывая трафик.

5. Закрытие туннеля.
Может быть принудительным (clear SA) либо по истечении тайм-аута.