Всем спасибо!!! Нужно было мнение людей в теме! Создалась полная картина че да как сделать, шоб лучше. Жаль только, что программулину привязывающую никто так и не посоветовал. Вот WINlicence распробовал только что — вроде то, что надо. Содает лицензию, привязанную к железу. осталось догадаться, как поставить на поток заворачивание клиентских версий — каждому свою с соответствующим ему Hardware ID!

ribentrop79 wrote:

> Всем спасибо!!! Нужно было мнение людей в теме! Создалась полная картина
> че да как сделать, шоб лучше. Жаль только, что программулину
> привязывающую никто так и не посоветовал. Вот WINlicence распробовал
> только что — вроде то, что надо. Содает лицензию, привязанную к железу.
> осталось догадаться, как поставить на поток заворачивание клиентских
> версий — каждому свою с соответствующим ему Hardware ID!
Так ты ничего и не понял.
Сказали ведь — нафиг тебе hardware? У тебя есть сервер, а у него клиенты — вот и ограничивай клиентов, выдавай им
логины/пароли (или сертификаты). А передачу клиентами своих идентификационных данных — отслеживать (по статистике числа
орбащений, по ip-адресам и прочее) и отстреливать банами/штрафами.

Понятно...

Исходя из технических реалий (нефиксированный IP, нерпименимость WEB) и коммерческих требований , вот на чем вроде как остановилось (слова из типа как отчета):

...Для увеличения трудоемкости реализации угрозы копирования полагаем эффективным попеременное использование нескольких ASProtect-подобных продуктов (протекторы кода) .Проведен анализ рынка ASProtect-подобного ПО для привязки «клиента» к клиенту. Некоторые из них (WINlicence, PC Guard (??) ) дополнительно позволят обеспечить привязку «клиента» к клиенту своими собственными средствами...

...В настоящее время силами программеров осуществляется реализация процедуры обмена сеансовыми ключами между клиентом и сервером. Это позволит выявлять более оперативно выявлять случаи несанкц.копирования и предотвратит , тем самым, постановку этого процесса на поток...


...В настоящее время прорабатывается вопрос использования HARDWARE-ключей… Это позволит…

...Реализация всех этих мер не будет иметь должного эффекта, если не принять надлежащих организационных мер. ( разъяснить, ввести ответственность, напугать штрафом(??) )...

===============

Вообще, конечно, все черезжописто получается, не как у людей...

Здравствуйте, Аноним, Вы писали:


А>3) если клиент соглашается на фикс-IP то логин-пароль прошиты (можно его защитить серийником тома харда) и никто не напрягается

Это я, так понимаю, опция провайдера, оговаривающаяся при выборе схемы подключения? Это зависит от технических озможностей конкретного провайдера? А насколько накладнее?

А>4) не давать одинаковым аккаунтам работать одновременно (кто последний тот и папа, с сообщением отрубаемому что его послали с такого то IP)

ну это вроде ж разновидность тех ж сеансовиков... нет?

А>5) отслеживание перескоков (например пол часа один IP потом другой, потом опять первый... (точнее — подсети)

Наскольуо я понимаю, отслеживание по подсетям — мера не очень сильная. Так, скорее как факультативная. Зависит от того, насколько трудоемкой проблемой является получение злоумышленником IP адреса той же подсети..

Интересно было бы узнать, насколько тут трудоемка была бы подмена/эмуляция IP адреса...

А>6) к аппаратуре привязываться можно, но или в виде хорошо сделанного (типа хардлок) или совсем простого (типа привязка к серийнику тома харда)

думаем

Здравствуйте, ribentrop79, Вы писали:

R>Здравствуйте, Аноним, Вы писали:


А>>3) если клиент соглашается на фикс-IP то логин-пароль прошиты (можно его защитить серийником тома харда) и никто не напрягается

R>Это я, так понимаю, опция провайдера, оговаривающаяся при выборе схемы подключения? Это зависит от технических озможностей конкретного провайдера? А насколько накладнее?

У нас в Саратове — порядка 30 руб/мес

Здравствуйте, ribentrop79, Вы писали:

R>Здравствуйте, Аноним, Вы писали:


