Especialista iptables ajuda necessária?

Question

Após uma análise detalhada, coletei esses detalhes.

Estou sob uma inundação UDP que é mais dependente de aplicativos. Eu corro um Servidor de Jogo e um invasor está me inundando com a consulta "getstatus" que faz o GameServer responder fazendo as respostas à consulta que fazem com que a saída para o IP do atacante chegue a 30mb / se o atraso do servidor.

Aqui estão os detalhes do pacote,

O pacote começa com 4 bytes 0xff e depois getstatus.
Teoricamente, o pacote é como "\ xff \ xff \ xff \ xffgetstatus"

Agora que eu tentei muitas variações do iptables como estado e limitação de taxa ao lado, mas elas não funcionaram. O limite de taxa funciona bem, mas apenas quando o servidor não é iniciado. Assim que o servidor inicia, nenhuma regra do iptables parece bloqueá-lo.

Alguém mais conseguiu mais soluções? alguém me pediu para entrar em contato com o provedor e fazê-lo na Rede / Roteador, mas isso parece muito estranho e acredito que eles podem não fazê-lo, pois isso também afetaria outros clientes.

Respondendo a todas essas respostas, eu diria:

Em primeiro lugar, é um VPS, então eles não podem fazer isso por mim. Em segundo lugar, eu não me importo se algo está chegando, mas desde a sua aplicação gerada, então tem que haver uma solução no nível do sistema operacional para bloquear os pacotes de saída. Pelo menos os que saem devem ser parados.

Em segundo lugar, não é Ddos desde apenas 400kb / s de entrada gera 30mb / s de saída do meu GameServer. Isso nunca acontece em um D-DOS. Pedir a solução de nível de provedor / hardware deve ser usada nesse caso, mas esta é diferente. E sim, Banir seu IP interrompe o fluxo de pacotes de saída, mas ele tem muito mais endereços IP, já que ele falsifica seu original, então eu só preciso de algo para bloqueá-lo automaticamente.

Até tentei muitos Firewalls, mas como você sabe, eles são apenas front ends para o iptables, então se algo não funciona no iptables, o que os firewalls fazem?

Estas foram as regras que tentei,

iptables -A INPUT -p udp -m state --state NEW -m recent --set --name DDOS --rsource
iptables -A INPUT -p udp -m state --state NEW -m recent --update --seconds 1 --hitcount 5 --name DDOS --rsource -j DROP

Funciona para os ataques em portas não usadas, mas quando o servidor está escutando e respondendo às consultas recebidas pelo invasor, ele nunca funciona.

Okay Tom.H, suas regras estavam funcionando quando eu as modifiquei de alguma forma assim:

iptables -A INPUT -p udp -m length --length 1:1024 -m recent --set --name XXXX --rsource
iptables -A INPUT -p udp -m string --string "xxxxxxxxxx" --algo bm --to 65535 -m recent --update --seconds 1 --hitcount 15 --name XXXX --rsource -j DROP

Eles trabalharam por cerca de 3 dias muito bem onde a string "xxxxxxxxx" seria limitada por uma taxa, bloqueada se alguém fosse inundada e também não afetasse os clientes. Mas só hoje, tentei atualizar a cadeia para tentar remover um IP anteriormente bloqueado para que eu tivesse que liberar a cadeia e restaurar essa regra (iptables -X e iptables -F), alguns clientes já estavam conectados a servidores inclusive eu. Portanto, a restauração das regras agora também bloquearia algumas das cadeias de clientes completamente, enquanto algumas não são afetadas. Então isso significa que eu preciso reiniciar o servidor ou por que mais isso aconteceria porque a última vez que as regras estavam funcionando, não havia ninguém conectado?

    

Answer 1

Você está quase lá, mas é possível que você tenha sido responsável pelo trabalho de outra pessoa, possivelmente no limite de taxa ssh, sem realmente entender. Por favor, note que não estou criticando você: construir o trabalho de outras pessoas é uma excelente ideia na comunidade de software livre; mas você deve entender por que eles fizeram o que fizeram, então você não deixa de usá-lo corretamente.

Eu configurei um equipamento de teste, usando nc (netcat) para inundar o tráfego UDP de uma máquina chamada bill para uma máquina chamada risby com as seguintes linhas:

risby% nc -l -u 12345
bill% seq 1 10000000 | nc -u risby 12345

Isso produziu uma lista de números muito rapidamente crescente a partir do netcat do risby, muito parecido com a inundação de comandos que você está tendo.

