<div dir="ltr"><div>Hi,</div><div><br></div><div>the syslog-ng() destination should use a special format which transfers all name-value pairs to the server side automatically. On the server side this should be handled specially in which case no sudo parser should run.</div><div><br></div><div>This is how this is implemented in the server side:</div><div><br></div><div>Traditional syslog:<br></div><div>``` <br></div><div> channel {<br> source {<br> network(transport(tcp)<br> port(`tcp-port`)<br> max-connections(`max-connections`)<br> log-msg-size(`log-msg-size`)<br> flags(no-parse, `flags`)<br> hook-commands(`hook-commands`));<br> network(transport(udp)<br> port(`udp-port`)<br> log-msg-size(`log-msg-size`)<br> flags(no-parse, `flags`));<br> };<br> if {<br> parser { app-parser(topic(syslog-raw) `__VARARGS__`); };<br> } else {<br> parser { syslog-parser(flags(syslog-protocol)); };<br> if {<br> parser { ewmm-parser(); };<br> }<br> elif {<br> parser { app-parser(topic(syslog) `__VARARGS__`); };<br> }<br> else {};<br> };<br> };<br></div><div>```</div><div><br></div><div>on port 514, we check if the message is matched by the any parsers registered on the syslog-raw topic. The sudo parser is not registered here, rather it is registered to "syslog":</div><div><br></div><div>```</div><div>application sudo[syslog] {<br> filter { program("sudo" type(string)); };<br> parser { sudo-parser(); };<br>};</div><div>```</div><div><br></div><div>In the else branch, we process the incoming stream with the syslog-parser(). ewmm is encapsulated into the syslog format, so it should be successful here. Once that finishes we apply ewmm-parser() which should again succeed, causing the elif branch not to run.<br></div><div><br></div><div><br></div><div>Checking it in practice. I have this config on the client side:</div><div>```<br></div><div>@version: 3.28<br><br>@include "scl.conf"<br><br>log {<br> source { system(); };<br> destination { syslog-ng(server("127.0.0.1") port(2000)); };<br>};<br>```</div><div><br></div><div>I invoked sudo, which triggered this message to be sent to the server: <br></div>$ nc -l -p 2000<br><div><85>1 2020-08-06T12:41:08.000+00:00 bzorp @syslog-ng - - [meta sequenceId="1"] {"PROGRAM":"sudo","PID":"243","MESSAGE":" bazsi : TTY=console ; PWD=/install ; USER=root ; COMMAND=/bin/ls","HOST_FROM":"bzorp","HOST":"bzorp",".unix":{"uid":"0","pid":"243","gid":"1000","cmdline":"sudo ls "},".sudo":{"USER":"root","TTY":"console","SUBJECT":"bazsi","PWD":"/install","COMMAND":"/bin/ls"},".app":{"name":"sudo"},"._TAGS":".app.sudo,.source.#anon-source0"}<br></div><div><br></div><div>Please note the ".sudo" key value pairs above.<br></div><div><br></div><div>I am then sending this to a default-network-drivers() source:</div><div><br></div><div>config:</div><div>```</div><div>@version: 3.28<br><br>@include "scl.conf"<br><br>log {<br> source { default-network-drivers(tcp-port(2514) udp-port(2514) rfc5424-tls-port(6514) rfc5424-tcp-port(2601)); };<br> destination { file("/install/foobar.log" template("$(format-json --leave-initial-dot --scope all-nv-pairs)\n")); };<br>};</div><div>```<br></div><div><br></div><div>output in foobar.log:</div>{"SOURCE":"#anon-source0","PROGRAM":"sudo","PID":"243","MESSAGE":" bazsi : TTY=console ; PWD=/install ; USER=root ; COMMAND=/bin/ls","HOST_FROM":"bzorp","HOST":"bzorp",".unix":{"uid":"0","pid":"243","gid":"1000","cmdline":"sudo ls "},".sudo":{"USER":"root","TTY":"console","SUBJECT":"bazsi","PWD":"/install","COMMAND":"/bin/ls"},".app":{"name":"sudo"},".SDATA":{"meta":{"sequenceId":"1"}}}<div><br></div><div>As you can see the ".sudo" top-level key is there, listing sudo related name-value pairs as extracted on the client. I also checked the debug/trace logs on the server and confirmed that only ewmm parsing was done, <br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 6, 2020 at 11:55 AM Fabien Wernli <<a href="mailto:wernli@in2p3.fr">wernli@in2p3.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
I'm investigating using the EWMM forwarding model.<br>
Consider the following setup: Linux hosts collect logs using `system()`<br>
send them over using `syslog-ng()` destination to a remote host that<br>
collects them using `default-network-drivers()` source.<br>
<br>
It seems to me that the sudo app parsing is fired up twice:<br>
<br>
1. On the sender side because `system()` expands to something including the<br>
`sudo-parser()` SCL<br>
2. On the receiver side because `default-network-drivers()` expands to<br>
something involving the `app-parser()`<br>
<br>
This happens also when using `syslog()` source on the sender side, which is<br>
why I noticed this behaviour.<br>
<br>
So my question is, is there something wrong with that model ?<br>
<br>
______________________________________________________________________________<br>
Member info: <a href="https://lists.balabit.hu/mailman/listinfo/syslog-ng" rel="noreferrer" target="_blank">https://lists.balabit.hu/mailman/listinfo/syslog-ng</a><br>
Documentation: <a href="http://www.balabit.com/support/documentation/?product=syslog-ng" rel="noreferrer" target="_blank">http://www.balabit.com/support/documentation/?product=syslog-ng</a><br>
FAQ: <a href="http://www.balabit.com/wiki/syslog-ng-faq" rel="noreferrer" target="_blank">http://www.balabit.com/wiki/syslog-ng-faq</a><br>
<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature">Bazsi</div>