antiCisco blogs


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

Публикации помечены ‘ASA’

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

Identity Firewall (здесь и далее IFW) является эволюцией технологии фаирволла на сетевых экранах Cisco ASA. Главной особенностью технологии является возможность написания различных правил доступа (напр. ACL) относительно не IP-адресов, а конкретно для определенного пользователя или же группы пользователей. Это может быть очень удобно для сетей, где у пользователей нет фиксированных IP-адресов, т.е. в подавляющем большинстве компаний. Читать продолжение записи »

 

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

Опубликовано 10 Декабрь , 2011

Вот мы и добрались до главного: а в какой же последовательности все это богатство трансляций обрабатывается?

Глобально всю последовательность можно разделить на 3 больших блока:
I – Twice NAT
II – Object NAT
III – Twice NAT (after-auto)

Да-да, именно так. И с до и после. По умолчанию трансляции Twice NAT добавляются в конец первой секции, но можно явно указать, в какое место их ставить (ура!) указав номер правила.
nat (INS,OUT) {НОМЕР} …
Логика здесь такая же, как у строк ACL — если пишем «номер 1», то добавляем самым первым правилом, а остальные сдвигаются ниже.

Это очень предусмотрительно со стороны циски 🙂 потому что сами правила в I и III секциях (там, где Twice NAT) обрабатываются по порядку, в котором они записаны в конфиге. Как только совпадение будет найдено, заголовок пакета сразу транслируется и новый пакет отправляется по назначению.

Мы можем принудительно записать трансляции Twice NAT и в третью секцию, указав ключевое слово after-auto. Такое правило вставится в конец третьей секции по умолчанию или в то место третьей секции, которое мы явно укажем при помощи номера строки.
Читать продолжение записи »

 

Метки: , ,
Опубликовано: Безопасность cisco | 2 комментария »

Опубликовано 9 Декабрь , 2011

С object NAT мы познакомились подробно в предыдущих статьях. Пришло время разобраться, что такое TWICE NAT и зачем он вообще нужен.

При помощи данной конструкции можно сделать две принципиальные вещи, которые нельзя сделать при помощи object NAT:
1. Сделать трансляции одной и той же сети в разные адреса в зависимости от того, в какую сеть идет пакет. Это необходимо, например, при построении IPSec – надо не транслировать адреса пакетов, если они направляются в туннель.
2. А еще (то, что нельзя было сделать в версии 8.2 вовсе) – статическая трансляция диапазона (или группы) портов кучкой. Например, пробросить целиком диапазон с 1024 по 65535.

Рассмотрим формат команды для динамических трансляций NAT пока без указания сети назначения:
nat [(SOURCE_INT,DEST_INT)] source dynamic SOURCE MAPPED_SOURCE [interface] [dns]
Читать продолжение записи »

 

Метки: , , , ,
Опубликовано: Безопасность cisco | 2 комментария »

Опубликовано 2 Декабрь , 2011

Продолжаем про новый синтаксис НАТа. Начало тут

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

Для этого также используются объекты. Например, мы хотим анонсировать наружу сервер с адресом 10.100.1.1 (статический NAT) по адресу 20.1.1.102. Для этого мы тоже создаем группы:
object network SERVER
  host 10.100.1.1
!
object network SERVER_GLOBAL
  host 20.1.1.102

И применяем правило статического НАТа для группы, которая описывает реальный адрес сервера:
object network SERVER
  nat (INS,OUT) static SERVER_GLOBAL [dns]

Можно также явно указать адрес, в который мы транслируем
object network SERVER
  nat (INS,OUT) static 20.1.1.102 [dns]

Читать продолжение записи »

 

Метки: , , ,
Опубликовано: Безопасность cisco | 1 комментарий »

Опубликовано 2 Декабрь , 2011

Наверняка многие уже столкнулись с большими изменениями в синтаксисе настройки NAT при переходе от линейки ASA ОС 8.2 к 8.3. Трудно сказать, с чем связано такое резкое изменение подхода, но одно можно сказать уверенно: настройка стала менее понятна и прозрачна. Но это не повод вовсе не использовать версии 8.3, 8.4 и далее (вряд ли разработчики вернут старый синтаксис :))

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

