[ossec-list] Ignore Alert from Certain User

[OSSEC junkie]

Is there a way to ignore an alert from a particular user?  We have an ESX
environment with a service account that is a bit buggy.  It's sending
invalid login attempts by the thousands on a daily basis.   Is it possible
to configure OSSEC to ignore any rule created by "svc_vesx" but still log
invalid login attempts as expected?

I would think it is but want to get the expert opinion.   Thanks!

-- 

--- 
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/groups/opt_out.

[ossec-list] active-response on the server

[Nicolas Zin]

Hi,

I have 20 agents, on ossec 2.7.0.

I have an active-response configurartion like this:

firewall-drop
all

3357,9951,9952,9953,31502,13,18,100011,100012,100101
600
30,60,120
  


The question is simple: why the active-reponse is applied everywhere except
on the server?
Should I add another active-response with the same rules but with
server?

I have nothing in my iptables, and no /var/ossec/log/active-response.log on
my server.


Thanks

-- 

--- 
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/groups/opt_out.

[ossec-list] Re: OSSEC opens lots of files and keeps them open

[Kat]

How many folders/files are you monitoring for changes?

On Friday, May 10, 2013 1:32:33 AM UTC-7, Winni Neessen wrote:
>
> Hi,
>
> I am running OSSEC 2.7 on FreeBSD 8.4. Recently I received a kernel 
> warning, that maxfiles was exceeded. 
> I was wondering how this could be, as kern.maxfiles was configured to 32k. 
> A run of "lsof" quickly showed that
> OSSEC was the bad guy. 30k files were currently open through OSSEC. After 
> a restart the count was back to
> 1k. A week later I can see that the kern.openfiles is again at 18k and 
> constantly growing. 16k are again used
> by OSSEC.
>
> My question... is this normal behaviour by OSSEC, so that I need to adjust 
> my kern.maxfiles settings? Or could
> this be some kind of misbehaviour?
>
> Any advice is greatly appreciated.
>
>
> Thanks
> Winni
>

-- 

--- 
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/groups/opt_out.

[ossec-list] MSSQL support?

[DGeebs]

I know Ossec's page says that MSSQL support was coming soon, but its been a 
while since they have said this and I was wondering if anyone was already 
ahead of the curve and had made some decoders and/or rules already. 
Anything to get a head start would be nice, don't want to reinvent the 
wheel if I don't have to! Thanks!

-- 

--- 
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/groups/opt_out.

Re: [ossec-list] Re: question with /var/ossec/queue/diff

[cgzones]

Hi,
i append a patch which disables the usage of state.[timestamp] files for
rule diff's.
These files are as far i see never used by ossec again. ossec uses only
the last-entry file.
I tested the patch only short, so it might not work for you, but feel
free to test.

Best regards

On 05/14/2013 04:38 PM, Aaron Bliss wrote:
> Hi all,
> Just thought I would report that the following bash script doesn't
> seem to have any adverse affects on OSSEC but will at least keep inode
> utilization in check.
>
> Aaron
>
> #!/bin/bash
>
> #script used for cleaning up ossec dirs
>
> cd /var/ossec/queue/diff
> mdir=`ls -1`
>
> /etc/init.d/ossec stop
> find ./$mdir/535 -type f -name state* -mtime +7 | xargs rm -f
> /etc/init.d/ossec start
>
>
> On Mon, May 6, 2013 at 6:38 PM, Jb Cheng  > wrote:
>
> The queue/diff//535/ directory is used for rule ID 535 as
> shown in etc/ruels/ossec-rules.xml.
> For Unix-like systems, syscheck daemon uses the output of 'last -n
> 5' to detect changes in logged-in users.
>
> Windows systems use a different mechanism for this so you don't
> see them under /diff/. 
>
> I do agree with you that the number of files under /diff/ should
> not grow without an upper bound. 
> Perhaps someone can offer a fix...?
>
> On Monday, May 6, 2013 5:51:03 AM UTC-7, ab wrote:
>
> Hi all,
> Just following up.  inode usage continues to grow.  I took a
> look at /var/ossec/queue/diff/server1/535 (I've inserted
> server1 by replacing the name of one of our agents) and there
> are thousands of files with the name state.number (number
> looks like a random or incremented number?).  I checked the
> contents of one of these files and they appear to be the
> output of last -n 5 command which is in the osssec.conf file
> of each of our Linux agents.  There aren't any directories in
> /var/ossec/queue/diff named after any of our Windows clients. 
> As I reported earlier, I did clear out /var/ossec/queue/diff
> and reset the syscheck database without any side affects a few
> days ago.  Would there be any issues by continuning to purge
> /var/ossec/queue/diff and if so, should clear the syscheck
> database when doing so?  I'm guessing this is a bug?  Please
> advise and thanks.
>
> Aaron
>
>
> On Thu, May 2, 2013 at 3:39 PM, Aaron Bliss
>  wrote:
>
> Hi all,
> In our environment, on the management server (version 2.7,
> CentOS 6 64 bit), OSSEC is installed on a dedicated mount
> point at /var/ossec (fairly new install, has been online
> since this past December).  We have a mixture of Windows
> and Linux agents (200 or so).  The /var/ossec mount point
> on the management server ran out of inodes, despite only
> having about 3% of 20 gigs disk utilization.  I determined
> that the inodes (1.3 million of them) were getting used in
> /var/ossec/queue/diff.  I was able to clean them up and
> clear syscheck database of the agents, after which
> everything started working again.  However, I was
> wondering what piece of OSSEC would be writing to
> /var/ossec/queue/diff and which configuration option would
> be doing so?  Please advise and thanks.
>
> Aaron 
>
>
> -- 
>  
> ---
> 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/groups/opt_out.
>  
>  
>
>
> -- 
>  
> ---
> 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/groups/opt_out.
>  
>  

