Troubleshooting firewalls

В нескольких предыдущих заметках я рассказывал о различных аспектах настройки firewall устройств Cisco PIX и ASA. Почти всё также относиться к модулю FWSM для 65 серии коммутаторов. Зачастую в заметках просто рассказывалось как настроить какую-либо "фичу", причем в минимальной конфигурации, так как переписывать документацию смысла особого нет, а вот иметь шпаргалочку для быстрого подглядывания например номера порта который необходимо разрешить на firewall для работы HSRP оказалось достаточно удобно.
Сегодня я расскажу о действиях когда что-то идет не так как планировалось. Поскольку последнее время я занимаюсь исключительно с ASA устройствами речь пойдет о них.

Прежде всего необходимо воспользоваться простыми show командами, зачастую с их помощью можно определить источник проблем.
Для поиска проблем при прохождении трафика через firewall крайне полезны команды show xlate и show connection. Первая предназначена для просмотра активных
сетевых трансляций, вторая для просмотра соединений. Почему зачастую для построения соединений нужен NAT и как его правильно настроить модно прочитать в одной из предыдущих заметок. Обращайте внимание на флаги которые появляются при выводе show xlate detail, например можно долго искать проблему в "странно работающем" DNS если не заметить флага "D" при трансляции.

pixasa# sh xlate detail
1 in use, 1 most used
Flags: D - DNS, d - dump, I - identity, i - dynamic, n - no random,
r - portmap, s - static
NAT from inside:10.10.11.5 to outside:10.10.11.2 flags sD

Крайне полезная команда show local-host. Показывает не достаточно подробную информацию. Причем не только по соединениям, а по всевозможным лимитам установленным для данного потока. Немного странновая терминилогия, но если верить документации local-host создается для каждого хоста который шлет пакеты на firewall или через него. Что интересно, во втором случае создается два локальных хоста, например как в этом примере. От 10.10.10.2 обращается по telnet к 10.10.11.2, соответственно для каждого могут быть применены свои лимиты. Также команда полезна для просмотра трансляция созданых с помощью Identity NAT.

pixasa# sh local-host
Interface inside: 1 active, 2 maximum active, 0 denied
local host: <10.10.11.2>,
TCP flow count/limit = 1/unlimited
TCP embryonic count to host = 0
TCP intercept watermark = unlimited
UDP flow count/limit = 0/unlimited

Conn:
TCP out 10.10.10.2:35803 in 10.10.11.2:23 idle 0:00:00 bytes 73 flags UIOB
Interface outside: 1 active, 1 maximum active, 0 denied
local host: <10.10.10.2>,
TCP flow count/limit = 1/unlimited
TCP embryonic count to host = 0
TCP intercept watermark = unlimited
UDP flow count/limit = 0/unlimited

Conn:
TCP out 10.10.10.2:35803 in 10.10.11.2:23 idle 0:00:00 bytes 73 flags UIOB

Команда show asp drop покажет общую статистику о пакетах заблокированных по тем или иными причинам. Например при настройке Unicast Reverse Path Forwarding сколько именно пакетов было заблокировано.
Также крайне полезная информация позволяющая сходу оценить количественные показатели. Сколько было заблокировано ACL (строчка Flow is denied by access rule), а сколько например по причине некорректно установленных опций в пакете (Bad TCP flags).
Примерно как в примере ниже.

pixasa# show asp drop | in Reverse-path

Reverse-path verify failed 15

pixasa# show asp drop | in Bad option length in

Bad option length in TCP 731

Следующая крайне полезная show команда позволить посмотреть насколько интенсивно используется процессор. Вывод очень похож на вывод команды uptime в системах *nix.

pixasa# show cpu usage
CPU utilization for 5 seconds = 9%; 1 minute: 11%; 5 minutes: 7%

Если используются виртуальные firewall, можно посмотреть статистику по конкретному контексту.

