Что поставить на периметр сети: Cisco маршрутизатор или Cisco ASA?



    Всем привет! Периодически при проектировании компьютерных сетей на базе оборудования Cisco возникает вопрос, что поставить на периметр сети: маршрутизатор или межсетевой экран Adaptive Security Appliance (ASA)? Далеко не всегда можно однозначно ответить на данный вопрос. Хотел бы в очередной раз сделать попытку и провести небольшое сравнение этих двух устройств. Вы заметите, что уже много раз это обсуждалось. Согласен. Но устройства постоянно развиваются: появляются новые модели, добавляется функционал. Поэтому иногда стоит отойти подальше и ещё раз посмотреть со стороны на данный вопрос. Вдруг что-то поменялось?

    Уточнение
    Для строгости отметим, что основное сопоставление будет идти между ASA 5500-X и маршрутизаторами ISR G2 и ISR 4000.

    Все мы знаем, что Cisco ASA является устройством безопасности и обычно его имя упоминается вместе с аббревиатурой МЭ (межсетевой экран). Маршрутизатор же Cisco является в первую очередь маршрутизатором. О, как сказал. Собственно, вот и отличие. Но всё не так просто: Cisco ASA умеет маршрутизировать трафик (даже поддерживает протоколы динамической маршрутизации), а маршрутизатор Cisco может выполнять функции МЭ (поддерживается две технологии – CBAC и ZFW). Чувствую, как в сторону автора полетели фразы: да, капитан очевидность, ты прав. Поэтому предлагаю более пристально взглянуть на эти устройства с целью определения, что в них общего, а что разного.


    Исторически сложилось, что ASA имеет преимущества перед маршрутизатором только в ряде технологий, в первую очередь связанных с безопасностью (классический межсетевой экран и VPN концентратор для подключения удалённых пользователей). Во всём остальном ASA выступает в основном в роли догоняющего. Это обусловлено тем, что ASA позиционируется как средство безопасности, а маршрутизатор Cisco – как универсальный швейцарский нож (на его базе мы можем запустить и функции шифрования, и голосовые функции, и оптимизировать трафик и пр.). Поэтому вопрос выбора устройства возникает только в разрезе вопроса обеспечения сетевой безопасности.

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

    • есть маршрутизация (статическая, динамическая, PBR), а также функция трансляции адресов NAT;
    • можно завести два и более провайдера (поддерживается IP SLA, BGP);
    • присутствуют функции межсетевого экранирования.

    Если необходимо, на обоих устройствах можно поднять VPN (site-to-site и remote-access). Везде есть поддержка Netflow, для получения статистики по трафику. Если нужны функции NG FW (МЭ нового поколения) или NG IPS (система предотвращения вторжений нового поколения) как на ASA, так и на маршрутизаторе мы можем это сделать. Таким образом, в целом оба устройства имеют относительно сходный функционал (ещё раз отмечу, что речь идёт только о технологии маршрутизации трафика и безопасности). Более того, периодически функционал одного из устройств плавно перетекает в другое. Это привносит дополнительные трудности с выбором решения. Например, расширенные возможности SSL VPN всегда были прерогативой ASA. Но со временем многие функции SSL VPN появились и на маршрутизаторе (режим clientless, smart tunnels и пр.). Возможность захвата пакетов на интерфейсах (packet capture) также долгое время поддерживалась только на ASA. Схожая ситуация и с использованием различных конструкций при настройке списков доступа ACL. Речь идёт об объектах (Object Groups), позволяющих группировать IP-адреса/сети, сервисы в сети. Всё это плавно перешло в ОС маршрутизатора. Аналогично ситуация складывается в обратную сторону: на ASA появилась поддержка протокола BGP, маршрутизация трафика на основании политик — Policy Base Routing и пр. Поэтому выбор в пользу одного или другого решения далеко не всегда предопределён. Как обычно дьявол кроется в деталях.

    Так как ASA является более узкопрофильным решением, попробуем провести наше сравнение относительно неё. ASA позиционируется как устройство безопасности, поэтому многие функции безопасности работают уже “из коробки”. По умолчанию в Cisco ASA “завинчены все гайки”, в то время как на маршрутизаторе функции безопасности требуется включать принудительно (настраивать с нуля МЭ, отключать лишние сервисы и пр.). Давайте пройдёмся по основным функциям ASA:

    • Функции трансляции адресов NAT. На ASA присутствуют все возможные вариации (статический и динамический NAT, PAT), в том числе двойной (twice NAT). Есть возможность влиять на порядок применения правил NAT. В этом плане ASA превосходит маршрутизатор.

    • Классический межсетевой экран с глубоким анализом содержимого протоколов, а также функцией обнаружения угроз (сканирования и DoS атак). Как межсетевой экран ASA способна работать в двух режимах: маршрутизируемом и прозрачном (Transparent Firewall). Также ASA может работать в режиме множественных контекстов (виртуальные межсетевые экраны, multiple context) либо в режиме единственного контекста. Основные отличия от маршрутизатора: в ASA базовые функции МЭ включены по умолчанию, МЭ является более функциональным (например, Identity Firewall даёт возможность предоставлять доступ на основании имён пользователей или групп в MS Active Directory), при этом его конфигурирование более интуитивно понятно. Маршрутизатор старается не отставать: обеспечивает работу МЭ также в двух режимах (маршрутизируемом и прозрачном), а вместо контекстов, поддерживает функционал Virtual Routing and Forwarding (VRF). Правда, настраивая Zone-Based Policy Firewall (ZFW) на маршрутизаторе, можно легко запутаться с созданием политик под каждую пару интерфейсов, настройкой классов, списков доступа и их связкой в конфигурации. Нужно также не забыть о правилах self-зоны и взаимодействии ZFW с remote-access VPN (тут появляются virtual template интерфейсы для возможности прикрепления зоны безопасности). В общем, есть где ошибиться развернуться.

    • Межсетевой экран нового поколения (NG FW) Cisco Firepower — безопасность с учетом контекста, контроль использования приложений для пользователей и групп, WEB фильтр с проверкой репутации, ретроспективный анализ файлов и пр. Для запуска сервисов Firepower на ASA требуется наличие SSD диска (новые модели всегда идут со встроенным SSD диском: ASA 5506-X, 5508-X и 5516-X). Сервисы Firepower до недавнего времени не были доступны на маршрутизаторах. Однако теперь их возможно запустить на универсальном блейд-сервере (например, UCS E-Series Servers или Cisco UCS E-Series Network Compute Engines), который может быть установлен непосредственно в маршрутизатор. При этом необходимо учитывать, что получить на базе маршрутизатора относительно бюджетный вариант не получится: потребуется минимум 1921 и блейд-сервер UCS EN120E.
    • Система предотвращения вторжений нового поколения (NG IPS) Cisco Firepower. Как мы помним, раньше функция IPS на ASA была реализована в качестве отдельного модуля, а далее стала доступна в виде виртуального лезвия (а ля виртуальной машины). Но после приобретения компании SourceFire традиционный IPS был отправлен в лету и на его смену пришёл NG IPS Cisco Firepower. С точки зрения требований по железу, они аналогичны решению NG FW. Отметим: на одном устройстве у нас есть возможность запустить одновременно сервисы NG IPS и NG FW.

    • VPN для подключения удалённых работников – на ASA существует несколько видов:
      • AnyConnect VPN Client — туннели SSL или IPSec IKEv2 с использованием AnyConnect Secure Mobility Client. Поддерживается большинство современных платформ ПК и мобильных устройств. Опционально интегрируется с сервисами и услугами Cloud Web Security, Host Scan, 802.1x.
      • Бесклиентский (Clientless) SSL VPN – доступ к приложениям осуществляется через web-портал, или обеспечивается проброс портов через тонкий клиент (Java-аплеты/Active-X скрипт) и SSL VPN Smart Tunnels.
      • Remote Access IPsec VPN и L2TP over IPsec (IKEv1) – в качестве клиента может выступать любой IPSec или L2TP-клиент (например, Microsoft Windows).
      • Easy VPN — туннели IPSec IKEv1. Раньше данное решение активно использовалось для подключения удалённых пользователей через Cisco VPN Client. Сейчас Cisco VPN Client умер, и остался только режим, при котором в качестве удалённого клиента выступает аппаратное устройство.

      Маршрутизатор уступает по функциональности в плане работы с AnyConnect VPN Client и Clientless SSL VPN. Например, не поддерживается модуль Host Scan — оценка состоянии подключаемого клиента (версия ОС, антивирус, клиентский МЭ и пр.). Нет динамических политик доступа (Dynamic Access Policies — DAP). DAP позволяют нам применять различные политики доступа (например, предоставить доступ только к определённым ресурсам) на основании авторизационных данных или данных, полученных при оценке состоянии подключаемого клиента. Не поддерживаются Java-аплеты/Active-X скрипты в режиме Clientless SSL VPN и пр. Отметим, что на маршрутизаторах Cisco 4000 на данный момент SSL VPN вообще не представлен. Правда есть поддержка AnyConnect IKEv2.

    • Отказоустойчивость и кластеризация. Резервирование ASA обеспечивается за счёт функций отказоустойчивости (failover) или кластеризации (clustering).

      В режиме отказоустойчивости два устройства объединяются в одно логическое. Данные с одного устройства реплицируются на второе для обеспечения сохранения состояния всех сессии при отказе одного из них. Доступны два режима работы: active/standby (с единственным контекстом) и active/active (в режиме множественных контекстов). Режим отказоустойчивости удобен тем, что после объединения двух устройств, необходимо настраивать только одно устройство — активное.

      Второй режим – кластеризация (clustering), позволяет объединить в одно логическое устройство до 16 устройств ASA. Необходимо оговориться, что в кластер из 16 устройств мы можем объединить на данный момент только ASA 5585-X. Для остальных моделей в кластер объединяются только два устройства. Кластеризация обеспечивает резервирование устройств, единую точку управления (все устройства объединяются в одно логическое) и повышение производительности (речь идёт о том, что мы получаем одно виртуальное устройство с бОльшей производительностью нежели одно физическое устройство).

      А что с маршрутизаторами? Там нет функций failover и clustering. Отказоустойчивость обеспечивается соответствующей настройкой каждого протокола и функции. Для маршрутизации трафика настройки будут свои, для МЭ свои, а для VPN – свои. Failover на ASA в этом плане более удобен: объединил устройства и далее все настроил из одной консоли, как будто у нас оно одно. С маршрутизатором так не получится.

    • Маршрутизация – статическая, динамическая (EIGRP, OSPF, BGP), маршрутизация трафика на основании политик (PBR), маршрутизация multicast-трафика (PIM). В этом плане ASA сделала большой шаг вперёд. Не так давно BGP и PBR были прерогативой только маршрутизаторов. Но в плане маршрутизации есть определённые «но». Во-первых, не все работает так как надо (периодически проскакивают небольшие глюки), плюс по каждому протолку (EIGRP/OSPF/BGP) присутствуют ограничения и нюансы. Лучше лишний раз заглянуть в документацию. Например, ASA при работе с BGP не рассчитана на обработку полной таблицы маршрутизации интернет (full view). Во-вторых, на ASA нет логических туннельных интерфейсов GRE/VTI. А значит, будут трудности с реализацией туннелей через публичные сети. Безусловно, маршрутизатор в данном аспекте существенно превосходит ASA по функциональности. Кто бы, собственно, сомневался. Стоит также отметить, что маршрутизация трафика на ASA в некоторых аспектах отличается от аналогичного процесса на маршрутизаторе. В чем именно, рассмотрим дальше.

    • Site-to-site VPN. ASA поддерживает только чистый IPSec. Можно его настроить совместно с протоколом L2TP. Но больших плюсов это нам не даёт. Так как нет GRE-интерфейсов, связку IPSec+GRE мы тоже не сможем реализовать. В этом плане маршрутизатор существенно функциональнее: IPSec+GRE, VTI, DMVPN, GET VPN, FlexVPN и пр. Отдельный вопрос – обеспечение отказоустойчивого подключения по VPN. Так как мы имеем чистый IPSec, в нашем распоряжении есть только возможность указывать несколько пиров в крипто-карте и использовать связку OSPF+IPSec. При указании нескольких пиров в крипто-карте на ASA мы сразу сталкиваемся с тем, что там нет preemption (т.е. после восстановления основного пира, переключение VPN-соединения на него не происходит). А значит, не всегда можно чётко определить, через каких провайдеров сейчас работает наш VPN (усугубляется эта ситуация, когда у нас по несколько провайдеров с каждой стороны). Конечно, эту проблему можно обойти, но не всегда элегантным путём (например, принудительно разорвав IPSec-соединение с помощью Embedded Event Manager). Работа связки OSPF+IPSec тоже имеет свою специфику: с обеих сторон туннеля должны стоять только устройства ASA. Сделать связку ASA-маршрутизатор не получится. В дополнение, с сайта вендора пропал документ, описывающий работу в таком режиме. Это наталкивает на определённые мысли. Эх, как же не хватает GRE-туннелей на ASA…

    • Качество обслуживания (QoS). Настройки ASA в этом плане достаточно ограничены. Фактически мы можем сделать несколько очередей и к каждой очереди применить или свойство приоритетной, или назначить ограничитель (policer). Пакеты в приоритетной очереди будут отправляться устройством в сеть в первую очередь. Ограничитель (policer) позволяет для очереди задать максимальную скорость, с которой будут передаваться пакеты из неё. В плане QoS маршрутизатор существеннее функциональнее.

    • Управление. Командная строка ASA отличается от командной строки маршрутизатора. Различие не фатальное, но есть. Отличается особенно конфигурация некоторых функций, например, NAT.

      У ASA есть очень неплохой WEB-интерфейс – Adaptive Security Device Manager (ASDM). Он полнофункциональный и ряд функций рекомендуется настраивать именно через него (например, SSL VPN), так как есть достаточно удобные помощники (wizard). Как мы знаем, WEB-интерфейс маршрутизаторов (Cisco Configuration Professional) оставляет желать лучшего.

      На ASA не так давно появилась поддержка Embedded Event Manager, что позволяет получить частичную автоматизацию. На маршрутизаторе этот функционал присутствует достаточно давно.


    На этом основная функциональность ASA практически исчерпывается. Хотел бы ещё отметить на ASA достаточно удобную утилиту – packet-tracer. Она позволяет провести первичную диагностику прохождения пакета через устройство. Packet-tracer выводит информацию по каждой стадии обработки пакета внутри устройства. Предполагаю, что отсутствие packet-tracer на маршрутизаторе обусловлено тем, что маршрутизатор существенно функциональнее.


    Коснёмся чуточку архитектурных особенностей программно-аппаратной частей. Сразу заметим, что программный код ASA и маршрутизатора абсолютно разный. Поэтому некоторые процессы реализованы по-разному.

    Например, маршрутизация. На ASA нет привычного для маршрутизаторов Cisco Express Forwarding (CEF). Используется своя собственная логика: маршрут определяется для сессии единожды при её установлении (чем-то напоминает fast-switching). Можно сказать, что маршрутизатор оперирует пакетами, а ASA – сессиями. На маршрутизацию в ASA может влиять NAT (правильнее сказать: NAT в ряде случаев определяет, куда будут отправлены пакеты той или иной сессии). На маршрутизаторах такого нет, всем «рулит» таблица маршрутизации или PBR. При переключении маршрутизации с одного интерфейса на другой на ASA далеко не всегда сессия будет также переброшена (она может остаться работать на старом интерфейсе). ASA для каждой сессии запоминает не только исходящий интерфейс (т.е. куда слать), но и входящий (откуда изначально пришли пакеты). Эта особенность работы наиболее ярко проявляется, когда у нас есть несколько провайдеров (подключенных через статическую маршрутизацию) и на них есть какие-то публикации. В случае ASA ответные пакеты всегда пойдут через того провайдера, через которого пришёл запрос. Т.е. все публикации будут рабочими. В случае маршрутизатора ответные пакеты будут идти через провайдера по умолчанию. Т.е. только на одном провайдере будут работать публикации (такое поведение можно обойти с помощью плясок с бубном: VRF+BGP).

    Давайте теперь посмотрим на производительность. Конечно, сравнивать устройства по данному параметру очень непросто, так как методика замеров для каждого типа устройств может отличаться, да и департамент маркетинга не дремлет. Плюс производительность зависит от сервисов, которые запущены на устройстве. Но всё-таки попробуем отметить несколько моментов. Раньше (для старых моделей ISR и ISR G2) по соотношению цена/производительность маршрутизаторы уступали (как по цифрам, так и из опыта). Например, при сходной стоимости ISR G2 2921-SEC и ASA5512-X первое устройство обеспечивало 50 Мбит/с (именно на эту цифру рекомендует ориентироваться вендор), а второе в худшем случае 100 Мбит/с (Application Control, пакеты HTTP 440 байт). Может быть, не совсем точное сравнение, но для грубой оценки, надеюсь, подойдёт. За одни и те же деньги чаще всего ASA нам давала бОльшую производительность. Но с появлением маршрутизаторов 4000 картина поменялась. Теперь нужно смотреть каждый отдельный случай. Связано это с тем, что на маршрутизаторах 4000 производительность не так сильно деградирует при включении сервисов.

    Заключение

    Пора подвести итоги и ответить на поставленный в заголовке статьи вопрос. Существуют рекомендации вендора на это счёт, оформленные в виде различных дизайнов в рамках архитектуры Cisco SAFE. Но далеко не всегда мы строим какие-то сложные сети, где присутствуют все виды устройств, выполняющие наиболее подходящие для них функции. Например, в качестве устройства МЭ мы ставим ASA с сервисами Firepower, а для организации подключения к WAN-каналам – маршрутизаторы. Часто бывают ситуации, когда нужно поставить что-то одно (причина может быть самая банальная — бюджет). И вот тут нам и приходится задумывать, что же выбрать.

    Случай 1. Относительно небольшая компания с одним офисом. Нужно обеспечить защищённый доступ в Интернет (используется один или два провайдера).


    В данной ситуации решение ASA может выглядеть более интересным по следующим причинам:
    • функционал ASA достаточен для реализации поставленной задачи;
    • на базе ASA можно запустить сервисы Firepower для получения функций NG FW и NG IPS (совокупная стоимость будет ниже, чем в случае использования связки маршрутизатор+модуль+сервисы Firepower);
    • если необходимо обеспечить подключение удалённых пользователей к корпоративной сети, ASA предоставит наиболее широкие возможности;
    • в ряде случаев мы получим бОльшую производительность устройства за те же деньги.


    Случай 2. Есть центральный и удалённые офис(ы). Что поставить в удалённый офис?

    Думаю, многим уже понятно, что site-to-site VPN не самая сильная сторона ASA. Если у нас много офисов, несколько провайдеров и нужен full-mesh (прямая связность всех офисов), лучше для этой задачи использовать маршрутизаторы. Одна только технология DMVPN позволит снять бОльшую часть головной боли. В центральном офисе в этом случае также должен стоять маршрутизатор.

    Если у нас везде один провайдер и офисов не так и много, ASA вполне подойдёт. Более того, решение может получиться дешевле аналогичного на базе маршрутизаторов. Но не стоит забывать, что сегодня провайдер один, а завтра два, да и компания может чуточку подрасти. Безусловно, на ASA в удалённом офисе можно настроить резервный VPN до центрального офиса, используя в центре двух провайдеров. Просто слишком много «но», которые порядком могут подпортить репутацию такого решения. Их, конечно, вендор старается убрать, однако пока эти «но» приходится принимать во внимание.

    Подытожим: ASA прекрасно подходит для таких задач, как межсетевое экранирование и remote-access VPN. Если мы можем себе позволить поставить это устройство для решения только этих вопросов, стоит так и сделать. Если же необходимо в одной «коробке» получить смесь функций, возможно, стоит присмотреться к маршрутизатору.

    Если у Вас есть свои мысли по поводу вопроса в заголовке статьи, добро пожаловать в комментарии.

    UPD:
    В статье указывается, что в маршрутизаторах нет аналогичной функции packet-tracer как на ASA. Это утверждение не совсем корректно. В IOS XE присутствует схожая функциональность — Datapath Packet Trace.
    CBS 51,62
    Компания
    Поделиться публикацией
    Комментарии 57
    • 0
      Умеет ли современный софт маршрутизаторов statefull FW?
      Без этой опции выставлять сети в Интернет с UDP-трафиком весьма опасно.

      P.S. Зачем Вы поместили фотографию маршрутизатора в центр текста про ASA ?
      • 0
        Безусловно, МЭ на базе маршрутизатора инспектирует сессии. Причём инспекции есть не только для TCP/UDP, а для более высокоуровневых протоколов, например, HTTP/SIP/пр. Также на маршрутизаторах поддерживается stateful failover для МЭ. Т.е. если у нас два маршрутизатора и один из них откажет, сессии не разорвутся и продолжат обрабатываться МЭ на втором.
      • 0
        Я сейчас глупость спрошу наверное, но спрошу — как обстоят дела с лицензированием ASA по количеству пользователей на inside интерфейсе? На старых железяках была градация 10/50/хх. Как сейчас с этим?
        • +1
          Такое лицензирование было только для ASA 5505. На современных устройствах ASA 5500-Х (в частности ASA 5506-X) данной схемы больше нет.
        • +2
          В небольшой сети ISR не нужен — он на порядок сложнее ASA в настройке, а DMVPN и прочие UC востребованы скорее в филиалах крупных компаний.
          Грубо говоря: для грамотной конфигурации ISR нужен специалист уровня CCNP (свой или на подряде), а настройка через ASDM почти не отличается от домашнего раутера и с ней справится обычный сисадмин читавший СДСМ.
          • 0
            для грамотной конфигурации ISR нужен специалист уровня CCNP

            А про какие задачи идет речь? Много-много лет назад я себе домой поставил 1721-й роутер, еще готовясь к CCNA. Помню, был SDM/CCP, где при желании в гуе все настраивается визардами, но я был за консоль.
            А аса… Я до сих пор не могу им простить отказ от синтаксиса NAT в <=8.2. Было ужасно, все привыкли, и вдруг стало совсем по-другому и еще ужаснее. Автоматическая миграция формально есть, но никогда не работает, надо руками.
            • 0
              А про какие задачи идет речь?

              Сразу оговорюсь, я не настоящий сварщик. Под настройкой имел ввиду IPSec-туннель с NAT для подключения к клиенту/подрядчику, обновления клиента и настройка портала для AnyConnect и т.д.
              Кстати, SSL VPN на 1921 работает без аппаратного ускорения и один пользователь может положить железку простым копированием файла по SMB. Пришлось мучаться с FlexVPN, который сам не обновляется и не подтягивает профиль при подключении.
              Помню, был SDM/CCP, где при желании в гуе все настраивается визардами, но я был за консоль.

              Я не понял логики CCP и тоже всё делаю через консоль, а вот на ASA ей пользовался всего два раза — когда активировал люцензию на шифрование и для TAC.
              • 0
                Клиентский VPN — да, аса лучше, только и она не сахар. Anyconnect по цене/возможностям ни разу не впечатляет.
                • +1
                  Напишите про альтернативы.
                  У меня сложилось впечатление, что классический VPN у них вне конкуренции — им пользуются все ([1], [2], [3]), стоит копейки и работает на куче платформ (в NetworkManager даже сделали свою реализацию). Не хватает только нормального запуска перед логином, но это похоже есть только в DirectAccess.
                  Про clientless ничего не знаю, его фичи пока не нужны и цена кусается.
                  • +1
                    F5 весьма шикарен.
                    Clientless — тестировали какое-то решение, дающее клиенту SSH клиента на Java и логирующее всё происходящее. Вроде там и RDP картинку умело писать. Бесценно для всяких криворуких системных интеграторов, любящих скрывать свои косяки.
                    Правда, лично я клиентским VPNом как раз не занимаюсь...
                    • 0
                      Не CyberArk случаем?
                      Про F5 слышал много хорошего, но вроде это махровый ентерпрайз с ценами от десятков килобаксов.
                      • 0
                        Не CyberArk. Чей — не помню.
                  • 0
                    Увы и ах — лучше AnyConnect ничего, похоже, не сделали:(
            • +1
              практика показывает, что попытки использовать ASA как маршрутизатор часто заканчиваются не очень хорошо. Действительно, в неё добавили очень много фич, которые делают её похожей на маршрутизатор — вот вам BGP, вот вам SLA, вот даже EEM. Но дьявол, как обычно, кроется в деталях. ASA как была, так и остаётся очень узкоспециализированным устройством безопасности, в соответствии с чем устроена её логика работы, поэтому многие функции имеют, скажем так, «особенности». Разумеется, их можно учесть, заранее и очень аккуратно разрисовав дизайн, все потоки трафика и надеясь, что к моменту реализации сеть будет именно в том состоянии, в котором вы её нарисовали. Потому что стоит какому-то серверу переехать в другую сеть и можно получить асимметричную маршрутизацию или ещё какую бяку и ой! Ура, костыли! Если роутер, будучи устройством универсальным, может простить предположения этапа дизайна, оказавшиеся неверными, то ASA — скорее всего нет. Вдобавок, заимствованные из маршрутизатора функции заимствованы далеко не полностью. То есть, увидев в описании ASA, что в ней есть EEM, не думайте, что этот тот же EEM, что в маршрутизаторах. Или Netflow, который вроде бы как Netflow, только не каждый neflow коллектор его понимает.
              И ещё, хочется развенчать распространённое заблуждение, что ASA проще в настройке, чем IOS-маршрутизатор, ведь у неё есть отличный GUI под названием ASDM. Да, GUI есть, вот только логика работы не так прямолинейна. Тот же NAT, участвующий в маршрутизации.
              В качестве заключения: ASA — отличная железка, если вы собираетесь использовать её по назначению. Если вам нужна гибкость, лучше остановиться на роутере.
              • 0
                эт с какой версии софта ASA стала поддерживать PBR?
                • 0
                  Поддержка PBR появилась в версии 9.4(1). Смотреть новый функционал относительно версий удобно здесь.
                • +1
                  А еще можно дополнить ", а для организации подключения к WAN-каналам – маршрутизаторы",
                  потому-что совместимых модулей расширения для ISR G2 огромное количество на вкус, цвет и все потребности:
                  www.cisco.com/c/en/us/products/routers/3900-series-integrated-services-routers-isr/relevant-interfaces-and-modules.html (далеко не все подходят для серии 4400),
                  а для ASA совсем 3 единицы: www.cisco.com/c/en/us/products/interfaces-modules/security-modules-security-appliances/models-listing.html
                  • 0
                    Большинство моделей ASA идут с портами GE и дополнительно может быть SFP. У ASA 5585-Х возможны ещё порты SFP+. В принципе для большинства подключений в настоящее время этого вполне достаточно, так как xDSL и пр. встречается существенно реже, чем раньше. Хотя, конечно же, маршрутизаторы дают нам в этом плане большую гибкость.
                    Модули для ASA по приведённой ссылке уже не продаются: AIP-SSM был заменён на NG IPS Firepower, CSC-SSM — сначала на ASA CX, потом на NG FW Firepower.

                  • +1
                    У ASA есть очень неплохой WEB-интерфейс – Adaptive Security Device Manager (ASDM).
                    Это вы его похвалили. Тяжелый и тормозной апплет на java. Жрет память и проц на компьютере, где запущен просто безбожно, даже болтаясь в бэкграунде. Постоянные проблемы с совместимостью версии софта ASA- версии ASDM- java на компьютере админа. Может конечно это все только на винде, но достает. У меня еще постоянно отваливается от 5505, которая лежит за 40 мс.Может я не прав, но есть подозрение что плохо работает при больших пингах (софт и ASDM там многократно меняли, но результат все тот же "temporarily unavailable".
                    • 0
                      Вы правы, запустить ASDM не всегда просто. Причём эта болезнь присутствует достаточно давно. Но он на ASA есть и практически полнофункциональный. На маршрутизаторе фактически мы имеем только командную строку.
                      • 0
                        У меня на старой ASA 5520 когда стоял ASDM 6.4.1 тоже была такая же ситуация, тормоза, открывался только джавой 1.6.
                        Сейчас обновил софт на 8.4.7 после известных событий, и ASDM залил другой, посвежее 7.5.2, так сейчас работая через джаву 1.8 — просто ракета )
                        • 0
                          Поставил java 1.8 (чует мое сердце сейчас средства разработки полетят). Работает вроде и правда шустрее. Но вот 500 метров ОЗУ и 25% проца от javaw — это как-то перебор :-)
                      • 0
                        И говоря про ASA неплохо бы рассказать про проблемы с криптографией. K9, я так понимаю, же просто не купишь. А учитывая что софт теперь требует активации через Инет, то как это все это корректно организовывать и проводить через бухгалтерию вопрос. У меня на каждой работе предложение написать письмо в ФСБ с просьбой разрешить купить вызывало истерику у начальство и жесткое требование "делай как хочешь, но мы к этому не будем иметь никакого отношения"
                        • 0
                          Вопрос ввоза криптографии на территорию РФ и для маршрутизатора, и для ASA одинаков. Если мы хотим ввезти оборудование со стойким шифрованием, мы должны получать на это разрешение ФСБ. Другое дело, момент связанный с "получением" криптографии на месте. И тут, кстати, ASA более удобна. Гипотетически, можно купить устройство с индексом K8 и, зарегистрировавшись на сайте вендора, бесплатно получить лицензию на стойкое шифрование. Правда, вопрос легальности "получения" криптографии на месте не всегда имеет точный ответ.
                          • 0
                            На маршрутизатор можно "просто залить" нужный ios. На ASA бесплатную лицензию-то получить можно, но (насколько я помню и могу врать) для того же Anyconnect она не подходила (и честно скажу, что я сломался в процессе ее получения). Залить "нормальный" образ на АСА тоже можно, но теперь его надо активировать. А для этого надо покупать соответствующие лицензии и получать на баланс купленную западную криптографию без разрешения. В общем все это не для "простого пользователя".
                            • +1
                              Бесплатная лицензия включает криптографию, которая в последствии будет использоваться для Anyconnect. Но помимо бесплатной лицензии для Anyconnect нужна ещё и лицензия на Anyconnect. Anyconnect для ASA всегда лицензировался отдельно, а сейчас лицензия на Anyconnect вообще покупается не на конкретную железку, а на количество пользователей.
                              • +1
                                На маршрутизатор можно «просто залить» нужный ios.

                                Боюсь, не очень просто, так как требуется, как минимум лицензия на функционал безопасности (SEC), который включает в том числе возможность настройки защищённых VPN соединений. Причём, если изначально куплен был бандл с функциями безопасности с лицензией SEC-NPE (т.е. без разрешения ФСБ), просто заменить IOS и получить шифрование опять же не получится. Нужно будет всё равно покупать лицензию SEC, так как SEC-NPE для полноценного IOS не подойдёт.
                                • 0
                                  Хм… Вот стоит… Каши не просит… Покупалась K8…
                                  sh hardware
                                  Cisco IOS Software, C1900 Software (C1900-UNIVERSALK9-M), Version 15.1(4)M7, RELEASE SOFTWARE (fc2)
                                  System image file is "flash:c1900-universalk9-mz.SPA.151-4.M7.bin"
                                  Cisco CISCO1921/K9 (revision 1.0) with 491520K/32768K bytes of memory.
                                  Technology Package License Information for Module:'c1900'
                                  Technology Technology-package Technology-package
                                  Current Type Next reboot
                                  ipbase ipbasek9 Permanent ipbasek9
                                  security securityk9 RightToUse securityk9
                                  data datak9 RightToUse datak9
                                  • 0
                                    RightToUse — это ваше обещание купить лицензию, вроде триалки (сами зачем-то написали про бухгалтерию).
                                    До её появления был ад и израиль с ФСБ, а сейчас действительно стало проще: меняем IOS, активируем RTU, докупаем и активируем SEC. Вот только в бандле выходило дешевле.

                                    • 0
                                      Я правильно понимаю, что покупка sec для router или secplus для ASA внимания регулирующих органов не привлекает и никаких доп.действий не требует? (то что бандл будет дешевле это понятно).
                                      • 0
                                        SEC точно продают без привлечения ФСБ, а про легальную сторону лучше спросить у alukatsky .
                                        • 0
                                          Небольшое уточнение, лицензия Security Plus для ASA на криптографию никакого влияния не оказывает.
                                          • 0
                                            Любое пользовательское шифрование, что на ASA, что на ISR (а также у любого другого зарубежного вендора) требует получения разрешения ФСБ на ввоз такого оборудования.

                                            Вот тут я разъяснял процедуру, связанную с ввозом — https://habrahabr.ru/company/cisco/blog/234491/
                                            • 0
                                              Так мы как раз обсуждаем схему покупки и ввоза оборудования с ослабленным шифрованием и последующей покупки и установки ПО с усиленным шифрованием. Коллеги выше утверждают что это правильный путь. Если нет, то тогда уж лучше ПО с усиленным шифрованием не покупать вообще, чтобы не светиться :-)
                                              PS
                                              Статью прочитал — про покупку с последующим скачиванием ПО с усиленным шифрованием там вроде ничего нет. Хотя по логике законодателей это вполне тянет на "физическое перемещение ПО через границу по оптоволоконным каналам связи"
                                              • 0
                                                Там есть раздел «А если я ввез оборудование без шифрования, а потом обновил его через Интернет и получилось средство шифрования?» Но логика верная :-)
                                                • 0
                                                  Был не внимателен. Нашел. И сразу вопрос
                                                  "Они должны понимать, что у регулирующих и проверяющих органов могут быть вопросы к организации, которая никогда не приобретала криптографические продукты, ввезенные для нее по заключению ЦЛСЗ, но использует их в своей деятельности." Какие вопросы? Даже если мы просто активировали 3DES на ASA k8 (как выше рекомендовали) — они все равно могут возникнуть? Выходит в целом куда не кинь — всюду клин и "за вами все равно придут"?
                                                  • 0
                                                    Вы не можете просто взять и активировать 3DES/AES. Это в серой зоне законодательства. С точки зрения регулятора вы меняете криптографические характеристики оборудования, на что у вас должно быть разрешение. Прямого разрешения на изменение характеристик оборудования нет. Разрешения на скачивание тоже нет. Есть разрешение на ввоз оборудования с определенными характеристиками. Это единственное существующая форма разрешения сегодня. И дабы избежать любых рисков мы рекомендуем именно ее.
                                                    • 0
                                                      И какие последствия согласно законодательству?
                                                      "Прямого разрешения на изменение характеристик оборудования нет." А прямой запрет есть?
                                                      У меня вообще половина оборудования на usedcisco куплено — в накладных ни слова про IOS. Это будет считаться криминалом?
                                                      • 0
                                                        А вот тут мы вступаем на скользкую дорожку домыслов и допущений, так как правоприменительная практика почти отсутствует. Ни запрета, ни разрешения на уровне законодательства нет. Как я написал, серая зона. Поэтому, если ФСБ спросит, то трактовать она будет по своему. А их трактовку я привел. Если компания лицензиат ФСБ, то у нее могут быть проблемы, так как легальный ввоз используемых СКЗИ — это одно из лицензионных условий. Если у компании нет лицензии ФСБ, то это вообще отдельная тема обсуждения — там и 171-я статья УК может светить и до нелегального «ввоза» дело может и вовсе не дойти. Также возможна инициация расследования по факту незаконного ввоза или контрабанды, в рамках которых может быть изъятие «незаконно ввезенного» оборудования.

                                                        Но все это теоретические рассуждения, так как ФСБ не часто проводит проверки законности ввоза и использования СКЗИ. Поэтому до суда дела доходят практически никогда, а поэтому говорить о криминале можно только после решения суда.

                                                        Учитывая столь непонятную и местами рискованную позицию, мы и рекомендуем получать разрешение ФСБ на ввоз, тем более, что при правильном заполнении документов, запретов почти не бывает.
                                • 0
                                  Единственная проблема с шифрованием на ASA — это необходимость подключать консоль для ввода ключа 3DES-AES, так как без него ни по SSH, ни через ASDM она подключиться не даст с 9.4 и выше.
                                • 0
                                  Ещё стоит упомянуть о том, что на ASA нет поддержки mpls, в отличии от ISR.
                                  • 0
                                    Никто не упомянул про очень интересный момент.
                                    ASA роутит ответный трафик в рамках установленной сессии всегда не по таблице маршрутизации — а через интерфейс откуда пришел запрос. Т.о. аса из коробки позволяет опубликовать в интернет некий сервис (web и т.д.) сразу через N-е число провайдеров. И ответ всегда будет уходить через того провайдера, через которого пришел запрос. Вне зависимости от того, на какого провайдера указывает маршрут по умолчанию.
                                    На маршрутизаторе подобное поведение можно организовать путем суровых костылей и с существенными ограничениями.
                                    При этом фича данная очень востребована.
                                    Т.о. для реализации отказоустойчивости публикуемых сервисов ASA сильно интереснее маршрутизатора. Если на объекте не используется BGP с провайдерами.
                                    А вообще, судя по анонсу новых фаерволов 4100 на новой ОС firepower — морально устаревшую ASA таки собираются похоронить.
                                    • +2
                                      Никто не упомянул про очень интересный момент.
                                      ASA роутит ответный трафик в рамках установленной сессии всегда не по таблице маршрутизации — а через интерфейс откуда пришел запрос.

                                      Pave1, в статье об этом написано. Также замечу, что само по себе утверждение не совсем верное. ASA делает маршрутизацию на основе NAT не всегда, только в ряде случаев (когда мы имеем destination NAT). При этом обязательно проверяя наличие маршрута в таблице маршрутизации. Если обратного маршрута нет, возвратные пакеты будут отброшены.
                                      А вообще, судя по анонсу новых фаерволов 4100 на новой ОС firepower — морально устаревшую ASA таки собираются похоронить.

                                      Хорошее замечание. Cisco сейчас выпустила новый код (Firepower Threat Defense — FTD), который совмещает в себе код ASA и Firepower (до этого сервисы Firepower на ASA запускались в виде отдельного образа). Причём, как говорит вендор, FTD можно будет запускать, как на ASA 5500-X, так и на новых платформах — FP 4100/9300. И наоборот — код ASA можно запустить на FP 4100/9300. Аппаратные платформы меняются. Но сам по себе код ASA никуда не девается. Также стоит заметить, что цена FP 4100/9300 достаточна большая. Поэтому для небольших инсталляций они не очень подходят.
                                      • 0
                                        Не совсем согласен. Как минимум моя практика это опровергает. Как я понимию, маршрутизация обратного трафика в рамках установленной сессии происходит вообще не на основе таблицы маршрутизации или тем более NAT. А на основе записи сессии stateful firewall, в которой явно указанно с какого интерфейса запрос пришел (сессия была инициирована). А таблица маршрутизации как таковая используется только в момент создания сессии.
                                        А проверка обратного Маршрута происходит только если включена на интерфейсе функия anti-spoofing.
                                        Возможно я в чем то ошибаюсь. Но явного детального описания процесса я не нашел. А практические изыскания говорят именно о таком поведении.
                                        • +2
                                          Вы правильно отметили тот факт, что для ASA стоит разделять момент установления соединения и передачу пакетов после того, как соединение уже присутствует. В случае установления сессии на маршрутизацию влияют NAT (Dest IP), PBR и таблица маршрутизации. ASA обязательно запоминает интерфейс, откуда пришли пакеты. Но ответные пакеты через этот интерфейс пойдут только в том случае, если на ASA есть маршрут через этот интерфейс (пусть даже с худшим AD). Также стоит учитывать, что если таблица маршрутизации поменяется (т.е. пакеты должны теперь уходить через другой интерфейс) в момент, когда сессия уже установлена, текущая сессия прервётся. Этого можно избежать, если на интерфейсах будет настроен Traffic Zones.
                                          Вы можете у себя легко всё это проверить. Просто уберите из конфигурации с одного из внешних интересов маршрут по умолчанию и попробуйте подключиться к опубликованным через него ресурсам.
                                          Думаю, данная презентация внесёт больше ясности в вопрос маршрутизации на ASA.
                                          • 0
                                            За ссылку на презентацию отдельное спасибо. Про нюанс с неактивным маршрутом и SLA трэкингом не знал.
                                      • 0
                                        буквально вчера-сегодня имел опыт настройки ASA с нуля, и могу сказать обратное. ответные tcp-пакеты идут вполне себе в соответствии с таблицей маршрутизации (привет, ассиметричный роутинг), а вместе с ним и все правила фильтрации
                                      • 0
                                        У нас ASA сгорела из-за известного брака (https://habrahabr.ru/post/216287/) а гарантия на неё оказывается 3 месяца!
                                        Плюс ещё пара критических уязвимостей обнаружена за прошлый месяц.
                                        CVE–2016–1287
                                        https://habrahabr.ru/company/pt/blog/277575/
                                        В общем мы решили перейти на Mikrotik.
                                        • +2
                                          А микротики — это основа надежности что ли? Ихние аппаратные реализации вообще из шлака делают. А уязвимости находят редко не потому что их нет. А потому, что никому не интересно. Т.к. красть у их владельцев особе нечего как правило.
                                          • 0
                                            Ну я не слыхал чтобы они массово горели. И гарантия подольше чем 3 месяца. И стоят дешевле.
                                          • 0
                                            Разве у Mikrotik есть Security appliance?
                                            Вроде все их проводные железки — или роутеры, или коммутаторы, которые на деле больше роутеры.
                                            • 0
                                              С задачей файерволла отлично справляется.
                                              • 0
                                                Дык любой Линукс с этой задачей отлично справиться :-) (не холивара ради). Все-таки ASA это больше чем только firewall. Особенно с "обвесами".
                                                • 0
                                                  RouterOS, которая в микротике, это по сути и есть линукс.
                                          • –1
                                            После Juniper SRX, ASA — это убогое поделие.
                                            vrf не умеет (контексты страшны как моя жизнь), виртуальные интерфейсы не умеет. имеет кучу ограничений, по сравнению с которым ограничения кластера из SRX кажутся детским лепетом. Я уж молчу про аболютно уродский failover, когда доступа к резервной ноде нет как класса (у кластера SRX хотя бы отображаются интерфейсы обеих нод).
                                            даже по сравнению с ISR G2 ASA как-то не впечатляет от слова совсем (хотя стои дёшево, согласен).
                                            • 0
                                              После Juniper SRX, ASA — это убогое поделие

                                              Данных вендоров сравнивают достаточно давно. И обычно приходят к тому, что у каждого из них есть свои плюсы и минусы. Мне кажется, не стоит быть на столько категоричным. Кому-то нравится командная строка Cisco, кому-то Juniper. Кто-то считает, что ASA работает более стабильно. При этом Juniper более функционален в плане маршрутизации. И так далее. Вряд ли, можно однозначно сказать, что один из них из них намного лучше другого. Более того, многое зависит ещё и от того, какую задачу мы решаем тем или иным устройством.
                                              когда доступа к резервной ноде нет как класса (у кластера SRX хотя бы отображаются интерфейсы обеих нод)

                                              Если у вас есть две ASA, собранные в Failover, вы можете подключить как к основной (active), так и к резервной (standby). Также вы сможет посмотреть статусы интерфейсов на обоих устройствах.
                                              контексты страшны как моя жизнь
                                              аболютно уродский failover

                                              Вы не могли бы более подробно указать, что именно в данном функционале Вам не нравится?
                                              • 0
                                                Если у вас есть две ASA, собранные в Failover, вы можете подключить как к основной (active), так и к резервной (standby). Также вы сможет посмотреть статусы интерфейсов на обоих устройствах.

                                                Конфигурация standby-интерфейсов автоматом берется как копия active-интерфейсов. В отличие от Juniper, где reth-группу можно делать, а можно и нет. Статусы устройств снимаются одним snmp-запросом на активную ноду, нет нужды делать failover и переключаться на другую ноду.
                                                Вы не могли бы более подробно указать, что именно в данном функционале Вам не нравится?

                                                Про failover я уже сказал (кстати — ISSU не поддерживается на ASA, емнип?). Контексты настраиваются гораздо менее интуитивно, чем куча видов routing instances на Juniper.

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

                                            Самое читаемое