[ossec-list] Tuning Rule 18152

2014-07-16 Thread Lance A. Brown 
I have a request to tune the output of Rule 18152: Multiple Windows Logon 
Failures.  They would like: 

1. More than 5 failed logins to a single user should be identified so we 
can act on it. 

2. More than 10 failed logins to a single device for any user be identified 
so we can act it. 

3. All other instants of Windows Logon Failures should be set to lower 
alert level 

I've spent all day mucking with rules and it seems like this: 

   
win_authentication_failed 
 
Multiple (5) Windows Logon Failures. 
authentication_failures, 
   

gets what I want for condition 1., but I'm not certain. 

I've had no success at all trying to get conditions 1 and 2 working at the 
same time. 

Is this type of rule configuration possible?  I could use some assistance, 
please. 

--[Lance] 

-- 

--- 
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/d/optout.

[ossec-list] trend-osce_rules

2014-07-16 Thread Scott Mace 
I've hashed together a new decoder and rules file for the "new" Trend Micro 
Office Scan logging to Windows Event Logs.  i don't quite have all the 
result codes in there, but it's a start.  Appreciate any comments, 
suggestions.  I'm using Ossec in AlienVault, so I'll be doing some 
correlation as well.

Decoder:





  ^\.+Trend Micro OfficeScan Server:|^\.+Trend Micro Security


  Result:(\.+)

  status



Ruleset:



  

trend-osce

Grouping of Trend OSCE rules.

  


  

7600

Cleaned|Quarantine

virus

Virus detected and cleaned/quarantined/remved

  


  

7600

Virus successfully detected, cannot perform the Clean action 
(Quarantine)

   virus

Virus detected and unable to clean up.

  


  

7600

Encrypted

Virus scan completed but the file is encrypted


  









-- 

--- 
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/d/optout.

[ossec-list] Re: Report changes not working?

2014-07-16 Thread Steven Ho 
It works locally on the server itself, but not on remote agents.  Any help 
would be greatly appreciated.

On Monday, July 14, 2014 6:29:04 PM UTC-7, Steven Ho wrote:
>
> Hi,
>
>  
>
> I’ve just installed ossec 2.7.1 and am trying to get Ossec to send the 
> actual contents of what changed in a file.  Here’s what my ossec.conf looks 
> like for the syscheck section.  report_changes="yes" has been included 
> already. Am I doing anything wrong?  Currently it only shows the checksum 
> changing:
>
>  
>
> *51*
>
> *Level:*
>
> *7 - **Integrity checksum changed.*
>
> *Rule Id:*
>
> 550  
>
> *Location:*
>
> (SNAv2.dev.i.spireon.com) 192.168.40.165->syscheck 
>
> Integrity checksum changed for: '/etc/group'
> Size changed from '909' to '915'
> Old md5sum was: '907cffdef99913c1fede06e557535594'
> New md5sum is : '5f35bae53e79dcc2c1601c849bddd2a3'
> Old sha1sum was: 'a992bae3a822f036a7637b3af24c8c1921a5b7bb'
> New sha1sum is : '3a6b75af8013169aff06fca37377b3830d5b201b
>
>  
>
> 
>
> 
>
> 3600
>
> yes
>
> yes
>
> 
>
>  check_all="yes">/etc,/usr/bin,/usr/sbin
>
> /bin,/sbin
>
>  
>
> 
>
> /etc/mtab
>
> /etc/mnttab
>
> /etc/hosts.deny
>
> /etc/mail/statistics
>
> /etc/random-seed
>
> /etc/adjtime
>
> /etc/httpd/logs
>
> /etc/utmpx
>
> /etc/wtmpx
>
> /etc/cups/certs
>
> /etc/dumpdates
>
> /etc/svc/volatile
>
>  
>
> 
>
> C:\WINDOWS/System32/LogFiles
>
> C:\WINDOWS/Debug
>
> C:\WINDOWS/WindowsUpdate.log
>
> C:\WINDOWS/iis6.log
>
> C:\WINDOWS/system32/wbem/Logs
>
> C:\WINDOWS/system32/wbem/Repository
>
> C:\WINDOWS/Prefetch
>
> C:\WINDOWS/PCHEALTH/HELPCTR/DataColl
>
> C:\WINDOWS/SoftwareDistribution
>
> C:\WINDOWS/Temp
>
> C:\WINDOWS/system32/config
>
> C:\WINDOWS/system32/spool
>
> C:\WINDOWS/system32/CatRoot
>
>   
>
>  
>
> Thanks,
>
> Steven
>

-- 

--- 
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/d/optout.

Re: [ossec-list] Is it not possible to do an unattended second install of OSSEC on a system?

2014-07-16 Thread Garett Shulman 
While reviewing the implementation of install.sh I discovered USER_CLEANINSTALL 
which does not appear to be documented at 
http://ossec-docs.readthedocs.org/en/latest/manual/installation/install-source-unattended.html.
  Adding USER_CLEANINSTALL="y" to etc/preloaded-vars. conf did the trick.

Thanks!

On Jul 16, 2014, at 5:55 AM, dan (ddp)  wrote:

