Devo classificar pacotes com iptables?


8

Estou usando o iptables no Ubuntu Server. É um servidor web em um VPS.
Gostaria de saber se devo limitar os pacotes de taxa. Em caso afirmativo, como devo limitar a taxa? E devo fazer isso globalmente ou por endereço IP?

Referência
: vi pessoas sugerindo isso:

# Limit packet traffic on a TCP or UDP port:
iptables -A INPUT -p $proto --destination-port $port --syn -m state --state NEW -m limit --limit $lim/s --limit-burst $lb -j ACCEPT

# Limit established/related packet traffic:
iptables -A INPUT -m state --state RELATED,ESTABLISHED -m limit --limit $lim/s --limit-burst $lb -j ACCEPT

Acima, um limite de taxa global não parece muito útil, pelo menos nos casos que posso imaginar. Existe algum caso em que eu deva limitar a taxa globalmente?
Eu acredito que um limite de taxa por IP geralmente é melhor:

# Add the IP to the list:
iptables -A INPUT -p $proto --destination-port $port --syn -m state --state NEW -m recent --set --name RATELIMITED
# Drop if exceeded limit:
iptables -A INPUT -p $proto --destination-port $port --syn -m state --state NEW -m recent --update --seconds $sec --hitcount $hc --rttl --name RATELIMITED -j DROP
# Accept if inside limit:
iptables -A INPUT -p $proto --destination-port $port --syn -m state --state NEW -j ACCEPT

Pergunta adicional: IPs remotos podem ser falsificados. Como limitá-los corretamente?
Foi adicionada outra pergunta para isso:
/server/340258/how-to-rate-limit-spoofed-ips-with-iptables

O objetivo
que estou tentando reduzir é o risco de alguns ataques D / DoS e abuso geral.

Relacionado
Como posso classificar conexões SSH limitadas com iptables?

PS : Acabei de abrir uma pergunta relacionada apenas para o ICMP e inclui limitação de taxa para este protocolo: iptables | Tipos de ICMP: quais são (potencialmente) prejudiciais?

Respostas:


6

Um limite de taxa não é uma prevenção, mas um convite ao DoS - especialmente no sabor apresentado acima, onde os pacotes serão descartados se uma certa taxa de pacotes não autenticados sem informações de estado tiver sido excedida. Como todos podem forjar pacotes (incluindo endereços IP de origem) nesse estado de conexão sem maiores esforços, um novo vetor de ataque DoS que alavanca seu recurso de limite de taxa irá surgir.

Um limite de taxa geralmente só fará sentido se você tiver

  1. um limite previsível de conexão rígida ou flexível em sua configuração
  2. defina o limite de taxa para tráfego geral abaixo desse limite para poder configurar conexões para tráfego prioritário ou administrativo, independentemente da carga

Embora 1. com frequência seja difícil o suficiente para determinar o incômodo, 2. obviamente funcionará apenas se você conseguir diferenciar de forma confiável o tráfego "prioritário ou administrativo" do restante na configuração da conexão - por exemplo, se estiver passando por uma interface de rede diferente.

Em outros casos, prefere reduzir a resiliência do seu sistema do que adicionar a ele.


Oi syneticon-dj. Entendo e concordo que um firewall mal configurado é outra ferramenta para um ataque de negação de serviço. Obrigado pela atenção!
ML--

A limitação de taxa por IP ou por porta IP também parece fazer sentido ao defender um tráfego legítimo muito grande para o servidor, mas cujo originador provavelmente não explorará o problema mencionado, por exemplo, comportamento abusivo do Bingbot ou Bots do Facebook.
Ján Lalinský 12/01/19

3

O problema com -m limit é a limitação de todos os pacotes TCP, independentemente dos endereços IP de origem. Portanto, se você tem uma limitação baixa para pacotes syn como

-A INPUT -p tcp  --syn -m limit --limit 30/s --limit-burst 30 -j ACCEPT
-A INPUT -p tcp --syn -j DROP

somente um cliente com a linha de comando hping pode derrubar o servidor enviando tantos pacotes tcp com sinalizador SYN, porque a regra de limite corresponderá e eliminará muitos pacotes, independentemente dos endereços IP de origem. O limite não faz diferença entre tráfego bom e tráfego ruim. Isso reduzirá também o bom tráfego de entrada.

hping pode ser algo como:

hping thetargetedhostip -p 80 -S -c 1000 -i u20000

É melhor usar o hashlimit para limitar as conexões TCP recebidas por endereço IP . A regra a seguir corresponderá apenas se 30 pacotes por segundo forem recebidos, reduzindo o número de pacotes autorizados por IP para 15 pacotes por segundo.

-A INPUT -p tcp --syn -m hashlimit --hashlimit 15/s --hashlimit-burst 30 --hashlimit-mode srcip --hashlimit-srcmask 32 --hashlimit-name synattack -j ACCEPT 
-A INPUT -p tcp --syn -j DROP

De fato, estou convencido de que muitos servidores que estão desativados hoje não estão esgotados durante um ataque, mas devido ao módulo de limite diminuir todo o tráfego de entrada.


1

Normalmente, limite as regras de limitação de taxa aos servidores que espero ter:

  • baixas quantidades de tráfego esperado
  • serviços de autenticação

Por exemplo, a página de login de um painel de controle de hospedagem, POP3, IMAP, SSH etc. Geralmente, deixo os serviços HTTP abertos e bloqueio apenas se houver algum problema.

Você não deseja descartar um bom tráfego na web. Um link no slashdot pode enviar muito tráfego e, com as regras globais, você pode não perceber um problema.

Com relação aos IPs falsificados, eles não podem ser bloqueados usando esse método e normalmente não são uma preocupação, pois essas regras se concentram principalmente na limitação de conexões TCP estabelecidas. Com um IP falso, a conexão TCP nunca pode ser estabelecida.


Oi jeffatrackaid, obrigado pela sua resposta! Também estou inclinado a limitar a taxa (globalmente) desses tipos de serviços (SSH etc). Em relação ao tráfego HTTP, é por isso que não pretendo aplicar um limite global. Nesta pergunta, espero ver se há casos em que um limite por IP pode ser interessante. Em relação aos IPs falsificados (eu abri uma pergunta separada sobre isso), embora as conexões não possam ser estabelecidas, existe a possibilidade de um DoS usando uma inundação SYN. Continuo interessado em saber como isso pode ser mitigado.
ML--
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.