Сервер Bastion: использовать TCP-пересылку VS размещение закрытого ключа на сервере
У нас есть сервер-бастион B. Нам нужно использовать SSH от A до B к C, используя закрытый ключ.
Какой вариант лучше:
Поместите закрытый SSH-ключ на сервер B. Мы читаем, что это плохая идея. сделайте это в производственной среде.
Из здесь :
Никогда не размещайте свои закрытые ключи SSH в экземпляре бастиона. Вместо, используйте пересылку агента SSH для подключения сначала к бастиону и от к другим экземплярам в частных подсетях. Это позволяет вам сохранить Закрытый ключ SSH прямо на вашем компьютере.
Используйте пересылку агента SSH . Для настройки пересылки агента мне нужно разрешить пересылку TCP.При настройке пересылки агента на хосте пересылки создается файл сокета, который является механизмом, с помощью которого ключ может быть переадресован в пункт назначения. В настройках Bastion на AWS:
TCP forward: установка этого значения на true включит пересылку TCP (SSH-туннелирование). Это может быть очень полезно, но это еще и безопасность. риск, поэтому мы рекомендуем оставить настройку по умолчанию (отключено) если не требуется
Также из здесь :
Пересылка агента SSH считается опасной
Что лучше? Как насчет альтернативы из второй ссылки: ProxyCommand , я понимаю, что это помогает решить проблему с файлом сокета, но все же я думаю, что мне нужно включить пересылку TCP, так что это достаточно безопасно?
Используйте ProxyCommand или ProxyJump
Я бы рекомендовал использовать ProxyCommand (или даже лучше ProxyJump , поскольку синтаксис проще, но требует openssh 7.3+ Я думаю, что на стороне клиента), и вам не нужно развертывать закрытый ключ на Bastion, все остается локальным.
Пример с ProxyJump
На вашем клиентском компьютере вы пишете файл под ~ / .ssh / config с содержанием, аналогичным приведенному ниже:
Host bastion
HostName bastion.example.com
User bastion-user
Port 22
IdentityFile ~/.ssh/id_bastion
Host srvC
HostName srvC.local
User server-user
IdentityFile ~/.ssh/id_protected_lan
ProxyJump bastion
Затем выполнение ssh srvC подключит вас к C через B (бастион) без пересылки агентов и без развертывания закрытого ключа в бастионе.
В приведенном выше примере «bastion» - это псевдоним вашего хоста Bastion, а srvC - псевдоним вашего сервера C. В HostName вам необходимо указать IP-адреса или настоящее полное доменное имя для ваших хостов. Для пользователей вам необходимо обновить User для правильного имени входа на Bastion и сервере C. Наконец, IdentityFile является необязательным, если вы используете локальный агент (например, KeeAgent или ssh -agent), но если он не запущен, он также будет работать и запрашивать парольные фразы для каждого ключа.
Развертывание открытых ключей
Конечно, вам необходимо развернуть общедоступные ключи для обоих бастион и srvC. Вы можете использовать (знак $ предназначен только для иллюстрации приглашения, не вводите его):
$ ssh-copy-id -i ~/.ssh/id_bastion.pub \
-o PreferredAuthentications=password \
-o PubkeyAuthentication=no \
bastion
$ ssh-copy-id -i ~/.ssh/id_protected_lan.pub \
-o PreferredAuthentications=password \
-o PubkeyAuthentication=no \
srvC
Примечание: приведенное выше будет работать, только если аутентификация по паролю все еще разрешена. После вышеуказанного развертывания и проверки того, что все работает должным образом, вам следует запретить аутентификацию по паролю на 2 серверах.
Пример с ProxyCommand вместо ProxyJump
Если у вас есть более старая версия OpenSSH, которая не поддерживает ProxyJump (на стороне клиента), затем замените:
ProxyJump bastion
на
ProxyCommand ssh -q -W %h:%p bastion
Насколько я понял, это похоже.
Просто используйте перенаправление агента SSH , как и большинство других.
- Ключи будут в агенте ssh на вашем ноутбуке.
- Вы входите в систему Bastion, аутентифицируясь через агента.
- Оттуда авторизуйтесь на целевом хосте с запросом аутентификации , перенаправленным обратно на ваш портативный компьютер .
Преимущество: на бастионе нет ключей, которыми можно было бы воспользоваться не по назначению.
Надеюсь, что это поможет :)
Я видел ответ о ProxyJump. Давайте поговорим о ProxyCommand .
Но подождите, подождите! Я могу написать вам , как взломать сервер , который использует пересылку агента, что было бы намного проще понять различия!
Давайте взломать!
Основные шаги: вы можете прочитать мой пост здесь
Основные шаги следующие:
- Создать пользователей бастиона
- Отключить вход root
- Блокировать попытки взлома
- Изменить порт
- Настроить брандмауэр
- Настроить SELinux
Как использовать AgentForwarding
-Создать конфигурацию в ~ / .ssh / config
Host bast
Hostname BASTION_IP
ForwardAgent yes
User bastion
-Добавить свой ключ аутентификации в ssh-agent
ssh-add ~/.ssh/name_rsa
-Подключиться к хосту-бастиону
ssh bast
-Подключиться к серверу приложений с бастиона
ssh app@IP -p PORT
Взлом!
Вы можете задать мне вопрос:
Безопасен ли мой сервер? И ответ довольно прост:
- НЕТ!
Почему?
- Потому что вы используете пересылку агента SSH!
И в чем проблема?
- Потому что пересылка агента опасна и считается вредной .
Почему?
- Давайте объясним все наизнанку: Когда вы подключаетесь к хосту-бастиону, ваш великолепный ssh-агент перенаправляется. Это означает, что сокет будет настроен так, чтобы кто-то мог использовать эти данные сокета для доступа к вашим серверам. Представьте, что ваш сервер-бастион скомпрометирован. Если кто-то имеет достаточные разрешения на вашем сервере Linux, он / она просто будет использовать информацию о вашем сокете. В результате можно получить доступ ко всему вашему серверу. Я знаю, что окно компромисса очень мало, потому что оно зависит от того, сколько времени вы подключены к хосту-бастиону. Но действительно ли вы хотите рисковать, когда у вас есть другие варианты, такие как ProxyCommand? Следовательно, просто используйте ProxyCommand!
Как взломать серверы, если вы взломали хост-бастион?
Track Target
В каталоге / tmp вы можете увидеть что-то вроде этого:
[root@localhost tmp]# ll
total 12
drwx------ 2 bastion bastion 4096 Sep 7 17:35 ssh-mKX88v0Vlo
Давайте откроем временный файл
[root@localhost tmp]# cd ssh-mKX88v0Vlo/
[root@localhost ssh-mKX88v0Vlo]# ll
total 0
srwxr-xr-x 1 bastion bastion 0 Sep 7 17:35 agent.10507
Let's см. подключения к этому идентификатору процесса.
netstat -nxp | grep 10507
результат:
unix [ ] STREAM CONNECTED 501384 10507/sshd: bastion
и кто подключен?
lsof -i -a -p 10507
результат:
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
sshd 10507 bastion 3u IPv4 501301 0t0 TCP *IP*:ssh->*IP*:8279 (ESTABLISHED)
Мы также можем увидеть файлы сокетов:
cd /proc/10507/fd/
ls
результат:
lrwx------ 1 root root 64 Sep 7 17:46 0 -> /dev/null
lrwx------ 1 root root 64 Sep 7 17:46 1 -> /dev/null
lrwx------ 1 root root 64 Sep 7 17:46 10 -> /dev/ptmx
lrwx------ 1 root root 64 Sep 7 17:46 14 -> /dev/ptmx
lrwx------ 1 root root 64 Sep 7 17:46 15 -> /dev/ptmx
lrwx------ 1 root root 64 Sep 7 17:46 2 -> /dev/null
lrwx------ 1 root root 64 Sep 7 17:46 3 -> socket:[501994]
lrwx------ 1 root root 64 Sep 7 17:46 4 -> socket:[502069]
lrwx------ 1 root root 64 Sep 7 17:46 5 -> socket:[502072]
l-wx------ 1 root root 64 Sep 7 17:46 6 -> /run/systemd/sessions/1836.ref
lr-x------ 1 root root 64 Sep 7 17:46 7 -> pipe:[502079]
l-wx------ 1 root root 64 Sep 7 17:46 8 -> pipe:[502079]
lrwx------ 1 root root 64 Sep 7 17:46 9 -> socket:[502080]
И что произойдет , когда клиент будет подключен к удаленному серверу? посмотрим:
lrwx------ 1 root root 64 Sep 7 17:46 0 -> /dev/null
lrwx------ 1 root root 64 Sep 7 17:46 1 -> /dev/null
lrwx------ 1 root root 64 Sep 7 17:46 10 -> /dev/ptmx
lrwx------ 1 root root 64 Sep 7 17:48 11 -> socket:[502267]
lrwx------ 1 root root 64 Sep 7 17:46 14 -> /dev/ptmx
lrwx------ 1 root root 64 Sep 7 17:46 15 -> /dev/ptmx
lrwx------ 1 root root 64 Sep 7 17:46 2 -> /dev/null
lrwx------ 1 root root 64 Sep 7 17:46 3 -> socket:[501994]
lrwx------ 1 root root 64 Sep 7 17:46 4 -> socket:[502069]
lrwx------ 1 root root 64 Sep 7 17:46 5 -> socket:[502072]
l-wx------ 1 root root 64 Sep 7 17:46 6 -> /run/systemd/sessions/1836.ref
lr-x------ 1 root root 64 Sep 7 17:46 7 -> pipe:[502079]
l-wx------ 1 root root 64 Sep 7 17:46 8 -> pipe:[502079]
lrwx------ 1 root root 64 Sep 7 17:46 9 -> socket:[502080]
Мы даже можем увидеть, используется ли файл сокета, используя netstat:
unix 3 [ ] STREAM CONNECTED 502267 10561/sshd:
bastion /tmp/ssh-oVoMXC6vb8/agent.10561
unix 3 [ ] STREAM CONNECTED 502072 10561/sshd: bastion
Steal Socket info and IP address
Теперь нам нужно украсть информацию о сокете, пока сеанс хоста-бастиона открыт . О, нам также нужен IP-адрес конечного сервера , поэтому просто используйте netstat:
netstat -tn
Последний шаг , чтобы использовать файл перенаправленного сокета
eval "$(ssh-agent -s)"
SSH_AUTH_SOCK=/tmp/ssh-EAKxOdL4fl/agent.10507
Проверьте, загружен ли ключ .
ssh-add -l
результат должен быть что-то подобное :
2048 SHA256:2Psdl..B5KQ /home/usr/.ssh/name_rsa (RSA)
Сервер взломан, как решить проблему безопасности?
Команда прокси
Host app
Hostname *.*.*.*
IdentityFile ~/.ssh/your_rsa
User *******
Port ****
ProxyCommand ssh -W %h:%p bast
Host bast
Hostname *.*.*.*
ForwardAgent no
User ******
Для основных операций: как передавать файлы через серверы (от клиента к серверу, от сервера к клиенту), вы можете прочитать в моем сообщении здесь
Заключение
- Если вы используете хост-бастион, не используйте AgentForwarding, а используйте ProxyCommand
- Всегда используйте для аутентификации пользователя без полномочий root.
- Используйте брандмауэр и блокируйте все ненужные соединения.
- Используйте SELinux (обычно)
- Блокируйте IP-адрес, который пытается войти несколько раз с неправильными учетными данными
- Если в этом нет необходимости, не давайте пользователю разрешения sudo
- Наблюдайте за своим сервером
- Обновите свой сервер для исправлений безопасности
Дополнительную информацию см. В моем блоге . Вдобавок у меня есть несколько скриншотов, так что они могут быть вам полезны.