Комментарии 30
Когда дизайнер рисует зубчатое зацепление. Брррр
Борис, добрый день.
Спасибо за статью.
Правильно ли я понял, что в данном раскладе мы опять таки возвращаемся к активной аутентификации? То есть каждому пользователю с каждого его устройства нужно вводить логин\пароль через Cisco AnyConnect.
И что произойдёт если мы изменили политику доступа? Нужно ли будет пользователю «перелогиниться» чтобы политики применились к нему?
Спасибо за статью.
Правильно ли я понял, что в данном раскладе мы опять таки возвращаемся к активной аутентификации? То есть каждому пользователю с каждого его устройства нужно вводить логин\пароль через Cisco AnyConnect.
И что произойдёт если мы изменили политику доступа? Нужно ли будет пользователю «перелогиниться» чтобы политики применились к нему?
Роман, да, мы получаем активную аутентификацию. При этом Anyconnect Network Access Module (NAM) можно настроить для Single Sign On, пользователю не придётся вводить учётные данные.
Кстати, использование Anyconnect для 802.1X аутентификации не обязательно. Например, Windows имеет встроенный сапликант. Нужно включить сервис «Проводная автонастройка», и тогда в настройках сетевого адаптера появится вкладка «Проверка подлинности»:
Windows по умолчанию будет предлагать учётные данные, под которыми пользователь вошёл в систему.
Таким образом, аутентификация, хоть и активная, но проходит прозрачно для конечных пользователей.
Если мы изменим политику доступа на FirePOWER, перелогиниться на нужно. Просто новая политика станет применяться к тем же пользователям.
Кстати, использование Anyconnect для 802.1X аутентификации не обязательно. Например, Windows имеет встроенный сапликант. Нужно включить сервис «Проводная автонастройка», и тогда в настройках сетевого адаптера появится вкладка «Проверка подлинности»:
Windows по умолчанию будет предлагать учётные данные, под которыми пользователь вошёл в систему.
Таким образом, аутентификация, хоть и активная, но проходит прозрачно для конечных пользователей.
Если мы изменим политику доступа на FirePOWER, перелогиниться на нужно. Просто новая политика станет применяться к тем же пользователям.
Про «проводную автонастройку» не знал, спасибо!
В данном стенде, получает, вовсю используется trustsec? Иначе не понятно где конкретно мы проходим аутентификацию
В данном стенде, получает, вовсю используется trustsec? Иначе не понятно где конкретно мы проходим аутентификацию
Для этой статьи trustsec метку (SGT) я использую только чтобы показать, что в консоли FirePOWER (FMC) появится соответствющий атрибут. То есть, что ISE передаёт на FirePOWER метку. Аутентификация происходит на ISE в не зависимости от использования trustsec.
Механизм таков: Коммутатор не пускает на своём порту никакой трафик от клиента, кроме трафика 802.1X, пока ISE не сообщит коммутатору с помощью протокола RADIUS, что аутентификация прошла успешно, и что пользователь авторизован к некоторым ресурсам. В результате авторизации могут происходить разные события: присвоение метки Trustsec, присвоение ACL на порт коммутатора, изменение VLAN на порту коммутатора и т.д. Основная идея в том, что как только аутентификация и авторизация прошли, на ISE появилось соответствие IP-адрес и учётной записи пользователя, и эту информацию можно передать далее на FirePOWER (в рамках pxGrid). И теперь, когда трафик авторизованного пользователя дойдёт до FirePOWER-сенсора, FirePOWER сможет понять от какого именно пользователя трафик пришёл, и сможет применить политики (например, запретить доступ в соц. сети для пользователя «Иванов»).
Механизм таков: Коммутатор не пускает на своём порту никакой трафик от клиента, кроме трафика 802.1X, пока ISE не сообщит коммутатору с помощью протокола RADIUS, что аутентификация прошла успешно, и что пользователь авторизован к некоторым ресурсам. В результате авторизации могут происходить разные события: присвоение метки Trustsec, присвоение ACL на порт коммутатора, изменение VLAN на порту коммутатора и т.д. Основная идея в том, что как только аутентификация и авторизация прошли, на ISE появилось соответствие IP-адрес и учётной записи пользователя, и эту информацию можно передать далее на FirePOWER (в рамках pxGrid). И теперь, когда трафик авторизованного пользователя дойдёт до FirePOWER-сенсора, FirePOWER сможет понять от какого именно пользователя трафик пришёл, и сможет применить политики (например, запретить доступ в соц. сети для пользователя «Иванов»).
Да, теперь понятно, сначала это обычный 802.1x и в качестве radius-клиента у нас коммутатор\wlc.
Тогда такой практический вопрос. Понятно что для тех же linux worksation или Mac-OS мы можем использовать Cisco AnyConnect. Но как быть в случае если у нас нет GUI? То есть нужно что-то вроде консольного супликанта.
Тогда такой практический вопрос. Понятно что для тех же linux worksation или Mac-OS мы можем использовать Cisco AnyConnect. Но как быть в случае если у нас нет GUI? То есть нужно что-то вроде консольного супликанта.
Ну да, видимо нужны консольные сапликанты…
ISE ещё умеет аутентифицировать по MAC-адресу — MAC Authentication Bypass (MAB). Это подойдёт для принтеров, камер видеонаблюдения и т.д.
Если вернуться к FirePOWER, тут уже такой момент. Коль нет GUI, вероятно и гранулярный контроль Web-приложений на FirePOWER для таких устройств не нужен. Достаточно разрешить доступ к определённым ресурсам (хоть по IP-адресам).
ISE ещё умеет аутентифицировать по MAC-адресу — MAC Authentication Bypass (MAB). Это подойдёт для принтеров, камер видеонаблюдения и т.д.
Если вернуться к FirePOWER, тут уже такой момент. Коль нет GUI, вероятно и гранулярный контроль Web-приложений на FirePOWER для таких устройств не нужен. Достаточно разрешить доступ к определённым ресурсам (хоть по IP-адресам).
Да вот в том то и дело, что нужен контроль… Сервера, хоть и не имеют GUI, обращаются к огромному количеству веб-ресурсов (git, maven, репозитории, etc) к которым доступ по IP предоставить сложно, ввиду огромного количества оных и тут нужна фильтрация именно по URL-ам.
Сейчас это делается либо открытием доступа по src IP, либо с помощью костылей типа «искуственных» AD Query и опять же выдёргиванием привязки юзер\IP из AD Security логов.
А хотелось бы чего-то более интеллектуального…
Сейчас это делается либо открытием доступа по src IP, либо с помощью костылей типа «искуственных» AD Query и опять же выдёргиванием привязки юзер\IP из AD Security логов.
А хотелось бы чего-то более интеллектуального…
Прошло уже почти 2 года, но справедливости ради хочу заметить что для Linux/Mac нет AnyConnect NAM. А жаль, очень жаль…
Жаль только, что нативный сапликант не поддерживает EAP Chaining…
Учитывая, что ISE уже может выполнять функции фаервола (точнее, хранит SGACL/DACL и разливает их на железки), то зачем еще FirePOWER? Как нечто более продвинутое? Или как средства контроля периметра?
FirePOWER — и как более продвинутый фаервол, и как контроль периметра. SGACL/DACL — контроль только по IP-адресам и меткам. FirePOWER даёт распознавание приложений (например, facebook можно разбить на facebook games, facebook comment, facebook like, facebook message и т.д.) URL-фильтрация по категориям и репутациям. Плюс FirePOWER предлагает NG IPS и AMP (AMP — это своего рода антивирусная проверка проходящих через сенсор файлов).
а насчет фейсбука можно поподробнее? ;) Если на комп пользователя ничего не ставится, то как вы собираетесь распознавать, какой ssl-трафик относится к играм, а какой к лайкам?
Ну FirePOWER умеет дешифровать ssl. Как обычно, с подменой сертификата. А далее, в прошивке FirePOWER зашиты сигнатуры различный приложений. По этим сигнатурам FirePOWER хитро распознаёт, трафик какого приложения проходит через сенсор. Соответственно, политиками можно блокировать тот или иной трафик.
С подменой сертификата сможет, простите «каждый дурак». При этом пользователь получает security exception, а в отдельных случаях — просто невозможность работы с ресурсом. некомильфо, в общем.
А есть другие варианты?
FirePOWER — корпоративный фаервол, сертификат подменяется корпоративным сертификатом. При этом сертификат ресурса также остаётся. Поэтому security exception не появляется, и проблем с доступом к ресурсам в 99% случаев не возникает.
Это я знаю.
Но сложности с тем же гуглом и прочим hsts остаются.
Но сложности с тем же гуглом и прочим hsts остаются.
Не сталкивались. Не расскажете поподробнее?
В Chrome, например, зашиты цифровые подписи их сертификатов. В случае попытки подмены сертификата цифровая подпись меняется (не смотря на то, что сертификат является доверенным) — получаем security exception. В FF нечто подобное тоже есть, на сколько я знаю.
Алсо, pinning так же сводит все усилия по подмене сертификатов на нет.
Алсо, pinning так же сводит все усилия по подмене сертификатов на нет.
Подождите))) Любой нормальный браузер помимо подлинности самого сертификата сверяет url с атрибутами этого сертификата. И если при заходе на google.com аналогичного атрибуда в сертификате не найдет — будет ругаться. Что с этим делать?
Корпоративный сертификат «вклинивается» перед сертификатом конечного ресурса. Сертификат конечного ресурса также остаётся со всеми его атрибутами, поэтому по этой причине браузер ругаться не будет.
А можно где то подробно прочитать про механизм? А то не совсем понятно. Выходит браузер знает, что его ломают, но молчит))) Спасибо.
Поподробнее можно почитать прямо в User Guide по FirePOWER. Ссылочку сделал именно на раздел дешифрации.
Если у вас есть свой CA, то можно сделать так, что FirePower будет генерить сертификаты для «интересных» сайтов, которым будут доверять ваши браузеры (т.к. CA-сертификат будет разложен по клиентам). Правда SSL работает крайне нестабильно. Тестировали декриптование входящего SSL трафика по известным сертификатам (своих публичных ресурсов, что бы определять атаки, которые идут через SSL) на всех версиях кроме последней (6.0.1.1) — куча проблем, пришлось отказаться.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Интеграция Cisco FirePOWER и ISE