|
Identity Firewall (здесь и далее IFW) является эволюцией технологии фаирволла на сетевых экранах Cisco ASA. Главной особенностью технологии является возможность написания различных правил доступа (напр. ACL) относительно не IP-адресов, а конкретно для определенного пользователя или же группы пользователей. Это может быть очень удобно для сетей, где у пользователей нет фиксированных IP-адресов, т.е. в подавляющем большинстве компаний. Читать продолжение записи » 
Метки: ASA, firewall, identity Вот мы и добрались до главного: а в какой же последовательности все это богатство трансляций обрабатывается? Глобально всю последовательность можно разделить на 3 больших блока: Да-да, именно так. И с до и после. По умолчанию трансляции Twice NAT добавляются в конец первой секции, но можно явно указать, в какое место их ставить (ура!) указав номер правила. Это очень предусмотрительно со стороны циски 🙂 потому что сами правила в I и III секциях (там, где Twice NAT) обрабатываются по порядку, в котором они записаны в конфиге. Как только совпадение будет найдено, заголовок пакета сразу транслируется и новый пакет отправляется по назначению. Мы можем принудительно записать трансляции Twice NAT и в третью секцию, указав ключевое слово
Метки: ASA, ASA 8.3, NAT С object NAT мы познакомились подробно в предыдущих статьях. Пришло время разобраться, что такое TWICE NAT и зачем он вообще нужен. При помощи данной конструкции можно сделать две принципиальные вещи, которые нельзя сделать при помощи object NAT: Рассмотрим формат команды для динамических трансляций NAT пока без указания сети назначения:
Метки: ASA, ASA 8.3, NAT, Twice NAT, новый синтаксис Продолжаем про новый синтаксис НАТа. Начало тут Теперь вторая задача: анонсировать что-либо наружу, т.е. статические трансляции. Для этого также используются объекты. Например, мы хотим анонсировать наружу сервер с адресом 10.100.1.1 (статический NAT) по адресу 20.1.1.102. Для этого мы тоже создаем группы: И применяем правило статического НАТа для группы, которая описывает реальный адрес сервера: Можно также явно указать адрес, в который мы транслируем
Метки: ASA, ASA 8.3, object NAT, static Наверняка многие уже столкнулись с большими изменениями в синтаксисе настройки NAT при переходе от линейки ASA ОС 8.2 к 8.3. Трудно сказать, с чем связано такое резкое изменение подхода, но одно можно сказать уверенно: настройка стала менее понятна и прозрачна. Но это не повод вовсе не использовать версии 8.3, 8.4 и далее (вряд ли разработчики вернут старый синтаксис :)) Предлагаю постепенно, от простого к сложному, освоить новый синтаксис, ибо по нему регулярно возникают вопросы в форуме и необходимость статьи назрела. Даже перезрела, я бы сказал 🙂 Итак, cisco ввела два новых понятия: Object NAT и Twice NAT, заменив ими все предыдущие типы (Regular, Policy, Identity NAT). Для начала познакомимся с понятием object NAT, узнаем про последовательность обработки правил object NAT, потом познакомимся с TWICE NAT и в конце подведем черту: опишем всю последовательность правил NAT в новом синтаксисе. Планирую небольшой цикл статей — штуки 4, дабы не перегружать сразу читателей. Работать будем вот с такой топологией Рассмотрим простейшую задачу: выйти через ASA в интернет.
Метки: ASA, ASA 8.3, NAT, новый синтаксис Ну вот, настало время описать ту засаду, что обещал в прошлой статье, а заодно расскажу еще про одну хитрость, которую обнаружил «методом тыка» на ACS5.2.
Метки: ACS, AD, ASA, SecurID В главе 15 про Advanced Protocol Handling мы познакомились с механизмом манипуляции пакетами MPF. Но эта часть была бы не полной, если не рассказывать про то, что ASA умеет в плане разбора самого протокола. Напомню, что программисты научили ASA понимать массу протоколов. Понимать значит знать внутреннюю структуру, поля, сообщения данного протокола. А значит манипулировать данными 7 уровня, данными самого приложения. Как же это сделать?
Метки: ASA, DPI, SNAF Протоколы, которые мы используем в повседневной жизни, не всегда используют одну сессию для своей работы (когда весь обмен данными происходит по одной сессии 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 и не малых. Поэтому включать инспектирование всех доступных протоколов «на всякий случай» не рекомендую.
Метки: advanced, ASA, inspect С 7 версии ОС у ASA наконец появилась хоть какая-то возможность управлять потоками пакетов. Т.е. появились зачатки QoS. В версии 8.0 эти возможности весьма расширили.
Метки: ASA, MPF, QoS Бесклиентское подключение (только с использованием браузера) — популярная топология. Это удобно, красиво и безопасно для внутренней сети. Но через браузер возможно обеспечить только связь протоколов, которые могут работать через него: HTTP(S), CIFS. Дополнительно можно пробросить и другие приложения (тонкий клиент), но только работающие по ТСР. Для этого используется Java. Вообще говоря, настроить базово SSL VPN на ASA можно 2 командами
При этом для аутентификации будет использоваться локальная база данных пользователей, попадать вы будете в туннельную группу
Метки: ASA, SNAF, SSLVPN, браузер, курс, настройка |
