Бардак в голове

Анализируй это! (capture on cisco IOS, tcpdump on cisco)

2008-10-28T12:01:00.001+01:00

Чуть больше года назад, я уже писал о инструментах подобных tcpdump в cisco рутерах и файрволлах. Напомню вкратце, для PIX/ASA существует удобный инструмент capture с помощью которого можно захватывать и просматривать трафик, для IOS приходилось довольствоваться командой дебаг предварительно уточнив её с помощью access-list.
В свеженькой версии IOS 12.4(20)Т появилась новый и удобный функционал решающий эту проблему более элегантно. Конечно, версия достаточно новая и мало кто рискнет поставить её в реальную работу, но рано или поздно функционал появится и в стабильных версиях.

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

// buf1 - название буфера
// size и max-size - размер буфера и максимальный размер элемента в буфере, соответственно
// circular или linear - тип буфера, будут ли старые элементы вытеснятся новыми или нет
R2#monitor capture buffer buf1 size 256 max-size 256 circular

Далее создадим "точку ловли" (capture point), которая сообщит рутеру где ожидать трафика и в каком направлении он будет двигаться.

// ip cef - метод коммутации, мы используем cef
// cappoint - название точки
// далее следует интерфейс на котором слушать и в каком направлении - в обоих
R2#monitor capture point ip cef cappoint fa 0/0 both

После создания, появится следующее сообщение с логах.

*Oct 27 15:23:23.859: %BUFCAP-6-CREATE: Capture Point cappoint created.

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

// синтаксис просто, даже не знаю что писать - всё очевидно
R2#monitor capture point associate cappoint buf1

// Проверить конфигурацю можно следующей командой
R2#show monitor capture point all
Status Information for Capture Point cappoint
IPv4 CEF
Switch Path: IPv4 CEF            , Capture Buffer: buf1
Status : Inactive

Configuration:
monitor capture point ip cef cappoint FastEthernet0/0 both

Всё готово для траблшута, осталось только включить. В данный момент статус - Inactive.

// Включаем. В данном случае all, но можно включить и отдельную "точку" по имени
R2#monitor capture point start all

Появится следующее сообщение в логах.
*Oct 27 15:25:05.195: %BUFCAP-6-ENABLE: Capture Point cappoint enabled

// проверим статус еще раз, как можно заметить статус изменился на активный
R2#show monitor capture point all
Status Information for Capture Point cappoint
IPv4 CEF
Switch Path: IPv4 CEF            , Capture Buffer: buf1
Status : Active

Configuration:
monitor capture point ip cef cappoint FastEthernet0/0 both

Посмотреть что же мы там наловили можно следующей командой

R2#show monitor capture buffer buf1 dump
15:29:24.251 UTC Oct 27 2008 : IPv4 CEF Turbo : Fa0/0 None

67BB35C0: CA000A00 0000C200 08340001 08004500 J.....B..4....E.
67BB35D0: 00640014 0000FE01 946E0A0A 0A020A0A .d....~..n......
67BB35E0: 0A010800 EEC20004 00000000 0000000F ....nB..........
67BB35F0: 8F74ABCD ABCDABCD ABCDABCD ABCDABCD .t+M+M+M+M+M+M+M
67BB3600: ABCDABCD ABCDABCD ABCDABCD ABCDABCD +M+M+M+M+M+M+M+M
67BB3610: ABCDABCD ABCDABCD ABCDABCD ABCDABCD +M+M+M+M+M+M+M+M
67BB3620: ABCDABCD ABCDABCD ABCDABCD ABCDABCD +M+M+M+M+M+M+M+M
67BB3630: ABCD00                               +M.

15:29:24.251 UTC Oct 27 2008 : IPv4 LES CEF    : Fa0/0 None

67BB35C0: CA000A00 0000C200 08340001 08004500 J.....B..4....E.
67BB35D0: 00640014 0000FE01 946E0A0A 0A020A0A .d....~..n......
67BB35E0: 0A010800 EEC20004 00000000 0000000F ....nB..........
67BB35F0: 8F74ABCD ABCDABCD ABCDABCD ABCDABCD .t+M+M+M+M+M+M+M
67BB3600: ABCDABCD ABCDABCD ABCDABCD ABCDABCD +M+M+M+M+M+M+M+M
67BB3610: ABCDABCD ABCDABCD ABCDABCD ABCDABCD +M+M+M+M+M+M+M+M
67BB3620: ABCDABCD ABCDABCD ABCDABCD ABCDABCD +M+M+M+M+M+M+M+M
67BB3630: ABCD00                               +M.

Не слишком понятно, правда? А ведь это был обычный ping, ничего более. Для упрощения анализа полученные данные можно экспортировать в формат pcap и анализировать на PC в любимом инструменте, например wireshark.

//экспорт буфера, вариантов много - tftp, ftp, scp и другие Xtp :)
R2#monitor capture buffer buf1 export (куда)

Но всё таки чего-то не хватает, зачем например собирать данные со всего интерфейса если интересует всего один IP и более того, только один протокол? Конечно решение есть. При создании буфера можно указать фильтр для отбора пакетов из потока. Делается это с помощью access-list.

R2#monitor capture buffer buf1 filter access-list (номер, имя)

Есть браузер – нет проблем. Немного теории и начальная конфигурация.

2008-10-05T19:22:00.002+02:00

Недавно мне в руки попала достаточно интересная железяка – Juniper SA-2000, предназначенная для организации построения VPN по технологии SSL. Следующие несколько заметок будут посвящены именно этой теме. В документации производителя она так же называется IVE. Итак, начнем.

Заголовок выбран неслучайно ведь основным преимуществом и отличием SSL VPN от хорошо знакомого IPSec является именно возможность подключится к шлюзу с помощью обычного браузера. Т.е. при полном отсутствии клиентской части, например из гостиницы или интернет кафе.

С технической точки зрения, Juniper, впрочем как и остальные вендоры, предоставляет два основных вида туннелей:

- чистый SSL

- network connect

Чистый SSL

Пользователь, используя обычный http, заходит на страничку удалённого доступа, вводит данные необходимые для аутентификации и попадает на SSL портал. На портале ему могут быть доступны следующие сервисы:

- web доступ, если внутри есть web сервер доступ к которому должен быть защищен это тот самый случай;

- файловый доступ, заворачивает NBT и NFS протоколы в SSL обертку;

- SAM, расшифровывается как Secure Application Manager, представляет собой Java либо ActiveX приложение поддерживающее туннель к заранее известным серверам. Сложно написал, но по-сути это тот же SSH туннель только с помощью SSL;

- Telnet/SSH, Java приложение являющееся клиентом Telnet либо SSH соответственно;

- Terminal Services, такое же Java приложение но для протоколов RDP и ICA;

- Meeting, защищенное место для проведения собраний, тема отдельной заметки по-хорошему;

- Email Client, такое же Java приложение.

Network Connect

