Re: Ajuda com LOG no iptables
Citação:
Postado originalmente por aprendiz_ce
Citação:
Postado originalmente por joseguilherme
aprendiz_ce,
A regra de log tem que estar antes da regra que libera o ssh. Voce pode adicioná-las com -I ao invéz de -A ou então coloca-las no seu script de firewall acima da regra que libera o ssh.
Mais uma coisa, substitua a regra do fin por fin + ack.
iptables -I INPUT -i eth0 -p tcp --dport 22 --tcp-flags ALL FIN,ACK -j LOG --log-prefix "FIREWALL: Acesso externo."
Abraço
joseguilherme,
antes de qualquer coisa, mais um vez muitíssimo obrigado pela sua valiosa atenção.
Estou colocando a regra referente aos LOGs acima da que libera o acesso SSH, mas não sei por que não está funcionando. Vou fazer os ajustes novamente conforme você recomendou e dou retorno.
Um forte abraço e até mais.
joseguilherme,
tentei tudo que você me passou, mas nada deu certo.
Daí criei a seguinte regra para a rede interna e está funcionando:
iptables -A INPUT -i eth1 -p tcp --syn --dport 22 -j LOG --log-level 1 --log-prefix "FIREWALL: SSH interno."
Só que tento fazer o mesmo com os dispositivo "ppp0" e/ou "eth0" (rede externa), mas não funciona.
Outra coisa: Como você pode ver, defini "--log-level 1" e o registro é feito quando a conexão é estabelecida. Como eu faço para registro o fechamento da conexão?
Obrigado e aguardo qualque ajuda.
Re: Ajuda com LOG no iptables
Amigo aprendiz_ce,
Primeiramente gostaria de tentar lhe explicar o por quê de eu ter usado as flags (syn, fin e ack) para determinar o estado da conexão (estabelecida e finalizada) e não usar o log-level para isso.
Uma conexão TCP é estabelecida através de um processo chamado handshake.
No cabeçalho dos pacotes TCP, entre tantas informações que ele contém ip de origem, ip de destino, há uma área de 6 bits, do bit 106 ao 111 do cabeçalho, reservada para as flags que dizem qual o estado da conexão.
Essas flags são URG, ACK, PSH, RST, SYN, FIN.
Quando um host vai abrir uma conexão com outro host, ele envia um pacote com a flag syn ativada. O outro host por sua vez, devolve um pacote com as flags syn e ack ativadas.
Após este processo os pacotes que trafegam não contém mais a flag syn ativada, apenas ack ou em alguns casos bem particulares alguma das outras flags, menos syn e fin.
No nosso caso específico nós usamos o módulo state do iptables (-m state) com as opções --state INVALID,NEW para filtrar os pacotes que passarem com a flag syn ativada ou algum outro pacote que contenha alguma flag inválida ou uma combinação de flags impossível tipo syn e fin no mesmo pacote.
O que pode estar acontecendo que não está logando as conexões novas?
- Você pode estar colocando a interface errada, por exemplo, quando vc estabelece uma conexão pppoe com seu provedor, a interface eth* não é a sua interface de saída, os pacotes todos devem ser filtrados na ppp0, mesmo acontece com interfaces tun*. ipsec* etc.
- Você pode estar colocando a regra de log em uma ordem que não vai te fornecer o log de tudo o que vc gostaria. Suponhamos que vc trabalhe numa empresa que tem uma filial e o seu firewall libera o acesso total para a filial e para o restante apenas liberaria ssh (apenas como exemplo), vc usaria uma regra
Código :
iptables -A INPUT -i ppp0 -s IpDaFilial -j ACCEPT
e logo abaixo vc colocaria as regras para liberar o ssh
Código :
iptables -A INPUT -i ppp0 -p tcp --dport 22 -m state --state INVALID,NEW -j LOG --log-prefix "FIREWALL: Acesso entrada SSH. "
Código :
iptables -A INPUT -i ppp0 -p tcp --dport 22 -j ACCEPT
Esse é uma pequena falta de atenção bem comum. Com as regras nessa ordem, vc não vai ter o log dos acessos ssh a partir da filial, pois todos os pacotes que vierem da filial casarão com a primeira regra e deixarão a chain.
Se você estiver colocando a regra de log antes de qualquer liberação abrangente que possa incluir aí as conexões ssh, conferir com o iptables -nvL --line-numbers e ela for a primeira a ser listada na chain ela deve funcionar. Confira as colunas dos contadores para saber se há algum pacote casando com aquela regra.
Nosso segundo problema, a finalização das conexões.
O handshake para finalizar uma conexão é bem parecido com o de abertura. A diferença é que os dois hosts podem finalizar a conexão ao mesmo tempo, abos enviando um fin e ambos respondendo com um fin e ack, ou apenas um dos lados enviando um pacote com a flag fin ativada e recebendo uma resposta de um pacote com as flags fin e ack ativadas.
A nossa regra para logar a finalização da conexão dá match no pacote de resposta que tem as flags fin e ack ativadas.
Código :
iptables -A INPUT -i ppp0 -p tcp --dport 22 --tcp-flags ALL FIN,ACK -j LOG --log-prefix "FIREWALL: Acesso finalizado SSH."
Os mesmo erros de interface errada ou ordem das regras, podem estar acontecendo, como eu descrevi acima para o caso das conexões novas.
Fora esses dois erros comuns, há mais um problema para logar a finalização de uma conexão, caso vc faça a conexão por um terminal gráfico (xterm, Eterm, etc) e vc simplesmente fechar o terminal com uma sessão ssh ativa, pode ser que ele não envie os pacotes para fechar essa conexão ssh.
Eu testei essas regras aqui hoje antes de te escrever e consegui logar tanto as conexões novas quanto a finalização delas.
Para fins de teste, coloque essas regras em primeiro lugar da tabela filter na chain INPUT, faça os testes e confira os contadores das regras para ter certeza de que há pacotes casando com essas regras.
Se mesmo assim não der certo, só com um tcpdump na interface para identificar o que está acontecendo, ver quais pacotes estão passando e porque eles não estão casando com as regras de log do iptables.
Espero que isso dê mais um gás nos seus testes.
Abraço.