Está aceitando RELACIONADO, ESTABELECIDO para todas as fontes em iptables consideradas “muito abertas”?

Question

Eu sempre vi a regra -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT aplicada. Embora eu não seja um especialista, essa linha em particular me preocupa. É bastante óbvio que a regra permite o tráfego all com a única exceção de que a conexão deve ter sido estabelecida ou relacionada a uma conexão estabelecida.

Cenário

• Vou permitir conexões com a porta SSH padrão 22 dos servidores LAN na sub-rede 192.168.0.0/16 ou qualquer outra coisa.
• SuperInsecureApp® expõe algo na porta 1337 , que eu adiciono à minha corrente INPUT .
• Adicionei a regra conntrack para aceitar ESTABLISHED e RELATED de todas fontes
• Política de encadeamento é DROP

Então, basicamente, essa configuração só permite conexões SSH da LAN, enquanto permite o tráfego de entrada na porta 1337 do mundo.

É aqui que minha confusão floresce. Será que o conntrack de alguma forma exporia uma falha de segurança que permitiria obter uma conexão estabelecida em 1337 (uma vez que o mundo é aberto), e então utilizar essa conexão para obter acesso à porta SSH ( ou qualquer outra porta para esse assunto)?

    

Answer 1

Eu não consideraria o tráfego ESTABELECIDO e RELACIONADO muito aberto. Você pode ser capaz de omitir RELATED, mas deve definitivamente permitir ESTABLISHED. Ambas as categorias de tráfego usam estados conntrack.

Conexões ESTABELECIDAS já foram validadas por outra regra. Isso torna muito mais simples a implementação de regras unidirecionais. Isso só permite que você continue transações na mesma porta.

As conexões RELACIONADAS também são validadas por outra regra. Eles não se aplicam a muitos protocolos. Novamente eles tornam muito mais simples configurar regras. Eles também garantem o sequenciamento adequado das conexões onde elas se aplicam. Isso realmente torna suas regras mais seguras. Embora isso possa possibilitar a conexão em uma porta diferente, essa porta só deve fazer parte de um processo relacionado, como uma conexão de dados FTP. Quais portas são permitidas são controladas por módulos conntrack específicos do protocolo.

Ao permitir conexões ESTABLISHED e RELATED, você pode se concentrar em quais novas conexões deseja que o firewall aceite. Também evita regras quebradas destinadas a permitir o tráfego de retorno, mas que permitem novas conexões.

Dado que você classificou o programa na porta 1337 como inseguro, ele deve ser identificado usando um ID de usuário não-root dedicado. Isso limitará o dano que alguém poderá causar se conseguir executar o aplicativo e obter acesso aprimorado.

É altamente improvável que uma conexão na porta 1337 possa ser usada para acessar a porta 22 remotamente, mas é possível que uma conexão com a porta 1337 possa ser usada para fazer proxy de uma conexão com a porta 22.

Você pode querer garantir que o SSH seja protegido em profundidade:

• Use hosts.allow para limitar o acesso, além das restrições do firewall.
• Evite o acesso root, ou pelo menos exija o uso de chaves e limite seu acesso no arquivo authorized_keys.
• Auditoria de falhas de login. Um scanner de log pode enviar relatórios periódicos de atividade incomum.
• Considere usar uma ferramenta como o fail2ban para bloquear automaticamente o acesso em falhas de acesso repetidas.

Answer 2

ESTABELECIDO e RELACIONADO são características da filtragem de pacotes "stateful", em que a filtragem não depende apenas de um conjunto de regras estático, mas também do contexto em que os pacotes são considerados. Você precisa ESTABELECIDO para permitir que as conexões funcionem e você precisa de RELATED para mensagens ICMP relevantes. A filtragem com preservação de estado permite filtrar com mais precisão em comparação com as regras estáticas "sem estado".

Vamos dar uma olhada primeiro em ESTABLISHED. Por exemplo, considere TCP na porta 22. O iniciador (cliente) envia um SYN para serverIPaddr:22 . O servidor retorna SYN+ACK para o cliente. Agora é a vez do cliente enviar um ACK . Como deve ser a regra de filtragem no servidor, de modo que apenas a "correspondência" ACK seja aceita? Uma regra geral sem estado seria parecida com

-A INPUT --proto tcp --port 22 -j ACCEPT

que é mais liberal do que a regra stateful de acordo. A regra sem estado permite segmentos arbitrários de TCP, por ex. ACK ou FIN sem ter estabelecido uma conexão primeiro. Os scanners de portas podem explorar esse tipo de comportamento para a impressão digital do SO.

Agora vamos dar uma olhada no RELATED. Isso é usado para mensagens ICMP, principalmente mensagens de erro. Por exemplo, se um pacote do servidor para o cliente for descartado, uma mensagem de erro será enviada ao servidor. Esta mensagem de erro está "relacionada" à conexão estabelecida anteriormente. Sem a regra RELATED, seria necessário permitir mensagens de erro de entrada em geral (sem contexto) ou, como é costume para muitos sites, descartar o ICMP completamente e esperar por tempo limite na camada de transporte. (Observe que essa é uma má ideia para o IPv6; o ICMPv6 desempenha um papel mais importante para o IPv6 do que o ICMP para o legado do IP.)