Depurador para Iptables

47

Estou procurando uma maneira fácil de seguir um pacote através das regras do iptables. Não se trata tanto de log, porque não quero registrar todo o tráfego (e só quero ter destinos de LOG para poucas regras).

Algo como o Wireshark for Iptables. Ou talvez até algo semelhante a um depurador para uma linguagem de programação.

Obrigado Chris

Nota: Não precisa ser uma ferramenta gráfica sofisticada. Mas deve fazer mais do que apenas mostrar um contador de pacotes ou mais.

Atualização: quase parece que não conseguimos encontrar nada que ofereça a funcionalidade solicitada. Nesse caso: Vamos pelo menos encontrar uma boa técnica baseada no log do iptables - que pode ser ativada e desativada facilmente e não requer a redundância das regras do iptables (é necessário escrever a mesma regra para -j LOGe -j ...)

ip  iptables  debugging  packet-analyzer 
— Chris Lercher
fonte

Respostas:

10

Não consigo pensar em uma solução direta, mas consigo pensar em uma maneira de rastrear um pacote.

  1. Registre cada regra com uma diretiva de prefixo de log (--log-prefix "Rule 34")
  2. Gere um pacote de teste ou fluxo de pacotes com scapy e defina o campo TOS para algo único
  3. grep a saída do arquivo de log para essa configuração TOS e veja quais regras o registraram.
— Haakon
fonte
Obrigado pela ideia. Infelizmente, eu não posso registrar cada regra (em um sistema, o disco provavelmente não seria rápido o suficiente para fazer isso Em outra, o iptables log não está disponível no kernel..)
— Chris Lercher
1
Use um pipe nomeado como o arquivo softpanorama.org/Logs/Syslog/pipes_in_syslog.shtml Entretanto, desde que você não pode entrar em seu kernel você está meio SOL
— Haakon
Obrigado, provavelmente não resolverá o meu problema, mas geralmente é bom saber que o syslog de canalização seria possível - pode ser útil em outro momento!
— precisa
Uma pergunta relacionada ao log: o iptables lida com vários pacotes simultaneamente (para que as entradas do log possam ser intercaladas)? Nesse caso, acho que a idéia do TOS seria uma necessidade absoluta para muitas análises LOG do iptables!
— precisa
Eu não sei a resposta para isso. Espero que cada interface seja tratada simultaneamente pelo iptables no mínimo.
— Haakon
82

Se você possui um kernel e uma versão recentes recentes do iptables, pode usar o alvo TRACE (parece estar embutido no mínimo no Debian 5.0). Você deve definir as condições do seu rastreio para serem o mais específicas possível e desabilitar quaisquer regras de TRACE quando não estiver depurando, pois elas enviam muitas informações aos logs.

TRACE
Este alvo marca os pacotes para que o kernel registre todas as regras que correspondem aos pacotes à medida que atravessam as tabelas, cadeias, regras. (O módulo ipt_LOG ou ip6t_LOG é necessário para o log.) Os pacotes são registrados com o prefixo da sequência: "TRACE: tablename: chainname: type: rulenum" onde o tipo pode ser "regra" para regra simples, "return" para regra implícita no final de uma cadeia definida pelo usuário e "política" para a política das cadeias incorporadas. Só pode ser usado na tabela bruta.

Se você adicionou regras como esta

iptables -t raw -A PREROUTING -p tcp --destination 192.168.0.0/24 --dport 80 -j TRACE
iptables -t raw -A OUTPUT -p tcp --destination 192.168.0.0/24 --dport 80 -j TRACE

Você receberá uma saída parecida com esta.

# cat /var/log/kern.log | grep 'TRACE:'
Mar 24 22:41:52 enterprise kernel: [885386.325658] TRACE: raw:PREROUTING:policy:2 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.12.152 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=80 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)
Mar 24 22:41:52 enterprise kernel: [885386.325689] TRACE: mangle:PREROUTING:policy:1 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.12.152 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=80 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)
Mar 24 22:41:52 enterprise kernel: [885386.325713] TRACE: nat:PREROUTING:rule:1 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.12.152 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=80 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)
Mar 24 22:41:52 enterprise kernel: [885386.325731] TRACE: nat:nat.1:rule:1 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.12.152 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=80 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)
Mar 24 22:41:52 enterprise kernel: [885386.325731] TRACE: mangle:INPUT:policy:1 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.32.10 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=3128 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)
Mar 24 22:41:52 enterprise kernel: [885386.325731] TRACE: filter:INPUT:rule:2 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.32.10 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=3128 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)
Mar 24 22:41:52 enterprise kernel: [885386.325731] TRACE: filter:in_world:rule:1 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.32.10 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=3128 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)
Mar 24 22:41:52 enterprise kernel: [885386.325731] TRACE: filter:in_world_all_c1:return:2 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.32.10 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=3128 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)
Mar 24 22:41:52 enterprise kernel: [885386.325731] TRACE: filter:in_world:rule:2 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.32.10 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=3128 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)
Mar 24 22:41:52 enterprise kernel: [885386.325731] TRACE: filter:in_world_irc_c2:return:2 IN=eth0 OUT= MAC=00:1d:7d:aa:e3:4e:00:04:4b:05:b4:dc:08:00 SRC=192.168.32.18 DST=192.168.32.10 LEN=52 TOS=0x00 PREC=0x00 TTL=128 ID=30561 DF PROTO=TCP SPT=53054 DPT=3128 SEQ=3653700382 ACK=0 WINDOW=8192 RES=0x00 SYN URGP=0 OPT (020405B40103030201010402)
— Zoredache
fonte
8
Obrigado, isso é incrível! Na verdade, é a melhor resposta, eu gostaria de poder aceitá-la (era uma pergunta de recompensa, portanto a resposta aceita é definitiva). Embora eu não possa usá-lo em todos os meus sistemas (devido a limitações do kernel), em alguns sistemas eu posso. Essa resposta merece votação, porque é muito próxima do que eu estava procurando.
— precisa
Encontrei esse recurso ontem à noite quando estava relendo a página de manual do iptables para poder responder a uma pergunta diferente. Parece ser um recurso relativamente novo. Não se preocupe em não poder marcá-lo como aceito. Talvez isso seja votado o suficiente ao longo do tempo para ganhar outro distintivo populista.
— Zoredache 25/03
Esta é realmente a resposta canônica para rastrear pacotes no iptables. É uma pena que alguns kernels recentes não o habilitem por padrão.
— Peter Grace
Há quanto tempo o kernel suporta o TRACE? Eu tenho usado com sucesso no CentOS 6.4, mas não no CentOS 6.2
— sebelk
6

