Vipnet Cryptoservice + Обновление Сертификатов

[Отдел ИБ]

Добрый день.

1) В ЦУС формирую 2 АП, зарегистрированных в ПЗ Криптосервис. На каждом АП по одному пользователю, ТК которых связаны друг с другом, а также с Координатором.

Формирую дистрибутивы пользователей, переношу их на компы с установленным ПО VipNet CryptoService, провожу первичную инициализацию. Указываю контейнер закрытых ключей. Подписываю вордовский документ ЭЦП пользователя, переношу на второй АП, на котором также установлен криптосервис и проведена первичная инициализация.

Проблема в том, что второй пользователь видит в вордовском документе недействительную подпись. По идее в дистрибутиве должны храниться и корневой сертификат администратора, и СОС. Хотя их также копировал в явном виде, результат тот же.

В чем может быть причина?

2) Я правильно понимаю, что в корневом сертификате и в dst-файле хранятся как закрытый ключ пользователя, так и СОС и корневой сертификат.

3) В транспортных настройках для координатора задал ip-адрес. После нажатия на кнопку опросить в транспортном модуле пишет, что узел недоступен. Хотя VipNet Клиенты видят координатор.

[slavanchuk]

Добрый день.

1) В ЦУС формирую 2 АП, зарегистрированных в ПЗ Криптосервис. На каждом АП по одному пользователю, ТК которых связаны друг с другом, а также с Координатором.

Формирую дистрибутивы пользователей, переношу их на компы с установленным ПО VipNet CryptoService, провожу первичную инициализацию. Указываю контейнер закрытых ключей. Подписываю вордовский документ ЭЦП пользователя, переношу на второй АП, на котором также установлен криптосервис и проведена первичная инициализация.

Проблема в том, что второй пользователь видит в вордовском документе недействительную подпись. По идее в дистрибутиве должны храниться и корневой сертификат администратора, и СОС. Хотя их также копировал в явном виде, результат тот же.

В чем может быть причина?

2) Я правильно понимаю, что в корневом сертификате и в dst-файле хранятся как закрытый ключ пользователя, так и СОС и корневой сертификат.

3) В транспортных настройках для координатора задал ip-адрес. После нажатия на кнопку опросить в транспортном модуле пишет, что узел недоступен. Хотя VipNet Клиенты видят координатор.

1) Не установлены СОСы или корневой сертификат. Причину, по которой подпись недействительна нужно смотреть.

2)В DST файле хранятся корневой сертификат, СОСы и закрытый ключ подписи (если только он при формировании DST не записывался на отдельный носитель).

3)Чтобы сервис видел клиентов, необходимо чтобы в фильтрах открытой сети для данного компьютера были доступны порты 5000-5002 TCP.

[Отдел ИБ]

Спасибо за ответ.

Еще кое-что хотел бы уточнить.

1) По первому вопросу: После проведения первичной инициализации (закрытый ключ также в dst-файле) на обоих АП были запросы на установку корневых сертификатов, я их удовлетворил. А списки отозванных сертификатов каким образом устанавливать, если они хранятся в dst файле?

2) По поводу 3 вопроса, возможно, я несовсем правильно выразился. Необходимо проводить обновление СОС и сертификата пользователя. Какие настройки нужно произвести после первичной инициализации?

3) Вопрос в догонку(для проверки, правильно ли я делаю или что-то упускаю): чтобы пользователь мог корректно подписывать документы, в ЦУСе нужно АП зарегистрировать в ПЗ "Криптосервис". После этого для его ТК какие связи необходимо настроить? Только с Координатором или еще с кем-то(у меня связи с Администратором и координатором)?

[slavanchuk]

1) Подтверждать нужно только корневые сертификаты. СОСы ставятся автоматически

2)Обновление СОСов происходит по MFTP. Криптосервис работает без IPLir. Следовательно, это нешифрованный трафик. И необходимо добавить исключения в фильтры открытой сети координатора. Настройки нужно делать только на координаторе.

3)Достаточно связи только с координатором.

[Отдел ИБ]

Во, спасибо, как раз все у меня в голове уложилось по полочкам.

Еще одна проблема: я через RegPoint создал двух пользователей и для них сертификаты, разослал контейнеры на компьютеры с VipNet CSP, установил корневой сертификат и СОС на каждый ПК. Подписывает/проверяет подпись нормально.

Проделал примерно те же самые операции для VipNet CryptoService, установил корневой сертификат, на всякий случай и СОС. Документы подписываются, но на втором ПК при проверке подписи пишет, что она недействительна. Хотя сертификаты актуальны.

Сравнив сертификаты в CSP и CryptoService обнаружил, что в сведения о сертификате:

1) для CSP сертификат:

- Подтверждает удаленному компьютеру идентификацию вашего компьютера;

- Защищает сообщения электронной почты.

2) для CryptoService только одна задача:

- Защищает сообщения электронной почты.

Я думаю, что, скорее всего, из-за этого подпись в документе считается недействительной.

Собственно вопрос, почему в сертификате из dst-файла не содержится задачи "Подтверждает удаленному компьютеру идентификацию вашего компьютера"?

В ЦУС я указал для ТК CryptoService только ПЗ "Криптосервис", хотя других ПЗ и не должно быть зарегистрированно.

[slavanchuk]

Данный вариант использования подписи "подтверждает .... идентификацию..." является обязательным для организации TLS-соединения (насколько я помню). Таким образом, проблема связана не с этим. В Вашем случае стоит проверить корректность установки СОС (и актуальности).

