I am dealing with this same issue on FreeBSD 11.1 using OSSEC 2.9.3. I have 
tracked it down to a socket issue in remoted with IPV4 addresses. If I 
configure the interface to use IPV6 sockets there are no issues, but if I 
use an IPV4 address I get the same error Quentin is getting. This happens 
on both the secure port and the syslog port for remoted. Note that I do not 
use IPV6 on my system outside of the loopback interface. My primary 
ethernet interface is configured for IPV4 only.

First, I run rsyslogd on my server, which binds to port 514 for both IPV4 
and IPV6. I want to take advantage of OSSEC's syslog capability so I 
configure OSSEC to use port 1515 as an alternate syslog interface. However, 
the configuration is only establishing a socket for UDP using IPV6, not 
IPV4. This is confirmed using netstat -an and the FreeBSD sockstat command.

For the secure port, if I don't specify an IP address, it binds to port 
1515 using IPV6 only. If I try to force it to use an IPV4 address, it fails 
with the following log message:

2018/04/11 12:04:10 ossec-remoted(1206): ERROR: Unable to Bind port '1514'

This is the relevant portion of the config that creates this error:

<remote>
  <connection>syslog</connection>
  <allowed-ips>192.168.1.0/24</allowed-ips>
  <port>1515</port>
</remote>

<remote>
  <connection>secure</connection>
  <local_ip>192.168.1.80</local_ip>
  <port>1514</port>
</remote>

If I change the secure port to this configuration, it binds to IPV6 on 
port 1514 without error, but it ignores the IPV4 address on the 
primary interface.  This is the relevant config that does this:

<remote>
  <connection>secure</connection>
</remote>

This is the output from netstat -an showing that rsyslogd is able to bind 
using both IPV4 and IPV6 to port 514, but OSSEC is only able to bind to 
IPV6 on ports 1514 and 1515:

ossec:/usr/local/ossec/etc [516] $ netstat -an
Active Internet connections (including servers)
Proto Recv-Q Send-Q Local Address          Foreign Address        (state)
tcp4       0      0 127.0.0.1.3306         *.*                    LISTEN
tcp4       0      0 127.0.0.1.25           *.*                    LISTEN
tcp4       0      0 *.514                  *.*                    LISTEN
tcp6       0      0 *.514                  *.*                    LISTEN
udp4       0      0 *.514                  *.*                    
udp6       0      0 *.514                  *.*                    
udp6       0      0 *.1514                 *.*                    
udp6       0      0 *.1515                 *.*                    
Active UNIX domain sockets
Address          Type   Recv-Q Send-Q            Inode             Conn    
         Refs          Nextref Addr
fffff800059d9780 stream      0      0 fffff800724301d8                0    
            0                0 /tmp/mysql.sock
fffff800059d9960 dgram       0      0 fffff8004c73d588                0 
fffff800059cf1e0                0 /queue/ossec/queue
fffff800059cfe10 dgram       0      0 fffff800462f9b10                0 
fffff80005a140f0                0 /queue/alerts/ar
fffff800059f2960 dgram       0      0 fffff80046f85b10                0 
fffff800059e5780                0 /usr/local/ossec/queue/alerts/execq

This is what FreeBSD's sockstat command shows:

ossec:/usr/local/ossec/etc [516] $ sockstat
USER     COMMAND            PID   FD PROTO  LOCAL ADDRESS         FOREIGN 
ADDRESS      
ossec    ossec-monitord     59461 3  dgram  -> /queue/ossec/queue
root     ossec-syscheckd    59457 3  dgram  -> /queue/ossec/queue
root     ossec-syscheckd    59457 4  dgram  -> /queue/ossec/queue
ossecr   ossec-remoted      59454 3  udp6   *:1514                *:*
ossecr   ossec-remoted      59454 4  dgram  -> /queue/ossec/queue
ossecr   ossec-remoted      59454 5  dgram  /queue/alerts/ar
ossecr   ossec-remoted      59453 3  udp6   *:1515                *:*
ossecr   ossec-remoted      59453 4  dgram  -> /queue/ossec/queue
root     ossec-logcollector 59447 3  dgram  -> /queue/ossec/queue
ossec    ossec-analysisd    59443 3  dgram  /queue/ossec/queue
ossec    ossec-analysisd    59443 7  dgram  -> /queue/alerts/ar
ossec    ossec-analysisd    59443 8  dgram  -> 
/usr/local/ossec/queue/alerts/execq
root     ossec-execd        59439 3  dgram  
/usr/local/ossec/queue/alerts/execq
mysql    mysqld             2119  22 tcp4   127.0.0.1:3306        *:*
mysql    mysqld             2119  24 stream /tmp/mysql.sock
smmsp    sendmail           1694  3  dgram  -> /var/run/log
root     sendmail           1661  3  tcp4   127.0.0.1:25          *:*
root     sendmail           1661  4  dgram  -> /var/run/log
root     rsyslogd           451   3  tcp4   *:514                 *:*
root     rsyslogd           451   0  tcp6   *:514                 *:*
root     rsyslogd           451   6  udp4   *:514                 *:*
root     rsyslogd           451   5  udp6   *:514                 *:*
root     rsyslogd           451   1  dgram  (not connected)
root     rsyslogd           451   7  dgram  /var/run/log

