[ossec-list] queue/ossec/queue' not accessible after fresh install

[Barry Kaplan]

I just lost our instance the runs ossec. I tried to reconfigure using 
persistent disk, but ran into all kinds of queue problems. So I create a 
fresh install and am getting this error

2017/03/08 07:56:08 ossec-syscheckd(1210): ERROR: Queue 
'/data/ossec/queue/ossec/queue' not accessible: 'Queue not found'.
2

Indeed queue/ossec/queue does not exist. The queue/ossec directory is 
empty. 

What creates those queues?

-- 

--- 
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] CDB Lists and MD5 checksums

[BJ]

I've seen the possibility mentioned in this forum a couple of times 
regarding adding the ability to check an MD5sum CDB list with rules. Right 
now, I'm in a situation where I could use that ability. However, I can't 
see anywhere that describes how to use it. Was that ever implemented? 
Frankly, I'm interested enough in this feature that I'd do it myself if I 
could, but I don't know C/C++, and only do scripting in Python. 

I'm trying to monitor a web folder for changes, but of course I don't want 
to be alerted on every file when a releases is done (they can be done at 
any time of day too). I can get md5 sums of each of the files prior to the 
release to whitelist them for ossec, but I can't seem to figure out how to 
tell ossec to use that database. Any help would be appreciated.

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

Re: [ossec-list] Potential Bug: Windows Security Event ID 5140 incorrectly parsed by OSSEC.

[Jahchan, Georges J.]

I have no issues with creating decoders and rules, been doing it for years.

But these do not make up for event information that the agent fails to
include in the event that it forwards to the OSSEC server. That is where
the problem lies -- agent-side /not/ server-side.

In the case of WMI, sufficient detail is forwarded. But in the case of
AppLocker, the information forwarded by the agent is woefully deficient.

In the environment, sudowin is utilized to elevate privileges. So the
user name _can__not_ be a criteria that allows the determination of
whether a user is privileged or not. In regulated environments this is
crucial. The Logon ID is what allows us to distinguish between
unprivileged and privileged user sessions for the same Account Name
/and/ Security ID. In the XML event, it reports the logon ID plus
rule/policy information. All that the agent sends upstream is the user
name and application path, and whether it was blocked, allowed, or
allowed in audit mode. Better than nothing, but not good enough. Lots
more information is definitely lurking in XML, and it is /not/ being
picked up by the agent.

Seems to me the agent is picking up the eventlog and not the
eventchannel. For WMI, there is little difference. between the two But
for AppLocker the story differs
 eventlog is truly minimal.

- <#> 

[ossec-list] Re: OSSEC IDS on Windows only sending Error logs

[Ed Davison]

Thanks; I will look into that and see what the logs show.


On Tuesday, March 7, 2017 at 4:30:09 AM UTC-6, InfoSec wrote:
>
> To gain visibility into what is going on at the agent side, turn on debug 
> mode on the agent.
>
> In C:\Program Files (x86)\ossec-agent\internal_options.conf change:
>
> # Windows debug (used by the windows agent)
> windows.debug=0
> to
> # Windows debug (used by the windows agent)
> windows.debug=2
>
> and restart the agent. It will log all events it picks up in the agent log 
> file: C:\Program Files (x86)\ossec-agent\ossec.log (Don't do it on a busy 
> production system!)
>
> By examining events in ossec.log, you will know what the agent is picking 
> up, and should be able to determine whether you are faced with an agent 
> issue, or a server issue.
>

-- 

--- 
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 IDS on Windows only sending Error logs

[lostinthetubez]

Hi Ed,

 

A couple things that might help here. When you enable logall, you’ll want to 
look inside archives.log, not alerts.log. Assuming this wasn’t a typo, here’s a 
few things that might help with your problem:

 

If you go look at your msauth_rules.xml file, you’ll note that OSSEC receives 
INFORMATION and WARNING events as level 0 alerts, meaning they aren’t retained. 
To change this, add the following to your local_rules.xml file and restart 
OSSEC services:

 





18100

^INFORMATION

Windows informational event.



 





18100

^WARNING

Windows warning event.



 

Retaining all warning logs is a reasonable approach, but retaining 
informational logs in a large deployment will get rather noisy rather quickly. 
You might just consider creating another custom rule looking for exactly what 
you want:



18101

^4$

The backup operation has finished successfully

A backup has completed successfully.

alert_by_email



 



18103

^5$

backup

A backup has failed. Please 
investigate.



 

In addition, I don’t believe OSSEC recognizes CRITICAL events. These are for 
things like unclean reboots.



18100

^CRITICAL

Windows critical event

NOTE: you can’t analyze logs written before OSSEC starts unless you 
are using eventchannel to monitor the system logs

system_error,



 

 

From: ossec-list@googlegroups.com [mailto:ossec-list@googlegroups.com] On 
Behalf Of Ed Davison
Sent: Wednesday, March 1, 2017 3:40 PM
To: ossec-list 
Subject: [ossec-list] OSSEC IDS on Windows only sending Error logs

 

I have OSSEC 2.8.3 installed on a Windows 2012R2 server and have added an 
eventchannel localfile option to gather logs from "Microsoft-Windows-Backup" 
log.  No errors on startup.

 

On the OSSIM side, I have logall enabled and am checking alerts.log file and 
can ONLY see Error logs being forwarded, not Information or Warning logs.  I 
need these latter as that is where the successful and successful with warning 
errors are logged as well as a backup was configured or cancelled.

 

How can I get ALL of the logs for all log severities sent to OSSIM using 2.8.3 
OSSEC for Windows and eventchannel?

 

Thanks in advance.

-- 

--- 
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] Re: syscheckd causing soft lockups

