Esta é uma questão simples de resolver e extremamente útil. Dependendo do tipo de informação registrada, a leitura pode ficar desagradável quando a informação de diferentes processos se mistura. Na maioria das vezes, são os logs de firewall que complicam a leitura dos demais serviços (risos). Alguns administradores desconhecem, mas é possível resolver esta questão com o próprio rsyslogd.

É evidente que devemos personalizar a saída de log ou identificar o formato utilizado nestes registros. Particularmente, não costumo logar todos os pacotes que atravessam o firewall. Quando há interesse, permito logar as conexões que desejo bloquear ou qualquer conexão bloqueada por falta de regra (que chamo de Indirect DROP).

Confiram um exemplo:

$iptables -A INPUT -m conntrack --ctstate NEW -m pkttype ! --pkt-type broadcast -j LOG --log-level info --log-prefix "Indirect DROP (in):"

$iptables -A FORWARD -m conntrack --ctstate NEW -m pkttype ! --pkt-type broadcast -j LOG --log-level info --log-prefix "Indirect DROP (out):"

São as últimas regras lidas (tanto na cadeia INPUT quanto na FORWARD), antes da decisão padrão. Por esta razão considero um “bloqueio indireto” (firewall default DROP) – não é um bloqueio explícito administrativamente. Percebam que não incluo pacotes de broadcast para não inundar desnecessariamente os registros de log.

Por exemplo:

[24786839.927273] Indirect DROP (in):IN=eth0 OUT= MAC=00:1a:64:64:c2:7a:00:20:9c:6b:91:43:08:00 SRC=10.0.0.30 DST=10.x.y.19 LEN=73 TOS=0x00 PREC=0x00 TTL=61 ID=1330 DF PROTO=UDP SPT=32795 DPT=161 LEN=53
[24786849.952927] Indirect DROP (in):IN=eth1 OUT= MAC=00:1a:64:64:c2:78:78:48:59:32:c1:ca:08:00 SRC=104.x.y.169 DST=200.x.y.250 LEN=40 TOS=0x10 PREC=0x00 TTL=242 ID=54321 PROTO=TCP SPT=60441 DPT=2362 WINDOW=65535 RES=0x00 SYN URGP=0
[24786851.652503] Indirect DROP (in):IN=eth1 OUT= MAC=00:1a:64:64:c2:78:78:48:59:32:c1:ca:08:00 SRC=77.x.y.193 DST=200.x.y.250 LEN=40 TOS=0x10 PREC=0x00 TTL=238 ID=9555 PROTO=TCP SPT=48344 DPT=14000 WINDOW=1024 RES=0x00 SYN URGP=0

Duas configurações no rsyslog são suficientes para redirecionar estes eventos para outro arquivo.

Para isto, começaremos criando um arquivo em /etc/rsyslog.d/10-firewall.conf, informando qual mensagem será redirecionada e para onde:

if $programname == 'kernel' and ($msg contains 'Indirect DROP' or $msg contains 'DROP profile ') then /var/log/firewall/access.log
& ~

Fiquem atentos porque são realmente duas linhas:

1. Como o log do netfilter é gerado por um evento de kernel, filtramos “programname” como “kernel” e incluímos a instrução “que contenha Indirect DROP” na mensagem ($msg). Em “then” basta informar o arquivo de destino.

2. A segunda instrução é utilizada para tornar este evento único – sem duplicar em outros arquivos (algo que aconteceria por padrão).

Por fim, basta reiniciar o serviço:

service rsyslog restart

Muito simples e útil.
Espero que gostem!