Re: [ossec-list] CDB Lists and MD5 checksums

[BJ]

Thank you Pedro. That's good information.

With that in mind, I've decided to give this a 
try: 
https://blog.rootshell.be/2013/05/13/improving-file-integrity-monitoring-with-ossec/

Basically, he patched the code to make it look at a sqlite3 database prior 
to alerting.

Unfortunately, the code is a bit old, and I'm not sure he included all of 
the steps. I couldn't use his patch because I wanted the latest code, so I 
created my own based on his (attached). And although I have installed 
libsqlite3-dev, it fails to compile. I keep getting the following, which 
suggests it isn't pulling the code in from sqlite3.h for some reason.

/usr/local/src/ossec-hids-2.8.3/src/analysisd/decoders/syscheck.c:845: 
undefined reference to `debug0'
/usr/local/src/ossec-hids-2.8.3/src/analysisd/decoders/syscheck.c:849: 
undefined reference to `sqlite3_open'
/usr/local/src/ossec-hids-2.8.3/src/analysisd/decoders/syscheck.c:852: 
undefined reference to `sqlite3_prepare_v2'
/usr/local/src/ossec-hids-2.8.3/src/analysisd/decoders/syscheck.c:854: 
undefined reference to `sqlite3_step'
/usr/local/src/ossec-hids-2.8.3/src/analysisd/decoders/syscheck.c:859: 
undefined reference to `sqlite3_finalize'
/usr/local/src/ossec-hids-2.8.3/src/analysisd/decoders/syscheck.c:860: 
undefined reference to `sqlite3_close'
/usr/local/src/ossec-hids-2.8.3/src/analysisd/decoders/syscheck.c:861: 
undefined reference to `debug0'
/usr/local/src/ossec-hids-2.8.3/src/analysisd/decoders/syscheck.c:865: 
undefined reference to `sqlite3_finalize'
/usr/local/src/ossec-hids-2.8.3/src/analysisd/decoders/syscheck.c:866: 
undefined reference to `sqlite3_close'

Now, I haven't coded in C since high school? Like 20 years ago. I 
remember some things, and have googled others, but I'm in over my head. I 
can't seem to figure out how to fix this, or what I might have done wrong. 
FYI, I'm on Ubuntu 16.04. 

If anyone could help me, I'd appreciate it.

Thanks,
BJ

On Wednesday, March 8, 2017 at 9:14:45 AM UTC-7, Pedro Sanchez wrote:
>
> Hi,
>
> I like your intention to create a whitelist for checksum using CDB lists, 
> I think it will be a great functionality. Unfortunately you won't be able 
> to do it, since OSSEC lists does not allow to match using 
> "syscheck.md5_after" field.
> You can check here the available fields for matching a CDB List: 
> https://github.com/wazuh/wazuh/blob/master/src/analysisd/rules.c#L665 
> (srcip, srcport, dstip, dstport, user, url, id, hostname, program_name, 
> status and action)
>
> Beside that, if somehow we add the funcionallity to match for that field, 
> you could use a negative key match, adding the list sentence to syscheck 
> rule 550.
>
> Negative key match: 
> http://ossec-docs.readthedocs.io/en/latest/manual/rules-decoders/rule-lists.html#negative-key-match
>
> Rule 550 for syscheck integrity checksum changed, will trigger only if 
> they md5 checksum is not present on the CDB list, how it would look like:
>
> 
>> ossec
>> syscheck_integrity_changed
>> *> lookup="not_match_key">etc/lists/whitelist_md5*
>> Integrity checksum changed.
>> syscheck,pci_dss_11.5,
>> 
>
>
> *whitelist_md5*
>
> d41d8cd98f00b204e9800998ecf8427a:file1
>> d41d8cd98f00b204e9800998ecf8427b:file2
>> d41d8cd98f00b204e9800998ecf8427c:file3
>> d41d8cd98f00b204e9800998ecf8427d:file4
>
>
> ossec.conf
>
>> *etc/lists/whitelist_md5*
>
>
> *Compile CDB List*
>
>> /var/ossec/bin/ossec-makelists
>
>
>  
>  Maybe someone figure out a different way to do this.
>
> Regards,
> Pedro Sanchez.
>
>
>
> On Wed, Mar 8, 2017 at 1:13 AM, BJ  
> wrote:
>
>> 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+...@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 

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

[Grant Leonard]

I am in EST and I absolutely agree with you. I think we should spend no 
more than 30 minutes looking at your discovery, looking at logs in 
archives.log then , as you noted, requesting an enhancement to ensure those 
log values are sent over by the agent.

All the best

Grant Leonard
Castra Consulting, LLC 


On Tuesday, March 7, 2017 at 5:38:02 PM UTC-5, InfoSec wrote:
>
> 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.
>
> - <#5116bc32-52df-0ed9-7252-dadf18cdb890@Compucenter.org_>  xmlns="*http://schemas.microsoft.com/win/2004/08/events/event 
> *">
> - <#5116bc32-52df-0ed9-7252-dadf18cdb890@Compucenter.org_> 
>
>   8003 
>   0 
>   3 
>   0 
>   0 
>   0x8000 
>
>   3367 
>
>
>   Microsoft-Windows-AppLocker/EXE and DLL 
>   Desktop 
>
>   
> - <#5116bc32-52df-0ed9-7252-dadf18cdb890@Compucenter.org_> 
> - <#5116bc32-52df-0ed9-7252-dadf18cdb890@Compucenter.org_> <
> RuleAndFileData 
> xmlns="*http://schemas.microsoft.com/schemas/event/Microsoft.Windows/1.0.0.0 
> *">
>   EXE 
>   {----} 
>   - 
>   - 
>   S-1-5-21-XX-XX-XX- 
>   18476 
>   
> %OSDRIVE%\USERS\\APPDATA\LOCAL\CITRIX\GOTOMEETING\6441\G2MUPDATE.EXE
>  
>   
> 27BACB741B3A46B326905C18E67D809404FD69578711E00C94CB00067AE79899 > 
>   O=CITRIX ONLINE, L=FORT LAUDERDALE, S=FLORIDA, 
> C=US\GOTOMEETING\G2M.EXE\8.0.0.6441 
>   0x3147a4 
>   
>   
>   
>
> Yet, the following is all the agent picks up:
>
> Log Name:  Microsoft-Windows-AppLocker/EXE and DLL
> Source:Microsoft-Windows-AppLocker
> Date:  2017-03-07 23:48:00
> Event ID:  8003
> Task Category: None
> Level: Warning
> Keywords:  
> User:  DOMAIN\User
> Computer:  Computer
> Description:
> %OSDRIVE%\USERS\\APPDATA\LOCAL\CITRIX\GOTOMEETING\6441\G2MUPDATE.EXE 
> was allowed to run but would have been prevented from running if the 
> AppLocker policy were enforced.
>
> Open to a G2M to exchange info if you feel it necessary to move forward.
>
> Which time zone are you in?
> --
>

-- 

--- 
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: queue/ossec/queue' not accessible after fresh install

[Victor Fernandez]

Hi Barry,

File /var/ossec/etc/local_decoder.xml must exist and contain at less one 
decoder, although it is a dummy one, for example:


local_decoder_example



Try to create that file and fill it with the content above and restar ossec 
with: /var/ossec/bin/ossec-control restart.

Hope it help.
Best regards.

On Wednesday, March 8, 2017 at 12:41:27 AM UTC-8, Barry Kaplan wrote:
>
> Looks like the config entries for local_decor was the culprit. Not sure 
> why that did not cause a problem the first time ossec was installed.
>
> On Wednesday, March 8, 2017 at 9:26:49 AM UTC+1, Barry Kaplan wrote:
>>
>> The only errors on ossec. log not about queues is 
>>
>> 2017/03/08 08:06:38 ossec-analysisd(1226): ERROR: Error reading XML file 
>> 'etc/local_decoder.xml
>> ': XMLERR: File 'etc/local_decoder.xml' not found. (line 126).
>> 2017/03/08 08:06:38 ossec-analysisd(1202): ERROR: Configuration error at 
>> 'etc/local_decoder.xml
>> '. Exiting.
>>
>>
>>
>>

-- 

--- 
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.

[Grant Leonard]

I am in EST and I absolutely agree with you. I think we should spend no
more than 30 minutes looking at your discovery, looking at logs in
archives.log then , as you noted, requesting an enhancement to ensure those
log values are sent over by the agent.

All the best



Grant Leonard
Castra Consulting, LLC 
SOC : +1 919 595 8560
cell : +1 919 949 4002

On Tue, Mar 7, 2017 at 5:37 PM, Jahchan, Georges J. <
gjahc...@compucenter.org> wrote:

> 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.
>
> - <#m_7888497442240393591_>  xmlns="*http://schemas.microsoft.com/win/2004/08/events/event
> *">
> - <#m_7888497442240393591_> 
>   
>   8003
>   0
>   3
>   0
>   0
>   0x8000
>   
>   3367
>   
>   
>   Microsoft-Windows-AppLocker/EXE and DLL
>   Desktop
>   
>   
> - <#m_7888497442240393591_> 
> - <#m_7888497442240393591_>  xmlns="*http://schemas.microsoft.com/schemas/event/Microsoft.Windows/1.0.0.0
> *">
>   EXE
>   {----}
>   -
>   -
>   S-1-5-21-XX-XX-XX-
>   18476
>   %OSDRIVE%\USERS\\APPDATA\LOCAL\CITRIX\
> GOTOMEETING\6441\G2MUPDATE.EXE
>   27BACB741B3A46B326905C18E67D809404FD69578711E00C94
> CB00067AE79899
>   O=CITRIX ONLINE, L=FORT LAUDERDALE, S=FLORIDA,
> C=US\GOTOMEETING\G2M.EXE\8.0.0.6441
>   0x3147a4
>   
>   
>   
>
> Yet, the following is all the agent picks up:
>
> Log Name:  Microsoft-Windows-AppLocker/EXE and DLL
> Source:Microsoft-Windows-AppLocker
> Date:  2017-03-07 23:48:00
> Event ID:  8003
> Task Category: None
> Level: Warning
> Keywords:
> User:  DOMAIN\User
> Computer:  Computer
> Description:
> %OSDRIVE%\USERS\\APPDATA\LOCAL\CITRIX\GOTOMEETING\6441\G2MUPDATE.EXE
> was allowed to run but would have been prevented from running if the
> AppLocker policy were enforced.
>
> Open to a G2M to exchange info if you feel it necessary to move forward.
>
> Which time zone are you in?
> --
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ossec-list" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/ossec-list/GnA9qGZw9MU/unsubscribe.
> To unsubscribe from this group and all its topics, 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] Re: Implementing ossec-local at scale in Docker containers

[Victor Fernandez]

Hi Sushan,

I think that embedding a local OSSEC into every container is not the best 
approach, IMHO. In fact, the Docker's "best practices" guideline recommends 
to have one process per container, this could mean one service per 
container.

Since agents can auto-register via ossec-authd, you could run a single 
manager with Authd. Containers may include an agent that auto-registers and 
sends logs to that manager.

I did some experiments with a configuration like this:

- Container for pure manager (remoted + analysisd) and Filebeat.
- Container for Authd (auto registration), sharing folder /var/ossec/etc.
- Container for Elasticsearch.
- Container for Kibana.

You may choose between embed an agent into each container, or as John said, 
configure containers to write the stdout into the host's syslog and install 
a single local OSSEC on the host. On the other hand, this option would make 
hard to do file integrity monitoring.

Best regards.


On Wednesday, March 8, 2017 at 9:03:34 AM UTC-8, Sushan Ghimire wrote:
>
> I am struggling to find a good read on pros and cons of running OSSEC on 
> Docker containers. 
>
> I am looking to implement intrusion detection on underlying hosts and not 
> on the containers. All applications run on containers but are orchestrated 
> by a orchestrator, therefore threat level is considered low. 
>
> Because the solution needs to be highly available, I think installing 
> ossec-local is more appropriate to the use case. On the server/client 
> model, it appears that agents need to be registered to server and server 
> then does heavy lifting. I want to send logs from ossec-local to Splunk (or 
> other monitoring/alerting tools).
>
> And finally, I have been instructed to run OSSEC on Docker containers. The 
> logic behind that is, everything runs on containers. In my head that is an 
> anti-pattern - containers are for isolation, an isolated process should not 
> be watching hosts. Or maybe it should? Depending on the rules to be 
> implemented, it sounds like I would need to map multiple volumes. 
>
> Does anyone have experience of similar use case? Any pointers/links and 
> thoughts will be highly appreciated. 
>
> When I am done, I will share my learnings in a blog. 
>

-- 

--- 
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: Implementing ossec-local at scale in Docker containers

[John Gelnaw]

Running the ossec server in a docker container, makes sense, and I run the 
Wazuh fork of ossec in their provided container with logstash / kibana4.

Running ossec agent in a container makes no sense to me.

I would suggest instead that you use the docker logging driver to reroute 
stdout from your containers to syslog, and run ossec agent on your docker 
host, if you want to monitor your containers.

Regardless, running the agent within a container will make it highly 
problematic to monitor the underlying host.



-- 

--- 
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] Implementing ossec-local at scale in Docker containers

[Sushan Ghimire]

I am struggling to find a good read on pros and cons of running OSSEC on 
Docker containers. 

I am looking to implement intrusion detection on underlying hosts and not 
on the containers. All applications run on containers but are orchestrated 
by a orchestrator, therefore threat level is considered low. 

Because the solution needs to be highly available, I think installing 
ossec-local is more appropriate to the use case. On the server/client 
model, it appears that agents need to be registered to server and server 
then does heavy lifting. I want to send logs from ossec-local to Splunk (or 
other monitoring/alerting tools).

And finally, I have been instructed to run OSSEC on Docker containers. The 
logic behind that is, everything runs on containers. In my head that is an 
anti-pattern - containers are for isolation, an isolated process should not 
be watching hosts. Or maybe it should? Depending on the rules to be 
implemented, it sounds like I would need to map multiple volumes. 

Does anyone have experience of similar use case? Any pointers/links and 
thoughts will be highly appreciated. 

When I am done, I will share my learnings in a blog. 

-- 

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

[Pedro Sanchez]

Hi,

I like your intention to create a whitelist for checksum using CDB lists, I
think it will be a great functionality. Unfortunately you won't be able to
do it, since OSSEC lists does not allow to match using "syscheck.md5_after"
field.
You can check here the available fields for matching a CDB List:
https://github.com/wazuh/wazuh/blob/master/src/analysisd/rules.c#L665
(srcip, srcport, dstip, dstport, user, url, id, hostname, program_name,
status and action)

Beside that, if somehow we add the funcionallity to match for that field,
you could use a negative key match, adding the list sentence to syscheck
rule 550.

Negative key match:
http://ossec-docs.readthedocs.io/en/latest/manual/rules-decoders/rule-lists.html#negative-key-match

Rule 550 for syscheck integrity checksum changed, will trigger only if they
md5 checksum is not present on the CDB list, how it would look like:


> ossec
> syscheck_integrity_changed
> * lookup="not_match_key">etc/lists/whitelist_md5*
> Integrity checksum changed.
> syscheck,pci_dss_11.5,
> 


*whitelist_md5*

d41d8cd98f00b204e9800998ecf8427a:file1
> d41d8cd98f00b204e9800998ecf8427b:file2
> d41d8cd98f00b204e9800998ecf8427c:file3
> d41d8cd98f00b204e9800998ecf8427d:file4


ossec.conf

> *etc/lists/whitelist_md5*


*Compile CDB List*

> /var/ossec/bin/ossec-makelists



 Maybe someone figure out a different way to do this.

Regards,
Pedro Sanchez.



On Wed, Mar 8, 2017 at 1:13 AM, BJ  wrote:

> 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.
>

-- 

--- 
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: queue/ossec/queue' not accessible after fresh install

[Barry Kaplan]

Looks like the config entries for local_decor was the culprit. Not sure why 
that did not cause a problem the first time ossec was installed.

On Wednesday, March 8, 2017 at 9:26:49 AM UTC+1, Barry Kaplan wrote:
>
> The only errors on ossec. log not about queues is 
>
> 2017/03/08 08:06:38 ossec-analysisd(1226): ERROR: Error reading XML file 
> 'etc/local_decoder.xml
> ': XMLERR: File 'etc/local_decoder.xml' not found. (line 126).
> 2017/03/08 08:06:38 ossec-analysisd(1202): ERROR: Configuration error at 
> 'etc/local_decoder.xml
> '. Exiting.
>
>
>
>

-- 

--- 
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: queue/ossec/queue' not accessible after fresh install

[Barry Kaplan]

Actually all the queue directories are empty.

-- 

--- 
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.