pixasa# show cpu context system

CPU utilization for 5 seconds = 6.3%; 1 minute: 7.7%; 5 minutes: 3.8%

show traffic покажет загрузку интерфейсов, может быть задержки происходят просто потому, что не хватает пропускной способности интерфейса?

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

Следующая команда проста и универсальна по своей сути. Часто бывает ситуация когда вроде бы всё должно работать, но при этом что-то не работает.
На помощь придет отличный тестировщик любых IP соединений - трассировка пакета.

// Синтаксис достаточно простой. Команда начинается с ключевых слов packet-tracer input
// далее следует указание интерфейса в который будем "инжектить" пакет и необходимые параметры в виде IP адресов и портов.

pixasa# packet-tracer input outside tcp 10.10.10.2 2222 10.10.11.2 23 detailed

Выводом будет пошаговая трассировка пакете через все проверки и лимиты возможные на firewall, проверка NAT если включен nat-control, проверка urpf если включена, конечно же соответствие политике устройства, т.е. access-lists. Приводить здесь вывод я не буду, он достаточно объемен. Лично я не представляю как я раньше без неё обходился, настолько удобным это оказалось.

Что интересно, firewall действительно создает этот пакет запускает его в реальный процессинг, это видно по строчкам лога, в которых можно разглядеть реальные события как
например создание слота трансляции для трассировочного пакета.

Достаточно симпатично packet trace выглядит запущенный в графическом режиме из ASDM.
Если же искусственно запущенный пакет проходит без проблем, а реальные приложения не работают остается только проверенное средство в виде сниффера.
Действительно, может проблема в том, что до firewall пакеты даже не доходят? Есть замечательная команда show capture о которой я уже писал. Повторяться здесь не буду, просто имейте в виду.

Также не следует забывать о существовании просто огромного количества debug команд на все случаи жизни. Здорово облегчить жизнь может использование фильтров для всё тех же команд show.

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. Это отдельная большая тема, хотя команды конфигурирования похожи. 

Немного о правах

Краткая заметка о настройке AAA на устройствах PIX/ASA.
Зачем это нужно расписывать не буду и так вроде очевидно.

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

1. Необходимый минимум. Простейшая аутентификация.
Минимальная настройка которая необходима как минимум для удаленного захода, например по ssh или с помощью ASDM.
По-сути это должны быть одни из первых команд на новой железяке.

//создаем пользователя
ciscoasa(config)# username admin password superpuper

//Разрешаем необходимый доступ - ssh и http.
// В данном случае открывается доступ для хоста 10.2.1.10 находящегося в inside
ciscoasa(config)# ssh 10.2.1.10 255.255.255.255 inside
ciscoasa(config)# http 10.2.1.10 255.255.255.255 inside

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

// указываем где искать пароли для пользователей. В данному случае локально.
ciscoasa(config)# aaa authentication ssh console LOCAL
ciscoasa(config)# aaa authentication http console LOCAL

Вот и всё. Теперь появилась возможность зайти удалённо.
Однако, для внесения изменений в конфигурацию используется enable доступ.
// Можно использовать распределённые пароль, указываемый командой enable password
ciscoasa(config)# enable password pupersuper

Но это не всегда удобно и совершенно не безопасно. Гораздо практичнее каждому пользователю использовать свой пароль.
Чем-то это похоже на работу sudo - пользователь просто вводит свой пароль еще раз.

// Использовать для enable пароль пользователя, а не глобальный
ciscoasa(config)# aaa authentication enable console LOCAL


2. Необходимый минимум. Простейшая авторизация.
В принципе для простых административных задач уровня smb вышеописанного вполне хватает.
Есть еще одна полезная функция - разделение привилегий. Например для задач мониторинга и простейшей поддержки

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

//Аналогично с аутентификацией необходимо указать как авторизовать действия пользователей.
ciscoasa(config)# aaa authorization command LOCAL