А>>3) если клиент соглашается на фикс-IP то логин-пароль прошиты (можно его защитить серийником тома харда) и никто не напрягается

R>Это я, так понимаю, опция провайдера, оговаривающаяся при выборе схемы подключения? Это зависит от технических озможностей конкретного провайдера? А насколько накладнее?

В общем да, фиксированный IP это опция провайдера, иногда за деньги, иногда единственно-возможное, иногда недоступное вообще

А>>4) не давать одинаковым аккаунтам работать одновременно (кто последний тот и папа, с сообщением отрубаемому что его послали с такого то IP)

R>ну это вроде ж разновидность тех ж сеансовиков... нет?

о сеансовых ключах принято говорить как о временном ключе для текущей сессии, сгенерированной в процессе идентификации/аутентификации, я говорил о запрете двух одновременных сессий, идентифицированных как одна учетная запись (читай — клиент)

А>>5) отслеживание перескоков (например пол часа один IP потом другой, потом опять первый... (точнее — подсети)

R>Наскольуо я понимаю, отслеживание по подсетям — мера не очень сильная. Так, скорее как факультативная. Зависит от того, насколько трудоемкой проблемой является получение злоумышленником IP адреса той же подсети..

Блин! Ну все разжевать... В случае фиксированного IP — отслеживать IP, если адреса динамические — смотреть конкретно по ситуации, главное тут — набирать статистику, например если адрес меняется раз в пять минут между двумя IP в течение рабочего дня — то подозрительно..., если нерегулярно три раза в день размазанно по подсети провайдера (кстати, в договоре прописывать провайдера подписчика — их раз в день не меняют) — то может и нет. Вообще, такие методики (в том числе) используют для предотвращения фрода по кредиткам (преставляете, покупка в США а через 15 минут в России).
И нужно определиться с потенциальными источниками атак (внутренние, внешние, недобросовестные клиенты, сторонние организации...)


R>Интересно было бы узнать, насколько тут трудоемка была бы подмена/эмуляция IP адреса...
В локальной сети — не проблема, всякие диалапы включая adsl — уже труднее

А>>6) к аппаратуре привязываться можно, но или в виде хорошо сделанного (типа хардлок) или совсем простого (типа привязка к серийнику тома харда)

R>думаем

Вообще чтоб выполнить вашу работу нужно (грубо):
1) провести анализ угроз с точки зрения бизнеса (классификация)
2) провести анализ этих угроз с точки зрения реализации атак (синтез)
3) выработать и классифицировать методы противодействия и мониторинга
4) передать на реализацию соответствующим подразделениям (юристам, программистам, службе безопасности итп)
5) тщательно наблюдать в процессе опытной эксплуатации

А так, читая это ваше все, создается ощущение что объемную задачку дали стажеру (ну, стажеру от этого может и неплохо, опыта набирается, а вот задача решается медленно, дорого и неэффективно) — без обид.

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

Здравствуйте, ribentrop79, Вы писали:

R>Исходя из технических реалий (нефиксированный IP, нерпименимость WEB) и коммерческих требований , вот на чем вроде как остановилось (слова из типа как отчета):

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

Здравствуйте, Аноним, Вы писали:

R>>Здравствуйте, Аноним, Вы писали:

А>А так, читая это ваше все, создается ощущение что объемную задачку дали стажеру (ну, стажеру от этого может и неплохо, опыта набирается, а вот задача решается медленно, дорого и неэффективно) — без обид.

Ну отчасти так Отчасти потому что вроде как стажеру и мне и правда было интересно со всем этим разбираться. Но мне ее не дали, а подкючили к ней. А задачка в то же время решается уже давно! Вчера разговаривал с руководством и программером, который ведет эту систему на протяжении 3-4 лет уже! Создалось впечатление, что правая рука не знает, что делает левая, и что не хватает административных рычагов, чтобы внедрить то, что уже давным-давно придумано, продумано и способно защитить, исходя из угроз, коммерческих требований, маркетинга и проч…

Далее читать, если зубрам действительно интересно


Нижеследующие шаги уже давно были проделаны:

