отмена
Отображаются результаты для 
Вместо этого искать 
Вы имели в виду: 
cancel
Объявления
5069
Просмотры
5
Полезный материал
50
Ответы
Julia Ustyugova
Community Manager

Спроси всё о своих Cisco NGFW устройствах

Добро пожаловать на сессию Спроси всё о своих Cisco NGFW устройствах после вебинара Сообщество Live!

Задавайте свои вопросы с 25 марта по 31 мая 2021

Нажмите "Ответить", чтобы опубликовать свой вопрос

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

Программа вебинара:

  • Зачем знать больше
  • Правильно ли работает Cisco NGFW устройство
  • На что обратить внимание в первую очередь при настройке и поиске неисправностей
  • Как оптимизировать текущую конфигурацию
  • Когда нужно/можно использовать новые возможности

Информация об эксперте:

dkontsev.jpegДмитрий Концевой – специалист по техническим решениям информационной безопасности департамента Global Demo Engineering (Krakow). В течение карьеры занимался внедрением решений ИБ, участвовал в проектах, связанных с аудитом ИБ и тестами на проникновение. Работал в поддержке клиентов Cisco в качестве TAC-инженера (AAA) и в крупных SOC Cisco/Akamai в качестве старшего специалиста. Сертифицированный инструктор Cisco с 2011 года. Выпускник Киевского Политехнического Института имени Игоря Сикорского(КПИ). Обладатель сертификатов CCIE Security #53849, CISSP #667520, CEH, CCSI #33988. 

50 ОТВЕТ 50

Добрый день Сергей, конечно, я просто был на довольно длительно больничном. До конца недели опубликуем все ответы.

 

Так же жду комментариев и более детальных вопросов если таковые появляются!

Добрый день!

 

Хотелось бы, чтобы при просмотре правил ACP по-умолчанию отображались не все колонки, а только нужные мне. Это возможно как-то настроить?

Добрый день, Сергей!  

Данный функционал точно доступен начиная с 6.6 версии FMC, но только в версии 6.7 настройки отображения колонок сохраняются для администратора при переходе между различными закладками меню или после выхода из системы. Чего не наблюдается в 6.6 - соответствующий баг

volovinoy
Beginner

В случае Cisco ASA 5525-X (традиционный классический, а не FTD имидж, управление через ASDM) с модулем FirePOWER (FTD, управление через Firepower Management Center):

- как в этом случае изменится и будет выглядеть данная цепочка
Prefilter -> L3/L4 ACL -> SI -> SSL -> DNS -> Identity -> NAP -> L7 ACL -> Discovery -> File&AMP -> Intrusion

- как будут взаимодействовать друг с другом политики Cisco ASA (сконфигурированные через ASDM) и политики модуля FirePOWER "Prefilter" и "L3/L4 ACL" (сконфигурированные через FMC) - они будут как-то дополнять друг друга, как-то изменять или полностью подменять собой (и кто кого?) ?

- какие best-practices составления политик для данного случая (исключая случай замены традиционного классического non-FTD имиджа ASA на FTD имидж)?

Добрый день,

 

Цепочка будет схожей и, если упрощённо,- то сперва трафик должен не быть заблокирован на АSA(ACL, shun, URPF, другой политикой, предшествующей перенаправлению на модуль, или прочими механизмами) и в дальнейшем перенаправлен на модуль FirePOWER при помощи MPF(Modular Policy Framework). Тем самым сперва отработают все основные функции АSA и уже потом функционал FirePOWER модуля.

Важно так же обратить внимание на то что в данном случае нет Prefilter’a, а так же пересбор сессий и TCP Normalization будут выполнены дважды - на  АSA и FirePOWER отдельно - одна из причин не эффективности работы модуля и потери производительности. Упрощенная схема последовательности действий: https://www.ciscopress.com/articles/article.asp?p=2730336&seqNum=7

 

При помощи MPF возможно настроить дополнительные ограничения либо проверки трафика такие как QoS, ограничения количества сессий, предотвращение SYN Flood, изменения значений TCP sequence, фильтрацию и анализ конкретного протокола(например запретить определённый метод/команду внутри протокола прикладного уровня - HTTP PUT Block).

MPF использует синтаксис классов и политик. Класс описывает сам трафик к которому хотим применить действие(например вся внутренняя сеть - match 10.0.0.0/24), - политика описывает само действие.

 

Важно помнить что эти дополнительные проверки и ограничения трафика имеют свою иерархию внутри политики(Сперва выполняются действия QoS input policing, затем TCP normalization, TCP and UDP connection limits and timeouts, TCP sequence number randomization, and TCP state bypass, ASA CSC - перенаправление на ASA FirePOWER (ASA SFR) на 8м месте - весь список и детали касательно применения политик: https://www.cisco.com/c/en/us/td/docs/security/asa/asa93/configuration/firewall/asa-firewall-cli/mpf-service-policy.html

 

Основная рекомендация по организации политик в данном случае - разрешить только ожидаемый трафик на ASA(при помощи ACL в самом простом случае, или других механизмов) и заблокировать/ограничить все остальное(или хотя бы не использовать по возможности permit ip any any в ключевых сегментах И далее перенаправлять трафик на FirePOWER модуль в первую очередь для/от критичных устройств в сети, увеличивая его количество в зависимости от требований и загруженности модуля.

Julia Ustyugova
Community Manager

Вопрос от  Alexandr.Shevchuk:  

 
 

Добрый день! Спасибо за такой полный разбор NGFW. Недавно с коллегами вышел спор, по поводу работы Intrusion Policy.  Правильно ли я понимаю, что если Firepower обладает информацией что за  хост (например OS), который передает пакет по правилу, то даже если там применена политика со всеми правилами он не будет "прогонять" пакет по всем правилам, а только относящимся к этой OS? Или это не так и под каждый хост нужно делать свою политику, с уязвимостями именно для этого хоста?