Três respostas em um post:

1) Depurar por script:

#!/bin/bash
debug() {
    if [ -n "$debug" ]; then
        $@ || echo -e "The command which launched the error:\n$@"
    else
        $@
    fi
}
debug=1
IPTABLES="debug /sbin/iptables"

$IPTABLES -P INPUT DROP
$IPTABLES -P OUTPUT DROP
....

2) Depurar por syslog

A partir deste site: http://www.brandonhutchinson.com/iptables_fw.html

If you want to make a syslog entry of dropped packets, change:

# Drop all other traffic
/sbin/iptables -A INPUT -j DROP

To:

# Create a LOGDROP chain to log and drop packets
/sbin/iptables -N LOGDROP
/sbin/iptables -A LOGDROP -j LOG
/sbin/iptables -A LOGDROP -j DROP

# Drop all other traffic
/sbin/iptables -A INPUT -j LOGDROP


You may also want to configure the --log-level to log dropped packets to a separate file instead of /var/log/messages:

# Drop all other traffic
/sbin/iptables -A INPUT -j LOGDROP --log-level debug


/etc/syslog.conf change:

# Send iptables LOGDROPs to /var/log/iptables
kern.=debug                                             /var/log/iptables

Reload the syslogd service for the change to take effect.
/sbin/service syslog reload

3) Sem depuração, bom iptables edita:

Também isso pode ser útil: http://www.fwbuilder.org/

— Marc Riera
fonte
1
Obrigado. Os pontos 1) e 3) não têm muito a ver com os seguintes pacotes através das regras do iptables, mas o argumento sobre o redirecionamento de entradas de log com base em "--log-level" pode ser útil, se eu realmente precisar voltar ao registro (caso não exista outra solução).
— precisa
2

teve a mesma pergunta e encontrou Zoredache apontando para TRACE / ipt_LOG foi a solução!

Além disso, encontrei um script que insere / remove regras de LOG que precedem todas as regras de tabelas de ip ativas no momento. Eu tentei e achei uma ferramenta muito boa. - A saída é semelhante à solução TRACE - Vantagem: funciona na configuração ativa do iptables, independentemente de onde foi carregada. Você pode ativar / desativar o log on-line! Você não precisa modificar nenhum script de firewall que possa ter sido gerado pelo Firewall Builder ou pela ferramenta que você usar ... - Desvantagem: sem modificação, o script cria regras de LOG para TODAS as regras ativas. Em vez disso, ao usar regras TRACE, você provavelmente restringirá o log a endereços / serviços / conexões para os quais deseja investigar o processamento de tabelas de ip agora.

De qualquer forma, eu gosto da abordagem :) Parabéns a Tony Clayton, dê uma olhada: http://lists.netfilter.org/pipermail/netfilter/2003-March/043088.html

Atenciosamente, Chris

— chris
fonte
0

Eu costumo usar contadores de pacotes e bytes para ver como as regras funcionam e para encontrar o que está faltando ou errado.

Você pode visualizá-los por "iptables -nvL".

— Vi.
fonte
2
Eu posso ver o que o autor quer; se você estiver tentando testar suas regras do iptables em uma interface ocupada, apenas assistir os contadores não ajudará muito, principalmente se o pacote provavelmente corresponder a várias regras e pular cadeias definidas pelo usuário no processo (como é típico quando filtragem de endereços IP indesejados e regras de proteção contra inundações).
— PP.
@ PP: Exatamente, você está lendo minha mente. @ Vi: Obrigado, isso pode ser útil em algumas circunstâncias, e eu tenho usado isso às vezes. Agora eu preciso de algo mais poderoso.
— precisa
-2

AFAIK um pacote IP percorre a cadeia de regras até a primeira correspondência. Então, eu realmente não vejo qual é o problema aqui. Se você tem:

  1. regra 1
  2. regra 2
  3. regra 3 LOG

E um pacote entra no log, significa que a regra 3 é a primeira regra correspondente.

— Anônimo
fonte
Não é verdade. Pacotes podem corresponder a várias regras, e eles fazem. A menos que uma regra tenha uma ação (como -j DROPou -j ACCEPT), ela continuará a corresponder mais adiante na cadeia.
— PP.
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.