bloqueando o ip do ataque do udp com o iptables [duplicado]

1

Eu estava tentando bloquear um ip de (ferramenta de estresse da rede - um site de ddos vendendo bots de dodo por segundos online) o primeiro que eu estava tentando bloquear com o iptables:

iptables -A INPUT -d 173.193.26.73 -j DROP
iptables -A INPUT -s 173.193.26.73 -j DROP

no entanto eu ainda vejo o ip e a largura de banda ainda no iftop. também ainda ver o ip acontecendo no tcpdump.

isso é normal? qual é o problema aqui?

    
por user230060 10.07.2014 / 20:08

2 respostas

3

Sim, é normal. iptables não impede que o tráfego de entrada acesse sua interface física, aumentando assim o seu iftop de contagens, e isso não impede o kernel de ver que ele está lá, portanto, a saída tcpdump . No entanto, ele impede que o kernel transfira o tráfego para algo que possa estar escutando.

Se você vir algum tráfego de saída em resposta a esses pacotes de entrada, algo está errado. Mas por outro lado, não, isso é normal.

    
por 10.07.2014 / 20:18
1

Como MadHatter mencionou ...

Os pacotes ainda estão sendo transmitidos fisicamente para o seu sistema, o iptables está apenas filtrando-os antes que cheguem onde o remetente os quer.

No entanto ...

Existem algumas coisas que você pode fazer para solucionar o problema subjacente:

  1. Coloque um roteador entre sua máquina e o mundo externo , que faz a filtragem para você, e encaminha todos os outros pacotes de maneira transparente.

    Os roteadores são otimizados para esse tipo de operação, portanto, como primeira linha de defesa, certamente não é uma má ideia. Embora você deseje manter o firmware atualizado, se não fizer isso sozinho.

    Claro, você também desejará alterar o registro DNS para um servidor de failover (se estiver preocupado com o tempo de inatividade, o que provavelmente é) enquanto conecta o roteador e certifica-se de que está fazendo o que deseja para fazer.

  2. Use -I em vez de -A ; Dessa forma, as regras de bloqueio são processadas primeiro, e sua CPU não grava quantos ciclos você verificar que os pacotes que você sabe imediatamente são horríveis contra todas as outras regras.

    Se o site está tentando fazer DoS, acredito que eles constituam uma fonte significativa de tráfego e, se for o caso, as regras que se aplicam a eles devem ser processadas antes. Uma boa regra é ordenar as regras com base na probabilidade do evento. Quanto mais provável o evento de rede, mais cedo ele deve ser tratado.

    Naturalmente, isso também deve ser pesado contra a complexidade do processamento do evento de rede (ou seja, se o evento A for duas vezes mais provável que o evento B, mas requerer 300 vezes o processamento, as regras do evento B provavelmente no caso de algumas regras de descarte de um site que está tentando um DoS, é provavelmente uma aposta segura.

    Uma maneira de evitar que o conjunto de regras iptables fique pesado é criando novas cadeias para lidar com cada tipo de tráfego (por exemplo, uma cadeia para lidar com tentativas de conexão de rede privada, uma cadeia para manipular o afogamento ssh etc.) para que o INPUT chain (que pode ser considerado como um método main se você tiver um histórico de programação) apenas chama outras cadeias para fazer a carne do processamento. Portanto, se você quiser experimentar novos conjuntos de regras ou alterar a ordem de processamento de eventos diferentes, só precisará alterar a ordem de saltos incondicionais em INPUT.

  3. Verifique os Termos de Serviço do seu ISP e, se estiverem em violação, informe o seu ISP (sendo o mais específico possível sobre a forma como estão em violação; você vai querer forneça referências, e você vai querer ser educado e profissional. Se a pessoa que recebe seu e-mail gostar de você e você facilita o trabalho, é mais provável que você obtenha um resultado). / p>

por 11.07.2014 / 05:24

Tags