Ну да, видимо нужны консольные сапликанты…
ISE ещё умеет аутентифицировать по MAC-адресу — MAC Authentication Bypass (MAB). Это подойдёт для принтеров, камер видеонаблюдения и т.д.
Если вернуться к FirePOWER, тут уже такой момент. Коль нет GUI, вероятно и гранулярный контроль Web-приложений на FirePOWER для таких устройств не нужен. Достаточно разрешить доступ к определённым ресурсам (хоть по IP-адресам).
Для этой статьи trustsec метку (SGT) я использую только чтобы показать, что в консоли FirePOWER (FMC) появится соответствющий атрибут. То есть, что ISE передаёт на FirePOWER метку. Аутентификация происходит на ISE в не зависимости от использования trustsec.
Механизм таков: Коммутатор не пускает на своём порту никакой трафик от клиента, кроме трафика 802.1X, пока ISE не сообщит коммутатору с помощью протокола RADIUS, что аутентификация прошла успешно, и что пользователь авторизован к некоторым ресурсам. В результате авторизации могут происходить разные события: присвоение метки Trustsec, присвоение ACL на порт коммутатора, изменение VLAN на порту коммутатора и т.д. Основная идея в том, что как только аутентификация и авторизация прошли, на ISE появилось соответствие IP-адрес и учётной записи пользователя, и эту информацию можно передать далее на FirePOWER (в рамках pxGrid). И теперь, когда трафик авторизованного пользователя дойдёт до FirePOWER-сенсора, FirePOWER сможет понять от какого именно пользователя трафик пришёл, и сможет применить политики (например, запретить доступ в соц. сети для пользователя «Иванов»).
Роман, да, мы получаем активную аутентификацию. При этом Anyconnect Network Access Module (NAM) можно настроить для Single Sign On, пользователю не придётся вводить учётные данные.
Кстати, использование Anyconnect для 802.1X аутентификации не обязательно. Например, Windows имеет встроенный сапликант. Нужно включить сервис «Проводная автонастройка», и тогда в настройках сетевого адаптера появится вкладка «Проверка подлинности»:
Windows по умолчанию будет предлагать учётные данные, под которыми пользователь вошёл в систему.
Таким образом, аутентификация, хоть и активная, но проходит прозрачно для конечных пользователей.
Если мы изменим политику доступа на FirePOWER, перелогиниться на нужно. Просто новая политика станет применяться к тем же пользователям.
Бесплатная лицензия включает криптографию, которая в последствии будет использоваться для Anyconnect. Но помимо бесплатной лицензии для Anyconnect нужна ещё и лицензия на Anyconnect. Anyconnect для ASA всегда лицензировался отдельно, а сейчас лицензия на Anyconnect вообще покупается не на конкретную железку, а на количество пользователей.
Мигрировать на Cisco ONE можно. Например, для коммутаторов доступа тут в таблице 1 прописаны разные варианты миграции. Но это для сетевых устройств. Что будет при этом с существующими лицензиями Cisco ISE и Prime точно не знаю.
Да, у Cisco с лицензированием всё не просто. Видите, они делают попытки упростить. Ведь в Cisco ONE только 3 лицензии для всех устройств (Foundation, Advanced App и Advanced Sec). Но я в этой статье и пытаюсь донести, что не всё так просто на самом деле, и что во многих случаях заказ по "упрощённой" схеме может получиться неоправданно дороже.
Про первый случай, когда у провайдера был secondary IP-address. Да, в случае с ASA, можно отключить отбрасывание ARP-запроса от провайдера. Для этого есть команда "arp permit-nonconnected". Другой вариант — попробовать настроить на ASA статическую ARP-запись с ключом ALIAS (имитация Secondary IP на ASA). Но про ALIAS – нужно проверять. Когда я описывал первый случай, моя основная идея была показать процесс диагностики. В данном случае, как мне кажется, важнее было не найти способ решения проблемы (уже с вами придумали три варианта), а определить причину проблемы и понять, что проблема кроется именно в ARP. Ведь провайдер не сразу признался, что у него наш шлюз прописан как secondary.
ARP в сетях с VLAN-ами. Вот тут, к сожалению, не смогу подсказать. У меня достаточно много примеров сетей, когда ASA маршрутизирует VLAN-ы, но с ARP-проблемами в этом случае никогда не сталкивались. Вы правильно заметили, в этом случае нужно собирать дополнительную информацию.
Статически агрегированные каналы. Опять же, к сожалению (или к счастью) с проблемами не сталкивался. Есть пример, когда маршрутизаторы подключены к коммутаторам ядра через статически агрегированные порты. Проблем с ARP на возникало, нужно больше информации.
Боюсь, Вы не совсем поняли идею статьи. Основная мысль в том, что ничего добавлять и ничего менять в настройках со стороны удалённого пользователя нельзя.
Поправлюсь. Для отправки писем ESA будет выбирать интерфейс, который ближе к next-hop. Это поведение по умолчанию. Однако, в командной строке можно настроить, чтобы ESA всегда использовала определённый интерфейс для отправки, не зависимо от статических маршрутов и маршрута по умолчанию. Это делается командой deliveryconfig.
Да, тогда да. Я, к сожалению, не знаю какого-либо способа поправить запись в EHLO динамически или заставить ESA выбирать исходящий интерфейс динамически (в зависимости от состояния провайдеров, подключенных к маршрутизатору). У ESA есть маршрут по умолчанию, и для отправки писем она всегда будет выбирать тот интерфейс, который находится ближе к next-hop из маршрута по умолчанию. Перебора интерфейсов она делать не будет.
ESA отвечает на HELO/EHLO тем именем, которое прописано в настройках интерфейса (hostname). Соответственно, можно настроить второй интерфейс на ESA с нужным именем, соответствующим публикации через резервного провайдера. Правда, тогда потребуется создать для него новый Listener, и, соответственно, придётся поддерживать две HAT и RAT таблицы. Ну и, само собой, все интерфейсы ESA должны быть в разных IP-подсетях.
Да, без проблем. Нужно только, чтобы софт был не ниже 9.2.2(4).
Если хотите использовать FirePOWER самой последней версии — 6.0.0.0, то софт на ASA должен быть 9.4.2 или 9.5.1(5).
Спасибо! А правильно ли я понимаю, если диспозиция по хеш определена как «Clean», то файл уже не будет отправлен в AMP Threat Grid для динамического анализа? Т.е., это две последовательные проверки?
Алексей, я извиняюсь, у меня в голове путаница с терминологией случилась. Скажите, пожалуйста, правильно ли я понимаю. Если у нас есть лицензия AMP на ESA, WSA или FirePOWER модуле, то перечисленные устройства при включении политик AMP начинают фактически работать с двумя облаками. Первое облако называется Collective Security Intelligence Cloud и используется исключительно, чтобы определить диспозицию файла по его hash. Если диспозиция файла не может быть определена, то можно отправить весь файл целиком для более детального анализа, но уже во второе облако, которое называется AMP Threat Grid? Это верно, или я ошибаюсь?
Правильно ли я понимаю, то, что в файловых политиках на FireSIGHT называется «Dynamic Analysis» и «Spero Analysis for MSEXE» — это и есть включение отправки исполняемых (и только исполняемых) файлов в облако AMP Threat Grid?
Да, можно. В статье я рассказывал про Outgoing Content Filters. Существуют также Incoming Content Filters, которые как раз можно применять для входящих писем. Так вот, можно создать такой фильтр, который будет выполнять вашу задачу.
Приведу пример скриншотов настроек. В add condition фильтра можно указать адрес получателя, группу получателей в AD или предопределённый список получателей (dictionary):
В Add Action можно выбрать действие Send to Alternate Destination Host:
Далее остаётся применить созданный фильтр к политике для входящих писем в разделе Incoming Mail Policies.
Что касается проверки существования адреса, она будет осуществляться не зависимо от выбранного «Destination host», если это задано в настройках на Cisco ESA. Проверка существования адреса осуществляется запросом в корпоративный Active Directory (так называемый LDAP Acceptance Query). Причём, эта проверка осуществляется до того, как письмо будет обработано фильтром.
ISE ещё умеет аутентифицировать по MAC-адресу — MAC Authentication Bypass (MAB). Это подойдёт для принтеров, камер видеонаблюдения и т.д.
Если вернуться к FirePOWER, тут уже такой момент. Коль нет GUI, вероятно и гранулярный контроль Web-приложений на FirePOWER для таких устройств не нужен. Достаточно разрешить доступ к определённым ресурсам (хоть по IP-адресам).
Механизм таков: Коммутатор не пускает на своём порту никакой трафик от клиента, кроме трафика 802.1X, пока ISE не сообщит коммутатору с помощью протокола RADIUS, что аутентификация прошла успешно, и что пользователь авторизован к некоторым ресурсам. В результате авторизации могут происходить разные события: присвоение метки Trustsec, присвоение ACL на порт коммутатора, изменение VLAN на порту коммутатора и т.д. Основная идея в том, что как только аутентификация и авторизация прошли, на ISE появилось соответствие IP-адрес и учётной записи пользователя, и эту информацию можно передать далее на FirePOWER (в рамках pxGrid). И теперь, когда трафик авторизованного пользователя дойдёт до FirePOWER-сенсора, FirePOWER сможет понять от какого именно пользователя трафик пришёл, и сможет применить политики (например, запретить доступ в соц. сети для пользователя «Иванов»).
Кстати, использование Anyconnect для 802.1X аутентификации не обязательно. Например, Windows имеет встроенный сапликант. Нужно включить сервис «Проводная автонастройка», и тогда в настройках сетевого адаптера появится вкладка «Проверка подлинности»:
Windows по умолчанию будет предлагать учётные данные, под которыми пользователь вошёл в систему.
Таким образом, аутентификация, хоть и активная, но проходит прозрачно для конечных пользователей.
Если мы изменим политику доступа на FirePOWER, перелогиниться на нужно. Просто новая политика станет применяться к тем же пользователям.
Про первый случай, когда у провайдера был secondary IP-address. Да, в случае с ASA, можно отключить отбрасывание ARP-запроса от провайдера. Для этого есть команда "arp permit-nonconnected". Другой вариант — попробовать настроить на ASA статическую ARP-запись с ключом ALIAS (имитация Secondary IP на ASA). Но про ALIAS – нужно проверять. Когда я описывал первый случай, моя основная идея была показать процесс диагностики. В данном случае, как мне кажется, важнее было не найти способ решения проблемы (уже с вами придумали три варианта), а определить причину проблемы и понять, что проблема кроется именно в ARP. Ведь провайдер не сразу признался, что у него наш шлюз прописан как secondary.
ARP в сетях с VLAN-ами. Вот тут, к сожалению, не смогу подсказать. У меня достаточно много примеров сетей, когда ASA маршрутизирует VLAN-ы, но с ARP-проблемами в этом случае никогда не сталкивались. Вы правильно заметили, в этом случае нужно собирать дополнительную информацию.
Статически агрегированные каналы. Опять же, к сожалению (или к счастью) с проблемами не сталкивался. Есть пример, когда маршрутизаторы подключены к коммутаторам ядра через статически агрегированные порты. Проблем с ARP на возникало, нужно больше информации.
Если хотите использовать FirePOWER самой последней версии — 6.0.0.0, то софт на ASA должен быть 9.4.2 или 9.5.1(5).
Правильно ли я понимаю, то, что в файловых политиках на FireSIGHT называется «Dynamic Analysis» и «Spero Analysis for MSEXE» — это и есть включение отправки исполняемых (и только исполняемых) файлов в облако AMP Threat Grid?
Приведу пример скриншотов настроек. В add condition фильтра можно указать адрес получателя, группу получателей в AD или предопределённый список получателей (dictionary):
В Add Action можно выбрать действие Send to Alternate Destination Host:
Далее остаётся применить созданный фильтр к политике для входящих писем в разделе Incoming Mail Policies.
Что касается проверки существования адреса, она будет осуществляться не зависимо от выбранного «Destination host», если это задано в настройках на Cisco ESA. Проверка существования адреса осуществляется запросом в корпоративный Active Directory (так называемый LDAP Acceptance Query). Причём, эта проверка осуществляется до того, как письмо будет обработано фильтром.