+ Responder ao Tópico



  1. #1

    Padrão Problemas com syn_sents e syn_receiveds

    Não sei bem como funciona, mas sei que muitas dessas conexões deixam a navegação dos clientes não muito legal. Começam a acontecer timeouts, os clientes mal conseguem carregar as páginas. Como alguns poucos clientes bichados podem derrubar uma rede desse jeito?

    Tem como impedir isso de acontecer SEM limitar número de conexões simultâneas?? Fica meio inviável ficar mandando os clientes formatarem, boa parte não aceita, se sente lesado, e de fato até o são de certa forma. Fora que com certa quantidade de clientes, por mais que vc saia bloqueando eles, todo dia aparecem mais uns 5 com pcs bichados...

  2. #2

    Padrão

    Os pacotes syn sao necessarios para qualquer conexao TCP... Nao tem como evita-los...

    Pelo que eu entendi, no entanto, seus clientes estao ficam "travados" no estado SYN_SENT?

    Isto pode ser um problema de MTU... Descreva melhor o que esta acontecendo que talvez a solucao seja ate simples...

  3. #3

    Padrão

    algum(ns) clientes às vezes geram muitos syn_sent e received. Normalmente quando está tudo certo funcionando direitinho, em ip>firewall>connections tem alguns poucos syn, coisa de 40-50 estourando. Quando entra algum cliente com alguns tipos de vírus na máquina, ele sozinho gera uns 200 desses syn. Quando isso acontece a navegação de todos os clientes começa a ficar instável. Por exemplo, eu tento abrir páginas e ele demora anos pra fazer cada uma das conexões (olhando no canto esquerdo inferior da tela do navegador), e dá timeout o tempo todo, não abrindo a página. Vou pro gerenciador de downloads fazer testes já que ele abre trocentas conexões simultâneas pra baixar um arquivo, e ele fica lá um tempão e não consegue fazer nenhuma conexão com o servidor do arquivo, ou faz 1-2 no tempo em que normalmente já teria feito 20.

    Eu desconecto e bloqueio o cliente, os syn que o ip dele estava criando somem em poucos segundos e o funcionamento volta ao normal instantaneamente.

    É mais ou menos isso que acontece.

  4. #4

    Padrão

    Você está sofrendo um ataque de DoS (Denial of Service) através de Syn Flood.
    Todo inicio de conexão TCP usa o three-way handshake, SYN/SYN-ACK/ACK.
    Se o cliente envia vários SYN e não responde com o ACK final, seu servidor enfileira todas essas requisições até que não consiga mais responder a nenhuma outra requisição.

    O grande problema disso é descobrir e bloquear a fonte, pois normalmente o ataque é distribuido entre vários computadores. Porém, pelo que parece esse não é seu caso, você sabe de onde se origina o ataque.

    Há ainda a possibilidade de alterar parâmetros da pilha de TCP para diminuir os efeitos maléficos destes ataques, mas isso poderia comprometer a performance de seu sistema e de seus clientes que nada tem a ver com isso !

    Portanto, não vejo outra alternativa a não ser entrar em contato com o cliente causador do ataque e explicar o que está ocorrendo. Com certeza, ele é apenas um hospedeiro e nem sabe disso !

    Apenas uma pergunta, estes SYN estão tentando conectar qual porta TCP ?

  5. #5

    Padrão

    Citação Postado originalmente por ferdam Ver Post
    Você está sofrendo um ataque de DoS (Denial of Service) através de Syn Flood.
    Todo inicio de conexão TCP usa o three-way handshake, SYN/SYN-ACK/ACK.
    Se o cliente envia vários SYN e não responde com o ACK final, seu servidor enfileira todas essas requisições até que não consiga mais responder a nenhuma outra requisição.

    O grande problema disso é descobrir e bloquear a fonte, pois normalmente o ataque é distribuido entre vários computadores. Porém, pelo que parece esse não é seu caso, você sabe de onde se origina o ataque.

    Há ainda a possibilidade de alterar parâmetros da pilha de TCP para diminuir os efeitos maléficos destes ataques, mas isso poderia comprometer a performance de seu sistema e de seus clientes que nada tem a ver com isso !

    Portanto, não vejo outra alternativa a não ser entrar em contato com o cliente causador do ataque e explicar o que está ocorrendo. Com certeza, ele é apenas um hospedeiro e nem sabe disso !

    Apenas uma pergunta, estes SYN estão tentando conectar qual porta TCP ?
    as mais variadas no source address (ip do cliente), no destination address 99% das portas são a porta 80.

    Agora, porque só eu tenho esses problemas e um monte de caras que têm até bem menos experiência que eu, mas têm redes com muitos clientes, não têm esses ataques todos?

    E como, por exemplo, uma Telemar da vida não passa o tempo todo fora do ar por causa disso? pq a quantidade de clientes infectados que eles têm deve ser gigantesca.

  6. #6

    Padrão

    Com toda sinceridade, acho que esta havendo uma certa supervalorizacao deste problema... Tem certeza de que realmente o problema sao os SYN? De quantos SYN por segundo estamos falando?

    Neste momento, por exemplo, o trafego do meu link esta em 32Mbs (1:10 da manha) o que eh bem baixo... De 18 as 23 eh o horario de pico onde o trafego chega a 96Mbs... Bem, neste momento estao passando cerca de 200 pacotes syn por segundo no meu roteador... Considerando-se um trafego 3x maior, pode colocar ai pelo menos 1000 pacotes syn por segundo... 520000 conexoes TCP simultaneas...

    Grande parte disto nao eh ataque nenhum, sao os programas de torrent... E isto nao deixa meu roteador nem de perto lento... E ele nem eh uma maquina tao boa assim, eh apenas um Core 2 de 2200Mhz com 3Gb de RAM... Faz o roteamento de 2500 clientes conectados simultaneos e ainda tem 6000 rotas BGP...

    Pacotes syn nao deveriam ser um problema a nao ser que voce esteja usando um hardware dimensionado bem abaixo disto... Digo bem mesmo, tipo Athlon XP 2000 pra baixo e pouquissima RAM...

    Telemar, nao tem problemas com isto pois eles nao usam um hardware ruim como o meu... Usam roteadores mesmo, nao PCs... Roteadores tem uma capacidade de processar IRQs muito maior... Aguentam muito mais pacotes por segundo...

    Voce nao citou, mas pelo forum onde postou, esta usando um Mikrotik como router, certo? Se sim, que RB eh? Ou eh computador? Tem umas RBs que realmente nao aguentam nada...
    Última edição por mtrojahn; 24-11-2009 às 01:21.

  7. #7

    Padrão

    é um atlhon X2 , 2.4ghz e 1024 ddr400. o processamento do cpu fica 0% o dia todo, inclusive nos momentos que começa a putaria.

    Eu não sei como medir exatamente os pacotes pra te dizer quantos por segundo são. mas olhando lá pela aba connections de ip>firewall , em horário de pico e com os clientes bichados conectados, apareciam cerca 500 conexões syn na tela.

    Se os syns não forem a causa, são sintomas, pois o problema começa quando eles aparecem. Não tenho experiência suficiente pra bater o olho e deduzir o problema, seja ele os syn ou nao.

  8. #8

    Padrão

    Eh, realmente eh complicado deduzir...

    O seu Mikrotik é o ultimo ponto antes da Internet? É seu roteador de borda?

    Há um bom tempo eu desisti de usar Mikrotiks na borda justamente pela falta de uma ferramenta boa para casos como este... O torch eh uma bela porcaria e o packet sniffer nao serve pra nada util... tcpdump e jnettop do Linux sao muito mais úteis para identificar ataques ou algo do genero...

    Vamos comecar do basico entao... Quando o problema ocorre, vendo esta tela, voce consegue identificar que vem apenas de 1 cliente seu? Se sim, coloque esta regra no FORWARD do seu IP > FIREWALL e deixe logando por alguns segundos e depois poste o log aqui...

    /ip firewall filter add chain=forward src-address=1.1.1.1 protocol=tcp action=log log-prefix=saida
    /ip firewall filter add chain=forward dst-address=1.1.1.1 protocol=tcp action=log log-prefix=entrada

    O IP 1.1.1.1 tem que ser substituido, obviamente... Lembre-se de mover ambas as regras para o topo do FORWARD e deixar apenas alguns segundos... Fique preparado para desativa-las pois, caso o ataque seja pesado, a propria regra pode deixar o Winbox lento.

    Acompanhe o log com "/log print follow" ao inves da tela LOG, pois eh mais rapido e menos penoso para a performace do Winbox.

    Essa regra logara todos os pacotes entrando e saindo do IP X... Funcionara praticamente como um tcpdump e dara uma nocao exata do que esta ocorrendo...

  9. #9

    Padrão

    essa maquina não é a border não, tem um load balance depois dela, esse load que recebe os links, balanceia eles (nth) e joga pro servidor.

    Vou fazer o teste que vc sugeriu, só deve demorar um pouco agora pois todos os clientes com o problema já formataram. Foi uma dor de cabeça explicar a coisa pra eles....