В терминологии Juniper называется это называется Network Connect - загружаемое win32 либо Java приложение которое после аутентификации устанавливает виртуальный драйвер и поднимает полноценный VPN туннель. Опять таки двумя различными способами, полноценный IPSec либо заворачивая всё в SSL. Для первого способа необходимо открыть порт udp/4500. Также для NC (Network Connect) необходимо иметь права администратора на клиентском компьютере.

Включаем

Надеюсь я понятно описал возможные опции, теперь перейдем к конфигурации.

Первоначальная конфигурация производится с помощью стандартного консольного соединения. После пары вопросов типа, "а не новый ли это член кластера?" или "согласны ли вы с лицензионным соглашением?", железяка примерно такое меню:

Welcome to the Juniper Networks IVE Serial Console!

Current version: 6.3R1 (build 13557)

Rollback version: 6.2R2-1 (build 13525)

Reset version: 5.1R2 (build 9029)

Licensing Hardware ID: XXXXXXX

Serial Number: XXXXXXXX

Please choose from among the following options:

1. Network Settings and Tools

2. Create admin username and password

3. Display log/status

4. System Operations

5. Toggle password protection for the console (Off)

6. Create a Super Admin session.

7. System Snapshot

8. Reset allowed encryption strength for SSL

10. Toggle SSL HW Acceleration (system will reboot when this setting is modified): off

Choice:

в котром в первую очередь нас должны интересовать два пункта, которые так и называются: первый и второй. :) Первый позволяет указать основные сетевые настройки интерфейсов, в второй создать локального пользователя с правами администратора.

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

Описывать настройку сети я не буду, она достаточно тривиальна. После конфигурации сетевых параметров web-интерфейс доступен по адресу: https://<IP_address>/admin. К сожалению в SSL устройствах Juniper не предоставляет возможности управления из командной строки.

Интерфейс

Следующий скриншот может дать определённое представление как выглядит интерфейс. Он кликабелен, можно рассмотреть подробнее.

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

Начнем с конца.

Первым делом необходимо создать и настроить серверы аутентификации (auth. servers), т.е. место откуда устройство будет черпать информацию о пользователях. Это может быть radius, LDAP, Active Directory, локальная база и еще пара менее популярных вариантов.

Каждому прошедшему аутентификацию пользователю присваивается роль или несколько (User Role). Именно на уровне роли пользователи получают доступ к различным возможностях IVE как например web, network connect или файловый доступ. Отмечу, кроме разрешения на уровне роли, должна быть создана ресурсная политика (Resource Police) разрешающая доступ к данному ресурсу.

Далее необходимо создать пользовательскую область (User Realm), подскажите лучший перевод если знаете. :) В реалме указывается несколько важных параметров: способ которым пользователи будут аутентифицироваться (указывается сервер настроенный в пункте auth. servers) и правила (Role Mapping) по которым пользователь будет оцениваться как подходящий для данной пользовательской роли. Например это может быть требование состоять в определённой группе.

Следующий шаг – страницы входа (Sign-in Page). Достаточно простая вещь позволяет создать страничку с необходимыми настройками как например: фирменный логотип, инструкция по использованию и т.д.

Страница входа назначается политике входа (Sign-in Police), также в политике входа настраивается адрес по которому будет доступна эта страница (например hostname/sign-in page) и user realm который будет использоваться для аутентификации.

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

Sign-in Page -> Sign-in Police -> User Realm -> User Role

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

Вопросы

Я прекрасно понимаю, читать текстовое описание настройки достаточно скучно, не говоря уже о том, что это запутывает. В связи с этим вопрос.

Подскажите каким образом лучше описывать конфигурацию в заметке? С устройствами конфигурируемыми посредством командной строки это достаточно просто, а как быть в случае графического инсталлятора? Пичкать пол-сотни скриншотов для объяснения мне не кажется выходом, описывать по типу пункт меню 1-> Пункт меню 2 -> галочка напротив пункта номер семь тоже достаточно скучно, да и не даст совершенно никакого представления тем у кого нет доступа к железу, а почитать и разобраться всё таки хочется. Может быть делать короткий анонс в блоге, а само описание перенести в презентацию? А может лучше записывать скринкасты? Меня интересует ваше мнение, читатели. :)

Отчет о поездке на FUDCon

2008-09-08T14:54:00.003+02:00

На прошедших выходных мне удалось попасть на достаточно интересную конференцию посвященную Linux - FUDCon. Как можно догадаться из названия посвящена она дистрибутиву Fedora пользователем которого я не являюсь. :) Несмотря на это информация была достаточно интересна для меня.
Расскажу подробнее об организации мероприятия.
Всё происходило в здании факультета информатики университета имени Масарика в городе Брно. Первые восторги вызвало само здание - отлично оборудованное, чистое и светлое. Всё настолько удобно и практично - наши студенты бы обзавидовались.

В фотографиях можно найти несколько отличных снимков аудиторий.

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

С докладами оказалось хуже.
Нет, темы были интересны и вопросы обсуждались правильные, но всё таки большинство технических людей не умеет читать презентации, что конечно сказалось на качестве.

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

Увидел и пощупал знаменитый долгострой - OpenMoko. Даже с двумя разными прошивками - родной и Nokia. На устройстве на фотографии слева установлена qtopia от финнов.

Конечно всем выдавали бесплатные футболки. :)

К сожалению посетить я смог только один день конференции, но зато самый главный. :)

Доклады на которых я присутствовал:

- sec tool. Достаточно простая утилита для анализа конфигураций компьютера. Изначально заложены простые принципы - проверка конфигурационных файлов основных сервисов (как ssh например), прав доступа (если, скажем, установить домашней директории права на запись для всем - утилита выдаст предупреждение).

- oVirt Продукт от Fedora который в идеале не должен уступать коммерческим реализациям VmWare. В качестве сердцевины используется стандартный KVM, также проект предлагает готовые образы "нод" для развертывания. Я так понял это выглядит следующим образом: есть один главный сервер и какое-то количество рабочих лошадок называемых нодами. На ноды устанавливается образы ОС и подключаются к консоли главного сервера. После этого на сервере создается (импортируется) виртуальная машина и всё готово к запуску. Сервер сам выберет ноду из пула которая загружена менее всего и запустит на ней VM. По словам докладчика, если через некоторое время нода даст сбой, то сервер способен перевести виртуальную машину на другую ноду даже без прекращение работы. Я спрашивал про tcp сессии в данном случае - сказали сессис выживут.

- Spacewalk

Spacewalk это то, что ранее называлось RedHat network и было доступно платным подписчикам. Сейчас (три месяца назад) продукт выпустили в open source и переименовали в Spacewalk. Предназначен для управления большим количеством серверов или рабочих станций под управлением Fedora. Например, если необходимо на 1000 рабочих станций установить новое ПО, добавить пользователя или провести любые другие изменения - то в этом случае Spacewalk то что нужно использовать. Достаточно интересное решение, призвано упростить миграцию на Linux в корпоративном секторе.

