[ossec-list] Monitoring Users loggin on and off from Active Directory.

[Kyriakos Stavridis]

Hello everyone.

I am trying to use OSSEC to monitor the logons and logoffs by employees on 
our Active Directory server.

The problem is that there is too much noise generated by the AD and I 
cannot find a way to isolate the events I need monitored to get the correct 
results.

The AD server generates about 5-6 events everytime a user logs on or logs 
off (logon Event ID 4624, logoff Event ID 4634).

The desirable result is to have alerts like : "User 'X' performed a logon" 
/ "User 'X' performed a logoff".

OSSEC by default has windows logon and logoff rules (4624, 4634) but they 
trigger at each event with these IDs and you cannot have a specific result, 
too much noise is generated.

Has anyone implemented successfully the monitoring of user logons/logoffs 
to the AD server with OSSEC? How can I isolate the noise and get the 
desirable results?

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ossec-list/ac693020-d0a5-4d05-ab24-a94005757741%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ossec-list] Re: how to configure ossec headless linux agent

[dan (ddp)]

Thanks for including your notes (some comments in-line).
I'll try to add some kind of walk through to the documentation when I
can make time for it.

On Thu, May 30, 2019 at 2:53 PM Kris Springer
 wrote:
>
> Thanks Dan.  I've got it figured out now.  Here's my instructions for anyone 
> else who comes across this thread.
> 
>
> The Security Onion server already has the Ossec Server running.  You must 
> define each client, called an ‘agent’ that is allowed to send info to the 
> server.
>
>
> On the Security Onion Server
>
> You must make sure UDP port 1514 is allowed on the server or it won’t allow 
> agents to connect.
>
> $ sudo ufw status
>
> $ sudo ufw allow 1514/udp
>
> $ sudo ufw status
>
>
> Add a new agent (client machine)
>

This is actually the manage_agents menu from the server.
The agent's manage_agents should only have:

* OSSEC HIDS v3.2.0 Agent manager. *
* The following options are available: *

   (I)mport key from the server (I).
   (Q)uit.


> $ sudo /var/ossec/bin/manage_agents
>
> L lists all agents (clients) that are currently configured
>
> A add an agent
>
> Name the new agent. This can be any name, but ideally it should be the FQDN 
> if its a server.
>
> Define the static IP the agent will be coming from.  It must have the subnet 
> slash on the end.
>

If that's true, then there is a regression somewhere (or it's a wazuh change).
It's never needed the subnet stuff on complete IP addresses in the past.

> Every agent gets a unique 3 digit ID number.
>
> Click here to see all syntax options
>
> [sample]
>
> LinuxServer1
>
> 10.11.12.33/24   (can also be ‘any’ if on DHCP. see syntax options)
>
>
> L to see the newly added agent in the list.
>
> E to get the Auth Key you need to copy and apply when installing on the client
>
> Q to quit the manager.
>
> Note: if removing agents, their ID numbers are not reusable.
>
>
> On the Linux Client machine (also known as the agent)
>
> Install instructions found here http://www.ossec.net/downloads/
>
>
> $ wget -q -O - https://updates.atomicorp.com/installers/atomic | sudo bash
>
> $ sudo apt update
>
> $ sudo apt install ossec-hids-agent
>
>
> Define the Security Onion Server IP address.
>
> $ sudo nano /var/ossec/etc/ossec.conf
>
>
> Import the Auth Key that you copied from the server.
>
> $ sudo /var/ossec/bin/manage_agents
>
>
> Start the ossec agent service.
>
> $ sudo service ossec start
>
> $ sudo service ossec status
>
>
> Check the logs to make sure it connected to the server.
>
> You may also see a few access errors for non-existent log files.
>
> $ sudo cat /var/ossec/logs/ossec.log
>
>
>
> View some logs on Security Onion Server
>
> Check the ‘HIDS’ alerts in Kibana to see if your new agent shows up as a new 
> connection.
>
>
>
> --
>
> ---
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/ossec-list/1b285f8a-ba13-45fd-9ce8-85ad6936b42c%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ossec-list/CAMyQvMpf2QoiLXfF-Msx1GHs7xB08z%2B5weRVmZ-HGAd3YjSqKw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ossec-list] Upgrading to version 3.3.0 from earlier release

[dan (ddp)]

On Tue, May 28, 2019 at 3:59 PM Buddha Man  wrote:
>
> I have some questions:
>
> Do changes need to be made to config files to activate or utilize the new 
> rules/decoders related to rootcheck, last root login, active response, PCRE2 
> reg ex engine, etc  in the new version?
>

