August 2020 - syslog-ng - lists.balabit.hu

UDP drops with syslog-ng 3.24.1-1
by brian hoffman 05 Oct '22

05 Oct '22

We've been centrally logging with syslog-ng for about 5 years now. Over that time, the number of sources has grown significantly, and at some point we crossed a line where drops were happening (a quick survey of 3 million syslog packets yielded 420 unique currently sending hosts). After much research and experimentation, we've been able to get to the point where throughout the day there are 0 drops for the most part. This was achieved by installing the latest syslog-ng (not the RedHat packaged one) and creating a source for each CPU. Occasionally, though, we still have periods of drops so I'm trying to eliminate these last few. Here are some relevant configuration items:2 RedHat 7.8 VMs (load balanced via an F5) with 16GB memory and 4 CPUs each running syslog-ng-3.24.1-1.el7.x86_64.net.core.rmem_default = 212992net.core.rmem_max = 268435456 log_fifo_size(268435456); source s_network {network(ip("0.0.0.0") port(514) transport("udp") so_rcvbuf(441326592) so-reuseport(1) persist-name("udp1"));network(ip("0.0.0.0") port(514) transport("udp") so_rcvbuf(441326592) so-reuseport(1) persist-name("udp2"));network(ip("0.0.0.0") port(514) transport("udp") so_rcvbuf(441326592) so-reuseport(1) persist-name("udp3"));network(ip("0.0.0.0") port(514) transport("udp") so_rcvbuf(441326592) so-reuseport(1) persist-name("udp4"));network(ip("0.0.0.0") port(514) transport("tcp") max_connections(200) keep_alive(yes) so_rcvbuf(67108864));}; We are limited to UDP, unfortunately, because we do not have control over the devices/networks/etc. that are sending to us, but we have changed as many of the internal senders and destinations to TCP as we can. With a script I created to view the packets, including drops, as well as the individual RECVQs, the issue can be illustrated. Here's what things look like normally:Thu May 7 10:48:15 EDT 2020, 27003 IP pkts rcvd,26980 IP pkts sent,24951 UDP pkts rcvd, 28075 UDP pkts sent,0 UDP pkt rcv err RECVQ-1=2176RECVQ-2=0RECVQ-3=0RECVQ-4=0Thu May 7 10:48:16 EDT 2020, 28453 IP pkts rcvd,28426 IP pkts sent,26185 UDP pkts rcvd, 29180 UDP pkts sent,0 UDP pkt rcv errRECVQ-1=0RECVQ-2=0RECVQ-3=4352RECVQ-4=0Thu May 7 10:48:17 EDT 2020, 28294 IP pkts rcvd,28276 IP pkts sent,26277 UDP pkts rcvd, 28709 UDP pkts sent,0 UDP pkt rcv errRECVQ-1=2176RECVQ-2=0RECVQ-3=0RECVQ-4=0 The RECVQs are sparsely used, and there are no errors. Around 9pm every night, the packet counts go up significantly (probably due to backup related logs):Wed May 6 21:00:08 EDT 2020, 66382 IP pkts rcvd,66366 IP pkts sent,39405 UDP pkts rcvd, 67592 UDP pkts sent,0 UDP pkt rcv errRECVQ-1=1595008RECVQ-2=106217088RECVQ-3=53694976RECVQ-4=31858816Wed May 6 21:00:09 EDT 2020, 69317 IP pkts rcvd,69338 IP pkts sent,44446 UDP pkts rcvd, 75958 UDP pkts sent,0 UDP pkt rcv errRECVQ-1=13056RECVQ-2=126397312RECVQ-3=75568128RECVQ-4=41626880Wed May 6 21:00:10 EDT 2020, 71205 IP pkts rcvd,71227 IP pkts sent,43657 UDP pkts rcvd, 74603 UDP pkts sent,0 UDP pkt rcv errRECVQ-1=920448RECVQ-2=146122752RECVQ-3=100951168RECVQ-4=52622208Wed May 6 21:00:12 EDT 2020, 69578 IP pkts rcvd,69454 IP pkts sent,124465 UDP pkts rcvd, 163367 UDP pkts sent,0 UDP pkt rcv errRECVQ-1=13140864RECVQ-2=44494848RECVQ-3=125579136RECVQ-4=0 Still, though, it's handling it with no errors. But then at some point a threshold is reached and errors start piling up:Wed May 6 21:00:20 EDT 2020, 63177 IP pkts rcvd,63291 IP pkts sent,0 UDP pkts rcvd, 0 UDP pkts sent,38011 UDP pkt rcv errRECVQ-1=536871424RECVQ-2=200357376RECVQ-3=292948352RECVQ-4=28890752Wed May 6 21:00:21 EDT 2020, 69501 IP pkts rcvd,69464 IP pkts sent,0 UDP pkts rcvd, 1 UDP pkts sent,42158 UDP pkt rcv errRECVQ-1=536871424RECVQ-2=223551360RECVQ-3=314995584RECVQ-4=41735680Wed May 6 21:00:23 EDT 2020, 69962 IP pkts rcvd,69978 IP pkts sent,0 UDP pkts rcvd, 2 UDP pkts sent,43775 UDP pkt rcv errRECVQ-1=536871424RECVQ-2=244732544RECVQ-3=338239616RECVQ-4=53858176Wed May 6 21:00:24 EDT 2020, 68266 IP pkts rcvd,68216 IP pkts sent,0 UDP pkts rcvd, 0 UDP pkts sent,43118 UDP pkt rcv errRECVQ-1=536871424RECVQ-2=265258752RECVQ-3=360643712RECVQ-4=65362688 The common denominator I've found is that one of the RECVQs hits 536,871,424. This number seems to be almost exactly double (512 difference) the rmem.max/log_fifo_size (268,435,456). Even though there seems to be capacity in the other RECVQs, just one of those hitting that magic number seems to be enough to throw things out of whack. During this time, the CPU usage for syslog-ng also drops: top - 21:00:11 up 2 days, 8:40, 2 users, load average: 1.09, 1.41, 1.32 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 7214 root 20 0 2111388 1.7g 5392 S 123.6 10.9 3080:46 syslog-ng top - 21:00:14 up 2 days, 8:40, 2 users, load average: 1.00, 1.39, 1.31 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 7214 root 20 0 2111388 1.7g 5392 S 24.6 10.9 3080:46 syslog-ng top - 21:00:17 up 2 days, 8:40, 2 users, load average: 1.00, 1.39, 1.31 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 7214 root 20 0 2111388 1.7g 5392 S 7.6 10.9 3080:47 syslog-ng As best I can tell, based on the reading I've done, the message counts we're getting should be doable, but it's still not clear exactly how to size some of these options as they relate to UDP (like log_fetch_limit, which we do not have set). Anything else I should try?