- State of RPM Откровенно скучная презентация. Сначала 20 минут рассказывали о истории rpm, упоминая даже о минорных версиях, потом рассказывали что будет с ним дальше (практически никаких изменений, исправление ошибок). Сложилось впечатление, что вся презентация была необходима ради одного слайда - RPM not dead. -) С середины я ушел и перешел на Fedora Ar.

- Fedora Art
Вообщем-то ничего интересного я здесь тоже не увидел.

Это была неформальная секция: на травке под деревом собралось пять человек интересующихся развитием интерфейса Fedora и прорисовкой обоев на рабочий стол с её логотипами. У них нашлась бутылка бурчака (молодого чешского вина). Итог - приятно провели время. :)

После краткого курса чешского языка, мы переместились в паб неподалеку и началась не менее интересная неофициальная часть мероприятия.

Ссылки

1. Base WIKI - http://fedoraproject.org/wiki/FUDCon/FUDConPrague2008
2. Фото - http://www.flickr.com/groups/fudconbrno/

На страничке wiki достаточно много ссылок на отчеты и доклады.

Запасной VPN (ipsec failover high availability stateless)

2008-07-15T20:28:00.000+02:00

0. Вводная

Думаю не нужно объяснять зачем это нужно и где применяется. Всё просто - если для вас потеря vpn соединения критична и работа останавливается, возможно стоит подумать о конфигурировании некоторой избыточности. Основных подходов в данном случае два:

- отказоустойчивый узел из двух или более устройств при этом активным является только одно устройство и данные о сессиях протокола более высокого уровня не синхронизируются между устройствами (stateless);
- отказоустойчивый узел из двух или более устройств, активно только одно, данные о сессиях синхронизированы (stateful).

Как очевидно основное отличие между двумя подходами в том, что при переключении с основного на резервное устройство и наборот текущие сессии ipsec сбрасываются. Конечно ситуация отрабатывается протоколами инкапсулироваными в ipsec пакеты, как tcp/udp, и скорее всего произойдет только некоторое "замораживание" соединения. Из опыта могу сказать, что задержка обычно немногим больше задержки возникающей при создании нового туннеля. Для большинства приложений этого достаточно.

1. Схема

Шифрации подлежит трафик
10.10.200.0/24 <-> 10.10.1.0/24
10.10.100.0/24 <-> 10.10.1.0/24

2. Конфигурация

Удивительно, но процесс настройки оказался достаточно простым. Основой всего является протокол HSRP (если словосочетание незнакомо, крайне рекомендую пройтись по ссылке) и ipsec собственно. Я не буду вдаваться в нюансы настройки HSRP или ipsec, для этого были написаны специальные заметки - HSRP, static ipsec . :)

По сути изменяется всего две команды.
В первую очередь необходимо добавить имя в конфигурацию hsrp

//конфигурация hsrp, добавлено имя
vpn0(config-if)#standby version 2
vpn0(config-if)#standby 100 ip 10.10.11.1
vpn0(config-if)#standby 100 priority 150
vpn0(config-if)#standby 100 preempt
vpn0(config-if)#standby 100 name vpn

Вторая команда - при применении crypto map к интерфейсу указывается имя hsrp группы которая будет обеспечивать отказоустойчивость.
//применение отказоустойчивого vpn
vpn0(config-if)#crypto map cr_outside redundancy vpn

В качестве дополнения приведу полную конфигурацию.

vpn0
Базовая конфигурация

crypto isakmp policy 200
encr aes
authentication pre-share
group 2
crypto isakmp key MyKey address 10.10.10.10
!
crypto ipsec transform-set ts-aes-sha esp-aes 256 esp-sha-hmac
!
crypto map cr_outside 200 ipsec-isakmp
set peer 10.10.10.10
set transform-set ts-aes-sha
match address 120
!
interface FastEthernet0/0
ip address 10.10.11.10 255.255.255.0
duplex auto
speed auto
standby version 2
standby 100 ip 10.10.11.1
standby 100 priority 150
standby 100 preempt
standby 100 name vpn
crypto map cr_outside redundancy vpn
!
access-list 120 permit ip 10.10.200.0 0.0.0.255 10.10.1.0 0.0.0.255
access-list 120 permit ip 10.10.1.0 0.0.0.255 10.10.200.0 0.0.0.255
access-list 120 permit ip 10.10.100.0 0.0.0.255 10.10.1.0 0.0.0.255
access-list 120 permit ip 10.10.1.0 0.0.0.255 10.10.100.0 0.0.0.255

vpn1
Совершенна идентична vpn0 за исключением адреса интерфейса и приоритета hsrp

crypto isakmp policy 200
encr aes
authentication pre-share
group 2
crypto isakmp key MyKey address 10.10.10.10
!
crypto ipsec transform-set ts-aes-sha esp-aes 256 esp-sha-hmac
!
crypto map cr_outside 200 ipsec-isakmp
set peer 10.10.10.10
set transform-set ts-aes-sha
match address 120

interface FastEthernet0/0
ip address 10.10.11.20 255.255.255.0
duplex auto
speed auto
standby version 2
standby 100 ip 10.10.11.1
standby 100 priority 101
standby 100 preempt
standby 100 name vpn
crypto map cr_outside redundancy vpn

access-list 120 permit ip 10.10.200.0 0.0.0.255 10.10.1.0 0.0.0.255
access-list 120 permit ip 10.10.1.0 0.0.0.255 10.10.200.0 0.0.0.255
access-list 120 permit ip 10.10.100.0 0.0.0.255 10.10.1.0 0.0.0.255
access-list 120 permit ip 10.10.1.0 0.0.0.255 10.10.100.0 0.0.0.255

client1
Простейшее из возможного

crypto isakmp policy 200
encr aes
authentication pre-share
group 2
crypto isakmp key MyKey address 10.10.11.1
!
crypto ipsec transform-set ts-aes-sha esp-aes 256 esp-sha-hmac
!
crypto map cr_outside 200 ipsec-isakmp
set peer 10.10.11.1
set transform-set ts-aes-sha
match address 120

interface FastEthernet0/0
ip address 10.10.10.10 255.255.255.0
duplex auto
speed auto
crypto map cr_outside

access-list 120 permit ip 10.10.200.0 0.0.0.255 10.10.1.0 0.0.0.255
access-list 120 permit ip 10.10.1.0 0.0.0.255 10.10.200.0 0.0.0.255
access-list 120 permit ip 10.10.100.0 0.0.0.255 10.10.1.0 0.0.0.255
access-list 120 permit ip 10.10.1.0 0.0.0.255 10.10.100.0 0.0.0.255

3. Проверка
Проверялось всё это хозяйство путем установки telnet сессии с маршрутизатора srv на client1 и принудительной остановкой интерфейса FastEthernet0/0 на vpn0. Показательно, что сессия telnet при этом не разорвалась хотя "замерла" на примерно 10-15 секунд.

Также необходимо обратить внимание на правильную маршрутизацию внутри vpn рутеров, в моём случае это сделано с помощью простейшей конфигурации ospf, подобной описанной в одной из прошлых заметок, однако можно использовать тот же hsrp с опцией трекинга outside интерфейса.

Защищая себя (zone-based firewall self)

