Re: [ossec-list] Re: Manager doesn't see agent
Can you provide a little more information on this in case it comes up again in the future? What's it called, how do you set it, where can I find it in the NSA RHEL hardening guide? Thank in advance! On Fri, Apr 13, 2012 at 11:54 AM, Alisha Kloc wrote: > All right, we *finally* found the problem - not OSSEC, but a new > system hardening step. > > The NSA security guidelines recommend setting Linux systems to > validate the source IP address of received packets. With eth3 up, this > validation fails because the IP stack sees packets sourced from the > network on eth3 coming in on eth0, which is a violation, and the > packets are dropped. > > So it's not that OSSEC is listening on the wrong port, local_ip option > or not; it's that the IP stack is dropping the packets before they get > to OSSEC. > > Thanks so much for all your help!
[ossec-list] Re: Manager doesn't see agent
All right, we *finally* found the problem - not OSSEC, but a new system hardening step. The NSA security guidelines recommend setting Linux systems to validate the source IP address of received packets. With eth3 up, this validation fails because the IP stack sees packets sourced from the network on eth3 coming in on eth0, which is a violation, and the packets are dropped. So it's not that OSSEC is listening on the wrong port, local_ip option or not; it's that the IP stack is dropping the packets before they get to OSSEC. Thanks so much for all your help!
[ossec-list] Re: Manager doesn't see agent
I can't post the exact ifconfig, but it boils down to this: eth0: Up, xxx.xxx.xxx.xxx (primary IP address for communication with OSSEC agents and Active Directory; does not share a subnet with any agents; address translation handled at the router/switch level) eth1: Up, Promiscuous (no IP) eth2: Down (unused) eth3: Up, xxx.xxx.xxx.xxx (secondary IP address for security assessments; shares first two octets with OSSEC agents; route is down at the router/switch level except during assessments) The section of the manager's ossec.conf is: secure Our sysadmin has been running some other tests; he found that if he changes eth3 to a different IP address that doesn't share anything with the agents, the problem goes away and OSSEC hears from its agents. So it seems like OSSEC has decided to only listen to the interface which shares part of its IP with its agents. But we'd had this tested and working before, so why would it start to do this now?
Re: [ossec-list] Re: Manager doesn't see agent
Looking at the source for 2.4, local_ip is there. I have no idea why OSSEC would choose an unrelated IP address instead of the one defined in . What's the `ifconfig -a` for this server? The section in the manager's ossec.conf? On Thu, Apr 12, 2012 at 1:10 PM, Alisha Kloc wrote: > All right, so I tried using the local_ip option - but no luck. > > Netstat -uan reports that the box is listening on eth0 to the OSSEC > port. However, OSSEC still didn't pick up any agent messages. I turned > eth3 down, and immediately got agent messages. Turned it back up, > messages stopped. > > So local_ip has no effect on this problem. The OSSEC Manager wants to > listen to eth3 unless forced to do otherwise. > > I've got no idea what to try next... any suggestions?
[ossec-list] Re: Manager doesn't see agent
All right, so I tried using the local_ip option - but no luck. Netstat -uan reports that the box is listening on eth0 to the OSSEC port. However, OSSEC still didn't pick up any agent messages. I turned eth3 down, and immediately got agent messages. Turned it back up, messages stopped. So local_ip has no effect on this problem. The OSSEC Manager wants to listen to eth3 unless forced to do otherwise. I've got no idea what to try next... any suggestions?
Re: [ossec-list] Re: Manager doesn't see agent
I don't know if it's in 2.4. I haven't used that in a long long time. On Thu, Apr 5, 2012 at 2:43 PM, Alisha Kloc wrote: > Hmm, I had not actually heard of that option before. So after looking > it up... it just goes in between the tags on the > manager's ossec.conf? Is it even applicable to OSSEC 2.4? (Yeah... > we're way behind.) > > Thanks! > -Alisha
[ossec-list] Re: Manager doesn't see agent
*Oops, I meant tags in my last message...
[ossec-list] Re: Manager doesn't see agent
Hmm, I had not actually heard of that option before. So after looking it up... it just goes in between the tags on the manager's ossec.conf? Is it even applicable to OSSEC 2.4? (Yeah... we're way behind.) Thanks! -Alisha
Re: [ossec-list] Re: Manager doesn't see agent
The local_ip option isn't working for you? On Apr 5, 2012 1:55 PM, "Alisha Kloc" wrote: > Bump. > > Can someone explain how OSSEC decides which Linux interface to listen > on? Is there a way to force it to listen to one in particular? > > Thanks! > -Alisha
[ossec-list] Re: Manager doesn't see agent
Bump. Can someone explain how OSSEC decides which Linux interface to listen on? Is there a way to force it to listen to one in particular? Thanks! -Alisha
[ossec-list] Re: Manager doesn't see agent
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
[ossec-list] Re: Manager doesn't see agent
Yeah, I checked everyone's IP addresses and ports; those are all fine. The manager's IP hasn't changed, either; we just had a physical room move. I tried deleting the agent off the manager and creating a new one with a new key, but the manager didn't pick up that agent either. I even tried giving the agent a bad key to see if I could at least get the manager to give that message that means it's seeing messages from an agent with the wrong key, but no luck. I'm starting to think this is some low-level network problem way beyond my depth... On Mar 27, 2:01 pm, "dan (ddp)" wrote: > tcpdump will pick up packets even if they're blocked by the firewall. > Are the messages coming from the correct IP? Did the manager's IP change at > all? > You could also try deleting the agent from the manager, creating a new > one, and installing that key on the agent.
Re: [ossec-list] Re: Manager doesn't see agent
tcpdump will pick up packets even if they're blocked by the firewall. Are the messages coming from the correct IP? Did the manager's IP change at all? You could also try deleting the agent from the manager, creating a new one, and installing that key on the agent. On Tue, Mar 27, 2012 at 4:50 PM, Alisha Kloc wrote: > One-way agents normally show as "Connected" like regular agents, > actually. All the one-way flag does afaik is skip the section in the > agent startup where it waits for a response from the manager before > continuing to start; otherwise, they behave exactly like normal > agents. > > Also, no, the manager wasn't updated recently, although we did > physically move to a new location so I'm a little worried there's some > kind of connection issue (although Wireshark says the packets are > getting to the manager...). > > I've already confirmed from a few angles that we're receiving no > events at all, and I think the agent would show up as "Connected" > under agent_control before it would send events...? But I'll > definitely try killing the firewall and setting debug. > > Thanks! > -Alisha > > > On Mar 27, 1:30 pm, "dan (ddp)" wrote: >> Are you sure that isn't how one way agents always show up? I have no >> idea, I don't like that option. Was the manager updated recently >> (maybe the one way comms setting has to be set on the manager and >> someone forgot to set it)? >> >> You can try: >> Turn off the firewall on the manager. >> Run the manager's ossec processes in debug mode, look for errors again. >> Double check to make sure logs aren't making it to the manager (you >> can even turn on the log all option to triple check).
[ossec-list] Re: Manager doesn't see agent
One-way agents normally show as "Connected" like regular agents, actually. All the one-way flag does afaik is skip the section in the agent startup where it waits for a response from the manager before continuing to start; otherwise, they behave exactly like normal agents. Also, no, the manager wasn't updated recently, although we did physically move to a new location so I'm a little worried there's some kind of connection issue (although Wireshark says the packets are getting to the manager...). I've already confirmed from a few angles that we're receiving no events at all, and I think the agent would show up as "Connected" under agent_control before it would send events...? But I'll definitely try killing the firewall and setting debug. Thanks! -Alisha On Mar 27, 1:30 pm, "dan (ddp)" wrote: > Are you sure that isn't how one way agents always show up? I have no > idea, I don't like that option. Was the manager updated recently > (maybe the one way comms setting has to be set on the manager and > someone forgot to set it)? > > You can try: > Turn off the firewall on the manager. > Run the manager's ossec processes in debug mode, look for errors again. > Double check to make sure logs aren't making it to the manager (you > can even turn on the log all option to triple check).