Скрытие пароля сетевого прокси в текстовых файлах на Linux/UNIX-подобных устройствах

При следующем подходе вам никогда не придется сохранять пароль прокси-сервера в виде простого текста. Вам просто нужно ввести пароль в интерактивном режиме, как только вам понадобится доступ к http/https/ftp:

• Используйте openssl, чтобы зашифровать ваш простой текстовый пароль прокси в файл, например, с помощью Шифрование AES256:

openssl enc -aes-256-cbc -in pw.txt -out pw.bin

• Используйте (другой) пароль для защиты закодированного файла
• Удалить обычный текст pw.txt
• Создайте псевдоним, например. ~/.alias для установки переменных среды http_proxy/https_proxy/ftp_proxy (установите соответствующие значения для $USER/proxy/$PORT)

псевдоним myproxy='PW=`openssl aes-256-cbc -d -in pw.bin`; PROXY="http://$USER:$PW@proxy:$PORT"; экспорт http_proxy=$PROXY; экспортировать https_proxy=$PROXY; экспортировать ftp_proxy=$PROXY'

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

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

псевдоним clearproxy='экспорт http_proxy=; экспортировать https_proxy=; экспорт ftp_proxy='

Я сделал модифицированное решение:

отредактируйте /etc/bash.bashrc и добавьте следующие строки:

alias myproxy='read -p "Username: " USER;read -s -p "Password: " PW
PROXY="$USER:[email protected]:80";
export http_proxy=http://$PROXY;export Proxy=$http_proxy;export https_proxy=https://$PROXY;export ftp_proxy=ftp://$PROXY'

При следующем входе введите myproxy и введите комбинацию пользователя и пароля! Теперь работайте с sudo -E

-E, --preserve-env Указывает политике безопасности, что пользователь хочет зарезервировать свои существующие переменные среды.

e.g. sudo -E apt-get update

Примечание: настройки прокси действительны только во время сеанса оболочки.

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

Для переменных среды в ~/.profile вы можете сохранить их закодированными, а затем декодировать их перед установкой переменных, например:

encodedcreds="sbbone:cnffjbeq"
creds=`echo "$encodedcreds" | tr n-za-mN-ZA-M a-zA-Z`

Это установит creds в foobar:password, которое вы затем сможете встроить в http_proxy и т. д.

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

Предпочитайте приложения, которые интегрируются с Gnome Keyring. Другая возможность — использовать туннель SSH для внешнего компьютера и запускать через него приложения. Взгляните на опцию -D для создания локального прокси-интерфейса SOCKS, а не на однообслуживание -L переадресации.

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

Одна вещь, которую я видел в подобных случаях, — это создание выделенных учетных данных для каждого сервера, для каждого пользователя или для каждого сервера/пользователя, которые имеют доступ к прокси-серверу только с определенного IP-адреса. Это не решает вашу основную проблему обфускации, но смягчает последствия того, что кто-то увидит пароль, потому что он так мало стоит.

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

Является ли аутентификация с открытым ключом допустимой альтернативой для вас?

Пока все три пункта верны, вам не повезло:

1. Серверу требуется веб-доступ
2. Пользователям нужен абсолютный контроль над сервером (root)
3. Вы не хотите, чтобы пользователи имели веб-доступ к серверу

Если вы не можете удалить № 2 или № 3, ваш единственный выбор — удалить № 1. Настройте внутренний сервер, на котором размещаются все обновления программного обеспечения. Держите его заблокированным от других пользователей и не позволяйте другим серверам иметь доступ в Интернет.

Все, что вы пытаетесь сделать, просто обманываете себя.

мы решили эту проблему, не запрашивая пароли прокси для rpm, apt или других подобных обновлений (базы вирусов, Windows и т. д.). Это небольшой белый список известных репозиториев для добавления в прокси.

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

Очевидным вектором атаки было бы изменение привилегированным пользователем этого локального прокси-сервера, чтобы он делал что-то еще с введенным паролем (как они могли бы с чем-то еще, например, с почтовым клиентом, который запрашивает его, или с самой оконной системой), но, по крайней мере, вы d быть защищенным от случайного просмотра.