[ossec-list] To block based on user

[Michael Clark]

I've been using OSSEC for a while, but only with the default rules. 
I've experimented, but just not understanding how to make a custom rule 
kick in when a loser tries guessing passwords to a non-existent user. 
Basically, if someone uses dovecot and tries a password for the user 
root (or admin, or adm, or a bunch of others that I frequently see) I 
want the IP blocked on the first request. Thanks, Mike

Re: [ossec-list] To block based on user

[dan (ddp)]

On Wed, Aug 22, 2012 at 6:18 AM, Michael Clark
6f0e8bfb03a6030e6bc5d69cc24da080.ossec-l...@planetmike.com wrote:
 I've been using OSSEC for a while, but only with the default rules.
 I've experimented, but just not understanding how to make a custom rule
 kick in when a loser tries guessing passwords to a non-existent user.
 Basically, if someone uses dovecot and tries a password for the user
 root (or admin, or adm, or a bunch of others that I frequently see) I
 want the IP blocked on the first request. Thanks, Mike



What have you tried?
How is your system currently configured?
Why do I have to ask all of these questions?
Is active response enabled on the agent and server?
Do you have log samples you can provide?
Do you really want this to work?
Why does the subject say block based on user when it seems like you
want to block an IP?
Are you sure you've tried?
Exactly what usernames do you want to cause a block on the first try?

Re: [ossec-list] clearing ossec db

[dan (ddp)]

On Tue, Aug 21, 2012 at 3:46 PM, Gil Vidals gvid...@gmail.com wrote:
 Dan,

 We have active response set to 1 hr, 1 day, 1 week, so assuming the IP is
 being blocked for one week and the iptables is reset in the middle of the
 week by the sysadmin, then the IP we thought was being blocked is actually
 not being blocked.

 Here is a clearer explanation:

 Monday - block for IP 1.1.1.1 starts for one week
 Tuesday - sysadmin clears iptables (no more block for 1.1.1.1)
 ...  - sysadmin has to wait until next monday before OSSEC will
 start blocking the desired IP again
 Monday - ossec clears block for 1.1.1.1



Yeah, I don't know where this info is kept on the server. You could
possibly try restarting the server processes to see if that helps.

I feel like it would be easier to just not lose that information in
the first place.

 Gil Vidals


 On Tue, Aug 21, 2012 at 12:00 PM, dan (ddp) ddp...@gmail.com wrote:

 On Tue, Aug 21, 2012 at 2:50 PM, Gil Vidals gvid...@gmail.com wrote:
  Dan,
 
  Can you tell me specifically what file to clear AND will this resolve
  the
  following condition:
 
  1) active response drops an IP as planned
  2) sysadmin restarts the firewall (which clears all the IP drop rules)
  3) ossec believes the drop is still in place, but it isn't!
 
  Gil Vidals
 

 I don't understand the problem in the above scenario. What are you
 trying to achieve specifically?

 Are you worried that the admin removed the block and OSSEC won't
 re-block it until after it's remove the block? Don't remove the block
 on the host. Or save the OSSEC blocked hosts and reload them when the
 firewall is reloaded. I don't know where that info is kept on the
 OSSEC server, possibly just in memory.

 
  On Tue, Aug 21, 2012 at 10:50 AM, dan (ddp) ddp...@gmail.com wrote:
 
  On Tue, Aug 21, 2012 at 1:37 PM, Gil Vidals gvid...@gmail.com wrote:
   How can I clear the ossec db for the active responses? I'm not using
   mysql
   for ossec. I have installed whatever the default db is.
  
   I don't need to clear the sys checks; instead I want to clear the
   active
   responses. Is there a way to do this?
  
   --
   Gil Vidals
  
   CONFIDENTIALITY NOTICE: The information contained in this
   transmission
   may
   contain privileged and confidential information.  It is intended only
   for
   the use of the person(s) named above.  If you are not the intended
   recipient, please contact the sender by reply email and permanently
   delete
   the original message.
  
 
  By default OSSEC only logs to text files. I guess you could stop the
  OSSEC processes, clear the file, and start OSSEC back up.
 
 
 
 
  --
  Gil Vidals
 
  CONFIDENTIALITY NOTICE: The information contained in this transmission
  may
  contain privileged and confidential information.  It is intended only
  for
  the use of the person(s) named above.  If you are not the intended
  recipient, please contact the sender by reply email and permanently
  delete
  the original message.
 




 --
 Gil Vidals

 CONFIDENTIALITY NOTICE: The information contained in this transmission may
 contain privileged and confidential information.  It is intended only for
 the use of the person(s) named above.  If you are not the intended
 recipient, please contact the sender by reply email and permanently delete
 the original message.

Re: [ossec-list] socketerr messages after restarting ossec, errors occur after the starting the rootcheck scan

[dan (ddp)]

On Tue, Aug 21, 2012 at 2:13 PM, Shaka Lewis shaka.le...@gmail.com wrote:
 The ossec processes running at this point are execd, logcollector, and 
 monitord.


 AnalysisD crashed and here is the output:

 Program received signal SIGSEGV, Segmentation fault.
 [Switching to process 26814]
 0x in ?? ()
 Missing separate debuginfos, use: debuginfo-install
 glibc-2.12-1.47.el6_2.12.x86_64
 (This version of glibc is already installed on the system)



You couldn't get a backtrace or anything on this?

 This is a server install and stopped working after migrating to new hardware.



Have you tried reinstalling/upgrading?

 On Tue, Aug 21, 2012 at 12:19 PM, dan (ddp) ddp...@gmail.com wrote:
 On Tue, Aug 21, 2012 at 11:19 AM, Shaka Lewis shaka.le...@gmail.com wrote:
 I ran the debug and here is the outupt

 2012/08/20 17:06:18 ossec-rootcheck: INFO: Ending rootcheck scan.
 2012/08/20 18:56:28 ossec-logcollector: socketerr (not available).
 2012/08/20 18:56:28 ossec-logcollector(1224): ERROR: Error sending
 message to queue.
 2012/08/20 18:56:29 ossec-logcollector: socketerr (not available).
 2012/08/20 18:56:29 ossec-logcollector(1224): ERROR: Error sending
 message to queue.
 2012/08/20 18:56:31 ossec-logcollector(1210): ERROR: Queue
 '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
 2012/08/20 18:56:31 ossec-logcollector(1211): ERROR: Unable to access
 queue: '/var/ossec/queue/ossec/queue'. Giving up..
 2012/08/20 18:56:32 ossec-logcollector(1210): ERROR: Queue
 '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
 2012/08/20 18:56:32 ossec-logcollector(1211): ERROR: Unable to access
 queue: '/var/ossec/queue/ossec/queue'. Giving up..
 2012/08/20 18:57:18 ossec-monitord: socketerr (not available).
 2012/08/20 18:57:18 ossec-monitord(1224): ERROR: Error sending message to 
 queue.
 2012/08/20 19:19:19 ossec-monitord: socketerr (not available).
 2012/08/20 19:19:19 ossec-monitord(1224): ERROR: Error sending message to 
 queue.
 2012/08/20 19:19:19 ossec-monitord: socketerr (not available).


 And what OSSEC processes are running at this point?
 Did you run analysisd in gdb? Did it crash? Is there a backtrace?

 I'll throw in some more questions, because I need some more to not be
 answered. Is this a server or a standalone installation? Has it ever
 worked? Did you change anything?


 On Mon, Aug 20, 2012 at 9:40 AM, dan (ddp) ddp...@gmail.com wrote:
 On Mon, Aug 20, 2012 at 9:38 AM, Shaka Lewis shaka.le...@gmail.com wrote:
 This is the error log in the ossec.log file when i restarted this morning

  ossec-logcollector(1950): INFO: Analyzing file:
 '/var/ossec/logs/alerts/alerts.log'.
 2012/08/20 09:29:30 ossec-logcollector: INFO: Started (pid: 10978).
 2012/08/20 09:29:50 ossec-logcollector: socketerr (not available).
 2012/08/20 09:29:50 ossec-logcollector(1224): ERROR: Error sending
 message to queue.
 2012/08/20 09:29:53 ossec-logcollector(1210): ERROR: Queue
 '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
 2012/08/20 09:29:53 ossec-logcollector(1211): ERROR: Unable to access
 queue: '/var/ossec/queue/ossec/queue'. Giving up..
 2012/08/20 09:30:31 ossec-syscheckd: INFO: Starting syscheck scan
 (forwarding database).
 2012/08/20 09:30:31 ossec-syscheckd: socketerr (not available).
 2012/08/20 09:30:31 ossec-syscheckd(1224): ERROR: Error sending
 message to queue.
 2012/08/20 09:30:34 ossec-syscheckd(1210): ERROR: Queue
 '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
 2012/08/20 09:30:34 ossec-syscheckd(1211): ERROR: Unable to access
 queue: '/var/ossec/queue/ossec/queue'. Giving up..


 This was in /var/log/messages

 kernel: ossec-analysisd[10974]: segfault at 0 ip (null) sp
 7fffe5ada2b8 error 14 in ossec-analysisd[40+62000]


 Try running ossec-analysisd in gdb to see if you can get more
 information from the crash.

 gdb ossec-analysisd
 set follow-fork-mode child
 run -d
 CRASH
 bt

 For a start


 On Mon, Aug 20, 2012 at 7:54 AM, dan (ddp) ddp...@gmail.com wrote:
 On Fri, Aug 17, 2012 at 5:29 PM, Shaka Lewis shaka.le...@gmail.com 
 wrote:
 I get the below errors after restarting ossec.  This is version 2.6
 running on a Linux machine

 2012/08/17 16:55:21 ossec-logcollector: socketerr (not available).
 2012/08/17 16:55:21 ossec-logcollector(1224): ERROR: Error sending
 message to queue.
 2012/08/17 16:55:24 ossec-logcollector(1210): ERROR: Queue
 '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
 2012/08/17 16:55:24 ossec-logcollector(1211): ERROR: Unable to access
 queue: '/var/ossec/queue/ossec/queue'. Giving up..
 2012/08/17 17:09:21 ossec-syscheckd: socketerr (not available).
 2012/08/17 17:09:21 ossec-rootcheck(1224): ERROR: Error sending
 message to queue.
 2012/08/17 17:09:24 ossec-syscheckd(1210): ERROR: Queue
 '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
 2012/08/17 17:09:24 ossec-rootcheck(1211): ERROR: Unable to access
 queue: 