А>1) провести анализ угроз с точки зрения бизнеса (классификация)
А>2) провести анализ этих угроз с точки зрения реализации атак (синтез)
А>3) выработать и классифицировать методы противодействия и мониторинга
А>4) передать на реализацию соответствующим подразделениям (юристам, программистам, службе безопасности и т.п.)
А>5) тщательно наблюдать в процессе опытной эксплуатации.


Сначала немного по деталям:

R>>Насколько я понимаю, отслеживание по подсетям — мера не очень сильная. Так, скорее как факультативная. Зависит от того, насколько трудоемкой проблемой является получение злоумышленником IP адреса той же подсети..

А>Блин! Ну все разжевать... В случае фиксированного IP — отслеживать IP, если адреса динамические — смотреть конкретно по ситуации, главное тут — набирать статистику, например если адрес меняется раз в пять минут между двумя IP в течение рабочего дня — то подозрительно..., если нерегулярно три раза в день размазано по подсети провайдера (кстати, в договоре прописывать провайдера подписчика — их раз в день не меняют) — то может и нет.

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

А> Вообще, такие методики (в том числе) используют для предотвращения фрода по кредиткам (преставляете, покупка в США а через 15 минут в России).

Представляю. Нечто подобное происходит, наверное, когда лезешь на порносайт со спи…ным паролем, а он тебе говорит, что слишком много таких умников по всему миру с таким аккаунтом.



Ну так вот, возвращаясь к задаче…

Ее специфика такая. Опасность представляет не отдельно стянутый прайсик, а постановка этого дела на поток у многих клиентов сразу! Ибо, как уже здесь писалось, клиентов много, у каждого свой прайс, свои скидки. Вот составление конкурентом всей этой полной картины и представляет опасность. Для этого, к примеру, из 10000 клиентов нужно получать прайсы 2000.

Какие шаги предложил вышеупомянутый программер. Перечислены в порядке необходимости внедрения:

1. Обязательно сеансовики! Процедура сеансовиков породит многочисленные коллизии обращения к серверу с последующим отрубанием клиента или злоумышленника. На такое, по его словам, они не пойдут, ибо это может остановить всю систему, а это как бы несимметричный удар со всеми последствиями, ибо то же делаем потом мы, рушим их систему, а потом можно еще подключить органы и прочее…

2. По определению, клиентская программка защищена/зашифрована, инсталлер привязывает клиента/его ключ к его компу. Используется ключик, завязанный на параметры компа. Но, как показала жизнь, это конкуренты отламывают. Решение такое: а) менять алгоритм образования ключа в новых версиях клиента, что совсем не сложно. А вариантов генерации ключа уйма. Не сложна и процедура обновления клиента с сервера. б) Менять алгоритм шифрования этим ключом, что тоже не трудоемко.

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

Практика может показать, что и первого шага будет достаточно… Если же нет, то самое главное, чтобы время на преодоление/взлом вышеуказанных схем защиты 2 и 3 было бы велико по сравнению с временем между сменой сеансовиков, после чего они уже не сунуться. Вот такая понятая мной логическая цепочка. Защита целиком программными средствами.

И следующие меры становятся не нужны:

-фиксированный IP (соответственно и подмена IP отпадает)
-хардлоки (к тому же при количестве клиентов в несколько тысяч – накладно)

Только достучаться до нужных людей не получается, чтобы инициировать все эти шаги – слишком недоступны эти люди. Вот вчера решили потратить деньги на консалтинг сторонний… Будут нам советовать, как защищаться…

Предыдущий пост — мой!

А>> Вообще, такие методики (в том числе) используют для предотвращения фрода по кредиткам (преставляете, покупка в США а через 15 минут в России).

А>Представляю. Нечто подобное происходит, наверное, когда лезешь на порносайт со спи…ным паролем, а он тебе говорит, что слишком много таких умников по всему миру с таким аккаунтом.

Понятно куда ходите в свободное время...



А>Ну так вот, возвращаясь к задаче…

А>Ее специфика такая. Опасность представляет не отдельно стянутый прайсик, а постановка этого дела на поток у многих клиентов сразу! Ибо, как уже здесь писалось, клиентов много, у каждого свой прайс, свои скидки. Вот составление конкурентом всей этой полной картины и представляет опасность. Для этого, к примеру, из 10000 клиентов нужно получать прайсы 2000.