2008-07-03T20:21:00.004+02:00

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

Для управлением трафиком предназначенным непосредственно маршрутизатору или трафику создаваемому им самим, в понимании ZBF предназначена специальная зона - self.
Соответственно, да контроля, например, доступа к маршрутизатору из интернета, необходимо создать цепочку (zone-pair) internet -> self и уже в контексте её политики задавать необходимы разрешения..

По умолчанию зона уже создана. Одно из основных отличий от "нормальных" зон - поведение по-умолчанию, трафик к/от self зоны разрешен.
Также отмечу, self зона достаточно обрезана в функциональности инспекция возможна только для протоколов tcp, udp, icmp, H.323

Опять таки, простейший пример конфигурации:
- из интернета запретить всё кроме icmp;
- из интранета, дополнительно к icmp разрешить ssh и https для задач управления.

Значительно облегчит задачу существующий по-умолчанию класс - class-default выделяющий весь трафик, наподобие permit any any acl.

Логичным было бы создать примерно следующую политику:

 R1(config)#class-map type inspect match-all cm_manage
 R1(config-cmap)#match protocol icmp
 R1(config-cmap)#match protocol ssh
 R1(config-cmap)#match protocol https

R1(config)#policy-map type inspect in-self
 R1(config-pmap)#class type inspect cm_manage
 R1(config-pmap-c)#inspect 
 R1(config-pmap)#class class-default
 R1(config-pmap-c)#drop    

R1(config)#zone-pair security in-self source inside destination self
 R1(config-sec-zone-pair)#service-policy type inspect in-self

Но не выходит. :)
Здесь мы сталкиваемся с ограничением на глубину инспекции в self зонах. Как сказано выше, максимальный уровень инспекции в данном случае - L3/L4. При применении получаем сообщение вида:

R1(config-sec-zone-pair)#service-policy type inspect out-self
%Protocol https configured in class-map cm_manage cannot be configured for the self zone. Please remove the protocol and retry

Inspect service-policy attachment failed

Заставить злобную железяку всё таки разрешать соединения по протоколам ssh и https можно следующим образом:

 R1(config)#access-list 198 permit tcp any any eq 22
 R1(config)#access-list 198 permit tcp any any eq 443

 R1(config)#class-map type inspect match-any cm_manage
 R1(config-cmap)#match protocol icmp
 R1(config-cmap)#match access-group 198

 R1(config)#policy-map type inspect in-self
 R1(config-pmap)#class type inspect cm_manage
 R1(config-pmap-c)#inspect
 R1(config-pmap)#class class-default
 R1(config-pmap-c)#drop

 R1(config)#zone-pair security in-self source inside destination self
 R1(config-sec-zone-pair)#service-policy type inspect  in-self

Хочу обратить внимание, что реальной инспекции именно протоколов http и ssh не происходит, пакеты инспектируются до уровня tcp.

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

Вот мы и познакомились с общими концепциями построение брандмауэров от Cisco. Хочется заметить, представленный метод конечно достаточно громоздок и если у вас всего два интерфейса между которыми необходимо настроить инспекцию, возможно классический CBAC в этом окажется удобнее, как минимум объем команд меньше.
Если же конфигурация усложняется, или же имеет свойство изменяться, Zone-Based Firewall именно то решение которое необходимо. Конфигурация гораздо легче читается и поддерживать, расширять, её проще.

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

2008-06-30T19:28:00.004+02:00

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

Динамический рутинг поверх vpn (ospf over gre ipsec)

2008-05-04T19:39:00.008+02:00

0. Зачем
После прочтения заметки о конфигурации gre ipsec может остаться некоторое недопонимание того зачем, собственно, так усложнять достаточно простую первоначальную конфигурацию.
Данная запись призвана ответить на эти вопросы.
Тем читателям, которые попали сюда по поиску из google или еще каким путем я настоятельно рекомендую прочитать предыдущую часть о настройке gre ipsec, а уже потом возвращаться сюда.
Итак речь идёт о запуске динамических протоколов маршрутизации, в данном случае ospf, поверх существующего vpn соединения.
В случае статической конфигурации, необходимо жесткое указание сетей подлежащих шифрованию. Для этого в конфигурации без gre используются crypto acl.
Если же конфигурация сетей меняется необходимо менять и конфигурацию. Представим довольно жизненную ситуацию - головной офис и определённое количество филиалов.
С случае появления в головном отделении новых ip сетей, необходимо произвести перенастройку всех рутеров, как в центрального так и филиальных. При большом количестве филиалов это может быть непосильной задачей.

1. Описание стенда
Настройка продолжается ровно с того места на котором закончилась статья о конфигурировании gre ipsec. Итак у нас есть следующая конфигурации IP сетей.

Внутренняя сеть А: 192.168.1.0/24
Внутренняя сеть Б: 192.168.2.0/24

Внешний интерфейс А: 10.10.11.2/24
Внешний интерфейс Б: 10.10.10.2/24

Допустим, что А это филиал, а Б головное отделение. В случае статического ipsec туннеля указание какой трафик подлежит шифрации с помощью crypto acl.
// routerA
RouterA(config)# access-list 120 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255

В случае gre ipsec необходимо статическим маршрутом указать куда напрявлять трафик для определённой сети.
RouterA(config)# ip route 192.168.2.0 255.255.255.0 Tunnel10
После этого трафик попадает в туннель, инкапсулируется в gre, а crypto acl настроеные между пирами пропускали его через процедуру шифрации.

Теперь представим, что в центральном офисе (сеть Б) появилась новая сеть, например 10.200.1.0/24, для обеспечения её видимости в филиалах, необходимо либо добавить по строчке вcrypto acl (static ipsec) либо добавить маршрут (gre ipsec ), что конечно не составляет проблемы для десятка устройств. Но мы же помним, что организация у нас большая и туннелей условно бесконечное количество. :)

2. Конфигурация
Простейшая конфигурация ospf достаточно проста и не вызывает особых проблем. Я не буду рассказывать о принципах работы, алгоритме или прочих ньансах работы этого протокола. В сети достаточно много информации по этой теме. Цель данной заметки показать практическое применение и не дать себе забыть эту простую но в то же время крайне эффективную конфигурацию. :)
Описание настройки.
- число после слова ospf обозначает просто номер процесса ospf на данном устройстве, нет смысла стремиться к его идентичности
- логирование изменений
- ключевая строка, описание сети которые будут анонсироваться от данного рутера. О том что такое area можно говорить долго, но не сейчас. Обратите внимание, используется не маска сети, а wildcard, как в acl.

//Настройка ospf. RouterA
RouterA(config)# router ospf 100
RouterA(config-router)# log-adjacency-changes
RouterA(config-router)# network 192.168.1.0 0.0.0.255 area 10

Практически анологична настройка ospf на рутере Б, исключение составляет дополнительная сеть.

//Настройка ospf. RouterB
RouterB(config)# router ospf 100
RouterB(config-router)# log-adjacency-changes
RouterB(config-router)# network 10.150.1.0 0.0.0.255 area 10
RouterB(config-router)# network 192.168.2.0 0.0.0.255 area 10

