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

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

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

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

• Используйте (другой) пароль для защиты закодированного файла
• Удалить обычный текст pw.txt
• Создайте псевдоним, например, в ~/.псевдоним для установки переменных среды 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'

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

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

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

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

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

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

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

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

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

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

alias myproxy='read -p "Username: " USER;read -s -p "Password: " PW
PROXY="$USER:$PW@proxy.com: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 Указывает в политике безопасности, что пользователь желает зарезервировать свои существующие переменные среды.

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

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

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

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

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

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

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

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

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

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

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

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

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

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