logo
Добро пожаловать, Гость! Чтобы использовать все возможности Вход или Регистрация.

Уведомление

Icon
Error

Опции
К последнему сообщению К первому непрочитанному
Offline res  
#1 Оставлено : 2 апреля 2015 г. 17:04:55(UTC)
res

Статус: Новичок

Группы: Участники
Зарегистрирован: 18.03.2015(UTC)
Сообщений: 8
Российская Федерация
Откуда: Мурманск

Добрый день!

1.В руководстве администратора безопасности версии 1.1 в п.1.Назначение есть фраза в конце:
"Соединения, построенные с использованием режимов и алгоритмов IPSec, отличных от описанных в настоящей документации, должны рассматриваться как незащищенные соединения."
Значит ли это, что любая конфигурация с использованием cryptopro ipsec отличная от приведенных в данном руководстве должна рассматриваться как незащищенная, соответственно на нее не будет распространятся сертификация ФСБ?

2.В лицензии на CryptoPro IpSec сказано:
"3.2. Вознаграждение Лицензиара за предоставленное право на использование программы для ЭВМ СКЗИ «КриптоПро IPsec» на рабочем месте входит в сумму вознаграждения за предоставленное право на использование программы для ЭВМ СКЗИ «КриптоПро CSP» версии 3.6.1 на условиях простой (неисключительной) лицензии."
В то же время в прайсе видим:
"Лицензия на право использования СКЗИ КриптоПро IPSec версии 1.0 на одном сервере - 20000"
Поясните, плз.
Получается надо купить лицензию за 20 тыс.руб. на CryptoPro CSP на сервер и CryptoPro IPsec на сервер то же за 20. Итого 40 тыс.руб. Как это вяжется с лицензией?
Offline pd  
#2 Оставлено : 2 апреля 2015 г. 17:18:37(UTC)
pd


Статус: Сотрудник

Группы: Администраторы
Зарегистрирован: 16.09.2010(UTC)
Сообщений: 464
Откуда: КРИПТО-ПРО

Сказал(а) «Спасибо»: 11 раз
Поблагодарили: 65 раз в 54 постах
По первому пункту, имеется ввиду, что можно так плохо настроить IPsec, что соединия на самом деле будут не защищены, всё пойдёт в открытом виде. Поэтому мы себя защищаем от подобных конфигураций.

Если вам кажется, что ваша конфигурация не подходит под предложенные в документации, возможно мы что-то упустили. Можете раскрыть подробности вашей конфигурации, которая не подходит под приведенные в руководстве?

По второму пункту:

Коммерческий отдел написал:
на рабочем месте бесплатно, купи только CSP
на сервере за деньги, но CSP все равно купить нужно

Отредактировано пользователем 2 апреля 2015 г. 17:23:47(UTC)  | Причина: добавлен ответ на второй вопрос

Offline res  
#3 Оставлено : 2 апреля 2015 г. 19:40:28(UTC)
res

Статус: Новичок

Группы: Участники
Зарегистрирован: 18.03.2015(UTC)
Сообщений: 8
Российская Федерация
Откуда: Мурманск

Хотим связать удаленные офисы с головным. Сейчас на шлюзе (он же фаервол) в головном офисе настроен ipsec, на стандартной западной криптографии.
В удаленных офисах в качестве шлюза обычные рабочие станции на Windows XP, там то же поднят ipsec. Хочется сертифицированной защиты :)
Предполагаем за существующим шлюзом в головном офисе поставить сервер с CryptoPro CSP + ipsec, такая же конфигурация на шлюзах в удаленных офисах. Маршрутизация в голове для доступа в удаленные офисы настраивается через этот сервер. Использовать PSK или сертификаты - пока не решили, протестируем потом определимся.
Вопрос вызван тем, что в Руководстве администратора безопасности описывавются варианты с использованием ISA, TMG, CheckPoint совместно с КриптоПро ipsec на одном сервере - у нас ничего из этих продуктов не используется и фаервол/шлюз планируется внешний по отношению к серверу с КриптоПро ipsec.
Offline pd  
#4 Оставлено : 3 апреля 2015 г. 11:39:06(UTC)
pd