Re: [ossec-list] Re: ossec-analysisd core dumps on Solaris 10

[dan (ddp)]

On Fri, Aug 17, 2012 at 7:56 PM, Jim jim.w.matth...@gmail.com wrote:
 Dan,

 Here is the backtrace from GDB, but I am not sure that tells much more than
 mdb had?


It's a tool I'm more familiar with. I don't get much of an opportunity
to use niche systems these days.

I'd consider tossing the following into log.c before the fprintf to
see if it gives anymore info;

 merror(_fflog,
%d %s %02d %s %s%s%s %s %s %s:%s-%s:%s\n,
lf-year,
lf-mon,
lf-day,
lf-hour,
lf-hostname != lf-location?lf-hostname:,
lf-hostname != lf-location?-:,
lf-location,
lf-action,
lf-protocol,
lf-srcip,
lf-srcport,
lf-dstip,
lf-dstport);


Also, do you have any rules or anything looking at the firewall logs?

Hopefully one of the actual developers will take a look at this and
just know what's going on.

 Program terminated with signal 11, Segmentation fault.
 #0  0xfed95b9c in strlen () from /usr/lib/libc.so.1
 (gdb) bt
 #0  0xfed95b9c in strlen () from /usr/lib/libc.so.1
 #1  0xfedf0f82 in _ndoprnt () from /usr/lib/libc.so.1
 #2  0xfedf3b09 in fprintf () from /usr/lib/libc.so.1
 #3  0x08076d0d in FW_Log (lf=0x81c0558) at log.c:261
 #4  0x08057530 in OS_ReadMSG (m_queue=6) at analysisd.c:860
 #5  0x08056f45 in main (argc=1, argv=0x8047dcc) at analysisd.c:527

 Any idea what is causing this?

 Thanks,


 --JIM

 On Thursday, August 16, 2012 8:54:43 AM UTC-4, dan (ddpbsd) wrote:

 On Thu, Aug 16, 2012 at 1:12 AM, Jim jim.w.m...@gmail.com wrote:
  Hello,
 
  Any further thoughts on fixing this core dump problem?
 
  Thanks,
 
 
  --JIM
 

 Is there any chance you can run it in gdb?

 gdb /var/ossec/bin/ossec-analysisd
 set follow-fork-mode child
 run
 *CRASH*
 bt


 There are probably other things you should be running in addition to
 bt, but I don't know it all that well.

 
  On Monday, August 13, 2012 7:41:39 PM UTC-4, Jim wrote:
 
  Here are the logs from the ossec.log, which was running in debug.
  Which
  reports until you can see analysisd core dumps.  IPs and hostnames have
  been
  changed from the original...
 
  2012/08/12 15:07:09 ossec-logcollector: DEBUG: Reading syslog message:
  'Aug 12 15:07:08 casrv9-hidn.local1 ipmon[123]: 15:07:07.674864 e1000g0
  @0:63 p 192.168.2.81,46618 - 192.168.2.205,994 PR tcp len 20 142 -AP
  IN'
  2012/08/12 15:07:09 ossec-logcollector: DEBUG: Reading syslog message:
  'Aug 12 15:07:08 casrv9-hidn.local1 ipmon[123]: 15:07:07.675807 e1000g0
  @0:63 p 192.168.2.81,46618 - 192.168.2.205,994 PR tcp len 20 52 -A IN'
  2012/08/12 15:07:09 ossec-logcollector: DEBUG: Reading syslog message:
  'Aug 12 15:07:08 batch.local1 batch kernel: VFS: busy inodes on changed
  media or resized disk hdb'
  2012/08/12 15:07:09 ossec-logcollector: DEBUG: Reading syslog message:
  'Aug 12 15:07:08 n58.local1 ntpd[2816]: kernel time sync enabled 0001'
  2012/08/12 15:07:09 ossec-logcollector: DEBUG: Reading syslog message:
  'Aug 12 15:07:09 n44.local1 smartd[2942]: Device: /dev/sda, 661
  Currently
  unreadable (pending) sectors '
  2012/08/12 15:07:11 ossec-logcollector: DEBUG: Reading syslog message:
  'Aug 12 15:07:10 FW1.local1 kernel: ACCEPTED IN=eth0 OUT=eth4
  SRC=192.168.1.200 DST=172.16.4.34 LEN=84 TOS=0x00 PREC=0x00 TTL=252
  ID=27140
  PROTO=ICMP TYPE=8 CODE=0 ID=16044 SEQ=0 '
  2012/08/12 15:07:11 ossec-logcollector: DEBUG: Reading syslog message:
  'Aug 12 15:07:10 batch.local1 batch kernel: VFS: busy inodes on changed
  media or resized disk hdb'
  2012/08/12 15:07:11 ossec-logcollector: DEBUG: Reading syslog message:
  'Aug 12 15:07:11 casrv9-hidn.local1 ipmon[123]: 15:07:10.875337 e1000g0
  @0:60 p 192.168.4.52,49168 - 192.168.2.205,6667 PR tcp len 20 72 -AP
  IN'
  2012/08/12 15:07:11 ossec-logcollector: DEBUG: Reading syslog message:
  'Aug 12 15:07:11 casrv9-hidn.local1 ipmon[123]: 15:07:10.876005 e1000g0
  @0:60 p 192.168.4.52,49168 - 192.168.2.205,6667 PR tcp len 20 52 -A
  IN'
  2012/08/12 15:07:11 ossec-logcollector: DEBUG: Reading syslog message:
  'Aug 12 15:07:11 casrv9-hidn.local1 ipmon[123]: 15:07:11.071610 e1000g0
  @0:63 p 192.168.2.127,56476 - 192.168.2.205,994 PR tcp len 20 142 -AP
  IN'
  2012/08/12 15:07:11 ossec-logcollector: DEBUG: Reading syslog message:
  'Aug 12 15:07:11 casrv9-hidn.local1 ipmon[123]: 15:07:11.074955 e1000g0
  @0:63 p 192.168.2.127,56476 - 192.168.2.205,994 PR tcp len 20 52 -A
  IN'
  2012/08/12 15:07:11 ossec-logcollector: DEBUG: Reading syslog message:
  'Aug 12 15:07:11 casrv9-hidn.local1 ipmon[123]: 15:07:11.140966 e1000g0
  @0:63 p 192.168.2.81,46618 - 192.168.2.205,994 PR tcp len 20 126 -AP
  IN'
  2012/08/12 15:07:11 ossec-logcollector: DEBUG: Reading syslog message:
  'Aug 12 15:07:11 casrv9-hidn.local1 ipmon[123]: 15:07:11.142122 e1000g0
  @0:63 p 192.168.2.81,46618 - 192.168.2.205,994 PR tcp len 20 52 -A IN'
  2012/08/12 15:07:13 ossec-logcollector: DEBUG: Reading syslog message:
  'Aug 

