Тема от Serggi

  • Serggi
  • Посетитель
  • Неактивен

Запретить логин к NET-ключу как к локальному

Мы поставляем пользователям ключи Stealth II, локальные и сетевые. Защита производится через API. При запуске сначала через GrdSetFindMode отыскивается локальный ключ (маска GrdFMR_Local) и выполняется логин, если он неуспешен, то в GrdSetFindMode  устанавливается маска GrdFMR_Remote и снова выполняется логин. В этом подходе есть один минус - на компьютере, где установлен ключ, для ключей NET успешен логин в локальном режиме, таким образом как бы добавляется дополнительная лицензия. Можно было бы изменить логику наоборот, вначале искать сетевой ключ, но тогда при наличии у пользователя реального локального ключа при работе в сети тратилось бы много времени на поиск сервера ключа.

Вопрос: возможно ли запретить использование NET-ключа как локального, используя другие флаги в GrdSetFindMode?  (Была надежда на флаг типа ключа GrdDT_LAN, но обратного к нему нет и эксперименты были неудачными)

Ответ от Кирилл Ковлежов

  • Кирилл Ковлежов
  • Посетитель
  • Неактивен

Re: Запретить логин к NET-ключу как к локальному

Могу предложить как вариант одну из многочисленных схем реализации поиска различных ключей.

Данную схему легко самостоятельно модифицировать любым нужным образом.

Например, так -

1) Выполняем блок инициализации (GrStartup(GrdFMR_Local+GrdFMR_Remote)), GrdCreateHandle, GrdSetAccessCode) - т. е. активируем и локальное и сетевое GrdAPI

2) Вызываем функцию GrdSetFindMode с обязательными параметрами dwRemoteMode=GrdFMR_Local и dwType=GrdDT_LAN (не забудьте установить GrdFM_Type!!) - т. е. собираемся искать только сетевые ключи - и только локально. После этого вызываем GrdFind для поиска.

3) Если  GrdFind на шаге 2) вернул Ок, то перед нами гарантировано сетевой ключ (метка GrdDT_LAN есть только у сетевых), в этом случае мы:
3а) Вызываем функцию GrdSetFindMode с обязательным параметром dwRemoteMode=GrdFMR_Remote -  т. е. активируем только сетевое GrdAPI, заставляя приложение искать ключ только через сервер сетевого ключа.
3б) Вызываем GrdLogin. Если успех - работаем, если неудача - требуем запустить сервер ключа и работаем

4) Если шаг 2) вернул 1 (ключ не найден), то у нас две возможности - ключ локальный и ключа на этом компьютере нет. Поэтому мы:
4а) Вызываем функцию GrdSetFindMode с обязательным параметром dwRemoteMode=GrdFMR_Local - т. е. активируем только локальное GrdAPI
4б) Вызываем GrdLogin. Если успех - работаем с локальным ключом, если неудача - ключа вообще нет, либо есть сетевой ключ, но на другой машине

5) Если шаг 4) вернул 1 (ключ не найден), то ищем сетевой ключ по сети:
5а) Вызываем функцию GrdSetFindMode с обязательным параметром dwRemoteMode=GrdFMR_Remote -  т. е. активируем только сетевое GrdAPI, заставляя приложение искать ключ только через сервер сетевого ключа.
5б) Вызываем GrdLogin. Если успех - работаем, если неудача - требуем запустить сервер ключа и работаем

Ответ от Serggi

  • Serggi
  • Посетитель
  • Неактивен

Re: Запретить логин к NET-ключу как к локальному

Спасибо Кирилл! Конечно если бы поддерживался локальный тип в наборе флагов для dwType в функции GrdSetFindMode, все бы было значительно проще.

Ответ от Кирилл Ковлежов

  • Кирилл Ковлежов
  • Посетитель
  • Неактивен

Re: Запретить логин к NET-ключу как к локальному

Наличие данного флага не принесло бы никакой практической пользы и носило бы явно дублирующий характер т.к. этот функционал выполняют флаги GrdFMR_XXX.
Примерная схема, приведённая мной выше, успешно используется многими нашими клиентами и её реализация не предполагает мало-мальски значительных временных затрат.

Ответ от Serggi (2012-06-01 12:20:06 отредактировано Serggi)

  • Serggi
  • Посетитель
  • Неактивен

Re: Запретить логин к NET-ключу как к локальному

Кирилл Ковлежов пишет:

Наличие данного флага не принесло бы никакой практической пользы и носило бы явно дублирующий характер т.к. этот функционал выполняют флаги GrdFMR_XXX

Вот не понял этого утверждения, тогда объясните, почему при использовании в маске единственного флага GrdFMR_Local возможен к ключу типа NET, если он установлен на данном компьютере? Собственно это и есть источник проблем. Если бы этого не было, то никакие схемы не были бы нужны.

Ответ от Кирилл Ковлежов

  • Кирилл Ковлежов
  • Посетитель
  • Неактивен

Re: Запретить логин к NET-ключу как к локальному

