Práticas recomendadas: aplicando regras de firewall do iptables para SSH

Question

Eu preciso adicionar algumas regras de firewall em nosso ambiente de controle de qualidade usando iptables . Eu tenho que fazer as mudanças remotamente. Algumas das alterações também incluem a desativação de SSH para poucas redes.

Quais são as práticas recomendadas que posso seguir para que, se SSH service for bloqueado de alguma forma, como restaurar meu acesso sem reinicializar o host?

Algumas das coisas que estou planejando são:

chkconfig iptables off 

Isso ocorre no caso de precisarmos reinicializar o host, para que iptables não seja inicializado.

Mas isso é para quando eu reiniciar o host, estou procurando algo para que possamos restaurar de volta sem reiniciar o host. BTW, console não está disponível para o servidor.

Alguma sugestão?

    

Answer 1

É para isso que serve o iptables-apply . Do página man :

iptables-apply will  try  to  apply  a  new  rulesfile  (as  output  by
   iptables-save,  read by iptables-restore) or run a command to configure
   iptables and then prompt the user whether the changes are okay. If  the
   new  iptables  rules  cut the existing connection, the user will not be
   able to answer affirmatively. In this case, the script  rolls  back  to
   the previous working iptables rules after the timeout expires.

O tempo limite padrão é de 10 segundos. Se isso for muito curto, pode ser alterado com --timeout 30 para redefinir a regra após 30 segundos, se nenhuma confirmação tiver sido recebida.

    

Answer 2

A abordagem que geralmente faço para uma tarefa como essa é garantir que eu tenha uma regra à prova de falhas no início da cadeia INPUT que permite explicitamente minha conexão de gerenciamento existente. Isso garantirá que quaisquer regras subsequentes que possam impedir uma conexão não afetarão a atual. Uma vez que eu tenho todas as regras no lugar, eu então testo com uma segunda conexão que deve ser aceita, mas que não corresponde à regra de segurança contra falhas. Se isso funcionar, sei que posso desconectar com segurança a minha sessão original e remover a regra de segurança contra falhas.

Por exemplo, digamos que você queira permitir o SSH a partir de 192.168.0.0/16, exceto 192.168.2.0/24, e você está atualmente conectado ao servidor a partir de 192.168.22.22. Para proteger-se contra um possível erro de digitação, você pode definir suas regras da seguinte forma:

iptables -I INPUT -p tcp -s 192.168.22.22  --dport 22 -j ACCEPT
iptables -I INPUT -p tcp                   --dport 22 -j LOG
iptables -A INPUT -p tcp -s 192.168.2.0/24 --dport 22 -j DROP
iptables -A INPUT -p tcp -s 192.168.0.0/16 --dport 22 -j ACCEPT

Nesse caso, inserimos a primeira regra com -I , de modo que ela está no início da cadeia, e adicionamos as outras com -A para que sejam colocadas no final. Suas regras são provavelmente mais complexas do que isso, mas o objetivo é garantir que sua regra à prova de falhas venha primeiro. Dessa forma, mesmo que você digite por engano 192.168.22.0/24 na segunda linha, sua linha à prova de falhas coincidirá primeiro, garantindo que você mantenha o acesso.

Teste as regras tentando conectar-se de algum lugar em 192.168.0.0/16 que não seja 192.168.22.22 ou 192.168.2.0/24. Independentemente do resultado, ele deve ser registrado em /var/log/kern.log . Se a conexão falhar, você saberá que tem mais trabalho a fazer; o log pode ajudá-lo a determinar por que ele falhou também.

Depois que seus testes forem bem-sucedidos, você poderá remover com segurança a regra de segurança contra falhas:

iptables -D INPUT -p tcp -s 192.168.22.22 --dport 22 -j ACCEPT