// Добавляем пользователя.
// Используем необязательный параметр privilege. Он указывает максимальный уровень привилегий которые может получить пользователь.
// Проводя аналогии с sudo - это группа в которую включен пользователь. Отличия только в том, что старшие группы включают в себя младшие.
// Т.е. пользователь с уровнем привилегий 6 имеет привилегии уровня 5.
ciscoasa(config)# username operator password 111 privilege 5

Далее необходимо указать что разрешено конкретному уровню привилегий.
Для этих целей используется команда privilege с следующим синтаксисом:

privilege {show | clear | configure} level level [mode {enable | configure}] command command

// Разрешим пользователям с уровнем привилегий 5 просматривать текущие соединения.
ciscoasa(config)# privilege show level 5 command conn

// Теперь после ввода команды пользователем команды enable и своего пароля он получит возможность использовать команду
ciscoasa# show conn

// При вводе команды которая не разрешена получим следующий результат
ciscoasa# show xlate
^
ERROR: % Invalid input detected at '^' marker.
ERROR: Command authorization failed

Привилегии не ограничиваются только просмотром. Можно дать возможность вносить изменения в конфигурацию.

// разрешим той же группе пользователей изменять таблицу рутинга
ciscoasaconfig)# privilege configure level 5 command route
ciscoasaconfig)# privilege configure level 5 command configure


// Для просмотра текущего уровня привилегий предназначена соответствующая команда show
ciscoasa# show curpriv
Username : operator
Current privilege level : 5
Current Mode/s : P_PRIV


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

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

Среди множества возможностей устройств 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

Настройка NAT на устройствах PIX/ASA

Настройка NAT на устройствах PIX/ASA


Терминология
global_IP - адрес в который будет осуществляться трансляция
real_ip - оригинальный адрес, подлежащий переписыванию
real_ifc - интерфейс на который приходят оригинальные пакеты подлежащие трансляции
global_ifc - интерфейс который будет использован для дальшейшей маршрутизации транслированного пакета

Static
Неудивительно и вполне ожидаемо, что для конфигурирования статических трансляций используется команда static имеющая следующий синтаксис:

PIX(config)# static (real_ifc,global_ifc) {global_ip |interface} {real_ip [netmask mask]}

Static NAT
Классический НАТ один к одному используется в тех случаях когда необходима реальная трансляция, маппинг, адреса.
PIX(config)# static (inside,outside) global_IP real_IP netmask 255.255.255.255

Т.е. если у нас реальный адрес на интерфейсе хоста во внутренней сети 10.10.10.10, а провайдер нам выделил пул из адресов 192.168.100.0/24 мы можем обеспечить доступность хоста снаружи введя команду
PIX(config)# static (inside,outside) 192.168.100.10 10.10.10.10 netmask 255.255.255.255
Всё что приходит на адрес 192.168.100.10 будет передаваться на хост с адресом 10.10.10.10.

Static PAT
Сюда же относиться и просто проброс порта, называемый обычно PAT, да и показываемый в по sh xlate тоже РАТ. Используеться в тех случаях когда необходимо обеспечить доступность снаружи только по некоторым портам. Допустим для почтового сервера.
PIX(config)# static (inside,outside) tcp 192.168.100.10 smtp 10.10.10.10 smtp netmask 255.255.255.255

Также может быть полезно в случае, если сервисов больше чем реальных адресов. Ничего не мешает пробросить порт и на веб-сервер.
PIX(config)# static (inside,outside) tcp 192.168.100.10 www 10.10.10.11 www netmask 255.255.255.255

Dynamic
Dynamic NAT
Определяется пул адресов для которых будет проводиться трансляция и пул в которые она будет проводиться.
Трансляция просиходит один к одному, т.е. каждый хост inside хост имеет монопольное право на один адрес из global_IP диапазона. Соответственно если global_IP <>

Определяем, что будем транслировать (real_IP):