Mas quando criei duas novas regras para o iptables de risby que filtravam apenas o tráfego UDP para a porta 12345 sem considerar o estado , funcionou bem:

iptables -I INPUT 1 -p udp --dport 12345 -m recent --set --name ddos
iptables -I INPUT 2 -p udp --dport 12345 -m recent --rcheck  --seconds 1 --hitcount 5 --name ddos -j DROP

Quando eu corri novamente os netcats, os primeiros pacotes da conta passaram pelo risby, e os números subiram rapidamente para cerca de 1800, mas depois pararam completamente e nenhum tráfego adicional foi recebido da conta.

Note que é muito importante que estas regras venham cedo na sua cadeia INPUT do iptables, e é por isso que as insiro nas linhas 1 e 2, respectivamente.

Editar :

Aumente a taxa e exija que ela seja mantida por mais tempo; talvez --seconds 10 --hitcount 50 ? Eventualmente, você atingirá um limite em que poucos clientes legítimos são afetados, mas o DDoS ainda é substancialmente limitado. Note que o fogo amigo é sempre uma possibilidade neste tipo de afogamento de camada 3; meu próprio servidor ssh limita novas conexões a duas por 60s, o que torna as scps repetidas bastante lentas. Mas é um preço que eu estou disposto a pagar e, para fazer melhor, é necessário o afogamento da camada 4, o que significa que o aplicativo precisa estar ciente do afogamento. iptables não pode ajudá-lo lá.

Observo que --hitcount não pode receber nenhum valor maior que o parâmetro ip_pkt_list_tot do módulo do kernel xt_recent e, se o valor for excedido, um erro será lançado no momento da criação da regra:

[root@risby scratch]# iptables -A INPUT -p udp -m recent --rcheck  --seconds 1 --hitcount 50 --name ddos -j DROP 
iptables: Invalid argument. Run 'dmesg' for more information.

Mas esse valor pode ser definido em até 255 no momento da inserção do módulo. Seguindo as sugestões nesta entrada de blog , é possível recarregar o módulo , definindo o parâmetro explicitamente:

[root@risby scratch]# rmmod xt_recent
[root@risby scratch]# modprobe xt_recent ip_pkt_list_tot=100
[root@risby scratch]# iptables -A INPUT -p udp -m recent --rcheck  --seconds 1 --hitcount 50 --name ddos -j DROP 
[root@risby scratch]# 

Observe como o --hitcount 50 não causa mais erros. Talvez você precise liberar a INPUT chain ( iptables -F INPUT ) e quaisquer outras cadeias que usam o módulo recent antes de poder remover e reinserir o módulo xt_recent .

    

Answer 2

use o tcpdump para obter um dump de pacote do tráfego.

tcpdump -s0 -w somefile.tcp proto udp and port NN and host www.xxx.yyy.zzz

inspecione os pacotes em wireshark para a cadeia de bytes que você deseja corresponder;

crie uma regra iptables com uma correspondência de seqüência de caracteres para procurar a sequência do protocolo de aplicativo, para permitir um determinado número desses pacotes por segundo e depois descartar o restante desses pacotes

iptables -I INPUT -p udp --dport NN -m string  --algo bm \
 --hex-string "|ff ff ff ff 67 65 74 73 74 61 74 75 73|" \
 -m limit --limit 1/second -j ACCEPT

iptables -I INPUT -p udp --dport NN -m string  --algo bm \
 --hex-string "|ff ff ff ff 67 65 74 73 74 61 74 75 73|" -j DROP 

sua sorte é o udp, porque é menos exigente em termos de recursos para fazer a correspondência no módulo netfilter ...

ressalvas são que você vai bloquear todas as requisições getstatus, a menos que você possa encontrar algum outro filtro apenas para esta fonte, e que você terá que fazer um pouco de trabalho na Wikipédia para descobrir a representação hexadecimal correta da sua correspondência string

    

Answer 3

Entre em contato com seu Provedor e peça para bloquear o tráfego no roteador.
Isso não afetará outros clientes, pois eles levarão em conta o destino dos pacotes (= seu servidor).

Cada iptables ou outra abordagem local não será uma solução, já que os pacotes precisam ser tratados de qualquer maneira, então eles afetarão seu servidor.

    

Answer 4

Você já pensou em proibir o seu IP (se ele não o está falsificando)? O que você está enfrentando é conhecido como negação de serviço. Eu sugiro que você experimente o OSSEC. Isso pode ajudar a bloquear o IP que o invasor está usando.