Hi Chris,

since you compiled the project with "TARGET=server", maybe you chose 
"local" when installed it. A local installation is a profile like a server 
but without Remoted, that's why that daemon doesn't start with "ossec-control 
start".

The line at ossec-init.conf has only informational purposes, changing it 
will be useless. The local profile compiles OSSEC with option "TARGET=local", 
copies the script at "src/init/ossec-local.sh" as "
/var/ossec/bin/ossec-control" and applies a local setting template (without 
<remote> configuration, for example).

The best option would be to uninstall OSSEC, clean the compilation (make 
clean) and re-install it. If you can't uninstall it, these steps may help 
you:

   1. Change to the "Wazuh" directory.
   2. Clean the project: make -C src clean
   3. Compile and install again: make -C src TARGET=server install
   4. Create a default remote setting on /var/ossec/etc/ossec.conf:
   
   <ossec_config>
     <!-- (...) -->
   
     *<remote>*
   *    <connection>secure</connection>*
   *  </remote>*
   
     <!-- (...) -->
   </ossec_config>
   
   5. Restart OSSEC: /var/ossec/bin/ossec-control restart
   
This may fix your problem.

Best regards.



On Monday, December 12, 2016 at 7:11:07 PM UTC+1, Chris Decker wrote:
>
> Victor,
>
> ossec-init.conf is showing the the installation is a *local* installation.
>
> However, I know that I performed a server installation per my notes and 
> bash history…
>
> make clean
>
> make TARGET=server
>
>
>
> Obviously I could change this value back to 'server', but will this fix 
> the issue?
>
>
>
> Thanks,
> Chris
>
>
> On Saturday, December 10, 2016 at 6:04:45 AM UTC-5, Victor Fernandez wrote:
>>
>> Hi Chris,
>>
>> as you guessed, there is one *remoted* process for each <remote> 
>> configuration. Although it's strange that "ossec-control stop" does stop 
>> the *remoted *processes but "ossec-control start" doesn't run them.
>>
>> How did you install Wazuh? Please make sure that the file "
>> /var/ossec/etc/ossec-init.conf" has the line:
>>
>> TYPE="server"
>>
>>
>> Regards.
>>
>>
>> On Friday, December 9, 2016 at 5:24:38 PM UTC+1, Chris Decker wrote:
>>>
>>> Dan,
>>>
>>> Thanks for your help.
>>>
>>> Is ossec-remoted listed in the DAEMONS variable in the script?
>>>>
>>> It was *not*, but I added it after noticing it wasn't in there.  If I 
>>> tell ossec-control to stop, remoted stops as expected:
>>>
>>> [root@logger01 limits.d]# /var/ossec/bin/ossec-control stop
>>> Killing ossec-monitord .. 
>>> Killing ossec-logcollector .. 
>>> Killing ossec-syscheckd .. 
>>> Killing ossec-analysisd .. 
>>> Killing ossec-maild .. 
>>> Killing ossec-remoted .. 
>>> Killing ossec-execd .. 
>>> Wazuh v1.2 Stopped
>>>
>>>
>>> However, if I tell ossec-control to start, it starts everything but I 
>>> don't see remoted referenced:
>>> [root@logger01 limits.d]# /var/ossec/bin/ossec-control start
>>>
>>> Starting Wazuh v1.2 (maintained by Wazuh Inc.)...
>>> Started wazuh-moduled...
>>> Started ossec-maild...
>>> Started ossec-execd...
>>> Started ossec-analysisd...
>>> Started ossec-logcollector...
>>> 2016/12/09 11:22:51 rootcheck: Rootcheck disabled. Exiting.
>>> 2016/12/09 11:22:51 ossec-syscheckd: WARN: Rootcheck module disabled.
>>> Started ossec-syscheckd...
>>> Started ossec-monitord...
>>> Completed.
>>>
>>>
>>> The only thing I *removed* from that list of modules was the 
>>> ossec-wuzuh module because I do not currently use it.
>>>  
>>>
>>>> What is your remote condiguration in your ossec.conf?
>>>
>>>  
>>>  <remote>
>>>     <connection>secure</connection>
>>>   </remote>
>>>
>>>
>>>   <remote>
>>>     <connection>syslog</connection>
>>>     <protocol>tcp</protocol>
>>>     <port>514</port>
>>>     <allowed-ips>10.0.0.0/8</allowed-ips>
>>>   </remote>
>>>   <remote>
>>>     <connection>syslog</connection>
>>>     <protocol>udp</protocol>
>>>     <port>514</port>
>>>     <allowed-ips>10.0.0.0/8</allowed-ips>
>>>   </remote> 
>>>
>>> Dave's comment jogged my memory about why remoted is running 3 separate 
>>> processes - 1514/udp, 514/udp and 514/tcp.
>>>
>>>
>>>
>>> On Friday, December 9, 2016 at 10:33:50 AM UTC-5, dan (ddpbsd) wrote:
>>>>
>>>>
>>>>
>>>> On Dec 9, 2016 9:17 AM, "Chris Decker" <ch...@chris-decker.com> wrote:
>>>>
>>>> Victor,
>>>>
>>>> On Friday, December 9, 2016 at 6:42:27 AM UTC-5, Victor Fernandez wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> Agents should send a keepalive each 10 minutes (600 seconds) by 
>>>>> default, and this should be enough. But you can go down that time at the 
>>>>> agent's ossec.conf:
>>>>>
>>>>>
>>>>> <ossec_config>
>>>>>    <client>
>>>>>       <server-ip>1.2.3.4</server-ip>
>>>>>       *<notify_time>60</notify_time>*
>>>>>    </client>
>>>>>
>>>>>
>>>>> If you see any agent disconnected, check its ossec.log file.
>>>>>
>>>>> On the other hand, as Dan says, the manager will discard two identical 
>>>>> consecutive messages, so you should generate different messages for the 
>>>>> logs (using a random string or the date).
>>>>>
>>>> These events were from auditd and were unique enough that OSSEC should 
>>>> treat them as such. 
>>>>
>>>>
>>>> Sorry, I thought you wrote that the logs were the same.
>>>>
>>>>
>>>>
>>>>> If you think that there could be network congestion, you may try to 
>>>>> connect using TCP, adding, at the agent's ossec.conf:
>>>>>
>>>>> <ossec_config>
>>>>>    <client>
>>>>>       <server-ip>1.2.3.4</server-ip>
>>>>>       *<protocol>tcp</protocol>*
>>>>>    </client>
>>>>>
>>>>> And, on the manager's ossec.conf:
>>>>>
>>>>> <ossec_config>
>>>>>   <remote>
>>>>>     <connection>secure</connection>
>>>>>     *<protocol>tcp</protocol>*
>>>>>   </remote>
>>>>>
>>>>> I'm going to give this a try.
>>>>
>>>> One thing I've noticed is that the ossec-control script isn't starting 
>>>> up remoted.  If I start remoted by hand it starts, but then I see 3 
>>>> remoted 
>>>> processes.  I've never come across this issue before.  Do you know what 
>>>> could be causing it?
>>>>
>>>>
>>>>
>>>> Is ossec-remoted listed in the DAEMONS variable in the script?
>>>> What is your remote condiguration in your ossec.conf?
>>>>
>>>>
>>>>> Please test it and write back to us if this doesn't solve the problem. 
>>>>> All feedback is welcome.
>>>>>
>>>>> Hope it helps.
>>>>> Best regards.
>>>>>
>>>>>
>>>>> On Friday, December 9, 2016 at 6:30:08 AM UTC+1, dan (ddpbsd) wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Dec 8, 2016 4:41 PM, "Chris Decker" <ch...@chris-decker.com> 
>>>>>> wrote:
>>>>>>
>>>>>> All,
>>>>>>
>>>>>> I have an OSSEC instance (running the latest/greatest Wuzuh code 
>>>>>> cloned from GitHub) that has about 1k active hosts.  I've noticed 
>>>>>> recently 
>>>>>> that hosts are flipping back and forth between *Active* and 
>>>>>> *Disconnected*.
>>>>>>
>>>>>>
>>>>>> Perhaps the manager is too busy? I can't remember the host limit 
>>>>>> offhand, but I believe ossec limits the number of agents to a number 
>>>>>> smaller than 1000.
>>>>>>
>>>>>>
>>>>>> I've also noticed that not all of the log messages from "*Active" *hosts 
>>>>>> are being received by the Manager.  For example, I have an agent that 
>>>>>> generates the same log message every second.  I have debug enabled on 
>>>>>> the 
>>>>>> Agent and I can see logcollector reading each message, but only 
>>>>>> *some* of the messages are received on the Manager (I monitored it 
>>>>>> for awhile and it's not that the messages show up later due to network 
>>>>>> congestion--I don't see the messages ever being received).  I tried 
>>>>>> disabling the agent ID checks on both the Manager and Agent but that 
>>>>>> didn't 
>>>>>> have any impact.
>>>>>>
>>>>>>
>>>>>> Ossec will discard some repeated messages. I forget the timeframe 
>>>>>> offhand though.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I suspect there is a misconfiguration or limit I am running into on 
>>>>>> my Manager running RHEL 7, but I haven't been able to track it down.  I 
>>>>>> did 
>>>>>> a simple netcat test between the same two hosts and there was no lag in 
>>>>>> transmissions.
>>>>>>
>>>>>> Any suggestions/thoughts from the community?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Chris
>>>>>>
>>>>>> -- 
>>>>>>
>>>>>> --- 
>>>>>> 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.
>>>>>>
>>>>>>
>>>>>> -- 
>>>>
>>>> --- 
>>>> 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.
>>>>
>>>>
>>>>

-- 

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