[Отдел ИБ]

Криптосервис работает без IPLir. Следовательно, это нешифрованный трафик. И необходимо добавить исключения в фильтры открытой сети координатора. Настройки нужно делать только на координаторе.

Исключения в фильтрах открытой сети делаются в МЭ координатора, разделе [forward]?

Если так, то трафик откуда куда нужно разрешить? Я создал правило, разрешающее трафик по всем протоколам с АП с криптосервисом до координатора (интерфейс открытой сети) и наоборот от координатора до АП. Интерфейс координатора не пингуется. Или я что-то неправильно понимаю?

[slavanchuk]

Исключения в фильтрах открытой сети делаются в МЭ координатора, разделе [forward]?

Если так, то трафик откуда куда нужно разрешить? Я создал правило, разрешающее трафик по всем протоколам с АП с криптосервисом до координатора (интерфейс открытой сети) и наоборот от координатора до АП. Интерфейс координатора не пингуется. Или я что-то неправильно понимаю?

Нужно сделать входящие соединения на координатор с узла криптосервиса по портам TCP 5000-5002. И наоборот - с координатора на эти порты узла криптосервиса (иногда координатор сам пытается установить соединение). У Вас, как я понимаю, linux координатор?

[Отдел ИБ]

Нужно сделать входящие соединения на координатор с узла криптосервиса по портам TCP 5000-5002. И наоборот - с координатора на эти порты узла криптосервиса (иногда координатор сам пытается установить соединение). У Вас, как я понимаю, linux координатор?

Да, Linux координатор HW1000. Попробовал в файерволе прописать данные правила, не помогло.

Криптосервис без ПЗ "Защита трафика", мб с этим связано?

[slavanchuk]

Да, Linux координатор HW1000. Попробовал в файерволе прописать данные правила, не помогло.

Криптосервис без ПЗ "Защита трафика", мб с этим связано?

Криптосервис и не должен, насколько я понмю, быть в задаче защита трафика, поскольку её там нет. А в журнале блокированных пакетов не видно блокировок на данный IP-адрес

[Отдел ИБ]

Криптосервис и не должен, насколько я понмю, быть в задаче защита трафика, поскольку её там нет. А в журнале блокированных пакетов не видно блокировок на данный IP-адрес

Единственная запись в журнале координатора.

Поскольку трафик с данного АП не шифруется, нужно ли помимо разрешающего правила в файерволе прописывать еще доп. правила, например, создавать полутуннель?

[slavanchuk]

Единственная запись в журнале координатора.

Поскольку трафик с данного АП не шифруется, нужно ли помимо разрешающего правила в файерволе прописывать еще доп. правила, например, создавать полутуннель?

Нет - туннель не обязательно делать. Достаточно прописать разрешающее правило. Туннель всё равно не шифруется, так как на том ПК нет криптографии. В журнале записей маловато. Вы как ограничивали выводимые записи? Если пакет приходит, он должен либо блокироваться, либо пропускаться.

[Отдел ИБ]

Нет - туннель не обязательно делать. Достаточно прописать разрешающее правило. Туннель всё равно не шифруется, так как на том ПК нет криптографии. В журнале записей маловато. Вы как ограничивали выводимые записи? Если пакет приходит, он должен либо блокироваться, либо пропускаться.

Извиняюсь, напутал немного с айпишником. Завтра напишу то, что нужно, заодно скажу ограничения выводимых записей в журнале.

Если не сложно, посмотрите, пожалуйста, еще одну тему: http://www.infotecs.ru/forum/index.php?showtopic=7448

[Отдел ИБ]

Журнал пакетов:

Все пакеты, направляемые на интерфейс координатора, удаляются. Во всех остальных фильтрах пакетов нет.

[slavanchuk]

Все пакеты, направляемые на интерфейс координатора, удаляются. Во всех остальных фильтрах пакетов нет.

Журнал пишет, что пакет заблокирован. Нужно добавить разрешающее правило.

[Отдел ИБ]

Журнал пишет, что пакет заблокирован. Нужно добавить разрешающее правило.

В разделе [forward] межсетевого экрана уже добавлял правила разрешающие входящий трафик с криптосервиса на координатор и наоборот по портам 5000-5002.

[slavanchuk]

В разделе [forward] межсетевого экрана уже добавлял правила разрешающие входящий трафик с криптосервиса на координатор и наоборот по портам 5000-5002.

Видимо, нужно посмотреть с порядком правил - нет ли ранее запрещающего. 30-ое событие - это блокировка фильтрами открытой сети. А добавлять правило нужно не в forward (транзит), а в local.

[Отдел ИБ]

Спасибо, все прекрасно работает.

Последний вопрос в этой теме: "Будут ли конфликтовать на одной машине КриптоПро и VipNet CryptoService? Если да, то как избежать конфликта?"

[slavanchuk]

Спасибо, все прекрасно работает.

Последний вопрос в этой теме: "Будут ли конфликтовать на одной машине КриптоПро и VipNet CryptoService? Если да, то как избежать конфликта?"

Да, есть между ними некие трения. Вроде бы, насколько я помню, сначала стоит ставить криптопро, а потом - випнет. Тогда проблем меньше. Если наоборот - возможны трудности. Хотя, они меняются от установки к установке.

[Отдел ИБ]

Спасибо за помощь!