> On Tue, Jul 15, 2014 at 7:24 PM, Garett Shulman
>  wrote:
>> Hello,
>> 
>> I am trying to do an unattended install of a second instance of OSSEC on an
>> Ubuntu system.
>> 
>> I'm trying to modify etc/preloaded-vars.conf based on
>> http://ossec-docs.readthedocs.org/en/latest/manual/installation/install-source-unattended.html
>> to accomplish this.
>> 
>> However, the fact that there is already an instance of ossec installed seems
>> to cause USER_NO_STOP="y" to be ignored by install.sh which asks if it
>> should update.
>> 
>> 
>> And according to the unattended docs: If USER_UPDATE is set to anything, the
>> update installation will be done.
>> 
>> 
>> This would seem to imply that there is no way to force USER_UPDATE to 'n' as
>> any value is interpreted as affirmative.
>> 
>> 
>> I can install the second instance of OSSEC fine interactively.
>> Disappointing that it doesn't seem possible to accomplish unattended.
>> 
>> 
>> Am I interpreting this correctly?  Anything I may be missing to accomplish
>> this?
>> 
>> 
>> Any assistance greatly appreciated.
>> 
> 
> I don't think this is a situation that was thought of when the support
> was originally developed. If you have any patches, please submit them
> through a pull request on http://www.github.com/ossec/ossec-hids
> 
>> -Garett
>> 
>> 
>> --
>> 
>> ---
>> 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/d/optout.
> 
> -- 
> 
> --- 
> 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/d/optout.

-- 

--- 
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/d/optout.

Re: [ossec-list] Having to restart ossec server on a daily basis for clients to report.

2014-07-16 Thread dan (ddp) 
On Wed, Jul 16, 2014 at 8:55 AM, Nick Souza  wrote:
> Am facing an issue of having to restart ossec server on a daily basis for
> clients to report. If not they all show as inactive. As soon as I run the
> restart command on the server the agents start to report. Am using ossec
> 2.6. Has anyone faced this problem? Any help would be appreciated.
>

Try updating, 2.6 is super old.

> --
>
> ---
> 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/d/optout.

-- 

--- 
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/d/optout.

[ossec-list] Having to restart ossec server on a daily basis for clients to report.

2014-07-16 Thread Nick Souza 
Am facing an issue of having to restart ossec server on a daily basis for 
clients to report. If not they all show as inactive. As soon as I run the 
restart command on the server the agents start to report. Am using ossec 
2.6. Has anyone faced this problem? Any help would be appreciated.

-- 

--- 
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/d/optout.

Re: [ossec-list] Is it not possible to do an unattended second install of OSSEC on a system?

2014-07-16 Thread dan (ddp) 
On Tue, Jul 15, 2014 at 7:24 PM, Garett Shulman
 wrote:
> Hello,
>
> I am trying to do an unattended install of a second instance of OSSEC on an
> Ubuntu system.
>
> I'm trying to modify etc/preloaded-vars.conf based on
> http://ossec-docs.readthedocs.org/en/latest/manual/installation/install-source-unattended.html
> to accomplish this.
>
> However, the fact that there is already an instance of ossec installed seems
> to cause USER_NO_STOP="y" to be ignored by install.sh which asks if it
> should update.
>
>
> And according to the unattended docs: If USER_UPDATE is set to anything, the
> update installation will be done.
>
>
> This would seem to imply that there is no way to force USER_UPDATE to 'n' as
> any value is interpreted as affirmative.
>
>
> I can install the second instance of OSSEC fine interactively.
> Disappointing that it doesn't seem possible to accomplish unattended.
>
>
> Am I interpreting this correctly?  Anything I may be missing to accomplish
> this?
>
>
> Any assistance greatly appreciated.
>

I don't think this is a situation that was thought of when the support
was originally developed. If you have any patches, please submit them
through a pull request on http://www.github.com/ossec/ossec-hids

> -Garett
>
>
> --
>
> ---
> 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/d/optout.

-- 

--- 
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/d/optout.

Re: [ossec-list] Ossec compatibility with Redhat

2014-07-16 Thread dan (ddp) 
On Wed, Jul 16, 2014 at 3:35 AM, Amritha Kumar
 wrote:
> Hi,
>
> One of my customer has installed Ossec on a RedHat server RHEL 5.4. Now this
> server needs to patched as per PCIDSS requirements. The current RedHat OS
> version is RHEL 5.4, once patched the version will be 5.10. Please let us
> know if Ossec v2.6 is compatible with RHEL 5.10.
>

Out of curiosity, what makes you think it might not work? Was there an
issue on the test systems?

>
>
> Thanks & Regards
>
> Amritha Kumar
>
> --
>
> ---
> 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/d/optout.

-- 

--- 
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/d/optout.

Re: [ossec-list] Ossec compatibility with Redhat

2014-07-16 Thread Eero Volotinen 
2014-07-16 10:35 GMT+03:00 Amritha Kumar :

> Hi,
>
> One of my customer has installed Ossec on a RedHat server RHEL 5.4. Now
> this server needs to patched as per PCIDSS requirements. The current RedHat
> OS version is RHEL 5.4, once patched the version will be 5.10. Please let
> us know if Ossec v2.6 is compatible with RHEL 5.10.
>
>
>
Yes, it is compatible. Note that you should also update ossec to latest
stable as required in PCI DSS patch requirements.

--
Eero

-- 

--- 
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/d/optout.

[ossec-list] Ossec compatibility with Redhat

2014-07-16 Thread Amritha Kumar 
 

Hi,

One of my customer has installed Ossec on a RedHat server RHEL 5.4. Now 
this server needs to patched as per PCIDSS requirements. The current RedHat 
OS version is RHEL 5.4, once patched the version will be 5.10. Please let 
us know if Ossec v2.6 is compatible with RHEL 5.10.

 

Thanks & Regards

Amritha Kumar

-- 

--- 
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/d/optout.