[GTER] Worm do SQL/1434-udp

[Juliano Souza]

Onde acho o site ou a documentação sobre este patch raw?

Att,

Juliano

----- Original Message ----- 
From: "Rubens Kuhl Jr." <rubens at email.com>
To: "Grupo de Trabalho de Engenharia e Operacao de Redes"
<gter at eng.registro.br>
Sent: Tuesday, September 14, 2004 5:08 PM
Subject: Re: [GTER] Worm do SQL/1434-udp


> > > Pq vc afirma que é o processamento do QoS que vai para 90% ?
> >
> > -----Pq eu tiro o cabo do cliente e logo abaixa o processamento, vejo
via
> > top e pela inserção de caracteres no terminal
>
> Isso significa que todos a carga gerada pelo pacote (entrada, roteamento,
filtros de saída, QoS, transmissão) causa isso, esse teste não isola nenhum
dos componentes em particular.
>
> > > De qualquer forma, QoS é tipicamente de saída... habilite filtro de
> > pacotes para UDP 1434(como vc faz bridge, pode ser via bridge-nf, mas
não
> > aconselho
> > conntrack nesse cenário), e jogue o lixo no lixo.
> >
> > -----Pq naum aconselha conntrack neste cenário, o que seria ideal?
>
> Pq worms geram fluxos em demasia e rapidamente lotam tabelas de sessões
como a do conntrack.
>
> O ideal é não carregar o conntrack; se vc precisa por algum motivo nesta
máquina, instale o patch RAW e coloque todos os tráfegos que não precisem em
NOTRACK.
>
> > -----Mas mesmo assim, filtro udp 1434 para saída. naum soh ele, mas tbm
> > todas as portas que os vírus utilizam, mas até aí, o pacote chega de
> > qualquer jeito na QoS.
>
> Pq colocar os filtros na saída e deixar pacotes que serão dropados
gastarem seus recursos ? Coloque na entrada, se possível direto no
PREROUTING.
>
> Além disso, se o pacote é dropado no filtro de saída, ele vem antes do
QoS... QoS é a última coisa a que um pacote é submetido, depois ele já é
transmitido.
>
>
> Rubens
>
>
> --
> GTER list    https://eng.registro.br/mailman/listinfo/gter
>