Статус: Сотрудник

Группы: Администраторы
Зарегистрирован: 16.09.2010(UTC)
Сообщений: 464
Откуда: КРИПТО-ПРО

Сказал(а) «Спасибо»: 11 раз
Поблагодарили: 65 раз в 54 постах
Автор: res Перейти к цитате
в Руководстве администратора безопасности описывавются варианты с использованием ISA, TMG, CheckPoint совместно с КриптоПро ipsec на одном сервере - у нас ничего из этих продуктов не используется и фаервол/шлюз планируется внешний по отношению к серверу с КриптоПро ipsec.

Судя по всему, вы используете схему client-to-site: 1 сервер (головной офис) и клиенты (windows xp).

Это реализуется с использованием RRAS на L2TP/IPsec, см. "10.1. Настройка VPN для безопасного подключения клиента к сети офиса", где есть ссылки на инструкции как с использование TMG, так и без, только средствами самих Windows Server.
Offline res  
#5 Оставлено : 3 апреля 2015 г. 12:02:00(UTC)
res

Статус: Новичок

Группы: Участники
Зарегистрирован: 18.03.2015(UTC)
Сообщений: 8
Российская Федерация
Откуда: Мурманск

Автор: pd Перейти к цитате

Судя по всему, вы используете схему client-to-site: 1 сервер (головной офис) и клиенты (windows xp).

Нет. site-to-site. Даже там где 2 компа. Один из компов - шлюз. Как ни странно, Windows Xp и Windows 7 нормально справляются с ролью шлюза.
Авторизация клиентов не нужна, шлюз в удаленном офисе должен быть всегда на связи, даже если пользователь не работает в данный момент.
Offline pd  
#6 Оставлено : 3 апреля 2015 г. 12:04:35(UTC)
pd


Статус: Сотрудник

Группы: Администраторы
Зарегистрирован: 16.09.2010(UTC)
Сообщений: 464
Откуда: КРИПТО-ПРО

Сказал(а) «Спасибо»: 11 раз
Поблагодарили: 65 раз в 54 постах
Автор: res Перейти к цитате
Нет. site-to-site. Даже там где 2 компа. Один из компов - шлюз. Как ни странно, Windows Xp и Windows 7 нормально справляются с ролью шлюза.

Расскажите подробнее про то как вы это настроили, а то непонятно о какой технолигии речь, туннельный IPsec с прописыванием подсетей на каждом шлюзе?
Offline res  
#7 Оставлено : 3 апреля 2015 г. 12:28:27(UTC)
res

Статус: Новичок

Группы: Участники
Зарегистрирован: 18.03.2015(UTC)
Сообщений: 8
Российская Федерация
Откуда: Мурманск

Да, совершенно верно, туннельный ipsec с подсетями в фильтрах и дополнительное правило непосредственно для внешнего интерфейса шлюза.
Аналогичную конфигурацию хочется и с КрпитоПро осуществить, чтоб обошлось с наименьшими трудозатратами.
Поэтому и возник вопрос о том будет ли сеть все еще защищенной и не аннулируются ли сертификаты из-за "неправильного использования", т.к. предполагаемая схема не очень-то вписывается в описанные в Руководстве схемы.
Offline pd  
#8 Оставлено : 3 апреля 2015 г. 12:42:12(UTC)
pd


Статус: Сотрудник

Группы: Администраторы
Зарегистрирован: 16.09.2010(UTC)
Сообщений: 464
Откуда: КРИПТО-ПРО

Сказал(а) «Спасибо»: 11 раз
Поблагодарили: 65 раз в 54 постах
Автор: res Перейти к цитате
Да, совершенно верно, туннельный ipsec с подсетями в фильтрах и дополнительное правило непосредственно для внешнего интерфейса шлюза.
Аналогичную конфигурацию хочется и с КрпитоПро осуществить, чтоб обошлось с наименьшими трудозатратами.
Поэтому и возник вопрос о том будет ли сеть все еще защищенной и не аннулируются ли сертификаты из-за "неправильного использования", т.к. предполагаемая схема не очень-то вписывается в описанные в Руководстве схемы.

