Hi Shane, thanks for the help and sorry it's taken a bit to get back to you. I've been running through ideas for the past few hours and finally narrowed down the problem by trial and error. Unfortunately, I'm not sure how to fix it.
The original client.keys file I was working with had 1300+ agents listed, and as stated, remoted wasn't listening on 1514/udp. I started over with 1 agent, and found that 2 processes of remoted would start up and one of them was listening on 1514/udp (while the other was listening on 514/udp). I know that there's a file open limit default of 1024, so I guessed that maybe that was still the issue. I put the client.keys file in place with 1024 agents. ossec-remoted would not listen on 1514/udp. Through some trial and error, found that 1015 (and sometimes 1016) was my magic limit. Anything higher than this in the client.keys file, would cause ossec-remoted to not listen on 1514/udp (i.e. that 2nd instance of remoted would start up and end immediately). I verified that root and all user accounts have a openfile limit of 4096. I haven't been able to adjust sysctl's variable kern.maxfiles, because it doesn't exist (on Ubuntu or CentOS5). With that said, I went through the same steps on CentOS5, and remoted starts up and listens on 1514/udp with 1300+ agents in client.keys. It appears the issue is isolated to Ubuntu. Is there another variable or setting that is set to 1024 that is not allowing me to run ossec with more than 1015 agents? Thanks, Patrick On Wed, Jan 5, 2011 at 11:17 AM, Castle, Shane <[email protected]> wrote: > Also: check your ossec.conf <remote> section, and check it against the info > here: > http://www.ossec.net/doc/syntax/head_ossec_config.remote.html > > -- > Shane Castle > Data Security Mgr, Boulder County IT > CISSP GSEC GCIH > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Castle, Shane > Sent: Wednesday, January 05, 2011 10:02 > To: [email protected] > Subject: RE: [ossec-list] ossec-remoted not binding to 1514/udp? > > 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 >> >