[ossec-list] Re: To block based on user

[dkoleary]

Hey;

While not a direct answer, I think I have the direction in which you want 
to go.  I've been reading the online manual (http://www.ossec.net/doc/) 
which has a section on cdb list lookups from within rules 
(http://www.ossec.net/doc/manual/rules-decoders/rule-lists.html).  Cdb is 
'constant database'; effectively a standalone perl hash, if you're familiar 
with perl.  

So, in english, what you want is a rule that will block IPs that are 
attempting access to the dovecot port with a user that is not in the list 
of valid users.  That is an excellent idea.  If you get the entire process 
worked out, let me know as I would like to do the same exact thing.  
Unfortunately, no time to work on it at the moment.

My understanding (which is probably inaccurate in some places)

* ossec.conf needs a line in the rules section similar to:


listrules/users/list


* You make a text file called rules/users formatted as:
${valid_user1}: 1
${valid_user2}: 1
${valid_user3}: 1
...

* You then run ossec-makelists

* Assuming all that works, you then create a rule with a line that looks 
something like:

list field=program_name lookup=not_match_keyrules/users/list


then use the active response if that rule triggers...

There's a *bunch* in there that needs work.  I'm very new to ossec myself 
but that seems like it'd be the right way to go. And, if not, someone more 
experienced will pipe up, call me all sorts of names, and tell us both the 
right way to do it :)

Hope that helps.

Doug O'Leary

Re: [ossec-list] Re: To block based on user

[dan (ddp)]

On Wed, Aug 22, 2012 at 9:29 AM, dkoleary dkole...@olearycomputers.com wrote:
 Hey;

 While not a direct answer, I think I have the direction in which you want to
 go.  I've been reading the online manual (http://www.ossec.net/doc/) which
 has a section on cdb list lookups from within rules
 (http://www.ossec.net/doc/manual/rules-decoders/rule-lists.html).  Cdb is
 'constant database'; effectively a standalone perl hash, if you're familiar
 with perl.

 So, in english, what you want is a rule that will block IPs that are
 attempting access to the dovecot port with a user that is not in the list of
 valid users.  That is an excellent idea.  If you get the entire process
 worked out, let me know as I would like to do the same exact thing.
 Unfortunately, no time to work on it at the moment.

 My understanding (which is probably inaccurate in some places)

 * ossec.conf needs a line in the rules section similar to:


 listrules/users/list


 * You make a text file called rules/users formatted as:
 ${valid_user1}: 1
 ${valid_user2}: 1
 ${valid_user3}: 1
 ...

 * You then run ossec-makelists

 * Assuming all that works, you then create a rule with a line that looks
 something like:

 list field=program_name lookup=not_match_keyrules/users/list


 then use the active response if that rule triggers...

 There's a *bunch* in there that needs work.  I'm very new to ossec myself
 but that seems like it'd be the right way to go. And, if not, someone more
 experienced will pipe up, call me all sorts of names, and tell us both the
 right way to do it :)

 Hope that helps.

 Doug O'Leary

That's where I would have gone with it. In fact, I have a
banned_user.cdb in one of my setups.

Re: [ossec-list] socketerr messages after restarting ossec, errors occur after the starting the rootcheck scan

[Shaka Lewis]

here is all I have from the latest debug:

2012/08/21 17:43:35 ossec-rootcheck: DEBUG: Going into check_rc_dev
2012/08/21 17:43:35 ossec-rootcheck: DEBUG: Starting on check_rc_dev
2012/08/21 17:43:36 ossec-rootcheck: DEBUG: Going into check_rc_sys
2012/08/21 17:43:36 ossec-rootcheck: DEBUG: Starting on check_rc_sys
2012/08/21 17:43:36 ossec-rootcheck: DEBUG: Going into check_rc_pids
2012/08/21 18:16:40 ossec-rootcheck: DEBUG: Going into check_rc_ports
2012/08/21 18:16:41 ossec-rootcheck: DEBUG: Going into check_open_ports
2012/08/21 18:16:41 ossec-rootcheck: DEBUG: Going into check_rc_if
2012/08/21 18:16:41 ossec-rootcheck: DEBUG: Completed with all checks.
2012/08/21 18:16:46 ossec-rootcheck: INFO: Ending rootcheck scan.
2012/08/21 18:16:46 ossec-rootcheck: DEBUG: Leaving run_rk_check
2012/08/21 19:22:09 ossec-logcollector: socketerr (not available).
2012/08/21 19:22:09 ossec-logcollector(1224): ERROR: Error sending
message to queue.
2012/08/21 19:22:12 ossec-logcollector(1210): ERROR: Queue
'/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
2012/08/21 19:22:12 ossec-logcollector(1211): ERROR: Unable to access
queue: '/var/ossec/queue/ossec/queue'. Giving up..
2012/08/21 19:31:30 ossec-monitord: socketerr (not available).

On Wed, Aug 22, 2012 at 7:45 AM, dan (ddp) ddp...@gmail.com wrote:
 On Tue, Aug 21, 2012 at 2:13 PM, Shaka Lewis shaka.le...@gmail.com wrote:
 The ossec processes running at this point are execd, logcollector, and 
 monitord.


 AnalysisD crashed and here is the output:

 Program received signal SIGSEGV, Segmentation fault.
 [Switching to process 26814]
 0x in ?? ()
 Missing separate debuginfos, use: debuginfo-install
 glibc-2.12-1.47.el6_2.12.x86_64
 (This version of glibc is already installed on the system)



 You couldn't get a backtrace or anything on this?

 This is a server install and stopped working after migrating to new hardware.



 Have you tried reinstalling/upgrading?

 On Tue, Aug 21, 2012 at 12:19 PM, dan (ddp) ddp...@gmail.com wrote:
 On Tue, Aug 21, 2012 at 11:19 AM, Shaka Lewis shaka.le...@gmail.com wrote:
 I ran the debug and here is the outupt

 2012/08/20 17:06:18 ossec-rootcheck: INFO: Ending rootcheck scan.
 2012/08/20 18:56:28 ossec-logcollector: socketerr (not available).
 2012/08/20 18:56:28 ossec-logcollector(1224): ERROR: Error sending
 message to queue.
 2012/08/20 18:56:29 ossec-logcollector: socketerr (not available).
 2012/08/20 18:56:29 ossec-logcollector(1224): ERROR: Error sending
 message to queue.
 2012/08/20 18:56:31 ossec-logcollector(1210): ERROR: Queue
 '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
 2012/08/20 18:56:31 ossec-logcollector(1211): ERROR: Unable to access
 queue: '/var/ossec/queue/ossec/queue'. Giving up..
 2012/08/20 18:56:32 ossec-logcollector(1210): ERROR: Queue
 '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
 2012/08/20 18:56:32 ossec-logcollector(1211): ERROR: Unable to access
 queue: '/var/ossec/queue/ossec/queue'. Giving up..
 2012/08/20 18:57:18 ossec-monitord: socketerr (not available).
 2012/08/20 18:57:18 ossec-monitord(1224): ERROR: Error sending message to 
 queue.
 2012/08/20 19:19:19 ossec-monitord: socketerr (not available).
 2012/08/20 19:19:19 ossec-monitord(1224): ERROR: Error sending message to 
 queue.
 2012/08/20 19:19:19 ossec-monitord: socketerr (not available).


 And what OSSEC processes are running at this point?
 Did you run analysisd in gdb? Did it crash? Is there a backtrace?

 I'll throw in some more questions, because I need some more to not be
 answered. Is this a server or a standalone installation? Has it ever
 worked? Did you change anything?


 On Mon, Aug 20, 2012 at 9:40 AM, dan (ddp) ddp...@gmail.com wrote:
 On Mon, Aug 20, 2012 at 9:38 AM, Shaka Lewis shaka.le...@gmail.com 
 wrote:
 This is the error log in the ossec.log file when i restarted this morning

  ossec-logcollector(1950): INFO: Analyzing file:
 '/var/ossec/logs/alerts/alerts.log'.
 2012/08/20 09:29:30 ossec-logcollector: INFO: Started (pid: 10978).
 2012/08/20 09:29:50 ossec-logcollector: socketerr (not available).
 2012/08/20 09:29:50 ossec-logcollector(1224): ERROR: Error sending
 message to queue.
 2012/08/20 09:29:53 ossec-logcollector(1210): ERROR: Queue
 '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
 2012/08/20 09:29:53 ossec-logcollector(1211): ERROR: Unable to access
 queue: '/var/ossec/queue/ossec/queue'. Giving up..
 2012/08/20 09:30:31 ossec-syscheckd: INFO: Starting syscheck scan
 (forwarding database).
 2012/08/20 09:30:31 ossec-syscheckd: socketerr (not available).
 2012/08/20 09:30:31 ossec-syscheckd(1224): ERROR: Error sending
 message to queue.
 2012/08/20 09:30:34 ossec-syscheckd(1210): ERROR: Queue
 '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
 2012/08/20 09:30:34 ossec-syscheckd(1211): ERROR: Unable to access
 queue: '/var/ossec/queue/ossec/queue'. Giving up..


 This was in 

