Atomicorp

Hello

I have installed latest OSSEC on CentOS 8 using these instructions:

# Add Yum repo configuration
wget -q -O - https://updates.atomicorp.com/installers/atomic | sudo bash

# Server
sudo yum install ossec-hids-server

Proceeded by installing the OSSEC Agent Manager on to a Win2K19 Xen VM and used manage_agents respectively.

I then restarted OSSEC using ossec-control to refresh everything.

This is the result of netstat -tulnp

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1047/sshd
tcp6 0 0 :::22 :::* LISTEN 1047/sshd
udp 0 0 127.0.0.1:323 0.0.0.0:* 955/chronyd
udp6 0 0 ::1:323 :::* 955/chronyd
udp6 0 0 :::1514 :::* 2949/ossec-remoted

I'm unable to get the agent connecting with the server. Is this because ossec-remoted is not binding to an ipv4 protocol udp 0.0.0.0:1514 ?

Both server and client are local machines and I've disabled firewalls on the server/agent. Am I totally missing something here?

Thanks in advance.

PS I tried to add the win2k19 agent log file, but would tell me "The extension is not allowed." - tried .log .txt and even without an extension.

Assuming the agent is trying to connect to the remoted service running on an IPv4 IP, no it doesnt look like you have ossec-remoted running on an IPv4 address. Is the hub system plumbed with an IPv4 address? Alternatively you can use IPv6.

If so, what happens if you restart the ossec-hids service?

PS I tried to add the win2k19 agent log file, but would tell me "The extension is not allowed." - tried .log .txt and even without an extension.

Not quite sure what you were trying to do, could you elaborate?

Hello

Please refer to https://pastebin.com/2JTv4kuX

It's my understanding IPv4 is enabled, otherwise I wouldn't be able to SSH to 192.* using port 22. The agent is connecting to the same IPv4 IP.

no it doesnt look like you have ossec-remoted running on an IPv4 address

Does ossec-remoted not bind to IPv4 by default?

Not quite sure what you were trying to do, could you elaborate?

I attempted to attach the ossec agent log file generated by the client to demonstrate that the agent is connecting to the server, but disconnecting after the "initializing" period, followed by further attempts to reconnect however failing on each attempt. I clicked Browse, selected file, clicked on Add the file, then the message "The extension is not allowed" appeared top of my screen.

Thanks.

Does ossec-remoted not bind to IPv4 by default?

It runs on IPv4 too, for example:

[root@host ~]# netstat -anupl | grep ossec-remoted
udp 0 0 0.0.0.0:1514 0.0.0.0:* 11174/ossec-remoted
[root@host ~]#

However, if an IPv4 interface wasnt plumbed when the service was started, then you would only see it listening on the one that was, like an IPv6 interface which isnt as uncommon as you might think.

Whats the output of this command:

awp -v

I attempted to attach the ossec agent log file generated by the client to demonstrate that the agent is connecting to the server, but disconnecting after the "initializing" period, followed by further attempts to reconnect however failing on each attempt. I clicked Browse, selected file, clicked on Add the file, then the message "The extension is not allowed" appeared top of my screen.

Do you mean you tried to attach the log file in the forums?

Hello

[root@localhost jameso]# netstat -anupl | grep ossec-remoted
udp6 0 0 :::1514 :::* 2450/ossec-remoted
[root@localhost jameso]# awp -v
bash: awp: command not found
[root@localhost jameso]#

It runs on IPv4 too, for example:

Understood, however, shouldn't the service run on both protocols, or at least be binding to IPv4 in the first instance as still the standard? Perhaps I disable IPv6 in an attempt to force ossec-remoted to bind to IPv4?

Do you mean you tried to attach the log file in the forums?

Yes!

Are you using the open source OSSEC only? And if so, what version?

Understood, however, shouldn't the service run on both protocols, or at least be binding to IPv4 in the first instance as still the standard?

I'm not sure I understand, remoted will run on both protocols at the same time. It will not bind a listener to a port on that protocol if there is no interface plumbed with that protocol when remoted starts up.

Are you using the open source OSSEC only? And if so, what version?

I have the version which was installed using the instructions from my initial post. How do I find from the command-line what version is installed?

It will not bind a listener to a port on that protocol if there is no interface plumbed with that protocol when remoted starts up.

You keep mentioning this.. but as testing indicates, IPv4 is enabled on the interface. Are you telling me that remoted can be started by choosing specific protocol(s)?

I did test with IPv6 disabled, and to my surprise, remoted actually did bind itself to IPv4 after restarting its service, so I am confused as to why this would be occurring.

I have the version which was installed using the instructions from my initial post. How do I find from the command-line what version is installed?

Just query the operating system software management system, for example:

rpm -qa ossec*

For example:

[mshinn@threat ~]$ rpm -qa ossec*
ossec-hids-4.2.2-13258.el7.art.x86_64
ossec-hids-mysql-4.2.2-13258.el7.art.x86_64
ossec-hids-server-4.2.2-13258.el7.art.x86_64
[mshinn@threat ~]$

Are you telling me that remoted can be started by choosing specific protocol(s)?

I'm not sure I understand your question, if youre asking can remoted run on both protocols at the same time, yes it can:

[root@threat ~]# netstat -anlpu | grep remoted
udp 0 0 0.0.0.0:1514 0.0.0.0:* 17915/ossec-remoted
udp6 0 0 :::1514 :::* 17915/ossec-remoted

[root@localhost ~]# rpm -qa ossec*
ossec-hids-3.6.0-11279.el8.art.x86_64
ossec-hids-server-3.6.0-11279.el8.art.x86_64
[root@localhost ~]# netstat -anlpu | grep remoted
udp6 0 0 192.168.1.60:1514 :::* 2608/ossec-remoted

Think I'm about to give up at this point. Appreciate your time and assistance.

OK, I see whats going on, your system is using the old 3.x open source branch, there a bug in the branch for remoted. You'll want to upgrade to the 4.x branch.

Ok, what's my best pathway to upgrade?

The 4.0 RPMs are available here:

https://updates.atomicorp.com/channels/ossec-hub-repo/

And the 4.2.x RPMs are available here:

https://updates.atomicorp.com/channels/awp-hub-repo/

https://updates.atomicorp.com/channels/ossec-hub-repo/

Asking for a username and password.

I have the same problem. Is this issue fixed in the open source (or the OSSEC+) version?

I can see a potential fix in the pull requests btw: https://github.com/ossec/ossec-hids/pull/1880

Thanks,
Matz