That is probably rootcheck trying to detect system anomalies and kernel level rootkits. It does it by comparing the output of netstat with its own results binding ports to check if they are open.
Remember that syscheckd not only does FIM, but also Rootchecks (policy monitoring checks and anomalies detection). You can disable these checks using <check_ports>no</check_ports> (under rootcheck section). Other checks are done to detect hiddent files or processes. Complete documentation here: http://ossec-docs.readthedocs.io/en/latest/manual/rootcheck/manual-rootcheck.html You can also enable debug for syscheck in internal_options.conf file (so you get to know better what it is doing) I hope it helps, Santiago. On Wed, Mar 1, 2017 at 7:59 AM, John Gelnaw <jgel...@gmail.com> wrote: > > Followup. ossec-syscheckd appears to be doing some bind operation: > > > socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 6 > bind(6, {sa_family=AF_INET, sin_port=htons(12310), > sin_addr=inet_addr("0.0.0.0")}, 16) = 0 > close(6) = 0 > socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 6 > bind(6, {sa_family=AF_INET, sin_port=htons(12311), > sin_addr=inet_addr("0.0.0.0")}, 16) = 0 > close(6) = 0 > socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 6 > bind(6, {sa_family=AF_INET, sin_port=htons(12312), > sin_addr=inet_addr("0.0.0.0")}, 16) = 0 > close(6) = 0 > socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 6 > bind(6, {sa_family=AF_INET, sin_port=htons(12313), > sin_addr=inet_addr("0.0.0.0")}, 16 > 2017 Mar 1 10:27:58 ahc-www01 NMI watchdog: BUG: soft lockup - CPU#0 stuck > for 22s! [ossec-syscheckd:19286] > 2017 Mar 1 10:28:26 ahc-www01 NMI watchdog: BUG: soft lockup - CPU#0 stuck > for 22s! [ossec-syscheckd:19286] > 2017 Mar 1 10:28:58 ahc-www01 NMI watchdog: BUG: soft lockup - CPU#0 stuck > for 22s! [ossec-syscheckd:19286] > 2017 Mar 1 10:29:26 ahc-www01 NMI watchdog: BUG: soft lockup - CPU#0 stuck > for 22s! [ossec-syscheckd:19286] > 2017 Mar 1 10:29:54 ahc-www01 NMI watchdog: BUG: soft lockup - CPU#0 stuck > for 22s! [ossec-syscheckd:19286] > > My guess is that it's trying to bind, running out of available sockets, > and waiting until a socket frees up (or forever, whichever comes first). > > Why would syscheckd be attempting to bind to 0.0.0.0, however? > > -- > > --- > You received this message because you are subscribed to the Google Groups > "ossec-list" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to ossec-list+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- --- You received this message because you are subscribed to the Google Groups "ossec-list" group. To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
