Se vc usa o ipchains para configurar seu firewall e está acontecendo algumas coisas estranhas, este é o artigo ideal para vc! Confira!!!

No ipchains não é tudo alegria, principalmente se você esta criando regras de ipchains complexas. Em regras complexas de ipchains é EXTREMAMENTE necessário o conhecimento dos protocolos de cominicação dos serviços. Um exemplo é se você fechar totalmente o servidor com ipchains -P input REJECT, ipchains -P output REJECT e ipchains -P forward REJECT, se você não expecificar o que entra e o que sai é quase certeza que você vai encontrar problemas: 1) Não consigo pingar meus clientes 2) A conexão com a internet parou 3) Meus clientes não acham o servidor de DNS Entre outros problemas, então, o que você vai encontrar nesta receita? Eu pretendo explicar como utilizar o log do ipchains para resolver certos problemas que vocês possam vir a encontrar com o firewall. Este também é um documento que você não encontra por ai! Primeiramente vamos arrumar o klogd ( log do kernel ) para que ele mande qualquer mensagem de erro para /var/log/err ou qualquer outro que você escolher. Em /etc/rc.d/init.d/syslog modifique a linha: gprintf "Starting %s: " "syslogd" daemon syslogd  daemon klogd echo touch /var/lock/subsys/syslog por gprintf "Starting %s: " "syslogd"/ daemon syslogd  daemon klogd -f /var/log/err  echo touch /var/lock/subsys/syslog Salve e reinicie o klogd com /etc/rc.d/init.d/syslog restart, agora todos os erros do kernel serão redirecionados para /var/log/err. Antes que alguém diga algo, modificar o /etc/syslog.conf não funcionou ( pelo menos comigo e meu Conectiva 4.0 ). Todos os hits do ipchains serão logados em nosso /var/log, para a base do nosso pequeno teste, crie um pequeno script para ipchains com o seguinte conteúdo: #!/bin/sh PATH=/sbin >Revertendo e limpando ipchains antigos ipchains -P input ACCEPT ipchains -P output ACCEPT ipchains -P forward ACCEPT ipchains -F >Fechando tudo ipchains -P input REJECT ipchains -P output REJECT ipchains -P forward REJECT >Abrindo telnet e ssh para o nosso teste ipchains -A input -p tcp -s 192.168.0.0/24 -d 192.168.0.3 22 -j ACCEPT ipchains -A input -p tcp -s 192.168.0.0/24 -d 192.168.0.3 23 -j ACCEPT ipchains -A output -p tcp -s 192.168.0.3 22 -d 192.168.0.0/24 -j ACCEPT ipchains -A output -p tcp -s 192.168.0.3 23 -d 192.168.0.0/24 -j ACCEPT >Logando todas as conexões para fins de procura de erros >Não use estas configurações abaixo em situações reais ou tenha dor de >cabeça mais tarde. Somente use-as se você souber o que esta fazendo!!! ipchains -A input -s 0/0 -d 0/0 -j REJECT -l ipchains -A output -s 0/0 -d 0/0 -j REJECT -l O que eu quero mostrar com isso? Toda regra complexa de ipchains começa fechando TODOS os serviços, então como esta tudo fechado você precisa liberar certos serviços e portas para que o sistema possa pelo menos funcionar. Com o exemplo que eu mostrei, você não consegue pingar nenhum cliente da sua rede interna e os clientes não conseguem pingar o servidor. Então, como o ipchains-howto diz, nós não podemos fechar certas portas e serviços para que o servidor funcione. Um exemplo é o DNS, ping, algumas portas icmp etc. Vamos arrumar o ping então. Dê um cat /etc/protocols para que você tenha uma base dos protocolos. Segunto o ipchains-howto na seção 4.1.3.3.2 você tem o exemplo dos tipos de icmp, e na seção 4.1.4.2 nós temos um exemplo de como será o log do kernel caso alguém tente se conectar em uma porta ou IP filtrados pelo ipchains. Use um cliente da sua rede e conecte-se via telnet no servidor e use as configurações acima. Se possível use duas conexões de telnet,uma para ver o log do kernel e outra para que fique livre para comandos, modifique os IPs acima para funcionar com o seu sistema. Na primeira tela do telnet faça um tail -f /var/log/err , na segunda tela dê um ping do servidor para o cliente,no meu caso o servidor é 192.168.0.3 e o cliente é 192.168.0.4,você verá o resultado: ping 192.168.0.4 PING 192.168.0.4 (192.168.0.4): 56 data bytes ping: sendto: Operation not permitted ping: wrote 192.168.0.4 64 chars, ret=-1 Na tela que você esta vendo o log vai aparecer: <6>Packet log: output REJECT eth0 PROTO=1 192.168.0.3:8 192.168.0.4:0 L=84 S=0x00 I=28698 F=0x0000 T=64 (#3) Esta vendo o que esta sendo rejeitado? A única coisa que precisamos saber aqui é o que ele esta rejeitando,a interface PROTO e os IPs+porta.  O output esta sendo rejeitado na eth0,o PROTO=1 significa icmp, o IP que está saindo é 192.168.0.3, porta 8 e o destino é 192.168.0.4 porta 0. Edite novamente o nosso script e comente fora a última linha:  #ipchains -A output -s 0/0 -d 0/0 -j REJECT -l Rode-o novamente. Já sabemos que as portas que estão sendo rejeitadas, basta agora abrí-las: ipchains -A output -p icmp -s 192.168.0.3 8 -d 192.168.0.4 0 -j ACCEPT Faça o ping novamente no cliente 192.168.0.4, mas espera aí, o ping fica parado??? Vamos ver os logs novamente: <6>Packet log: input REJECT eth0 PROTO=1 192.168.0.4:0 192.168.0.3:0 L=84 S=0x00 I=54293 F=0x0000 T=128 (#3) Claro, o ping esta mandando os pacotes, mas o ipchains esta bloqueando a entrada. Vamos liberar então: ipchains -A input -p icmp -s 192.168.0.4 0 -d 192.168.0.3 0 -j ACCEPT Faça o ping no cliente novamente, ué? Não funciona ainda?? Vamos ao log novamente!! Parece tudo igual! Lembra da penúltima linha do nosso script onde lista: ipchains -A input -s 0/0 -d 0/0 -j REJECT Inverta,digite no terminal o mesmo comando mas em vez de ipchains -A coloque ipchains -D para apagar a regra e tente pingar o cliente novamente: ping 192.168.0.4 PING 192.168.0.4 (192.168.0.4): 56 data bytes 64 bytes from 192.168.0.4: icmp_seq=0 ttl=128 time=0.2 ms 64 bytes from 192.168.0.4: icmp_seq=1 ttl=128 time=0.2 ms Ué, mas por quê? As regras de ipchains são ORGANIZADAS de cima para baixo. Explicando melhor, quando você expecifica: ipchains -P input DENY ( ou REJECT ) ipchains -P output DENY ( ou REJECT ) ipchains -P forward DENY ( ou REJECT ) O ipchains bloqueia tudo para todos, então o ipchains só espera que você abra portas e não feche, caso você feche algo novamente, pode ser uma porta de ftp, www, qualquer uma, o ipchains não vai se preocupar em verificar as outras regras,mesmo que você as abra mais tarde. Como vocês viram no meu exemplo, se eu abrir certas portas no input e terminar com um DENY ( ou REJECT ), o ipchains para por ai e não verifica o resto das regras de input. Então você precisa tomar MUITO cuidado com o que é fechado nas primeiras sequências de comandos ou as primeiras linhas do script, pois o que você fecha no ínicio você não abre lá em baixo. Imagine que você criou um script complexo de ipchains, de cabeça, que tem 1.000 linhas, se der problema depois, imagine o trabalho que vai ser para descobrir o erro. Principalmente comandos do tipo "selo": ipchains -A input -s 0/0 -d 0/0 -j REJECT ipchains -A output -s 0/0 -d 0/0 -j REJECT ipchains -A forward -s 0/0 -d 0/0 -j REJECT Um exemplo: Eu quero que minha rede 192.168.0.0 tenha acesso ao servidor de ftp, mas não para alguém de fora, então o que você vai fazer é liberar o acesso PRIMEIRO e fechar depois para o resto: ipchains -A input -p tcp -s 192.168.0.0/24 -d 192.168.1.3 ftp -j ACCEPT ipchains -A input -p tcp -s 192.168.0.0/24 -d 192.168.1.3 ftp-data -j ACCEPT ipchains -A output -p tcp -d 192.168.0.0/24 -s 192.168.1.3 ftp -j ACCEPT ipchains -A output -p tcp -d 192.168.0.0/24 -s 192.168.1.3 ftp-data -j ACCEPT  ipchains -A input -p tcp -s 0/0 -d 192.168.1.3 ftp -j REJECT -l ipchains -A input -p tcp -s 0/0 -d 192.168.1.3 ftp-data -j REJECT -l Eu liberei a minha rede interna para ter acesso ao ftp, mas por quê eu coloquei as duas últimas linhas se o servidor já esta configurado para rejeitar tudo? Vamos supor que você tenha um site no seu servidor e você DIZ logo na entrada que: "Este servidor não oferece serviços de ftp anônimo" Mas tem sempre um que quer TESTAR para ver se é verdade, então a função das duas linhas extras ali é para registrar no nosso sistema de log qualquer um de fora que tente o acesso. Por muio tempo eu martelava isso na cabeça, e cheguei a seguinte conclusão para ?aprender? qual seria o significado deste "selo"/. Por exemplo, quando você vai em uma padaria e compra uma bengala, enquanto aquele papel de seda que o padeiro usa para enrolar a bengala estiver aberto,vai caber mais uma ou duas bengalas, mas depois de fechado não tem jeito de colocar mais, a não ser que você rasgue o papel e enrole mais bengalas com um papel maior e feche novamente. Note que isso é só uma teoria, um exemplo para que você entenda o significado de se usar um "selo". Com o ipchains eu uso esta "teoria", eu crio umas 200 regras de input e fecho ("passo o selo") com: ipchains -A input -s 0/0 -d 0/0 -j DENY -l O mesmo para forward e output, então eu sei que se por algum acaso eu tiver algum problema, os "selos" serão os primeiros que eu irei abrir para, a partir daí, resolver o problema, ou seja: ipchains -D input -s 0/0 -d 0/0 -j REJECT-l ipchains -D forward -s 0/0 -d 0/0 -j REJECT-l ipchains -D output -s 0/0 -d 0/0 -j REJECT-l Note que eu estou dizendo "selos" para que você aprenda o que eles fazem, e seja mais fácil de você gravar a sua função. Vamos arrumar o nosso script para que o protocolo icmp funcione com todos os clientes da rede como para a internet também. Adcione a seguinte linha: ipchains -A input -p icmp -s 0/0 -d 192.168.0.3 -j ACCEPT ipchains -A output -p icmp -s 192.168.0.3 -d 0/0 -j ACCEPT Com estas duas linha nós já damos conta do recado. Se você tem mais de uma interface, não se esqueça de colocar o IP das suas interfaces também. Lembrando que 0/0 ou 0.0.0.0 significa "infinito ou qualquer", então a primeira regra é para entrada de pacotes icmp vindos de qualquer lugar para o endereço do servidor. A segunda regra é a saida para a resposta do pedido, que vai sair do nosso servidor para qualquer lugar.  É importante resaltar que não é necessário que você feche totalmente o protocolo icmp, por mais que você queira deixar o seu servidor o mais seguro possível, o servidor precisa deste protocolo para funcionar. Você pode achar que bloqueando o ping ao seu servidor você possa estar mais seguro, mas é um grande erro, pois o invasor pode usar de outras táticas para conseguir identificar o seu servidor. Vou mostrar como arrumar os pedidos de DNS ( porta 53 ), o nosso servidor continua lacrado, nós só liberamos o protocolo icmp para ir e vir, então vamos achar o erro que esta causando o reject na porta de DNS. Abra o nosso script com as devidas modificações ( liberação do protocolo icmp ) e descomente ( retire o # da frente ) os nossos dois "selos" que estão nas duas últimas linha e execute-o novamente. Aqui no meu servidor eu tenho duas interfaces eth0 e eth1. A eth0 ( 192.168.0.3 ) cuida da parte interna da rede, a eth1 ( 192.168.1.3 ) cuida da saída para a internet e é o servidor de DNS da minha pequena rede. Eu configurei o meu domain name para ser wtulinux.co.jp, então no meu cliente ( 192.168.0.4 ) vamos chamar o www ( porta 80 ) do meu servidor e ver o que acontece. Mas como abrir somente o DNS não vai resolver, precisamos da porta 80 aberta para que possamos ver as páginas do servidor. Então vamos ao log do systema. No seu cliente, mantenha as duas janelas do telnet abertas, uma com tail -f /var/log/err e outra para comandos. Abra o seu browser e chame o endereço do seu servidor ( www.wtulinux.co.jp no meu caso ), veja o que acontece, no browser nada vai acontecer, mas vamos ver os logs: <6>Packet log: input REJECT eth1 PROTO=17 192.168.0.4:1322 192.168.1.3:53 L=76 S=0x00 I=55093 F=0x0000 T=128 (#5) Bom, o input na minha interface eth1 esta fechada e o protocolo é código 17 ( udp ) que vem do cliente na porta 1322 e entra no servidor na porta 53. Agora abra o nosso script e comente ( coloque um # na frente ) os "selos" e rode-o novamente. Eu sei que os pedidos nunca vem na mesma porta, então eu não posso especificar a porta 1322 do cliente, mas o servidor sempre vai servir o DNS na porta 53, com isso nossa regra de entrada e saída ficaria assim: ipchains -A input -p udp -s 192.168.0.4 -d 192.168.1.3 53 -j ACCEPT ipchains -A output -p udp -s 192.168.1.3 53 -d 192.168.0.4 -j ACCEPT Isso deve resolver o problema no servidor de DNS. Para comprovar que o DNS esta funcionando, faça um ping chamando o DNS, no caso: ping www.wtulinux.co.jp Mas a porta 80 ainda esta fechada, eu só pedi para que o servidor resolvesse o nome www.wtulinux.co.jp para o IP que no caso é 192.168.1.3 Volte ao nosso script e adcione o input e output para o DNS ( sempre acima dos "selos" ), ligue os "selos"/ novamente e no cliente pegue o seu browser e chame o servidor novamente ( www.wtulinux.co.jp no meu caso ). Vamos aos logs: <6>Packet log: input REJECT eth1 PROTO=6 192.168.0.4:1333 192.168.1.3:80 L=48 S=0x00 I=15927 F=0x4000 T=128 SYN (#6) Então o meu Netscape chama a porta 80 pelo protocolo de código 6, segundo o nosso /etc/protocols é tcp. Vamos criar as regras de entrada e saída então. Desative os "selos"/ e execute o script novamente, depois digite o seguinte: ipchains -A input -p tcp -s 192.168.0.4 -d 192.168.1.3 80 -j ACCEPT ipchains -A output -p tcp -s 192.168.1.3 80 -d 192.168.0.4 -j ACCEPT Volte ao browser e tente novamente. Pronto, problema resolvido. Como o DNS eu não posso bloquear e o www eu quero que todos tenham acesso, os comandos completos seriam: >Abrindo DNS ipchains -A input -p tcp -s 0/0 -d 192.168.1.3 53 -j ACCEPT ipchains -A input -p udp -s 0/0 -d 192.168.1.3 53 -j ACCEPT ipchains -A output -p tcp -s 192.168.1.3 53 -d 0/0 -j ACCEPT ipchains -A output -p udp -s 192.168.1.3 53 -d 0/0 -j ACCEPT >Interface interna é valida para ir e vir, sem esta linha o seu nslookup não funciona ipchains -A input -i lo -s 0/0 -d 0/0 -j ACCEPT ipchains -A output -i lo -s 0/0 -d 0/0 -j ACCEPT  >Abrindo www ipchains -A input -p tcp -s 0/0 -d 192.168.1.3 80 -j ACCEPT ipchains -A output -p tcp -s 192.168.1.3 80 -d 0/0 -j ACCEPT Não é tão difícil localizar estes tipos de problemas com o ipchains não é mesmo? Sempre que você tiver algum tipo de problema com as suas regras de ipchains ou se você estiver usando regras de "terceiros" e esta tendo problemas também, essa é a tática que eu utilizo para resolver os meus problemas com ipchains. Não esqueça de criar as regras e testar seu funcionamento antes de criar linhas e mais linhas de regras de ipchains. Nada impede também que você utilize os comandos "selo", mas é importante que você saiba o quê eles podem fazer por você e o que eles podem fazer se mal utilizados. Então é isso, espero que vocês tenham aprendido este básico e que seja de alguma ultilidade para todos.

Quebra-Linha

Colaborador..: Michael Costa Schon
Categoria(s).: Segurança; Linux;
Data.........: 03/06/2002 09:53:50
Visualizado..: 4279 vezes
Fonte........: Sites da Web + experiências