lançamento do filtro de pacotes , que está se desenvolvendo como uma substituição para iptables, ip6table, arptables e ebtables, por meio da unificação das interfaces de filtragem de pacotes para IPv4, IPv6, ARP e pontes de rede. O pacote nftables inclui componentes do filtro de pacotes que operam no espaço do usuário, enquanto a operação a nível de kernel é garantida pelo subsistema nf_tables, que faz parte do kernel Linux desde a versão 3.13. As alterações necessárias para a operação da versão nftables 0.9.2 foram incluídas no kernel Linux 5.3.
No nível do kernel, é fornecida apenas uma interface geral, independente do protocolo específico, que oferece funções básicas de extração de dados de pacotes, execução de operações sobre dados e controle de fluxo. A lógica de filtragem e os manipuladores específicos de protocolo são compilados em bytecode no espaço do usuário, após o que esse bytecode é carregado no kernel através da interface Netlink e executado em uma máquina virtual especial, semelhante ao BPF (Berkeley Packet Filters). Essa abordagem permite reduzir significativamente o tamanho do código de filtragem que opera no nível do kernel e transferir todas as funções de análise de regras e lógica de trabalho com protocolos para o espaço do usuário.
Principais novidades:
- A capacidade de verificar o número da porta do cabeçalho do pacote de nível de transporte independentemente do tipo de protocolo de nível 4:
add rule x y ip protocol { tcp, udp } th dport 53
- Suporte à recuperação do tempo de vida de um conjunto de elementos:
add element ip x y { 1.1.1.1 timeout 30s expires 15s }
- A capacidade de verificar opções individuais (lsrr, rr, ssrr e ra) de pacotes IPv4:
add rule x y ip option rr exists drop
Para opções de roteamento, é possível verificar os campos type, ptr, length e addr:
add rule x y ip option rr type 1 drop
- Nas expressões, agora é permitido especificar prefixos de rede e faixas de endereços:
iifname ens3 snat to 10.0.0.0/28
iifname ens3 snat to 10.0.0.1-10.0.0.15 - Suporte ao uso de variáveis nas definições de cadeias:
define default_policy = accept
add chain ip foo bar { type filter hook input priority filter; policy $default_policy } - A prioridade da cadeia agora pode ser definida tanto em forma numérica quanto simbólica:
define prio = filter
define prionum = 10
define prioffset = «filter — 150»add table ip foo
add chain ip foo bar { type filter hook input priority $prio; }
add chain ip foo ber { type filter hook input priority $prionum; }
add chain ip foo bor { type filter hook input priority $prioffset; } - Foi implementado o suporte ao módulo synproxy. Por exemplo, para colocar a porta TCP 8888 sob proteção da synproxy, pode-se usar o conjunto de regras:
table ip x {
chain y {
type filter hook prerouting priority raw; policy accept;
tcp dport 8888 tcp flags syn notrack
}chain z {
type filter hook forward priority filter; policy accept;
tcp dport 8888 ct state invalid,untracked synproxy mss 1460 \
wscale 7 timestamp sack-perm ct state invalid drop
}
} - Para definir na tabela conntrack as conexões adicionais esperadas relacionadas à conexão atual, que são utilizadas em protocolos e cenários que exigem a configuração de várias conexões, agora é possível definir políticas através de conjuntos de regras padrão. Por exemplo, para definir as conexões subsequentes esperadas para a porta TCP 8888 em relação à porta 5432, pode-se especificar as seguintes regras:
tabela x {
ct expectation myexpect {
protocol tcp
dport 5432
timeout 1h
size 12
l3proto ip
}chain input {
type filter hook input priority 0;
ct state new tcp dport 8888 ct expectation set myexpect
ct state established,related counter accept
}
}
Fonte: opennet.ru
