Necessito auxílio para "limpar" um firewall

removido
(usa Nenhuma)

Enviado em 21/04/2017 - 03:32h

Este firewall é tão grotesco que pensei umas dez vezes entes de mostrá-lo e umas vinte antes de solicitar auxílio.

Tenho um script de firewall que tem funcionado bem quando necessito, mas acontece de que ele é bem imperfeito e paranoico, cheio de coisas excessivas e que podem ser cortadas e ajustadas. Gostaria de submetê-lo para apreciação e, se possível, receber orientação do que pode ser limpo nele.

Até tenho livro de redes que fala de iptables, mas as citações são sobre como criar desvios de stream e roteamento. Não falam sobre bloqueio destas coisas. A ideia é fazer um script de defesa agressiva, que bloqueia tudo praticamente.

É um script meio que frankenstein, cheio de partes de montes de scripts, que foram eliminadas duplicações, mas mesmo assim está carregado. Inclusive está dando problema em uma das máquinas reais de teste. Em algumas outras máquinas não deu problema. Por um acaso o ambiente gráfico de teste foi o XFCE4.

Os trechos de LOGS são testes para saber como e onde sairiam as informações.

Ele está bloqueando as conexões de internet da máquina que deu pau. Lá vai:

fw() {

	echo "0" | tee /proc/sys/net/ipv4/ip_forward > /dev/null
	echo "1" | tee /proc/sys/net/ipv4/conf/*/rp_filter > /dev/null
	echo "0" | tee /proc/sys/net/ipv4/icmp_echo_ignore_all  > /dev/null
	echo "1" | tee /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts > /dev/null
	echo "1" | tee /proc/sys/net/ipv6/conf/*/disable_ipv6 > /dev/null

	iptables -A INPUT -i lo -j ACCEPT

#	iptables -A INPUT --dport 21,22,25,80,135,137,139,443,3306 -m iprange --src-range 192.168.0.0-192.168.255.255 -j LOG --log-prefix "@P:-> "
#	iptables -A INPUT --dport 21,22,25,80,135,137,139,443,3306 -m iprange --src-range 192.168.0.0-192.168.255.255 -j DROP

	iptables -A INPUT -s 127.0.0.10 -j LOG --log-prefix "@@s-> "
	iptables -A INPUT -s 127.0.0.10 -j DROP
        iptables -A INPUT -d 127.0.0.10 -j LOG --log-prefix "@@d-> "
        iptables -A INPUT -d 127.0.0.10 -j DROP

        iptables -A OUTPUT -s 127.0.0.10 -j LOG --log-prefix "@@s-> "
        iptables -A OUTPUT -s 127.0.0.10 -j DROP
	iptables -A OUTPUT -d 127.0.0.10 -j LOG --log-prefix "@@d-> "
	iptables -A OUTPUT -d 127.0.0.10 -j DROP

	iptables -A INPUT -p tcp --syn -j LOG --log-prefix "syn -> "
	iptables -A INPUT -p tcp --syn -j DROP

	iptables -A INPUT -p udp --dport 0:1023 -j DROP

	iptables -A INPUT -s 239.255.255.250/255.255.255.0 -j LOG --log-prefix "M$ -> "
	iptables -A INPUT -s 239.255.255.250/255.255.255.0 -j DROP

#	iptables -A INPUT -s 192.168.2.47/255.255.255.0 -p tcp --dport 445 -j DROP

	iptables -A INPUT -s 192.168.14.252/255.255.255.240 -j LOG --log-prefix "s--> "
	iptables -A INPUT -s 192.168.14.252/255.255.255.240 -j DROP

	iptables -A INPUT -p udp -s 0/0 -i eth0 --dport 33435:33525 -j LOG --log-prefix "udp -> "
	iptables -A INPUT -p udp -s 0/0 -i eth0 --dport 33435:33525 -j DROP

	iptables -A INPUT -i eth0 -p tcp --dport :32000 -j DROP
	iptables -A INPUT -i eth0 -p udp --dport :32000 -j DROP
	iptables -A INPUT -p icmp --icmp-type echo-request -j DROP

	iptables -A INPUT -i eth0 -p tcp --sport 6000:6255 -j DROP
	iptables -A INPUT -i eth0 -p tcp --dport 6000:6255 -j DROP

	iptables -A FORWARD -p tcp --tcp-flags ALL SYN -j DROP
	iptables -A FORWARD -p tcp --tcp-flags ALL SYN,ACK -j LOG --log-prefix "SYN/ACK-> "
	iptables -A FORWARD -p tcp --tcp-flags ALL SYN,ACK -j DROP

#	iptables -A OUTPUT -p tcp --dport 80 ! -s 127.0.0.1 -j -log-prefix "P80 -> "
#	iptables -A OUTPUT -p tcp --dport 80 ! -s 127.0.0.1 -j DROP
#	iptables -A OUTPUT -p tcp --dport 3306 ! -s 127.0.0.1 -j -log-prefix "P3306 -> "
#	iptables -A OUTPUT -p tcp --dport 3306 ! -s 127.0.0.1 -j DROP

# bloqueia conexoes de dentro pra fora:

#	for i in 21 22 23 80 86 139 443 445 631 901 3306 5190; do
#		iptables -A OUTPUT -p tcp --dport "$i" -j DROP
#	done;

# log
#	 iptables -A FORWARD -m limit --limit 3/minute --limit-burst 3 -j LOG

} 

