Início / unix / Perguntas / 556804
Accepted
user1404316
Asked: 2019-12-12 17:23:28 +0800 CST

firewall: regras de contador nftable

  • 772

Alguns meses atrás, eu migrei o firewall de um laptop debian de iptablespara nftables, usando o procedimento recomendado pelo debian, e tudo parece estar bem. Agora, meses depois, estou examinando o conjunto de regras criado por esse procedimento de migração, tentando aprender a nftablessintaxe e ver o que parecem ser várias regras baseadas em contadores que não entendo e suspeito que podem não estar corretas. Não encontrei o nftableswiki como um recurso educacional útil e não encontrei nenhum outro recurso educacional on-line que aborde esse tipo de pergunta:

O conjunto de regras padrão migrado automaticamente inclui o seguinte:

table inet filter {
  chain INPUT {
    type filter hook input priority 0; policy drop;
    counter packets 123 bytes 105891 jump ufw-before-logging-input                                                                                                                                
    counter packets 123 bytes 105891 jump ufw-before-input
    counter packets 0 bytes 0 jump ufw-after-input
    counter packets 0 bytes 0 jump ufw-after-logging-input
    counter packets 0 bytes 0 jump ufw-reject-input                                                                                                                                               
    counter packets 0 bytes 0 jump ufw-track-input                                                                                                                                                
  }

As duas primeiras counterdeclarações são exemplos do que me chamou a atenção. Estou certo de que eles estão dizendo "pule para as regras na seção ufw-before-foo, mas somente após os primeiros 123 pacotes e os primeiros 105891 bytes terem sido recebidos".

  1. Por que não iniciar imediatamente do pacote 0 byte 0?
  2. Por que não usar uma sintaxe >= que parece ser suportada por nftables?
  3. Esses números são arbitrários? Possivelmente devido a uma falha na migração?

O conjunto de regras acima inclui um salto para a cadeia a seguir, com um problema possivelmente semelhante. Aqui está um trecho dele:

  chain ufw-before-input {
    iifname "lo" counter packets 26 bytes 3011 accept
    ct state related,established counter packets 64 bytes 63272 accept
    ct state invalid counter packets 0 bytes 0 jump ufw-logging-deny
    ct state invalid counter packets 0 bytes 0 drop
    ...
  }
  1. Por que as decisões de aceitação são baseadas no recebimento de 26 ou 64 pacotes anteriores?
  2. Um firewall pode ser liberado arbitrariamente a qualquer momento após a inicialização e a descoberta/conexão da rede, então por que descartar todos esses pacotes iniciais?

Como mencionei acima, essas regras estão em vigor há meses, então estou me perguntando que efeito negativo elas poderiam ter tido. O único candidato que encontrei é que o laptop às vezes pode ter dificuldade em fazer uma conexão wifi (especialmente depois de sair do modo de suspensão), enquanto um segundo laptop próximo não tem esse problema.

  1. Essas regras que descartam pacotes podem ser as culpadas pela dificuldade de negociar uma conexão wifi?
firewall nftables

1 respostas

  1. Best Answer

    Não, a explicação é muito mais simples: o contador possui argumentos opcionais de pacotes e bytes que exibem a quantidade de pacotes e bytes contados pelo contador quando um pacote atingiu a regra onde estava. Sem filtro antes do contador, qualquer pacote (inclusive no loopback) aumentará os valores para que possa acontecer muito cedo e rápido. A ferramenta de conversão viu um contador padrão do iptables e optou por também traduzir seus valores para fidelidade.

    Então geralmente quando você escreve uma regra você não define esses valores, você coloca um simples countersozinho, e ambos recebem um padrão de 0. Quando os pacotes passam por ela, esses valores aumentam. Opcionalmente , especialmente quando usado em um objeto com estado de contador nomeado , onde ele pode até ser exibido e redefinido (usando algo como nft reset counters), para fazer alguma forma de contabilidade, pode-se definir esses valores ao escrever o conjunto de regras: geralmente ao restaurar o conjunto de regras salvo logo antes de reiniciar. Isso só pode ser redefinido se usado como a variante nomeada , não como um contador anônimo "inline". Eles não podem ser usados ​​para alterar a correspondência em uma regra, não há outra opção a não ser exibi-los.

    Qualquer problema de wifi que você tenha não pode ser causado por nenhuma declaração contrária .

    Se agora você deseja usar a contagem de pacotes para limitar o uso de regras em um firewall nftables, existem alguns métodos diferentes, dependendo das necessidades:

    • a outra cota de objeto com estado (novamente que pode ser usada anonimamente, mas só pode ser redefinida se usada com o nome ). Você pode então ter, por exemplo, uma regra que nunca corresponde ou começa a corresponder dependendo de sua contagem.

    • há a declaração de limite para contar as taxas . Por exemplo, se você tem medo de que uma regra de log possa inundar arquivos de log, você pode usar isso para limitar o número de logs feitos. Também pode limitar a taxa a algum recurso (geralmente usado com outros filtros com conntrack).

    • com um nftables recente o suficiente (0.9.2?) e kernel (4.18?), existe a expressão ct count conntrack para contar o número de conexões estabelecidas usando conntrack, geralmente para limitar o acesso simultâneo a algum recurso (ssh, servidor web... )

    • 2

relate perguntas