Почему, это site-to-site но без L2TP/IPsec, вот цитата из руководства:

10.2. Настройка Site-to-Site написал:
... Допускается VPN-соединений сетей по схеме site-to-site с применением двух типов прото-колов: IPsec-tunnel и L2TP\IPsec ...


Просто настройка туннелей более одного через политики, довольно кропотливая ручная работа, есть где ошибиться.
Offline res  
#9 Оставлено : 3 апреля 2015 г. 14:52:22(UTC)
res

Статус: Новичок

Группы: Участники
Зарегистрирован: 18.03.2015(UTC)
Сообщений: 8
Российская Федерация
Откуда: Мурманск

Ясно.
Спасибо за наводку! Видимо пропустил когда читал руководство.
Да, ошибиться есть где. Как-то у микрософта это слишком сложно сделано, в том же линуксе или freebsd настройка ipsec гораздо проще происходит.
Но спасает то, что если не правильно настроишь, то, как правило, связи нет, поэтому ошибки диагностируются легко, но, бывает, тяжело исправляются :)
Offline pd  
#10 Оставлено : 3 апреля 2015 г. 14:55:06(UTC)
pd


Статус: Сотрудник

Группы: Администраторы
Зарегистрирован: 16.09.2010(UTC)
Сообщений: 464
Откуда: КРИПТО-ПРО

Сказал(а) «Спасибо»: 11 раз
Поблагодарили: 65 раз в 54 постах
Автор: res Перейти к цитате
Но спасает то, что если не правильно настроишь, то, как правило, связи нет, поэтому ошибки диагностируются легко, но, бывает, тяжело исправляются :)

Тут страшнее другое, что связь вроде бы есть и всё правильно — но всё идет в открытом виде.
Offline res  
#11 Оставлено : 3 апреля 2015 г. 15:00:43(UTC)
res

Статус: Новичок

Группы: Участники
Зарегистрирован: 18.03.2015(UTC)
Сообщений: 8
Российская Федерация
Откуда: Мурманск

Может быть и такое.
Всегда проверяю после настройки на шлюзе в головном офисе с помощью tcpdump, чтоб ничего кроме трафика ipsec на внешнем интерфейсе не было.
Offline res  
#12 Оставлено : 4 апреля 2015 г. 21:33:33(UTC)
res

Статус: Новичок

Группы: Участники
Зарегистрирован: 18.03.2015(UTC)
Сообщений: 8
Российская Федерация
Откуда: Мурманск

Прокоментируй, плз., еще фразу из Руководства:
п.10.2 "IPSec в туннельном режиме менее защищен"
Почему он менее защищен, чем l2tp/ipsec? Когда ipsec в связке l2tp/ipsec как раз и занимается обеспечением конфиденциальности и целостности пакетов.
Возможно имеется ввиду, что нет аутентификации пользователя?

И на счет "IPSec в туннельном режиме может уменьшить эффективную пропускную способность VPN-туннеля" то же не согласен. Т.к. в случае с l2tp/ipsec все заголовки l2tp идут внутри пакета ipsec, поэтому оверхед этой связки выше, чем одного ipsec.
Offline pd  
#13 Оставлено : 6 апреля 2015 г. 11:57:31(UTC)
pd


Статус: Сотрудник

Группы: Администраторы
Зарегистрирован: 16.09.2010(UTC)
Сообщений: 464
Откуда: КРИПТО-ПРО

Сказал(а) «Спасибо»: 11 раз
Поблагодарили: 65 раз в 54 постах
Автор: res Перейти к цитате
Почему он менее защищен, чем l2tp/ipsec? Когда ipsec в связке l2tp/ipsec как раз и занимается обеспечением конфиденциальности и целостности пакетов.
Возможно имеется ввиду, что нет аутентификации пользователя?