PIX(config)# nat (real_ifc) nat_id real_ip [mask]
PIX(config)# nat (inside) 1 10.10.10.0 255.255.255.0

Во что будем транслировать (global_IP):

PIX(config)# global (global_ifc) nat_id global_ip[-global_ip] [netmask global_mask]
PIX(config)# global (outside) 1 192.168.100.20-192.168.100.121

Вот такая нехитрая конфигураци позволяет получить доступ в внешнюю сеть первым 100 хостам из сети 10.10.10.0/24 :)
Зачастую этот тип трансляции используется в том случае если протокол более высокого уровня не поддерживает работу через PAT.


Dynamic PAT
То что в Linux называется маскарадинг. Ситуация когда несколько внутренних хостов используют один, либо несколько, глобальных адресов для выхода в внешнюю сеть..

Определяем, что будем транслировать (real_IP):
PIX(config)# nat (real_ifc) nat_id real_ip [mask]

В данном случае мы будем выпускать "в мир" всё ту же многострадальную сеть - 10.10.10.0/24. Это наши настоящие (real_IP) адреса на интерфейсах внутренних хостов.
PIX(config)# nat (inside) 1 10.10.10.0 255.255.255.0

Транслироваться всё это будет в один адрес global_IP:
PIX(config)# global (outside) 1 192.168.100.130

Однако, зачастую интерфейсов на нашем firewall чем два, возможно остальным тоже необходимо получать доступ?
Добавляем правило трансляции для еще одного интерфейса, необходимо использовать такой же nat-id.
PIX(config)# nat (inside2) 1 10.10.11.0 255.255.255.0

Теперь хосты из двух подсетей 10.10.10.0/24 и 10.10.11.0/24 видны как один адрес 192.168.100.130.

Теперь вполне возможна ситуация, когда лимитов на соединение (около 64 тысяч) будет уже не хватать.
Есть возможность выделить еще несколько адресов для РАТ.
PIX(config)# global (outside) 1 192.168.100.12
PIX(config)# global (outside) 1 192.168.100.13

Есть возможность ипользовать адрес интерфейса, для РАТ трансляции.
PIX(config)# global (outside) 1 interface

Также для определения адресов подлежащих трансляции можно пользоваться acl.
В примере ниже разрешена трансляция адресов сети 10.10.10.0/24 в адрес outside интерфейса с помощью acl в том случае если адрес назначения сеть 10.10.100.0/24

PIX(config)# access-list someflow permit ip 10.10.10.0 255.255.255.0 10.10.100.0 255.255.255.0
PIX(config)# nat (inside) 1 access-list someflow
PIX(config)# global (outside) 1 interface

Это не так очевидно, посему особо отмечу: конфигурация NAT от PAT отличается только способом указания global_IP.В первом случае указывается диапазон, во втором отдельные адреса.
nat-id варьируеться от 1 до 2,147,483,647 т.е. можно использовать разные правила трансляции для различных интерфейсов, PIX/ASA различает их по nat-id.

Policy NAT
Используется в случае необходимости нелинейно транслировать адреса, например в зависимости от адреса назначения. Например адреса внутренней сети 10.10.10.0/24 могут быть транслированы в 192.168.100.12 при обращении к сети 10.11.10.0 и в 192.168.100.13 при обращении к 10.12.10.0

PIX(config)# access-list someflowA permit ip 10.10.10.0 255.255.255.0 10.11.10.0 255.255.255.0
PIX(config)# access-list someflowB permit ip 10.10.10.0 255.255.255.0 10.12.10.0 255.255.255.0
PIX(config)# nat (inside) 1 access-list someflowA
PIX(config)# nat (inside) 2 access-list someflowB
PIX(config)# global (outside) 1 192.168.100.12
PIX(config)# global (outside) 2 192.168.100.13

