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 :)