[John Gelnaw]

to follow up to my own post-- First, the problem was indeed happening 
during ossec-rootcheck, but I was unable to determine what was failing.

Secondly, the affected servers all were at one time or another, exporting a 
CIFS or NFS share.  Disabling the share didn't prevent ossec-rootcheck from 
crashing.

Reading the docs on 2.9.0, I thought the "skip_nfs" option might be 
helpful, so I upgraded-- but the problem went away before I enabled 
skip_nfs.

So upgrading seems to have solved the problem, but I don't know why.

-- 

--- 
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: OSSEC IDS on Windows only sending Error logs

[InfoSec]

To gain visibility into what is going on at the agent side, turn on debug 
mode on the agent.

In C:\Program Files (x86)\ossec-agent\internal_options.conf change:

# Windows debug (used by the windows agent)
windows.debug=0
to
# Windows debug (used by the windows agent)
windows.debug=2

and restart the agent. It will log all events it picks up in the agent log 
file: C:\Program Files (x86)\ossec-agent\ossec.log (Don't do it on a busy 
production system!)

By examining events in ossec.log, you will know what the agent is picking 
up, and should be able to determine whether you are faced with an agent 
issue, or a server issue.

-- 

--- 
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] Dynamic values in regex inside OSSEC rules?

[Jahchan, Georges J.]

Hello Jesus,

Following is the design recipe for an /advanced/ OSSEC correlation engine.

The engine is to have the following capabilities:
   i) Look forward and look back: Wait a certain time for next events,
-or- look back a certain time for previous events.
  ii) Conditions based on the content of decoded fields.
 iii) More than one condition can be specified simultaneously.
 iv) Boolean logic (at least the basic AND, OR, NOT) can be used in
conditions. Add regex to provide a further boost in capabilities.
  v) Stickiness: multiple occurrences of events with a field content
that matches (or does not match) that of the previous event in the sequence.
  Ex: Look for multiple occurrences of same events with same
IP/different port, or different IP/same port.
 vi) Generate a new custom event with a predefined alert level when a
correlation level is matched.
vii) Alert by e-mail (&/or SMS) when a correlation level is matched.

_Example_:
Correlation Trigger:
- Rule Level 1: X occurrences of event A matching one or more conditions
within a specified timeout period.
  Can be a single occurrence, at which time the Level 1 timeout becomes
irrelevant, level 2 timer kicks in.
  - Rules Level 2: Within XX seconds of matching Level 1 -or- in the XX
seconds preceding matching of Level 1, look for:
- Branch A - XX occurrences of:
  - Event B with 1 or more conditions relating to Level 1; -and-
  - Event C with 1 or more conditions relating to Level 1; -or-
  - ...
- Rules Level 3: Within XX seconds of matching Level 2 Branch A
-or- in the XX seconds preceding matching Level 2 Branch A, look for:
  - Branch C - XX occurrences of:
- Event D with 1 or more conditions relating to higher-level
events in this tree; -and-
- Event E with 1 or more conditions relating to higher-level
events in this tree; -or-
- ...
  *OR*
  - Branch D - XX occurrences of:
- Event F with 1 or more conditions relating to higher-level
events in this tree; -and-
- Event G with 1 or more conditions relating to higher-level
events in this tree; -or-
- ...
*OR*
- Branch B - XX occurrences of:
  - Event H with 1 or more conditions relating to Level 1; -and-
  - Event I with 1 or more conditions relating to level 1; -or-
  - ...
- Rules Level 3: Within XX seconds of matching Level 2 Branch B
-or- in the XX seconds preceding matching of Level 2 Branch B, look for:
  - Branch E - XX occurrences of:
- Event J with 1 or more conditions relating to higher-level
events in this tree; -and-
- Event K with 1 or more conditions relating to higher-level
events in this tree; -or-
- ...
  *OR*
  - Branch F - XX occurrences of:
- Event L with 1 or more conditions relating to higher-level
events in this tree; -and-
- Event M with 1 or more conditions relating to higher-level
events in this tree; -or-
- ...

Conditions for Branches at the same correlation level must be _mutually
exclusive_.

Example: if a condition for Branch A is 'audit success', for Branch B it
would be 'audit failure'. An event can be an audit success, or an audit
failure, _it cannot be both_. So at level 2 and below, the correlation
engine logic must branch to _only one Branch at a given level_. There
can be NO overlap between Branches at the same level. It is the
responsibility of the individual designing the correlation logic to
ensure the sanity of the logic behind it. Within a Branch, it is OK if
more than one rule matches.

Level 3 comes below Level 2 Branch A, and another Level 3 may come below
Level 2 Branch  B. Since Branch A and Branch B are mutually exclusive,
Branch C and Branch D at level 3 could be the same under branch A and
Branch B. Following the same principles, level 4 comes below level 3,
etc... As many levels as necessary can be defined.

Such an engine would allow alerting to:
  - Suspicious low and slow activity that attempts to remain below the
security monitoring radar -- provided one knows what to look for.
  - Scenarios with exponential growth in network connections (such as a
worm infection spreading).
  - Scenarios where a rapid recurrence of specific events occurs on
hosts (such as a ransomware infection).
  - Network footprinting: scans for a specific destination port on
multiple destination IPs.
  - Network footprinting: scans for a wide range of destination ports on
a single destination IP.
  - Dictionary attacks: repeated authentication failures from same
source targeting the same account name for all occurrences.
  - Dictionary attacks: repeated authentication failures from same
source targeting a different account name for each occurrence.

- When a correlation level is matched, if within the specified timeout
period (forward or backward) all the branches for the
  level below do not match, remove from correlation.
- A