Sugestões? Desde já agradeço.

zenull
(usa Outra)

Enviado em 28/04/2017 - 02:51h

Um pouco mais de paranoia:
http://www.clubedohardware.com.br/forums/topic/1118532-tutorial-firewall-seguro-no-linux-avan%C3%A7a...

Não é o que pediu, mas talvez tenha alguma utilidade.

Buckminster
(usa Debian)

Enviado em 28/04/2017 - 10:06h

Vamos fazer como o esquartejador, por partes.

Que máquina é essa:
127.0.0.10

E qual o IP da máquina que está dando pau?

Algumas explicações:
" --syn :: Somente corresponde pacotes TCP com o bit SYN e com os bits RST, ACK e FIN limpos. Esses pacotes são utilizados para solicitar o início da conexão TCP, por exemplo, bloquear esses pacotes em uma interface vai evitar conexões TCP de entrada, mas as conexões TCP de saída não serão afetadas. É equivalente a --tcp-flags syn, rst, ack, fin syn. Se o "!" precede a flag "--syn", o sentido da opção é invertido.

--tcp-flags mask comp :: Combina quando as flags TCP estão especificadas. O primeiro argumento mask é a flag que devemos examinar, escrito como uma lista separada por vírgulas, e o segundo argumento deve ser uma lista de flags separadas por vírgula. As flags são: syn ack fin rst urg psh all none.

Por exemplo:

# iptables -a FORWARD -p tcp --tcp-flags syn,ack,fin,rst syn

Só irá corresponder pacotes com a flag syn, as flags fin, ack e rst não serão setadas."

Acredito que o problema com a máquina em questão está nas regras

iptables -A INPUT -p tcp --syn -j DROP
e
iptables -A FORWARD -p tcp --tcp-flags ALL SYN -j DROP
e
iptables -A FORWARD -p tcp --tcp-flags ALL SYN,ACK -j DROP

Em regras como esta
iptables -A INPUT -i eth0 -p tcp --dport :32000 -j DROP
não foi especificada a primeira porta (:32000), então a porta "0" é assumida, ou seja, todo o intervalo entre as portas 0 e 32000 está sendo bloqueado. Ou você coloca uma porta aí ou tira o sinal de : se você quer que somente a porta 32000 seja bloqueada.

