Daniel, I am pretty sure the OSSEC server is not behaving correctly.
I set the <local_ip> on the server to xxx.xxx.150.137 (which is the IP attached to the physical interface. This is not what I want, but I needed to test it). This is a tcpdump when the server is configured for 150.137 and the client's IP is on a DIFFERENT network. The client's IP is xxx.xxx. 135.169: 10:00:50.992638 IP xxx.xxx.135.169.32856 > xxx.xxx.150.137.1514: UDP, length 73 10:00:50.993992 IP xxx.xxx.150.139.1514 > xxx.xxx.135.169.32856: UDP, length 73 As you can see, even when the server is told to only use its physical interface, it responds on the IP attached to the virtual interface. Here is the exact same scenerio, but from a client on the SAME network (client IP = 150.134): 10:03:48.669698 IP xxx.xxx.150.134.56598 > xxx.xxx.150.137.1514: UDP, length 73 10:03:48.670930 IP xxx.xxx.150.137.1514 > xxx.xxx.150.134.56598: UDP, length 73 On Mar 19, 8:29 am, Mark C <[email protected]> wrote: > I neglected to mention the IPs of the server, ovm-a > > ovm-a eth0 is xxx.xxx.xxx.137 > > ovm-a eth0:0 is xxx.xxx.xxx.139 > > On Mar 18, 3:10 pm, Mark C <[email protected]> wrote: > > > Daniel, > > > Thanks for the response! I am humbled by the lead developer helping a > > lowly user ;) > > > It looks like you're absolutely right. One of my clients, named lmp- > > a, is talking to the server (named ovm-a) on the server's virtual > > interface (with the floating IP). However, the server is replying > > from the physical interface. > > > I thought one easy fix would be specifying both of the server's IPs as > > <server>s in the client's ossec.conf file, so that the OSSEC client > > will not drop replies coming from the server's physical interface. > > > Anyways, here's the data: > > > r...@ovm-a:~$ netstat -uanep > > Active Internet connections (servers and established) > > Proto Recv-Q Send-Q Local Address Foreign Address > > State User Inode PID/Program name > > udp 0 0 127.0.0.1:161 > > 0.0.0.0:* 0 12347 4948/ > > snmpd > > udp 0 0 0.0.0.0:57150 > > 0.0.0.0:* 0 10699 4079/ > > rpc.statd > > udp 0 0 0.0.0.0:24278 > > 0.0.0.0:* 0 12348 4948/ > > snmpd > > udp 0 0 0.0.0.0:863 > > 0.0.0.0:* 0 10691 4079/ > > rpc.statd > > udp 0 0 0.0.0.0:1514 > > 0.0.0.0:* 0 75080074 1905/ossec- > > remoted > > udp 0 0 0.0.0.0:111 > > 0.0.0.0:* 0 10657 4063/ > > portmap > > udp 0 0 0.0.0.0:40566 > > 0.0.0.0:* 33 75265071 24577/php > > > r...@ovm-a:~$ route -n > > Kernel IP routing table > > Destination Gateway Genmask Flags Metric Ref > > Use Iface > > xxx.xxx.xxx.0 0.0.0.0 255.255.255.0 U 0 0 > > 0 eth0 > > 0.0.0.0 xxx.xxx.xxx.2 0.0.0.0 UG 100 0 > > 0 eth0 > > 0.0.0.0 xxx.xxx.xxx.2 0.0.0.0 UG 100 0 > > 0 eth0 > > > r...@ovm-a:~$ /var/ossec/bin/manage_agents -a > > Choose your action: A,E,L,R or Q: l > > ... > > Available agents: > > ID: 001, Name: lmp-b, IP: xxx.xxx.xxx.134 > > ID: 002, Name: lmp-a, IP: xxx.xxx.xxx.133 > > > r...@ovm-a:~$ /var/ossec/bin/list_agents -a > > lmp-b-xxx.xxx.xxx.134 is available. > > > r...@ovm-a:~$ /var/ossec/bin/list_agents -c > > lmp-b-xxx.xxx.xxx.134 is active. > > > =============lmp-a - does NOT connect > > > r...@lmp-a:~/tcpdump-a$ grep server /var/ossec/etc/ossec.conf > > <server-ip>xxx.xxx.xxx.139</server-ip> > > > r...@lmp-a:~/tcpdump-a$ less /var/log/ossec.log > > 2009/03/18 14:52:35 ossec-agentd(4101): WARN: Waiting for server reply > > (not started). Tried: 'xxx.xxx.xxx.139'. > > 2009/03/18 14:53:15 ossec-agentd: INFO: Trying to connect to server > > (xxx.xxx.xxx.139:1514). > > > r...@lmp-a:~/tcpdump-a$ grep 1514 lmp-a.tcpdump > > 15:22:22.984876 IP xxx.xxx.xxx.133.48171 > xxx.xxx.xxx.139.1514: UDP, > > length 73 > > 15:22:22.985747 IP xxx.xxx.xxx.137.1514 > xxx.xxx.xxx.133.48171: UDP, > > length 73 > > > =============lmp-b - DOES connect > > > r...@lmp-b:~/tcpdump-b$ grep server /var/ossec/etc/ossec.conf > > <server-ip>xxx.xxx.xxx.137</server-ip> > > > r...@lmp-b:~/tcpdump-b$ less /var/log/ossec.log > > 2009/03/18 14:34:34 ossec-agentd: INFO: Trying to connect to server > > (xxx.xxx.xxx.137:1514). > > 2009/03/18 14:34:35 ossec-agentd(4102): INFO: Connected to the server > > (xxx.xxx.xxx.137:1514). > > > r...@lmp-b:~/tcpdump-b$ grep 1514 lmp-b.tcpdump > > 15:03:53.837915 IP xxx.xxx.xxx.134.55838 > xxx.xxx.xxx.137.1514: UDP, > > length 73 > > 15:03:53.838970 IP xxx.xxx.xxx.137.1514 > xxx.xxx.xxx.134.55838: UDP, > > length 73 > > > On Mar 18, 12:02 pm, Daniel Cid <[email protected]> wrote: > > > > Hi Mark, > > > > If you don't specify a local_ip in the config, it will bind to all the > > > interfaces. What I am thinking > > > is that you are having a routing issue, where ip A is receiving the > > > events from the agent, but > > > with a route configure to reply with ip B. Can you run tcpdump on both > > > ends (and netstat -uanep) to > > > see what is going on? > > > > Thanks, > > > > -- > > > Daniel B. Cid > > > dcid ( at ) ossec.net > > > > On Tue, Mar 17, 2009 at 10:46 AM, Mark C <[email protected]> wrote: > > > > > The <local_ip> I was trying was the IP attached to the eth0:0 > > > > interface. And yes, I restarted both the server and clients. > > > > > I just tried entering 0.0.0.0. When starting ossec: > > > > > 2009/03/17 08:43:45 ossec-config(1237): ERROR: Invalid ip address: > > > > '0.0.0.0'. > > > > 2009/03/17 08:43:45 ossec-config(1202): ERROR: Configuration error at > > > > '/var/ossec/etc/ossec.conf'. Exiting. > > > > 2009/03/17 08:43:45 ossec-remoted(1202): ERROR: Configuration error at > > > > '/var/ossec/etc/ossec.conf'. Exiting. > > > > > I found someone else having a similar problem: > > > >http://groups.google.com/group/ossec-list/browse_thread/thread/3cc339... > > > > > It sounds like Daniel Cid, a developer, I presume, was going to take a > > > > look at this in Oct 2007 (v1.5) but this is still a problem. For some > > > > reason, it looks like ossec is not looking at the incoming DST IP from > > > > the clients and using that as the SRC IP when responding. > > > > > I am sure my situation of using a floating IP is quite common - can > > > > anyone say that they've used virtual interfaces successfully, first > > > > hand? > > > > > On Mar 16, 7:42 pm, Christopher <[email protected]> wrote: > > > >> What IP did you specify with that option? I would assume setting > > > >> 0.0.0.0 > > > >> would allow OSSEC to listen on any IP address. You are restarting the > > > >> server after you make these changes, right? > > > > >> On Mon, Mar 16, 2009 at 3:40 PM, Mark C <[email protected]> wrote: > > > > >> > Oh, I tried the <local_ip> option specified here: > > > >> >http://www.ossec.net/main/manual/configuration-options/#remote_options > > > > >> > <remote> > > > >> > <connection>syslog</connection> > > > >> > <local_ip>xxx.xxx.xxx.xxx</local_ip> > > > >> > </remote> > > > > >> > And it did not work even after restarting. > > > > >> > On Mar 16, 2:54 pm, Mark C <[email protected]> wrote: > > > >> > > Hi all, > > > > >> > > I've just installed OSSEC 2 on an Ubuntu 6.06 server 32bit system. > > > >> > > It's part of a simple cluster where there's a floating IP, eth0:0. > > > >> > > I > > > >> > > setup 2 agents, and during the initial setup gave them the floating > > > >> > > IP. Here's what both saw in the logs: > > > > >> > > 2009/03/16 14:42:11 ossec-agentd(4101): WARN: Waiting for server > > > >> > > reply > > > >> > > (not started). Tried: 'xxx.xxx.xxx.xxx'. > > > >> > > 2009/03/16 14:42:33 ossec-agentd: INFO: Trying to connect to server > > > >> > > (xxx.xxx.xxx.xxx:1514). > > > > >> > > I restarted the server and agents several times. > > > > >> > > Then on one of the agents, I changed the server IP in > > > >> > > /var/ossec/etc/ > > > >> > > ossec.conf. I restarted the agent and when I ran /var/ossec/bin/ > > > >> > > list_agents -c on the server, I saw that it was connectd. > > > > >> > > I've searched for any file on the server that might let me specify > > > >> > > what IP or interface to listen on but I can't find anything. > > > >> > > Connectivity to the virtual interface, aside from OSSEC, works > > > >> > > without > > > >> > > any problems whatsoever. > > > > >> > > The server and clients are on the same subnet. There are no > > > >> > > firewalls > > > >> > > involved. > > > > >> > > I'm sure I'm missing something very simple :)
