Comments 12
За статью спасибо. Жаль только, что сам вендор Fortinet (производитель продукта Fortigate) в 2022 году покинул рынок России и Беларуси из-за санкций.
Сами уже год как ведём с ними переписку, чтобы получить лицензии на их продукты, но пока результат около нулевой.
SSL VPN
Это, простите, куда и как?
SSL — прокси https? Тогда при чём тут VPN? Смешались в кучу кони, люди...
>> Эта безопасность через неясность действительно работает
Вы упоминаете неработающее решение первым, а парадигму ZeroTrust одиннадцатой.
Хотя в вашей же статье от 2018 года вы поставили пункт "Rules with ANY/ALL in services are almost always a bad idea" существенно выше. Что изменилось за 5 лет?
Неработающим это решение является потому, что вероятность взлома никак не зависит от неизвестности порта - это не подбор хеша длиной 256 бит, это околомгновенное прочесывание 64к портов. Если у вас не установлено стандартного пароля на стандартной учетке, ломай-не хочу.
Согласен. Любые предложения, начинающиеся со смены стандартного порта, лично я дальше не читаю. Это маркер, что люди не совсем понимают сетевые реалии. Настоятельно рекомендую всем остальным поступать также.
Касаемо статьи от 2018 - искал но нашел только эту https://yurisk.info/2018/01/05/Fortinet-Fortigate-ssh-access-with-certificate-authentication/ но она об SSH, не SSL VPN.
Нумерация/порядок не имеет встроенной логики или иерархии, т.е пункты ниже не потому что менее важны. Ранжировать рекомендации не стал так как было бы субьективно - важность/применимость пункта зависит от конкретных условий каждого Фортика.
А что security by obscurity работает просто жизнь показала, тот же CVE-2018-13379 - встречал Форти которые год (!) стояли не пропатченные с этой уязвимостью и не взломанные, только потому что SSL VPN слушал на рандомно-высоком порте. Если почитать например записки рансомщика, который "кормится" на этой же уязвимости - https://xss.is/threads/54506/ то очевидно что на потоке не точечный взлом компании Х, а поиск легких целей. Конечно, при направленных усилиях взломать конкретную компанию, смена порта не поможет - атакующий просканирует все порты. Но с тем что такие меры не эффективны и применять их вообще не стоит - не соглашусь.
Насчет Zero Trust Network Access (ZTNA) - многие упомянули, но это решение в Форти работает только в связке с сервером EMS что дополнительные расходы и нетривиальный деплоймент, поэтому не упомянул чтобы не усложнять гайд. Эта тема стоит отдельного освещения.
Re:Статья 2018 года: https://www.linkedin.com/pulse/tips-best-practices-caring-your-fortigate-firewalls-yuri-slobodyanyuk/?trackingId=BSOUTSA%2BS7%2BN3Wb5jw40gw%3D%3D
Я концептуально не согласен в том, что ранжирование субъективно. Есть best practices, и ZTN - одна из них. Вы, как я понимаю, в консалтинге работаете, если у вас клиент спросит, с чего начать, не будете же рассказывать про субъективность ранжирования рекомендаций.
ZTN в общем - это отсутствие понятия trusted зон, выражающееся в необходимости писать максимально гранулярные правила (в то же время, не доводя это до идиотизма). Про ZTNA я ничего не писал и не слышал.
Не хотите palo alto попробовать? 15 лет работать с фортинетом - это большое увлечение, снимаю шляпу.
Понял о какой вы статье, забыл что писал ее когда-то, спасибо что напомнили, надо будет обновить.
Угадали - работаю в Telco/Интеграторе. Хотелось бы быть таким же оптимистом, но увы - большинство кейсов обеспечения безопасности у клиентов не то что best practices, common sense напрочь отказываются применить, и много энергиии уходит на внедрение казалось бы элементарных вещей в 21-ом веке "не могу я согласиться открыть доступ из Интернета всем пулам MS Azure к вашему SCADA, потому что какая-то компания суппорта там VDI держит и дала вам этот пул как «их собственный»" . То есть внедрение/консультации по ИБ больше на сражение с ветряными мельницами схоже. Поэтому до ZTN дело просто не доходит. А так идея обещающая, особенно со стиранием периметра, вхождением IPv6.
Palo Alto тоже занимаюсь, но конечно не так тесно как Фортиками, просто так вышло. Правда на русскоязычном пространстве они еще менее знакомы, так что не уверен будет ли интересно кому-нибудь читать о них.
А можно подробнее про "поскольку SSL VPN НЕ поддерживает аппаратное ускорение ни на одном Fortigate", а то вендор на словах и документах обратное утверждает.
Так же стоит упомянуть, что при реализации SSL VPN не стоит делать микс аутентификаций даже если очень очень хочется. Как пример RADIUS c MFA и AD. Даже последняя версия FortiOS реализует это максимально тупо - "кто первый ответил того и тапки".
Спасибо, да фича-баг с миксом аутентификации может сделать проблемы, не упомянул потому что надо было где-то остановиться. Если напишу когда-нибудь специфически о видах и подводных камнях аутентикации на Фортиках то опишу и это.
Форти поддерживают акселерацию в железе только на обмен ключами в SSL VPN, и то когда эта фича включена. На всех фортиках что смотрел, она выключена по умолчанию, подробнее здесь - https://community.fortinet.com/t5/FortiGate/Technical-Tip-Status-of-SSL-VPN-acceleration/ta-p/230215
Проверил на нескольких разных. Версия FortiOS 7.0.11. Везде включена.
На 7.2.4 как будто команда сменилось.
Спасибо, просто акселерации данных в туннеле не происходит даже при включении этой строки, из-за этого я не сильно пытался выверить эту настройку, и посмотрел на нескольких которые имел под рукой. Смысл который я хотел довести это то что не надо боятся переводить SSL VPN на Loopback из-за возможной "потери" акселерации в железе - не будет никакой потери в производительности https://www.reddit.com/r/fortinet/comments/jxw9nc/comment/gd1umlc/?utm_source=share&utm_medium=web2x&context=3
Да, этот топик не реддите я тоже нашёл уже. Слегка был удивлён конечно. Просто ipsec туннели на loopback из-за отсутствия аппаратного ускорения на боксах до NP7 не рекомендуется переводить. А про аппаратное ускорение ssl vpn я как-то никогда не задумывался.
Мне кстати на одном проекте доставшемся по наследству из-за использования нестандартного порта для ssl vpn пришлось сделать NAT на Virtual IP на intervdom link на стандартные порты. Потому что у клиента часто возникали проблемы например у подрядчиков в их корпоративных сетях и на публичных wifi в поездах, гостиницах и тд. Надо бы кстати уже доделать этот момент и нат оставить на нестандартном порту, для забывших всё его ещё сменить, а в ssl vpn настройках поставить 443.
Fortigate SSL VPN рекомендации по ужесточению конфигурации