rootcheck: It doesn't look like all of the audit files are added to
the configuration, so you may have to add them manually.
I'll have to look at the installation templates to see if they're
present on new installs, but there isn't a built-in way to update them
during upgrades.

active-response: I don't think anything changed beyond maybe a script
update. The scripts will be updated, so those changes should be used
by default.

PCRE2: I don't think there is anything using it in 3.3, but you may
have to run contrib/ossec-pcre2-config.pl on the OSSEC server.

> If yes, what are the recommended settings and how should each rule be 
> utilized?
>
> How are folks using active response be used on endpoints to fend off 
> potential attacks?
>
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/ossec-list/c79b2828-767e-43c5-a290-a0bcba3980a9%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ossec-list/CAMyQvMp6YdKOTQ2JyJd7CHBRSdWTwR%2Btve70qkC2MYnX1k1%2Bww%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[ossec-list] Re: Monitoring Users loggin on and off from Active Directory.

[Grant Leonard]

You are going to need to grab logs from the desktop as well, as those have 
the "unlock" and "lock"  instances, many times users remain logged in and 
you get tons of background authentication noise.

You can also marry that with Kerberos ticket requests, but that is a whole 
next level of noise.

One way to reduce the noise would be ignoring machine accounts (accounts 
ending in $), focusing on the specific user. Much of the noise is 
attributed to Audit Policies at the domain level as well, so getting that 
correctly tuned is key. 

My best results came from Audit Policies and matching specific desktop 
events with Domain logon/logoff , as you can then filter out the connection 
to shared drives and such

All the best

Grant

On Friday, May 31, 2019 at 4:21:05 AM UTC-4, Kyriakos Stavridis wrote:
>
> Hello everyone.
>
> I am trying to use OSSEC to monitor the logons and logoffs by employees on 
> our Active Directory server.
>
> The problem is that there is too much noise generated by the AD and I 
> cannot find a way to isolate the events I need monitored to get the correct 
> results.
>
> The AD server generates about 5-6 events everytime a user logs on or logs 
> off (logon Event ID 4624, logoff Event ID 4634).
>
> The desirable result is to have alerts like : "User 'X' performed a logon" 
> / "User 'X' performed a logoff".
>
> OSSEC by default has windows logon and logoff rules (4624, 4634) but they 
> trigger at each event with these IDs and you cannot have a specific result, 
> too much noise is generated.
>
> Has anyone implemented successfully the monitoring of user logons/logoffs 
> to the AD server with OSSEC? How can I isolate the noise and get the 
> desirable results?
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ossec-list/59bf0c74-9814-49f6-89ab-f41cb0b045b5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ossec-list] Ossec WebUI - 'Latest modified files (for all agents)' stopped updating

[Christina Wyndham]

We have been using ossec 2.8.2 for about 5 years now to monitor an array of 
25 servers in various locations without problems, until... May 19, around 2 
weeks ago.

Since then, per the subject line, we have seen no updates at all in the 
'Latest modified files (for all agents)'. The last entries there are for 
May 19, then nothing after that. Normally there is a list of file changes 
most days as you might expect.

However:

   - All of the agents continue to report in (the 'Main' tab shows a last 
   keep alive in the last few minutes for all agents)
   - Latest events shows a steady stream of current entries, so we're 
   confident that the agents are talking to the manager
   - Analogi shows a graphical analysis of recent events - but excluding 
   any file checksum change events

All systems (except for a couple of windows machines) are running Ubuntu or 
Debian.

We have tried restarting the Manager processes (many times), and also one 
local agent that we can easily monitor closely. We tried this process 

 
to empty and recreate the syscheck file for that one agent, and it 
successfully recreates the syscheck file for that agent but with only 2 
entries, but still I do not see anything in the 'Latest modified files (for 
all agents)'.

That two-entry result sounds like this issue 
,
 
except the OS and version are different there.

To answer the obvious question, we cannot find anything relevant that 
changed around that May 19 time, and for example I have done a find for 
ossec manager config files modified at that time or after - there are none 
(we do occasionally make edits to the configuration obviously).

To my eyes the manager logs do not show any messages related to our problem.

I am at a loss to know where to suggest we turn next in terms of debugging, 
and I would hugely appreciate any advice on where to look next for hints as 
to what our problem might be.

Thank you so much 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ossec-list/43d18657-889f-4cec-bbc2-345b519222d5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.