Защита клиента от копирования

[KIV]

Добрый день!

Недавно задались вот каким вопросом: есть сеть в ней много VipNet клиентов и стоят они в других организациях. Есть подозрение, что некоторые Админы этих организации могут взять и скопировать папку Infotecs, принести ее на свой комп, накатить сверху дистрибутив и пользоваться клиентом когда им захочется и откуда захочется. Собственно вопрос: как защитить клиент от переноса при условии, что компы у клиентов админит потенциальный злоумышленник? Я себе представляю только дополнять функционал клиента и админа таким образом, чтобы клиент при установке и подключении к сети предавал уникальные данные об ОС, оборудовании, а администратор сети VipNet мог разрешать доступ к ресурсам только после принятия этой конфигурации.

Еще вопрос и пожелание: у кого какой размер стоит журнала пакетов на интерфейсах HW1000/2000 и как потом работает iplir view? Задавался кто нить вопросом централизованного сбора этих журналов? Еще бы хотелось иметь возможность просматривать историю изменения IP адресов с которых подключались узлы VipNet.

[Xenobius]

Я так понимаю, ключи пользователей на Ваших клиентах записаны на жёсткий диск рабочего места? Если так, то чтобы таких проблем, о которых Вы говорите, не возникало, нужно ключи пользователя хранить на внешних защищенных носителях (eToken, Rutoken, JaCarta и т.д.), находящихся у пользователей, за безопасность которых эти пользователи и отвечают сами. У токена должен быть не стандартный заводской пин-код, ну и так далее, о чём мы все хорошо знаем. Этот порядок вполне естественен с точки зрения безопасности. и, вроде как, должен присутствовать.

По второму вопросу. Если не ошибаюсь, на прошедшем вебинаре Кирилл Пантелеев говорил про размер журнала в 20 Мб, и он очень рекомендовал не менять это значение. По поводу централизованного сбора журналов может быть ViPNet StateWatcher сможет чем-то помочь?

[Vintik]

Согласен с Xenobius, на счёт отдельных носителей, если всё так плохо, ну или хотя бы не хранить пароли на рабочем столе в файле txt пользователям. Т.е. как не крути, а пока самих пользователей не обучите (или не заставите) серьёзно относиться и выполнять ОРД, то всё будет безрезультатно. Если есть даже мысль о таких администраторах, которые могут нагадить, то это совсем плохо дело у вас. В таком случае надо реально разделять админов безопасности и просто админов и чтоб они пиво ещё не пили вместе :-) \ Т.е. это практически не реально же в нашей стране. Ну и с другой строну пусть пользуются где им хочется и можется, трафик то будет защищён, а работа выполняться - не это ли главное? Да и кому нужен дома ваш випнет... другое дело реальный зловред - тут да, тут совсем другой разговор.\

И так рассматривает модель угроз и что там у вас с моделью нарушителя прописано? Местные админы, уволенные, не довольные.... есть такое. Исключить 100% не реально, уменьшить риски - да. Как предложено выше, внешние носитили, при конце раб. дня, сдаются как и ключи. Второе, выполнять что у вас там ещё написано, ограничение по времени и смена пароля в сроки (т..е не как поставили так и забыли, а регулярно, раз в 60-90 дней, идёт смена пароля.. при этом пользователь может даже и не знать этот пароль т.к. АБ его генерирует, записывает на ключ, а в випнете (ну то что там права не полные я уже молчу, у вас же так да?) он ставит обязательную аутентификацию с сохранением хэша в ОС и это буден не ослабление ПБ (типа как так в хэше..) т.к. контейнер на ключе и не извлекаемый ещё он. Потому пользователь имеет только пин (хоть 1234 пофиг уже какой, т.к. за ключ он отвечает) а там уже пароль хоть в 256 символов.)

Ну и пусть будет третье, на координаторе вы пишите безумные правила, чтоб он разрешал работать с такого то ID и IP и если даже потом я подключусь как то завладев всем, то связка ID и IP уже будет точно не как в вашей выделенной ДЛЗ и координатор будет всё отвергать. Ну и там как не будь себе тревогу настроите на такого рода события, как вам подсказали  ViPNet StateWatcher в помощь.

 

\ Вопчем это полное безумие. проще сделать рубильник, РАЗ и у всех загораются красные кнопки))) кто не успеет нажать 5-10 секунд, того отрубают от всего )))\

[KIV]

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

По поводу использования StateWatcher я правильно понимаю, что нужно для каждого клиента покупать лицензию на мониторинг?

[Xenobius]

Понимаете, раз админы могут токены домой унести - нужно в любом случае вводить жёсткие организационные меры по предотвращению этого. Вводить нормативные документы, регламентирующие порядок использования ПОЛЬЗОВАТЕЛЯМИ средств криптозащиты. Чтобы именно пользователь нёс персональную ответственность за сохранность средств криптозащиты, которые они используют. За то, чтобы не было несанкционированного доступа посторонних к этим средствам. Обозначить ответственность админов за несанкционированный доступ. Даже если есть мнение, что перенос ответственности не выход. Это нужно сделать всё равно. Статьи 272-274 УК РФ никто не отменял. И в первую очередь нужно повышать осведомлённость пользователей. Да, необходимы было сообщить пин-код токена, или пароль от сетевого узла. Дык пусть пользователь сменит его, после того как админ закончит свою работу! Это большая, и пожалуй, самая сложная часть специалиста (администратора) по информационной безопасности - сделать так, что пользователя СКЗИ исполняли требования. А вообще сложная задача - чтобы они исполняли эти требования не потому, что их накажут, а потому что так просто нужно делать. В нашем деле без организационных мер - просто никуда.

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