Just to complete the loop, this is the configuration for my network 
interfaces:

ossec:/usr/local/ossec/etc [538] $ ifconfig -a
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        
options=4019b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,VLAN_HWTSO>
        ether c0:3f:d5:60:a5:58
        hwaddr c0:3f:d5:60:a5:58
        inet 192.168.1.80 netmask 0xffffff00 broadcast 192.168.1.255 
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
        inet6 ::1 prefixlen 128 
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 
        inet 127.0.0.1 netmask 0xff000000 
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
        groups: lo 

On my client end (Windows 7 Pro) I am seeing the following log messages:

2018/04/11 12:18:00 ossec-agentd: INFO: Trying to connect to server 
192.168.1.80, port 1514.
2018/04/11 12:18:00 INFO: Connected to 192.168.1.80 at address 
192.168.1.80:1514, port 1514
2018/04/11 12:18:21 ossec-agentd(4101): WARN: Waiting for server reply (not 
started). Tried: '192.168.1.80'.
2018/04/11 12:39:41 ossec-agentd: INFO: Trying to connect to server 
192.168.1.80, port 1514.
2018/04/11 12:39:41 INFO: Connected to 192.168.1.80 at address 
192.168.1.80:1514, port 1514
2018/04/11 12:40:02 ossec-agentd(4101): WARN: Waiting for server reply (not 
started). Tried: '192.168.1.80'.
2018/04/11 13:01:40 ossec-agentd: INFO: Trying to connect to server 
192.168.1.80, port 1514.
2018/04/11 13:01:40 INFO: Connected to 192.168.1.80 at address 
192.168.1.80:1514, port 1514
2018/04/11 13:02:01 ossec-agentd(4101): WARN: Waiting for server reply (not 
started). Tried: '192.168.1.80'.

I have verified that the packs are arriving at the OSSEC server using 
tcpdump. But of course the server is not going to reply because the message 
is being sent using UDP on IPV4, but there are no IPV4 sockets listening on 
the server side. This is further backed up with the logging of this message 
by the server showing a connection attempt without a listening service:

Apr 11 13:02:10 c1000s1 kernel: Connection attempt to UDP 192.168.1.80:1514 
from 192.168.1.54:61835
Apr 11 13:02:15 c1000s1 kernel: Connection attempt to UDP 192.168.1.80:1514 
from 192.168.1.54:61835
Apr 11 13:02:21 c1000s1 kernel: Connection attempt to UDP 192.168.1.80:1514 
from 192.168.1.54:61835

My guess is that they broke something when one of the developers added IPV6 
support to the 2.8.3 release. I have done a lot of network programming in C 
in the past, so I think I can fix this. In src/remoted directory there are 
two files that bind sockets - secure.c and syslog.c.  Because it affects 
both functions, the programming error is in both modules. I will see what I 
can find this afternoon, and if I can fix it I will submit a pull request 
on the archive and post the patch in this forum as well. I saw some flakey 
behavior in this code in the 2.8.3 release as well, so it may require some 
more in depth work. I will also add better diagnostics to this to track 
down errors.  Down the rabbit hole ...

Dave Stoddard
Network Alarm Corporation
dgs at networkalarmcorp dot com
301-850-0668 x101

