Duvida: algum problema com esse firewall?

1 Anexo(s)

Ola Galera,
sou novato, ainda estou aprendendo
apesar de entender um pouco sobre o iptables, nao sou nenhuma fera nele.
andei vendo varios firewall por ai, peguei o que interessava, fiz algumas modificacoes qdo necessarias.
ele esta funcionando normalmente aqui no meu servidor de teste em casa!
porem, tenho a leve impressao que estou sobrepondo regras... e tendo regras que nao sao necessarias.

por esse motivo, alguem mais intendido, poderia dar uma olhada nele pra min? se a estrutura das regras esta bom? ou se tem algo para tirar?[
scritp firewall em anexo
desde ja
obrigado

Mantendo e depurando regras do Netfilter/iptables com auxílio de fluxogramas

Espero que ajude...

muito interessante
vou analisar ele
porem, acho q vou demorar demais...^^

porem,
se alguem mais experiente estiver disponivel.
poderia dar uma olhada pra min tbm!? se a estrutura das regras esta bom? se tem algo para tirar ou modificar???

Cara, aqui no Under-Linux.org a política geralmente é não dar o peixa, mas ensinar como pescar.

A maioria trabalha/estuda e geralmente não tem muito tempo. Por isso fica difícil tentar ajudar da maneira que você está pedinfo. Como você mesmo falou, analisar um conjunto de regras de filtro de pacotes leva muito tempo. Por isso lhe indiquei o post. Não por ser meu, mas por apresentar uma metodologia que irá lhe poupar esforço já que você ainda não tem uma própria.

Mas como estou de férias, resolvi dar uma olhada no seu conjunto...

1 - Você está usando uma política restritiva na chain INPUT. Portanto, não faz sentido ter regras com alvos DROP nessa chain;

2 - Não adianta ter uma regra impedindo a resposta de pacotes ICMP já que você não tem nenhuma regra permitindo a chegada desses pacotes;

3 - Você pode sofrer facilmente de um ataque de negação de serviço devido as regras que geram registros. Você deveria usar a match limit para tentar controlar a quantidade de registros gerados;

4 - Você está liberando todo o tráfego da rede interna para a rede externa. Está ciente disso?

5 - Na minha opnião você deveria mudar a abordagem do seu filtro de pacotes para stateful. Isso reduziria bastante seu conjunto de regras, consequentemente tornando o filtro mais eficiente;

Falouz

1 Anexo(s)

Obrigado amigo pelas dicas...
sou novato ainda, algumas coisas nao entendo... mesmo lendo lendo lendo.. acabamos por precisar de alguem para esclarecer alguns pontos (como, pra que server, o q faz exatamente, qdo usara).

Um firewall tem que ser adequado para aquele ambiente.
E quando abri esse topico, nao disse na realidade qual era a intencao do firewall.

Pois bem, pretendo montar um firewall que tenha uma certa prevencao para o servidor e a rede interna contra ataques/invasao ou virus (se possivel).
mas ao mesmo tempo, nao bloquei a navegacao interna da rede, nao pode ter bloqueios internos para externos!

Fiz algumas modificacoes, tirei um bocado de coisa do firewall.
@PEdroArthurJEdi vc deu umas dicas diante do firewall... com essas novas mudancas, consegui dar uma melhorada nele?

### na sua 3 dica, vc disse que eu teria que usar a match limit para tentar controlar a quantidade de registros gerados, seria mais ou menos isso (exemplo):
iptables -A TROJAN -m limit --limit 15/m -j LOG --log-level 6 --log-prefix "FIREWALL: trojan: "
iptables -A TROJAN -j DROP
iptables -A INPUT -p TCP -i $IF_EXTERNA --dport 666 -j TROJAN
iptables -A INPUT -p TCP -i $IF_EXTERNA --dport 666 -j TROJAN

Outra coisa PEdroArthurJEdi
Muito OBRIGADO pelas dicas e atencao!

Já melhorou muito... Mas vamos as observações.

1 - Ping of Death não está relacionado a quantidade de pacotes ICMP que chegam a interface. E aliais, não creio que nenhum sistema atual ainda é vulnerável a esses ataques;

2 - A regra que (supostamente) está protegendo contra port scanner, pode levar o seu sistema a DoS: depois do 20 pacote Syn casar com a regra, todos os outros passarão despercebidos;

3 - Usar o target REJECT significa que sua máquina alocará recursos para poder sinalizar a fonte problemas. Portanto, mais uma vez você poderá sofrer de um DoS, estando esse problema relacionado a quantidade de pacotes que chegarão a sua interface e o throughput geral do seu filtro;

4 - A chain VALID_CHECK está inútil pois não é referenciada por nenhuma regra presente nas chains padrão;

5 - Mais uma vez: numa política restritiva é inútil ter regras com targets DROP. A menos que deseje fazer uma espécie de contabilidade. Então, todas as regras com target DROP que estão nas chains INPUT e FORWARD são inúteis, visto que a política dessas é restritiva e se tem como objetivo principal a eficiência;

Eu re-escreveria suas regras da seguinte maneira:

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

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Obeservação no final...
iptables -N SERVICOS
iptables -A SERVICOS -p tcp --dport 80 -j RETURN
iptables -A SERVICOS -p udp --dport 53 -j RETURN
iptables -A SERVICOS -j DROP

iptables -A FORWARD -j SERVICOS

for i in `cat $MACLIST`; do

IPSOURCE=`echo $i | cut -d ';' -f 1`
MACSOURCE=`echo $i | cut -d ';' -f 2`

iptables -t filter -A FORWARD -m mac --mac-source $MACSOURCE -d 0/0 -s $IPSOURCE -p tcp --syn -m state --state NEW -j ACCEPT
done

iptables -t nat -A PREROUTING -s 172.167.0.0/24 -p tcp -d ! 200.201.0.0/16 --dport 80 -j REDIRECT --to-port 3128

iptables -t nat -A POSTROUTING -o $INTERNET -j MASQUERADE

iptables -t filter -A INPUT -i lo -j ACCEPT
iptables -A INPUT -p tcp --dport 2210 --syn -m state --state NEW -j ACCEPT
Não inclui aqui limites para a saída de pacotes visto que acho mais eficiente o uso de um mecanismo de controle de tráfego (HTB).

Devido as polítias de onde atuo, sempre limitamos o conjunto de sevicões que estarão disponíveis. Na chain SERVICOS você poderá colocar todos os serviços que serão liberados. No conjunto acima, essa chain será chamada para verificar se o serviço de destido no pacote é permitido na rede. E quem sabe você pode até fazer uma automatização, que nem está na sua MACLIST.

Ola caro @PEdroArthurJEdi
acabei de chegar do trabalho, estava alinhando uma antena, que com a chuva saiu do lugar!

sabe, fiz 20 anos a pouco tempo
trabalho com informatica a menos de 1 ano
comecei com servidor a menos de 1 mes.

essas dicas que me deu, foi mtooo bem recebida
aprendi bastante.
muita coisa que lendo, nao entendia direito... comecei a colocar em ordem o "no qdo sera utilizada" e "o pq utilizar".
amanha, irei ver com mais calma as novas modificacoes, estudar e testar as regras mais um pouco...
trabalhar mais ainda.
mas agora, quase meia noite, vou dar uma olhada na minha cama^^

no entanto, nessas novas dicas e nas anteriores, ja digo que as seguintes duvidas surgiram:

1:

Citação:

iptables -N SERVICOS
iptables -A SERVICOS -p tcp --dport 80 -j RETURN
iptables -A SERVICOS -p udp --dport 53 -j RETURN
iptables -A SERVICOS -j DROP

foi criado um novo chain com o nome servicos
adicionou uma nova regra ao chain Servicos, com o protocolo tcp na porta 80 e o udp na porta 53.
porem nao entendi o RETURN???? nao li sobre ele ainda.
no final vc drop o restante.

2:
nessas suas regras, poderia ser adicionado aquelas regras do kernel?

Citação:

echo "1" > /proc/sys/net/ipv4/conf/default/rp_filter
echo "1" > /proc/sys/net/ipv4/tcp_syncookies
echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
echo "1" > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
echo "0" > /proc/sys/net/ipv4/conf/all/accept_redirects
echo "1" > /proc/sys/net/ipv4/conf/all/secure_redirects
echo "0" > /proc/sys/net/ipv4/conf/all/accept_source_route
echo "0" > /proc/sys/net/ipv4/tcp_timestamps
echo "1" > /proc/sys/net/ipv4/ip_dynaddr

poderia ser adicionadas?

3:
o Sr. disse:

Citação:

3 - Você pode sofrer facilmente de um ataque de negação de serviço devido as regras que geram registros. Você deveria usar a match limit para tentar controlar a quantidade de registros gerados;

poderia me dar um exemplo confiavel para se gerar os logs? o que achei sobre o match limit foi mto pouco, e quase nao entendi...

Se vai realmente adentrar na área de infra-estrutura de servidores de rede, recomendo você dar uma lida no Guia Foca GNU/Linux. Uma das melhores referências...

Mas voltando...

O target RETURN serve para voltar ao fluxo anterior de checagem de regras. Explicando melhor: eu coloquei uma regra que diz:

iptables -A FORWARD -j SERVICOS
Então, quando o controle de checagem de regras chega nessa regra, ele é desviado para a chain SERVICOS. O RETURN vai fazer justamente que o controle volte para a chain FORWARD. Ou seja, caso o serviço esteja autorizado, o controle voltará a chain FORWARD e irá verificar agora se a o IP e MAC também estão.

A regra

iptables -A SERVICOS -j DROP
serva para que, se o serviço não estiver na lista, ele será bloqueado. A principal razão para tal abordagem é que em chains do usuário não é possível utilizar uma política.

Quanto ao segundo questionamento: sim. Eu não coloquei apenas para simplificar pois esses ajustes não fazem parte do filtro de pacotes. Podem até ajudar no seu funcionamento, mas não fazem parte.

Quanto a terceira,

iptables -A INPUT -p tcp --tcp-flags ALL FIN,PSH,URG -m limit --limit 3/minute -j LOG --log-prefix "Xmas Scan "
Na regra acima serão gerados 3 entradas por minuto.

ps: Chamar de "Sr." lasca ... Sou 2 anos menos novo que você...

Hum...
Desculpa pelo Sr... ^^

seria basicamente isso:
antes a regra era: iptables -A INPUT -i $INTERNET -p tcp --dport 21 -j LOG --log-prefix "FIREWALL:

se eu acresentar o limit ficaria:
iptables -A INPUT -i $INTERNET -p tcp --dport 21 -m limit --limit 3/minute -j LOG --log-prefix "FIREWALL:

cria uma regra normalmente
iptables -A INPUT -i $INTERNET -p tcp --dport 21

acresenta o limit
da a acao de LOG
e um "Nome para o log" (Prefixo)

existe alguma maneira de se registrar um determinado log em outro local..?
para ser mais claro, nao é necessário checar por trojans se adotamos a política de tudo fechado.
Mas, podemos querer verificar mesmo assim, para poder registrar um log mais específico, e ajudar a indentificar a maquina na rede com virus?

1 Anexo(s)

Bom
aprendi mto nesses ultimos dias com relacao ao iptables
consegui entender bem melhor as regras que antes nao conseguia...
Agradeco novamente ao @PEdroArthurJEdi
sao poucos que se aprontam em ajudar de tal forma.

creio que agora ele esteja bem melhor que antes...rs...rs...rs...
precisava mesmo era de uma organizacao!!!

sera que ainda existe algo a se modificar ou acresentar?

As seguintes regras são inúteis:

iptables -t filter -A FORWARD -d $IPSOURCE -s 0/0 -j ACCEPT
iptables -t nat -A POSTROUTING -s $IPSOURCE -o $REDE_INTERNA -j MASQUERADE

iptables -A INPUT -j DROP
iptables -A FORWARD -j DROP
A seguinte regra está dizendo que seu filtro deve aceitar qualquer pacote vindo de uma máquina da rede interna:

iptables -t filter -A INPUT -s $IPSOURCE -d 0/0 -m mac --mac-source $MACSOURCE -j ACCEPT
É esse comportamente mesmo que você deseja?

Citação:

A seguinte regra está dizendo que seu filtro deve aceitar qualquer pacote vindo de uma máquina da rede interna:iptables -t filter -A INPUT -s $IPSOURCE -d 0/0 -m mac --mac-source $MACSOURCE -j ACCEPT

É esse comportamente mesmo que você deseja?

com relacao a aceitar qualquer pacote da rede interna... sim
aqui tenho q ter regra o maximo possivel restritiva, contra invasao, etc e tal!
mas nao posso impedir em nada a rede interna, ela pode acessar qualquer site e usar qualquer programa!
Por isso, alem das portas importantes no servidor, estou querendo ver quais portas da para ficar gerando logs, para poder indentificar mais facilmente a maquina interna com trojan/virus.
meio complicado nao acha?

Citação:

As seguintes regras são inúteis:iptables -t filter -A FORWARD -d $IPSOURCE -s 0/0 -j ACCEPT
iptables -t nat -A POSTROUTING -s $IPSOURCE -o $REDE_INTERNA -j MASQUERADE

iptables -A INPUT -j DROP
iptables -A FORWARD -j DROP

a 1 regras, faz parte do meu controle de acesso, qual maquina pode ou nao acessar web.
se eu retiro qualquer regra desse controle, as maquinas nao navegam mais!

a 2 e 3 regras, fecham o script, dropa todo o restante...
nao precisa dela?

Citação:

Postado originalmente por mascaraapj

com relacao a aceitar qualquer pacote da rede interna... sim
aqui tenho q ter regra o maximo possivel restritiva, contra invasao, etc e tal!
mas nao posso impedir em nada a rede interna, ela pode acessar qualquer site e usar qualquer programa!

Mas você não está dizendo isso... Você está dizendo que a máquina onde roda o filtro de pacotes deve receber qualquer pacote vindo da rede interna.

O que você quer fazer você fez, mas com a regra presente na chain FORWARD. Recomendo você retirar essa regra.

Citação:

Postado originalmente por mascaraapj

Por isso, alem das portas importantes no servidor, estou querendo ver quais portas da para ficar gerando logs, para poder indentificar mais facilmente a maquina interna com trojan/virus.
meio complicado nao acha?

Para isso você terá que ter regras tanto na chain INPUT quanto na chain FORWARD. Recomendo você criar uma chain e colocar as regras de registro e a partir das chain INPUT e FORWARD você a chama.

Citação:

Postado originalmente por mascaraapj

a 1 regras, faz parte do meu controle de acesso, qual maquina pode ou nao acessar web.
se eu retiro qualquer regra desse controle, as maquinas nao navegam mais!

Tem certeza? Se você está usando o módulo state, essas regras são desnecessárias.

Citação:

Postado originalmente por mascaraapj

a 2 e 3 regras, fecham o script, dropa todo o restante...
nao precisa dela?

Não... No inicio você já configurou seu filtro como restritivo (opção -P CHAIN DROP).

verdade... nao faz diferenca mesmo...
agora sim, creio q tenha um firewall bem melhor que antes para o ambiente que estou.

adicionei no meu squid.conf, um script contra malware...
para melhorar um pouquinho mais a seguranca da rede interna no acesso a web.

Obrigado pela atencao

1 Anexo(s)

Ola amigo.
Sera que poderia dar novamente, mais uma ajudinha?
Com o squid, eu consigo bloquear o acesso da rede interna a determinados sites.
Porem, com base nesse firewall atual que estou usando, gostaria de saber... como poderia fazer para que a rede interna nao acesse determinados IPs externos ou dominios?

seria algo como:
iptables -A FORWARD -d 200.x.x.x -j DROP

?

Isso mesmo... Porém as regras de bloqueio de domínio deveriam vir antes das regras de controle por IP/MAC.