Настроить учетную запись ssh, которая может использоваться только для прокси socks5
У меня есть Linux-машина Arch за брандмауэром. Я могу открыть переадресацию порта для порта ssh. Я хотел бы создать пользователя, которого можно будет использовать только для прокси-сервера socks.
ssh -N -D 5000 user@server -p9000
5000 будет локальным портом, который пользователь использует для прокси-сервера socks5
: 9000 - порт ssh для сервер (переадресация портов)
-N означает, что терминал не должен открываться. Я создам пользователя с оболочкой по умолчанию / sbin / nologin .
Теперь проблема в том, что пользователь может перенаправлять локальные порты ( -L8080: server2: 80 ) и Я хочу избежать этого.
Также я хочу, чтобы прокси-сервер не проксировал подключения к чему-либо во внутренней сети сервера.
Это легко достижимо или нет?
Есть ли другие подводные камни, о которых я должен подумать?
Как упоминалось в Jakuje , вы можете использовать параметры для запрета пересылки.
Ограничение Исходящий трафик по владельцу
Также я хочу, чтобы прокси-сервер не подключал прокси-сервер к чему-либо во внутренней сети сервера.
Вы можете использовать модуль iptables owner , чтобы разрешить определенные группы и пользователей исходящий трафик в OUTPUT правила для определенных местоположений, таких как ваш сервер шлюза ssh, но затем блокируют все остальное. Модуль владельца может соответствовать gid или uid. Этот метод также обычно используется вместе с Tor.
Вы также можете использовать его, чтобы разрешить определенным демонам обращаться к определенным службам. например При использовании ldap вы можете разрешить учетной записи службы ldap запрашивать ваш ldap-сервер и ничего больше.
Если вы используете iptables в этом поместье, вы можете сначала разрешить (но зарегистрировать) трафик, чтобы знать, что было бы отброшено .
Вы можете запретить локальную пересылку в sshd_config , например:
Match User your_user
AllowTcpForwarding no
PermitOpen none
Это не должно влиять на прокси динамической пересылки / SOCKS.
Также я хочу, чтобы прокси не прокси-подключения к чему-либо во внутренней сети сервера.
Это необходимо настроить где-нибудь еще, а не в ssh .