В принципе в документации сказано о том, что для указания процессу ospf работать на конкретном интерфейсе необходимо указать сеть относящуюся к данному интерфейсу в конфигурации network.
Т.е. в данном случае сети 10.10.11.0/24 и 10.10.10.0/24 также должны быть указаны. Если у вас версия IOS менее чем 12.4 так и придется сделать. Я же сделаю немного по-другому.
//Настройка ospf. RouterA
RouterA(config)# interface Tunnel10
RouterA(config)# ip ospf 100 area 10

Это просто указание процессу работать на данном интерфейсе. Об этом трюке я узнал от простого словацкого парня Ивана, чей блог я с удовольствием читаю.
После настройки ospf указание статического маршрута более не нужно. Т.е. для рутера А.
//удаление статического маршрута
RouterA(config)# no ip route 192.168.2.0 255.255.255.0 Tunnel10

Теперь можно взглянуть на таблицу маршрутизации во всей красе.

RouterA#sh ip route | beg Gateway
Gateway of last resort is 10.10.11.1 to network 0.0.0.0

10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C 10.10.11.0/24 is directly connected, FastEthernet1/0
O 10.150.1.0/24 [110/11122] via 10.10.10.2, 00:00:22, Tunnel10
C 192.168.1.0/24 is directly connected, FastEthernet0/1
O 192.168.2.0/24 [110/11121] via 10.10.10.2, 00:00:22, Tunnel10
S* 0.0.0.0/0 [1/0] via 10.10.11.1

Как видно, анонсы сетей прошли и рутер А видит маршруты в сети за рутером Б через ospf, что и было необходимо.
Теперь при появлении в центральном отделении новых сетей, конфигурация филиалов не нуждается в изменениях. Всё что необходимо, добавить новую строчкуnetwork в конфигурацию ospf на рутере в центральном офисе. Филиалы узнают об этом практически мгновенно. :)

upd 14.05.08, спасибо Vadim
//Посмотрим на наших соседей.
RouterA#show ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
192.168.2.1 0 FULL/ - 00:00:37 10.10.10.2 Tunnel10

Соединяя офисные пространства (lan-2-lan ipsec vpn gre)

2008-05-04T17:52:00.009+02:00

0. Вводная
Продолжим разборки с различными технологиями vpn предоставляемыми рутерами cisco. Заметка будет больше практического характера. Ориентирована на тех, кто уже знаком с общей теорией работы ipsec и простейшими примерами построения туннелей. Итак, сегодня в качестве примера рассмотрим построение всё такого-же статического туннеля. Отличие только в том, что в данном примере, все пакеты подлежащие шифрованию будут сначалаинкапсулироваться в gre туннель и только потом в ipsec . Зачем такая сложность может ответить любой кто сталкивался с необходимостью пропускать через туннель мультикаст пакеты, которые в свою очередь любят использовать современные протоколы динамической маршрутизации. Впрочем, обо всём по порядку.
Адресация сети снова выглядит следующим образом.

Внутренняя сеть А: 192.168.1.0/24
Внутренняя сеть Б: 192.168.2.0/24

Внешний интерфейс А: 10.10.11.2/24
Внешний интерфейс Б: 10.10.10.2/24

Между внешними интерфейсами у меня находиться pix. В данном случае это не так важно, но он поможет сниффить проходящий траффик.

1. Труба (она же туннель).
Итак, необходимо установить туннель между внешними интерфейсами маршрутизаторов, в данном случае 10.10.11.2 и 10.10.10.2.
Минимальные параметры настройки:
- каждый туннель "привязывается" к конкретному физическому интерфейсу, в данном случае это FastEthernet 1/0.
- поскольку это layer 3 соединения, необходима ip адресация. Для уменьшения путаницы с "лишними" адресами будем использовать адреса физических интерфейсов. Ссылка.
- совершенно очевидно, что раз есть у туннеля начало, значит еть где-то и конец :) Указание второго пира, также обязательный параметр.
В примере приведена конфигурация только одной стороны туннеля, очевидно другая сторона конфигурируется идентично за исключением адреса пира.

//пример конфигурации gre туннеля
RouterA(config)# interface Tunnel10
RouterA(config-if)# tunnel source FastEthernet1/0
RouterA(config-if)# tunnel destination 10.10.10.2
RouterA(config-if)# ip unnumbered FastEthernet1/0

Итак туннель поднят, но не совсем понятно для каких целей, поскольку по нему еще ничего не ходит. Развернем рутинг для сетей 192.168.1.0/24 и 192.168.2.0/24, соответственно в сторону туннеля.
//рутинг в туннель
RouterA(config)# ip route 192.168.2.0 255.255.255.0 Tunnel10

Для рутера Б, нужно развернуть сеть 192.168.1.0/24.
Теперь внутренние сети находящиеся за рутерами видят друг друга.
//простейшая проверка - ping
RouterA#ping
Protocol [ip]:
Target IP address: 192.168.2.1
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 192.168.1.1
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/61/104 ms

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

// sniff
pixfirewall# show cap anyin
10 packets captured
1: 16:01:56.004577 10.10.11.2 > 10.10.10.2: ip-proto-47, length 104
2: 16:01:56.024870 10.10.10.2 > 10.10.11.2: ip-proto-47, length 104
(skip)
9: 16:01:56.232715 10.10.11.2 > 10.10.10.2: ip-proto-47, length 104
10: 16:01:56.249163 10.10.10.2 > 10.10.11.2: ip-proto-47, length 104
10 packets shown

Как и предпологалось, туннель работает нормально. Протокол 47 стека IP И есть gre.

2. Шифруем

Дальше всё просто. Принципиальных отличий между данной и минимальной конфигурацией практически никаких. Всё что нужно сделать это изменить crypto acl определяющий какой трафик подлежит шифрации.
Поскольку сниффер нам показал только gre пакеты между двумя пирами шифровать будем только их. Что в принципе достаточно очевидно. :)
//crypto acl, конечно они должны быть зеркальны с обоих сторон туннеля
RouterA(config)# access-list 150 permit gre host 10.10.11.2 host 10.10.10.2

isakmp, crypto map и прочие безобразия настраиваются совершенно идентично. На всякий случай привожу кусок конфигурации рутера А.

//пример окончательной конфигурации
!
crypto isakmp policy 200
encr aes 256
authentication pre-share
group 2
lifetime 36000
crypto isakmp key sUpeRkEy address 10.10.10.2
!
crypto ipsec transform-set ts-aes-sha esp-aes 256 esp-sha-hmac
!
crypto map cr_outside 200 ipsec-isakmp
set peer 10.10.10.2
set transform-set ts-aes-sha
match address 150
!
interface Tunnel10
ip unnumbered FastEthernet1/0
tunnel source FastEthernet1/0
tunnel destination 10.10.10.2
!
interface FastEthernet1/0
ip address 10.10.11.2 255.255.255.0
duplex auto
speed auto
crypto map cr_outside
!
ip route 192.168.2.0 255.255.255.0 Tunnel10
!
access-list 150 permit gre host 10.10.11.2 host 10.10.10.2
!