не-NAT
Псевдонат используется в тех случаях если включен nat-control, который требует, чтобы для пакета проходящего с более защищенного интерфейса на менее защищенный (inside -> outside) существовала трансляция. В противном случае обработка пакета прекращается.

Identity NAT
Команда выглядит следующим образом
PIX(config)# nat (real_ifc) 0 real_ip real_mask

Допустим, что в внутренней сети, например в dmz находиться сервер с реальным адресом на интерфейсе 100.100.100.100.
В данном случае команда будет выглядеть так:
PIX(config)# nat (dmz) 0 100.100.100.100 255.255.255.255

Необходимо обратить внимание на nat-id равный нулю и на отсутствие команды global.
Отмечу также, что в данном случае firewall разрешит только соединения в внешнюю сеть (outbound), inbound соединения будут сброшены.

NAT Exemption
Почти то же самое, что и Identity NAT но соединения разрешены в обе стороны. Настраивается почти так же, единственное отличие - используется acl.

PIX(config)# access-list nonat_from_dmz permit ip 100.100.100.100 255.255.255.255 any
PIX(config)# nat (dmz) 0 access-list nonat_from_dmz


Плюшки
Это не все параметры имеющиеся в арсенале команд nat и static. Полный синтаксис выглядит так:
... [norandomseq] [[tcp] max_conns [emb_limit]] [udp udp_max_conns]

norandomseq
Включено по-умолчанию. При каждом новом соединении firewall генерирует случайный initial sequence number (ISN).
Связано это с тем, что tcp/ip стек некоторых ОС использует предсказуемые ISN, что дает возможность злоумышленнику вклиниться в чужую сессию.
Атака носит название TCP hijacking.
PIX/ASA использует оригинальный ISN для поддержания сессис с сгенерировавшим его хостом и переписывает на сгенерированый собственноручно, для общения с хостом назначения.
Протоколы используемые проверку целостности пакетов не смогут работать в таких жестоких условиях. :) Для отключения используется данный параметр.

tcp max_conns и udp udp_max_conns
В принипе из названия всё понятно. Лимиты на количество соединений. Значения по умолчанию равны нулю - отсутствие лимитов.

emb_limit
Удивительно полезная и нужная опция. Позволяет защитить внутренние хосты от syn-flood.
До тех пор пока лимит не достигнут, все новые пакеты (первый syn) перенаправляються оригинальному хосту получателю.
Как только лимит в достигнут firewall перехватывает новые пакеты, с первым syn, и отвечает иницатору соединения с syn-ack.
В случае благополучного завершения тройного рукопожатия,получения ack от инициатора, firewall создает новое соединение с оригинальным хостом назначения.

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

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

Unicast Reverse Path Forwarding

Зачастую можно увидеть как сетевые администраторы используют традиционные списки доступа для предотвращения подделки адресов (spoofing).
Видимо сказывается привычка выработаная с годами. :)

Тем не менее многие знают или слышали о такой штуке как Unicast Reverse Path Forwarding.

Как это работает

Для работы Unicast Reverse Path Forwarding должен быть включен cef.
При получении пакета uRPF проверяет соответствует ли адрес источника и интерфейс через который получен пакет значениям в таблице FIB.
По сути выполняется обратный резолвинг адреса источника используя базу (reverse lookup) FIB

Решение конечно не универсальное. Его нельзя применять в случае ассиметричного рутинга (вход по одному интерфейсу, а выход по другому).

Подробнее можно почитать в RFC 2267.

Настройка

Cisco IOS
В конфигурацию интерфейса необходимо добавить строку

routerA(conf-if)# ip verify unicast reverse-path

PIX/ASA
В режиме глобальной конфигурации необходимо выполнить команду

myasa# ip verify reverse-path interface e0


Проверка состояния rpf

В случае Cisco IOS проверить можно поискав строку относящуюся с rpf в выводе команды:

RouterA# show cef interface FastEthernet 0/0

IP unicast RPF check is enabled

