Re: Snort 3 output to linux journal is buffered?

["Neville, Andrew via Snort-devel" <snort-devel () lists snort org>]

Hi Adrian,

Thanks for the suggestions.  My service definition is just lifted from the install guide for CentOS 8 Stream guide on 
Snort.org  and I do have the daemon -D flag set already.

I gave unbuffer  a try and it does help, but your suggestion got me thinking and after some poking around I found the 
-M command line flag, which apparently makes Snort write directly to rsyslog/journald, and there is no buffering.

I see the -M option was available in for Snort 2 but it didn't seem to be required.

Anyhow, with -M set I'm not seeing any buffering  so I have what I need.

Thanks,

Andrew.

From: Snort-devel <snort-devel-bounces () lists snort org> On Behalf Of Adrian Mamolea (admamole) via Snort-devel
Sent: 08 November 2022 14:31
To: snort-devel () lists snort org
Subject: Re: [Snort-devel] Snort 3 output to linux journal is buffered?

Hello Andrew,

I wonder if using -D command line option helps. Could you share your Snort systemD service file? There is a tutorial 
that describes a setup similar to yours here:  
https://www.sunnyvalley.io/docs/linux-tutorials/how-to-install-and-configure-snort-on-ubuntu-linux<https://gbr01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.sunnyvalley.io%2Fdocs%2Flinux-tutorials%2Fhow-to-install-and-configure-snort-on-ubuntu-linux&data=05%7C01%7Candrew.neville%40fujitsu.co.uk%7Ca376862364e64f73a89808dac1d92424%7C7caf3ccea13e40708fdd9fb24a8c5294%7C0%7C0%7C638035435602255329%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=I01c51Lg70eIlX0lyBTD1lkDIXjAaAaw6WoPNvjGsac%3D&reserved=0>

If the issue persists, you can try running snort using unbuffer:
ExecStart=/usr/bin/unbuffer <your command line>

The man page for unbuffer: 
https://expect.sourceforge.net/example/unbuffer.man.html<https://gbr01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fexpect.sourceforge.net%2Fexample%2Funbuffer.man.html&data=05%7C01%7Candrew.neville%40fujitsu.co.uk%7Ca376862364e64f73a89808dac1d92424%7C7caf3ccea13e40708fdd9fb24a8c5294%7C0%7C0%7C638035435602255329%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ep16eqylK5Gxl9FKuID8MyL9a%2BySvZiTWySZAvkEJjw%3D&reserved=0>

Thanks,
Adrian


From: Snort-devel <snort-devel-bounces () lists snort org<mailto:snort-devel-bounces () lists snort org>> On Behalf Of 
Neville, Andrew via Snort-devel
Sent: Monday, November 7, 2022 10:09 AM
To: snort-devel () lists snort org<mailto:snort-devel () lists snort org>
Subject: [Snort-devel] Snort 3 output to linux journal is buffered?

Hi,

I'm looking for some help with a slightly odd behaviour we see when running Snort 3 as a systemd service.

When Snort3 is started from a simple systemd service definition it does not immediately show its normal full startup 
information into the journal. I'm expecting approximately 300 lines ending with "Commencing packet processing" and then 
the list of interfaces its monitoring, but I don't get all lines - only around 230 ish lines.

The only way to get the remaining output seems to be to make Snort write something else to the journal,   like send it 
a USR1 signal.

And actually,  in response to the USR1 signal again we see only some of the USR1 runtime information is written to the 
journal.  We have to send the USR1 signal twice in order to make sure we immediately get all the output from the first 
signal.

When running Snort in the foreground, all the expected output is displayed to the terminal immediately. Similarly, 
starting Snort3 at the command line, but putting it into the background, still allows all the startup and USR1 
information to display fully.

The most recent test I've tried is with Snort3 compiled on a basic CentOS 8 stream VM, following the guide from the 
snort.org, with a really vanilla configuration as far as I can tell (registered rules were loaded).

