Community ID not being generated on macOS/Linux

[Phil Rzewski]

As discussed in brimdata/zui#1207, an issue related to the nss libraries is currently preventing the Community ID field from being populated in alert events on macOS.

I discovered a similar problem on CentOS 8 using a fresh-launched VM.

$ cat wrccdc.2018-03-23.010014000000000.pcap | ./suricatarunner 
/home/phil/suricata/bin/suricata: error while loading shared libraries: libnss3.so: cannot open shared object file: No such file or directory

FWIW I had a different failure on CentOS 7, but this is so ancient that perhaps we shouldn't pursue it. The Brim support statement sets expectations that we're not actively testing on versions older than CentOS 8.

$ cat wrccdc.pcap | ./suricatarunner 
/home/phil/suricata/bin/suricata: /lib64/libc.so.6: version `GLIBC_2.22' not found (required by /home/phil/suricata/bin/suricata)
/home/phil/suricata/bin/suricata: /lib64/libc.so.6: version `GLIBC_2.27' not found (required by /home/phil/suricata/bin/suricata)
/home/phil/suricata/bin/suricata: /lib64/libc.so.6: version `GLIBC_2.18' not found (required by /home/phil/suricata/bin/suricata)
/home/phil/suricata/bin/suricata: /lib64/libc.so.6: version `GLIBC_2.25' not found (required by /home/phil/suricata/bin/suricata)

However, it fails similarly on Fedora 21, which is currently the "floor" on our support statement for Linux.

$ cat ../wrccdc.pcap | ./suricatarunner 
/home/phil/suricata/bin/suricata: /lib64/libc.so.6: version `GLIBC_2.22' not found (required by /home/phil/suricata/bin/suricata)
/home/phil/suricata/bin/suricata: /lib64/libc.so.6: version `GLIBC_2.27' not found (required by /home/phil/suricata/bin/suricata)
/home/phil/suricata/bin/suricata: /lib64/libc.so.6: version `GLIBC_2.25' not found (required by /home/phil/suricata/bin/suricata)

[henridf]

Fwiw, the issue is that nss loads dynamic libraries at runtime as part of it's module system. The specific module that's needed here for community_id is the one implementing SHA1. Statically linking the libraries does not help here, since the loading is done at runtime.

Bundling the libraries addresses this (at least, so far, on macOS).

[Phil Rzewski]

A verification on macOS is covered in #40 (comment).

I revisited CentOS v7.8 and Fedora 21 and had a problem similar to what I reported above. However, that led me to recall that we have existing issue brimdata/zui#1008 that shows up when I try to install any GA Brim RPM on those releases. So even if we muscled the right libraries into place to make Suricata run on these, it seems it'd be moot if the rest of Brim can't run either.

However, on CentOS 8.2 with the brim_x86_64_rc-v0.20.0-suricata18.rpm artifact and on Ubuntu 18.04 with the brim_amd_rc-v0.20.0-suricata18.deb artifact, I was able to install and generate Suricata alerts.

As you can see, all the alerts are all of the same category, which is highly suspicious. I've opened #42 to pursue that.

Also, Community ID is not being populated on Windows, but I think we already knew that. I didn't have an issue open to track that, though, so I've just opened #43 for that.