// Проведем то же элементарное тестирование с помощью ping. Ниже представлен вывод сниффера.
pixfirewall# show capture anyin
17 packets captured
1: 15:33:57.516788 10.10.11.2.500 > 10.10.10.2.500: udp 144
2: 15:33:57.741477 10.10.10.2.500 > 10.10.11.2.500: udp 104
3: 15:33:57.911284 10.10.11.2.500 > 10.10.10.2.500: udp 304
4: 15:33:58.126153 10.10.10.2.500 > 10.10.11.2.500: udp 304
5: 15:33:58.186025 10.10.11.2.500 > 10.10.10.2.500: udp 108
6: 15:33:58.206059 10.10.10.2.500 > 10.10.11.2.500: udp 76
7: 15:33:58.219852 10.10.11.2.500 > 10.10.10.2.500: udp 172
8: 15:33:58.259401 10.10.10.2.500 > 10.10.11.2.500: udp 172
9: 15:33:58.268388 10.10.11.2.500 > 10.10.10.2.500: udp 60
10: 15:33:59.395807 10.10.11.2 > 10.10.10.2: ip-proto-50, length 164
11: 15:33:59.444541 10.10.10.2 > 10.10.11.2: ip-proto-50, length 164
(skip)
17: 15:33:59.556703 10.10.10.2 > 10.10.11.2: ip-proto-50, length 164
17 packets shown

Как и ожидалось, конфигурация работает и даже шифрует трафик.
Первые 9 пакетов показывают обмен небольшими udp пакетами по 500 порту. Этот порт используется isakmp при установлении SA.
Далее идёт обмен пакетами протокола 50 стека IP, что и есть, собственно, ipsec.

Оцени меня

2008-04-30T06:53:00.005+02:00

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

Линк: http://www.ratemynetworkdiagram.com/

Соединяя офисные пространства (lan-2-lan vpn pre-shared)

2008-04-21T20:00:00.008+02:00

0. Общие слова
Зачем нужен vpn и что с ним делать рассказывать не буду, в сети достаточно много информации на эту тему. Скажу только, что под vpn подразумевается ipsec и в данной заметке описывается построение site to site vpn используя pre-shared keys, т.е. соединение двух локальных сетей, например центрального отделения и филиала через открытую сеть типа интернет. Используемое оборудование - рутер cisco. Заметка сугубо практическая, поскольку рассмотрение теории займет достаточно много места и времени. Краткий обзор: что происходит при построении ipsec туннеля можно найти в одной из предыдущих заметок.

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

Внутренняя сеть А: 192.168.1.0/24
Внутренняя сеть Б: 192.168.2.0/24

Внешний интерфейс А: 10.10.11.2/24
Внешний интерфейс Б: 10.10.10.2/24

Необходимо убедиться, что существующие acl совместимы с ipsec. Как требует документация необходимо разрешить прохождения трафика по протоколам 51 (ah) и 50 (esp) стека ip, зависит от желаемой конфигурации. Порт 500/udp и echo/echo-replay. Впрочем без разрешенного icmp у меня туннель заработал.

1. Установка триггера на трафик подлежащий шифрованию

Задача, соответственно, состоит в том, чтобы позволить пользователям из сети 192.168.1.0/24 получать доступ к компьютерам находящимся в сети 192.168.2.0/24 и наоборот.
На первом этапе ipsec рутер просматривает проходящий через него трафик и если находит пакет совпадающий с определенным acl, шифрует его и передает дальше. Таким образом первая задача - определить трафик подлежащий шифрованию с помощью acl. Логично, что acl должны быть совершенно зеркальны на обоих сторонах туннеля, поскольку SA создаются уникальные для source и destination в прямом и обратном направлении. Соответственно, если acl будут не зеркальны, то и туннель не установится.

//Пример acl
// routerA
RouterA(config)# access-list 120 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255
// routerB
RouterB(config)# access-list 120 permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255

2. Первая фаза IKE
Следующий этап - создание IKE SA.
Поскольку на каждому рутере может создаваться несколько IKE SA для различных туннелей с различными настройками безопасности используются политики IKE с различными уровнями приоритета (<1-10000), id="ce4u">Каждая политика характеризуется следующими параметрами: алгоритм шифрования, алгоритм хеширования, метод аутентификации, используемая реализация алгоритма Диффи-Хелмана, время жизни SA. Настройки по-умолчанию можно посмотреть следующим образом:

//политика IKE по-умолчанию
RouterA#sh crypto isakmp policy

Global IKE policy
Default protection suite
encryption algorithm: DES - Data Encryption Standard (56 bit keys).
hash algorithm: Secure Hash Standard
authentication method: Rivest-Shamir-Adleman Signature
Diffie-Hellman group: #1 (768 bit)
lifetime: 86400 seconds, no volume limit

Минимально необходимых, а мы сейчас говорим именно о них, параметров не так много. В данном случае изменим метод аутентификации на pre-shared keys, заменим не рекомендуемый аглоритм шифрования данных, на продвинутый (DES & AES) и Диффи-Хелмана на вторую группу, 1024 бита.
Поскольку в качестве метода аутентификации выбран метод распределенного ключа, его необходимо также указать.
Манипуляции производятся следующими командами.

// Настройки необходимые для IKE SA, в данном случае политика с приоритетом 200
// ключ указывается отдельно от политики, поскольку в общем случае он почти ничего общего с ней не имеет,
// политика может использоваться многократно для нескольких туннелей. Ключ желательно оставлять уникальным для каждого пира.
// Конечно, настройки для рутера Б должны быть идентичны за исключением адреса другого конца туннеля.
RouterA(config)# crypto isakmp policy 200
RouterA(config-isakmp)# encr aes
RouterA(config-isakmp)# authentication pre-share
RouterA(config-isakmp)# group 2
RouterA(config)# crypto isakmp key sUpeRkEy address 10.10.10.2

3. Вторая фаза IKE
В рамках второй фазы IKE происходит установка ipsec SA которые потом будут использоваться непосредственно для шифрования трафика.
Для этого необходимо указать желаемые параметры: алгоритм и шифрования и хеширования. Происходит это путем создания так называемого transform-set.

// В данном случае:
// ts-aes-sha - имя данного transform-set
// esp-aes 256 - алгоритм шифрования и длина его ключа
// esp-sha-hmac - алгорим хеширования
RouterA(config)# crypto ipsec transform-set ts-aes-sha esp-aes 256 esp-sha-hmac

Следущим этапом идет создание специальной крипто карты, которая связывает всё вместе. Именно эта карта потом привязывается к конкретному интерфейсу.
Поскольку для каждого интерфейса может быть определена только одна крипто карта, здесь используется тот же принцип приоритетов, позволяющий создавать туннели к разным пирам и с различными параметрами безопасности.
Параметров не так много: адрес другого конца туннеля, имя желаемомого transform-set, acl который будет использваться как триггер для данной крипто карты.

