Como desativar o encaminhamento de porta local SSH?


20

Eu tenho um servidor executando o Ubuntu e o daemon OpenSSH. Vamos chamá-lo de S1.

Eu uso esse servidor de máquinas clientes (vamos chamar uma delas de C1) para fazer um túnel reverso SSH usando o encaminhamento de porta remota, por exemplo:

ssh -R 1234:localhost:23 login@S1

No S1, eu uso o arquivo sshd_config padrão. Pelo que pude ver, qualquer pessoa com as credenciais corretas {login, pwd} no S1 pode fazer login no S1 e fazer encaminhamento de porta remota e encaminhamento de porta local. Tais credenciais podem ser um certificado no futuro, portanto, no meu entendimento, qualquer pessoa que pegue o certificado poderá efetuar login no S1 de qualquer outro lugar (não necessariamente C1) e, portanto, criar encaminhamentos de porta locais.

Para mim, permitir o encaminhamento de porta local é muito perigoso, pois permite criar algum tipo de proxy público. Estou procurando uma maneira de desativar apenas os encaminhamentos -L.

Tentei o seguinte, mas isso desabilita o encaminhamento local e remoto:

AllowTcpForwarding No

Eu também tentei o seguinte, isso permitirá apenas -L to SX: 1. É melhor que nada, mas ainda não é o que eu preciso, que é uma opção "nenhuma".

PermitOpen SX:1

Então, eu estou querendo saber se existe uma maneira, para que eu possa proibir todas as portas locais encaminharem escrever algo como:

PermitOpen none:none

A seguinte é uma boa ideia?

PermitOpen localhost:1

então, como sempre, vamos à raiz disso: qual é o seu verdadeiro problema, por que você deseja configurar algo assim para dispositivos móveis / incorporados, o que você deseja resolver?
Akira

O problema a ser resolvido aqui é poder abrir uma sessão Telnet, em qualquer lugar da Internet, para um dispositivo móvel / incorporado conectado à Internet, levando em consideração que o dispositivo pode ter NAT ou firewall, portanto, não é acessível. da internet.
SCO

telnet .. para que? para furos de perfuração em google firewall para 'atordoamento'
akira

Respostas:


16

qualquer pessoa com credenciais de login pode exibir sua própria instância do sshd, executando em uma porta aleatória e permitir o que quiser, incluindo -L encaminhamentos locais:

% /usr/sbin/sshd -d -f mysshd.config -p 12345

se você não confiar que os usuários façam algo com sua máquina, não deverá permitir que eles façam login em primeiro lugar.

(aliás, o sinalizador -D também é "problemático por proxy")


Bem, acho que posso configurar uma conta muito restritiva para esse fim (por exemplo, manter o usuário em sua casa, sem listagem, sem navegação no sistema de arquivos), para que ele não possa iniciar e sshd (ou instalar e iniciar um binário sshd). O ponto é que os clientes devem ser dispositivos incorporados. Mas como eles provavelmente incorporaram certificados e suas memórias flash podem ser descartadas, é possível que os certificados vazem, permitindo que qualquer pessoa faça login no S1.
SCO

Usar o ChrootDirectory para esse usuário específico fará o truque, tentará isso!
SCO

1
Em allowed_keys, defina command="/sbin/nologin". Isso deve impedi-los de executar qualquer comando no servidor.
justis 31/07

A declaração "qualquer pessoa com credenciais de login pode exibir suas próprias <qualquer que seja>" é falsa. sshpode ser usado para conectar-se a contas com restrições de login severamente restritas que não permitem isso. O encaminhamento de porta é um furo de segurança em tais shells restritos. Além de executar um comando permitido, o usuário pode criar túneis.
Kaz

3
Citação da sshd_configpágina de manual: Observe que desativar o encaminhamento de TCP não melhora a segurança, a menos que os usuários também tenham acesso negado ao shell , pois sempre podem instalar seus próprios encaminhadores. (Ênfase minha).
Kaz

17

Outra solução seria permitir apenas o encaminhamento de porta para usuários específicos:

Do SSH: o guia definitivo

