Isso é um pouco relacionado à minha pergunta anterior aqui .
Eu tenho três arquivos em /etc/rsyslog.d , que estão incluídos em /etc/rsyslog.conf :
-
00-iptables.conf
-
50-default.conf
-
postfix.conf
O primeiro é um que eu criei. Minha suposição é / foi, que devido à nomenclatura ele será incluído antes de 50-default.conf , mas também tentei colocar as linhas de filtro diretamente em 50-default.conf e remover meu arquivo personalizado ( 00-iptables.conf ).
:msg, startswith, "ipt:" /var/log/iptables.log
& stop
Substituiu ~ com stop como em execução rsyslogd com -N1 conforme descrito na página do manual e nas etapas de solução de problemas forneceu um aviso, dizendo que ~ foi preterido em favor ou stop , o que significa a documentação disponível (oficial!) parece estar desatualizada / atrasada.
Agora, a ideia aqui é que qualquer mensagem prefixada com ipt: entrará no arquivo de log nomeado e nenhum outro arquivo de log receberá essas linhas (tentei também contains em vez de startswith ). Em particular, syslog e kern.log mencionados em 50-default.conf não devem mais receber essas mensagens:
auth,authpriv.* /var/log/auth.log
*.*;auth,authpriv.none -/var/log/syslog
kern.* -/var/log/kern.log
Eu li a documentação do rsyslog, mas a documentação para os filtros baseados em propriedade (também aqui ) não é exatamente o mais esclarecedor.
O exemplo dado na documentação (também encontrada em outro lugar) e o seu Wiki dá um exemplo similar :
# From documentation
*.* /var/log/allmsgs-including-informational.log
:msg, contains, "informational" ~
*.* /var/log/allmsgs-but-informational.log
# From Wiki
:syslogtag, startswith, "MSWinEventLog#011" /var/log/messages;fixsnareFormat
& @192.168.1.8;fixsnareForwardFormat
& ~
Embora o exemplo da documentação não seja tão próximo do meu verso, ele ainda explica o significado do ~ better.
O que estou fazendo de errado?
Pontos de bônus se alguém puder responder se existe uma maneira de combinar seletores e propriedades. Por exemplo:
:msg, startswith, "ipt:" kern.* /var/log/iptables.log
NB: eu uso a versão 7.4.4 de rsyslog . E sim, eu fiz service rsyslog restart após as alterações e depois esperei que isso tivesse efeito.
Editar
Mais algumas informações. Ao executar o daemon no modo de depuração ( RSYSLOG_DEBUG=LogFuncFlow RSYSLOG_DEBUGLOG=~/rsl.log $(which rsyslogd) -f /etc/rsyslog.conf -d ), posso ver que o conjunto de regras após a otimização se parece com isso, o que parece indicar que é exatamente do jeito que eu quero (prefixo removido por brevidade):
ruleset 'RSYSLOG_DefaultRuleset' after optimization:
ruleset 0x214a640: rsyslog ruleset RSYSLOG_DefaultRuleset:
PROPFILT
Property.: 'rawmsg'
Operation: 'contains'
Value....: 'ipt:'
THEN
ACTION 0x215c070 [builtin:omfile:/var/log/iptables.log]
STOP
END PROPFILT
PRIFILT 'auth,authpriv.*'
pmask: X X X X FF X X X X X FF X X X X X X X X X X X X X X
ACTION 0x215e840 [builtin:omfile:/var/log/auth.log]
END PRIFILT
PRIFILT '*.*;auth,authpriv.none'
pmask: FF FF FF FF X FF FF FF FF FF X FF FF FF FF FF FF FF FF FF FF FF FF FF FF
ACTION 0x215f030 [builtin:omfile:-/var/log/syslog]
END PRIFILT
Devo também acrescentar que, a partir do comportamento que vejo, posso deduzir que o filtro tem um efeito, já que ele grava claramente no arquivo /var/log/iptables.log como esperado. No entanto, as mensagens não são descartadas conforme o esperado depois de serem gravadas nesse arquivo específico.
Veja uma linha de exemplo do jeito que acaba em kern.log , syslog e iptables.log em oposição a apenas a última. Detalhes foram redigidos por motivos de privacidade:
Jun 1 02:23:01 hostname kernel: [70025.211497] ipt:drop IN=eth0 OUT=virbr0 MAC=dd:cc:bb:aa:99:88:77:66:55:44:33:22:11:00 SRC=9.8.7.6 DST=1.2.3.4 LEN=60 TOS=0x00 PREC=0x00 TTL=47 ID=59201 DF PROTO=TCP SPT=47626 DPT=23 WINDOW=4380 RES=0x00 SYN URGP=0