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. On Mar 19, 11:31 am, Daniel Cid <[email protected]> wrote: > 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: > > d...@ourhome:~$ nc -l -u -p 12345 (listening on all interfaces) > d...@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 > > On Thu, Mar 19, 2009 at 12:06 PM, Mark C <[email protected]> wrote: > > > > > 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 > > ... > > read more »
