Разрабатываете ли вы защиту сервера от угона?

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

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

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

Теперь о билетах, подробнее. Когда сервер запускается, генерирует рандомный идентификатор сессии сервера SSID. Разработчик его получает, и дальше этот SSID используется в качестве ключа для подписи хэша передаваемых на сервер данных (MAC). Сгенерированный MAC подписывается на основе секретного ключа, и эта подпись вместе с исходными данными — передаются на сервер. Сервер получает данные, генерирует тот же самый MAC, и сверяет подпись на основе открытого ключа. В качестве тех самых подписываемых данных разработчик передаёт время начала действия билета, и время окончания действия билета, а также права доступа. Таким образом, не имеет значения, на каком оборудовании запущен сервер, и разработчик может контролировать сколько конкретно времени работает сервер.

О реализации. Подписывать решил ЭЦП на основе эллиптических кривых, алгоритм ECDSA, вот тут вкратце есть толковое описание теории: www.intuit.ru/...​urses/28/28/lecture/20430. Для генерации MAC подписываемых данных использую алгоритм SHA256. Дальше данные склеиваются с подписью, и переводятся в кодировку base64 для удобства передачи на сервер. Вот тут yadi.sk/d/06Ssa9r9sScXH моя реализация генератора билетов на Go, исходный код всего на 320 строк. Вам достаточно только заменить ключи (строки 21-23), и можно использовать. По исходному коду увидите, как можно генерировать и проверять подпись.

Что думаете по этому поводу?

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

детсад какойто. Не усложняйте, хостерам ваши наданные даром не нужны
Если не доверяете — Хостите тогда у себя или на амазоне/азуре где точно ваши данные нафиг не нужны хостеру
Если кто-то хочет потестировать сервак — подымите для них инстанс на котором вы админ и пусть они его тестят-проюют сколько хотят через апи

и научитесь формулировать свои вопросы. Ничего не понятно из поста. Все в одну кучу свалено и в чем проблема — хз

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

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

Да конечно, а ещё лицензионным соглашением с пользователем. «Внимательно прочтите соглашение, если вы не согласны с условием, не продолжайте установку». В общем случае задача сводится к методам защиты софта, я только смотрю мало кто этим вопросом задавался.

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

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

Я смотрел на принцип защиты продуктов Майкрософта, с их 25-буквенными продуктовыми ключами. Такой ключ преобразуется в 114-битное число, в котором только 31 бит используется для формирования подписываемого хэша, и 62 бита — сама подпись. Алгоритм тоже основан на эллиптической кривой. Как видно, длина секретного ключа Майкрософта — всего 31 бит, и именно по этой причине он легко взламывается брутфорсом, перебором всего 32К вариантов. Поскольку в данном случае юзается 256-битный секретный ключ, его врядли пробутфорсят даже на будущих квантовых компьютерах, хотябы по причине количества затраченных на это квант энергии.

Таким образом, посредники, или какие-то третьи лица могут иметь у себя в «кармане» сервер, а работать он будет только с вашей подачи билетов, и причём столько времени и на тех правах, которые указаны в билете.

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

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

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

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

Метод терморектального криптоанализа никто не отменял.

Например у юристов есть такая схема при продаже действующих предприятий:
до просмотра документов — спрашивай — ответим. Базовые документы покажем бесплатно (свидетельства о ригистрации, право собственности). Хочешь смотреть более конкретные документы (конкретные договора, списки и т.д.) — плати 500-1000-3000 баксов и приезжай смотри в нашем офисе в нашем присутсвии. Как они поясняют: это позволяет отсеять всяких деятелей, которые имеют подобные задачи, но не знают с какой стороны начать и почему нужно сделать именно так.

Якщо треба буде — дадуть кулхацкеру Васі 50 баксів і він за дві годинки поламає ваш захист в хлам. Хочете захистити — залийте бетоном.

Як на мене, найкращий захист — офігітельна підтримка, аби крякати було дорожче і геморойніше чим купляти і отримувати кваліфіковану підтримку.

А по темі — Intel AMT + повнодискове шифрування і виконання коду в захищеному контейнері.

Кстати, от пропатчивания я эффективной защиты так и не нашёл, кроме обфускации кода. Но это снижает производительность, да и не надёжно.

Все ламається. Тому краще робити крутий продукт, ніж крутий захист поганенького продукту.

А можно объяснить так, чтобы нам не приходилось применять телепатию? А именно: нарисуй схему, что по звеньям как работает, в какое конкретно звено ты вмешиваешься, и какое конкретно паразитное звено ты так отсекаешь.

Да, я не все нюансы обрисовал в первых 2 предложениях. Типичная схема, где подобная защита нужна такова: есть люди, которые пишут сервер, и есть посредник, который занимается контактами с клиентами, договаривается с ними. Посредник, имея доступ и клиентов, может спокойно захостить сервер в другом месте, или просто послать разработчиков, и ничего не платить. Посредник/менеджмент имеет возможности манипуляции разработчиками, в то время как возможности разработчиков — ограничены.

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

Как правило, за написанием софта ещё есть огромный шлейф правки багов. Свалить в этом случае от программиста — означает освободить его от 90% работы. Так что ему это даже выгодно.

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

Не впевнений що зрозумів про що ви говорите... Чим шифрування жорсткого диску не підходить?

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

в ынтерпрайзе проблема не стоит, надо спросить пхпшников как идейно близких

То есть в интерпрайзе продают только труд, затраченный на разработку, а продавать функционал не хотят.

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

Підписатись на коментарі