iptables

Question

Eu estava procurando atualizar o iptables em nosso servidor, o que evitaria o ataque DoS em certa medida.

1) Relacionado ao tráfego da web, abaixo estão as regras do iptables que encontrei.

iptables -I INPUT -p tcp --dport 80 -i eth0 -m state --state NEW -m recent --set
iptables -I INPUT -p tcp --dport 80 -i eth0 -m state --state NEW -m recent --update --seconds 60 --hitcount 10 -j DROP

iptables -A INPUT -p tcp --dport 80 -m state --state NEW -m limit --limit 50/minute --limit-burst 200 -j ACCEPT

iptables -A INPUT -m state --state RELATED,ESTABLISHED -m limit --limit 50/second --limit-burst 50 -j ACCEPT

Eu consigo entender as duas primeiras regras. Alguém pode esclarecer as últimas duas regras? Tomando as duas últimas regras, a primeira significa que apenas 50 novas conexões são aceitas por minuto? O que o limite de explosão faz? Eu tentei ler sobre isso. Mas não tenho certeza se eu entendi claramente. Significa que, uma vez que 200 novas conexões são aceitas em um minuto, então coloca um limite de apenas 50 novas conexões por minuto. E quaisquer novas solicitações de conexão serão descartadas. E quando voltará novamente permitindo a explosão de 200 novos pedidos novamente?

Agora, o que significa a última regra? Apenas 50 usuários podem ser conectados ao meu servidor web por segundo? Por que a contagem de estouro aqui é novamente a mesma 50? Com essas duas últimas regras, há chances de que algum tráfego legítimo seja descartado?

2) Eu me deparei com o conjunto de regras abaixo que estava sendo referido em tantos lugares para bloquear o portscan. Parece certo? Alguém pode explicar o que isso faz? Estou bastante inseguro sobre a lógica e por que o dport é 139 nas últimas 4 regras.

# Attempt to block portscans
# Anyone who tried to portscan us is locked out for an entire day.
iptables -A INPUT   -m recent --name portscan --rcheck --seconds 86400 -j DROP
iptables -A FORWARD -m recent --name portscan --rcheck --seconds 86400 -j DROP

# Once the day has passed, remove them from the portscan list
iptables -A INPUT   -m recent --name portscan --remove
iptables -A FORWARD -m recent --name portscan --remove

# These rules add scanners to the portscan list, and log the attempt.
iptables -A INPUT   -p tcp -m tcp --dport 139 -m recent --name portscan --set -j LOG --log-prefix "Portscan:"
iptables -A INPUT   -p tcp -m tcp --dport 139 -m recent --name portscan --set -j DROP

iptables -A FORWARD -p tcp -m tcp --dport 139 -m recent --name portscan --set -j LOG --log-prefix "Portscan:"
iptables -A FORWARD -p tcp -m tcp --dport 139 -m recent --name portscan --set -j DROP

    

Answer 1

A extensão limit implementa um mecanismo de token bucket. Geralmente, quando uma regra corresponde, o netfilter salta para o destino fornecido, ACCEPT neste caso. Quando você conecta a extensão limit , o netfilter tem que remover um "token" do "balde" desta regra antes que seja permitido pular. Se não houver tokens no bucket, essa extensão impedirá que o netfilter salte, mesmo que a regra tenha correspondido.

--limit 50/minute #tells netfilter to add 50 tokens per minute to the bucket
--limit-burst 200 #tells netfilter to use a bucket which holds up to 200 tokens

Se houver 50 solicitações de conexão por minuto (ou mais), seu servidor permitirá 50 novas conexões a cada minuto. Se houver menos de 50 solicitações em um minuto, o depósito será preenchido (na verdade, ele começará cheio). Isso significa que, se houver apenas algumas solicitações em um minuto, o servidor aceitará mais de 50 novas solicitações no próximo minuto. Para evitar que isso saia do controle, há um limite para o número de fichas que o recipiente pode conter. 200 neste caso. Quando o bucket estiver cheio, seu servidor aceitará as próximas 200 conexões recebidas, mesmo quando elas atingirem seu servidor ao mesmo tempo. Como isso é mais do que 50, chamamos isso de burst, onde o número de conexões aceitas chega a mais do que as 50 que queremos ON AVAERAGE .

A segunda regra significa que esta máquina aceitará 50 pacotes IP em segundo sem mais investigação, contanto que eles pertençam a um fluxo que o netfilter reconhece. Para avaliar os efeitos dessa regra, precisaríamos ver toda a cadeia (e cada cadeia que faz referência e é referenciada por). No entanto, posso lhe dizer algumas coisas que se alinham aqui:

1. O Netfilter conta o ACK do iniciador da conexão TCP para concluir o handshake como um pacote RELATED . 50 conexões estabelecidas com sucesso por minuto saturam perfeitamente a segunda regra com a qual você está tendo problemas.

2. As implementações TCP mais comuns fazem quatro tentativas de conexão antes de desistir. Com 50 conexões estabelecidas com sucesso, você recebe 200 solicitações de conexão, no pior dos casos.

3. Não importa com que frequência um endpoint faça uma solicitação de conexão específica, apenas um precisa ser bem-sucedido, dentro de um período de tempo razoável, para estabelecer a conexão. A maioria das implementações coloca 60 segundos como a quantidade de tempo razoável padrão.

Se a última regra fosse 50/minute , essas quatro regras poderiam ser parte de uma estrutura de proteção do DoS realmente interessante. Como ele não tem o filtro --dport 80 e é 50/second , só posso adivinhar:

a) Você arrancou totalmente esta linha do contexto e ela não está imediatamente relacionada aos três primeiros.

b) Esse é um limite geral para diminuir o tráfego.

c) É um erro e deve ser 50/minute .

d) É uma troca entre proteger o servidor contra ataques DoS e manter o serviço acessível durante e imediatamente após um ataque DoS.

Para entender o segundo recorte, primeiro você deve detalhar que a extensão recent usa e mantém o conhecimento sobre o endereço IP de origem.

A extensão recent gerencia seu conhecimento em listas. A lista padrão é denominada DEFAULT e é usada se nenhuma outra lista for fornecida. Um fornece outra lista usando --name .

Portanto, as duas primeiras regras significam "descartar este pacote se o IP de origem tiver sido colocado na lista portscan nos últimos 86400 segundos".

As segundas duas regras significam "remova este endereço IP da lista portscan ". Por favor, não que esta regra seja avaliada apenas se a regra anterior não corresponder. Esta regra existe para manter a lista portscan curta. Listas mais longas levam mais tempo para pesquisar.

As últimas quatro regras colocam os IPs de origem na lista portscan , registram sobre isso e DROP o pacote. --dport 139 está lá porque esse comportamento é desejado apenas neste caso. Tenho certeza de que essas regras fazem muito mais sentido quando no contexto, porque isso não é um conjunto completo de regras para impedir a varredura de portas.