Ключ NET является полным аналогом локального ключа с возможностью сетевого лицензирования. При этом никто и ничто его локальных свойств и возможностей не отменяет, в том числе и возможность login`а на него, как на локальный.

Ответ от Serggi

  • Serggi
  • Посетитель
  • Неактивен

Re: Запретить логин к NET-ключу как к локальному

Если бы существовал аналог флага GrdDT_LAN, но с признаком локального ключа, то только настройкой через GrdSetFindMode мы бы отсекли возможность логина к NET-ключу, которая нежелательна в нашем случае.

Ответ от AndreyStepin

  • AndreyStepin
  • Техническая поддержка
  • Неактивен

Re: Запретить логин к NET-ключу как к локальному

Serggi пишет:

Если бы существовал аналог флага GrdDT_LAN, но с признаком локального ключа, то только настройкой через GrdSetFindMode мы бы отсекли возможность логина к NET-ключу, которая нежелательна в нашем случае.

Такой флаг сильно осложнил бы использование флагов GrdDT именно потому, что любой сетевой ключ как подмножество включает в себя все возможности локального. Т.е. гипотетический флаг GrdDT_LOCAL обозначал бы не какую то возможность ключа, а ее отсутствие (GrdDT_LAN). Это противоречит смыслу параметра флагов.

Т.е. если вы хотите найти все ключи "сетевые но используемые локально" то это можно достичь только описанной выше комбинацией флагов GrdDT и GrdFMR. Объединить эти флаги в одном параметре было бы очень вредно по многим причинам.

Ответ от Serggi

  • Serggi
  • Посетитель
  • Неактивен

Re: Запретить логин к NET-ключу как к локальному

Программировать схему, которую описал Кирилл в сообщении №2, совсем не хочется. Переставить последовательность поиска, как я писал в сообщении №1, тоже вызовет массу недовольства у владельцев реальных локальных ключей. В итоге мы дарим незапланированный ресурс.  А ситуация, видимо, совершенно стандартная для большинства разработчиков.

Ответ от igev (2013-09-27 11:47:07 отредактировано igev)

  • igev
  • Посетитель
  • Неактивен

Re: Запретить логин к NET-ключу как к локальному

Попробовал реализовать предложенный в сообщении 2 алгоритм, но почему-то даже локальный ключ Sign определяет как сетевой,
т.е. флаг GrdDT_LAN при поиске ключа не фильтрует ключи. Использую API 6.0, сервер 5.5.0.10.

Обращение к ключу делаю со следующими параметрами:
nRet =  GrdSetFindMode( hGrd, GrdFMR_Local, GrdFM_NProg, dwProgV-CryptPG, 0, 0, 0, 0, GrdDT_LAN, GrdFMM_Sign, GrdFMI_USB );
dwID = 0;
nRet = GrdFind( hGrd, GrdF_First, &dwID, &GrdFindInfo );

Пока решил данную проблему проверкой флага GrdDT_LAN уже у найденного локального ключа и т.п. Тут все работает.

P.S. Нестабильно проходит проверка на наличие сетевого ключа. То находит его, то нет.
На сервере - таймаут блокировки ключа поставил в 5 сек, отправки и получения данных по 30 сек.
На клиенте - поднял значения RECONNECT_TRY_NUMBER = 5, TO_SEARCH = 10, TO_RECEIVE = 30.
Не помогло.

Ответ от Антон Тихиенко

  • Антон Тихиенко
  • Администратор
  • Неактивен

Re: Запретить логин к NET-ключу как к локальному

Здравствуйте.

igev пишет:

nRet =  GrdSetFindMode( hGrd, GrdFMR_Local, GrdFM_NProg, dwProgV-CryptPG, 0, 0, 0, 0, GrdDT_LAN, GrdFMM_Sign, GrdFMI_USB );

Для того, чтобы при поиске учитывались флаги типов ключей (GrdDT_LAN, GrdDT_Time, GrdDT_GSII64 и др.) нужно в качестве параметра dwFlags, функции GrdSetFindMode, передавать соответствующее значение - GrdFM_Type - разрешающее учитывать при поиске параметр dwType.

Таким образом, вызов функции GrdSetFindMode, должен производится со следующими параметрами:
( hGrd, GrdFMR_Local, GrdFM_NProg + GrdFM_Type, dwProgV-CryptPG, 0, 0, 0, 0, GrdDT_LAN, GrdFMM_Sign, GrdFMI_USB ).

Что же касается поиска и проверки сетевого ключа, то в подавляющем большинстве случаев на стабильность или нестабильность этих операций влияет конкретная среда ЛВС и входящих в ее состав рабочих станций (настройки маршрутизации, доменные политики, средства проактивной защиты (антивирусы, антиспамы, брандмауэры и.тп)).

Для того чтобы однозначно исключить влияние подобных факторов следует проводить тестирование по следующему алгоритму:

1) Взять два ПК полностью отключенных от ЛВС;
2) На одном установить драйвер, подсоединить ключ и запустить сервер Guardant Net, а на другом установить защищенное приложение;
3) Соединить данные две машины, прямым (без использования хабов или маршрутизаторов), кроссовым патчкордом;
4) Вручную настроить стандартную (вида: 192.168.x.x) подсеть между данными компьютерами;
5) Выключить абсолютно все средства проактивной защиты запущенные на обоих компьютерах;
6) Запустить защищенное приложение на ПК-клиенте.

Ответ от igev (2013-10-09 11:39:16 отредактировано igev)

  • igev
  • Посетитель
  • Неактивен

Re: Запретить логин к NET-ключу как к локальному

Спасибо, Антон!

Про "(не забудьте установить GrdFM_Type!!)" читал в начале топика, но не понял тогда, куда прописать.
Сейчас все работает. Но... Проверка идет медленно, т.к. последовательно производится поиск разных ключей
с заметной задержкой (при отсутствии искомого ключа).
"Хоть три версии делай, чтобы без задержки проверяли локальный и 2 вида сетевых ключей..."

> Что же касается поиска и проверки сетевого ключа

Да, тут интересный момент в том, что сервер ключей крутится на той же машине, откуда запускается защищенное
приложение, антивирусник и брэндмауэр выключен. И все равно ключ находится "через раз".
+ к предыдущей проблеме : двукратный поиск сетевого ключа (сначала локального, затем внешнего) приводит к вероятности
подключения к нему уже не "через раз", а еще реже.

P.S. Переход на сервер 6.1.0.370 проблему с нестабильностью подключения к лок.ключу вроде как устранил :)

Ответ от Антон Тихиенко

  • Антон Тихиенко
  • Администратор
  • Неактивен

Re: Запретить логин к NET-ключу как к локальному

Добрый день.

igev пишет:

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

При поиске сетевого ключа действительно допустимы некоторые задержки из-за того, что защищенное приложение посылает широковещательный запрос внутри ЛВС и ожидает ответа от сервера сетевых ключей Guardant Net.

Уточните, пожалуйста, каковы максимальные задержки наблюдаются при поиске ключа защищенным приложением?

Также приложите содержимое конфигурационного файла (gnclient.ini) "проблемного" защищенного приложения.

Ответ от igev

  • igev
  • Посетитель
  • Неактивен

Re: Запретить логин к NET-ключу как к локальному

Антон Тихиенко пишет:

Уточните, пожалуйста, каковы максимальные задержки наблюдаются при поиске ключа защищенным приложением? Также приложите содержимое конфигурационного файла (gnclient.ini) "проблемного" защищенного приложения.

Сейчас, при переходе на сервер 6.1.0.370, заморочки с подсоединением (длинные таймауты, отсутствие коннекта) к ключу исчезли.
Но уже заметили, что при коннекте клиентского приложения с другого компьютера к машине, на которой стоит сервер ключей 6.1,
происходит кратковременная 1-2сек загрузка процессора на сервере ключей до 50% (проц AMD 2.3ГГц, памяти 2Гб),
мышь PS/2 подвисает (в "событиях Windows" пишется, что "Переполнение кольцевого буфера для поступающих данных мыши").

И еще один более критичный момент: запуск GLDS.exe, как сервиса, работает не совсем корректно на WinXP SP2.
1) при включении компьютера сервис стартует как надо, автоматом (в настройке службы указан тип запуска "авто").
2) если же зайти пользователем, затем выйти ("завершить сеанс") и снова зайти, сервер обнаруживается в выключенном состоянии.
(в "событиях Windows" пишется, что "Служба "Guardant dongle licensing system" перешла в состояние Остановлена).
Вот с этим что-то нужно делать, при входе-выходе пользователей на сервере служба не должна рестартовать или останавливаться.

Ответ от Антон Тихиенко

  • Антон Тихиенко
  • Администратор
  • Неактивен

Re: Запретить логин к NET-ключу как к локальному

Здравствуйте.

igev пишет:

Но уже заметили, что при коннекте клиентского приложения с другого компьютера к машине, на которой стоит сервер ключей 6.1,
происходит кратковременная 1-2сек загрузка процессора на сервере ключей до 50% (проц AMD 2.3ГГц, памяти 2Гб),
мышь PS/2 подвисает (в "событиях Windows" пишется, что "Переполнение кольцевого буфера для поступающих данных мыши").

Загрузка процессора и задержки до некоторой степени связаны с системой защиты ключа: Guardant API защищено псевдокодом Guardant, он замедляет код примерно на 3 порядка, но аналогично затрудняет анализ и реверс-инжиниринг.

igev пишет:

И еще один более критичный момент: запуск GLDS.exe, как сервиса, работает не совсем корректно на WinXP SP2.
1) при включении компьютера сервис стартует как надо, автоматом (в настройке службы указан тип запуска "авто").
2) если же зайти пользователем, затем выйти ("завершить сеанс") и снова зайти, сервер обнаруживается в выключенном состоянии.
(в "событиях Windows" пишется, что "Служба "Guardant dongle licensing system" перешла в состояние Остановлена).
Вот с этим что-то нужно делать, при входе-выходе пользователей на сервере служба не должна рестартовать или останавливаться.

Указанное поведение воспроизводится и для Windows XP SP3. Информация передана разработчикам.