Outras explicações, básicas:
O iptables lê as regras de cima para baixo, de acordo com cada tabela, ou seja, se uma regra bloquear tudo numa determinada tabela, as exceções (liberações) devem ser colocadas acima desta regra.

Exemplo:

iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j REJECT
iptables -A INPUT -p tcp --dport 443 -j DROP

A primeira regra libera, a segunda rejeita e a terceira regra, nega o acesso. A primeira regra é que terá o privilégio, então, o acesso na porta 443 será liberado para todos, mesmo rejeitando e negando o acesso nas regras subsequentes.

Caso queiramos negar o acesso à porta 443 somente para alguns IPs, por exemplo, devemos colocar essas regras ACIMA da primeira regra.
Lembrando que nas regras acima não foi determinada nenhuma tabela (-t), então, elas serão aplicadas somente na tabela padrão, a filter, e, no caso, somente na chain INPUT.

No momento é isso, vamos por partes.

removido
(usa Nenhuma)

Enviado em 29/04/2017 - 06:10h

Olá. Obrigado por me responder. Tentarei ser sucinto.

O IP da máquina é algo configurado internamente como 192.168.12.101.

O comando iptables -A INPUT -i eth0 -p tcp --dport :32000 -j DROP seria para bloquear as quase 32000 primeiras portas, por paranoia pura. Tanto quanto a confguração 33435:33525. Pode ser com a 0 ou com a 1, se não houver problema. Porta 0 é algum tipo de "broadcast" de portas, se me entende?

O comando iptables -A INPUT -i eth0 -p tcp --sport 6000:6255 -j DROP seria para bloquear conexões do servidor gráfico X na interface de rede principal, tanto partindo de origem como de destino.

O endereço 127.0.0.10 seria uma configuração no arquivo /etc/hosts para bloquear endereços em requisições indesejadas.
A ideia vem do arquivo http://winhelp2002.mvps.org/hosts.txt que costumava ser atualizado periodicamente com endereços novos.
Ao invés de jogar para 0.0.0.0 imaginei que poderia ser mais saudável jogar para um IP de loopback e travá-lo no iptables.
Isto é assim mesmo? É correto? Pode ser melhorado/consertado?

Bloquear pacotes com syn ativado seria no caso para bloqueio de conexões externas, cuja necessidade seria dispensada.
Seriam apenas requisições de dentro para fora. Mas se não há daemons em escuta rodando, seria necessário? Outro caso de paranoia?

Há ainda o início com

	echo "0" | tee /proc/sys/net/ipv4/ip_forward > /dev/null
	echo "1" | tee /proc/sys/net/ipv4/conf/*/rp_filter > /dev/null
	echo "0" | tee /proc/sys/net/ipv4/icmp_echo_ignore_all  > /dev/null
	echo "1" | tee /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts > /dev/null
	echo "1" | tee /proc/sys/net/ipv6/conf/*/disable_ipv6 > /dev/null 

que talvez torne algum comando iptables redundante ou um destes acima seja o redundante. Existem umas três formas de se mexer nesse tipo de configuração, se não me engano: a acima, com o comando sysctl e direto no arquivo /etc/sysctl.conf.

As linhas com

#	for i in 21 22 23 80 86 139 443 445 631 901 3306 5190; do
#		iptables -A OUTPUT -p tcp --dport "$i" -j DROP
#	done; 

caso descomentadas seriam para barrar algum daemon usual se ativo por engano ou em uso apenas em loopback no momento. Se for usado na rede, daí deve ser retirado da lista.

Fiz o teste em duas máquinas. Na que funciona a tabela ficou:

iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            
LOG        all  --  127.0.0.10           anywhere             LOG level warning prefix "@@s-> "
DROP       all  --  127.0.0.10           anywhere            
LOG        all  --  anywhere             127.0.0.10           LOG level warning prefix "@@d-> "
DROP       all  --  anywhere             127.0.0.10          
LOG        tcp  --  anywhere             anywhere             tcp flags:FIN,SYN,RST,ACK/SYN LOG level warning prefix "syn -> "
DROP       tcp  --  anywhere             anywhere             tcp flags:FIN,SYN,RST,ACK/SYN
DROP       udp  --  anywhere             anywhere             udp dpts:0:1023
LOG        all  --  239.255.255.0/24     anywhere             LOG level warning prefix "M$ -> "
DROP       all  --  239.255.255.0/24     anywhere            
LOG        all  --  localnet/28          anywhere             LOG level warning prefix "s--> "
DROP       all  --  localnet/28          anywhere            
LOG        udp  --  anywhere             anywhere             udp dpts:33435:33525 LOG level warning prefix "udp -> "
DROP       udp  --  anywhere             anywhere             udp dpts:33435:33525
DROP       tcp  --  anywhere             anywhere             tcp dpts:0:32000
DROP       udp  --  anywhere             anywhere             udp dpts:0:32000
DROP       icmp --  anywhere             anywhere             icmp echo-request
DROP       tcp  --  anywhere             anywhere             tcp spts:x11:6255
DROP       tcp  --  anywhere             anywhere             tcp dpts:x11:6255

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
DROP       tcp  --  anywhere             anywhere             tcp flags:FIN,SYN,RST,PSH,ACK,URG/SYN
LOG        tcp  --  anywhere             anywhere             tcp flags:FIN,SYN,RST,PSH,ACK,URG/SYN,ACK LOG level warning prefix "SYN/ACK-> "
DROP       tcp  --  anywhere             anywhere             tcp flags:FIN,SYN,RST,PSH,ACK,URG/SYN,ACK

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
LOG        all  --  127.0.0.10           anywhere             LOG level warning prefix "@@s-> "
DROP       all  --  127.0.0.10           anywhere            
LOG        all  --  anywhere             127.0.0.10           LOG level warning prefix "@@d-> "
DROP       all  --  anywhere             127.0.0.10 

Essa coisa com

iptables -A INPUT -p tcp --syn -j DROP
iptables -A FORWARD -p tcp --tcp-flags ALL SYN -j DROP
iptables -A FORWARD -p tcp --tcp-flags ALL SYN,ACK -j DROP 

funcionou no caso. Daí para a outra máquina com a mesma sequencia de comandos fica estranho a questão de funcionar em uma situação e em outra não. Nem imagino o que possa ser. Mas eu testarei na outra máquina a omissão destes comandos para ver se dá diferença.

Se eu não acrescentar algo ou aperceber que faltou algo torno a editar. Obrigado de novo.

removido
(usa Nenhuma)

Enviado em 29/04/2017 - 06:10h

Estou lendo com calma. É bem útil.

----------------------------------------------------------------------------------------------------------------
Nem direita, nem esquerda. Quando se trata de corrupção o Brasil é ambidestro.
(anônimo)

Buckminster
(usa Debian)

Enviado em 29/04/2017 - 09:24h

Bom, talvez o problema da máquina em questão seja nela mesma, alguma configuração que não está permitindo a conexão ou algum problema com hardware (placa de rede, cabo, etc...).

Vou dar uma olhada com calma nos logs.

Buckminster
(usa Debian)

Enviado em 29/04/2017 - 11:15h

"O IP da máquina é algo configurado internamente como 192.168.12.101."

Caso o problema dessa máquina não seja nela mesma, coloque uma regra acima de todas liberando totalmente o IP dela e teste. Outra sugestão: de repente essa máquina esteja recebendo as conexões numa porta dessas bloqueadas pelo Iptables, talvez a porta 80. Claro que seguindo esse raciocínio as outras máquinas também não deveriam receber as conexões de entrada. É uma possibilidade remota, mas nunca se sabe.

