Рискну предположить, что никак. От подмены сертификата поможет техника Certificate pinning. Я кратко упоминал этот момент в тексте. Думаю, по вашего вопросу имеет смысл смотреть в этом направлении.
По производительности cisco тоже не даёт точных цифр. Объясняют тем, что цифры очень зависят от дополнительных включенных сервисов: используется ли IPS, файловые политики и AMP и т.д.
В любом случае, вендор предупреждает, что не стоит использовать дешифрацию для всего подряд. Включайте дешифрацию только тогда, когда она действительно нужна.
Как раз в предыдущем материале я попробовал разобраться, для чего именно требуется дешифрация.
Ранее устройства-сенсоры SourceFIRE вообще не поддерживали дешифрацию. Для дешифрации нужно было покупать дополнительную железку — SSL Appliance. Это было связано именно с производительностью.
Возможно нам удастся протестировать в каком-либо виде устройство Cisco на предмет производительности при дешифрации. Если получится, обязательно поделимся результатами.
Коллеги, у нас тут была дискуссия про дешифрацию. Мы попробовали подробнее разобраться и описать, зачем она вообще нужна на NGFW — тут, и как она работает — тут. Посмотрите, надеюсь будет информативно.
Да, одно и то же. Но часто бывает так: у вас есть свой сервер отправитель, тот же MS Exchange, который прописан в настройках почтового клиента. Но у него в настройках прописано слать все письма во вне через провайдерские релеи или какие-либо другие внешние почтовые релеи (в send connector настройка smart host, если не ошибаюсь). А уже провайдерские релеи отправляют письма дальше в Интернет. И именно IP-адреса или A-записи провайдерских серверов фигурируют в SPF. Если эти провайдерские MTA оказываются скомпрометированными, злоумышленник также получает возможность слать через них поддельные письма, а SPF-проверка на стороне получателя будет проходить успешно.
В этом случае, если ваш exchange будет формировать DKIM-отпечаток до отправки писем на провайдерские релеи, получатель сможет отличить ваше письмо от письма злоумышленника.
Вот как раз, если отбросить «cousin domain» и «free mail account», то мы вполне хорошо могли бы защититься с помощью SPF, DKIM, DMARC. Но проблема в том, что далеко не все это используют. В комментарии ниже очень верно подметили про ключевого партнёра с кривыми записями в SPF.
То же самое касается цифровой подписи PGP. Многие ли готовы её внедрять?
Именно поэтому я выделил в статье отдельный метод — создание гранулярных правил «вручную».
Метод 7. Создание гранулярных фильтров «вручную». В данном примере помогло бы либо сравнение mail from с заголовком From, либо, в случае в ESA, функциональность Forged Email Detection.
Корпоративный сертификат «вклинивается» перед сертификатом конечного ресурса. Сертификат конечного ресурса также остаётся со всеми его атрибутами, поэтому по этой причине браузер ругаться не будет.
FirePOWER — корпоративный фаервол, сертификат подменяется корпоративным сертификатом. При этом сертификат ресурса также остаётся. Поэтому security exception не появляется, и проблем с доступом к ресурсам в 99% случаев не возникает.
Ну FirePOWER умеет дешифровать ssl. Как обычно, с подменой сертификата. А далее, в прошивке FirePOWER зашиты сигнатуры различный приложений. По этим сигнатурам FirePOWER хитро распознаёт, трафик какого приложения проходит через сенсор. Соответственно, политиками можно блокировать тот или иной трафик.
FirePOWER — и как более продвинутый фаервол, и как контроль периметра. SGACL/DACL — контроль только по IP-адресам и меткам. FirePOWER даёт распознавание приложений (например, facebook можно разбить на facebook games, facebook comment, facebook like, facebook message и т.д.) URL-фильтрация по категориям и репутациям. Плюс FirePOWER предлагает NG IPS и AMP (AMP — это своего рода антивирусная проверка проходящих через сенсор файлов).
В любом случае, вендор предупреждает, что не стоит использовать дешифрацию для всего подряд. Включайте дешифрацию только тогда, когда она действительно нужна.
Как раз в предыдущем материале я попробовал разобраться, для чего именно требуется дешифрация.
Ранее устройства-сенсоры SourceFIRE вообще не поддерживали дешифрацию. Для дешифрации нужно было покупать дополнительную железку — SSL Appliance. Это было связано именно с производительностью.
Возможно нам удастся протестировать в каком-либо виде устройство Cisco на предмет производительности при дешифрации. Если получится, обязательно поделимся результатами.
В этом случае, если ваш exchange будет формировать DKIM-отпечаток до отправки писем на провайдерские релеи, получатель сможет отличить ваше письмо от письма злоумышленника.
То же самое касается цифровой подписи PGP. Многие ли готовы её внедрять?
Именно поэтому я выделил в статье отдельный метод — создание гранулярных правил «вручную».