Да, StateWatcher лицензируется по количеству мониторируемых узлов.

[kpys]

3 часа назад, Xenobius сказал:

Да, необходимы было сообщить пин-код токена, или пароль от сетевого узла. Дык пусть пользователь сменит его, после того как админ закончит свою работу!

<irony>Кто по Вашему будет менять этот пароль в "районе"?</irony>

Админы могут накосячить и не умышленно. Например, звучат рациональные предложения поставить ViPNet Client сразу на 3 компа (через копирование папки с 1-ого). Хорошо бы добавить этот функционал:

В 4/15/2017в04:59, KIV сказал:

дополнять функционал клиента и админа таким образом, чтобы клиент при установке и подключении к сети предавал уникальные данные об ОС, оборудовании, а администратор сети VipNet мог разрешать доступ к ресурсам только после принятия этой конфигурации.

кстати, будет за что денежку срубить при переустановке

В 4/15/2017в09:55, Xenobius сказал:

Если не ошибаюсь, на прошедшем вебинаре Кирилл Пантелеев говорил про размер журнала в 20 Мб, и он очень рекомендовал не менять это значение.

Кирилл говорил про производительность. imho все упирается в железо и методики работы с логами. На хорошем железе можно и поменять. На HW1000 если выгрузить лог: logs.tar.gz ~ 150 MB в нем файлы лога everything.log, everything.log.1 и т.д., где фалы типа everything.log.1 - по 1 GB. В них есть информация и по сообщениям

Jxx XX 04:30:15 hw1000 iplircfg[xxxxx]: [xx-xx 04:30:15] CIpServer.SendResolveAddr: sending resolve IP address message to XXXXXXXX 
Jxx XX 04:30:15 hw1000 iplircfg[xxxxx]: [xx-xx 04:30:15] CSendQueue.Add: added message type 5 to XXXXXXXX to queue (msg name 'FUXXXXXX.XXX') 
Jxx XX 04:30:15 hw1000 iplircfg[xxxxx]: [xx-xx 04:30:15] CSendQueue.CheckSend: message 3 to XXXXXXXX expired (msg name 'E1XXXXXX.XXX') 

вас устроит, там же и IP есть? Если речь идет о forensic

Jxx xx 04:20:45 hw1000 iplircfg[xxxxx]: [xx-xx 04:20:45] CIpServer.GetMessage: read 237 bytes from 10.00.00.XX:2046 
Jxx xx 04:20:45 hw1000 iplircfg[xxxxx]: [xx-xx 04:20:45] CMsgMonChannel.CopyFrom: got COMPRESSED message 
Jxx xx 04:20:45 hw1000 iplircfg[xxxxx]: [xx-xx 04:20:45] CIpServer.ProcessMonChannel: got message: type 1 from ID XXXXXXXX (msg name 'TXXXXXXX.XXX') 
Jxx xx 04:20:45 hw1000 iplircfg[xxxxx]: [xx-xx 04:20:45] CIpServer.ProcessMonChannel: last recv time for XXXXXXXX is 145XXXXXXX 
Jxx xx 04:20:45 hw1000 iplircfg[xxxxx]: [xx-xx 04:20:45] CIpServer.ProcessMonChannel: register forward id XXXXXXXX for XXXXXXXX 
Jxx xx 04:20:45 hw1000 iplircfg[xxxxx]: [xx-xx 04:20:45] CIpServer.ProcessMonChannel: message will need reply 
Jxx xx 04:20:45 hw1000 iplircfg[xxxxx]: [xx-xx 04:20:45] CIpServer.ProcessMonChannel: processing incoming ID list (size 1) 
Jxx xx 04:20:45 hw1000 iplircfg[xxxxx]: [xx-xx 04:20:45] CIpServer.ProcessWSList: Save SSRO info for ID 0xXXXXXXXX: OS ver 'hw1000 ( Linux X.X.XX i686 )' 
Jxx xx 04:20:45 hw1000 iplircfg[xxxxx]: [xx-xx 04:20:45] CIpServer.ProcessWSList: received info about XXXXXXXX 
Jxx xx 04:20:45 hw1000 iplircfg[xxxxx]: [xx-xx 04:20:45] CIpServer.ProcessWSList: received natsettings: firewallIp 95.00.00.XX, port 55777, proxyid FFFFFFFE, timeout 0 
Jxx xx 04:20:45 hw1000 iplircfg[xxxxx]: [xx-xx 04:20:45] CIpServer.ProcessMonChannel: message still needs reply, sending 
Jxx xx 04:20:45 hw1000 iplircfg[xxxxx]: [xx-xx 04:20:45] CIpServer.SendMessage: sending COMPRESSED message (type 7, len 202, name 'TKZRFNBK.XZT') to XXXXXXXX ip 10.00.00.XX (Station version 3.0-670) 
Jxx xx 04:20:45 hw1000 iplircfg[xxxxx]: [xx-xx 04:20:45] CIpServer.SendMessage: last sendtime for XXXXXXXX is 145XXXXXXX