//Пример crypto map
RouterA(config)# crypto map cr_outside 200 ipsec-isakmp
RouterA(config-crypto-map)# set peer 10.10.10.2
RouterA(config-crypto-map)# set transform-set ts-aes-sha
RouterA(config-crypto-map)# match address 120

4. Нормальная работа
Почти всё необходимые настойки произведены, осталось только указать интерфейс используемый как источник для создния туннеля и включить "глобальный выключатель" разрешающий использовать IKE и слушать 500/udp порт.

//Привязка созданной крипто карты к интерфейсу
RouterA(config-if)#crypto map cr_outside

//Включить IKE
RouterA(config)#crypto isakmp enable

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

// Просмотр активных туннелей
RouterA#sh crypto engine connections active
ID Interface IP-Address State Algorithm Encrypt Decrypt
2001 FastEthernet1/0 10.10.11.2 set AES256+SHA 9 0
2002 FastEthernet1/0 10.10.11.2 set AES256+SHA 0 9

Насколько видно из примера, создано две SA каждая используется для одного направления. В данном случае SA c ID 2001 используется для шифрования, а c ID 2002 для расшифровывания, что видно по счетчикам пакетов.

Более подробную информацию может дать команда show crypto ipsec sa.

// Доступные SA на рутере.
RouterA#sh crypto ipsec sa

interface: FastEthernet1/0
Crypto map tag: cr_outside, local addr 10.10.11.2

protected vrf: (none)
local ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (192.168.2.0/255.255.255.0/0/0)
current_peer 10.10.10.2 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 9, #pkts encrypt: 9, #pkts digest: 9
#pkts decaps: 9, #pkts decrypt: 9, #pkts verify: 9
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 1, #recv errors 0

local crypto endpt.: 10.10.11.2, remote crypto endpt.: 10.10.10.2
path mtu 1500, ip mtu 1500
current outbound spi: 0xB2259128(2988806440)

inbound esp sas:
spi: 0x8A02CA5F(2315438687)
transform: esp-256-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 2002, flow_id: SW:2, crypto map: cr_outside
sa timing: remaining key lifetime (k/sec): (4533541/3425)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE

inbound ah sas:

inbound pcp sas:

outbound esp sas:
spi: 0xB2259128(2988806440)
transform: esp-256-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 2001, flow_id: SW:1, crypto map: cr_outside
sa timing: remaining key lifetime (k/sec): (4533541/3425)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE

inbound ah sas:

inbound pcp sas:

outbound esp sas:
spi: 0xB2259128(2988806440)
transform: esp-256-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 2001, flow_id: SW:1, crypto map: cr_outside
sa timing: remaining key lifetime (k/sec): (4533541/3363)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE

outbound ah sas:

outbound pcp sas:

Новый CSA

2008-04-09T17:50:00.004+02:00

Появилась новая версия Cisco Security Agent.
Достаточно интересно, что теперь к функцям HIPS та же добавилась функциональнасть ативируса. Также достаточно забавно, что несмотря на достаточно долгое и успешное сотрудничество Cisco c компанией Trendmicro в данном случае использован движок open-source проекта ClamAV. Судя по информации представленной на сайте cisco, монитора реального времени нет, на данный момент реализована только проверка по-требованию.
Однако существует возможность удалённого управления и обновления антивируса из менеджмент консоли самого CSA.

2008-04-03T21:45:00.000+02:00

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

2008-03-30T15:06:00.002+02:00

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

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

2008-02-05T09:51:00.000+01:00

Краткая заметка о настройке 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

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

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

2008-01-23T10:31:00.000+01:00

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

2007-12-11T07:03:00.001+01:00

Настройка 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 создает новое соединение с оригинальным хостом назначения.

uRPF loose mode

2007-12-04T20:03:00.001+01:00

Не так давно я уже писал о Unicast Reverse Path Forwarding технологии и одной из отличитильных особенностей реализации была невозможность её использования при асинхронном рутинге. Связано это с тем, что проверка достижимости проводилась с помощью cef для каждого конкретного интерфейса.
Времена меняються! Собственно они изменились еще с версии 12.2Т IOS, просто я узнал об этом только сейчас. :)

Итак. Старый режим, известный как uRPF, теперь называется uRPF strict mode, а новый uRPF loose mode.
Изменения в первую очередь касаються работы с асинхронным рутингом. Теперь проверка достижимости адреса источника осуществляется для всех интерфейсов. Другими словами неважно откуда пришел пакет, если есть дорога обратно то он легитимен.

Настроить такое поведени можно с помощью команды ip verify unicast source reachable-via выполненой в контексте интерфейса.

RouterA (config-if)# ip verify unicast source reachable-via {rx|any} [allow-default]

rx - возврат к истокам. strict mode, проверять достижимость источника только для интерфейса через который пакет получен
any - loose mode, проверять доостижимость через любой доступный интерфейс
allow-default - использовать ли для проверки default route

Дополнительно loose mode отбрасывает пакеты с адресами источника:
- адреса зарезервированные для специального применения (0/8, 127/8);
- адреса предназначенные для частных сетей (RFC 1918);
- адреса которые рутятся в интерфейс null на рутере.

Легкий debug
Проверить "работает ли эта штуковина" можно следующими способами:

RouterA# show ip interface Serial1/1 | in verif
RouterA# show ip traffic | in RPF

В обоих случаях можно увидеть счетчики RFP. Увеличение которых, показывает отброшенные пакеты.

ASA Firewall operation

2007-11-19T06:34:00.000+01:00

Что происходит с пакетом попадающим внутрь 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

2007-11-06T10:32:00.001+01:00

Зачастую можно увидеть как сетевые администраторы используют традиционные списки доступа для предотвращения подделки адресов (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

2007-10-11T18:52:00.001+02:00

Периодически приходят посетители с 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: кто это сделал!?

2007-10-08T20:31:00.000+02:00

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

*Mar 1 00:12:15.675: %SYS-5-CONFIG_I: Configured from console by one on vty0 (10.10.10.1)

И всё!

С некоторой версии ios появилась возможность посмотреть кто и что конкретно сделал. Подробненько. :)
Для этого необходимо добавить в конфигурацию следующие строки:

archive
log config
logging enable
notify syslog
hidekeys

logging enable - писать лог. По умолчанию выключено.
notify syslog - писать лог локально или посылать также на syslog сервер
hidekeys - не записывать в лог пароли

Теперь процесс логина и изменения отобразится примерно следующим образом:
Легко определить что в гости заходил пользователь one и настроил интерфейс FastEthernet1/0.

*Mar 1 00:18:18.839: %PARSER-5-CFGLOG_LOGGEDCMD: User:one logged command:!exec: enable
*Mar 1 00:18:58.003: %PARSER-5-CFGLOG_LOGGEDCMD: User:one logged command:interface FastEthernet1/0
*Mar 1 00:19:11.023: %PARSER-5-CFGLOG_LOGGEDCMD: User:one logged command:ip address 192.168.1.1 255.255.255.0
*Mar 1 00:19:13.715: %PARSER-5-CFGLOG_LOGGEDCMD: User:one logged command:no shutdown
*Mar 1 00:19:15.687: %LINK-3-UPDOWN: Interface FastEthernet1/0, changed state to up
*Mar 1 00:19:16.687: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0, changed state to up

