Okay, update: We finally figured out, after completely rebuilding the machine from scratch on new hardware, that the problem is that OSSEC is listening on the wrong interface.
However, it didn't previously listen on the wrong interface (several months ago, when we first built and tested this machine, and before we moved to the new room), and on a similarly-configured machine, OSSEC listens on the correct interface. The machine is configured with three interfaces, eth0, eth1, and eth3 (eth2 is reserved and not active). Eth0 is configured as the primary interface for the box, and it's the interface to which our router/ switch forwards packets addressed to the OSSEC port. Eth1 is in promiscuous mode, and eth3 is configured as a rare-use management port, with its route disabled at the switch. It happens to be on the same subnet as some of our OSSEC agents, though not all of them. Up until now, through multiple builds of this and similar machines, OSSEC has had no problem understanding that it is supposed to listen on eth0. However, on this particular machine, OSSEC tries to listen on eth3 as long as it's active. Only if we ifconfig eth3 down does OSSEC listen to eth0. We've rebuilt this machine from scratch - deleted the old partitions and overwrote the old data - and put it on new hardware, yet OSSEC continues to try to listen to the wrong interface. We've never had this happen before, on half a dozen identical builds. What mechanism does OSSEC use to determine which interface to listen on in Linux? What could have caused OSSEC to stop listening to eth0 and switch to eth3? Could the fact that eth3 exists on the same subnet as some, but not all, agents have any effect on this? Thanks! -Alisha