-- 

--- 
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/groups/opt_out.


*** dodiff.c.old	2013-05-14 17:08:04.331522742 +0200
--- dodiff.c	2013-05-14 17:13:48.299529199 +0200
***
*** 90,96 
  int date_of_change;
  char *htpt = NULL;
  char flastfile[OS_SIZE_2048 +1];
- char fdifffile[OS_SIZE_2048 +1];
  char flastcontent[OS_SIZE_8192 +1];
  
  
--- 90,95 
***
*** 174,203 
  }
  
  
- /* File was modified. */
- if(lf->hostname[0] == '(')
- {
-

Re: [ossec-list] Re: question with /var/ossec/queue/diff

[Aaron Bliss]

Hi all,
Just thought I would report that the following bash script doesn't seem to
have any adverse affects on OSSEC but will at least keep inode utilization
in check.

Aaron

#!/bin/bash

#script used for cleaning up ossec dirs

cd /var/ossec/queue/diff
mdir=`ls -1`

/etc/init.d/ossec stop
find ./$mdir/535 -type f -name state* -mtime +7 | xargs rm -f
/etc/init.d/ossec start


On Mon, May 6, 2013 at 6:38 PM, Jb Cheng  wrote:

> The queue/diff//535/ directory is used for rule ID 535 as shown in
> etc/ruels/ossec-rules.xml.
> For Unix-like systems, syscheck daemon uses the output of 'last -n 5' to
> detect changes in logged-in users.
>
> Windows systems use a different mechanism for this so you don't see them
> under /diff/.
>
> I do agree with you that the number of files under /diff/ should not grow
> without an upper bound.
> Perhaps someone can offer a fix...?
>
> On Monday, May 6, 2013 5:51:03 AM UTC-7, ab wrote:
>>
>> Hi all,
>> Just following up.  inode usage continues to grow.  I took a look at
>> /var/ossec/queue/diff/server1/**535 (I've inserted server1 by replacing
>> the name of one of our agents) and there are thousands of files with the
>> name state.number (number looks like a random or incremented number?).  I
>> checked the contents of one of these files and they appear to be the output
>> of last -n 5 command which is in the osssec.conf file of each of our Linux
>> agents.  There aren't any directories in /var/ossec/queue/diff named after
>> any of our Windows clients.  As I reported earlier, I did clear out
>> /var/ossec/queue/diff and reset the syscheck database without any side
>> affects a few days ago.  Would there be any issues by continuning to purge
>> /var/ossec/queue/diff and if so, should clear the syscheck database when
>> doing so?  I'm guessing this is a bug?  Please advise and thanks.
>>
>> Aaron
>>
>>
>> On Thu, May 2, 2013 at 3:39 PM, Aaron Bliss  wrote:
>>
>>> Hi all,
>>> In our environment, on the management server (version 2.7, CentOS 6 64
>>> bit), OSSEC is installed on a dedicated mount point at /var/ossec (fairly
>>> new install, has been online since this past December).  We have a mixture
>>> of Windows and Linux agents (200 or so).  The /var/ossec mount point on the
>>> management server ran out of inodes, despite only having about 3% of 20
>>> gigs disk utilization.  I determined that the inodes (1.3 million of them)
>>> were getting used in /var/ossec/queue/diff.  I was able to clean them up
>>> and clear syscheck database of the agents, after which everything started
>>> working again.  However, I was wondering what piece of OSSEC would be
>>> writing to /var/ossec/queue/diff and which configuration option would be
>>> doing so?  Please advise and thanks.
>>>
>>> Aaron
>>>
>>
>>  --
>
> ---
> 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/groups/opt_out.
>
>
>

-- 

--- 
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/groups/opt_out.

Re: [ossec-list] Re: Error "Unable to access ossec directory" using ossec-wui

[David Juarez]

All -

Many Thanks to everyone for your help and response.. I appreciate it.. On
the other hand.. all good with apache and user (apache) as well. perms are
set properly.. yes.. it is about selinux..
Please refer to the link below.. now it works...

http://www.crypt.gen.nz/selinux/disable_selinux.html


set it as permissive.. and it works..

Many Thanks again !!

Cheers...

David Juarez






On Mon, May 13, 2013 at 12:46 PM, Castle, Shane
wrote:

> Selinux?
>
> --
> Shane Castle
> Data Security Mgr, Boulder County IT
>
>
> -Original Message-
> From: ossec-list@googlegroups.com [mailto:ossec-list@googlegroups.com] On
> Behalf Of Ryan Schulze
> Sent: Monday, May 13, 2013 12:22
> To: ossec-list@googlegroups.com
> Subject: Re: [ossec-list] Re: Error "Unable to access ossec directory"
> using ossec-wui
>
> Based on your ls output I'd say that the error message is occurring since
> Apache isn't allowed to access the directory. Did you add any ACLs to the
> directory to allow access that we aren't seeing here? Have you tried just
> su'ing to your apache user to see if it can access everything like it needs
> to?
>
>
> On 5/10/2013 4:27 PM, David Juarez wrote:
>
>
> still not working... Apache is running well, tested a basic
> index.html and works.. except the ossec wui..
>
> any recommendations?
>
> Thanks.
>
> Regards,
> David Juarez
>
>
> On Fri, May 10, 2013 at 2:26 PM, David Juarez 
> wrote:
>
>
> here are changes made to ossec_conf.php
>
> $ossec_dir="/var2/ossec";
>
>
> the error message I received is coming from: (note below)
>
>
> /* Starting handle */
> $ossec_handle = os_handle_start($ossec_dir);
> if($ossec_handle == NULL)
> {
> echo "Unable to access ossec
> directory.\n";
> return(1);
> }
>
>
> Looks like somehow can start the os_handle_start
>
>
>
>
> On Fri, May 10, 2013 at 1:01 PM, David Juarez <
> djuar...@usfca.edu> wrote:
>
>
> Hi,
>
> I am having problems access ossec directory when
> trying to use the web
> I receive the error message from my browser.
>
> ""Unable to access ossec directory"
>
> I can access the webserver from
> http://138.202.80.161/ossec-wui/index.php?f=s
>
>
> and I am able to see the tabs where
> Main, Search, Integrity Checking, Stats, About..
>
> am I missing something..
>
> Note: I installed ossec under a diff partition
> using LVM
> /var2
>
> all is working well, except the web..
>
> Any recommendations? am I missing something.
> your help is greatly appreciated.
>
> Thanks.
>
> David Juarez
>
> I decompresse/untar ossec-wui-0.3.tar.gz.
> mv mv ossec-wui* /var/www/html/ossec-wui
>
>
> [root@syslog-rhel63-svr html]# pwd
> /var/www/html
> [root@syslog-rhel63-svr html]# ls -l
> total 4
> drwxr-xr-x. 8 root ossec 4096 May  9 17:08
> ossec-wui
> [root@syslog-rhel63-svr html]# ls -l ossec-wui/
> total 92
> -rwxr-xr-x. 1 root ossec   317 May  9 17:08 CONTRIB
> drwxr-xr-x. 3 root ossec  4096 May  9 17:08 css
> -rw-r--r--. 1 root ossec   218 May  9 17:08
> htaccess_def.txt
> drwxr-xr-x. 2 root ossec  4096 May  9 17:08 img
> -rwxr-xr-x. 1 root ossec  5177 May  9 17:08
> index.php
> drwxr-xr-x. 2 root ossec  4096 May  9 17:08 js
> drwxr-xr-x. 3 root ossec  4096 May  9 17:08 lib
> -rw-r--r--. 1 root ossec 35745 May  9 17:08 LICENSE
> -rw-r--r--. 1 root ossec   462 May  9 17:08
> ossec_conf.php
> -rw-r--r--. 1 root ossec  1449 May  9 17:08 README
> -rw-r--r--. 1 root ossec   923 May  9 17:08
> README.search
> -rwxr-xr-x. 1 root ossec  1824 May  9 17:08
> setup.sh
> drwxr-xr-x. 2 root ossec  4096 May 10 12:30 site
> drwxrwxrwx. 2 root ossec  4096 May  9 17:08 tmp
>
>
> ran the setup.sh script created 3 users apache,
> and nobody
>
> [root@syslog-rhel63-svr html]# grep ossec
> /etc/group
> ossec:x:502:apache,nobody
> [ro