Eu corro um servidor que envia e-mails através de smtp.mailgun.org. Bloqueei o servidor para permitir apenas SMTP de saída na porta 587 para smtp.mailgun.org.
O endereço IP deste domínio mudou recentemente e, como resultado, meu sistema parou de enviar e-mails. Como parte da tentativa de descobrir o que havia parado de funcionar, fiquei ciente das desvantagens de usar nomes de domínio nas regras do iptables, bem como do fato de que o iptables faz uma pesquisa quando você executa a regra e salva o endereço IP no momento em que a regra é criado, portanto, as alterações de endereço IP nos domínios não são refletidas no iptables.
Na página de status do mailgun, eles dizem
Nossas atualizações de infraestrutura resultarão em alterações mais frequentes nesses endereços IP no futuro e os clientes devem garantir que estejam usando apenas nossos nomes de host suportados ao se conectarem ao serviço Mailgun.
Não fui notificado sobre uma alteração de endereço IP e não sei se serei notificado sobre alterações futuras.
Qual é a melhor forma de gerir esta situação? Devo escrever um script que verifique regularmente o endereço IP de smtp.mailgun.org e atualize o iptables quando ele mudar? (Estou ciente dos riscos de segurança ao fazer isso, mas talvez valha a pena correr).
Uma rápida olhada nos endereços IP atuais de smtp.mailgun.org revela que eles estão todos na Amazon AWS. Você deve esperar que eles mudem com frequência e, portanto, codificá-los no firewall torna-se complicado, na melhor das hipóteses. Você pode perder e-mails enviados mesmo com um script dinâmico, pois o endereço IP pode mudar e você tenta enviar e-mails antes da próxima execução do script. Isso é chamado de condição de corrida. Não há muito que você possa fazer a não ser redesenhar, e é isso que eu recomendo...
Quanto ao firewall de saída, realmente não tenho muita preocupação com o tráfego de saída para a porta 587. Todo esse tráfego precisa ser autenticado no servidor de correio remoto de qualquer maneira, portanto, não é uma preocupação significativa para mim. Para correio, preocupo-me com o tráfego de saída para a porta 25; se você estiver usando um serviço como mailgun, não deve haver esse tráfego e, se houver, é quase certo que você foi comprometido.
Algumas coisas que você pode considerar são:
Permitir qualquer tráfego TCP de saída para a porta de destino 587. Conforme explicado acima, isso é um risco relativamente baixo, mas você pode reduzir ainda mais o risco...
Execute seu aplicativo da web com um ID de usuário exclusivo e, em seguida, permita qualquer tráfego TCP de saída para a porta de destino 587 apenas para esse ID de usuário. (Use a
-m ownercorrespondência.) Isso reduz ainda mais o risco, estipulando que apenas o usuário do aplicativo da web pode iniciar esse tráfego. Observe que, se você fizer isso, outros usuários não poderão fazer essa conexão de saída, nem mesmo o root (mas o root pode alterar as regras do firewall para tornar isso possível).Você pode tornar sua configuração mais robusta executando um servidor de e-mail somente local configurado para usar o mailgun como um smarthost, retransmitindo todos os e-mails recebidos (como ele escuta apenas localmente, isso deve vir apenas do seu aplicativo da web). Em seguida, você permite que apenas o ID do usuário do servidor de correio faça conexões de saída para a porta 587 como acima. Isso lhe dá o benefício adicional de não perder e-mails porque mailgun estava inacessível no momento em que seu aplicativo da web tentou enviar e-mails. Se o mailgun estiver inacessível, devido a problemas de rede ou firewall mal configurado ou qualquer outro motivo, seu aplicativo da web registrará um erro e perderá o e-mail, mas o servidor de e-mail local colocará o e-mail na fila e o entregará quando o serviço for restaurado. Em seguida, você configura o aplicativo da web para entregar localmente.