[GTER] Worm do SQL/1434-udp

[Rubens Kuhl Jr.]

> > 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