LINUX.ORG.RU

Концепция автоматической настройки автономных ПК

 


2

2

Всем привет!

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

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

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

Одна смена пароля может затянуться на два дня, пока всех обойдёшь.

У меня работает система обновления баз антивируса с определённой флешкой (флешки кроме разрешённых блокированы).

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

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

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

Человек подключает флешку, компьютер выполняет скрипт (например смены пароля) и все счастливы.

Единственное «но» в безопасности такой реализации.

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

Второй скрипт, размещён на всех автономных ПК. Он предназначен для расшифровки скриптов с настройками и их выполнения. На автономных ПЭВМ так же размещается приватный ключ для расшифровки.

Первый скрипт (шифрование):

#!/bin/bash

file_path_to_encrypt=$1
dir_path_to_result=./task

rm -Rf ./task && mkdir $dir_path_to_result

openssl rand 214 > ./key_to_work.key # Генерируем случайный ключ (он же пароль)

openssl enc -aes-256-ctr -pbkdf2 -in $file_path_to_encrypt -out $dir_path_to_result/encrypt_shell.sh -pass file:./key_to_work.key # Используя симметричное шифрование шифрую файл используя этот ключ (пароль)

openssl rsautl -encrypt -pubin -inkey public.pem -in ./key_to_work.key -out $dir_path_to_result/auth_key.pem # Используя публичный ключ шифрую пароль

rm ./key_to_work.key # Удаляю пароль в открытом виде

Второй скрипт (расшифровка и выполнение):

#!/bin/bash

file_path_to_decrypt="$1"

openssl rsautl -decrypt -inkey private.pem -in ./task/auth_key.pem -out ./key_to_work.key # Расшифрую пароль используя приватный ключ (асимментричное шифрование)

if [[ $? == "0" ]] # Если расшифровка прошла успешно
  then
    : # Значит скрипт зашифровал я, продолжаем работу
  else
    echo 'Скрипт не подтверждён. Завершаю работу.' # Иначе вывожу сообщение, удаляю открытый файл ключа, завершаю работу
    rm -f ./key_to_work.key
    exit 1
fi

openssl enc -d -aes-256-ctr -pbkdf2 -in $file_path_to_decrypt -out ./script.sh -pass file:./key_to_work.key # Расшифрую файл используя полученный пароль (симметричное шифрование)

/bin/bash ./script.sh # Запускаю расшифрованный скрипт

rm -f ./{key_to_work.key,script.sh} # Удаляю файлы пароля и скрипта

На «красоту» и оптимизацию кода прошу внимание не обращать. Это черновой вариант, просто чтобы посмотреть на концепцию.

Безопасно ли это? Какие тонкие места Вы видите в такой реализации (например, возможность замены инструкций скрипта настроек)?

Заранее спасибо!



Последнее исправление: Sandro331k (всего исправлений: 2)

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

Khnazile ★★★★★
()

на Debian

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

Профит?

vvn_black ★★★★★
()
Последнее исправление: vvn_black (всего исправлений: 1)
Ответ на: комментарий от Sandro331k

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

Достаточно использовать только подпись своих пакетов, и проверку подписи при установке, без всякого шифрования.

vvn_black ★★★★★
()
Ответ на: комментарий от Sandro331k

Продвинутому, да будет. Что там у вас, гостайна или 1, 2 группа ПД?

Если так, то вам не на форум, а покупать решения, за которыми будут охранительные бумажки от ФСТЭК.

vvn_black ★★★★★
()
Ответ на: комментарий от hobbit

Интересный совет, спасибо! Компьютеры без сети, но допустим установлю я Ansible… Я применяю его на сетевых ПК. Хочу сменить свой пароль на всех автономных ПК. Мои действия?

Sandro331k
() автор топика
Ответ на: комментарий от vvn_black

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

Sandro331k
() автор топика
Ответ на: комментарий от Khnazile

Ересь, это конечно плохо. Я читал, что разделение на секретный и несекретный ключ только у нас в головах.

По факту алгоритм математический и его задача расшифровывать и зашифровывать отдельными ключами - остальное ограничивается моей фантазией и задачей.

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

Sandro331k
() автор топика
Ответ на: комментарий от Sandro331k

Как Вы считаете, как можно обмануть ту концепцию, что я изложил?

В вашем же тоне отвечу. )

Тут же думать надо, а «денег нет», поэтому и думать нет.

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

vvn_black ★★★★★
()
Ответ на: комментарий от Sandro331k

я-то подскажу, а толку?

публичный ключ … для шифрования

для шифрования

для начала поведай мне, о администратор безопасности, как ты собрался шифровать публичным ключом? а потом уже можно подумать про rsa/не rsa :)

aol ★★★★★
()
Ответ на: комментарий от Sandro331k

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

Khnazile ★★★★★
()
Ответ на: комментарий от Sandro331k

Ключ шифрования только у владельца, открытый ключ у всех остальных. У вас получается ровно наоборот, опять же исходя из невинмательного чтения ОП.

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

Т.е. к задаче обновления вы еще добавляете задачу уровнем посложнее - управление ключами.

vvn_black ★★★★★
()
Ответ на: комментарий от vvn_black

а вот надо бы, чтобы, как раз, в первую очередь была «характеристика профессиональных навыков», а то так и будем открытым ключом шифровать, а закрытым расшифровывать..

какая уж там квантовая криптография нам….

aol ★★★★★
()
Ответ на: комментарий от aol

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

Khnazile ★★★★★
()
Ответ на: комментарий от aol

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