Итак, cisco ввела два новых понятия: Object NAT и Twice NAT, заменив ими все предыдущие типы (Regular, Policy, Identity NAT).
______________
UPD 10.12.11
А также попутно отменила понятие nat-control. Теперь у нас тотальный no nat-control что означает «нет правила НАТ — просто маршрутизировать».
______________

Для начала познакомимся с понятием object NAT, узнаем про последовательность обработки правил object NAT, потом познакомимся с TWICE NAT и в конце подведем черту: опишем всю последовательность правил NAT в новом синтаксисе. Планирую небольшой цикл статей — штуки 4, дабы не перегружать сразу читателей.

Работать будем вот с такой топологией

Рассмотрим простейшую задачу: выйти через ASA в интернет.
Для этого, как и ранее, надо определить, какие внутренние адреса мы собираемся транслировать в какой внешний пул адресов (NAT) или какой адрес (РАТ).
Читать продолжение записи »

 

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

Опубликовано 5 Сентябрь , 2011

Ну вот, настало время описать ту засаду, что обещал в прошлой статье, а заодно расскажу еще про одну хитрость, которую обнаружил «методом тыка» на ACS5.2.
Итак, напомню, что при настройке связки «тройственного союза»: ASA->ACS5.2->RSA SecurID+AD возникает неопределенность. Опишу ее поподробнее.
Запрос от ASA смело уходит через протокол RADIUS на ACS5.2 на котором настроено, что все, что приходит с этой ASA обрабатывается профилем, скажем, VPN_PROFILE. Предположим в этом профиле в качестве сервера аутентификации применен сложный механизм (sequence), состоящий из запроса на RSA Auth Manager и дополнительного запроса атрибутов через LDAP в Active Directory, а в случае неудачи – прямой запрос в AD. Т.е. логика такая: спросить RSA и в случае успеха для данного пользователя запросить атрибуты из AD (например, я использовал memberOf). А если для данного пользователя нет токена, то запросить напрямую AD. Напомню, что по условию задачи все пользователи должны быть в AD.
И вот тут нас и ждет засада!
Читать продолжение записи »

 

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

Опубликовано 8 Февраль , 2011

В главе 15 про Advanced Protocol Handling мы познакомились с механизмом манипуляции пакетами MPF. Но эта часть была бы не полной, если не рассказывать про то, что ASA умеет в плане разбора самого протокола. Напомню, что программисты научили ASA понимать массу протоколов. Понимать значит знать внутреннюю структуру, поля, сообщения данного протокола. А значит манипулировать данными 7 уровня, данными самого приложения.

Как же это сделать?
Прежде чем я буду закидывать вас командами, лирическое отступление, притча, которую я сочинил и рассказывал на курсах.
——-
Представьте себе: вы работаете на рудниках. Например, добываете самоцветы на Урале в 18 веке. Ваши руки сильны и мозолисты, глаз даже в темноте отличит малахит от змеевика. Вы молоды и влюблены. Она прекрасна и юна и вы хотите преподнести ей в сочельник малахитовую шкатулку ручной работы. Но вы не умеете точить малахит. Вы даже не можете с уверенностью сказать, подойдет ли вот этот кусок малахита для шкатулки? А может там трещина, или еще какой изъян? Но на ваше счастье в деревне близ рудника живет и творит МалахитовыйМастер. Вам нужно лишь собрать в мешок весь малахит и принести Мастеру. Сам он стар и никуда не выходит, так что поиск — ваша задача. Из вашего мешка Мастер отберет нужное, а мусор выкинет. И родится чудо рукотворное — подарок суженой неземной красоты…
——
Читать продолжение записи »

 

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

Опубликовано 8 Ноябрь , 2010