Re: [ossec-list] socketerr messages after restarting ossec, errors occur after the starting the rootcheck scan

[dan (ddp)]

Since you don't seem too interested in fixing this, good luck.

On Wed, Aug 22, 2012 at 10:19 AM, Shaka Lewis shaka.le...@gmail.com wrote:
 here is all I have from the latest debug:

 2012/08/21 17:43:35 ossec-rootcheck: DEBUG: Going into check_rc_dev
 2012/08/21 17:43:35 ossec-rootcheck: DEBUG: Starting on check_rc_dev
 2012/08/21 17:43:36 ossec-rootcheck: DEBUG: Going into check_rc_sys
 2012/08/21 17:43:36 ossec-rootcheck: DEBUG: Starting on check_rc_sys
 2012/08/21 17:43:36 ossec-rootcheck: DEBUG: Going into check_rc_pids
 2012/08/21 18:16:40 ossec-rootcheck: DEBUG: Going into check_rc_ports
 2012/08/21 18:16:41 ossec-rootcheck: DEBUG: Going into check_open_ports
 2012/08/21 18:16:41 ossec-rootcheck: DEBUG: Going into check_rc_if
 2012/08/21 18:16:41 ossec-rootcheck: DEBUG: Completed with all checks.
 2012/08/21 18:16:46 ossec-rootcheck: INFO: Ending rootcheck scan.
 2012/08/21 18:16:46 ossec-rootcheck: DEBUG: Leaving run_rk_check
 2012/08/21 19:22:09 ossec-logcollector: socketerr (not available).
 2012/08/21 19:22:09 ossec-logcollector(1224): ERROR: Error sending
 message to queue.
 2012/08/21 19:22:12 ossec-logcollector(1210): ERROR: Queue
 '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
 2012/08/21 19:22:12 ossec-logcollector(1211): ERROR: Unable to access
 queue: '/var/ossec/queue/ossec/queue'. Giving up..
 2012/08/21 19:31:30 ossec-monitord: socketerr (not available).

 On Wed, Aug 22, 2012 at 7:45 AM, dan (ddp) ddp...@gmail.com wrote:
 On Tue, Aug 21, 2012 at 2:13 PM, Shaka Lewis shaka.le...@gmail.com wrote:
 The ossec processes running at this point are execd, logcollector, and 
 monitord.


 AnalysisD crashed and here is the output:

 Program received signal SIGSEGV, Segmentation fault.
 [Switching to process 26814]
 0x in ?? ()
 Missing separate debuginfos, use: debuginfo-install
 glibc-2.12-1.47.el6_2.12.x86_64
 (This version of glibc is already installed on the system)



 You couldn't get a backtrace or anything on this?

 This is a server install and stopped working after migrating to new 
 hardware.



 Have you tried reinstalling/upgrading?

 On Tue, Aug 21, 2012 at 12:19 PM, dan (ddp) ddp...@gmail.com wrote:
 On Tue, Aug 21, 2012 at 11:19 AM, Shaka Lewis shaka.le...@gmail.com 
 wrote:
 I ran the debug and here is the outupt

 2012/08/20 17:06:18 ossec-rootcheck: INFO: Ending rootcheck scan.
 2012/08/20 18:56:28 ossec-logcollector: socketerr (not available).
 2012/08/20 18:56:28 ossec-logcollector(1224): ERROR: Error sending
 message to queue.
 2012/08/20 18:56:29 ossec-logcollector: socketerr (not available).
 2012/08/20 18:56:29 ossec-logcollector(1224): ERROR: Error sending
 message to queue.
 2012/08/20 18:56:31 ossec-logcollector(1210): ERROR: Queue
 '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
 2012/08/20 18:56:31 ossec-logcollector(1211): ERROR: Unable to access
 queue: '/var/ossec/queue/ossec/queue'. Giving up..
 2012/08/20 18:56:32 ossec-logcollector(1210): ERROR: Queue
 '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
 2012/08/20 18:56:32 ossec-logcollector(1211): ERROR: Unable to access
 queue: '/var/ossec/queue/ossec/queue'. Giving up..
 2012/08/20 18:57:18 ossec-monitord: socketerr (not available).
 2012/08/20 18:57:18 ossec-monitord(1224): ERROR: Error sending message to 
 queue.
 2012/08/20 19:19:19 ossec-monitord: socketerr (not available).
 2012/08/20 19:19:19 ossec-monitord(1224): ERROR: Error sending message to 
 queue.
 2012/08/20 19:19:19 ossec-monitord: socketerr (not available).


 And what OSSEC processes are running at this point?
 Did you run analysisd in gdb? Did it crash? Is there a backtrace?

 I'll throw in some more questions, because I need some more to not be
 answered. Is this a server or a standalone installation? Has it ever
 worked? Did you change anything?


 On Mon, Aug 20, 2012 at 9:40 AM, dan (ddp) ddp...@gmail.com wrote:
 On Mon, Aug 20, 2012 at 9:38 AM, Shaka Lewis shaka.le...@gmail.com 
 wrote:
 This is the error log in the ossec.log file when i restarted this 
 morning

  ossec-logcollector(1950): INFO: Analyzing file:
 '/var/ossec/logs/alerts/alerts.log'.
 2012/08/20 09:29:30 ossec-logcollector: INFO: Started (pid: 10978).
 2012/08/20 09:29:50 ossec-logcollector: socketerr (not available).
 2012/08/20 09:29:50 ossec-logcollector(1224): ERROR: Error sending
 message to queue.
 2012/08/20 09:29:53 ossec-logcollector(1210): ERROR: Queue
 '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
 2012/08/20 09:29:53 ossec-logcollector(1211): ERROR: Unable to access
 queue: '/var/ossec/queue/ossec/queue'. Giving up..
 2012/08/20 09:30:31 ossec-syscheckd: INFO: Starting syscheck scan
 (forwarding database).
 2012/08/20 09:30:31 ossec-syscheckd: socketerr (not available).
 2012/08/20 09:30:31 ossec-syscheckd(1224): ERROR: Error sending
 message to queue.
 2012/08/20 09:30:34 ossec-syscheckd(1210): ERROR: Queue
 '/var/ossec/queue/ossec/queue' not accessible: 

Re: [ossec-list] socketerr messages after restarting ossec, errors occur after the starting the rootcheck scan

[Shaka Lewis]

Not sure what you mean, I have run all the debug commands you requested.