В случае PIX/ASA всё выглядит похоже:

myasa# show ip verify statistics
interface outside: 21 unicast rpf drops
interface inside: 2738 unicast rpf drops
interface vpn: 0 unicast rpf drops

Настройка DHCP в PIX/ASA

Периодически приходят посетители с google, которые находят блог по ключевым словам asa dhcp. Не очень понимая как это происходит, я решил не разочаровывать их написать маленькую заметку на интересующую их тему. :)
Может сделаю это практикой.

0. Официальная документация
http://cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a00806c1cd5.shtml
http://cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a008075fcfb.shtml

Существует два режима работы DHCP.
- сервер
- клиент

Для чего нужен каждый рассказывать не буду, вроде и так понятно.


1. Сервер. Необходимый минимум

Минимальная настройка это всего две команды. Первая определяет пул из которого будут "черпаться" адреса, вторая указывает на каком интерфейсе слушать. Можно запустить несколько сервисов на нескольких интерфейсах

dhcpd address 10.10.10.1-10.10.10.128 LAN
dhcpd enable LAN

2. Сервер. Дополнительно.

Следующие команды позволяют настраивать различные параметры передаваемые клиентам. К большинству из них можно добавить ключевое слово interface с указанием интерфейса PIX/ASA, что позволит иметь разные настройки для разных интерфейсов.

// Передать клиенту адрес dns сервера
dhcpd dns 192.168.100.25

// Передать клиенту адрес wins сервера
dhcpd wins 192.168.100.25

// dns домен
dhcpd domain piva.net

// Время на которое выдается адрес. Указывается в секундах
dhcpd lease 7200

В качестве дополнительной проверки PIX/ASA пингует адрес перед выдачей.
Похожее поведение можно настроить и в IOS, здесь это включено по-умолчанию. Перед выдачей адреса посылается для icmp пакета.
Как это выключить я не нашел. :) Зато есть способ управлять таймаутами.

// Изменяем таймуат отклика на пинг. По-умолчанию равен 50 миллисекундам.
dhcpd ping_timeout 100

3. Клиент
При настройке PIX/ASA как клиента dhcp всё еще проще.
В контексте редактирования интерефейса необходимо добавить всего одну команду.

// Получать IP адрес для интерфейса динамически
ip address dhcp [setroute]

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

4. Дополнительно
Есть возможность передавать полученые как dhcp клиент параметры (dns, wins, домен) клиентам dhcp динамически.

// Отдавать параметры полученые как клиент своим клиентым

dhcpd auto_config interface LAN

Live and learn

[upd, 19.09.2007]
Попалась совершенно замечательная статья в подробностях показывающая как нижеописанное применять на PIX/ASA.
http://security-planet.de/2005/07/26/cisco-pix-capturing-traffic/


Век живи - век учись. Всегда оказывается что чего-то не знаешь...

Как часто при попытке дианостировать разнообразные "подземные стуки", я сожалел о том, что под Cisco нет ничего похожего на tcpdump.

Глупец. Я ошибался. Оказывается, все прогрессивное человечество давно энает способы. Итак, представляем...

1. Cisco PIX/ASA

Способ хорошо известен.

Описан здесь: http://cisco.com/en/US/products/ps6120/products_tech_note09186a00807c35e7.shtml

Скопирую суть:

ciscoasa(config)#access-list inside_test permit icmp any host 192.168.1.1

ciscoasa(config)#capture inside_interface access-list inside_test interface inside

The user pings the inside interface of the ASA (ping 192.168.1.1). This output is displayed.

ciscoasa#show capture inside_interface

1: 13:04:06.284897 192.168.1.50 > 192.168.1.1: icmp: echo request

2. Cisco router

Создаем ip access-list которым будем "ловить" интересующий нас трафик.