Это я примерно понял, но от этого не избавится, увы... Бормана помните? Если знают двое...
Обычно продавцы (эээ, заинтересованные люди в торгующих организациях) стараются не светить закупочные цены (как минимум чтоб не светить навар). Если кому-то нужна картина, то за эн рублей можно попросить бабу Маню распечатать прайс поставщика (отксерить, итп) и вынести с черного входа милому пареньку в жигулях... Это если будет сложно влезть электронно.


А>Какие шаги предложил вышеупомянутый программер. Перечислены в порядке необходимости внедрения:

А>1. Обязательно сеансовики! Процедура сеансовиков породит многочисленные коллизии обращения к серверу с последующим отрубанием клиента или злоумышленника. На такое, по его словам, они не пойдут, ибо это может остановить всю систему, а это как бы несимметричный удар со всеми последствиями, ибо то же делаем потом мы, рушим их систему, а потом можно еще подключить органы и прочее…

добавьте просто передачу набора локальных данных компа (мак адрес, список айпи, список драйвов и метки томов хардов, модель материнки и видюшки, размер памяти, точную версию винды...) , т.е. первый запуск — просто передача, далее сравнение и анализ на предмет "фрода". Разрешение работы только одного UserID. При высокой вероятности "нелегала" — навязывать дезу.

А>2. По определению, клиентская программка защищена/зашифрована, инсталлер привязывает клиента/его ключ к его компу. Используется ключик, завязанный на параметры компа. Но, как показала жизнь, это конкуренты отламывают. Решение такое: а) менять алгоритм образования ключа в новых версиях клиента, что совсем не сложно. А вариантов генерации ключа уйма. Не сложна и процедура обновления клиента с сервера. б) Менять алгоритм шифрования этим ключом, что тоже не трудоемко.

это уже не надо

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

и это уже не надо

А>Практика может показать, что и первого шага будет достаточно… Если же нет, то самое главное, чтобы время на преодоление/взлом вышеуказанных схем защиты 2 и 3 было бы велико по сравнению с временем между сменой сеансовиков, после чего они уже не сунуться. Вот такая понятая мной логическая цепочка. Защита целиком программными средствами.

это верно. а против бабы мани с ксероксом как?

А>И следующие меры становятся не нужны:

А>-фиксированный IP (соответственно и подмена IP отпадает)
А>-хардлоки (к тому же при количестве клиентов в несколько тысяч – накладно)

верно

А>Только достучаться до нужных людей не получается, чтобы инициировать все эти шаги – слишком недоступны эти люди. Вот вчера решили потратить деньги на консалтинг сторонний… Будут нам советовать, как защищаться…

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

А>>Только достучаться до нужных людей не получается, чтобы инициировать все эти шаги – слишком недоступны эти люди. Вот вчера решили потратить деньги на консалтинг сторонний… Будут нам советовать, как защищаться…

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

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

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

Вдвоём на одном аккаунте жить можно будет, но надо будет постоянно таскать эту куку между двумя компьютерами. Если соединания устанавливаются часто, это будет доставать.
Файл с кукой можно лочить на время работы (чтобы надо было останавливать клиента чтобы забрать куку).
Можно сохранять куку где-нибудь у винды в protected storage (опять же, достать всё равно можно, но уже не Far'ом).

Ресинхронизация куки — после трёпа по телефону.
В нерабочее время клиентов не впускать.
Уже писали — не пускать 2 соединения для одного аккаунта одновременно — им придётся договариваться, чтобы аптекарши выключали на время своего клиента. Договориться с 2000 аптекарш тоже непросто.

Куку можно постоянно (раз в 2/5/15 мин менять) — она будет устаревать пока её несут.

Здравствуйте, ribentrop79, Вы писали:

Довольно таки интересно. Простите за нескромный вопрос А у вас вообще есть аналитик по той же безопасности хоть что-то понимающий в защите данных? От доступа копирования и т д? Вы вкурсе как устроены те же электронные магазины Доступ к БД банков. Литературу какую-нибудь используете? Что классическое вам известо о защите информащии. У меня создалось впечатление что Вы пытаетесь решить большую проблему пажарными методами -- так не делается. Возникнут ещё большие проблемы.