И на счет "IPSec в туннельном режиме может уменьшить эффективную пропускную способность VPN-туннеля" то же не согласен. Т.к. в случае с l2tp/ipsec все заголовки l2tp идут внутри пакета ipsec, поэтому оверхед этой связки выше, чем одного ipsec.


Все верно, нет аутентификации пользователя, при настройке, например PSK, при компрометации одного шлюза - будет скомпрометирована вся сеть. В этом случае, на период обновления PSK, сеть будет недоступна полностью или частично, пока не обновятся ключи PSK на всех машинах. В случае L2TP, есть механизм отключения шлюза по пользователю, с дальнейшей плановой заменой PSK, без отказа в обслуживании всей сети.

Оверхед оверхеду рознь, здесь скорее всего просто констатируется факт появления этого оверхеда. В случае L2TP/IPsec против IPsec в туннельном режиме, да, первый проигрывает по размеру оверхеда, но содержит в себе многие преимущества встроенных механизмов протокола PPP: обнаружение колец, ошибок, разрывов, многоканальности и т.д.

Offline res  
#14 Оставлено : 6 апреля 2015 г. 13:56:39(UTC)
res

Статус: Новичок

Группы: Участники
Зарегистрирован: 18.03.2015(UTC)
Сообщений: 8
Российская Федерация
Откуда: Мурманск

Спасибо за ответ!
Offline kitsb0  
#15 Оставлено : 1 ноября 2017 г. 11:46:17(UTC)
kitsb0

Статус: Новичок

Группы: Участники
Зарегистрирован: 14.03.2017(UTC)
Сообщений: 2
Российская Федерация

Коллеги, добрый день!
Отчасти оффтоп, но на новую тему не тянет.

Прошу подсказать, как бороться с непредсказуемостью срока действия PSK:
используем vpn до RRAS'a по PSK средствами КриптоПро CSP 3.6 + ipsec1.1
При генерации пары задаётся срок действия -m 6 (6 мес.), но PSK истекает всегда не по графику.
Для примера: PSK сгенерирован 01.07.2017, должен закончится 01.01.2018.
30.10.2017 был выполнен chkpsk, который показал, что ключ истекает 01.10.2017, т.е. не должен работать уже как месяц. В итоге истёк 01.11.2017. Живёт своей жизнью.

Как генерим: genpsk.exe -D RRAS -n 01.11.2017 -v 2 -m 6 -f GenPSK -P CMAK -S -N ForOffice ForClient

Это особенность сборки или дело в нас?
Offline pd  
#16 Оставлено : 1 ноября 2017 г. 12:04:59(UTC)
pd


Статус: Сотрудник

Группы: Администраторы
Зарегистрирован: 16.09.2010(UTC)
Сообщений: 464
Откуда: КРИПТО-ПРО

Сказал(а) «Спасибо»: 11 раз
Поблагодарили: 65 раз в 54 постах
Автор: kitsb0 Перейти к цитате
Это особенность сборки или дело в нас?

Это особенности PSK, чтобы было мучительно больно им пользоваться и переходить уже на сертификаты.

На самом деле, конечно это ошибки в коде и плохое проектирование PSK. Мы рассчитали, что этот метод аутентификации будет востребован мало и временно, поэтому не уделили ему должного внимания. Сейчас же что-либо исправить уже тяжело. Поэтому можем рекомендовать рассчитывать смену PSK заранее и, по возможности, переходить на аутентификацию по сертификатам.
Offline kitsb0  
#17 Оставлено : 1 ноября 2017 г. 12:55:18(UTC)
kitsb0

Статус: Новичок

Группы: Участники
Зарегистрирован: 14.03.2017(UTC)
Сообщений: 2
Российская Федерация

Автор: pd Перейти к цитате
Это особенности PSK, чтобы было мучительно больно им пользоваться и переходить уже на сертификаты.


Собственно я так коллегам и обозначил, что это сознательный вау-эффект для раскраски серых будней :)
Спасибо!
RSS Лента  Atom Лента
Пользователи, просматривающие эту тему
Быстрый переход  
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.