routerA(conf)# access-list 111 permit ip 10.10.10.0 0.0.0.255 10.10.15.0 0.0.0.255
routerA(conf)# access-list 111 permit ip 10.10.15.0 0.0.0.255 10.10.10.0 0.0.0.255

Запускаем команду на выполнение и смотрим результат:

routerA# debug ip packet 111 detail

IP packet debugging is on (detailed) for access list 111

*Mar 1 00:10:32.975: IP: tableid=0, s=10.10.10.5 (FastEthernet0/0), d=10.10.15.1 (Serial2/0), routed via FIB
*Mar 1 00:10:33.119: IP: s=10.10.15.1 (Serial2/0), d=10.10.10.5 (FastEthernet0/0), g=10.10.10.5, len 44, forward
*Mar 1 00:10:33.123: TCP src=23, dst=43741, seq=762553188, ack=408925172, win=4128 ACK SYN
*Mar 1 00:10:33.239: IP: tableid=0, s=10.10.10.5 (FastEthernet0/0), d=10.10.15.1 (Serial2/0), routed via FIB
*Mar 1 00:10:33.287: IP: tableid=0, s=10.10.10.5 (FastEthernet0/0), d=10.10.15.1 (Serial2/0), routed via FIB
*Mar 1 00:10:33.291: IP: tableid=0, s=10.10.10.5 (FastEthernet0/0), d=10.10.15.1 (Serial2/0), routed via FIB
*Mar 1 00:10:33.431: IP: s=10.10.15.1 (Serial2/0), d=10.10.10.5 (FastEthernet0/0), g=10.10.10.5, len 52, forward
*Mar 1 00:10:33.435: TCP src=23, dst=43741, seq=762553189, ack=408925181, win=4119 ACK PSH
*Mar 1 00:10:33.455: IP: s=10.10.15.1 (Serial2/0), d=10.10.10.5 (FastEthernet0/0), g=10.10.10.5, len 77, forward
*Mar 1 00:10:33.459: TCP src=23, dst=43741, seq=762553201, ack=408925181, win=4119 ACK PSH
*Mar 1 00:10:33.575: IP: tableid=0, s=10.10.10.5 (FastEthernet0/0), d=10.10.15.1 (Serial2/0), routed via FIB
*Mar 1 00:10:33.599: IP: tableid=0, s=10.10.10.5 (FastEthernet0/0), d=10.10.15.1 (Serial2/0), routed via FIB
*Mar 1 00:10:33.647: IP: tableid=0, s=10.10.10.5 (FastEthernet0/0), d=10.10.15.1 (Serial2/0), routed via FIB
*Mar 1 00:10:33.759: IP: s=10.10.15.1 (Serial2/0), d=10.10.10.5 (FastEthernet0/0), g=10.10.10.5, len 40, forward
*Mar 1 00:10:33.763: TCP src=23, dst=43741, seq=762553238, ack=408925196, win=4104 ACK
*Mar 1 00:10:35.415: IP: s=10.10.15.1 (Serial2/0), d=10.10.10.5 (FastEthernet0/0), g=10.10.10.5, len 40, forward
*Mar 1 00:10:35.423: TCP src=23, dst=43741, seq=762553238, ack=408925196, win=4104 ACK PSH FIN
*Mar 1 00:10:35.623: IP: tableid=0, s=10.10.10.5 (FastEthernet0/0), d=10.10.15.1 (Serial2/0), routed via FIB
*Mar 1 00:10:35.627: IP: tableid=0, s=10.10.10.5 (FastEthernet0/0), d=10.10.15.1 (Serial2/0), routed via FIB
*Mar 1 00:10:35.647: IP: s=10.10.15.1 (Serial2/0), d=10.10.10.5 (FastEthernet0/0), g=10.10.10.5, len 40, forward
*Mar 1 00:10:35.651: TCP src=23, dst=43741, seq=762553239, ack=408925197, win=4104 ACK

Это решение не работает с fast-switching (ip route-cache).