И подписывают закрытым ключом отправителя. Это же цель подписи, чтобы ее мог сформировать только один субъект — владелец закрытого ключа (отправитель).

А у вас в голове что, все наоборот?

iliyap ★★★★★
()
Последнее исправление: iliyap (всего исправлений: 1)
Ответ на: комментарий от Khnazile

Вы молодец! Я как раз шёл на работу и тоже пришёл к этому! Создал каждому автономному компьютеру по ключу, чтобы исключить компрометацию сразу всей системы.

Sandro331k
() автор топика
Ответ на: комментарий от frunobulax

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

Sandro331k
() автор топика
Последнее исправление: Sandro331k (всего исправлений: 1)
Ответ на: комментарий от vvn_black

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

Sandro331k
() автор топика
Последнее исправление: Sandro331k (всего исправлений: 1)

Он предназначен для расшифровки скриптов с настройками и их выполнения. На автономных ПЭВМ так же размещается приватный ключ для расшифровки.

В скриптах при этом AES в режиме CTR, который никаких гарантий целостности не даёт.

Безопасно ли это?

Нет. Нужно научиться понимать разницу между обеспечением целостности и конфиденциальности, и какие гарантии какие алгоритмы дают.

Значит скрипт зашифровал я, продолжаем работу

LOL. На клиентском компьютере есть приватный ключ. Из него легко сделать публичный.

ivlad ★★★★★
()
Ответ на: комментарий от ivlad

Спасибо за комментарий!) Гарантии целостности, это другая сторона работы над скриптом, я же попросил разобрать концепцию со стороны безопасности (конфиденциальности).

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

Так как приватный ключ будет не доступен обычному пользователю за счёт дискреционного разграничения прав доступа, он не сможет сделать из него публичный. Если он получит доступ к суперпользователю или просто снимет жёсткий диск, то уже не будет смысла может он генерировать публичный ключ или не может).

В любом случае я не знал про режим ctr, поэтому обязательно прочитаю литературу в данном направлении.

Sandro331k
() автор топика
Последнее исправление: Sandro331k (всего исправлений: 2)
Ответ на: комментарий от Khnazile

Сегодня почитал про электронную подпись (она у нас не используется, поэтому опыта нет) и понял, что Вы имели ввиду. Если на одном компьютере ключи будут скомпрометированы, то у злоумышленника будет возможность изменить содержимое зашифрованных файлов. Цифровая подпись позволит избежать данного сценария.

Sandro331k
() автор топика
Ответ на: комментарий от Sandro331k

Ansbile умеет работать в pull режиме. Ansible умеет шифровать рабочие книги, да и вообще любые файлы. Просто изучи готовый инструмент и избежишь большого количества граблей.

Хочу сменить свой пароль на всех автономных ПК. Мои действия?

Пишешь книгу, шифруешь, подсовываешь книгу в рабочий каталог с флешки.

???

Profit.

P.S. У Ansible есть один серьёщный недостаток. На каком-то этапе, изучая Ansible, ты захочешь делать через него вообще всё. Надо будет усилием воли удерживать себя.

Aceler ★★★★★
()
Ответ на: комментарий от vvn_black

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

подписанными *-пакетами

Соглашусь, что обновления систем должны выполняться стандартными средствами системы.

Для обновления ПО на клиентских компах необходимо и достаточное только публичных ключей для верификации подписей. (Шифрование обновлений вынесем за скобки, здесь надо хранилища приватных ключей, вводить пароли для этих приватных ключей).

Раз для обновления создаём подписанные настроенные пакеты для каждого компа и устанавливаем стандартными средствами дистра, то есть вопрос по существующим менеджерам пакетов: кто из них уже имеет поддержку IMA/EVM, надо при создании пакета дергать готовую прогу для подписи и при упаковке/распаковке сохранять XATTR.

anonymous
()
Ответ на: комментарий от vvn_black

написано про RSA, а в скриптах шифрование с общим ключиком

Так ведь так обычно и делают. Данные прогоняются через симметричный шифр, а потом ключ симметричного шифра шифруется RSA. Даже TLS работает аналогично: сеансовое шифрование там происходит симметричными алгоритмами, и только на этапе согласования используется RSA. Теперь уже аналоги, а не RSA, но не это главное.

i-rinat ★★★★★
()

Безопасно ли это? Какие тонкие места Вы видите в такой реализации

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

Если до private.pem у операторов ПЭВМ доступа нет, то есть считается, что он в полной безопасности, то вместо возни с асимметричным шифрованием можно просто использовать симметричное. На конечных машинах от пользователя спрятаны ключи, а всё содержимое флешек с обновлениями полностью зашифровано. В таком случае скрытно внести какие-то изменения в данные на флешке не выйдет.

i-rinat ★★★★★
()

для синхронизации паролей гугли LDAP, для автоматизации работ вроде установки баз антивирусов или настройки установки софта, юзай ansible. Инструменты вроде ssh scp тебе в помощь.

s-warus ★★★
()
Последнее исправление: s-warus (всего исправлений: 1)
Ответ на: комментарий от Aceler

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

anonymous
()
Ответ на: комментарий от anonymous

Потому что он много говорит и мало делает. Считаю, что если человек за несколько лет не осилил выписать себе сертификат (хотел, но не смог), то и модерировать разделы типа admin и вебдев ему не стоит.

anonymous
()
Ответ на: комментарий от anonymous

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

капча: то, что сотворила рука человека

anonymous
()