Hmm. 514/udp is the syslog listener. All I can think is the install is wrong 
somehow, since as a server it should open 1514/udp, but it is not. It looks 
like a "local" install rather than a "server" install. 

I think you should reinstall, making sure to reply "server" to the question 
"What kind of installation do you want (server, agent, local or help)?".

-- 
Shane Castle
Data Security Mgr, Boulder County IT
CISSP GSEC GCIH

-----Original Message-----
From: [email protected] [mailto:[email protected]] On 
Behalf Of Patrick Melvin
Sent: Wednesday, January 05, 2011 08:00
To: [email protected]
Subject: Re: [ossec-list] ossec-remoted not binding to 1514/udp?

Hi Shane, thanks for the response.

Below is the output of the 2nd command you listed, unfortunatly, like
netstat, there are no 1514 entries:

$ sudo lsof -P -a -i -c ossec-remoted
lsof: WARNING: can't stat() fuse.gvfs-fuse-daemon file system
/home/<user_account>/.gvfs
      Output information may be incomplete.
COMMAND     PID   USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
ossec-rem 18455 ossecr    4u  IPv4 467430      0t0  UDP *:514


And you are correct, when I mentioned logs, it was
/var/ossec/logs/ossec.log and no failure messages are being reported.

When you ran the command, did you have a 514 entry?  If not, do I have
something incorrect in my ossec.conf file that is causing remoted to
try to bind to 514/udp (syslog) instead of 1514/udp?

Thanks,
Patrick


On Tue, Jan 4, 2011 at 3:21 PM, Castle, Shane <[email protected]> wrote:
> Um. "lsof -P -c ossec-remoted" ? There should be a line like this:
>
> ossec-rem 3378 ossecr    4u  IPv4  11436       UDP *:1514
>
> which you should be able to get by being a bit more restrictive:
>
> # lsof -P -a -i -c ossec-remoted
> COMMAND    PID   USER   FD   TYPE DEVICE SIZE NODE NAME
> ossec-rem 3378 ossecr    4u  IPv4  11436       UDP *:1514
>
> Also, you say you checked logs. This includes /var/ossec/logs/ossec.log
> too? That's where OSSSEC puts all its info, including any failure
> messages.
>
> --
> Shane Castle
> Data Security Mgr, Boulder County IT
> CISSP GSEC GCIH
>
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> On Behalf Of Patrick Melvin
> Sent: Tuesday, January 04, 2011 14:02
> To: [email protected]
> Subject: [ossec-list] ossec-remoted not binding to 1514/udp?
>
> 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>
>
>  <remote>
>    <connection>secure</connection>
>    <allowed-ips>192.168.0.0/16</allowed-ips>
>    <port>1514</port>
>    <local_ip>(server_ip_address)</local_ip>
>  </remote>
>
>
> 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
>

Reply via email to