Regras de firewall para conexões RSH de saída

Question

Eu tenho um servidor CentOS 6 que precisa de acesso rsh a um de nossos antigos servidores legados que não suportam ssh.

O RSH se conecta à porta 514 nos servidores remotos, o que cria outra conexão de volta ao cliente em uma porta entre 512-1023. Meu nível de habilidade atual de firewall é "porta aberta / porta fechada" e a abertura de todos eles não deixaria muito de um firewall. Qual é a maneira mais restritiva de permitir conexões RSH de saída?

    

Answer 1

Eu restringiria a entrada do intervalo de servidores usando iptables -A INPUT --src {IP address or range}/{netmask} -m state --state NEW -m tcp -p tcp --dport 514:1023 -j ACCEPT .

Você pode restringir os intervalos de portas de entrada para os servidores corretos

A menos que você precise restringir dados de saída de um servidor específico, não me preocupo com a configuração de regras de saída.

Eu uso o webmin para configurar minhas regras básicas, depois copio-as manualmente (é mais rápido e evita que eu procure todas as informações que não uso regularmente). O Webmin suporta todos os tipos de regras - entrada, saída e mangle. Você pode configurar o webmin em uma caixa de teste e editá-lo, depois escrever as regras e copiá-las para o servidor apropriado.

    

Answer 2

No Ubuntu 18.04 com pacotes rsh-redone-client / server instalados, o rsh / rlogin para outro host na LAN (executando o CentOS 6) estava bloqueando por um longo tempo (cerca de 30 segundos) até eu abrir a porta 113 (auth) no firewall local para conexões de entrada da LAN. Não tenho certeza de como foi, eventualmente (após esses ~ 30 segundos) o evento de trabalho sem a porta 113 aberta. Provavelmente o servidor permitiu a conexão depois de algum tempo limite.

    

Answer 3

Alguns serviços antigos incluem um recurso que enviará uma consulta de nome de usuário de volta ao host do cliente em cada conexão de entrada. Serviços que eu vi para incluir este recurso:

• FTP em servidores Unix proprietários antigos
• rsh / rlogin / rexec
• IRC

A consulta de nome de usuário tem uma porta TCP de destino 113, originalmente conhecida como auth port, posteriormente renomeada para ident , pois foi reconhecido que não tinha nada a ver com qualquer autenticação real. Nos primórdios da Internet, quando a maioria dos sistemas conectados via TCP / IP eram sistemas Unix multiusuários, este serviço tomava como entrada o endereço IP e os números de porta de origem + destino de outra conexão TCP, e procurava o lado do cliente. nome de usuário associado à conexão.

Hoje, uma divulgação cegamente confiável e facilmente spoofável de nomes de usuários obviamente não é uma coisa boa.

Na maioria dos casos, o serviço que está fazendo a consulta ident / auth aceitará que a informação não está disponível - mas você deve aceitar ou rejeitar a consulta: se você simplesmente a soltar, o usuário verá atrasos de conexão de até 30 segundos, até que o lado do servidor desista. A rejeição ideal seria semelhante ao que aconteceria se um host não tivesse um firewall ativo, mas não tivesse nenhum serviço escutando na porta TCP 113, ou seja, um pacote TCP Reset.

Para regras iptables, isso significa que você deve usar uma regra REJECT em vez de DROP para a porta TCP 113, se estiver usando serviços legados que ainda enviam ident consultas.

Algo como isso deve rejeitar as ident consultas de maneira a minimizar os atrasos:

iptables -I INPUT -p tcp --dport 113 -j REJECT --reject-with tcp-reset

Se você tem medo de alguém abusar disso para gerar um ataque de negação de serviço, adicione uma regra de limitação de taxa para a porta TCP 113 antes dessa regra. Mas eu entendo que os drivers de rede mais modernos já irão lidar com o envio de respostas TCP Reset como uma tarefa de prioridade muito baixa por padrão, então pode não ser um risco muito significativo.