Официальная документация
http://www.cisco.com/en/US/products/ps6350/products_configuration_guide_chapter09186a0080454f8c.html#wp1100253

BGP: запоминаем порядок

2007-10-01T13:48:00.000+02:00

BGP использует алгоритм для определения правильной дороги к определенной сети.
Подробно он описан в следующем документе.
http://cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094431.shtml

Однако запомнить порядок трудновато. Совершенно случайно нашел мнемонику которая позволяет здорово облегчить жизнь.

“We Love Oranges AS Oranges Mean Pure Refreshment”

W Weight (Highest)
L Local_Pref (Highest)
O Originate (local originate)
AS As_Path (shortest)
O Origin Code (IGP <>

нашёл здесь.

Live and learn

2007-09-12T08:52:00.000+02:00

[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).

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

2007-09-11T08:31:00.000+02:00

Сырая версия, но ньансов настолько много, что хочеться записать то что помниться, чтобы потом дополнять.
Итак, поговорим о 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) либо по истечении тайм-аута.

GLBP

2007-09-04T16:35:00.000+02:00

Продолжая тему резервирования...

0. Официальная документация
http://cisco.com/en/US/products/sw/iosswrel/ps1839/products_white_paper09186a00801541c8.shtml
http://cisco.com/en/US/products/ps6600/products_data_sheet0900aecd803a546c.html
http://cisco.com/en/US/products/ps6600/prod_presentation0900aecd801790a3.html

1. Зачем это нужно и как это работает
Зачем нужен еще один протокол? В отличии от HSRP который работает в режиме Active/Standby GLBP работает в режиме Active/Active.
Это означает, что дополнительно к функциям резервирования реализуемым HSRP добавилась возвожность реализовать Load Sharing.

Краткий принцип работы: выбирается главный рутер (AVG), все остальные играют пассивную (AVF) роль. Управляющий рутер назначает каждому пассивному дополнительный виртуальный МАС адрес.
Каждый из рутеров имеет на интерфейса одинаковый виртуальный IP.
AVG отвечает на ARP запросы спрашивающие МАС виртуального IP посылая в ответ один из виртуальных МАС адресов пассивных рутеров (AVF).
Соответственно можно ожидать, что распределение трафика по разным рутерам будет примерно одинаковым.

Максимальное количество рутеров в одной GLBP группе равно четырем.
Количество GLBP групп на одном интерфейсе не должно превышать 1024. Соответственно от 0 до 1023.

AVG - Active Virtual Gateway - главный рутер, основная задача присвоение участвующим рутерам различных виртуальных МАС адресов и ответ на ARP запросы касающиеся виртуального IP.
Дополнительно выбирается Standby Virtual Gateway который перебирает на себя функции AVG в случае отказа последнего.
AVF - Active Virtual Forwarder - занимается непосредственно пересылкой клиентского трафика.

2. Минимальная настройка
Команды вводятся в режиме конфигурации интерфейса

// Основной адрес интерфейса
RouterA(config-if)# ip address 10.0.0.254 255.255.255.0

// Группа в пределах которой работает GLBP и "разделяемый" адрес.
RouterA(config-if)# glbp 20 ip 10.0.0.1
Также есть возможность использовать несколько адресов в пределах конкретной группы. Для этого необходимо использовать ключевое слово secondary после ip адреса.

3. Дополнительные команды
// Приоритет при выборе AVG. Значение по умолчанию - 100.
RouterА(config-if)# glbp 20 priority 254

// Обращать внимание на приоритет при перераспределении ролей AVG/AVF. Действует аналогично HSRP
RouterA(config-if)# glbp 20 preempt

// Алгоритм отвечающий за порядок ответа на ARP запросы. Может быть:
none - в этом случае балансировка не выполняется. AVG всегда отвечает на ARP запросы только своим МАС. Т.е. работаем как обычный HSRP.

round-robin - Крутить по кругу. По истечению тайм-аута хранения МАС адреса у клиента он может получить новый МАС в ответ от AVG. Значение по умолчанию.

host-dependent - По истечению тайм-аута хранения МАС адреса у клиента он гарантированно получит тот же МАС от AVF в ответ на новый запрос. Конечно, до тех пор пока состояние группы неизменно.
Используется в том случае если на рутерах входящих в GLBP группу осуществляется трансляция адресов (NAT), это гарантирует что текущие сессии не потеряются.

weighted - Разделять полосу основываясь на весах весах каждого рутера.
Для использования весов необходимо задать их в конфигурации для каждого рутера участвующего в группе с помощью команды:

RouterA(config-if)# glbp 10 weighting 70
Работает по простому принципу. Если на другом рутере в той же группе задать вес 140, то распределение будет один к двум. Необходимо учитывать, что это не распределение трафика, а распределение хостов.

// Пример
RouterA(config-if)# glbp 20 load-balancing round-robin

// Команда аналогичная HSRP, в ситауции когда рутер с большим приоритетом для данной группы появляется в сети. Отдавать ли ему роль AVG или нет. И если отдавать, то сколько подождать.
Router(config-if)# glbp 20 forwarder preempt delay minimum 30

// tracking. Первым делом нужно создать объект трекинга. Сделать это можно используя следующую команду:
Router(config)# track 100 interface Serial 2/0 line-protocol

todo: разобратся с трекингом подробнее

// Применяем трекинг к glbp. Т.е. в glbp группе 20 отслеживать объект 100 и в случае падения уменьшать приоритет на 20.
Router(config-if)# glbp 20 weighting track 100 decrement 200

При этом что интересно, если один товарищ устал и оставшимся приходится работать за себя и за того парня, AVG ответственнен за пересылку трафика ранее ходившего через упавший AVF. Т.е. отвечает на ARP запросы по его адресам тоже. Тут мне видится такая штука: видимо при использовании в GLBP группе более чем двух активных AVF полезно изначально (с помощью весов) занизить трафик идущий через AVG, поскольку в случае поломки ему и так приходится работать за двоих.

4. Команды диагностики
Легче всего проверить как это выглядит со стороны клиента. Например в данном случае используется алгорит балансировки round-robin. Вывод команды sh arp с двух клиентов.

// Главное поле: Hardware Addr.
Client#sh arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 10.10.10.1 6 0007.b400.1401 ARPA FastEthernet0/0

client1#sh arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 10.10.10.1 4 0007.b400.1402 ARPA FastEthernet0/0

// Еще одна полезная команда
RouterA# sh glbp br
Interface Grp Fwd Pri State Address Active router Standby route
Fa0/0 20 - 254 Active 10.10.10.1 local 10.10.10.4
Fa0/0 20 1 7 Active 0007.b400.1401 local -
Fa0/0 20 2 7 Active 0007.b400.1402 local -