remoted not starting

[Joel Parker]

I have an ansible-ized install of ossec as a server, using the art rpm's to install (ossec-hids and ossec-hids-server). I have it working as expected on a server in our office, however when I run the same setup on a server in our remote data center I am unable to get remoted to stay running. Both of these servers started as centos 6.5 minimal installs.. both are x86_64.

Everything starts up, including remoted, but remoted then exits after it forks. From gdb:

Reading symbols from /var/ossec/bin/ossec-remoted...Reading symbols from /usr/lib/debug/var/ossec/bin/ossec-remoted.debug...done.

done.

(gdb) set follow-fork-mode child

(gdb) run -df

Starting program: /var/ossec/bin/ossec-remoted -df

[Thread debugging using libthread_db enabled]

2014/11/25 00:43:05 ossec-remoted: DEBUG: Starting ...

2014/11/25 00:43:05 ossec-remoted: INFO: Started (pid: 24882).

[New process 24885]

[Thread debugging using libthread_db enabled]

2014/11/25 00:43:05 ossec-remoted: DEBUG: Forking remoted: '0'.

2014/11/25 00:43:05 ossec-remoted: INFO: Started (pid: 24885).

2014/11/25 00:43:05 ossec-remoted: DEBUG: Running manager_init

[New Thread 0x7ffff75ea700 (LWP 24886)]

[New Thread 0x7ffff6be9700 (LWP 24887)]

2014/11/25 00:43:05 ossec-remoted: INFO: (unix_domain) Maximum send buffer set to: '124928'.

2014/11/25 00:43:05 ossec-remoted(4111): INFO: Maximum number of agents allowed: '256'.

2014/11/25 00:43:05 ossec-remoted(1410): INFO: Reading authentication keys file.

2014/11/25 00:43:05 ossec-remoted(1750): ERROR: No remote connection configured. Exiting.

[Thread 0x7ffff75ea700 (LWP 24886) exited]

[Thread 0x7ffff6be9700 (LWP 24887) exited]

ossec.log:

2014/11/25 00:43:05 ossec-remoted: DEBUG: Starting ...

2014/11/25 00:43:05 ossec-remoted: INFO: Started (pid: 24882).

2014/11/25 00:43:05 ossec-remoted: DEBUG: Forking remoted: '0'.

ossec.conf (I've tried every variation I can think of here, including removing all but the <secure> line. Removing the remote config entirely also has no affect on the above issue:

  <remote>

    <connection>secure</connection>

    <port>1514</port>

    <protocol>udp</protocol>

    <local_ip>192.168.3.11</local_ip>

  </remote>

So, what could be causing this? The same configuration works on my server that's local to me. I've grep'd through /var/ossec for any other mentions of "remote" that might be causing problems, and none exist. Searching for this gets me several people who have had the same error but they don't care because they aren't running ossec as a server.

Any guesses/thoughts on why remoted would fail to find the remote configuration would be huge. I've spent hours on this already.

[Colin Bruce]

Dear Joel,

 

What I am about to suggest is probably silly but have you configured an agent at the remote installation. If there are no agents installed then remoted stops as it has nothing to do. I see from your gdb output that it reads the authentication keys but I am not sure if it says that even when the keys file is empty.

 

Just a thought.

 

Best wishes…

Colin

--

---
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+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[dan (ddp)]

set follow-fork-mode child
or
run -df

> ossec.log:
> 2014/11/25 00:43:05 ossec-remoted: DEBUG: Starting ...
> 2014/11/25 00:43:05 ossec-remoted: INFO: Started (pid: 24882).
> 2014/11/25 00:43:05 ossec-remoted: DEBUG: Forking remoted: '0'.
>
> ossec.conf (I've tried every variation I can think of here, including
> removing all but the <secure> line. Removing the remote config entirely also
> has no affect on the above issue:
> <remote>
> <connection>secure</connection>
> <port>1514</port>
> <protocol>udp</protocol>

I think protocol only really does anything with the syslog transport.

> <local_ip>192.168.3.11</local_ip>
> </remote>
>
>
> So, what could be causing this? The same configuration works on my server
> that's local to me. I've grep'd through /var/ossec for any other mentions of
> "remote" that might be causing problems, and none exist. Searching for this
> gets me several people who have had the same error but they don't care
> because they aren't running ossec as a server.
>
> Any guesses/thoughts on why remoted would fail to find the remote
> configuration would be huge. I've spent hours on this already.
>

[Joel Parker]

On Tuesday, November 25, 2014 6:14:48 AM UTC-8, dan (ddpbsd) wrote:

On Mon, Nov 24, 2014 at 7:52 PM, Joel Parker <root...@gmail.com> wrote:
> (gdb) set follow-fork-mode child
> (gdb) run -df

set follow-fork-mode child
or
run -df

hmm??

 

> ossec.conf (I've tried every variation I can think of here, including
> removing all but the <secure> line. Removing the remote config entirely also
> has no affect on the above issue:
>   <remote>
>     <connection>secure</connection>
>     <port>1514</port>
>     <protocol>udp</protocol>

I think protocol only really does anything with the syslog transport.

good point. Though I do have protocol on my working server. 

[dan (ddp)]

On Tue, Nov 25, 2014 at 1:18 PM, Joel Parker <root...@gmail.com> wrote:
> On Tuesday, November 25, 2014 6:14:48 AM UTC-8, dan (ddpbsd) wrote:
>>
>> On Mon, Nov 24, 2014 at 7:52 PM, Joel Parker <root...@gmail.com> wrote:
>> > (gdb) set follow-fork-mode child
>> > (gdb) run -df
>>
>> set follow-fork-mode child
>> or
>> run -df
>
>
> hmm??
>

I missed that set that in your initial email.

>
>>
>> > ossec.conf (I've tried every variation I can think of here, including
>> > removing all but the <secure> line. Removing the remote config entirely
>> > also
>> > has no affect on the above issue:
>> > <remote>
>> > <connection>secure</connection>
>> > <port>1514</port>
>> > <protocol>udp</protocol>
>>
>> I think protocol only really does anything with the syslog transport.
>
>
> good point. Though I do have protocol on my working server.
>
>

[Joel Parker]

That was it. So, apparently, not only does ossec-remoted check for the existence of client.keys, but it also needs client.keys to be populated with at least one agent? The error, documentation, and results from searches all don't make that clear :(

thank you very much!

[Barry Kaplan]

Old post, sorry. I'm not sure I understand what to do in this case. Will remoted start again if an agent is registered some time after the server starts and remoted decides to shut down? 

[Santiago Bassett]

no, you need to restart the manager, after the first agent is added. Once that is done then you don't need to restart it anymore. You can actually insert a dummy agent, if you really need to have remoted running since the very beginning.

best

On Fri, Feb 19, 2016 at 5:16 PM, Barry Kaplan <mem...@gmail.com> wrote:

Old post, sorry. I'm not sure I understand what to do in this case. Will remoted start again if an agent is registered some time after the server starts and remoted decides to shut down? 

--

[James Le Cuirot]

Note that there is a pull request to fix this on GitHub. The initial attempt didn't work but the latest should.

https://github.com/ossec/ossec-hids/pull/662

[Barry Kaplan]

Well, I did what you did in the Dockerfile for OSSEC: Defined a dummy local agent. Ok for now, I'll watch for https://github.com/ossec/ossec-hids/pull/662.