Specify LISTEN IP and/or interface on the server?

[Mark C]

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

[Mark C]

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.

[Christopher]

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?

[Mark C]

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/3cc3390d5ad19a24/b2c16a478b9a97a1?lnk=gst&q=local_ip#b2c16a478b9a97a1

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?

[Rob Butterworth]

I've got the problem in the other direction - I have client machines with multiple virtual interfaces, and after a reboot the ossec agent binds to different addresses, breaking agent->server comms. Switching to using a network address range as the client address works for alerting, but breaks the WUI, so I don't want to do that. A config option to force the agent to use a specific IP would be better...

Rob

-
Any views expressed in this message are those of the individual sender, except where specifically stated to be the view of the Company, its subsidiaries or associates. When addressed to our customers, any opinions or advice contained in this eMail are subject to the relevant Company terms of business. The Company reserves the right to monitor all email communications through its internal and external networks. NOTICE: This eMail is intended solely for the named recipient only. It may contain privileged and/or confidential information. If you are not one of the intended recipients, please notify the sender immediately, and destroy this eMail; you must not copy, distribute or take any action in reliance upon it. Whilst all efforts are made to safeguard Inbound and Outbound eMails, the Company cannot guarantee that attachments are Virus-free or compatible with your systems and does not accept any liability in respect of viruses or computer problems experienced.
IMPORTANT: Credit Card Details should not be sent to the Company by email.

[Daniel Cid]

Hi Rob,

Can you describe what is breaking the wui? Using a network address
range should work fine in there...

Thanks,

--
Daniel B. Cid
dcid ( at ) ossec.net

[Daniel Cid]

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

[Rob Butterworth]

When I used an address range (e.g. 192.168.1.0/24) I ended up with only one agent listed in the WUI - it didn't seem to like that I had multiple agents on the same network using the same address.

[Mark C]

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:


root@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

root@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

root@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

root@ovm-a:~$ /var/ossec/bin/list_agents -a
lmp-b-xxx.xxx.xxx.134 is available.

root@ovm-a:~$ /var/ossec/bin/list_agents -c
lmp-b-xxx.xxx.xxx.134 is active.


=============lmp-a - does NOT connect

root@lmp-a:~/tcpdump-a$ grep server /var/ossec/etc/ossec.conf
<server-ip>xxx.xxx.xxx.139</server-ip>

root@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).

root@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

root@lmp-b:~/tcpdump-b$ grep server /var/ossec/etc/ossec.conf
<server-ip>xxx.xxx.xxx.137</server-ip>

root@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).

root@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 <daniel....@gmail.com> 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 <ved...@gmail.com> 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...

[Mark C]

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

[Mark C]

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

[Daniel Cid]

Hi Mark,

This is a networking issue common to UDP, since it is stateless and
the kernel decides on which interface
to reply, it will generally use the main (first) interface.

For example, if I setup a virtual interface in here (host ourhome):
eth0 -> 192.168.2.15
eth0:0 -> 192.168.2.77
eth0:1 -> 192.168.2.78

and test with netcat:

dcid@ourhome:~$ nc -l -u -p 12345 (listening on all interfaces)
dcid@remotebox:~$ nc -u 192.168.2.78 12345 (using the eth0:1 ip).

This is what I get on tcpdump:

# tcpdump -nn -i xl0 udp port 12345
tcpdump: listening on xl0, link-type EN10MB
12:15:08.654902 192.168.2.10.23783 > 192.168.2.78.12345: udp 7
12:15:11.903964 192.168.2.15.12345 > 192.168.2.10.23783: udp 7 (DF)

You see that I am talking to the ip .78 and the kernel is replying
using the .15 (main interface ip). That's
why the client doesn't get the reply from netcat.

However, if I set a local ip in there, it will work properly.

So, for your case to work, you need to set <local_ip> to
xxx.xxx.xxx.139 and restart the manager (and the agent
after). If you do that, it will use the proper interface. But note
that even if you set that and the connections comes
from a different network, the kernel will redirect using the configured route.

*I will also look into changing the code to try getting the dst ip of
the incoming packets and use that
as the source of the reply...

Thanks,

--
Daniel B. Cid
dcid ( at ) ossec.net

[Mark C]

Hi Daniel,

When the server uses local_ip x.x.150.139 (virtual interface) and a
client on a different network is set to contact the server on x.x.
150.139:

10:13:24.789953 IP xxx.xxx.135.169.32862 > xxx.xxx.150.139.1514: UDP,
length 73
10:13:24.791055 IP xxx.xxx.150.137.1514 > xxx.xxx.135.169.32862: UDP,
length 73

(So, this is exactly what you described. The client contacts the
server on the x.x.x.139, the virtual interface IP, and the server uses
its physical interface to reply.)

However..

When the server uses local_ip x.x.150.139 (virtual interface) and a
client on the SAME network is set to contact the server o x.x.150.139:

10:13:21.154749 IP xxx.xxx.150.134.46997 > xxx.xxx.150.139.1514: UDP,
length 73
10:13:21.155934 IP xxx.xxx.150.137.1514 > xxx.xxx.150.134.46997: UDP,
length 73

Just like when the server/client are on different networks, the server
still responds using the IP attached to the physical interface.

If it's not too much trouble (and assuming there are no drawbacks), a
code change to use the incoming DST IP as the outgoing SRC IP would be
MUCH appreciated!! I have already fallen in love with OSSEC just by
using it on the few hosts on the same network as the server.

> ...
>
> read more »