O encaminhamento de porta pode ser ativado ou desativado globalmente no sshd. Isso é feito com a palavra-chave de configuração em todo o servidor AllowTcpForwarding em / etc / sshd_config. A palavra-chave pode ter o valor yes (o padrão, habilitando o encaminhamento) ou no (desativando o encaminhamento):

# SSH1, SSH2, OpenSSH
AllowTcpForwarding no

Além disso, o SSH2 tem as seguintes opções:

# SSH2 only
AllowTcpForwardingForUsers
AllowTcpForwardingForGroups

A sintaxe é a mesma das opções AllowUsers e AllowGroups. [Seção 5.5.2.1, "Controle de acesso à conta"] Eles especificam uma lista de usuários ou grupos que têm permissão para usar o encaminhamento de porta; o servidor se recusa a atender solicitações de encaminhamento de porta para qualquer outra pessoa. Observe que eles se referem à conta de destino da sessão SSH, não ao nome de usuário do cliente (que geralmente não é conhecido).

...

É importante perceber que as diretrizes desta seção não impedem o encaminhamento de porta, a menos que você também desative os logons interativos e restrinja os programas que podem ser executados no lado remoto. Caso contrário, usuários experientes podem simplesmente executar seu próprio aplicativo de encaminhamento de porta na sessão SSH. Somente essas configurações podem ser um impedimento suficiente em uma comunidade não técnica, mas não impedirão alguém que saiba o que está fazendo.


1
Basicamente, terei apenas um usuário provisionado no S1. AFAIU, nesse caso específico, usar AllowTcpForwardingForUsers / AllowTcpForwardingForGroups não funcionará, certo? Proibir o login interativo é uma boa idéia, pois fará com que os usuários não consigam iniciar os binários. Mas qualquer cliente ainda poderá usar a sintaxe -L, certo? Portanto, por enquanto, as melhores opções seriam: 1 / Desativar logon interativo, 2 / PermitOpen com um nome de host falso: port. Perdi alguma coisa ?
SCO

A melhor maneira de verificar isso seria tentar a instalação.
Christian

Não consigo ver essas opções no software OpenSSH gratuito. Um google para AllowTcpForwardingForUsersrevela que está configurado em um sshd2_config, usado em alguns programas comerciais. Veja uma das respostas para: superuser.com/questions/384643/…
Kaz

^ O OpenSSH possui Matchblocos na configuração. Você pode Matchacessar usuários e grupos e incluir o AllowTcpForwardinginterior.
Kaz

2

Agora existe uma opção para permitir somente o encaminhamento local / remoto.

AllowTcpForwarding Especifica se o encaminhamento de TCP é permitido. As opções disponíveis são "yes" ou "all" para permitir o encaminhamento de TCP, "no" para impedir todo o encaminhamento de TCP, "local" para permitir somente o encaminhamento local (da perspectiva do ssh (1)) ou "remoto" para permitir o encaminhamento remoto encaminhamento apenas . O padrão é "yes". Observe que desativar o encaminhamento de TCP não melhora a segurança, a menos que os usuários também tenham acesso negado ao shell, pois sempre podem instalar seus próprios encaminhadores.

Portanto, como já foi dito, você também deve configurar o shell para nologin.


0

Minha solução para esse problema foi adicionar: PermitOpen fo.local: 80 na seção principal do sshd_config.

Isso simplesmente nega qualquer solicitação de encaminhamento local além de fo.local: 80.


0

Estou procurando uma maneira de desativar apenas encaminhamentos -L

Se eu entendi corretamente, seus usuários têm acesso total ao shell, mas você não deseja que eles possam abrir conexões com o resto da rede.

O "encaminhamento de porta local" permitido pelo SSH é apenas uma das maneiras possíveis de fazer isso. Outros incluem o lançamento de uma instância socat, netcatou qualquer outro número de ferramentas.

A melhor maneira de controlar as conexões de saída e de entrada no Linux é o Netfilter, também conhecido como IPTables.

Possui um módulo especial chamado owner ( ipt_owner) que permite combinar várias características do criador de pacotes, para pacotes gerados localmente. É válido nas cadeias OUTPUTe POSTROUTING.

Você pode usá-lo para negar pacotes de saída gerados por certos grupos de usuários, impedindo assim qualquer tipo de encaminhamento de porta, não apenas a -Lopção do SSH.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.