[FUGSPBR] Bloquear ICMP
Ricardo A. Reis
n.i.b em terra.com.br
Seg Jul 22 22:38:22 BRT 2002
> O Servidor deles eh em Linux, e la RFC1191 e 1122, fala sobre isso.
Realmente eu esqueci de passar o links das rfc eu ate' tenho algo em
meu bookmarks, preciso ainda colocar ordem na casa ta td uma zona .hehe
> Entao agora fico com a pergunta, porque entao essa MTU 1492 não eh padrao ?
Uma vez que a rfc que padroniza pppoe e' de 1999 ou 2000 "naum tenho
certeza" saum rfc novas, tudo denpende da ietf.. mais acho que isso
naum sera padronizado pq td depende do adm da rede ..verificar o que
e' melhor.
> Aprofeitando para que serve o
> net.inet.tcp.rfc1323=0 do sysctl.conf ?
>
> Eu tenho um server com 1 e outro com 0 ?
Naum tive tempo de ler essa rfc ..naum tao bem!! Acho que e' algo
sobre ganho de performace depois de tantos mbits.. algo que seja
quase no limite do meio fisico!
> Qual o melhor?
Nao vejo contras de se deixar 1.
t++
--------------------------------------------
"FreeBSD,BeOS,Linux"|"Cisco Network Academy"
--------------------------------------------
BSD User = 050834 | Linux User = 280168
--------------------------------------------
The Power to the Serve
>
> ----- Original Message -----
> From: "Ricardo A. Reis" <n.i.b em terra.com.br>
> To: "fugspbr" <fugspbr em fugspbr.org>
> Sent: Monday, July 22, 2002 8:33 PM
> Subject: Re: [FUGSPBR] Bloquear ICMP
>
>
> Bom voltamos a uma duvida antiga, PMTU-D e a sigla para
> Path MTU Discovery... onde a MTU e a sigla pra Unidade Maxima de
> Transmicao,
>
> Segundo a Braslink se vc filtra pacote fragmentados automaticamente
> esta impedindo que o a origem perceba que esta enviando pacote grandes
> de mais, gerando trafedo desnecessario e erro de roteamento.
> As vezes nem e' pq e' grande de mais e sim porque a MTU setada pela
> origen e' difente da sua, logo vc tera fragmentos e perda de pacote,
> que resultaram nesses erros estranhos, verifique e compare as MTU's.
> A MTU default e' 1500 porem muitas aplicacoes encap o protocolo ip
> gerando um overhead, sendo assim se diminui o tamanho da MTU.
> Ex ADSL sobre pppoe "se eu naum me engano este encap gera uns 8bytes
> de overhead", sendo assim pra compesar o overhead se diminui a mtu
> para 1492 ou menos.
> Porem arquivos fragmentado sao na maioria das vezes pacotes
> descartado por ma formacao,colisao e outras coisas, estaum presentes
> na maioria dos ataques DDOS e DOS podem vir a sem um grande problema.
> Tente ajustar o MTU manualmente se mesmo assim nao resolver permita
> fragment.
>
>
>
> O trafego icmp e' algo essencial para o bom funcionamento da rede pq
> e' um protocolo de controle,
> Este saum os tipo de mensagens icmp!
>
>
> 0 - Echo Reply (Resposta de Echo)
> 3
> -
> Destination Unreachable (Destino Indisponível)
> 4
> -
> Source Quench (Origem extinta)
> 5
> -
> Redirect (Redireção)
> 8
> -
> Echo Request (Pedido de Echo)
> 9
> -
> Router Advertisement (SPAM de roteamento? :-))
> 10
> -
> Router Solicitation (Pedido de Roteamento)
> 11
> -
> Time-to-Live Exceeded (TTL Excedido)
> 12
> -
> IP header bad (Cabeçalho IP malformado)
> 13
> -
> Timestamp Request (Pedido de Timestamp)
> 14
> -
> Timestamp Reply (Resposta de Timestamp)
> 15
> -
> Information Request (Pedido de Informação)
> 16
> -
> Information Reply (Resposta de Informação)
> 17
> -
> Address Mask Request (Pedido de Máscara de Rede)
> 18
> -
> Address Mask Reply (Resposta de Máscara de Rede)
>
>
> Eu aqui em casa eu permito a entrada de 0,3,8,11 e a saida de
> tudo, e nego fragment tambem!
>
> Na entrada da minha adsl permito a entrada
> Echo Request (Pedido de Echo) pra simplemente eu sei que me pinga
> porem o Echo Reply (Resposta de Echo) na sai da rede, isso e' so uma
> forma de parar com os curiosos ja que se pode pingar com tcp.
> Destination Unreachable (Destino Indisponível) tambem permito
> logo que tive erros com alguns aplicativos "gnutella" porem muitas
> tentativas de DDOS (Destributed Denial of Service) se usam desta
> mensagem.
> Time-to-Live Exceeded (TTL Excedido) a cada pacote tem um tempo
> de vida ..para evitar que fique rodando pela rede indeterminadamente a
> cada no' "router" esse numero e' decrementado ate' ser descartado!
> Isso evita loops e outra coisas.
> A opcao de bloquear esta tipo de icmp e pro sua conta eu naum
> faria em um router de producao, agora naum tenho muita certeza de sua
> utilizade pra um servidor de web ou outra aplicacao sei que para
> programas tipo gnutella ele e' essencial ja que estes trabalham com
> pontos distantes.
>
>
>
>
> Da uma olhada nesse historico da lista!
>
> http://www2.fugspbr.org/listas/200204/msg00305.html
>
>
> Acho que e' isso, se algo estiver errado me falem!!
>
>
> t++
>
>
> >
> > Ola Pessoal,
> >
> > Olha estou com um problema com o Pessoal da Braslink.com, onde os clientes
> > que estao em baixo da minha rede(firewall e nat), nao conseguem acessar o
> > WebMail
> > deles e acorrem alguns outros erros malucos, time out em banco de dados,
> nao
> > consegue abrir algumas paginas e etc.
> >
> > Hoje eu nao deixo passar pacotes ICMP´s de fora para dentro de minha rede,
> > apenas claro aqueles que eu solicitei (resposta) eu deixo.
> >
> > O pessoal da Braslink, me passou este texto a baixo, que nao entendi muito
> > bem, mas
> > que fala se filtramos o ICMP, pode causar problemas como esse meu, onde
> > os server se perdem no meio do caminho.
> >
> > Eu tambem nao deixo passar pacotes fragmentados na minha rede...
> >
> > O que eh esse PMTU-D ?
> > Essa fato eh veridico, se for que tipo de ping eu posso liberar?
> >
> > Thanks
> > Jean Duarte
> >
> >
> > Now, to the problem with ICMP filtering and PMTU-D
> > Now we get to the problem. Many network administrators have decided to
> > filter ICMP at a router or firewall.
> > There are valid (and many invalid) reasons for doing this, however it can
> > cause problems. ICMP is an integral
> > part of the Internet and can not be filtered without due consideration for
> > the effects.
> > In this case, if the ICMP can't fragment errors can not get back to the
> > source host due to a filter, the host will
> > never know that the packets it is sending are too large. This means it
> will
> > keep trying to send the same large packet,
> > and it will keep being dropped--silently dropped from the view of any
> system
> > on the other side of the filter. While a
> > small handful of systems that implement PMTU-D also implement a way to
> > detect such situations, mo
> > st don't and even for those that do it has a negative impact on
> performance
> > and the network.
> > If this is happening, typical symptoms include the ability for small
> packets
> > (eg. request a very small web page) to
> > get through, but larger ones (eg. a large web page) will simply hang. This
> > situation can be confusing to the novice
> > administrator because they obviously have some connectivity to the host,
> but
> > it just stops working for no obvious
> > reason on certain transfers.
> >
> >
> > ________________________________________________
> > Para sair da lista visite o URL abaixo:
> > http://www2.fugspbr.org/mailman/listinfo/fugspbr
> >
> >
>
> --------------------------------------------
> "FreeBSD,BeOS,Linux"|"Cisco Network Academy"
> --------------------------------------------
> BSD User = 050834 | Linux User = 280168
> --------------------------------------------
> The Power to the Serve
>
>
>
> ________________________________________________
> Para sair da lista visite o URL abaixo:
> http://www2.fugspbr.org/mailman/listinfo/fugspbr
>
>
> ________________________________________________
> Para sair da lista visite o URL abaixo:
> http://www2.fugspbr.org/mailman/listinfo/fugspbr
>
>
________________________________________________
Para sair da lista visite o URL abaixo:
http://www2.fugspbr.org/mailman/listinfo/fugspbr
Mais detalhes sobre a lista de discussão freebsd