Os meus iptables são seguros?

Question

Eu tenho isso no meu rc.local no meu novo servidor Ubuntu:

iptables -F

iptables -A INPUT -i eth0 -p tcp --sport 22 -m state --state ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT

iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp --sport 22 -m state --state ESTABLISHED -j ACCEPT

iptables -A OUTPUT -o eth0 -p tcp --dport 9418 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --sport 9418 -m state --state ESTABLISHED -j ACCEPT

iptables -A OUTPUT -o eth0 -p tcp --dport 5000 -m state --state NEW,ESTABLISHED -j ACCEPT # Heroku
iptables -A INPUT -i eth0 -p tcp --sport 5000 -m state --state ESTABLISHED -j ACCEPT # Heroku

iptables -A INPUT -p udp -s 74.207.242.5/32 --source-port 53 -d 0/0 --destination-port 1024:65535 -j ACCEPT
iptables -A INPUT -p udp -s 74.207.241.5/32 --source-port 53 -d 0/0 --destination-port 1024:65535 -j ACCEPT

iptables -A OUTPUT -o eth0 -p tcp --dport 443 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --sport 443 -m state --state ESTABLISHED -j ACCEPT

iptables -P INPUT DROP
iptables -P FORWARD DROP

9418 é a porta do Git. 5000 é uma porta usada para gerenciar aplicativos Heroku. E 74.207.242.5 e 74.207.241.5 são nossos servidores DNS.

Você acha que isso é seguro? Você pode ver algum buraco aqui?

Atualização: Por que é importante bloquear o OUTPUT? Esta máquina será usada somente por mim.

    

Answer 1

O único buraco importante que vejo é o IPv6. Você precisará de ip6tables para isso. Se algum dos seus serviços escutar no IPv6 (e muitos deles, incluindo ssh, escutar IPv6 por padrão), então um invasor pode usar isso para ignorar completamente todas as regras que você tem acima. As redes usarão o IPv6 em preferência ao IPv4 quando ele estiver disponível.

Supondo que sua política OUTPUT seja DROP , você restringiu muito bem o IPv4.

Ignorar a opção RELATED pode significar que você recebe tempo limite em vez de rejeições instantâneas quando um serviço fica inativo e para de escutar, por entender que TCP RST pacotes não são NEW ou ESTABLISHED neste contexto.

Para responder à atualização da sua pergunta: para quando não é usado apenas por você.

Não importa o quão cuidadosos todos nós somos, a possibilidade sempre permanece de que perdemos alguma coisa ou somos momentaneamente descuidados e permitimos a alguém alguma medida de controle sobre nossa caixa. A primeira coisa que um atacante fará depois de ter um toe-hold é baixar um kit de escalonamento de privilégio, um rootkit, seu sistema de comando e controle e o que quer que ele realmente queira executar na caixa. Restringir conexões de saída significa que eles não podem fazer o download desse kit de escalonamento de privilégios, o que significa que eles estão presos em execução como o usuário do Apache ou o usuário do Git ou o que eles conseguiram atacar. Sem privilégios de root, eles não podem se esconder e não podem modificar o firewall. Isso não vai parar um atacante para sempre, mas pode detê-lo por tempo suficiente para você perceber que ele está lá ou frustrá-lo o suficiente para que ele desista e vá para algum lugar mais fácil.

As regras acima significam que um ataque de inclusão de arquivo remoto só funcionará se o arquivo remoto estiver hospedado em SSL. Se você colocar um servidor proxy entre esta caixa e a internet e permitir que apenas alguns padrões de URL sejam permitidos, você poderá interromper o RFI em suas trilhas enquanto ainda permitir a operação normal. Isso é defesa em profundidade .

    

Answer 2

Além dos comentários postados pelos outros caras sobre a falta das regras OUTPUT chain e ESTABLISHED repetidas, você pode restringir protocolos como SSH (TCP / porta 22) a IPs específicos, se aplicável.

Para verificar sua configuração, você pode tentar o NMAP para verificar as portas abertas. Isso pode ser mais útil caso suas regras de firewall se tornem mais complicadas.

    

Answer 3

Você deve executar o script a partir de uma linha de pré-inicialização em / etc / network / interfaces (consulte man 5 interfaces ) para que as regras de firewall estejam em vigor ANTES de a rede estar disponível e os serviços serem iniciados. rc.local é a última coisa que corre, então há uma janela desnecessária de tempo onde as coisas estão desprotegidas.

É também sensato ter em mente que esse tipo de coisa que você está fazendo não é algum tipo de mágica. Se houver outros serviços que você está olhando mas tentando impedir o acesso, você não deve iniciá-los em primeiro lugar. Se a ideia aqui é impedir o acesso a serviços que você não pretende iniciar, isso significa que pessoas não confiáveis já estão fazendo coisas em sua máquina? Nesse caso, você já perdeu, e é seguro assumir que, no momento em que você tem usuários mal-intencionados executando código em sua caixa, que suas regras de firewall também podem ser manipuladas.

    

Answer 4

eu open-source iptables-boilerplate no github alguns dias atrás. é essencialmente um bom conjunto de regras de iptable pré-definidas e é extensivamente comentado.

talvez o uso e a leitura possam ajudá-lo