Предположим, у вас есть полу-доверенная машина (например, та, к которой у ИТ-отдела вашего делового партнера есть root-доступ), находящаяся за брандмауэром, и вы хотите подключиться к этой машине с одной из ваших доверенных машин.
Основная идея состоит в том, чтобы обойти брандмауэр, установив SSH-туннель с ненадежной машины, чтобы доверенная машина могла подключаться локально. Этот туннель должен быть постоянным, поэтому я использую autossh программа.
Чтобы сделать это в некоторой степени безопасным, я сейчас создаю пользователя autossh на обеих машинах и авторизуйте свой открытый ключ без парольной фразы, чтобы autossh пользователь может установить соединение, не вводя кодовую фразу. Кроме того, я установил эту пользовательскую оболочку на /bin/false, так как это запрещает нормальный вход в систему, по-прежнему позволяя настроить туннель.
Это в основном работает, но я чувствую, что нужно сделать больше, чтобы сделать это достаточно безопасным.
Хотя злоумышленник с доступом к полу-доверенному компьютеру не может войти на доверенный сервер с помощью этого ключа, он может, например, выполнить атаку типа "отказ в обслуживании", создав туннельный цикл SSH и заполнить таблицу открытых файлов (см., например, 1) вот так
ssh -vN -L4141:localhost:4141 trustedhost
ssh -vN -R4141:localhost:4141 trustedhost
telnet localhost 4141
И, вероятно, есть и другие возможные атаки. Итак, как я могу дополнительно защитить этот механизм создания этого полу-доверенного туннеля? Мне нужно только установить одно постоянное соединение между этими серверами, никакие другие команды / туннели не должны выполняться / устанавливаться autossh пользователь.
Во-первых, убедитесь, что тот, кто установил брандмауэр, действительно хочет, чтобы вы его обошли. Возможно, он не был проинформирован о вашем запросе на прямой доступ к этой машине и может предложить другое решение (например, изменение брандмауэра или топологии сети).
Попытки исчерпания ресурсов, как в вашем примере, не должны вызывать особого беспокойства, поскольку вы, вероятно, уже применили nproc так же как nofile пределы.
$ ulimit -n
1024
$ ulimit -u
2048
Исчерпание памяти или inode будет затруднено, пока вы перемещаете такого пользователя в пустой tmpfs ограниченного размера.
Если вы хотите уменьшить поверхность атаки, прекратите использовать autossh (программа, предназначенная для устранения исторических недостатков, которые были устранены в openssh десять лет назад) и запретите использование TCP-портов на вашей стороне (сокетов unix вполне достаточно для поддержания туннеля).
Match Group untrusted
ChrootDirectory /run/empty/%u
AllowTcpForwarding no
AllowStreamLocalForwarding remote
PermitTunnel no
Риски, которые вы не сможете снизить: