O iptables é horrível e existem pessoas que conseguem tornar a experiência de usá-lo ainda pior. Já perdi a conta de quantas vezes eu tive que dar manutenção em scripts com zilhares de linhas e simplesmente era quase inviável. Às vezes é mais fácil simplesmente zerar tudo e começar de novo. E acredite, você vai facilmente jogar mais da metade das linhas no lixo. Vai descobrir que existem regras redundantes e que não servem pra nada.

Um das regras mais inúteis que sempre vejo são as de log. Me diz, você vai ver o log? Vai mesmo? Realmente importa saber se alguém tentou se conectar na sua máquina na porta 139? Não, não importa. Você quer saber toda vez que alguém se logou no ssh, aí coloca lá um -p tcp --dport 22 -m state --state NEW -j LOG. Simplesmente redundante, o importante é saber qual é o usuário que está logando e se a sessão foi criada com sucesso e pra isso já tem o log do sshd. Tire as regras de log do seu firewall, agora. Log tem que ser gerado para ser lido. Deixe as regras que sigam esse critério: se ninguém vai precisar ver, então não serve.

Outra mania infernal é usar nomes nada descritivos de variáveis no script, como $IF_EXT, $IF_INT, etc. Com uma máquina de duas interfaces não tem muito problema, é interno e externo. Agora coloque aí uma terceira. Qual é o crime de se usar um nome de verdade e não abreviações?

If you have a function that counts the number of active users, you should call that count_active_users() or similar, you should not call it cntusr().

Encoding the type of a function into the name (so-called Hungarian notation) is brain damaged.

Faço das palavras do Linux kernel coding style as minhas.

Antes de colocar uma regra no firewall, você tem certeza absoluta que não consegue configurar sua aplicação corretamente? Certeza mesmo? Por exemplo, você instalou o Squid no servidor e obviamente não quer que ele receba conexões da Internet, e para isso você põe uma regra no firewall bloqueando a porta 3128. Errado! Antes de mexer no firewall, configure sua aplicação, no caso o Squid, para que ela ouça apenas na interface interna, não deixando nenhuma porta aberta na interface externa.

Existem duas correntes de pensamento na configuração de firewalls: uma acha que o melhor é ignorar tudo, usando DROP, e outra que acha importante que uma resposta seja enviada, usando REJECT. Por padrão, se alguém tentar se conectar a um destino onde não há ninguém ouvindo e aguardando conexões, como um servidor HTTP ou SMTP, o sistema operacional manda resposta ICMP avisado que não há ninguém para receber uma conexão. Se usar DROP no iptables, o sistema recebe o pedido de conexão e joga fora, não enviando uma resposta ao requisitante de que não há nada ali. Eu acho certo que sua máquina responda ao requisitante que não há nada, retornando erro. Imagine que você é o cara que dar uma olhadinha em um IP, pega o nmap e manda vasculhar. Algumas portas voltam como filtered. Pode ser que tem alguma coisa lá, ou não. Porém, as portas que deram retorno e o SO respondeu que não há nada, você certamente vai ignorar e voltar sua atenção para o que foi filtrado. Ou seja, dar a privilégio da dúvida a um atacante nem sempre pode ser eficaz.

Faça um script de firewall coerente e enxuto. Use nomes simples e claros para variáveis. Log somente o estritamente necessário e algo que realmente deva chamar sua atenção. Configure seus serviços para ouvir apenas nas interfaces necessárias. A próxima pessoa que dará manutenção no seu script agradece.