Сертификация в РФ и NGFW — это несколько не взаимосвязанные вещи и такое лучше пояснять. Сертифицируется отдельный «функционал», в основном это функционал МЭ, СОВ и Криптография.
Что касается первого варианта с продажей железки (или виртуальной машины), не верьте даташитам… Только пилотный проект даст честный результат.
Не каждая компания может позволить себе проверять каждую железку в рамках пилотных проектов, учитывая, что во многих случаях пилотный проект такой железки фактически полноценное внедрение. Да и пилотный проект не всегда даст «честный» результат — не любая компания решится пропускать весь свой трафик через тестовый агрегат, а без всего трафика «честного» результата по производительности вы не получите.
Рекомендация, если вендор не имеет поддержки в РФ (или количество инженеров меньше 10 человек), вы с гарантией будете сами и уединенно решать свои проблемы.
Не совсем прослеживается связь между территориальным нахождением техподдержки и качеством ее обслуживания (за исключением выездов ественно). Или акцент идет на знание английского языка у обладателя нового продукта?
Списки компаний под санкциями ширятся...
А можете привести примеры уже санкционных NGFW?
Почти у всех HTTPS разбор трафика с подменой сертификата есть, если нет – это уже не NGFW решение.
Очень странный критерий конечно, но да ладно. Вашими бы устами да года полтора-два назад, когда ngfw уже были, а для дешифрации рекомендовали использовать отдельные аппаратные платформы. Как вы и сказали, тонкостей хватает и в большинстве случаев, по итогу, дешифрацию необходимо делать только для части специфического трафика.
11. Интеграция с MS AD и другими службами. Совет: пилот и решение кейсов на местах.
Вот как нигде не могу с вами не согласится. Но к середине статьи уже складывается впечатление, что все решается только через пилот)
12. IPS/IDS. Какая периодичность обновления? Скорость обновления и реакции на инциденты ИБ вендором. Есть примеры когда на самые критичные уязвимости вендор пишет сигнатуры месяцами и годами…
Рядовому заказчику, честного и однозначного ответа на столь абстрактный вопрос, к сожалению, не получить. Все врут.
14. Блокирование ботнет трафика
Разве, в основном, это не функционал IPS и, от части, url фильтрации?
18. ГОСТ VPN. Если вам нужен ГОСТ VPN, скорее всего вы купите российское решение
У нас сейчас кто то делает ngfw? Прям вот ngfw? Помню, года полтора назад задавал подобный вопрос одному из именитых российских производителей криптошлюзов — там ближайшие лет 5 не планировалось ничего)
Jan 23 2017 00:05:32: %ASA-4-722051: Group <GroupPolicy_CBS> User <privetkakdela> IP <289.123.44.12> IPv4 Address <192.168.3.34> IPv6 address <::> assigned to session
Еще можно парсить логи асы. В части SVC они достаточно информативны, их много и они имеют соответсвующие ID, что облегчает процесс получения только необходимых сообщений.
пример некоторых сообщений
Jan 23 2017 23:50:32: %ASA-6-734001: DAP: User privetkakdela, Addr 289.123.44.12, Connection AnyConnect: The following DAP records were selected for this connection: DfltAccessPolicy
Jan 23 2017 23:50:32: %ASA-6-113039: Group <GroupPolicy_CBS> User < privetkakdela> IP <289.123.44.12> AnyConnect parent session started.
Jan 22 2017 23:53:25: %ASA-4-113019: Group = CBS, Username = privetkakdela, IP = 289.123.44.12, Session disconnected. Session Type: AnyConnect-Parent, Duration: 0h:05m:28s, Bytes xmt: 12562, Bytes rcv: 921, Reason: User Requested
Такой вариант уменьшает шансы возникновения приступа паранойи: можно не переживать, что в системе где то лежит файл скрипта, в котором в открытом виде хранятся креденшелы для подключения к центральному мэ по SNMP. Не надо ничего выдумывать для получения логина пользователей. И не надо ничего запускать каждые 30 секунд, пусть даже через crone — достаточно натравить скрипт парсера на файлы логов и запустить его в фоне.
Оффтоп по времени сходимости. Очень наглядный пример — это одновременное использование и bgp и igp. Тот самый случай, когда мы получаем black hole из-за того что, к примеру, ospf уже поднялся, а bgp ещё нет. Не зря придумали overload механизмы для «запрета» прохождения транзитного трафика: overload bit (is-is), max-metric (ospf). Помимо стандартных таймеров там есть опция «жди меня», а точнее «жди его» — дождаться пока поднимется братюня bgp и только потом возвращать работу igp в штатный режим. Eigrp в этом плане нервно курит в сторонке.
Флуд выглядит куда занятнее, когда в такой топологии (фул меш с кучей провайдеров) один из провайдеров начинает биться в конвульсиях, прыгая из up в down каждые несколько секунд.
Классное «просто падал OSPF». А то что при падении одного интерфейса в OSPF, в вашей фул меш топологии, в рамках одной area начинался флудинг по всем n(n-1) линкам (без деления на 2, т.к по два провайдера на каждой ноде), вас видимо не сильно волновало.
Печально будет, если будет скомпрометирован любой локальный хост, у которого есть доступ к управляющим портам tor.
Кстати, еще момент. Если ставить tor на Ubuntu, то лучше прописать официальные репы и добавить ключи, да бы получить последнюю стабильную версию. Для Debian вроде и так все должно быть ок, хотя репы и для него есть.
Если вы везде открывает ControlPort, то не надо ли включать аутентификацию для него? HashedControlPassword или CookieAuthentication.
## If you enable the controlport, be sure to enable one of these
## authentication methods, to prevent attackers from accessing it.
#HashedControlPassword
#CookieAuthentication
Вы про самолеты, а мы про пароходы. Понятное дело, что любой трансивер должен соответствовать стандартам передачи сигнала (и за это отвечает вендор), но это не означает, что он должен работать в чужом оборудовании.
Если в радиоприемник Sony вставить детали из радиоприемника Огонёк, то не факт, что он будет хоть в каком то виде принимать FM-радиостанции. Пример утрированный, но вы уловили суть.
Всё верно, в конечном итоге, любой вопрос по совместимости уточняется у вендоров с письменным подтверждением (ну либо оф. документ какой нить). С такими ценниками, без апрува сейчас никуда, да и с двумя почками как то спокойнее живется.
Мне кажется, лучше переформулировать в терминах продаж — чем это лучше и насколько дороже.
Собственно, это относится практически ко всему письму :)
Что то мне подсказывает, что из описания и так понятно чем лучше. А про «насколько дороже»: так не с чем проводить сравнение. Вот про S-Class есть с чем сравнивать, на это и тыкнули пальцем.
В большей степени, все сноски сделаны, что бы помочь менеджерам отвечать на относительно стандартные вопросы заказчиков, собственно, это относится практически ко всему письму. А переформулировать техническую часть в термины продаж могут и сами менеджеры, они у нас классные.
Очень полезно дать готовую таблицу замены снятых с продажи трансиверов на актуальные, т.к. заказчик в подавляющем большинстве случаев копипастит партномера из предыдущей удачной закупки, сколько бы лет назад она не случилась.
Там все просто, для SFP добавилась литера «D» в конец, и литера «E» для медного. Не стал делать на этом акцент, у нас все в курсе.
Очень распространённый кейс — каким твинаксом связать нехус или вообще кошку с другим-не-менее-брендовым-свитчем?
Цисковский? Нецисковский? Брокада-меланокс-длинк? Кто «даст зуб» за совместимость?
Заказчику не нужен этот головняк, да и продажнику тем более.
«Мы не можем давать ни гарантий, ни рекомендаций по использованию сторонних трансиверов с оборудованием Cisco или Twinax с оборудованием других вендоров.»
И другой интересный момент — не все порты SFP+ поддерживают медные гигабитные трансиверы в форм-факторе SFP+, могут быть неприятные сюрпризы.
В контексте письма рассматривался один единственный коммутатор и судя по докам, у него должно быть все впорядке с glc-te.
Умеет мультимод.
Вот это кстати да, спасибо. Возможно, я решил закрыть на это глаза из за вопиющей несправедливости по отношению к 2Х ценнику за ММ (по сравнению с GLC-SX-MMD). В любом случае, в статье поправим, менеджеров оповестим, мир спасём.
Вы конечно большой молодец, что всё подробно расписали. Но мне кажется, что всего лишь пара картинок (с общей топологией и схемами переключения при отказах) и адекватное восприятие статьи возросло бы в разы.
Это все классно, когда решаемые задачи ограничиваются «базовой» или «околобазовой» конфигурацией фиксированной группы «статических» устройств.
ИМХО, было бы много полезнее сделать такой GUI для поиска блоков текущей конфигурации по задаваемым параметрам. Например, указываешь конфигурационный файл, задаешь ip адрес для поиска и тебе выдается: в какой строке, какого ACL используется этот ip, в каком объекте лежит этот ip, какой группе объектов принадлежит этот объект, где используется этот объект и т.д. и т.п. Как по мне, это бы исключило такую задачу как: покдлючение к устройству, вывод конфигурации, копипаст конфигурации в блокнот, Ctrl+F по блокноту нужного ip адреса, выдирание нужных блоков конфига и копипаст в другой файл блокнота. Возможно Вам покажется это интересным и Вы подумаете над реализацией этой идеи.
Если интересно, то нажми
Я как то делал такое на python, для ASA (не люблю ASDM), с использованием ciscoconfparse в связке с pexpect (для автоматического подключения к выбранному устройству и загрузки нужных блоков текущей конфигурации, по которым выполняется поиск). И вот как раз, для того что бы запилить нормальный GUI, у меня не хватило энтузиазма. Хватило только на такое:
Какую именно информацию выдавал скрипт?
1. Присутствие заданного адреса в правилах NAT и ACL
2. Присутствие заданного адреса в объектах и этих объектов в правилах NAT и ACL
3. Присутствие найденных объектов в группах объектов и этих групп в правилах NAT и ACL
4. Присутствие найденных групп объектов в группах объектов и этих групп в правилах NAT и ACL (и так далее в цикле)
5. Присутствие заданного адреса в группах объектов и этих групп в правилах NAT и ACL
6. Присутствие найденных групп объектов в группах объектов и этих групп в правилах NAT и ACL (и так далее в цикле)
При этом если на ASA включена функция NAMES (автоматическая замена ip адреса на указанное имя), то происходил поиск и по имени, где это необходимо (начиная с версии 8.3(1) необходимо это только в object-group-ах).
Не возьмусь сказать за всех, но для многих основным аргументом служит IPS. Объективно выражая свое субъективное мнение, NGIPS в FP действительно хорош. Да и Циска, в большей степени, старается позиционировать FP, как решение NGIPS (+AMP), а уже потом как NGFW.
Первая версия FTD действительно получилась «странной». Но попытка создания централизованного управления «всем и сразу» засчитана. Будем ждать следующих релизов. Как минимум, интересно же, чем там дело закончится с VPN (особенно с Remote Access).
Не каждая компания может позволить себе проверять каждую железку в рамках пилотных проектов, учитывая, что во многих случаях пилотный проект такой железки фактически полноценное внедрение. Да и пилотный проект не всегда даст «честный» результат — не любая компания решится пропускать весь свой трафик через тестовый агрегат, а без всего трафика «честного» результата по производительности вы не получите.
Не совсем прослеживается связь между территориальным нахождением техподдержки и качеством ее обслуживания (за исключением выездов ественно). Или акцент идет на знание английского языка у обладателя нового продукта?
А можете привести примеры уже санкционных NGFW?
Очень странный критерий конечно, но да ладно. Вашими бы устами да года полтора-два назад, когда ngfw уже были, а для дешифрации рекомендовали использовать отдельные аппаратные платформы. Как вы и сказали, тонкостей хватает и в большинстве случаев, по итогу, дешифрацию необходимо делать только для части специфического трафика.
Вот как нигде не могу с вами не согласится. Но к середине статьи уже складывается впечатление, что все решается только через пилот)
Рядовому заказчику, честного и однозначного ответа на столь абстрактный вопрос, к сожалению, не получить. Все врут.
Разве, в основном, это не функционал IPS и, от части, url фильтрации?
У нас сейчас кто то делает ngfw? Прям вот ngfw? Помню, года полтора назад задавал подобный вопрос одному из именитых российских производителей криптошлюзов — там ближайшие лет 5 не планировалось ничего)
Такой вариант уменьшает шансы возникновения приступа паранойи: можно не переживать, что в системе где то лежит файл скрипта, в котором в открытом виде хранятся креденшелы для подключения к центральному мэ по SNMP. Не надо ничего выдумывать для получения логина пользователей. И не надо ничего запускать каждые 30 секунд, пусть даже через crone — достаточно натравить скрипт парсера на файлы логов и запустить его в фоне.
Кстати, еще момент. Если ставить tor на Ubuntu, то лучше прописать официальные репы и добавить ключи, да бы получить последнюю стабильную версию. Для Debian вроде и так все должно быть ок, хотя репы и для него есть.
Если в радиоприемник Sony вставить детали из радиоприемника Огонёк, то не факт, что он будет хоть в каком то виде принимать FM-радиостанции. Пример утрированный, но вы уловили суть.
Что то мне подсказывает, что из описания и так понятно чем лучше. А про «насколько дороже»: так не с чем проводить сравнение. Вот про S-Class есть с чем сравнивать, на это и тыкнули пальцем.
В большей степени, все сноски сделаны, что бы помочь менеджерам отвечать на относительно стандартные вопросы заказчиков, собственно, это относится практически ко всему письму. А переформулировать техническую часть в термины продаж могут и сами менеджеры, они у нас классные.
Там все просто, для SFP добавилась литера «D» в конец, и литера «E» для медного. Не стал делать на этом акцент, у нас все в курсе.
«Мы не можем давать ни гарантий, ни рекомендаций по использованию сторонних трансиверов с оборудованием Cisco или Twinax с оборудованием других вендоров.»
В контексте письма рассматривался один единственный коммутатор и судя по докам, у него должно быть все впорядке с glc-te.
Вот это кстати да, спасибо. Возможно, я решил закрыть на это глаза из за вопиющей несправедливости по отношению к 2Х ценнику за ММ (по сравнению с GLC-SX-MMD). В любом случае, в статье поправим, менеджеров оповестим, мир спасём.
ИМХО, было бы много полезнее сделать такой GUI для поиска блоков текущей конфигурации по задаваемым параметрам. Например, указываешь конфигурационный файл, задаешь ip адрес для поиска и тебе выдается: в какой строке, какого ACL используется этот ip, в каком объекте лежит этот ip, какой группе объектов принадлежит этот объект, где используется этот объект и т.д. и т.п. Как по мне, это бы исключило такую задачу как: покдлючение к устройству, вывод конфигурации, копипаст конфигурации в блокнот, Ctrl+F по блокноту нужного ip адреса, выдирание нужных блоков конфига и копипаст в другой файл блокнота. Возможно Вам покажется это интересным и Вы подумаете над реализацией этой идеи.
2. Присутствие заданного адреса в объектах и этих объектов в правилах NAT и ACL
3. Присутствие найденных объектов в группах объектов и этих групп в правилах NAT и ACL
4. Присутствие найденных групп объектов в группах объектов и этих групп в правилах NAT и ACL (и так далее в цикле)
5. Присутствие заданного адреса в группах объектов и этих групп в правилах NAT и ACL
6. Присутствие найденных групп объектов в группах объектов и этих групп в правилах NAT и ACL (и так далее в цикле)
При этом если на ASA включена функция NAMES (автоматическая замена ip адреса на указанное имя), то происходил поиск и по имени, где это необходимо (начиная с версии 8.3(1) необходимо это только в object-group-ах).
Не возьмусь сказать за всех, но для многих основным аргументом служит IPS. Объективно выражая свое субъективное мнение, NGIPS в FP действительно хорош. Да и Циска, в большей степени, старается позиционировать FP, как решение NGIPS (+AMP), а уже потом как NGFW.
Первая версия FTD действительно получилась «странной». Но попытка создания централизованного управления «всем и сразу» засчитана. Будем ждать следующих релизов. Как минимум, интересно же, чем там дело закончится с VPN (особенно с Remote Access).