One last weird update...it was at 1342 agents.  Added 1 to bring the
total to 1343 and it was working then the process died.  Now when I
restart ossec, I'm back to where I was before where ossec-remoted
isn't running:

2011/01/05 16:08:03 ossec-remoted: DEBUG: Starting ...
2011/01/05 16:08:03 ossec-remoted: INFO: Started (pid: 9045).
2011/01/05 16:08:03 ossec-remoted: DEBUG: Forking remoted: '0'.


$ ps -ef | grep remoted
<blank>


On Wed, Jan 5, 2011 at 2:23 PM, Patrick Melvin <[email protected]> wrote:
> Hi Dan, thanks for the response.  I was running into issues that
> remoted would complain about not having an IP address in the remote
> section (with that said, on my CentOS5 setup, the remote section is
> left as default and it runs fine...another issue isolated to Ubuntu?)
>
> ossec-remoted(1501): ERROR: No IP or network allowed in the access
> list for syslog. No reason for running it. Exiting.
>
> Once I added the IP, it went away.  I'll get the port removed, was
> grasping at straws when I added it ;)
> After retesting what you stated, I see that the error was specifically
> for the syslog section (even though it went away when it was added to
> either the syslog or secure section).  I'll remove syslog from the
> configuration files going forward.
>
> Anyways, on to the Ubuntu issue:
>
> In the logs file, when debug is enabled, this is all I get when it
> fails to start up and bind to 1514/udp:
> (Note: This is what the output looks like when the remote syslog
> section is still included in the ossec.conf.  When working correctly,
> it shows 2 remoted processes)
>
> 2011/01/05 14:45:12 ossec-remoted: DEBUG: Starting ...
> 2011/01/05 14:45:12 ossec-remoted: INFO: Started (pid: 4255).
> 2011/01/05 14:45:12 ossec-remoted: DEBUG: Forking remoted: '0'.
> 2011/01/05 14:45:12 ossec-remoted: Remote syslog allowed from: 
> '192.168.0.0/16'
> 2011/01/05 14:45:12 ossec-remoted: DEBUG: Forking remoted: '1'.
>
> $ ps -ef | grep remoted
> ossecr    4256     1  0 14:45 ?        00:00:00 /var/ossec/bin/ossec-remoted 
> -d
>
>
> $ sudo lsof -P -a -i -c ossec-remoted
> COMMAND    PID   USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
> ossec-rem 4256 ossecr    4u  IPv4  19255      0t0  UDP *:514
>
>
> (This is the output when remote syslog section is removed from ossec.conf)
>
> 2011/01/05 14:56:22 ossec-remoted: DEBUG: Starting ...
> 2011/01/05 14:56:22 ossec-remoted: INFO: Started (pid: 4765).
> 2011/01/05 14:56:22 ossec-remoted: DEBUG: Forking remoted: '0'.
>
> $ ps -ef | grep remoted
> <blank>
>
> $ sudo lsof -P -a -i -c ossec-remoted
> <blank>
>
>
> When I delete an agent from client.keys and (in this case) go back
> down to 1015, these are the outputs:
>
> 2011/01/05 15:03:16 ossec-remoted: DEBUG: Starting ...
> 2011/01/05 15:03:16 ossec-remoted: INFO: Started (pid: 5350).
> 2011/01/05 15:03:16 ossec-remoted: DEBUG: Forking remoted: '0'.
>
>
> $ ps -ef | grep remoted
> ossecr    5351     1  0 15:03 ?        00:00:00 /var/ossec/bin/ossec-remoted 
> -d
>
>
> $ sudo lsof -P -a -i -c ossec-remoted
> COMMAND    PID   USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
> ossec-rem 5351 ossecr    4u  IPv4  23036      0t0  UDP *:1514
>
>
> Now I'm really confused.  I went through the tests above, and put the
> original client.keys file in place (1300+ agents), and it's working
> now. Just replaced the original configuration file settings (as stated
> in the start of the email) and it still works.
>
> I'm really at a loss...
>
> Thanks in advance,
> Patrick
>
>
> On Wed, Jan 5, 2011 at 1:06 PM, dan <[email protected]> wrote:
>> Hi Patrick,
>>
>> On Tue, Jan 04, 2011 at 03:01:30PM -0600, Patrick Melvin wrote:
>>> Hello,
>>>
>>> I believe I'm having an issue with ossec-remoted binding to port 1514/udp.
>>>
>>>
>>> ** Basic Configuration/OS Information **
>>>
>>> OS: Linux <server_name> 2.6.32-27-server #49-Ubuntu SMP Thu Dec 2
>>> 02:05:21 UTC 2010 x86_64 GNU/Linux
>>> ossec: 2.5.1
>>>
>>> make setmaxagents
>>> Specify maximum number of agents: 4096
>>> ./install.sh
>>>
>>> /etc/security/limits.conf have the following entries (and server was
>>> restarted afterwards):
>>> *     soft    nofile  4096
>>> *     hard    nofile  4096
>>>
>>>
>>> ** Issue Description **
>>>
>>> As stated, it appears that while ossec-remoted is running, it is not
>>> binding to 1514/udp.  I've been troubleshooting this and have not been
>>> able to get any helpful information out of the logs, debug mode, or
>>> stracing the process.
>>>
>>>
>>> When I run a tcpdump, I see the agents trying to connect to the server
>>> on 1514/udp, but the server responds back with the following:
>>>
>>> ICMP <server_ip> udp port 1514 unreachable, length 109
>>>
>>> Which indicates there's no process listening on the port. netstat does
>>> not show 1514 in use.
>>>
>>>
>>> I verified 1514/udp connectivity by utilizing netcat (nc) and
>>> successfully connected to the server on 1514/udp.
>>>
>>>
>>> strace show's the following for ossec-remoted:
>>> recvfrom(4,
>>>
>>>
>>> I have the following in ossec.conf with relation to remoted:
>>>   <remote>
>>>     <connection>syslog</connection>
>>>   </remote>
>>>
>>
>> Are you using OSSEC to collect syslog messages? If not, you don't need
>> this. If you are using it, put it after the secure connection type, and
>> add allowed-ips.
>>
>>>   <remote>
>>>     <connection>secure</connection>
>>>     <allowed-ips>192.168.0.0/16</allowed-ips>
>>>     <port>1514</port>
>>>     <local_ip>(server_ip_address)</local_ip>
>>>   </remote>
>>>
>>
>> You shouldn't need the allowed-ips in the secure section, I think it's
>> only for syslog. You also don't need to put the port in there if you're
>> using the default.
>>
>>>
>>> If there's any addtional information that might be helpful, please let me 
>>> know.
>>>
>>> I've been researching using google but have found no resolutions to
>>> this specific problem.  Any ideas?
>>>
>>> Thanks in advance,
>>> Patrick
>>
>> Look for entries for ossec-remoted in /var/ossec/logs/ossec.log. You may
>> need to enable debugging for that daemon (run it with the -d flag) to
>> get something more useful.
>>
>> I'm currently using both syslog and secure on one of my servers, so it
>> is possible. I haven't tried it with so many clients though.
>>
>> dan
>>
>

Reply via email to