Спасибо, просто акселерации данных в туннеле не происходит даже при включении этой строки, из-за этого я не сильно пытался выверить эту настройку, и посмотрел на нескольких которые имел под рукой. Смысл который я хотел довести это то что не надо боятся переводить SSL VPN на Loopback из-за возможной "потери" акселерации в железе - не будет никакой потери в производительности https://www.reddit.com/r/fortinet/comments/jxw9nc/comment/gd1umlc/?utm_source=share&utm_medium=web2x&context=3
Понял о какой вы статье, забыл что писал ее когда-то, спасибо что напомнили, надо будет обновить.
Угадали - работаю в Telco/Интеграторе. Хотелось бы быть таким же оптимистом, но увы - большинство кейсов обеспечения безопасности у клиентов не то что best practices, common sense напрочь отказываются применить, и много энергиии уходит на внедрение казалось бы элементарных вещей в 21-ом веке "не могу я согласиться открыть доступ из Интернета всем пулам MS Azure к вашему SCADA, потому что какая-то компания суппорта там VDI держит и дала вам этот пул как «их собственный»" . То есть внедрение/консультации по ИБ больше на сражение с ветряными мельницами схоже. Поэтому до ZTN дело просто не доходит. А так идея обещающая, особенно со стиранием периметра, вхождением IPv6.
Palo Alto тоже занимаюсь, но конечно не так тесно как Фортиками, просто так вышло. Правда на русскоязычном пространстве они еще менее знакомы, так что не уверен будет ли интересно кому-нибудь читать о них.
Спасибо, да фича-баг с миксом аутентификации может сделать проблемы, не упомянул потому что надо было где-то остановиться. Если напишу когда-нибудь специфически о видах и подводных камнях аутентикации на Фортиках то опишу и это.
Нумерация/порядок не имеет встроенной логики или иерархии, т.е пункты ниже не потому что менее важны. Ранжировать рекомендации не стал так как было бы субьективно - важность/применимость пункта зависит от конкретных условий каждого Фортика.
А что security by obscurity работает просто жизнь показала, тот же CVE-2018-13379 - встречал Форти которые год (!) стояли не пропатченные с этой уязвимостью и не взломанные, только потому что SSL VPN слушал на рандомно-высоком порте. Если почитать например записки рансомщика, который "кормится" на этой же уязвимости - https://xss.is/threads/54506/ то очевидно что на потоке не точечный взлом компании Х, а поиск легких целей. Конечно, при направленных усилиях взломать конкретную компанию, смена порта не поможет - атакующий просканирует все порты. Но с тем что такие меры не эффективны и применять их вообще не стоит - не соглашусь.
Насчет Zero Trust Network Access (ZTNA) - многие упомянули, но это решение в Форти работает только в связке с сервером EMS что дополнительные расходы и нетривиальный деплоймент, поэтому не упомянул чтобы не усложнять гайд. Эта тема стоит отдельного освещения.
Спасибо, просто акселерации данных в туннеле не происходит даже при включении этой строки, из-за этого я не сильно пытался выверить эту настройку, и посмотрел на нескольких которые имел под рукой. Смысл который я хотел довести это то что не надо боятся переводить SSL VPN на Loopback из-за возможной "потери" акселерации в железе - не будет никакой потери в производительности https://www.reddit.com/r/fortinet/comments/jxw9nc/comment/gd1umlc/?utm_source=share&utm_medium=web2x&context=3
Понял о какой вы статье, забыл что писал ее когда-то, спасибо что напомнили, надо будет обновить.
Угадали - работаю в Telco/Интеграторе. Хотелось бы быть таким же оптимистом, но увы - большинство кейсов обеспечения безопасности у клиентов не то что best practices, common sense напрочь отказываются применить, и много энергиии уходит на внедрение казалось бы элементарных вещей в 21-ом веке "не могу я согласиться открыть доступ из Интернета всем пулам MS Azure к вашему SCADA, потому что какая-то компания суппорта там VDI держит и дала вам этот пул как «их собственный»" . То есть внедрение/консультации по ИБ больше на сражение с ветряными мельницами схоже. Поэтому до ZTN дело просто не доходит. А так идея обещающая, особенно со стиранием периметра, вхождением IPv6.
Palo Alto тоже занимаюсь, но конечно не так тесно как Фортиками, просто так вышло. Правда на русскоязычном пространстве они еще менее знакомы, так что не уверен будет ли интересно кому-нибудь читать о них.
Спасибо, да фича-баг с миксом аутентификации может сделать проблемы, не упомянул потому что надо было где-то остановиться. Если напишу когда-нибудь специфически о видах и подводных камнях аутентикации на Фортиках то опишу и это.
Форти поддерживают акселерацию в железе только на обмен ключами в SSL VPN, и то когда эта фича включена. На всех фортиках что смотрел, она выключена по умолчанию, подробнее здесь - https://community.fortinet.com/t5/FortiGate/Technical-Tip-Status-of-SSL-VPN-acceleration/ta-p/230215
Касаемо статьи от 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 что дополнительные расходы и нетривиальный деплоймент, поэтому не упомянул чтобы не усложнять гайд. Эта тема стоит отдельного освещения.