snort -V

   ,,_     -*> Snort++ <*-
  o"  )~   Version 3.1.43.0
   ''''    By Martin Roesch & The Snort Team
           
http://snort.org/contact#team<https://gbr01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsnort.org%2Fcontact%23team&data=05%7C01%7Candrew.neville%40fujitsu.co.uk%7Ca376862364e64f73a89808dac1d92424%7C7caf3ccea13e40708fdd9fb24a8c5294%7C0%7C0%7C638035435602255329%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=6hn6523uSslsqr57WFG4Nkw866q0aNx8OICmnOP2A4s%3D&reserved=0>
           Copyright (C) 2014-2022 Cisco and/or its affiliates. All rights reserved.
           Copyright (C) 1998-2013 Sourcefire, Inc., et al.
           Using DAQ version 3.0.9
           Using LuaJIT version 2.1.0-beta3
           Using OpenSSL 1.1.1k  FIPS 25 Mar 2021
           Using libpcap version 1.9.1 (with TPACKET_V3)
           Using PCRE version 8.42 2018-03-20
           Using ZLIB version 1.2.11
           Using Hyperscan version 5.3.0 2020-08-10
           Using LZMA version 5.2.4

As far as I know this behaviour is not as a result of  any journald configuration (I just have the default)  and we 
have seen the same behaviour with Alma and Ubuntu too.

Anyone have any pointers please??

Thanks,

Andrew.


Andrew Neville
Defence & National Security

Fujitsu
Jays Close, Viables Industrial Estate, Basingstoke, Hampshire, RG22 4BY
Email: andrew.neville () fujitsu co uk<mailto:andrew.neville () fujitsu co uk>

[cid:image001.jpg@01D8F5D4.3EEDE6C0]<https://gbr01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.fujitsu.com%2Fuk%2Fsolutions%2Findustry%2Fdefence-national-security%2F&data=05%7C01%7Candrew.neville%40fujitsu.co.uk%7Ca376862364e64f73a89808dac1d92424%7C7caf3ccea13e40708fdd9fb24a8c5294%7C0%7C0%7C638035435602255329%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=C4fV3%2BZ0NtLPAoEf8tnk6TCUXYTSBsIr2IgOKuBtX3g%3D&reserved=0>


Unless otherwise stated, this email has been sent from Fujitsu Services Limited (registered in England No 96056); 
Fujitsu EMEA PLC (registered in England No 2216100) both with registered offices at: 22 Baker Street, London W1U 3BW; 
PFU (EMEA) Limited, (registered in England No 1578652) registered offices at: Belmont, Belmont Road, Uxbridge, England, 
UB8 1HE and Fujitsu Research of Europe Ltd (registered in England No. 4153469) 4th Floor, Building 3, Hyde Park Hayes, 
11 Millington Road, Hayes, UB3 4AZ.

This email is only for the use of its intended recipient. Its contents are subject to a duty of confidence and may be 
privileged. Fujitsu does not guarantee that this email has not been intercepted and amended or that it is virus-free.

Unless otherwise stated, this email has been sent from Fujitsu Services Limited (registered in England No 96056); 
Fujitsu EMEA PLC (registered in England No 2216100) both with registered offices at: 22 Baker Street, London W1U 3BW; 
PFU (EMEA) Limited, (registered in England No 1578652) registered offices at: Belmont, Belmont Road, Uxbridge, England, 
UB8 1HE and Fujitsu Research of Europe Ltd (registered in England No. 4153469) 4th Floor, Building 3, Hyde Park Hayes, 
11 Millington Road, Hayes, UB3 4AZ.

This email is only for the use of its intended recipient. Its contents are subject to a duty of confidence and may be 
privileged. Fujitsu does not guarantee that this email has not been intercepted and amended or that it is virus-free.

_______________________________________________
Snort-devel mailing list
Snort-devel () lists snort org
https://lists.snort.org/mailman/listinfo/snort-devel

Please visit http://blog.snort.org for the latest news about Snort!