On Wed, Aug 22, 2012 at 10:33 AM, dan (ddp) ddp...@gmail.com wrote:
 Since you don't seem too interested in fixing this, good luck.

 On Wed, Aug 22, 2012 at 10:19 AM, Shaka Lewis shaka.le...@gmail.com wrote:
 here is all I have from the latest debug:

 2012/08/21 17:43:35 ossec-rootcheck: DEBUG: Going into check_rc_dev
 2012/08/21 17:43:35 ossec-rootcheck: DEBUG: Starting on check_rc_dev
 2012/08/21 17:43:36 ossec-rootcheck: DEBUG: Going into check_rc_sys
 2012/08/21 17:43:36 ossec-rootcheck: DEBUG: Starting on check_rc_sys
 2012/08/21 17:43:36 ossec-rootcheck: DEBUG: Going into check_rc_pids
 2012/08/21 18:16:40 ossec-rootcheck: DEBUG: Going into check_rc_ports
 2012/08/21 18:16:41 ossec-rootcheck: DEBUG: Going into check_open_ports
 2012/08/21 18:16:41 ossec-rootcheck: DEBUG: Going into check_rc_if
 2012/08/21 18:16:41 ossec-rootcheck: DEBUG: Completed with all checks.
 2012/08/21 18:16:46 ossec-rootcheck: INFO: Ending rootcheck scan.
 2012/08/21 18:16:46 ossec-rootcheck: DEBUG: Leaving run_rk_check
 2012/08/21 19:22:09 ossec-logcollector: socketerr (not available).
 2012/08/21 19:22:09 ossec-logcollector(1224): ERROR: Error sending
 message to queue.
 2012/08/21 19:22:12 ossec-logcollector(1210): ERROR: Queue
 '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
 2012/08/21 19:22:12 ossec-logcollector(1211): ERROR: Unable to access
 queue: '/var/ossec/queue/ossec/queue'. Giving up..
 2012/08/21 19:31:30 ossec-monitord: socketerr (not available).

 On Wed, Aug 22, 2012 at 7:45 AM, dan (ddp) ddp...@gmail.com wrote:
 On Tue, Aug 21, 2012 at 2:13 PM, Shaka Lewis shaka.le...@gmail.com wrote:
 The ossec processes running at this point are execd, logcollector, and 
 monitord.


 AnalysisD crashed and here is the output:

 Program received signal SIGSEGV, Segmentation fault.
 [Switching to process 26814]
 0x in ?? ()
 Missing separate debuginfos, use: debuginfo-install
 glibc-2.12-1.47.el6_2.12.x86_64
 (This version of glibc is already installed on the system)



 You couldn't get a backtrace or anything on this?

 This is a server install and stopped working after migrating to new 
 hardware.



 Have you tried reinstalling/upgrading?

 On Tue, Aug 21, 2012 at 12:19 PM, dan (ddp) ddp...@gmail.com wrote:
 On Tue, Aug 21, 2012 at 11:19 AM, Shaka Lewis shaka.le...@gmail.com 
 wrote:
 I ran the debug and here is the outupt

 2012/08/20 17:06:18 ossec-rootcheck: INFO: Ending rootcheck scan.
 2012/08/20 18:56:28 ossec-logcollector: socketerr (not available).
 2012/08/20 18:56:28 ossec-logcollector(1224): ERROR: Error sending
 message to queue.
 2012/08/20 18:56:29 ossec-logcollector: socketerr (not available).
 2012/08/20 18:56:29 ossec-logcollector(1224): ERROR: Error sending
 message to queue.
 2012/08/20 18:56:31 ossec-logcollector(1210): ERROR: Queue
 '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
 2012/08/20 18:56:31 ossec-logcollector(1211): ERROR: Unable to access
 queue: '/var/ossec/queue/ossec/queue'. Giving up..
 2012/08/20 18:56:32 ossec-logcollector(1210): ERROR: Queue
 '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
 2012/08/20 18:56:32 ossec-logcollector(1211): ERROR: Unable to access
 queue: '/var/ossec/queue/ossec/queue'. Giving up..
 2012/08/20 18:57:18 ossec-monitord: socketerr (not available).
 2012/08/20 18:57:18 ossec-monitord(1224): ERROR: Error sending message 
 to queue.
 2012/08/20 19:19:19 ossec-monitord: socketerr (not available).
 2012/08/20 19:19:19 ossec-monitord(1224): ERROR: Error sending message 
 to queue.
 2012/08/20 19:19:19 ossec-monitord: socketerr (not available).


 And what OSSEC processes are running at this point?
 Did you run analysisd in gdb? Did it crash? Is there a backtrace?

 I'll throw in some more questions, because I need some more to not be
 answered. Is this a server or a standalone installation? Has it ever
 worked? Did you change anything?


 On Mon, Aug 20, 2012 at 9:40 AM, dan (ddp) ddp...@gmail.com wrote:
 On Mon, Aug 20, 2012 at 9:38 AM, Shaka Lewis shaka.le...@gmail.com 
 wrote:
 This is the error log in the ossec.log file when i restarted this 
 morning

  ossec-logcollector(1950): INFO: Analyzing file:
 '/var/ossec/logs/alerts/alerts.log'.
 2012/08/20 09:29:30 ossec-logcollector: INFO: Started (pid: 10978).
 2012/08/20 09:29:50 ossec-logcollector: socketerr (not available).
 2012/08/20 09:29:50 ossec-logcollector(1224): ERROR: Error sending
 message to queue.
 2012/08/20 09:29:53 ossec-logcollector(1210): ERROR: Queue
 '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
 2012/08/20 09:29:53 ossec-logcollector(1211): ERROR: Unable to access
 queue: '/var/ossec/queue/ossec/queue'. Giving up..
 2012/08/20 09:30:31 ossec-syscheckd: INFO: Starting syscheck scan
 (forwarding database).
 2012/08/20 09:30:31 ossec-syscheckd: socketerr (not available).
 2012/08/20 09:30:31 ossec-syscheckd(1224): 

[ossec-list] Matching a port range

[Doc]

Drawing a blank here and not finding it in documentation...can we match a 
port range in a local rule?  I'm looking to exclude messages where the 
destination port is dynamic within a specific range.

Thanks,
Doc

[ossec-list] Client.keys Permission error

[OSSEC junkie]

I am getting permission errors on client.keys:
2012/08/22 08:44:38 ossec-remoted(4111): INFO: Maximum number of
agents allowed: '3500'.
2012/08/22 08:44:38 ossec-remoted(1410): INFO: Reading authentication keys file.
2012/08/22 08:44:38 ossec-remoted(1103): ERROR: Unable to open file
'/etc/client.keys'.
2012/08/22 08:44:38 ossec-remoted(1750): ERROR: No remote connection
configured. Exiting.


My configuration (permissions) for the file is:

root@wu-tang:/var/ossec/etc# ls -al
total 184
dr-xr-x---  3 root ossec  4096 Aug 20 06:02 .
dr-xr-x--- 13 root ossec  4096 Aug 20 05:59 ..
-r--r-  1 root root  57369 Aug 20 06:22 client.keys

I assume it needs to be root:ossec but wanted to get final confirmation.

Can you let me know please?

Re: [ossec-list] Client.keys Permission error

[Daniel Cid]

Yes, the ossecr user (or ossec group) needs permission to read it.

thanks,

On Wed, Aug 22, 2012 at 1:00 PM, OSSEC junkie ossec.jun...@gmail.com wrote:
 I am getting permission errors on client.keys:
 2012/08/22 08:44:38 ossec-remoted(4111): INFO: Maximum number of
 agents allowed: '3500'.
 2012/08/22 08:44:38 ossec-remoted(1410): INFO: Reading authentication keys 
 file.
 2012/08/22 08:44:38 ossec-remoted(1103): ERROR: Unable to open file
 '/etc/client.keys'.
 2012/08/22 08:44:38 ossec-remoted(1750): ERROR: No remote connection
 configured. Exiting.


 My configuration (permissions) for the file is:

 root@wu-tang:/var/ossec/etc# ls -al
 total 184
 dr-xr-x---  3 root ossec  4096 Aug 20 06:02 .
 dr-xr-x--- 13 root ossec  4096 Aug 20 05:59 ..
 -r--r-  1 root root  57369 Aug 20 06:22 client.keys

 I assume it needs to be root:ossec but wanted to get final confirmation.

 Can you let me know please?

Re: [ossec-list] socketerr messages after restarting ossec, errors occur after the starting the rootcheck scan

[dan (ddp)]

On Wed, Aug 22, 2012 at 11:18 AM, Shaka Lewis shaka.le...@gmail.com wrote:
 Not sure what you mean, I have run all the debug commands you requested.


I'm sorry, gmail isn't showing the gdb info.
Or the answer to  Did you make any changes before
restarting? What log messages are
 there before the first socketerr?