2 4

Re: [syslog-ng] syslog-ng is ignoring a network source
by Bruns, Benjamin 01 Sep '20

01 Sep '20

Hello Laci, Thanks a lot! It turned out that my second firewall does not come through to netcat on port 514, even if I turned off the firewall completely. It's all running a Security Onion host and now I'm wondering if the IDS/IPS is fooling me and is blocking the traffic (but I don't notice any alerts related to the IP of the second firewall ...). However, any other ideas? Mit freundlichen Grüßen / Best regards Benjamin Bruns IT Security Manager CYPP GmbH Gotenstrasse 15 20097 Hamburg Germany Telefon: +49 40 237 34-285 Mobil: +49 160 3230 655 Mail: benjamin.bruns(a)cypp.de<mailto:benjamin.bruns@cypp.de> www.cypp.de<http://www.cypp.de/> | www.plathgroup.com<http://www.plathgroup.com/> Sitz der Gesellschaft: Hamburg HRB 132781 Amtsgericht Hamburg Ust-ID DE 298033875 Vertretungsberechtigter Geschäftsführerin: Maya von Holdt Dies ist eine vertrauliche Nachricht und nur für den Adressaten bestimmt. Es ist nicht erlaubt, diese Nachricht zu kopieren oder Dritten zugänglich zu machen. Sollten Sie diese Nachricht irrtümlich erhalten haben, benachrichtigen Sie den Versender bitte per E-Mail oder telefonisch und löschen Sie die Nachricht unverzüglich. This message is strictly confidential and intended solely for the use of the addressee. It is not allowed to copy or disseminate this message. Please notify the sender by e-mail or telephone if you have received this message by mistake and delete this message immediately. Von: syslog-ng <syslog-ng-bounces(a)lists.balabit.hu> Im Auftrag von Laszlo Szemere (lszemere) Gesendet: Freitag, 28. August 2020 13:41 An: Syslog-ng users' and developers' mailing list <syslog-ng(a)lists.balabit.hu> Betreff: Re: [syslog-ng] syslog-ng is ignoring a network source Hello Ben, nc -u -l -p 514 -u : use UDP -l : listen in server mode, instead of sending -p : defines port number (If you need, you can also specify the local IP address to bind to with the -s option.) Br, Laci ________________________________ From: syslog-ng <syslog-ng-bounces(a)lists.balabit.hu<mailto:syslog-ng-bounces@lists.balabit.hu>> on behalf of Bruns, Benjamin <Benjamin.Bruns(a)cypp.de<mailto:Benjamin.Bruns@cypp.de>> Sent: Friday, August 28, 2020 13:29 To: Syslog-ng users' and developers' mailing list <syslog-ng(a)lists.balabit.hu<mailto:syslog-ng@lists.balabit.hu>> Subject: Re: [syslog-ng] syslog-ng is ignoring a network source CAUTION: This email originated from outside of the organization. Do not follow guidance, click links, or open attachments unless you recognize the sender and know the content is safe. Hello Laci, how do I check that by using netcat? Cheers, Ben Von: syslog-ng <syslog-ng-bounces(a)lists.balabit.hu<mailto:syslog-ng-bounces@lists.balabit.hu>> Im Auftrag von Laszlo Szemere (lszemere) Gesendet: Freitag, 28. August 2020 12:21 An: Syslog-ng users' and developers' mailing list <syslog-ng(a)lists.balabit.hu<mailto:syslog-ng@lists.balabit.hu>> Betreff: Re: [syslog-ng] syslog-ng is ignoring a network source Hello Ben, our experience shows that having logs in Wireshark doesn't necessary means that they reach the applications. (Wireshark captures packets on the interface level.) So as a first step I would recommend to clarify that the logs from the second host indeed reaches Syslog-ng. (For UDP logs netcat usually is enough.) Once it is clear that those logs reaches the application level, we can focus on debugging Syslog-ng. By starting Syslog-ng with the following options, it would be much easier to examine the flow of messages: syslog-ng -Fdevt -F : start it in the foreground -d : debug mode -e : log messages to stderr -v : increases verbository -t : also enable trace messages Note: With these options enabled, Syslog-ng will produce a LOT of messages. So if you can turn off other logging sources temporary, than it will be much more easier to read those logs. At this point you should start to receive this kind of debug messages, which will indicate that Syslog-ng received the log messages from your host: [2020-08-28T10:09:43.289660] Incoming log entry; line='hello world' >From this point the easiest way is to start with a minimal config, and build up your final configuration step by step. Checking incoming logs in each steps. Br, Laci ________________________________ From: syslog-ng <syslog-ng-bounces(a)lists.balabit.hu<mailto:syslog-ng-bounces@lists.balabit.hu>> on behalf of Bruns, Benjamin <Benjamin.Bruns(a)cypp.de<mailto:Benjamin.Bruns@cypp.de>> Sent: Friday, August 28, 2020 11:53 To: syslog-ng(a)lists.balabit.hu<mailto:syslog-ng@lists.balabit.hu> <syslog-ng(a)lists.balabit.hu<mailto:syslog-ng@lists.balabit.hu>> Subject: [syslog-ng] syslog-ng is ignoring a network source CAUTION: This email originated from outside of the organization. Do not follow guidance, click links, or open attachments unless you recognize the sender and know the content is safe. Hello! I try to send syslogs from two firewalls to my syslog-ng host. The first one worked immediately, but logs of the second firewall seems to be ignored. Both syslogs come in via UDP on port 514 and I can see them in Wireshark on my syslog-ng host, but they disappear for my second firewall in a black hole. Both have Logstash as their destination configured. Any ideas? Thanks in advance! Cheers, Ben

2 3

Re: [syslog-ng] syslog-ng is ignoring a network source
by Bruns, Benjamin 01 Sep '20

01 Sep '20

Hello Laci, Question: I can successfully read the logs of the firewall that is located in the same network that my logserver is, but the second firewall is sending the logs from a different network segment to the log server. Does this causes the problem? Again: I can see the traffic on my network interface, but netcat doesn't receive anything on port 514 (for the second firewall). Does iptables fools me somehow? Mit freundlichen Grüßen / Best regards Benjamin Bruns IT Security Manager CYPP GmbH Gotenstrasse 15 20097 Hamburg Germany Telefon: +49 40 237 34-285 Mobil: +49 160 3230 655 Mail: benjamin.bruns(a)cypp.de<mailto:benjamin.bruns@cypp.de> www.cypp.de<http://www.cypp.de/> | www.plathgroup.com<http://www.plathgroup.com/> Sitz der Gesellschaft: Hamburg HRB 132781 Amtsgericht Hamburg Ust-ID DE 298033875 Vertretungsberechtigter Geschäftsführerin: Maya von Holdt Dies ist eine vertrauliche Nachricht und nur für den Adressaten bestimmt. Es ist nicht erlaubt, diese Nachricht zu kopieren oder Dritten zugänglich zu machen. Sollten Sie diese Nachricht irrtümlich erhalten haben, benachrichtigen Sie den Versender bitte per E-Mail oder telefonisch und löschen Sie die Nachricht unverzüglich. This message is strictly confidential and intended solely for the use of the addressee. It is not allowed to copy or disseminate this message. Please notify the sender by e-mail or telephone if you have received this message by mistake and delete this message immediately. Von: syslog-ng <syslog-ng-bounces(a)lists.balabit.hu> Im Auftrag von Laszlo Szemere (lszemere) Gesendet: Freitag, 28. August 2020 13:41 An: Syslog-ng users' and developers' mailing list <syslog-ng(a)lists.balabit.hu> Betreff: Re: [syslog-ng] syslog-ng is ignoring a network source Hello Ben, nc -u -l -p 514 -u : use UDP -l : listen in server mode, instead of sending -p : defines port number (If you need, you can also specify the local IP address to bind to with the -s option.) Br, Laci ________________________________ From: syslog-ng <syslog-ng-bounces(a)lists.balabit.hu<mailto:syslog-ng-bounces@lists.balabit.hu>> on behalf of Bruns, Benjamin <Benjamin.Bruns(a)cypp.de<mailto:Benjamin.Bruns@cypp.de>> Sent: Friday, August 28, 2020 13:29 To: Syslog-ng users' and developers' mailing list <syslog-ng(a)lists.balabit.hu<mailto:syslog-ng@lists.balabit.hu>> Subject: Re: [syslog-ng] syslog-ng is ignoring a network source CAUTION: This email originated from outside of the organization. Do not follow guidance, click links, or open attachments unless you recognize the sender and know the content is safe. Hello Laci, how do I check that by using netcat? Cheers, Ben Von: syslog-ng <syslog-ng-bounces(a)lists.balabit.hu<mailto:syslog-ng-bounces@lists.balabit.hu>> Im Auftrag von Laszlo Szemere (lszemere) Gesendet: Freitag, 28. August 2020 12:21 An: Syslog-ng users' and developers' mailing list <syslog-ng(a)lists.balabit.hu<mailto:syslog-ng@lists.balabit.hu>> Betreff: Re: [syslog-ng] syslog-ng is ignoring a network source Hello Ben, our experience shows that having logs in Wireshark doesn't necessary means that they reach the applications. (Wireshark captures packets on the interface level.) So as a first step I would recommend to clarify that the logs from the second host indeed reaches Syslog-ng. (For UDP logs netcat usually is enough.) Once it is clear that those logs reaches the application level, we can focus on debugging Syslog-ng. By starting Syslog-ng with the following options, it would be much easier to examine the flow of messages: syslog-ng -Fdevt -F : start it in the foreground -d : debug mode -e : log messages to stderr -v : increases verbository -t : also enable trace messages Note: With these options enabled, Syslog-ng will produce a LOT of messages. So if you can turn off other logging sources temporary, than it will be much more easier to read those logs. At this point you should start to receive this kind of debug messages, which will indicate that Syslog-ng received the log messages from your host: [2020-08-28T10:09:43.289660] Incoming log entry; line='hello world' >From this point the easiest way is to start with a minimal config, and build up your final configuration step by step. Checking incoming logs in each steps. Br, Laci ________________________________ From: syslog-ng <syslog-ng-bounces(a)lists.balabit.hu<mailto:syslog-ng-bounces@lists.balabit.hu>> on behalf of Bruns, Benjamin <Benjamin.Bruns(a)cypp.de<mailto:Benjamin.Bruns@cypp.de>> Sent: Friday, August 28, 2020 11:53 To: syslog-ng(a)lists.balabit.hu<mailto:syslog-ng@lists.balabit.hu> <syslog-ng(a)lists.balabit.hu<mailto:syslog-ng@lists.balabit.hu>> Subject: [syslog-ng] syslog-ng is ignoring a network source CAUTION: This email originated from outside of the organization. Do not follow guidance, click links, or open attachments unless you recognize the sender and know the content is safe. Hello! I try to send syslogs from two firewalls to my syslog-ng host. The first one worked immediately, but logs of the second firewall seems to be ignored. Both syslogs come in via UDP on port 514 and I can see them in Wireshark on my syslog-ng host, but they disappear for my second firewall in a black hole. Both have Logstash as their destination configured. Any ideas? Thanks in advance! Cheers, Ben

2 1

message being consistently dropped
by Wilson, Jonathan 01 Sep '20

01 Sep '20

We are running syslog-ng, open source edition, version 3.22.1, on RedHat Enterprise version 7.8. Among many other data sources, we receive syslog data from an F5 device that acts as a VPN server. One type of message that it sends us is consistently not making it into the log (though everything else, to my knowledge, does.) I wonder if anyone sees something wrong with the message that would prevent its being parsed/stored. The message (reconstructed from a packet capture, identification fields redacted or changed): <141>1 2020-08-04T08:10:58.769127-05:00 <fqdn here> apmd 12374 01490113:5: [F5@12276 hostname="fqdn" errdefs_msgno="01490113:5:" partition_name="Common" session_id="1c95e1e7" Access_Profile="/Common/blah" Partition="Common" Session_Id="1c95e1e6" Session_Variable_Name="session.machine_info.last.net_adapter.list.[0].mac_address" Session_Variable_Value="3C:D9:2B:33:9A:8E"] /Common/<blah>:Common:1c95e1e6: session.machine_info.last.net_adapter.list.[0].mac_address is 3C:D9:2B:33:9A:8E I inserted the line breaks to help Outlook. Note that although the message appears to be RFC5424-compliant I have discovered that it does not have whatever magic headers let syslog-ng handle it as structured data transparently. As a result, I cannot use the "syslog" transport but have to use the generic "network" transport and then use flags "syslog-protocol". This works OK for everything else from this source. The message doesn't appear in our syslog logs at all. It's consistent. The relevant parts of the syslog-ng configuration look like: options { ts_format(iso); use_dns(yes); dns_cache(1000); dns_cache_expire(30); use_fqdn(yes); keep_hostname(no); chain-hostnames(no); keep_timestamp(yes); stats_level(1); stats_freq(3600); normalize_hostnames(yes); log_fifo_size(10000); flush_lines(1000); log-msg-size(65536); trim-large-messages(yes); threaded(yes); time_reap(10); create_dirs(yes); dir_group(esmapp); dir_owner(esmapp); group(esmapp); owner(esmapp); perm(0644); }; source s_F5VPN_source { network( transport("tcp") ip(0.0.0.0) port(11000) keep-timestamp(yes) flags(no-multi-line,syslog-protocol) max-connections(50) log_iw_size(10000) log-fetch-limit(20) ); }; filter f_F5VPN_client { netmask(<blah>) and facility(local1); }; destination d_F5VPN_client { file( "/home/syslog/F5VPN_client.log" ts_format(rfc3164) ); }; log { source(s_F5VPN_source); filter(f_F5VPN_client); destination(d_F5VPN_client); flags(flow-control); }; Regards, Jon Jon Wilson | Principal System Engineer, IT Service Management | Information Technology | Vanderbilt University Medical Center jonathan.wilson(a)vumc.org<mailto:jonathan.wilson@vumc.org> | phone: 615-440-7895 | fax: 615-323-2181

2 1

No remote logging with hostname which has address is IPv6
by Alexandre Santos 28 Aug '20

28 Aug '20

Hi, I have configuration, which is sending log messages to a remote hostname (dns6server). The particularity of this remote server is that it is resolved to an IPv6 address. ping works fine: root@localhost:~# ping dns6server -c 3 PING dns6server(2620:38:4::8:4000:238) 56 data bytes 64 bytes from 2620:38:4::8:4000:238: icmp_seq=1 ttl=63 time=0.354 ms 64 bytes from 2620:38:4::8:4000:238: icmp_seq=2 ttl=63 time=0.264 ms 64 bytes from 2620:38:4::8:4000:238: icmp_seq=3 ttl=63 time=0.310 ms But syslog-ng seems not to be able to resolve the ipv6 address: Aug 27 20:58:37 localhost systemd[1]: mgmt-syslog-ng.service: Succeeded. Aug 27 20:58:37 localhost systemd[1]: Stopped External Logger Daemon. Aug 27 20:58:37 localhost systemd[1]: Starting External Logger Daemon... Aug 27 20:58:37 localhost ip[32709]: [2020-08-27T20:58:37.841389] WARNING: With use-dns(no), dns-cache() will be forced to 'no' too!; Aug 27 20:58:46 localhost ip[32709]: [2020-08-27T20:58:46.854714] Error resolving hostname; host='dns6server' Aug 27 20:58:46 localhost ip[32709]: [2020-08-27T20:58:46.854758] Initiating connection failed, reconnecting; time_reopen='60' Aug 27 20:58:46 localhost systemd[1]: Started External Logger Daemon. Any Ideas? I am sending the configuration and debug log in attachment. Thanks in Advance, Alex

2 5

syslog-ng 3.29 Debian/Ubuntu packages (OBS)
by Laszlo Budai 28 Aug '20

28 Aug '20

Hi, syslog-ng 3.29.1[1] packages are available from OBS repositories[2, 3, 4]. List of supported OSs: * Debian 8.0 * Debian 9.0 * Debian 10.0 * Raspbian 9.0 * Raspbian 10.0 * Ubuntu 14.04 * Ubuntu 16.04 * Ubuntu 18.04 * Ubuntu 18.10 * Ubuntu 19.04 * Ubuntu 19.10 * Ubuntu 20.04 Install ------- example: Debian 9.0 1. get release key wget -qO - http://download.opensuse.org/repositories/home:/laszlo_budai:/syslog-ng/Deb… | sudo apt-key add - 2. add repo to APT sources eg.: /etc/apt/sources.list.d/syslog-ng-obs.list deb http://download.opensuse.org/repositories/home:/laszlo_budai:/syslog-ng/Deb… ./ Then `apt-get update` and `apt-geat install syslog-ng-core` Links -------- [1] https://github.com/balabit/syslog-ng/releases/tag/syslog-ng-3.29.1 [2] https://build.opensuse.org/package/show/home:laszlo_budai:syslog-ng/syslog-… [3] https://build.opensuse.org/package/show/home:laszlo_budai:syslog-ng/syslog-… [4] https://build.opensuse.org/package/show/home:laszlo_budai:syslog-ng/syslog-… regards, Laszlo Budai

1 0

syslog-ng-3.29.1
by Laszlo Budai 28 Aug '20

28 Aug '20

3.29.1 Highlights * panos-parser(): parse Palo Alto PAN-OS logs Example: @include "scl.conf" log { source { network(transport("udp")); }; parser { panos-parser(); }; destination { elasticsearch-http( index("syslog-ng-${YEAR}-${MONTH}-${DAY}") type("") url("http://localhost:9200/_bulk") template("$(format-json --scope rfc5424 --scope dot-nv-pairs --rekey .* --shift 1 --exclude *future_* --exclude *dg_hier_level_* --scope nv-pairs --exclude DATE --key ISODATE @timestamp=${ISODATE})") ); }; }; (#3234<https://github.com/syslog-ng/syslog-ng/pull/3234>) Features * snmptrap: improve error message when missing dependency (#3363<https://github.com/syslog-ng/syslog-ng/pull/3363>) * disk queue: reduce memory usage during load (#3352<https://github.com/syslog-ng/syslog-ng/pull/3352>) * Allow dupnames flag to be used in PCRE expressions, allowing duplicate names for named subpatterns as explained here: https://www.pcre.org/original/doc/html/pcrepattern.html#SEC16 . Example: filter f_filter1 { match("(?<FOOBAR>bar)|(?<FOOBAR>foo)" value(MSG) flags(store-matches, dupnames)); }; (#3381<https://github.com/syslog-ng/syslog-ng/pull/3381>) Bugfixes * filter/regex: if there was a named match (?..)? that is optional to match, the previose or the next named matches might not be saved as named match. (#3393<https://github.com/syslog-ng/syslog-ng/pull/3393>) * tls: Fixed a bug, where ecdh-curve-list() were not applied at client side. (#3356<https://github.com/syslog-ng/syslog-ng/pull/3356>) * scratch-buffers: fix global.scratch_buffers_bytes.queued counter bug This bug only affected the stats_counter value, not the actual memory usage (i.e. memory usage was fine before) (#3355<https://github.com/syslog-ng/syslog-ng/pull/3355>) * wsl: fix infinite loop during startup (#3340<https://github.com/syslog-ng/syslog-ng/pull/3340>) * openbsd: showing grammar debug info for openbsd too, when -y command line option is used (#3339<https://github.com/syslog-ng/syslog-ng/pull/3339>) * stats-query: speedup syslog-ng-ctl query get "*" command. An algorithmic error view made syslog-ng-ctl query get "*" very slow with large number of counters. (#3376<https://github.com/syslog-ng/syslog-ng/pull/3376>) * syslogformat: fixing crashing with small invalid formatted logs see example in #3328<https://github.com/syslog-ng/syslog-ng/issues/3328> (#3364<https://github.com/syslog-ng/syslog-ng/pull/3364>) * cfg: fix config reload crash via introducing on_config_inited in LogPipe (#3176<https://github.com/syslog-ng/syslog-ng/pull/3176>) * config: fix error reporting * Error reporting was fixed for lines longer than 1024 characters. * The location of the error was incorrectly reported in some cases. (#3383<https://github.com/syslog-ng/syslog-ng/pull/3383>) * disk queue: fix possible crash during load, and possible false positive corruption detection (#3342<https://github.com/syslog-ng/syslog-ng/pull/3342>) * db-parser, pdbtool, graphite-output: fix glib assertion error The assertion happened in these cases * dbparser database load * argument parsing in graphite-output * pdbtool merge commad Syslog-ng emitted a glib assertion warning in the cases above, even in successful executions. If G_DEBUG=fatal-warnings environment variable was used, the warning turned into a crash. (#3344<https://github.com/syslog-ng/syslog-ng/pull/3344>) * stats: fix stats-ctl query crash when trying to reset all the counters syslog-ng-ctl query get '*' --reset (#3361<https://github.com/syslog-ng/syslog-ng/pull/3361>) Packaging * RHEL 7 packaging: fix logrotate file conflict with rsyslog (#3324<https://github.com/syslog-ng/syslog-ng/pull/3324>) * Debian packaging: python3-nose was removed from package dependencies. Pytest will run Python related unittests (for modules/python/pylib/syslogng/debuggercli/tests/) instead of nose. (#3343<https://github.com/syslog-ng/syslog-ng/pull/3343>) Notes to developers * light: test for assertion errors in glib for each testcases (#3344<https://github.com/syslog-ng/syslog-ng/pull/3344>) * Fix signal handling when an external library/plugin sets SIG_IGN Previously, setting SIG_IGN in a plugin/library (for example, in a Python module) resulted in a crash. (#3338<https://github.com/syslog-ng/syslog-ng/pull/3338>) * func-test: removed logstore_reader check, which was never reached (#3236<https://github.com/syslog-ng/syslog-ng/pull/3236>) * plugin_skeleton_creator: fixing a compiler switch Wrong compiler switch used in plugin_skeleton_creator. This caused a compiler warning. The grammar debug info did not appear for that module, when -y command line option was used. (#3339<https://github.com/syslog-ng/syslog-ng/pull/3339>) * Light test framework: get_stats and get_query functions to DestinationDriver class Two new functions added to DestinationDriver class which can be used for getting the stats and query output of syslog-ng-ctl. (#3211<https://github.com/syslog-ng/syslog-ng/pull/3211>) Other changes * internal(): limit the size of internal()'s temporary queue The internal() source uses a temporary queue to buffer messages. >From now on, the queue has a maximum capacity, the log-fifo-size() option can be used to change the default limit (10000). This change prevents consuming all the available memory in special rare cases. (#3229<https://github.com/syslog-ng/syslog-ng/pull/3229>) * network plugins: better timer defaults for TCP keepalive >From now on, syslog-ng uses the following defaults for TCP keepalive: * tcp-keepalive-time(): 60 * tcp-keepalive-intvl(): 10 * tcp-keepalive-probes(): 6 Note: so-keepalive() is enabled by default. (#3357<https://github.com/syslog-ng/syslog-ng/pull/3357>) Credits syslog-ng is developed as a community project, and as such it relies on volunteers, to do the work necessarily to produce syslog-ng. Reporting bugs, testing changes, writing code or simply providing feedback are all important contributions, so please if you are a user of syslog-ng, contribute. We would like to thank the following people for their contribution: Andras Mitzki, Antal Nemes, Attila Szakacs, Balazs Scheidler, Christian Tramnitz, chunmeng, Gabor Nagy, Laszlo Budai, Laszlo Szemere, László Várady, MileK, Norbert Takacs, Peter Czanik, Péter Kókai, Terez Nemes.

1 0

Re: [syslog-ng] syslog-ng is ignoring a network source
by Bruns, Benjamin 28 Aug '20

28 Aug '20

Hello Laci, how do I check that by using netcat? Cheers, Ben Von: syslog-ng <syslog-ng-bounces(a)lists.balabit.hu> Im Auftrag von Laszlo Szemere (lszemere) Gesendet: Freitag, 28. August 2020 12:21 An: Syslog-ng users' and developers' mailing list <syslog-ng(a)lists.balabit.hu> Betreff: Re: [syslog-ng] syslog-ng is ignoring a network source Hello Ben, our experience shows that having logs in Wireshark doesn't necessary means that they reach the applications. (Wireshark captures packets on the interface level.) So as a first step I would recommend to clarify that the logs from the second host indeed reaches Syslog-ng. (For UDP logs netcat usually is enough.) Once it is clear that those logs reaches the application level, we can focus on debugging Syslog-ng. By starting Syslog-ng with the following options, it would be much easier to examine the flow of messages: syslog-ng -Fdevt -F : start it in the foreground -d : debug mode -e : log messages to stderr -v : increases verbository -t : also enable trace messages Note: With these options enabled, Syslog-ng will produce a LOT of messages. So if you can turn off other logging sources temporary, than it will be much more easier to read those logs. At this point you should start to receive this kind of debug messages, which will indicate that Syslog-ng received the log messages from your host: [2020-08-28T10:09:43.289660] Incoming log entry; line='hello world' >From this point the easiest way is to start with a minimal config, and build up your final configuration step by step. Checking incoming logs in each steps. Br, Laci ________________________________ From: syslog-ng <syslog-ng-bounces(a)lists.balabit.hu<mailto:syslog-ng-bounces@lists.balabit.hu>> on behalf of Bruns, Benjamin <Benjamin.Bruns(a)cypp.de<mailto:Benjamin.Bruns@cypp.de>> Sent: Friday, August 28, 2020 11:53 To: syslog-ng(a)lists.balabit.hu<mailto:syslog-ng@lists.balabit.hu> <syslog-ng(a)lists.balabit.hu<mailto:syslog-ng@lists.balabit.hu>> Subject: [syslog-ng] syslog-ng is ignoring a network source CAUTION: This email originated from outside of the organization. Do not follow guidance, click links, or open attachments unless you recognize the sender and know the content is safe. Hello! I try to send syslogs from two firewalls to my syslog-ng host. The first one worked immediately, but logs of the second firewall seems to be ignored. Both syslogs come in via UDP on port 514 and I can see them in Wireshark on my syslog-ng host, but they disappear for my second firewall in a black hole. Both have Logstash as their destination configured. Any ideas? Thanks in advance! Cheers, Ben

2 1

syslog-ng is ignoring a network source
by Bruns, Benjamin 28 Aug '20

28 Aug '20

Hello! I try to send syslogs from two firewalls to my syslog-ng host. The first one worked immediately, but logs of the second firewall seems to be ignored. Both syslogs come in via UDP on port 514 and I can see them in Wireshark on my syslog-ng host, but they disappear for my second firewall in a black hole. Both have Logstash as their destination configured. Any ideas? Thanks in advance! Cheers, Ben

2 1

Message Macros
by Faine, Mark R. (MSFC-IS40)[NICS] 27 Aug '20

27 Aug '20

Is it possible to break up the $MESSAGE macro into smaller macros that constitute the entire message? The reason I ask is that we tried this format in our destination: template("${S_ISODATE} ${MESSAGE}\n") However, we get two dates now, since I'm assuming one is part of the $MESSAGE macro, and we also lost the $HOST in our messages. We just want the output to be exactly like it would be without specifying a template but with an ISO date, followed by the hostname/ip, and the rest of the message excluding the date. Thanks, -Mark

3 3