| 1.2, Аноним (2), 15:22, 08/05/2019 [ответить] [﹢﹢﹢] [ · · · ] [↓] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| –2 +/– | |
> В случае применения цифровых подписей получение контроля над сервером распространения обновлений не приведёт к компрометации пользовательских систем, так как для проведения атаки дополнительно понадобиться получить отдельно хранящийся закрытый ключ, при помощи которого осуществляется подпись обновлений.
Как это реализуется?
Если взломать инфраструктуру и послать хеш архива с бекдором на подпись, то юзеры также получат такое обновление.
| | |
| |
| |
| |
| 4.12, Ключевский (?), 18:04, 08/05/2019 [^] [^^] [^^^] [ответить] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +5 +/– |
Могу рассказать как это реализовано у меня.
У меня есть репозиторий с пакетами для неких проектов.
Есть виртуалка на которой все собирается, эта виртуалка не имеет выхода в инет, он ей просто не сделан, ее никто туда не пустит. Она получает все свои обновления c одного из двух серверов в локалке к которым может обращаться(там у меня apt-cacher-ng обслуживающий всю локалку), с него же она получает исходники того, что должна собирать. Виртуалка включается только на время, когда ей нужно собрать пакеты, собирает их и выгружает на сервер с репозиторием внутри локалки(а это вторая точка с которой она может общаться по сети, все остальное ей запрещено). Из тестового репозитория на этом сервере тестовые виртуалки ставят все к себе и тестируют обнову, если все нормально, то пакеты переносятся в основной репозиторий в локалке, к которому по VPN имеют доступ все сервера и с которого они накатывают обновления.
В принципе так же можно организовать и работу публичного репозитория, убрать часть с VPN для доступа просто.
Если ты сможешь как-то получить ключ которым моя сборочная виртуалка подписывает пакеты, то ты тот еще волшебник. Да, физический доступ к серверу где она живет не поможет, так как ее LVM закриптован и когда она погашена хоть ты тресни, но данные ты оттуда не получишь.
При этом я всего лишь фрилансер, который обслуживает совершенно рядовые проекты. Я не особо продумывал систему безопасности, сделал первую пришедшую в голову схему. При желании можно продумать и более безопасную. Главное это хранение приватных ключей в заведомо недоступном для злоумышленника месте, каковым безусловно является изолированная от внешнего мира виртуалка.
| | |
| |
| |
| 6.19, Онаним (?), 21:06, 08/05/2019 [^] [^^] [^^^] [ответить] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +/– |
Тем, что получив доступ к файловому хранилищу репозитория, любой школьник может залить туда свой "контент".
Сервер подписей на то и сервер подписей, что он отделён от основной инфраструктуры.
| | |
| 6.20, Аноним (20), 22:00, 08/05/2019 [^] [^^] [^^^] [ответить] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +1 +/– | |
Онаним верно глаголит, что по всем стандартам сервер подписывающий должен быть отделен, а товарищ выше очень правильно описал пример своей инфраструктуры, хотя мне кажется, что для фрилансера админящего несколько мелких проектов он слишком заморочился, но все сделал идеологически верно.
Сервер собирающий и подписывающий должен быть изолирован полностью на случай взлома сервера раздающего, они не должны даже знать друг о друге, все через посредника и сервер собирающий должен быть недоступен при взломе сервера раздающего, что бы не впарили людям левые пакеты и что бы при взломе можно было быстрым движением вернуть правильные пакеты взад, сразу после перестановке сервера раздающего(перестановка, так как взломанный сервер считается скомпроментированным и подлежит только чистой перестановке)
| | |
|
| |
| 6.32, Ключевский (?), 15:19, 09/05/2019 [^] [^^] [^^^] [ответить] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +1 +/– |
Да я просто считаю это нормой. У меня так было давным давно в офисе, когда ушел на фриланс организовал для себя аналогичную инфраструктуру. Клиенты с которыми работаю на постоянной основе подключаются к VPNу для мониторинга основного работающего в моей сети и для обновлений того что я собираю, внешний мониторинг следит только за доступностью всякого веба снаружи, на случай каких-то недоразумений(мало ли что, вдруг изнутри будет доступно, а снаружи нет, надо такое проверять). С подписями пакетов считаю возможным только так работать, потому что мало ли какая фигня, мало ли мою машину как-то смогут взломать(вряд ли, но всегда надо допускать), подписываться должны на отдельной изолированой только так подписи можно доверять.
| | |
|
|
|
|
|
| |
| 2.5, мурзилла (?), 15:52, 08/05/2019 [^] [^^] [^^^] [ответить] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| –1 +/– | |
ага. Проект г-но и из г-на, ломают раз в три дня - но их больше всего заботит, ну надо же ж, чтоб злые хакеры не подсунули неправильное обновление.
результат будет примерно как у нас - через пару лет всеми забытый ключ поэкспайрится, или его просто проимеют вместе с плохо читавшейся флэшкой, и как раз когда надо будет заткнуть всеми уже имеемую дырку на всех этих миллионах инстансов - ой, оно не работает, вам надо вон там скачать (по http) непойми что, подсунуть вон туда, запустить в шелле (ваш хостер не дает шелл? ну мы даже и не знаем) вот это, и тогда автообновление легко и просто установится!
| | |
|
| 1.8, Аноним (8), 16:12, 08/05/2019 [ответить] [﹢﹢﹢] [ · · · ] [↑] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +/– | |
> Ed25519 обладает более высоким уровнем безопасности, чем ECDSA и DSA, и демонстрирует очень высокую скоростью верификации и создания подписей
Ой, какие умнички - джвадцать джва года ждали появления фичастой криптолибы, вместо того, чтобы сделать хоть какую-то проверку с теми алгоритмами, которые уже были доступны.
| | |
| 1.14, Онаним (?), 19:42, 08/05/2019 [ответить] [﹢﹢﹢] [ · · · ] [↑] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +4 +/– | |
> Белый список допускает только загрузку изображений, но обойти его можно указав двойное расширение, например, ".gif.phtml
Плагины от безграмотных такие плагины.
| | |
|
