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

Подходит ли вам аутентификация с открытым ключом?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

При следующем подходе вам никогда не придется сохранять пароль прокси в виде обычного текста. Вам просто нужно ввести пароль в интерактивном режиме, как только вам понадобится доступ по 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)

alias myproxy='PW=`openssl aes-256-cbc -d -in pw.bin`; PROXY = "http://$USER:$PW@proxy:$PORT"; export http_proxy=$PROXY; export https_proxy=$PROXY; export ftp_proxy=$PROXY'

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

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

alias clearproxy='export http_proxy=; export https_proxy=; export 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 Indicates to the security policy that the user wishes to reserve their existing environment variables.

например sudo -E apt-get update

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