Протоколы, которые мы используем в повседневной жизни, не всегда используют одну сессию для своей работы (когда весь обмен данными происходит по одной сессии TCP или UDP). Примерами таких «сложных» для МСЭ протоколов являются FTP, SIP, SCCP, H.323, и многие другие. Все приведенные протоколы используют для служебной информации одно соединение, а для передачи данных – другое. Например, популярный протокол SIP устанавливает служебную сессию на ТСР/5060 с SIP-сервером. Но голосовой поток идет от одного телефона до другого напрямую. Но этого мало: поток идет по паре случайных портов UDP с заголовком RTP (cisco использует для портов источника и назначения пару из диапазона [16384–32767], другие производители могут использовать другие диапазоны, например 2000-65535 или вовсе любые порты UDP из верхнего диапазона портов: 1024-65535). Вот в таких нечеловеческих условиях МСЭ, который стоит на пути прохождения служебного и голосового трафика, должен обеспечить работу не только служебного протокола, но и пропустить голосовой поток. И сделать это безопасно. А значит, МСЭ должен узнать, что за порты будут использовать телефоны для прямого соединения, и какой ip-адрес у локального и удаленного телефонов. Благо, эта информация передается по служебному каналу TCP/5060 при помощи специальных сообщений. Вот эти сообщения и может подслушивать МСЭ. А подслушав МСЭ, может поместить такую сессию в кэш сессий заранее! Вы, конечно, помните, что когда приходит пакет, ASA его сначала проверяет в кэше сессий и только потом по входящему списку доступа.

Для каждого сложного протокола надо знать структуру его сообщений и уметь использовать их для корректной и безопасной работы МСЭ. Глубокое инспектирование подразумевает собой разбор протокола до 7 уровня модели OSI. Понятно, что такой разбор требует затрат CPU и не малых. Поэтому включать инспектирование всех доступных протоколов «на всякий случай» не рекомендую.
Читать продолжение записи »

 

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

Опубликовано 19 Сентябрь , 2010

С 7 версии ОС у ASA наконец появилась хоть какая-то возможность управлять потоками пакетов. Т.е. появились зачатки QoS. В версии 8.0 эти возможности весьма расширили.
На ASA эту технологию, видимо, чтобы запутать админов, называют не так, как на маршрутизаторах. Там она называется MQC (Modular QoS CLI), а на asa — MPF. Однако, идея похожая: надо определить классы трафика при помощи команды class-map, затем создать политику (policy-map), где для различным классам сопоставить различные действия для качества обслуживания (например, ограничить полосу до явно указанной), или другие сложные действия (например, поменять параметры в ТСР заголовке или отправить на модуль AIP-SSM). И последним шагом надо применить созданную политику при помощи команды service-policy к интерфейсу либо глобально. Вот давайте с этими тремя шагами поподробнее познакомимся.
Читать продолжение записи »

 

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

Опубликовано 21 Апрель , 2010

Бесклиентское подключение (только с использованием браузера) — популярная топология. Это удобно, красиво и безопасно для внутренней сети. Но через браузер возможно обеспечить только связь протоколов, которые могут работать через него: HTTP(S), CIFS. Дополнительно можно пробросить и другие приложения (тонкий клиент), но только работающие по ТСР. Для этого используется Java.

Вообще говоря, настроить базово SSL VPN на ASA можно 2 командами

webvpn
  enable {INTERFACE}

При этом для аутентификации будет использоваться локальная база данных пользователей, попадать вы будете в туннельную группу DefaultRAGroup, а групповые настройки применятся из групповой политики DfltGrpPolicy (все эти смешные названия можно увидеть, только через sh run all). При включении SSL VPN шлюз будет использовать порт TCP/443 и самоподписанный сертификат для удостоверения «личности». Понятно, что все браузеры будут ругаться на самоподписанный сертификат, ибо ему нет доверия. Если на указанном интерфейсе также используется управление по ASDM на том же порту, то оно «переедет» на зарезервированный URL
https://{IP}/admin
Читать продолжение записи »

 

Метки: , , , , ,
Опубликовано: Безопасность cisco | 1 комментарий »