On Friday, April 6, 2018 at 5:42:28 AM UTC-4, quentin mallet wrote:
>
> Greetings everyone,
>
> I have a distributed setup with the server on a securityonion install. No 
> issues with clients in other subnets but when I tried to set up a client on 
> a remote server I encountered the following situation:
>
> Client log
> 2018/04/06 09:29:00 INFO: Connected to [redacted] at address XX.XX.XX.XX, 
> port 1514
> 2018/04/06 09:29:21 ossec-agentd(4101): WARN: Waiting for server reply 
> (not started). Tried: '[redacted]'.
>
> ----------------------------------------
> Setup Data
> ----------------------------------------
>
> Sever ossec-init.conf:
> DIRECTORY="/var/ossec"
> VERSION="v2.8.2"
> DATE="Mon Oct 19 19:53:53 UTC 2015"
> TYPE="server"
>
> Client ossec-init.conf:
> DIRECTORY="/var/ossec"
> VERSION="v2.9.3"
> DATE="Thu Apr  5 15:45:55 CEST 2018"
> TYPE="agent"
>
> The version mismatch does not seem to be the root cause, I have other 
> clients in other subnets behind the same firewall that have the same 
> version and don't have any issues connecting with the server (clients are 
> both on windows and *nix machines).
>
> ---------------------------
> Network topology
> ---------------------------
> client ----> NAT_router ---> Firewall_NAT ---> Server
>
>
> -------------------------
> Fix attempt
> -------------------------
> I triple checked the client keys and did the following:
> 1. Shut down server and client
> 2. Delete client on server, Generate new client key
> 3. Start server
> 4. Import new key on client.
> 5. Start client.
>
> No luck. 
>
>
> ----------------------------------
> Packet Captures
> ----------------------------------
> I did packet captures on the server side, on the client side, on both 
> sides of the firewall and packets seem to flow freely. The port changes on 
> the client side happens every 5 packets it seem. the captures were taken at 
> different points in time.
>
>
> Tcpdump on the client (tcpdump -i XXX udp port 1514):
>
> -------------------------------------------------------------------------------
> 07:40:48.281799 IP [client] > [server].1514: UDP, length 73
> 07:40:48.282499 IP [server].1514 > [client].39116: UDP, length 73
> 07:40:53.282313 IP [client].39116 > [server].1514: UDP, length 73
> 07:40:53.282954 IP [server].1514 > [client].39116: UDP, length 73
>
> Tcpdump on the server (tcpdump -i XXX udp port 1514):
>
> -------------------------------------------------------------------------------
> 08:29:31.305862 IP client.52958 > server.1514: UDP, length 73
> 08:29:31.306591 IP server.1514 > client.52958: UDP, length 73
>
>
> Between the firewall and the NAT router:
>
> -------------------------------------------------------------------------------
> 08:14:13.837919 de:ad:ba:be:ca:fe > de:ad:be:ef:ca:fe, ethertype IPv4 
> (0x0800), length 115: (tos 0x0, ttl 54, id 29801, offset 0, flags [DF], 
> proto UDP (17), length 101)
>   [client].48932 > [firewall].1514: [udp sum ok] UDP, length 73
>
> 08:24:36.288617 de:ad:ba:be:ca:fe > de:ad:be:ef:ca:f, ethertype IPv4 
> (0x0800), length 115: (tos 0x0, ttl 63, id 36571, offset 0, flags [DF], 
> proto UDP (17), length 101, bad cksum 0 (->ea4)!)
>     [firewall].1514 > [client].48932: [udp sum ok] UDP, length 73
>
> Sometimes I have a bad checksum error.
>
> Between the firewall and the server
>
> -------------------------------------------------------------------------------
> 08:21:42.391671 ba:dd:ee:d0:00:00 > de:ad:be:ad:ad:00, ethertype IPv4 
> (0x0800), length 115: (tos 0x0, ttl 52, id 27141, offset 0, flags [DF], 
> proto UDP (17), length 101, bad cksum 0 (->3b7a)!)
>     [client].39656 > [server].1514: [udp sum ok] UDP, length 73
>
> And same thing on return path.
>
> Logically it seems that the NAT might be the issue, since other (not 
> NATed) clients don't have any troubles connecting, but I can't see how it 
> would impede communication, as data flows freely both ways...
> I'm running out of ideas so any input on my situation would be greatly 
> appreciated!
>
> Regards,
> Quentin
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to