Ipset com Iptables com grande lista de intervalos de IP (CIDR)

Ipset com Iptables com grande lista de intervalos de IP (CIDR)

Li algumas respostas aqui sobre o bloqueio de intervalos de endereços IP e já usei iptablespara esse fim antes. Sugere-se usar ipsetem combinação com iptables.

Eu só instaleiipsetmas ainda não o configurei.

Eu encontrei este siteip2location. compara gerar uma lista de IPs a serem banidos por país. Selecionei os 5 países que segmentam nossos sites regularmente, mas a lista é enorme,256.000 linhas.

  • Essa lista enorme tornaria meu servidor lento ao usá-lo ipset(antes de tentar usar apenas IPtables, questionei que um arquivo tão grande poderia diminuir o desempenho).
  • Se for esse o caso, qual é a maneira de fazer isso? No momento eu uso o fail2ban, mas não acho que a configuração do nginx esteja configurada corretamente (presumo regex). De qualquer forma, preciso de uma forma mais robusta.
  • Por fim, não pretendo entender o CIDR o suficiente para diminuir esta lista (agregar intervalos de IP semelhantes, se possível).

Por exemplo, existem várias entradas /21:

185.179.152.0/22

Uma ferramenta online mostra que isso resolve para: 185.179.1520,0 a 185,179.1550,255

Não creio que exista uma maneira fácil de diminuir as entradas, portanto, qualquer conselho sobre questões de implementação e desempenho, por favor.

Responder1

Existe um utilitário de linha de comando chamado aggregate. Ele pega uma lista de netblocks CIDR e agrega blocos consecutivos no bloco maior correspondente. Ele também remove netblocks redundantes.

Por exemplo:

$ aggregate -q << EOF
> 192.168.0.0/24
> 192.168.1.0/24
EOF
192.168.0.0/23

Alimente-o com um arquivo de texto contendo apenas seus blocos CIDR e ele tentará agregá-los, reduzindo o tamanho da lista.

Na página de manual:

DESCRIPTION
       Takes  a list of prefixes in conventional format on stdin, and performs
       two optimisations to attempt to reduce the length of the prefix list.

       The first optimisation is to remove any supplied prefixes which are su‐
       perfluous because they are already included in another supplied prefix.
       For example, 203.97.2.0/24 would be removed if 203.97.0.0/17  was  also
       supplied.

       The  second  optimisation identifies adjacent prefixes that can be com‐
       bined under a single, shorter-length prefix. For example, 203.97.2.0/24
       and 203.97.3.0/24 can be combined into the single prefix 203.97.2.0/23.

aggregateé empacotado na maioria das principais distribuições Linux, incluindo Ubuntu.

(Observe que peguei uma lista desse site e tentei agregá-los e nada aconteceu, então eles já podem estar agregados. Você certamente pode usar mais de um ipset, o que provavelmente é a melhor coisa a fazer aqui.)

Responder2

Normalmente, o comprimento máximo de uma lista ipset é de 65.536 elementos, então talvez seja necessário usar uma lista separada para cada país que deseja bloquear.

Usando um conjunto hash:net você pode adicionar diretamente os registros CIDR que deseja banir. Você pode querer verificarhttps://www.ipdeny.com/ipblocks/para blocos em nível de país

Quanto às suas perguntas

  • O ipset não deve desacelerar significativamente o seu sistema - ele usará um pouco de memória para manter os conjuntos, mas caso contrário a carga não deverá ser perceptível
  • É bom manter o fail2ban, já que os invasores podem usar servidores cloud/vps em qualquer país

Finalmente, há muitas perguntas semelhantes sobre o uso do iptables com ipset para bloquear países específicos, então não entrarei em detalhes de configuração do iptables - apenas verifique https://askubuntu.com/questions/868334/block-china-with-iptablesou similar

Responder3

Você poderia usar oxt_geoipcomplemento xtables em vez disso?

geoip vs ipset xt_geoip usa o formato (provavelmente) mais eficiente, um blob compactado (não compactado). Carregar um país no kernel custa tanto quanto o arquivo no disco.

Como o ipset não suporta intervalos arbitrários de IPaddr-IPaddr, seria necessário aproximar isso usando, por exemplo, várias entradas de Network/Prefixlength. Além disso, se um tipo de conjunto de hash for usado, você pode assumir que, pela natureza dos hashes e/ou árvores, alguns buckets permanecem vazios e/ou são necessários metadados adicionais. O consumo de memória com um geoip baseado em ipset é naturalmente maior. Relatórios de usuários1indicam que pode se tornar duas ordens de magnitude maior em certos casos (iptreemap).

O tempo de pesquisa do xt_geoip é O(log2(ranges)), portanto, para pesquisar um endereço dentro de 20.000 intervalos, são necessárias no máximo 15 iterações cada uma com comparações de endereços (no máximo 3). ipset usa Jenkins3 para hash, que tem um certo custo de tempo próprio.

Nenhum teste empírico de temporização foi realizado até agora.

informação relacionada