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

Question

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

Это означает, что необходимо ввести сетевой пароль в файл apt.conf, а также переменные окружения http_proxy, ftp_proxy и https_proxy, определенные в ~/.profile

Я понимаю, что с apt.conf вы можете установить chmod 600 (что не является по умолчанию в Ubuntu / Debian!), Но в нашей системе есть люди, которым нужны привилегии суперпользователя.

Я также понимаю, что технически невозможно защитить пароль от кого-то, у кого есть root-доступ, однако мне было интересно, существует ли способ скрыть пароль, чтобы предотвратить случайное обнаружение. Windows работает с пользователями как администраторы, но каким-то образом хранит сетевые пароли (вероятно, хранящиеся глубоко в реестре, каким-то образом скрытые), чтобы при обычном использовании вы не наткнулись на него в виде простого текста

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

@ monjardin - Боюсь, аутентификация с открытым ключом не является альтернативой в этой сети. Кроме того, я сомневаюсь, что он поддерживается большинством инструментов командной строки.

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

Answer 1

При следующем подходе вам никогда не придется сохранять свой пароль прокси в виде простого текста. Вам просто нужно ввести пароль в интерактивном режиме, как только вам понадобится доступ по 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; экспорт https_proxy = $ PROXY; экспорт ftp_proxy = $ PROXY '

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

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

alias clearproxy = 'export http_proxy =; export https_proxy =; экспорт ftp_proxy = '

Answer 2

Я сделал измененное решение:

изменить /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

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

Answer 3

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

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

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

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

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

Answer 4

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

Answer 5

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

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

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

Answer 6

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

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

Answer 7

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

Answer 8

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

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

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

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

Answer 9

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