"O comando iptables -A INPUT -i eth0 -p tcp --dport :32000 -j DROP seria para bloquear as quase 32000 primeiras portas, por paranoia pura. Tanto quanto a confguração 33435:33525. Pode ser com a 0 ou com a 1, se não houver problema. Porta 0 é algum tipo de "broadcast" de portas, se me entende?
O comando iptables -A INPUT -i eth0 -p tcp --sport 6000:6255 -j DROP seria para bloquear conexões do servidor gráfico X na interface de rede principal, tanto partindo de origem como de destino."

iptables -A INPUT -p udp --dport 0:1023 -j DROP
iptables -A INPUT -i eth0 -p udp --dport :32000 -j DROP

Esses dois comandos acima são meio que redundantes, mas não são conflitantes. O primeiro bloqueia tudo no intervalo 0:1023 para todas as placas no servidor no protocolo UDP e o segundo bloqueia as conexões de entrada (INPUT) no intervalo 0:32000 para as entradas (-i) na placa de rede eth0 no protocolo UDP.

"O endereço 127.0.0.10 seria uma configuração no arquivo /etc/hosts para bloquear endereços em requisições indesejadas.
A ideia vem do arquivo http://winhelp2002.mvps.org/hosts.txt que costumava ser atualizado periodicamente com endereços novos.
Ao invés de jogar para 0.0.0.0 imaginei que poderia ser mais saudável jogar para um IP de loopback e travá-lo no iptables.
Isto é assim mesmo? É correto? Pode ser melhorado/consertado?"

O IP de loopback é 127.0.0.1, por isso perguntei do 127.0.0.10. Talvez você configurou alguma máquina com esse IP 127.0.0.10 alterando o padrão do sistema, o que é difícil.
O IP 0.0.0.0 bloqueia tudo para todos os endereços de rede em alguns casos, apesar de que antigamente esse era o endereço de loopback, hoje não se usa mais por dar conflito. O IPV4 convencionou usar o IP 127.0.0.1.
Caso você colocar 127.0.0.1 irá conflitar com a regra iptables -A INPUT -i lo -j ACCEPT que está acima de todas liberando a loopback e como o Iptables lê de cima para baixo ele irá desconsiderar as outras regras. Caso você pretenda, deve colocar as regras acima da iptables -A INPUT -i lo -j ACCEPT.
Talvez você devesse testar com 0.0.0.0.

iptables -A INPUT -s 127.0.0.10 -j DROP
iptables -A INPUT -d 127.0.0.10 -j DROP

Por exemplo, a primeira regra acima bloqueia as conexões na chain INPUT (entrada) que tenham origem (-s) do IP 127.0.0.10 e a segunda regra bloqueia as conexões de destino (-d) para o IP 127.0.0.10.
Se não tiver nenhuma máquina com o IP 127.0.0.10 acredito que as regras com esse IP são inúteis.

"Bloquear pacotes com syn ativado seria no caso para bloqueio de conexões externas, cuja necessidade seria dispensada.
Seriam apenas requisições de dentro para fora. Mas se não há daemons em escuta rodando, seria necessário? Outro caso de paranoia?"

Daemons acredito que sempre terá algum escutando em alguma porta, isso é do sistema, sempre terá um serviço provido pelo sistema escutando em alguma porta. Talvez seja esse o problema naquela máquina que não recebe conexões, mas é somente uma hipótese.

Quanto ao log, vamos por partes, de novo:
Chain INPUT (policy ACCEPT)
Chain FORWARD (policy ACCEPT)
Chain OUTPUT (policy ACCEPT)

Veja que as políticas padrões estão todas ACCEPT. Acredito que teu firewall está bloqueando nada, pois as políticas padrões vem todas como ACCEPT por padrão.
Talvez você devesse colocar nesta parte