How many times did I ask which processes were running?
You said you migrated to new hardware, but didn't give any information
as to how that was done.
I don't mind helping, but I don't like to be forced into digging the
information out of you. I also hate repeating myself.

 On Wed, Aug 22, 2012 at 10:33 AM, dan (ddp) ddp...@gmail.com wrote:
 Since you don't seem too interested in fixing this, good luck.

 On Wed, Aug 22, 2012 at 10:19 AM, Shaka Lewis shaka.le...@gmail.com wrote:
 here is all I have from the latest debug:

 2012/08/21 17:43:35 ossec-rootcheck: DEBUG: Going into check_rc_dev
 2012/08/21 17:43:35 ossec-rootcheck: DEBUG: Starting on check_rc_dev
 2012/08/21 17:43:36 ossec-rootcheck: DEBUG: Going into check_rc_sys
 2012/08/21 17:43:36 ossec-rootcheck: DEBUG: Starting on check_rc_sys
 2012/08/21 17:43:36 ossec-rootcheck: DEBUG: Going into check_rc_pids
 2012/08/21 18:16:40 ossec-rootcheck: DEBUG: Going into check_rc_ports
 2012/08/21 18:16:41 ossec-rootcheck: DEBUG: Going into check_open_ports
 2012/08/21 18:16:41 ossec-rootcheck: DEBUG: Going into check_rc_if
 2012/08/21 18:16:41 ossec-rootcheck: DEBUG: Completed with all checks.
 2012/08/21 18:16:46 ossec-rootcheck: INFO: Ending rootcheck scan.
 2012/08/21 18:16:46 ossec-rootcheck: DEBUG: Leaving run_rk_check
 2012/08/21 19:22:09 ossec-logcollector: socketerr (not available).
 2012/08/21 19:22:09 ossec-logcollector(1224): ERROR: Error sending
 message to queue.
 2012/08/21 19:22:12 ossec-logcollector(1210): ERROR: Queue
 '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
 2012/08/21 19:22:12 ossec-logcollector(1211): ERROR: Unable to access
 queue: '/var/ossec/queue/ossec/queue'. Giving up..
 2012/08/21 19:31:30 ossec-monitord: socketerr (not available).

 On Wed, Aug 22, 2012 at 7:45 AM, dan (ddp) ddp...@gmail.com wrote:
 On Tue, Aug 21, 2012 at 2:13 PM, Shaka Lewis shaka.le...@gmail.com wrote:
 The ossec processes running at this point are execd, logcollector, and 
 monitord.


 AnalysisD crashed and here is the output:

 Program received signal SIGSEGV, Segmentation fault.
 [Switching to process 26814]
 0x in ?? ()
 Missing separate debuginfos, use: debuginfo-install
 glibc-2.12-1.47.el6_2.12.x86_64
 (This version of glibc is already installed on the system)



 You couldn't get a backtrace or anything on this?

 This is a server install and stopped working after migrating to new 
 hardware.



 Have you tried reinstalling/upgrading?

 On Tue, Aug 21, 2012 at 12:19 PM, dan (ddp) ddp...@gmail.com wrote:
 On Tue, Aug 21, 2012 at 11:19 AM, Shaka Lewis shaka.le...@gmail.com 
 wrote:
 I ran the debug and here is the outupt

 2012/08/20 17:06:18 ossec-rootcheck: INFO: Ending rootcheck scan.
 2012/08/20 18:56:28 ossec-logcollector: socketerr (not available).
 2012/08/20 18:56:28 ossec-logcollector(1224): ERROR: Error sending
 message to queue.
 2012/08/20 18:56:29 ossec-logcollector: socketerr (not available).
 2012/08/20 18:56:29 ossec-logcollector(1224): ERROR: Error sending
 message to queue.
 2012/08/20 18:56:31 ossec-logcollector(1210): ERROR: Queue
 '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
 2012/08/20 18:56:31 ossec-logcollector(1211): ERROR: Unable to access
 queue: '/var/ossec/queue/ossec/queue'. Giving up..
 2012/08/20 18:56:32 ossec-logcollector(1210): ERROR: Queue
 '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
 2012/08/20 18:56:32 ossec-logcollector(1211): ERROR: Unable to access
 queue: '/var/ossec/queue/ossec/queue'. Giving up..
 2012/08/20 18:57:18 ossec-monitord: socketerr (not available).
 2012/08/20 18:57:18 ossec-monitord(1224): ERROR: Error sending message 
 to queue.
 2012/08/20 19:19:19 ossec-monitord: socketerr (not available).
 2012/08/20 19:19:19 ossec-monitord(1224): ERROR: Error sending message 
 to queue.
 2012/08/20 19:19:19 ossec-monitord: socketerr (not available).


 And what OSSEC processes are running at this point?
 Did you run analysisd in gdb? Did it crash? Is there a backtrace?

 I'll throw in some more questions, because I need some more to not be
 answered. Is this a server or a standalone installation? Has it ever
 worked? Did you change anything?


 On Mon, Aug 20, 2012 at 9:40 AM, dan (ddp) ddp...@gmail.com wrote:
 On Mon, Aug 20, 2012 at 9:38 AM, Shaka Lewis shaka.le...@gmail.com 
 wrote:
 This is the error log in the ossec.log file when i restarted this 
 morning

  ossec-logcollector(1950): INFO: Analyzing file:
 '/var/ossec/logs/alerts/alerts.log'.
 2012/08/20 09:29:30 ossec-logcollector: INFO: Started (pid: 10978).
 2012/08/20 09:29:50 ossec-logcollector: socketerr (not available).
 2012/08/20 09:29:50 

Re: [ossec-list] Matching a port range

[dan (ddp)]

On Wed, Aug 22, 2012 at 11:56 AM, Doc teetime2...@gmail.com wrote:
 Drawing a blank here and not finding it in documentation...can we match a
 port range in a local rule?  I'm looking to exclude messages where the
 destination port is dynamic within a specific range.

 Thanks,
 Doc

Nope.

Re: [ossec-list] socketerr messages after restarting ossec, errors occur after the starting the rootcheck scan

[dan (ddp)]

On Wed, Aug 22, 2012 at 3:05 PM, Shaka Lewis shaka.le...@gmail.com wrote:
 And what OSSEC processes are running at this point?
 Did you run analysisd in gdb? Did it crash? Is there a backtrace?

 I'll throw in some more questions, because I need some more to not be
 answered. Is this a server or a standalone installation? Has it ever
 worked? Did you change anything?

 The ossec processes running at this point are execd, logcollector, and 
 monitord.


 AnalysisD crashed and here is the output:

 Program received signal SIGSEGV, Segmentation fault.
 [Switching to process 26814]
 0x in ?? ()
 Missing separate debuginfos, use: debuginfo-install
 glibc-2.12-1.47.el6_2.12.x86_64
 (This version of glibc is already installed on the system)


 This is a server install and stopped working after migrating to new hardware.


 2012/08/21 17:19:43 ossec-syscheckd(1210): ERROR: Queue
 '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
 2012/08/21 17:19:43 ossec-rootcheck(1210): ERROR: Queue
 '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
 2012/08/21 17:19:51 ossec-syscheckd(1210): ERROR: Queue
 '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
 2012/08/21 17:19:51 ossec-rootcheck(1210): ERROR: Queue
 '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
 2012/08/21 17:20:04 ossec-syscheckd(1210): ERROR: Queue
 '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.







 Here is the sequence of events before the problems started occuring.

 1.  The old ossec server was replaced with new hardware.  I had the
 UNIX admin copy the ossec directories and ossec groups and users to
 the new hardware.  This caused permissions issues that I had to
 resolve.


Yeah, no idea what all could be broken with this. Just backup the
configs and the rids and reinstall. Stop making this so difficult.

 The only changes I made to the local rules file was copying a ftp
 connect signature and limiting the number of times it alerts.  Current
 state as of today is that ossec processes run for about an hours or so
 then the error messages start.

 First error messages before first socket error:

 2012/08/21 18:16:41 ossec-rootcheck: DEBUG: Completed with all checks.
 2012/08/21 18:16:46 ossec-rootcheck: INFO: Ending rootcheck scan.
 2012/08/21 18:16:46 ossec-rootcheck: DEBUG: Leaving run_rk_check
 2012/08/21 19:22:09 ossec-logcollector: socketerr (not available).
 2012/08/21 19:22:09 ossec-logcollector(1224): ERROR: Error sending
 message to queue.
 2012/08/21 19:22:12 ossec-logcollector(1210): ERROR: Queue
 '/var/ossec/queue/ossec/queue' not accessible: 'Connection refused'.
 2012/08/21 19:22:12 ossec-logcollector(1211): ERROR: Unable to access
 queue: '/var/ossec/queue/ossec/queue'. Giving up..
 2012/08/21 19:31:30 ossec-monitord: socketerr (not available).


 How many times did I ask which processes were running? ( I also
 answered this question) Here are the processes running:

 root 30371 1  0 Aug21 ?00:00:00 /var/ossec/bin/ossec-execd -d
 ossec30394 1  0 Aug21 ?00:00:00 /var/ossec/bin/ossec-monitord 
 -d


