Na verdade, seu conjunto de regras deve ser bom para pacotes de saída: o problema é que as respostas recebidas para esses pacotes estão sendo rejeitadas.
O principal problema é esta linha:
-A INPUT -p tcp -m tcp --sport 1024:65535 --dport 20:65535 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
Por exemplo, quando você está tentando executar uma atualização de pacote, a ferramenta apt enviará uma conexão para um servidor espelho Debian, tipicamente para a porta de destino 80 para HTTP. A porta de origem será uma porta alta aleatória (certamente acima de 1024, digamos 12345).
A resposta a este pacote retornará do espelho Debian com os números de porta de origem e destino invertidos: o número da porta de origem da resposta será 80 e o número da porta de destino será 12345.
Mas sua regra de entrada não corresponderá a nenhum pacote de entrada com porta de origem inferior a 1024, independentemente de serem conexões novas ou já estabelecidas. Como resultado, você está enviando solicitações de conexão para a porta 80, mas fica surdo a todas as respostas que retornam.
Eu recomendaria o seguinte como suas primeiras duas regras de entrada:
-A INPUT -i lo -j ACCEPT # accept anything from the loopback interface
-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
A primeira linha aceitará qualquer coisa que passar pela interface de loopback, ou em outras palavras, processos em seu próprio computador conversando entre si usando protocolos de rede. Quando o tráfego entra pela interface de loopback, a fonte é, por definição, no mesmo computador, portanto, normalmente há poucas razões para bloqueá-los.
A segunda linha aceita quaisquer respostas recebidas válidas para quaisquer conexões de saída e qualquer coisa relacionada a elas (por exemplo, um pacote de erro ICMP informando o que está errado em uma determinada tentativa de conexão). Se o auxiliar de rastreamento de conexão especial apropriado para FTP tiver sido ativado, essa linha também cuidará das conexões de dados FTP, ativas ou passivas. Leia em ...
(A correspondência -m state que você está usando é obsoleta e está ficando obsoleta; meu -m conntrack --ctstate ESTABLISHED,RELATED é basicamente a versão atualizada dela.)
As conexões FTP serão muito mais fáceis de manipular se você chamar o auxiliar de rastreamento de conexão apropriado para elas. Isso costumava ser automático antes de , mas alguém encontrou uma maneira de abusar da seleção do ajudante automático e teve que ser desativado.
Portanto, diga ao sistema que esperamos que quaisquer conexões de entrada da sua rede com a porta TCP 21 sejam conexões de controle FTP válidas:
-t raw -A PREROUTING -p tcp -s yyy.yyy.yyy.yyy/25 --dport 21 -j CT --helper ftp
À medida que uma conexão FTP de controle de entrada é estabelecida, o auxiliar do FTP conntrack monitora quaisquer comandos de transferência de arquivos emitidos e fará com que o subsistema conntrack fique ciente de quaisquer conexões de dados FTP relacionadas, para que o anterior "ESTABELECIDO, RELACIONADO" regra irá aceitá-los e apenas eles: não há necessidade de manter um vasto leque de portas abertas para possíveis conexões de dados FTP mais!
Quando o auxiliar FTP conntrack estiver em uso, você não precisará mais de nenhuma regra para a porta 20 nem de suas regras com --sport 1024:65535 ou --dport 20:65535 .
Tentativas de seqüestrar conexões de dados FTP passivas serão automaticamente frustradas também: o subsistema de rastreamento de conexão verá que a conexão do invasor não vem da mesma origem que a conexão de controle FTP que solicitou a transferência de dados e, portanto, a tentativa de seqüestro não será correspondido e será rejeitado por padrão.
Se você estiver usando espelhos FTP para suas atualizações Debian, você também precisará de um tratamento similar para qualquer conexão FTP de saída. Isso pode ser feito com:
-t raw -A OUTPUT -p tcp --dport 21 -j CT --helper ftp