История изменений

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

Теперь я объясню почему я плохо реагирую на деление «клиент-сервер». Проблема проста.

Предположим, у Вас есть некое решение, где есть клиент и сервер. Сервер (или серверы) живут в своём ДЦ. И возвращают подписи клиентам, которых ни один и ни два. Всё хорошо, всё как-то, но работает.

Дальше некие уроды-злоумышленники кладут канал на этот ДЦ или на этот сервер (сервера). Банально длительным DDoS. Всё. Звиздец, приехали. Сервера отъехали, канал прилёг. И что, работа всё, встала?

Очевидно, что для данного случая в клиентах должен быть предусмотрена смена ролей, когда какой-то из клиентов берёт на себя функции генерации/возврата подписей и он в этом случае должен сам стать доверенным сервером. Ближайший аналог здесь – перевыборы контроллера домена в виндах. Лёг основной, всё равно найдётся какой-то хост, который будет обеспечивать работу домена.

Можем мы заранее сказать как мы будем резервировать и реализовывать эту возможность? Кто и на основании каких критериев станет доверенным сервером для всей этой сети в случае отказа основных серверов? Нет конечно. Мы эту возможность не рассматриваем изначально. У нас просто и тупо – сервера прилегли, всё, работа кончилась, все по домам. Это называется уязвимость by design. Вот почему я крайне косо смотрю на принятую среди коллег идеологию «клиент-сервер» без оглядки на реалии. Ибо внезапно вечер может перестать быть томным и всё станет грустно и печально.

Тут же ещё до кучи возникает проблема с тем, что в отношении ряда клиентов может быть проведена атака типа DNS cache poison. Т.е., ряд клиентов, которые используют какой-либо общий для них DNS server, вообще могут оказаться в ситуации, когда им навязали вообще левый сервак с обновами и они могут в принципе начать качать обновление не с доверенного сервера, а с фейкового. И что там за обновление они в таком случае скачают, можно только догадываться. Но скажу сразу – ничего хорошего.

Это чисто навскидку и крупными мазками. Сейчас нет плоских, однонаправленных атак. Сейчас есть атаки по разным направлениям и сразу. Я, собственно, вот что пытаюсь объяснить.

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

Здесь, как всегда, два вопроса:

• От чего и от кого мы защищаемся? Если от Василия-the-хаккИра, с gdb наперевес или radare2 с IDA Pro, то хватит в принципе проверки хэша на уровне локального хоста, где функционирует данное приложение. Даже по сети таскать ничего ненадо, изобретая аналоги гуглёвых сервисов для платных андроидных приблуд. У гугля это тоже не получилось, да они и в курсе почему не получится (как только мы перестаём контролировать корень доверия, при чём похрен на сервере или на клиенте, мы приплыли).

Если от ребятишек, которые в курсах поверхностей атаки для того же TEE/TrustZone/Intel SGX, то я Вас просто умоляю – не тратьте время. =))) «Защита» всегда будет отставать от «атаки» и служить только временной мерой. И её постоянно нужно будет менять и апгрейдить. Т.е., программисты начнут заниматься не наращиванием функционального наполнения приложения, а реализацией всё более хитро вые… реализованных алгоритмов защиты.

• Какова реальная стоимость защищаемой информации? В ряде случаев просто создают два информационных контура. Один для использования публичных сетей, с ним всё ясно. И другой, ни как не пересекающийся с первым даже на уровне инфраструктурного оборудования и каналов передачи данных, до немогусеньки герметичный, короче. И нет, там даже usb-флешку без «контроля» не вставишь. Чужие там не ходят в принципе.

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

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

Повторю ещё раз. Любая защита, это как замок. Она от честных людей. Хотите защиты? Реализуйте её на базе комплекса мероприятий. И организационных в том числе.

Ну или не майтесь фигнёй. Тоже вариант. ;)

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

Теперь я объясню почему я плохо реагирую на деление «клиент-сервер». Проблема проста.

Предположим, у Вас есть некое решение, где есть клиент и сервер. Сервер (или серверы) живут в своём ДЦ. И возвращают подписи клиентам, которых ни один и ни два. Всё хорошо, всё как-то, но работает.

Дальше некие уроды-злоумышленники кладут канал на этот ДЦ или на этот сервер (сервера). Банально длительным DDoS. Всё. Звиздец, приехали. Сервера отъехали, канал прилёг. И что, работа всё, встала?

Очевидно, что для данного случая в клиентах должен быть предусмотрена смена ролей, когда какой-то из клиентов берёт на себя функции генерации/возврата подписей и он в этом случае должен сам стать доверенным сервером. Ближайший аналог здесь – перевыборы контроллера домена в виндах. Лёг основной, всё равно найдётся какой-то хост, который будет обеспечивать работу домена.

Можем мы заранее сказать как мы будем резервировать и реализовывать эту возможность? Кто и на основании каких критериев станет доверенным сервером для всей этой сети в случае отказа основных серверов? Нет конечно. Мы эту возможность не рассматриваем изначально. У нас просто и тупо – сервера прилегли, всё, работа кончилась, все по домам. Это называется уязвимость by design. Вот почему я крайне косо смотрю на принятую среди коллег идеологию «клиент-сервер» без оглядки на реалии. Ибо внезапно вечер может перестать быть томным и всё станет грустно и печально.

Тут же ещё до кучи возникает проблема с тем, что в отношении ряда клиентов может быть проведена атака типа DNS cache poison. Т.е., ряд клиентов, которые используют какой-либо общий для них DNS server, вообще могут оказаться в ситуации, когда им навязали вообще левый сервак с обновами и они могут в принципе начать качать обновление не с доверенного сервера, а с фейкового. И что там за обновление они в таком случае скачают, можно только догадываться. Но скажу сразу – ничего хорошего.

Это чисто навскидку и крупными мазками. Сейчас нет плоских, однонаправленных атак. Сейчас есть атаки по разным направлениям и сразу. Я, собственно, вот что пытаюсь объяснить.

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

Здесь, как всегда, два вопроса:

• От чего и от кого мы защищаемся? Если от Василия-the-хаккИра, с gdb наперевес или radare2 с IDA Pro, то хватит в принципе проверки хэша на уровне локального хоста, где функционирует данное приложение. Даже по сети таскать ничего ненадо, изобретая аналоги гуглёвых сервисов для платных андроидных приблуд. У гугля это тоже не получилось, да они и в курсе почему не получится (как только мы перестаём контролировать корень доверия, при чём похрен на сервере или на клиенте, мы приплыли).

Если от ребятишек, которые в курсах поверхностей атаки для того же TEE/TrustZone/Intel SGX, то я Вас просто умоляю – не тратьте время. =))) «Защита» всегда будет отставать от «атаки» и служить только временной мерой. И её постоянно нужно будет менять и апгрейдить. Т.е., программисты начнут заниматься не наращиванием функционального наполнения приложения, а реализацией всё более хитро вые… реализованных алгоритмов защиты.

• Какова реальная стоимость защищаемой информации? В ряде случаев просто создают два информационных контура. Один для использования публичных сетей, с ним всё ясно. И другой, ни как не пересекающийся с первым даже на уровне инфраструктурного оборудования и каналов передачи данных, до немогусеньки герметичный, короче. И нет, там даже usb-флешку без «контроля» не вставишь. Чужие там не ходят в принципе.

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

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

Повторю ещё раз. Любая защита, это как замок. Она от честных людей.