You answered this after I asked a second time.



 stack trace:




 read(5, Aug 21 10:10:24 alalpsec006 sudo..., 4096) = 107
 stat(/var/ossec/queue/ossec/.wait, 0x7fff415fc1d0) = -1 ENOENT (No
 such file or directory)
 sendto(4, 1:/var/log/messages:Aug 21 10:10..., 127, 0, NULL, 0) = 127
 read(5, , 4096)   = 0
 read(6, Aug 21 10:10:24 alalpsec006 sudo..., 4096) = 114
 stat(/var/ossec/queue/ossec/.wait, 0x7fff415fc1d0) = -1 ENOENT (No
 such file or directory)
 sendto(4, 1:/var/log/secure:Aug 21 10:10:2..., 132, 0, NULL, 0) = 132
 read(6, , 4096)   = 0
 read(7, , 4096)   = 0
 read(8, , 4096)   = 0
 select(0, NULL, NULL, NULL, {2, 0}) = 0 (Timeout)
 read(5, , 4096)   = 0
 read(6, , 4096)   = 0
 read(7, , 4096)   = 0
 read(8, , 4096)   = 0
 select(0, NULL, NULL, NULL, {2, 0}) = 0 (Timeout)
 read(5, , 4096)   = 0
 read(6, , 4096)   = 0
 read(7, , 4096)   = 0
 read(8, , 4096)   = 0
 select(0, NULL, NULL, NULL, {2, 0}) = 0 (Timeout)
 read(5, , 4096)   = 0
 read(6, , 4096)   = 0
 read(7, , 4096)   = 0
 read(8, , 4096)   = 0
 select(0, NULL, NULL, NULL, {2, 0}) = 0 (Timeout)
 read(5, , 4096)   = 0
 read(6, , 4096)   = 0
 read(7, , 4096)   = 0
 read(8, , 4096)   = 0
 select(0, NULL, NULL, NULL, {2, 0}) = 0 (Timeout)
 read(5, , 4096)   = 0
 read(6, , 4096)   = 0
 read(7, , 4096)   = 0
 read(8, , 4096)   = 0
 select(0, 

[ossec-list] Can this be achieved by rules?

[Kevin Huang]

Hi,

I am new to ossec, I would like to write a rule that will check for an
occurrences when a rule is fired and if it is fired at a certain rate,
do something.

A scenario, I would like to write a rule that monitors all alerts and if
I found more than 5 identical alerts from the same machine, then raise
the alert level and silent the corresponding rule for 1 hour.

Is this possible?

Thanks!

-KH

Re: [ossec-list] analysisd register_rule.sh script permission error halts install

[Joe Gedeon]

You need to build a binary install.
http://www.ossec.net/doc/manual/installation/installation-binary.html

On Wed, Aug 22, 2012 at 4:42 PM, Christopher Werby cwe...@pipsqueak.com wrote:
 Hi

 I'm trying to set OSSEC up as local on a VPS hosted by Dreamhost (running
 the Debian 6.0, Linux kernal release 3.1.9-vs2.3.2.5).  I've done this twice
 before using older versions of OSSEC without difficulty.

 When running the register_rule.sh script, the installer dies with a
 permission error.  I tried to change the permissions and made the
 register_rule.sh file 777 with no luck.  I'm executing the script as root
 (using sudo su).

 I've reproduced the onscreen display starting from just before the point it
 dies.

 make[3]: Leaving directory
 `/tmp/ossec-hids-2.6/src/analysisd/decoders/plugins'
 gcc -g -Wall -I../../ -I../../headers  -DDEFAULTDIR=\/var/ossec\ -DLOCAL
 -DUSE_OPENSSL -DUSEINOTIFY-DARGV0=\ossec-analysisd\ -DXML_VAR=\var\
 -DOSSECHIDS -I../ -c *.c
 ar cru decoders.a *.o  plugins/*.o
 ranlib decoders.a
 make[2]: Leaving directory `/tmp/ossec-hids-2.6/src/analysisd/decoders'
 cd ./compiled_rules; make;
 make[2]: Entering directory
 `/tmp/ossec-hids-2.6/src/analysisd/compiled_rules'
 ./register_rule.sh build
 make[2]: execvp: ./register_rule.sh: Permission denied
 make[2]: *** [plugins] Error 127
 make[2]: Leaving directory
 `/tmp/ossec-hids-2.6/src/analysisd/compiled_rules'
 make[1]: *** [logaudit] Error 2
 make[1]: Leaving directory `/tmp/ossec-hids-2.6/src/analysisd'
 Error Making analysisd
 make: *** [all] Error 1
  Error 0x5.
  Building error. Unable to finish the installation.



 Any thoughts on how I might fix this?

 Thanks!



-- 
Registered Linux User # 379282

Re: [ossec-list] analysisd register_rule.sh script permission error halts install

[Christopher Werby]

Hi Joe,

If I understand properly, I need an identical platform to create the binary.  
There aren't premade binaries available for me to use.  The platform where I 
got stuck was a brand new just out of the box VPS.  I don't have another.  
And even if I made another, it would presumably stick at the same place.

So how would I get the binaries that I need to install?

Best,
---
Christopher Werby
Pipsqueak Productions, LLC
http://www.Pipsqueak.com

On Aug 22, 2012, at 3:56 PM, Joe Gedeon wrote:

 You need to build a binary install.
 http://www.ossec.net/doc/manual/installation/installation-binary.html
 
 On Wed, Aug 22, 2012 at 4:42 PM, Christopher Werby cwe...@pipsqueak.com 
 wrote:
 Hi
 
 I'm trying to set OSSEC up as local on a VPS hosted by Dreamhost (running
 the Debian 6.0, Linux kernal release 3.1.9-vs2.3.2.5).  I've done this twice
 before using older versions of OSSEC without difficulty.
 
 When running the register_rule.sh script, the installer dies with a
 permission error.  I tried to change the permissions and made the
 register_rule.sh file 777 with no luck.  I'm executing the script as root
 (using sudo su).
 
 I've reproduced the onscreen display starting from just before the point it
 dies.
 
 make[3]: Leaving directory
 `/tmp/ossec-hids-2.6/src/analysisd/decoders/plugins'
 gcc -g -Wall -I../../ -I../../headers  -DDEFAULTDIR=\/var/ossec\ -DLOCAL
 -DUSE_OPENSSL -DUSEINOTIFY-DARGV0=\ossec-analysisd\ -DXML_VAR=\var\
 -DOSSECHIDS -I../ -c *.c
 ar cru decoders.a *.o  plugins/*.o
 ranlib decoders.a
 make[2]: Leaving directory `/tmp/ossec-hids-2.6/src/analysisd/decoders'
 cd ./compiled_rules; make;
 make[2]: Entering directory
 `/tmp/ossec-hids-2.6/src/analysisd/compiled_rules'
 ./register_rule.sh build
 make[2]: execvp: ./register_rule.sh: Permission denied
 make[2]: *** [plugins] Error 127
 make[2]: Leaving directory
 `/tmp/ossec-hids-2.6/src/analysisd/compiled_rules'
 make[1]: *** [logaudit] Error 2
 make[1]: Leaving directory `/tmp/ossec-hids-2.6/src/analysisd'
 Error Making analysisd
 make: *** [all] Error 1
 Error 0x5.
 Building error. Unable to finish the installation.
 
 
 
 Any thoughts on how I might fix this?
 
 Thanks!
 
 
 
 -- 
 Registered Linux User # 379282

Re: [ossec-list] analysisd register_rule.sh script permission error halts install

[dan (ddp)]

On Aug 22, 2012 4:46 PM, Christopher Werby cwe...@pipsqueak.com wrote:

 Hi

 I'm trying to set OSSEC up as local on a VPS hosted by Dreamhost
(running the Debian 6.0, Linux kernal release 3.1.9-vs2.3.2.5).  I've done
this twice before using older versions of OSSEC without difficulty.

 When running the register_rule.sh script, the installer dies with a
permission error.  I tried to change the permissions and made the
register_rule.sh file 777 with no luck.  I'm executing the script as root
(using sudo su).

 I've reproduced the onscreen display starting from just before the point
it dies.

 make[3]: Leaving directory
`/tmp/ossec-hids-2.6/src/analysisd/decoders/plugins'
 gcc -g -Wall -I../../ -I../../headers  -DDEFAULTDIR=\/var/ossec\
-DLOCAL -DUSE_OPENSSL -DUSEINOTIFY-DARGV0=\ossec-analysisd\
-DXML_VAR=\var\ -DOSSECHIDS -I../ -c *.c
 ar cru decoders.a *.o  plugins/*.o
 ranlib decoders.a
 make[2]: Leaving directory `/tmp/ossec-hids-2.6/src/analysisd/decoders'
 cd ./compiled_rules; make;
 make[2]: Entering directory
`/tmp/ossec-hids-2.6/src/analysisd/compiled_rules'
 ./register_rule.sh build

Try /bin/sh -x register_rule.sh (after going into the above dir)

That might give more info on what is failing.

 make[2]: execvp: ./register_rule.sh: Permission denied
 make[2]: *** [plugins] Error 127
 make[2]: Leaving directory
`/tmp/ossec-hids-2.6/src/analysisd/compiled_rules'
 make[1]: *** [logaudit] Error 2
 make[1]: Leaving directory `/tmp/ossec-hids-2.6/src/analysisd'
 Error Making analysisd
 make: *** [all] Error 1
  Error 0x5.
  Building error. Unable to finish the installation.



 Any thoughts on how I might fix this?

 Thanks!

Re: [ossec-list] analysisd register_rule.sh script permission error halts install

[Christopher Werby]

Hi Dan,

Here's the output.  Does it help?

 root@xxx:/tmp/ossec-hids-2.6/src/analysisd/compiled_rules# /bin/sh -x 
 register_rule.sh
 + CHF=compiled_rules.h
 + ls -la register_rule.sh
 + '[' '!' 0 = 0 ']'
 + '[' x = x -o x = xhelp -o x = x-h ']'
 + echo 'register_rule.sh add function_name'
 register_rule.sh add function_name
 + echo 'register_rule.sh list'
 register_rule.sh list
 + echo 'register_rule.sh build'
 register_rule.sh build
 + echo 'register_rule.sh save'
 register_rule.sh save
 + echo 'register_rule.sh restore'
 register_rule.sh restore
 + exit 0



Best
---
Christopher Werby
Pipsqueak Productions, LLC
http://www.Pipsqueak.com

On Aug 22, 2012, at 5:06 PM, dan (ddp) wrote:

 
 On Aug 22, 2012 4:46 PM, Christopher Werby cwe...@pipsqueak.com wrote:
 
  Hi
 
  I'm trying to set OSSEC up as local on a VPS hosted by Dreamhost (running 
  the Debian 6.0, Linux kernal release 3.1.9-vs2.3.2.5).  I've done this 
  twice before using older versions of OSSEC without difficulty.
 
  When running the register_rule.sh script, the installer dies with a 
  permission error.  I tried to change the permissions and made the 
  register_rule.sh file 777 with no luck.  I'm executing the script as root 
  (using sudo su).
 
  I've reproduced the onscreen display starting from just before the point it 
  dies.
 
  make[3]: Leaving directory 
  `/tmp/ossec-hids-2.6/src/analysisd/decoders/plugins'
  gcc -g -Wall -I../../ -I../../headers  -DDEFAULTDIR=\/var/ossec\ -DLOCAL 
  -DUSE_OPENSSL -DUSEINOTIFY-DARGV0=\ossec-analysisd\ 
  -DXML_VAR=\var\ -DOSSECHIDS -I../ -c *.c
  ar cru decoders.a *.o  plugins/*.o
  ranlib decoders.a
  make[2]: Leaving directory `/tmp/ossec-hids-2.6/src/analysisd/decoders'
  cd ./compiled_rules; make;
  make[2]: Entering directory 
  `/tmp/ossec-hids-2.6/src/analysisd/compiled_rules'
  ./register_rule.sh build
 
 Try /bin/sh -x register_rule.sh (after going into the above dir)
 
 That might give more info on what is failing.
 
  make[2]: execvp: ./register_rule.sh: Permission denied
  make[2]: *** [plugins] Error 127
  make[2]: Leaving directory 
  `/tmp/ossec-hids-2.6/src/analysisd/compiled_rules'
  make[1]: *** [logaudit] Error 2
  make[1]: Leaving directory `/tmp/ossec-hids-2.6/src/analysisd'
  Error Making analysisd
  make: *** [all] Error 1
   Error 0x5.
   Building error. Unable to finish the installation.
 
   
 
  Any thoughts on how I might fix this?
 
  Thanks!
 

Re: [ossec-list] analysisd register_rule.sh script permission error halts install

[Ryan Schulze]

Can you do that again, but this time as /bin/sh -x register_rule.sh 
build ?


On 8/22/2012 7:10 PM, Christopher Werby wrote:
root@xxx:/tmp/ossec-hids-2.6/src/analysisd/compiled_rules# /bin/sh -x 
register_rule.sh

Re: [ossec-list] analysisd register_rule.sh script permission error halts install

[Christopher Werby]

Hi Ryan,

Sure!

 root@XXX:/tmp/ossec-hids-2.6/src/analysisd/compiled_rules# /bin/sh -x 
 register_rule.sh build
 + CHF=compiled_rules.h
 + ls -la register_rule.sh
 + '[' '!' 0 = 0 ']'
 + '[' xbuild = x -o xbuild = xhelp -o xbuild = x-h ']'
 + '[' xbuild = xlist ']'
 + '[' xbuild = xsave ']'
 + '[' xbuild = xrestore ']'
 + '[' xbuild = xbuild ']'
 + ls -la .function_list
 + '[' '!' 0 = 0 ']'
 + echo '/* This file is auto generated by register_rule.sh. Do not touch it. 
 */'
 + echo ''
 + echo '/* Adding the function definitions. */'
 ++ cat .function_list
 ++ sort
 ++ uniq
 + for i in '`cat .function_list | sort| uniq`'
 + echo 'void *check_id_size(Eventinfo *lf);'
 + for i in '`cat .function_list | sort| uniq`'
 + echo 'void *comp_mswin_targetuser_calleruser_diff(Eventinfo *lf);'
 + for i in '`cat .function_list | sort| uniq`'
 + echo 'void *comp_srcuser_dstuser(Eventinfo *lf);'
 + for i in '`cat .function_list | sort| uniq`'
 + echo 'void *is_simple_http_request(Eventinfo *lf);'
 + for i in '`cat .function_list | sort| uniq`'
 + echo 'void *is_valid_crawler(Eventinfo *lf);'
 + echo ''
 + echo '/* Adding the rules list. */'
 + echo 'void *(compiled_rules_list[]) = '
 + echo '{'
 ++ cat .function_list
 ++ sort
 ++ uniq
 + for i in '`cat .function_list | sort| uniq`'
 + echo 'check_id_size,'
 + for i in '`cat .function_list | sort| uniq`'
 + echo 'comp_mswin_targetuser_calleruser_diff,'
 + for i in '`cat .function_list | sort| uniq`'
 + echo 'comp_srcuser_dstuser,'
 + for i in '`cat .function_list | sort| uniq`'
 + echo 'is_simple_http_request,'
 + for i in '`cat .function_list | sort| uniq`'
 + echo 'is_valid_crawler,'
 + echo 'NULL'
 + echo '};'
 + echo ''
 + echo '/* Adding the rules list names. */'
 + echo 'char *(compiled_rules_name[]) = '
 + echo '{'
 ++ cat .function_list
 ++ sort
 ++ uniq
 + for i in '`cat .function_list |sort | uniq`'
 + echo 'check_id_size,'
 + for i in '`cat .function_list |sort | uniq`'
 + echo 'comp_mswin_targetuser_calleruser_diff,'
 + for i in '`cat .function_list |sort | uniq`'
 + echo 'comp_srcuser_dstuser,'
 + for i in '`cat .function_list |sort | uniq`'
 + echo 'is_simple_http_request,'
 + for i in '`cat .function_list |sort | uniq`'
 + echo 'is_valid_crawler,'
 + echo 'NULL'
 + echo '};'
 + echo ''
 + echo '/* EOF */'
 + echo '*Build completed.'
 *Build completed.

---
Christopher Werby
Pipsqueak Productions, LLC
http://www.Pipsqueak.com

On Aug 22, 2012, at 8:44 PM, Ryan Schulze wrote:

 /bin/sh -x register_rule.sh build