fw() {
echo "0" | tee /proc/sys/net/ipv4/ip_forward > /dev/null
echo "1" | tee /proc/sys/net/ipv4/conf/*/rp_filter > /dev/null
echo "0" | tee /proc/sys/net/ipv4/icmp_echo_ignore_all > /dev/null
echo "1" | tee /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts > /dev/null
echo "1" | tee /proc/sys/net/ipv6/conf/*/disable_ipv6 > /dev/null

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

Geralmente se faz assim como acima. Bloqueia-se as chains INPUT e FORWARD e depois vai se liberando o que se quer.

E aqui uma sugestão:

##Proteção contra ping, SYN Cookie, IP Spoofing e proteções do kernel
#####################################################################
echo 1 > /proc/sys/net/ipv4/tcp_syncookies #Syn Flood
echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter #Ip Spoofing
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts #Sem ping e port scan
echo 0 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses #Sem resposta remota
for i in /proc/sys/net/ipv4/conf/*; do
echo 0 >$i/accept_redirects #Sem redirecionar rotas
echo 0 >$i/accept_source_route #Sem traceroute e tracert
echo 1 >$i/log_martians #Loga pacotes suspeitos no kernel
echo 1 >$i/rp_filter #Ip Spoofing
echo 1 >$i/secure_redirects; #Redirecionamento seguro de pacotes
done
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all #Sem ping
#

Vou preparar aqui uma sugestão de script para o que tu quer, depois coloco aqui.

removido
(usa Nenhuma)

Enviado em 29/04/2017 - 11:48h

Beleza! Já estou entendendo melhor algumas coisas.

Neste meio-tempo outra dúvida:

O endereço 0.0.0.0, no /etc/hosts fornecido por aquele site, ele desvia um monte de adsenses para este endereço.
Há um porém que uma vez eu li uma citação dizendo que "eu é que não quero um tráfego destes na minha rede interna".
Tanto pela possibilidade de usar em 0.0.0.0 como em 127.0.0.1.
Ficou subentendido que seria um endereço destes particular da máquina.

Creio que usar esta técnica para barrar requisições de adsenses e demais tranqueiras funcione.

Só estou de pé atrás com o endereço interno a se usar pela segurança, pois representa lixo circulando nos neurônios da máquina.

----------------------------------------------------------------------------------------------------------------
Nem direita, nem esquerda. Quando se trata de corrupção o Brasil é ambidestro.
(anônimo)

Buckminster
(usa Debian)

Enviado em 29/04/2017 - 11:53h

É que uma regra dessas

iptables -A INPUT -s 127.0.0.1 -j DROP

bloqueia somente para o servidor as conexões que tiverem origem nele mesmo.

E uma regra dessas

iptables -A FORWARD -s 127.0.0.1 -j DROP

bloqueia somente as conexões que passarem pelo servidor para a rede e que tem origem no próprio servidor.

No caso daquele arquivo ele serve para bloquear para o localhost os sites definidos na lista e irá bloquear somente para a própria máquina.
Se você colocar tudo aquilo no /etc/hosts do servidor, mesmo assim os sites serão bloqueados somente para o servidor e não para a rede.

Veja as chains:
filter :: Esta é a tabela padrão (se a opção "-t" não definir outra tabela, será utilizada esta tabela). Ela contém a chain "built-in INPUT" (entrada - para pacotes destinados a sockets locais, pacotes destinados para a própria máquina), FORWARD (para pacotes sendo roteados através da máquina, pacotes que passam pela máquina) e OUTPUT (para pacotes gerados localmente, pacotes oriundos da própria máquina com destino para fora dela).

* Nota do tradutor: "máquina" significa o servidor ou o desktop no qual o iptables estiver instalado e configurado. O iptables vem em praticamente todas as distribuições GNU/Linux e para configurá-lo, basta somente criar um arquivo em modo texto, dar permissão de execução e colocá-lo para iniciar junto com o sistema.

https://www.vivaolinux.com.br/artigo/Manual-do-IPtables-Comentarios-e-sugestoes-de-regras/

Buckminster
(usa Debian)

Enviado em 29/04/2017 - 12:07h

O link sugerido pelo zenull contém ótimas sugestões para o que tu quer.