[ossec-list] Re: Monitoring Users loggin on and off from Active Directory.
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.
Re: [ossec-list] Looking for an older OSSEC version, 2.9.1 for MAC OS
Thank you sir, this is the source code, I was hoping for binaries as I am not really awesome at making them for Mac from scratch, I don't use that OS Thoughts? All the best Grant On Thursday, January 17, 2019 at 1:58:49 PM UTC-5, dan (ddpbsd) wrote: > > On Thu, Jan 17, 2019 at 1:48 PM Grant Leonard > > wrote: > > > > Does anyone know where I can find this version, if it even exists? > > > > Here you go: https://github.com/ossec/ossec-hids/releases/tag/2.9.1 > > > All the best > > > > Grant > > > > -- > > > > --- > > 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 https://groups.google.com/d/optout.
[ossec-list] Looking for an older OSSEC version, 2.9.1 for MAC OS
Does anyone know where I can find this version, if it even exists? All the best Grant -- --- 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 / alienvault - issues getting application logs to AlienVault
You need to make sure the numbers you picked for your new rules exist in a DS group and you have the correct translation statements in your .cfg.local file for the plugin. Also, to ensure you get a hit with the rule, your level has to be > 0 to be written to alerts.log You are closing in sir! Note that this is for OSSEC and not Alienvault. I happen to run both and know what you are doing, though this group might not be the best place for Alienvault related questions of OSSEC All the best Grant On Monday, February 5, 2018 at 6:07:21 PM UTC-5, Sam Wallace wrote: > > Currently I'm getting my application logs to my archives.log file, but not > my alerts.log file. When I run my event through ossec-logtest they make it > through phase 2 with my custom decoder I built and then they also make it > through phase 3 with the custom rule I built. > > Where do I go from here? Even though it hits a rule, it doesn't get > written to my alerts.log. Once I get it to alerts.log how do I go about > writing a plugin to capture this event and put it into AlienVault proper. > > Thank you! > -- --- 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] Format email output from ossec-reportd and category list
Thank you, I will try piping output somewhere else first. Please note the full list does not exist there, I started there, it shows category Filter by group/category. *Default value* n/a *Allowed values* Any category used is allowed. categories are then user defined, correct? I can grep for the existing list Thanks! On Thursday, November 9, 2017 at 8:52:08 AM UTC-5, dan (ddpbsd) wrote: > > On Tue, Nov 7, 2017 at 9:58 AM, Grant Leonard > <gr...@castraconsulting.com > wrote: > > > > Good morning > > > > After the /var/ossec/bin/ossec-reportd runs, the tallies are left > aligned > > and when emailed the spacing is not kept from stdout to email > > > > Thus stdout looks like this > > > > Top entries for 'Group': > > > > pci_dss_10.6.1 > > |801 | > > audit > > |799 | > > audit_selinux > > |799 | > > > > How ever email looks like this > > > > > > Top entries for 'Group': > > -- > > -- > > pci_dss_10.2.5 > > |110 | > > windows > > |110 | > > authentication_success > > |85 | > > > > > > How can we force "fixed width" or "Courier New" style formatting in > email to > > prevent this? > > > > I'm not sure there's a way to do that, not universally. You could pipe > the reportd output through a script that formats it nicer though. It > shouldn't be too difficult. > > > > > > > Additionally, what are the full list of categories found here > > > > > https://documentation.wazuh.com/2.0/user-manual/reference/ossec-conf/reports.html#category > > > > > I don't know about Wazuh, but for OSSEC they probably match the groups > and categories in the rules files. > > > 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 https://groups.google.com/d/optout.
[ossec-list] Format email output from ossec-reportd and category list
Good morning After the /var/ossec/bin/ossec-reportd runs, the tallies are left aligned and when emailed the spacing is not kept from stdout to email Thus stdout looks like this Top entries for 'Group': pci_dss_10.6.1 |801 | audit |799 | audit_selinux |799 | How ever email looks like this Top entries for 'Group': -- -- pci_dss_10.2.5 |110 | windows |110 | authentication_success |85 | How can we force "fixed width" or "Courier New" style formatting in email to prevent this? Additionally, what are the full list of categories found here https://documentation.wazuh.com/2.0/user-manual/reference/ossec-conf/reports.html#category 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.
[ossec-list] Re: regex not working
Out of curiosity, can you post the raw message here? I would like to know
what kind of log has "`" in it.
All the best
On Monday, September 25, 2017 at 4:23:30 AM UTC-4, Robert Necela wrote:
>
> Hello, i have message with character "`". But i can't write rule with such
> character. \. -> For anything not working and i can't find this character
> in \p -> ()*+,-.:;<=>?[]!"'#$%&|{} (punctuation characters)
>
> Thanks for any help
>
--
---
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] How to collect only syscheck and rootcheck logs
I turned them OFF this way. I am assuming you can declare just these options with no logging location and you will have the reverse of my config yes no no yes no no HKEY_LOCAL_MACHINE HKEY_USERS HKEY_CURRENT_CONFIG HKEY_CURRENT_USER HKEY_CLASSES_ROOT Grant On Thursday, September 14, 2017 at 9:38:48 AM UTC-4, dan (ddpbsd) wrote: > > On Tue, Sep 12, 2017 at 12:09 AM, vikas <srihar...@gmail.com > > wrote: > > Hi All, > > > > I am trying to collect only syscheck and rootcheck logs, and not the > > eventlogs in windows or any other log files in unix. I see some /var/log > > file locations declared in ossec.conf for linux that I can comment out, > but > > don't see an option to turn off the log collection for windows. The > > application, security and system logs are specified in > default-ossec.conf on > > the agent. How can I stop collecting these logs without having to touch > each > > agent? > > > > If you want to turn off the collection of logs on each agent, you'll > have to touch each agent. > I think removing the localfile options should be enough, but I haven't > tried it. > > > Thanks, > > Vikas. > > > > -- > > > > --- > > 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 https://groups.google.com/d/optout.
[ossec-list] ossec-agent buffer and/or cache configurations
Two specific questions Are the amount of logs cached/tracked configurable? (Specifically for linux agents) when the agent cannot reach the ossec-server (yes I read the discussion from 2010, looking for updated thoughts here) How, specifically, does the agent handle being down/restarted? For instance, ossec-agent is reading /var/log/syslog , we restart ossec-agent, where does the agent pick up in the /var/log/syslog file and HOW does it know where to pick up? Asking for 2.8.3 and forward please All the best -- --- 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.
Confirmed
George walked through the events with me. The event channel is read, though
in archives.log , post decryption, only part of the event is sent over. For
most events this is not an issue, but for Applocker and other more detailed
events writing to Event Channels, there is a second level of XML that has
VERY interesting traffic. There are some good security features in Windows
OS that are worth reading correctly with any tool.
It is worth noting that, It did not matter which rule set was being used,
this was an agent thing. (Default versus custom). Further in comparison
with another "open source windows event agent to syslog" utility, the same
issue was present.
Grant
On Wednesday, March 8, 2017 at 2:49:59 PM UTC-5, Grant Leonard wrote:
>
> 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 <http://castraconsulting.com/#/>
>
>
> 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.
>>
>> -
>> <#2edbed17-053f-42cd-9721-42470f5b8993@googlegroups.com_5116bc32-52df-0ed9-7252-dadf18cdb890@Compucenter.org_>
>>
>> http://schemas.microsoft.com/win/2004/08/events/event
>> <http://schemas.microsoft.com/win/2004/08/events/event>*">
>> -
>> <#2edbed17-053f-42cd-9721-42470f5b8993@googlegroups.com_5116bc32-52df-0ed9-7252-dadf18cdb890@Compucenter.org_>
>>
>>
>>
>> 8003
>> 0
>> 3
>> 0
>> 0
>> 0x8000
>>
>> 3367
>>
>>
>> Microsoft-Windows-AppLocker/EXE and DLL
>> Desktop
>>
>>
>> -
>> <#2edbed17-053f-42cd-9721-42470f5b8993@googlegroups.com_5116bc32-52df-0ed9-7252-dadf18cdb890@Compucenter.org_>
>>
>>
>> -
>> <#2edbed17-053f-42cd-9721-42470f5b8993@googlegroups.com_5116bc32-52df-0ed9-7252-dadf18cdb890@Compucenter.org_>
>>
>> > xmlns="*http://schemas.microsoft.com/schemas/event/Microsoft.Windows/1.0.0.0
>> <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> FileHash>
>> 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
Re: [ossec-list] Potential Bug: Windows Security Event ID 5140 incorrectly parsed by OSSEC.
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 <http://castraconsulting.com/#/>
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
> <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
> <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.
Re: [ossec-list] Potential Bug: Windows Security Event ID 5140 incorrectly parsed by OSSEC.
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 <http://castraconsulting.com/#/>
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
> <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
> <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.
Re: [ossec-list] Potential Bug: Windows Security Event ID 5140 incorrectly parsed by OSSEC.
We will take a stab at it this week and see what we can uncover All the best Grant On Friday, February 24, 2017 at 12:32:02 PM UTC-5, dan (ddpbsd) wrote: > > Any Windows users want to take a look at this? > > On Thu, Feb 23, 2017 at 11:42 PM, Jahchan, Georges J. > <gjah...@compucenter.org > wrote: > > I am using the eventchannel format. Eventlog provides no useful > information > > for logs other than the three basics: Application, Security and System. > > > > If confirmed, this is a significant bug that impacts the integrity of > all > > deployments of Windows agents, as far as I can determine at minimum on > > Windows 10, other versions are TBD. > > > > I unfortunately do not have at hand other versions of Windows to test > with, > > in order to determine whether it is an issue related to the agent that > > therefore impacts all Windows deployments, or a less serious issue that > is > > specific to Windows 10. > > > > IMHO the agent code needs to be thoroughly debugged, as: > > i) some events are forwarded correctly; > > ii) some have field names removed (which makes it very difficult to > decode > > for any information other than what is in the OSSEC header); and > > iii) some have important security information completely chopped off the > > message, that is in addition to missing field labels. > > > > On Windows 10, I can confirm (not an exhaustive list): > > i) The integrity of event IDs 4624, 4625, 4634, 4656~4663, 4688, 4689 > is > > preserved. > > ii) Event IDs 5140 and 4703 are forwarded without field labels (there > are > > certainly others). > > iii) Eventchannel logs other than the three standard event logs have no > > field labels, and are emptied of important security content. > > > > Steps to reproduce on any recent flavor of Windows: > > > > 1) From the Group Policy Editor turn on AppLocker in Audit mode, and > > temporarily turn on all auditing in Security. > > > > 2) Configure the agent to collect AppLocker logs (This is for Windows > 10, > > the log names differ for Windows 7): > > > > In /var/ossec/etc/shared/agent.conf > > > > > > > > eventchannel > > Microsoft-Windows-AppLocker/EXE and DLL > > > > > > eventchannel > > Microsoft-Windows-AppLocker/MSI and Script > > > > > > eventchannel > > Microsoft-Windows-AppLocker/Packaged > app-Deployment > > > > > > eventchannel > > Microsoft-Windows-AppLocker/Packaged > app-execution > > > > > > > > 3) Set the Windows agent to debug mode in internal_options.conf in the > > ossec-agent installation directory. > > > > 4) Restart the agent (net stop "OSSEC HIDS" then net start "OSSEC HIDS", > or > > use the agent control GUI, or Services .msc to bounce the agent). > > > > 5) Examine events in the ossec.log file inside the OSSEC-agent > installation > > directory. > > > > -- > > > > --- > > 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 https://groups.google.com/d/optout.
Re: [ossec-list] .txt file for log overwrites daily - ossec only reads once
Thanks, we will check into that today and see what we find. It appears it merely overwrites versus replacing though All the best Grant On Friday, February 24, 2017 at 9:50:12 PM UTC-5, Victor Fernandez wrote: > > Hi Grant, > > how is that file overwritten? I mean, is it truncated and re-written or is > replaced by another? > > OSSEC follows local files and never reads them again from the beginning, > there is no mechanism to detect that a previous file segment has been > changed. But OSSEC does detect that a file itself has been replaced by > checking the file inode. > > So if the file is replaced (it is first removed and then re-created, or > your benchmark writes on another log file that then is moved onto the > monitored file) OSSEC should detect it and read it again entirely. > > I hope that it help. > > On Thu, Feb 23, 2017 at 1:39 PM, Grant Leonard <gr...@castraconsulting.com > > wrote: > >> >> How can we get the ossec agent to read a localfile that overwrites itself? >> >> The CIS CAT benchmarks write a .txt file which we are reading with >> "syslog" as the local file >> >> However when the benchmark tests run, ossec does not appear to re-read >> the log, its as if it never gets read again. >> >> As it turns out, there is no date/time in the log. >> >> We have a decoder and rules that work, just need this last piece. >> >> Anyone run into this before? >> >> -- >> >> --- >> 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. >> > > > > -- > Victor M. Fernandez-Castro > IT Security Engineer > Wazuh Inc. > -- --- 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] .txt file for log overwrites daily - ossec only reads once
How can we get the ossec agent to read a localfile that overwrites itself? The CIS CAT benchmarks write a .txt file which we are reading with "syslog" as the local file However when the benchmark tests run, ossec does not appear to re-read the log, its as if it never gets read again. As it turns out, there is no date/time in the log. We have a decoder and rules that work, just need this last piece. Anyone run into this before? -- --- 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: Hacker or configuration error ?
Do you have a firewall at all ? Are any server ports exposed to the world? is it always /proc that is full? Where is all the space and how big is your hard drive? Could it be, given you are running a mail server, simply spam/email that has filled up your hard drive? This doesn't seem related to OSSEC at all to be honest On Saturday, November 28, 2015 at 8:36:52 AM UTC-5, Antoine wrote: > > Hello everyone, > > First of all, I would like to apologize for the quality of my english, > it's not my mother language. > > I'm sorry for the length, I tried to be quickest and detailed as possible. > > I need your advice on something. > > Until the 3rd august I had an home server running Debian Jessie. On the > 3rd august I discovered > it had been hacked the 2 august. I shut it down, and during the > following days I replaced the hard > drive of my desktop computer and reinstalled fresh Debian Jessie by > security. > > Then a friend told me about OSSEC and gave me a tutorial. During the 15 > following days I had > the same problem. After a fresh install of Debian Jessie, I set up every > security tools I know. > When I used OSSEC, after a random time, some minutes or some hours, my > system partition was filling > at a variable speed with directories in /proc or a subdirectory, if my > memory is correct. And when the system partition was full, when > rebooting I had an error message saying that X or KDE can't start because > of this lack of disk space. In august I was installing OSSEC with a > downloaded zip, v2.8.1. > > I had to go away around the 15 august and came back 1 month ago. When > being back I installed a fresh > Debian Jessie on my desktop computer, without OSSEC. I had a doubt about > my system, so yesterday morning I reinstalled another time my system and > followed the same tutorial for OSSEC. This time I installed > the v2.8.3 from the debian repos as indicated on the OSSEC website. > Yesterday night my disk was another > time full, unable to surf, I reboot and the same message appeared... > Yesterday night, I reinstalled Jessie again, with OSSEC but set up OSSEC > with an minimal config : email to, email from, smtp server. For the > moment, my disk isn't filling, I control from time to time with df -h. > > I really far of being a security expert, my skills are very low. > So my question is : by following this tutorial do I introduce a weird > behavior in OSSEC ? or someone > is having fun with my nerves by triggering something that fills my > system partition with bullshit ? > > The tuto I used : > > https://www.digitalocean.com/community/tutorials/how-to-set-up-a-local-ossec-installation-on-debian-8 > > > I have a fix ip that can't be modifed by my ISP. I still have a domain > name linked to my ip, > but before connecting to my account and change my domain parameters, I > want to be sure of my system... > > Thank you very much for the time you could spend to read and answer me. > > Antoine. > -- --- 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: Windows Event ID 4625
We addressed this using an OSSIM plugin to read a different part of the alert log Hope that helps sir Grant Leonard Castra Consulting, LLC <http://castraconsulting.com/#/> 919-949-4002 On Fri, Nov 20, 2015 at 12:28 PM, Joshua Roback <jrob...@gmail.com> wrote: > I have a decoder that grabs the appropriate Account Name, but have come > across another issue. Even if I am able to properly decoder "user", my > ossec alert.log does not correlate that to "user" unless it's in the > expected location in the WinEvtLog header. > > Raw Log > WinEvtLog: Security: AUDIT_SUCCESS(4725): > Microsoft-Windows-Security-Auditing: *(no user)*: no domain: > myhost.mydomain.com: A user account was disabled.Subject: Security > ID: S-1-5-21-789336058-1532298954-839522115-141077 Account Name: > *my_account*Account Domain: MYDOMAIN Logon ID: 0x23a80332 > Target Account:Security ID: > S-1-5-21-789336058-1532298954-839522115-60716 Account Name: my_account >Account Domain: MYDOMAIN > > Decoder: > > windows > Security ID:\s*\S*\s*Account > Name:\s*(\S\S+)\s+Account Domain:\s*(\S*) > user, extra_data > > > ossec-logtest output: > > **Phase 2: Completed decoding. >decoder: 'windows' >status: 'AUDIT_SUCCESS' >id: '4725' >extra_data: 'Microsoft-Windows-Security-Auditing' >system_name: 'myhost.mydomain.com' >*dstuser: 'my_account'* > > > > Alert.log > ** Alert ** > time: 1448030023 > hostname: (agent26) 0.0.0.0->WinEvtLog > location: (agent26) 0.0.0.0->WinEvtLog > rule_id: 18112 > rule_rev: 1 > rule_name: User account disabled or deleted. > rule_level: 8 > lrec_object_tag: user > lrec_action_tag: authentication delete > lrec_status_tag: success > lrec_action: review > event_id: 4725 > status: AUDIT_SUCCESS > data: Microsoft-Windows-Security-Auditing > systemname: myhost.mydomain.com > raw_log: > WinEvtLog: Security: AUDIT_SUCCESS(4725): > Microsoft-Windows-Security-Auditing: (no user): no domain: > myhost.mydomain.com: A user account was disabled.Subject: Security > ID: S-1-5-21-789336058-1532298954-839522115-141077 Account Name: > my_accountAccount Domain: MYDOMAIN Logon ID: 0x23a80332 > Target Account:Security ID: > S-1-5-21-789336058-1532298954-839522115-60716 Account Name: my_account >Account Domain: MYDOMAIN > > As you can see, "user" in the alert.log doesn't populate. If I modify the > log message and manually ingest it into OSSEC, it works. > > > New Raw Log: > WinEvtLog: Security: AUDIT_SUCCESS(4725): > Microsoft-Windows-Security-Auditing: *my_account*: no domain: > myhost.mydomain.com: A user account was disabled.Subject: Security > ID: S-1-5-21-789336058-1532298954-839522115-141077 Account Name: > my_accountAccount Domain: MYDOMAIN Logon ID: 0x23a80332 > Target Account:Security ID: > S-1-5-21-789336058-1532298954-839522115-60716 Account Name: my_account >Account Domain: MYDOMAIN > > New Alert.log > ** Alert ** > time: 1448030023 > hostname: (agent26) 0.0.0.0->WinEvtLog > location: (agent26) 0.0.0.0->WinEvtLog > rule_id: 18112 > rule_rev: 1 > rule_name: User account disabled or deleted. > rule_level: 8 > lrec_object_tag: user > lrec_action_tag: authentication delete > lrec_status_tag: success > lrec_action: review > event_id: 4725 > status: AUDIT_SUCCESS > data: Microsoft-Windows-Security-Auditing > *user: my_account* > systemname: myhost.mydomain.com > raw_log: > WinEvtLog: Security: AUDIT_SUCCESS(4725): > Microsoft-Windows-Security-Auditing: *my_account: *no domain: > myhost.mydomain.com: A user account was disabled.Subject: Security > ID: S-1-5-21-789336058-1532298954-839522115-141077 Account Name: > my_accountAccount Domain: MYDOMAIN Logon ID: 0x23a80332 > Target Account:Security ID: > S-1-5-21-789336058-1532298954-839522115-60716 Account Name: my_account >Account Domain: MYDOMAIN > > > > On Wednesday, October 7, 2015 at 4:56:14 PM UTC-4, Eloy Alonso wrote: >> >> This Event is usually caused by a stale hidden credential. Try this from >> the system giving the error: >> >> From a command prompt run:psexec -i -s -d cmd.exe >> From the new DOS window run: rundll32 keymgr.dll,KRShowKeyMgr >> Remove any items that appear in the list of Stored User Names and >> Passwords. Restart the computer. >> >> >> On Monday, November 3, 2014 at 4:37:34 PM UTC-5, Luke Goldman wrote: >>> >>> I am new to setting up Ossec but so far am liking it a lot. I am having >>>
[ossec-list] Re: Windows Server 2012 and automated ossec install
It is possible, our company has successfully pulled it off for another larger corporation On Wednesday, September 16, 2015 at 8:00:46 AM UTC-4, Chris Spangler wrote: > > Does anyone know if ossec will allow for an unattended install under > Windows Server 2012. It seems like I saw some issues in the past and was > wondering if there was a newer version that supported it? 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.
[ossec-list] Re: Deleting the OSSEC agent 'queue' directory
I haven't seen this directory fill up unless it cannot talk to the server
and even in that case it did not take much disk space
What kind of size are you seeing?
On Wednesday, August 19, 2015 at 10:51:26 AM UTC-4, Jamey B wrote:
>
> I'm making a CRON job to remove anything in the queue folder, would this
> be a good CRON job if I wanted the directory cleared if the items are over
> 5 days old and I want it ran once a day at 10PM? The last time I took my
> OSSEC server down, the agent disk space started getting too big in
> /var/ossec/queue/diff/local after a few weeks. Would any other directories
> do the same thing, or is this the only directory that gets queue data?
>
> 0 22 * * * /usr/bin/find /var/ossec/queue/diff/local/* -mtime +5 -exec rm
> {} \;
>
>
> I don't want the OSSEC agent to take up a lot of disk space, what else
> could I do?
>
>
>
>
--
---
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: SEIM system with OSSEC.
a SIEM platform of any kind is a correlation tool for comparing and contrasting logs from disparate device types As you have seen, 3 different folks provided 3 different answers and that will likely be true when talking with any professionals. for 200 devices, you will need a decent size server, OSSIM (and ultimately Alienvault) have the OSSEC server running on their main server and remote sensor devices allowing you to manually deploy OSSEC agents and control OSSEC agent configurations from a GUI as well as command line. If you are only managing 200 servers and no other log feeds, OSSIM might be a good place to start as you will get some pre-canned ideas for writing subsequent rules/directives/escalations. If, however, you choose to add additional feeds, you might keep the 200+ agents reporting to a remote sensor and use the server for just correlation/presentation. Your options are wide open, give it a try! https://www.alienvault.com/products/ossim Grant Leonard Castra Consulting, LLC http://castraconsulting.com/#/ 919-949-4002 On Sun, Aug 9, 2015 at 10:46 AM, 'Jason Long' via ossec-list ossec-list@googlegroups.com wrote: Thank you. Grant , Can you give me more information? I want to implement SIEM for a windows network with 200 clients. Which requirements are need? On Saturday, August 8, 2015 8:58 PM, Grant Leonard gr...@castraconsulting.com wrote: Try Alienvault or OSSIM, they both make good use of OSSEC and add additional tools you will need for detecting the spread of malware On Friday, August 7, 2015 at 6:40:54 AM UTC-4, Jason Long wrote: Hello Experts. How can I launch a SEIM for my local network and find the spread point of malware in my local network? Any idea? Please let me know which tools are needed. Thank you. -- --- 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 a topic in the Google Groups ossec-list group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/ossec-list/oAWYa0XDz1M/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: SEIM system with OSSEC.
Try Alienvault or OSSIM, they both make good use of OSSEC and add additional tools you will need for detecting the spread of malware On Friday, August 7, 2015 at 6:40:54 AM UTC-4, Jason Long wrote: Hello Experts. How can I launch a SEIM for my local network and find the spread point of malware in my local network? Any idea? Please let me know which tools are needed. Thank you. -- --- 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] #*#*#*#*#*# in client.keys on server. Is it hosed?
it is certainly what happens when deleting old agents. This is normal expected behavior Check you ossec.log to look for errors with remote agents reporting in. On Wednesday, July 1, 2015 at 8:35:14 PM UTC-4, Michael Starks wrote: On 07/01/2015 04:50 PM, Jon Price wrote: Ive had ~1000 agents connected to a single ossec server for the past 18 months. About ~2 months ago agents started dropping like flies. I noticed many lines in the client.keys on the server have been replaced with #*#*#*#*#*#*#. I believe this is why my agents are not talking to the server, BUT how can I remedy ~500 agents? Shall I recreate / make new Agents? This is generally what happens when one runs ./bin/manage_agents and removes them from the manager. Does someone else have access to the server? -- --- 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: Rules
You can look up the codes here http://technet.microsoft.com/en-us/library/dd941635(v=ws.10).aspx https://technet.microsoft.com/en-us/library/dd941635%28v=ws.10%29.aspx https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=4625 ...you have a 2008 server or newer, and this link is for 2003, but the logon type values have not changed value 3 = network logon, failure reason 2313 is your key http://answers.microsoft.com/en-us/windows/forum/windows_vista-security/where-can-i-find-the-full-list-of-failure-reasons/d0269426-2183-4d99-8af0-cc009dee6658 https://technet.microsoft.com/en-us/library/cc787567%28v=ws.10%29.aspx On Friday, June 5, 2015 at 1:11:12 PM UTC-4, Todd Clementz wrote: Good Day, I am getting a lot of these in my email notification. Can anyone shed light at to how to deal with these. I am working through someone else’s install and still not understanding how to write the rules to process this type of message. Any help would be great. OSSEC HIDS Notification. 2015 Jun 05 10:00:13 Received From: (%ServerName%) %ServerIP%-WinEvtLog Rule: 40111 fired (level 10) - Multiple authentication failures. Portion of the log(s): 2015 Jun 05 10:00:17 WinEvtLog: Security: AUDIT_FAILURE(4625): Microsoft-Windows-Security-Auditing: (no user): no domain: %servername.domain.local%: An account failed to log on. Subject: Security ID: S-1-0-0 Account Name: - Account Domain: - Logon ID: 0x0 Logon Type: 3 Account For Which Logon Failed: Security ID: S-1-0-0 Account Name: Shipping Account Domain: %workstation% Failure Information: Failure Reason: %%2313 Status: 0xc06d Sub Status: 0xc064 Process Information: Caller Process ID: 0x0 Caller Process Name: - Network Information: Workstation Name: %workstation% Source Network Address: %workstationIP% Source Port: 65472 Detailed Authentication Information: Logon Process: NtLmSsp Authentication Package: NTLM Transited Services: - Package Name (NTLM only): - Key Length: 0 This event is generated when a logon request fails. It is generated on the computer where access was attempted. Thank you, Todd Clementz ACLens IT Department -- --- 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 Agent Install - Windows
I wasn't aware that agent-auth works in Windows, I know some people have written things to make it work Here is some code you can try https://github.com/sedarasecurity/ossec-agent-auth/blob/master/build.sh I am sure there others out there as well, typically we use a mass deploy script depending on the scenario and environment On Wednesday, May 20, 2015 at 5:59:57 PM UTC-4, Bryan Carter wrote: I am finally to a point where I can do testing on the agent-auth bit for Windows. I am not real keen on the windows compilation process, and have very little experience taking code to the executable level. I see that some things have been done on this since it was discussed last, but can someone tell me the actual steps to be able to test it? Thanks --- Bryan K. Carter On 12/26/14, 5:31 AM, dan (ddp) ddp...@gmail.com javascript: wrote: On Tue, Dec 23, 2014 at 5:10 PM, Bryan K. Carter cart...@deseretmgt.com javascript: wrote: I would also be willing to do some testing. I am just beginning a deployment to about 700 windows clients. Awesome! Please report back any results. --- Bryan K. Carter On 12/23/14, 2:09 PM, David Lang da...@lang.hm javascript: wrote: On Tue, 23 Dec 2014, dan (ddp) wrote: On Mon, Dec 22, 2014 at 3:27 PM, David Lang da...@lang.hm javascript: wrote: I have the following .cmd script that I run on each machine. Has the agent-auth tool for the auto-configuration of keys been ported to windows? I don't see any sign of it and all the documentation is for linux. Last I saw there was a request for testers that went no where, but that was a long time ago. well, it looks like we've got a couple folks interested in testing now if there is still development interest. :-) David Lang @echo off setlocal enabledelayedexpansion NUL 2 NUL net stop OSSEC HIDS NUL 2 NUL del C:\Program Files (x86)\ossec-agent /s /q NUL 2 NUL cmd /c \\10.1.1.1\ossec\ossec-agent-win32-2.8.exe /S findstr /I /C: %COMPUTERNAME%. \\10.1.1.1\ossec\ossec.keys C:\Program Files (x86)\ossec-agent\client.keys copy \\10.1.1.1\ossec\ossec.conf C:\Program Files (x86)\ossec-agent\ /y net start OSSEC HIDS David Lang On Mon, 22 Dec 2014, dan (ddp) wrote: On Mon, Dec 22, 2014 at 2:56 PM, ste...@bawks.com javascript: wrote: Is there a way to silently install the .exe in windows? /s? /S? Something like that, I think. I could not find any form of documentation and or any command line options that I can include but I thought I would reach out and find 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+...@googlegroups.com javascript:. 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+...@googlegroups.com javascript:. 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+...@googlegroups.com javascript:. 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: ossec-agent installation process automatization on windows
It should be enough sir Each agent needs their own key, but once the agent has the key and checks in with the server, it will pick up any custom configurations All the best On Thursday, May 14, 2015 at 7:02:32 PM UTC-4, Daniil Svetlov wrote: Hi! I'm trying update ossec-agent key on windows via cli. I have found, that wingui just make base64decode against key, received from server, and write it to file ossec.keys. If I'll repeate the same manually, is it enough for agent funtioning? Or I miss something? -- --- 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: Agent cannot connect to server, does not appear to be firewall or key related
Have you run a tcdpump or ngrep on the server to ensure packets are arriving on UDP port 1514? When the agent is initially restarted it begins a new dialog with the server and you should be able to see that on the wire On Thursday, May 14, 2015 at 5:31:28 PM UTC-4, Andy Theuninck wrote: I have OSSEC 2.8.1 server installed on CentOS 7. I have OSSEC 2.8.1 agent installed on a separate CentOS 6 box. The agent cannot connect to the server and I do not understand why. When the agent starts, I see this in the logs: 2015/05/14 15:35:11 ossec-agentd: INFO: Trying to connect to server ( 192.168.2.4:1514). 2015/05/14 15:35:11 ossec-agentd: INFO: Using IPv4 for: 192.168.2.4 . 2015/05/14 15:35:32 ossec-agentd(4101): WARN: Waiting for server reply (not started). Tried: '192.168.2.4'. The server ossec.log show absolutely nothing while the agent is attempting to connect. This would lead me to believe it's a firewall (or general connectivity problem). However, I can connect to the server machine from the agent machine just fine using netcat. E.g., nc -uv 192.168.2.4 1514 If I type random things into the server after connecting with netcat, I get the expected log entries on the server: 2015/05/15 15:39:37 ossec-remoted(1403): ERROR: Incorrectly formated message from '192.168.2.3'. So far as I can tell, the agent machine has connectivity to UDP 1514 on the server machine, except ossec-agentd does not. -- --- 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: Trying to create a application whitelist for Windows
Josh, some of these are really amazing. Thank you so much for sharing and posting that. All the best Grant On Wednesday, March 25, 2015 at 12:43:29 PM UTC-4, DefensiveDepth wrote: I have been doing some work in the area as well, but with Sysmon logs. Feel free to look over what I have already: https://github.com/defensivedepth/Sysmon_OSSEC -Josh -- --- 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: Monitoring Windows AD account lockouts etc
I would be interested in those as well. I have a few generic ones for other events of interest (workstation lock, console logon, network logon) but I am missing some good differentiation in failures and 4625 type events (related to your 4771 ) On Tuesday, February 24, 2015 at 4:09:34 PM UTC-5, Stephen Carr wrote: that would be really helpful for sure. thanks Steve On Tuesday, February 24, 2015 at 5:55:30 AM UTC-8, Derek Morris wrote: Would be happy to share my local_rules.xml and the msauth.xml tweeked version I use. Let me know On Monday, February 23, 2015 at 3:28:39 PM UTC-5, Stephen Carr wrote: Hey there all, I’m wading into the realm of Domain Controller security logs and what is possible for filtering events to get a more fine-grained alerting setup based on certain criteria that OSSEC picks up from the windows security event log. I’ve been digging through the msauth XML rules file trying to get a sense of how it all works (plus reading up on building local rules in general) but haven’t been able to figure the full ins and outs of rule criteria and what is in “play” vs what isn’t. The thing with windows auditing of authentication is that many events (including successful ones) can all be grouped under one ID so some of the pre-written rules in that XML file trigger a very broad swathe of events. Long story short, I’d like to use some of the “fine print” in an event to filter out the “noise”. Here is an example of an attempted login to a locked out account in Kerberos: AV - Alert - 1424475022 -- RID: 18105; RL: 4; RG: windows,; RC: Windows audit failure event.; USER: (no user); SRCIP: None; HOSTNAME: (DC) 172.16.1.17-WinEvtLog; LOCATION: (DC) 192.168.1.1-WinEvtLog; EVENT: [INIT]2015 Feb 20 15:30:22 WinEvtLog: Security: AUDIT_FAILURE(4771): Microsoft-Windows-Security-Auditing: (no user): no domain: DC.domain.com: Kerberos pre-authentication failed. Account Information: Security ID: S-1-5-21-361591302-153053782-0- Account Name: USER Service Information: Service Name: krbtgt/domain.com Network Information: Client Address: :::192.168.1.2 Client Port: 32209 Additional Information: Ticket Options: 0x40810010 Failure Code: 0x12 Pre-Authentication Type: 0 Certificate Information: Certificate Issuer Name: Certificate Serial Number: Certificate Thumbprint: Certificate information is only provided if a certificate was used for pre-authentication. Pre-authentication types, ticket options and failure codes are defined in RFC 4120. If the ticket was malformed or damaged during transit and could not be decrypted, then many fields in this event might not be present.[END]; So, as you can see, this lands under rule 18105 due to it being event ID 4771 (much falls under 4771). The key identifier is the part that reads “Failure Code: 0x12” So, can I build a local rule to override the generic 4771 rule when that failure code is present? I’m assuming I can since the info was sent to OSSEC in the first place but I haven’t been successful. Any thoughts? Thanks in advance Steve -- --- 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: Fail to config ossec agent on Windows 8
I have only tested one laptop, using English, installed as Administrator, and it works That said, I cannot read the logs or access various files even though I am administrator, I have to launch the GUI first. I make all my changes on the OSSEC server and the Agent picks up the config from there Hope this helps On Wednesday, February 4, 2015 at 7:16:15 PM UTC-5, SoulAuctioneer wrote: This may be fixed in the upcoming release of OSSEC. Are any of you running a different language other than English as the primary language for Windows? Can you post the log entries (if any) that are in the ossec.log file after this happens? Would any of you be able to try the latest 2.9 beta? I believe you can get it here: https://github.com/ossec/ossec-hids/releases/tag/2.9.0-beta02 -- --- 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:
This has worked for me C: \ Windows \ System32 \ cmd.exe Typically I stand up a basic windows syscheck like this agent_config syscheck auto_ignoreno/auto_ignore alert_new_filesyes/alert_new_files scan_on_startyes/scan_on_start directories realtime=yes check_all=yesc:\windows\system32/ directories directories realtime=yes check_all=yesc:\windows\syswow64/ directories /syscheck /agent_config Hope that helps sir On Friday, January 16, 2015 at 8:45:08 AM UTC-5, alex petrov wrote: Hello. Please tell me how out of the way to get the file name of the file. Example C: \ Windows \ System32 \ cmd.exe or C: \ Windows \ System32 \ .. \ .. \ .. \ ... cmd.exe need cmd.ehe ossec not support grouping regular expressions? -- --- 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] Syslog forwarding doesn't work with custom_alert_output
Great point. We do see the custom alert in alerts.log Should we put in a request or just modify csyslogd ourselves? Grant Leonard Castra Consulting, LLC http://castraconsulting.com/#/ 919-949-4002 On Wed, Jan 7, 2015 at 8:58 AM, dan (ddp) ddp...@gmail.com wrote: On Wed, Jan 7, 2015 at 8:18 AM, gr...@castraconsulting.com wrote: I can confirm this to be true, we did an extensive testing running a stock 2.7 and 2.8.1 OSSEC install feeding an Alienvault platform and syslog, when custom alert is configured, did not work. Does the alerts.log file contain alerts in the custom format? If so, GetAlertData() probably doesn't know how to read it. Instead of messing with that nonsense, I think it'd be better in the long run for someone to modify csyslogd to read from the zeromq pubsub and send the syslog alerts based on that information. It should be simpler than teaching it how to read the alerts.log better. On Wednesday, January 7, 2015 8:04:25 AM UTC-5, dan (ddpbsd) wrote: On Tue, Jan 6, 2015 at 10:12 AM, Chris H chris@gmail.com wrote: It's the default OSSEC install in OSSIM, rather than one I installed myself. It's 2.8 though. Does it work with a standard 2.8.1 installation? Thanks On Monday, January 5, 2015 3:17:09 PM UTC, dan (ddpbsd) wrote: On Mon, Jan 5, 2015 at 10:14 AM, Chris H chris@gmail.com wrote: Hi. The OSSEC deployment within OSSIM uses custom_alert_output, rather than the default log format. I'm was trying to get these alerts sent to another server, and enabled syslog_output, as I have done on other OSSEC deployments. On the OSSIM deployment, the logs do not get forwarded. I removed the custom_alert_output setting in ossec.conf and the logs get forwarded as expected. Is this a known issue? If not, I can raise a bug on github. Which version of OSSEC did you install? 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+...@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 a topic in the Google Groups ossec-list group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/ossec-list/cJsJemPdqhs/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: ossec-remoted Process Pegged at 100%
I know you are focusing on the receiving side, but 30k EPS is really high even for 2k servers. If the agents are on Windows servers, check your audit policies (local/global) to make sure you don't have object access and process tracking on (this is for debugging and not really useful to OSSEC imho) Grant On Tuesday, December 16, 2014 8:00:13 AM UTC-5, Chris Decker wrote: Good morning all, I have about 2,000 (heavily active) OSSEC agents sending logs to a Manager. On the Manager side I've noticed that *ossec-remoted* is hovering around 98% to 100% of a CPU. I was under the impression that *ossec-remoted* is multi-threaded, but I only ever see one process running (and no childs). Am I doing something incorrectly? I was speaking with some folks on IRC and they said that not only is the process multi-threaded, but that a modern server could easily handle 70,000 EPS. Right now I have a machine with 16 Intel Xeon cores running at 3.3 GHz, and I estimate I'm seeing about 30,000 EPS. Any performance/tuning tips are appreciated!!! Thanks, Chris -- --- 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: Windows login failure event 4625 not logging
When I run ossec-logtest and put the ID 4625 Do you paste the entire log into the logtest? Can you put your logtest output here? On Monday, December 8, 2014 7:14:15 PM UTC-5, Jarrod Farncomb wrote: I'm having an issue getting failed logins to Windows servers to log correctly to alerts.log. I've created a log in fail and confirmed the Windows event logs show this as ID 4625. Checking in the rules directory on the OSSEC server this appears within the id field of the msauth rule file (ID 18106), however it doesn't actually seem to detect or log it to alerts.log. What needs to be changed? When I run ossec-logtest and put the ID 4625 in it says that no rules have been applied, despite there already being one that appears to match it. -- --- 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: manage_agent fails again
manage_agent is a server side function, not a client side. On a Windows platform you can manually add your key in 'client.keys' then restart the agent On Tuesday, November 25, 2014 12:19:07 PM UTC-5, Colin Bruce wrote: Is there any way on Windows to install the agent’s key without using the GUI and cutting and pasting the key into it. Manage_agents –I should do the import but it doesn’t work. It doesn’t read from the command line, it doesn’t read the shell variable and it doesn’t prompt for a key. Cutting and pasting is no use when there are hundreds of servers to install. Best wishes… Colin -- --- 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: Rules for MS14-066
I have not seen a log in the wild that would let me write a rule for this Any luck on your end? On Thursday, November 20, 2014 5:07:31 AM UTC-5, secuc...@free.fr wrote: hi does someone has rule for MS14-066 ? https://technet.microsoft.com/en-us/library/security/ms14-066.aspx or maybe some logs i can work on ? 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.
[ossec-list] Re: Convert Multiline Eventlog
Set a custom Alert variable output. You can do this in the global config on the OSSEC server receiving the logs, once the rules match and you get an ALERT you will have the same output over and over. Make sense? On Tuesday, November 18, 2014 7:55:55 AM UTC-5, DefensiveDepth wrote: I have an OSSEC agent monitoring some Windows eventlogs through the eventchannel config and then sending them to the OSSEC manager and archiving them. The SIEM is then parsing the archive and indexing the logs. Unfortunately, these eventlogs are multiline, and the SIEM that is being used is having issues with multiline logs Is there any way to have OSSEC convert/strip out the new lines from the logs as it processes them and sends them to the manager? 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] OSSEC with OSSIM
I send alert level ossec via syslog to rsyslog ossim but not working because OSSIM use custom log with tag AV in front of each log so alert from ossec server not recognize by OSSIM OSSIM has plugins built to read that default output, you don't need to route OSSEC syslog to OSSIM, you merely need to have the OSSEC agent report to the OSSEC server running on the OSSIM platform and have the correct plugins enabled. Does this help? On Wednesday, November 12, 2014 9:09:36 AM UTC-5, dan (ddpbsd) wrote: On Wed, Nov 12, 2014 at 5:47 AM, Teddy Jayasaputra teddy.ja...@gmail.com javascript: wrote: Dear all, Any of you have working with ossec server talking to ossec in OSSIM? I send alert level ossec via syslog to rsyslog ossim but not working because OSSIM use custom log with tag AV in front of each log so alert from ossec server not recognize by OSSIM. I heard about ossec in hybrid mode. Can someone describe it? Or point me the manual to do it? Can hybrid mode solve deployment ossec to ossec in OSSIM ? Hybrid mode allows an OSSEC manager to report alerts to another OSSEC manager. Thanks. Best Regards, -Teddy- -- --- 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 javascript:. 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] Huge event logs create Network Bandwidth issue
That is an interesting idea, however all the logs are processed server side, not agent side, thus by the time you detect an uptick in events, you have already sent the traffic. In theory you could create a custom rule for # of X event types over a period of time, and if the rule fires, you have a custom script looking for that alert which subsequently logs into the server in question and turns off the agent. That all seems overkill, perhaps don't collect Application logs? That alone will reduce your volume significantly On Wednesday, November 5, 2014 10:25:14 AM UTC-5, priyonko chakraborty wrote: Hi, I know it is not problem of OSSEC. Point is we want to capture the windows event logs including system, security and application. As OSSEC agents collects all those logs, sometime due to configuration error or any application error, windows triggered lots of noise on event logs and OSSEC captured everything and trying to send it to server. So I wanted to know, is there any rule I can implement if the events will be high, it simply disconnect the agent with server. So there will be no impact on system performance as well network bandwidth. In short it's possible to put some bandwidth limitations, uniq events logging, etc??? Regards, Priyonko On Wednesday, 5 November 2014 20:40:25 UTC+5:30, Michael Starks wrote: On 2014-11-05 5:49, priyonko chakraborty wrote: Can you suggest your views, if we can implement any rule to discard the connection from OSSEC agent to Servers if it crosses some threshold. Like if the we will get Event count after '2': 13179011-8264848 (62%), there should be some rule which stops the connection between OSSEC agent with servers and help us to stop bandwidth killing. Identify the cause of the chatty logs and address that. You may have object auditing enabled, which can generate a large number of events. This is not really an OSSEC problem. OSSEC sends every log to the manager for analysis just like any other log analysis tool and it needs to do that in order to do its job. It even compresses the logs, so I really think you need to examine the source of the problem and address it there. -- --- 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-logtest works but no alerts in real-tim
What Dan says is accurate, and a visual representation might be helpful For this log : 2014 Nov 05 09:10:02 (w2008) 192.1.1.1-\Programs\myapp\ logs\05-11-2014\Error.log Error - The process started successfully This part is from the OSSEC agent : 2014 Nov 05 09:10:02 (w2008) 192.1.1.1- And this part is from the log on the remote server : \Programs\myapp\ logs\05-11-2014\Error.log Error - The process started successfully And this part is what is likely processed by the Decoder/Rule (the actual message): Error - The process started successfully Thus you should write your rule and decoder to work on that string, does this help sir? To be honest, we saw a similar issue with OpenVPN logs on 2.7.1 and had to write the decoder about 3 different times. It all worked in logtest, but never in production, just as you describe, until we trimmed down what we were looking for within the log. @Dan, does the decoder and logtest work at all differently than a live event? I stink at digging through source code sir... On Wednesday, November 5, 2014 9:21:27 AM UTC-5, dan (ddpbsd) wrote: On Wed, Nov 5, 2014 at 1:47 AM, sathis...@gmail.com javascript: wrote: Hello, I am trying to fix the following problem and no luck yet.. Kindly help me on the following issue. I have the following log stored in windows 2008 in the file called F:\Programs\myapp\logs\05-11-2014\Error.log Error - The process cannot access the file 'INST5.txt' because it is being used by another process. The ossec_agent.conf contains the following localfile settings: localfile locationF:\Programs\myapp\logs\05-11-2014\Error.log/location log_formatsyslog/log_format /localfile Then in the server side archives.log I get the log from windows 2008: 2014 Nov 05 09:02:02 (w2008) 192.1.1.1-\Programs\myapp\logs\05-11-2014\Error.log Error - The process cannot access the file 'INST5.txt' because it is being used by another process. If this is taken straight out of archives.log there is a header attached to it. I'd try using the log message as detailed earlier, starting with Error. I have written the following decoder in local_decoder.xml: decoder name=f-error-log typesyslog/type prematch(\d+ \w+ \d+ \d+:\d+:\d+) \(w2008\) /prematch regex\d+ \w+ \d+ \d+:\d+:\d+ \((w2008)\) (\d+.\d+.\d+.\d+)-(\S+) (Error) - (\.+)/regex ordersystem_name,srcip,extra_data,status,extra_data/order /decoder And also I have the following rules: group name=finbridge, rule id=100060 level=0 decoded_asf-error-log/decoded_as descriptionF Error Messages grouped./description /rule rule id=100061 level=5 if_sid100060/if_sid matchError/match descriptionF Error/description /rule When I run ossec-logtest I see the decoders and rules are working properly: **Phase 1: Completed pre-decoding. full event: '2014 Nov 05 09:02:02 (w2008) 192.1.1.1-\Programs\myapp\logs\05-11-2014\Error.log Error - The process cannot access the file 'INST5.txt' because it is being used by another process.' hostname: 'alienvault' program_name: '(null)' log: '2014 Nov 05 09:02:02 (2008) 192.1.1.1-\Programs\myapp\logs\05-11-2014\Error.log Error - The process cannot access the file 'INST5.txt' because it is being used by another process.' **Phase 2: Completed decoding. decoder: 'f-error-log' system_name: 'w2008' srcip: '192.1.1.1' extra_data: '\Programs\myapp\logs\05-11-2014\Error.log' status: 'Error' extra_data: 'The process cannot access the file 'INST5.txt' because it is being used by another process.' **Phase 3: Completed filtering (rules). Rule id: '100061' Level: '5' Description: 'F Error' **Alert to be generated. Then I have restarted ossec service on ossec server and added the following line on F:\Programs\myapp\logs\05-11-2014\Error.log to see if I get alerts in alerts.log Error - The process started successfully I can see the above log in archives.log: 2014 Nov 05 09:10:02 (w2008) 192.1.1.1-\Programs\myapp\logs\05-11-2014\Error.log Error - The process started successfully But when I check alerts.log there are no alerts :( I spent couple of hours and double checked the config and etc.. still I cannot see an alert in alerts.log. Thank you in advance. Sathish. -- --- 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 javascript:. For more options, visit https://groups.google.com/d/optout. -- --- You received this message because you are subscribed to the Google
Re: [ossec-list] Re: Windows Event ID 4625
You do not have to tell the platform to use local_decoders, just make sure the permissions are the same I am upgrading to 2.8 this week across numerous platforms from 2.7.1 I already have the decoders in place and will begin making rules today or tomorrow for the events in the custom decoder file I will post with results. All the best Grant Leonard Castra Consulting, LLC http://castraconsulting.com/#/ 919-949-4002 On Tue, Nov 4, 2014 at 10:16 AM, Luke Goldman logol...@gocolumbiamo.com wrote: Let me know if you get the decoders to work. Do you have tell ossec to use the local_decoders.xml? I cannot get it to use the custom decoders. On Tuesday, November 4, 2014 9:07:14 AM UTC-6, gr...@castraconsulting.com wrote: great article sir, thanks I am testing that now Make sure you add the values to local_decoder the way he discusses, not the way he lists them. He also doesn't note that you need override rules for each of those in your local_rules so be sure to add those. Thanks again for the link! On Tuesday, November 4, 2014 9:32:02 AM UTC-5, Luke Goldman wrote: That is exactly what I was noticing. I was playing around with the suggestions from this site (http://www.richardosgood.com/ blog/fixing-ossec-windows-logon-failure-events/) to create custom decoders but was messing something up because every time I used the custom decoders it would break all of the other alerts from the windows decoder. I did have to change his decoder for the 4625 event id because it was not correct. I didn't know if anyone else had a fix. Thanks for any help/suggestions. On Tuesday, November 4, 2014 6:43:37 AM UTC-6, gr...@castraconsulting.com wrote: So that is rule 18106 I have just recently been playing with this one. The issue isn't OSSEC its literally the WIndows log (note that the log states (no user) EVENT: [INIT]WinEvtLog: Security: AUDIT_FAILURE(4625): Microsoft-Windows-Security-Auditing: (no user): no domain: some.server.name.here: An account failed to log on. Subject: Security ID: S-1-0-0 Account Name: - Account Domain: - Logon ID: 0x0 Logon Type: 3 Account For Which Logon Failed: Security ID: S-1-0-0 Account Name: username_we_want_here_but_not_parsed Account Domain: some.domain Failure Information: Failure Reason: %%2313 Status: 0xc06d Sub Status: 0xc06a Process Information: Caller Process ID: 0x0 Caller Process Name: - Network Information: Workstation Name: Remote.workstation Source Network Address: - Source Port: - Detailed Authentication Information: Logon Process: NtLmSsp Authentication Package: NTLM Transited Services: - Package Name (NTLM only): - Key Length: 0 This event is generated when a logon request fails. It is generated on the computer where access was attempted. [END]; What it appears we need is a way to move the match for this particular event From -- Microsoft-Windows-Security-Auditing: (no user): To -- Account Name: username_we_want_here_but_not_parsed Which I assume we need to do in the decoder Initially in OSSIM I was excluding (no user) but I decided on a different path and I was trying to match on the status/subcode (like this 0xC06F) as that tells me what really happened (this is not proving worthwhile as the sub code types are numerous) What matters after the username are the sub codes or status here as we get the kind of auth fail for this VERY wide scoping log Does anyone have any idea on how better to match at the decoder level? 18106 is if_sid 18105 which is if_sid 18100 which is rule id=18105 level=4 if_sid18100/if_sid status^AUDIT_FAILURE|^failure/status descriptionWindows audit failure event./description /rule and the generic decoder decoder name=windows typewindows/type prematch^WinEvtLog: /prematch regex offset=after_prematch^\.+: (\w+)\((\d+)\): (\.+): /regex regex(\.+): \.+: (\S+): /regex orderstatus, id, extra_data, srcuser, system_name/order ftsname, location, user, system_name/fts /decoder So, the srcuser is perhaps wrong? Maybe we need a second decoder for this and other events that don't leverage the initial username, adding an actor and actee type value? On Monday, November 3, 2014 4:37:34 PM UTC-5, Luke Goldman wrote: I am new to setting up Ossec but so far am liking it a lot. I am having one issue that I am sure someone has resolved. The main thing I am working right now is tracking failed windows logins. Most of this has worked right out of the box which is awesome. The issue I am having is that the Windows Event ID 4625 shows (no user) where every other Windows Event ID shows the username. So Ossec reports the user as (no user). This causes issues when I want to alert on 6 failed logins from the same user, as every user will match this (no user). Has anyone got a solution for this? Below is a log that will show what I am talking about. Thanks! 2014 Nov 03 12:05:34
[ossec-list] Re: Windows Event ID 4625
So that is rule 18106 I have just recently been playing with this one. The issue isn't OSSEC its literally the WIndows log (note that the log states (no user) EVENT: [INIT]WinEvtLog: Security: AUDIT_FAILURE(4625): Microsoft-Windows-Security-Auditing: (no user): no domain: some.server.name.here: An account failed to log on. Subject: Security ID: S-1-0-0 Account Name: - Account Domain: - Logon ID: 0x0 Logon Type: 3 Account For Which Logon Failed: Security ID: S-1-0-0 Account Name: username_we_want_here_but_not_parsed Account Domain: some.domain Failure Information: Failure Reason: %%2313 Status: 0xc06d Sub Status: 0xc06a Process Information: Caller Process ID: 0x0 Caller Process Name: - Network Information: Workstation Name: Remote.workstation Source Network Address: - Source Port: - Detailed Authentication Information: Logon Process: NtLmSsp Authentication Package: NTLM Transited Services: - Package Name (NTLM only): - Key Length: 0 This event is generated when a logon request fails. It is generated on the computer where access was attempted. [END]; What it appears we need is a way to move the match for this particular event From -- Microsoft-Windows-Security-Auditing: (no user): To -- Account Name: username_we_want_here_but_not_parsed Which I assume we need to do in the decoder Initially in OSSIM I was excluding (no user) but I decided on a different path and I was trying to match on the status/subcode (like this 0xC06F) as that tells me what really happened (this is not proving worthwhile as the sub code types are numerous) What matters after the username are the sub codes or status here as we get the kind of auth fail for this VERY wide scoping log Does anyone have any idea on how better to match at the decoder level? 18106 is if_sid 18105 which is if_sid 18100 which is rule id=18105 level=4 if_sid18100/if_sid status^AUDIT_FAILURE|^failure/status descriptionWindows audit failure event./description /rule and the generic decoder decoder name=windows typewindows/type prematch^WinEvtLog: /prematch regex offset=after_prematch^\.+: (\w+)\((\d+)\): (\.+): /regex regex(\.+): \.+: (\S+): /regex orderstatus, id, extra_data, srcuser, system_name/order ftsname, location, user, system_name/fts /decoder So, the srcuser is perhaps wrong? Maybe we need a second decoder for this and other events that don't leverage the initial username, adding an actor and actee type value? On Monday, November 3, 2014 4:37:34 PM UTC-5, Luke Goldman wrote: I am new to setting up Ossec but so far am liking it a lot. I am having one issue that I am sure someone has resolved. The main thing I am working right now is tracking failed windows logins. Most of this has worked right out of the box which is awesome. The issue I am having is that the Windows Event ID 4625 shows (no user) where every other Windows Event ID shows the username. So Ossec reports the user as (no user). This causes issues when I want to alert on 6 failed logins from the same user, as every user will match this (no user). Has anyone got a solution for this? Below is a log that will show what I am talking about. Thanks! 2014 Nov 03 12:05:34 WinEvtLog: Security: AUDIT_FAILURE(4625): Microsoft-Windows-Security-Auditing: (no user): 2014 Nov 03 13:15:27 WinEvtLog: Security: AUDIT_SUCCESS(4624): Microsoft-Windows-Security-Auditing: Username: -- --- 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: Windows Event ID 4625
great article sir, thanks I am testing that now Make sure you add the values to local_decoder the way he discusses, not the way he lists them. He also doesn't note that you need override rules for each of those in your local_rules so be sure to add those. Thanks again for the link! On Tuesday, November 4, 2014 9:32:02 AM UTC-5, Luke Goldman wrote: That is exactly what I was noticing. I was playing around with the suggestions from this site ( http://www.richardosgood.com/blog/fixing-ossec-windows-logon-failure-events/) to create custom decoders but was messing something up because every time I used the custom decoders it would break all of the other alerts from the windows decoder. I did have to change his decoder for the 4625 event id because it was not correct. I didn't know if anyone else had a fix. Thanks for any help/suggestions. On Tuesday, November 4, 2014 6:43:37 AM UTC-6, gr...@castraconsulting.com wrote: So that is rule 18106 I have just recently been playing with this one. The issue isn't OSSEC its literally the WIndows log (note that the log states (no user) EVENT: [INIT]WinEvtLog: Security: AUDIT_FAILURE(4625): Microsoft-Windows-Security-Auditing: (no user): no domain: some.server.name.here: An account failed to log on. Subject: Security ID: S-1-0-0 Account Name: - Account Domain: - Logon ID: 0x0 Logon Type: 3 Account For Which Logon Failed: Security ID: S-1-0-0 Account Name: username_we_want_here_but_not_parsed Account Domain: some.domain Failure Information: Failure Reason: %%2313 Status: 0xc06d Sub Status: 0xc06a Process Information: Caller Process ID: 0x0 Caller Process Name: - Network Information: Workstation Name: Remote.workstation Source Network Address: - Source Port: - Detailed Authentication Information: Logon Process: NtLmSsp Authentication Package: NTLM Transited Services: - Package Name (NTLM only): - Key Length: 0 This event is generated when a logon request fails. It is generated on the computer where access was attempted. [END]; What it appears we need is a way to move the match for this particular event From -- Microsoft-Windows-Security-Auditing: (no user): To -- Account Name: username_we_want_here_but_not_parsed Which I assume we need to do in the decoder Initially in OSSIM I was excluding (no user) but I decided on a different path and I was trying to match on the status/subcode (like this 0xC06F) as that tells me what really happened (this is not proving worthwhile as the sub code types are numerous) What matters after the username are the sub codes or status here as we get the kind of auth fail for this VERY wide scoping log Does anyone have any idea on how better to match at the decoder level? 18106 is if_sid 18105 which is if_sid 18100 which is rule id=18105 level=4 if_sid18100/if_sid status^AUDIT_FAILURE|^failure/status descriptionWindows audit failure event./description /rule and the generic decoder decoder name=windows typewindows/type prematch^WinEvtLog: /prematch regex offset=after_prematch^\.+: (\w+)\((\d+)\): (\.+): /regex regex(\.+): \.+: (\S+): /regex orderstatus, id, extra_data, srcuser, system_name/order ftsname, location, user, system_name/fts /decoder So, the srcuser is perhaps wrong? Maybe we need a second decoder for this and other events that don't leverage the initial username, adding an actor and actee type value? On Monday, November 3, 2014 4:37:34 PM UTC-5, Luke Goldman wrote: I am new to setting up Ossec but so far am liking it a lot. I am having one issue that I am sure someone has resolved. The main thing I am working right now is tracking failed windows logins. Most of this has worked right out of the box which is awesome. The issue I am having is that the Windows Event ID 4625 shows (no user) where every other Windows Event ID shows the username. So Ossec reports the user as (no user). This causes issues when I want to alert on 6 failed logins from the same user, as every user will match this (no user). Has anyone got a solution for this? Below is a log that will show what I am talking about. Thanks! 2014 Nov 03 12:05:34 WinEvtLog: Security: AUDIT_FAILURE(4625): Microsoft-Windows-Security-Auditing: (no user): 2014 Nov 03 13:15:27 WinEvtLog: Security: AUDIT_SUCCESS(4624): Microsoft-Windows-Security-Auditing: Username: -- --- 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] Capturing Window Event ID's
I have been following this thread with interest and I have a question First, there is no reason, on the surface this should not have worked using rule id = 19000, I tested in my lab on 2.7.1 and it worked. (I know I need to move up and I will this year) In my setup I tend to start with 7 for new rules and it just works, so I altered existing working rules to use 19000 with no errors. However, when using rule 18104, isn't he essentially overwriting a current rule with a different match? Further, since the override syntax is not used, is there not a conflict in the subsystem? Thank in advance for the information. On Tuesday, October 28, 2014 10:45:15 AM UTC-4, dan (ddpbsd) wrote: On Tue, Oct 28, 2014 at 10:39 AM, Brian ke...@myschatz.net javascript: wrote: I think I got it working; it may not be the correct way.. I removed Rule ID 19000 Added id^5142$|^5143$|^5144$|^5145$/id to Rule 18104 and gave Rule 18104 Level 2 and it seems to work now.. If continues to work correctly, I thank you for your help.. Old Rules: rule id=19000 level=2 Be careful using these ID ranges. New rules could always be added using those IDs, and that would cause issues. if_sid18100/if_sid id^5142$|^5143$|^5144$|^5145$/id status^AUDIT_SUCCESS|^success/status descriptionWindows audit success event./description /rule rule id=18104 level=0 if_sid18100/if_sid status^AUDIT_SUCCESS|^success/status descriptionWindows audit success event./description /rule New Rule: rule id=18104 level=2 if_sid18100/if_sid id^5142$|^5143$|^5144$|^5145$/id status^AUDIT_SUCCESS|^success/status descriptionWindows audit success event./description /rule On Tuesday, October 28, 2014 9:34:59 AM UTC-4, dan (ddpbsd) wrote: On Mon, Oct 27, 2014 at 8:34 PM, Brian ke...@myschatz.net wrote: From what I can tell, and I am doing this correctly. here is the log for event ID 5145. . I did run ./ossec-logtest , I placed WinEvtLog: Security: AUDIT_SUCCESS(5145) and it took me to Rule 18100 and not 19000. below I have my log, rules and logtest Log: 2014 Oct 27 14:16:54 (WinClient) 10.10.10.67-WinEvtLog 2014 Oct 27 14:17:07 WinEvtLog: Security: AUDIT_SUCCESS(5145): Microsoft-Windows-Security-Auditing: (no user): no domain: WinClient.Domain.Local: S-1-5-21-3748380571-1685127485-3479259990-2707 User01 Domain 0xbe810a File 10.5.5.8 51134 \\*\IPC$ srvsvc 0x12019f %%1538 %%1541 %%4416 %%4417 %%4418 %%4419 %%4420 %%4423 %%4424 I don't know enough about the Windows stuff to know why all of these are being presented on their own lines and whatnot. Running everything up until the first newline through ossec-logtest gives me the following output (Removing everything between the beginning of the line and 2014 because that should be an OSSEC header added to the archives.log entries): [root@localhost ddp]# cat /tmp/xxx 2014 Oct 27 14:17:07 WinEvtLog: Security: AUDIT_SUCCESS(5145): Microsoft-Windows-Security-Auditing: (no user): no domain: WinClient.Domain.Local: S-1-5-21-3748380571-1685127485-3479259990-2707 User01 Domain 0xbe810a File 10.5.5.8 51134 \\*\IPC$ srvsvc 0x12019f %%1538 [root@localhost ddp]# cat /tmp/xxx | /var/ossec/bin/ossec-logtest 2014/10/28 09:30:41 ossec-testrule: INFO: Reading local decoder file. 2014/10/28 09:30:41 ossec-testrule: INFO: Started (pid: 6981). ossec-testrule: Type one log per line. **Phase 1: Completed pre-decoding. full event: '2014 Oct 27 14:17:07 WinEvtLog: Security: AUDIT_SUCCESS(5145): Microsoft-Windows-Security-Auditing: (no user): no domain: WinClient.Domain.Local: S-1-5-21-3748380571-1685127485-3479259990-2707 User01 Domain 0xbe810a File 10.5.5.8 51134 \\*\IPC$ srvsvc 0x12019f %%1538' hostname: 'localhost' program_name: '(null)' log: '2014 Oct 27 14:17:07 WinEvtLog: Security: AUDIT_SUCCESS(5145): Microsoft-Windows-Security-Auditing: (no user): no domain: WinClient.Domain.Local: S-1-5-21-3748380571-1685127485-3479259990-2707 User01 Domain 0xbe810a File 10.5.5.8 51134 \\*\IPC$ srvsvc 0x12019f %%1538' **Phase 2: Completed decoding. decoder: 'windows' status: 'AUDIT_SUCCESS' id: '5145' extra_data: 'Microsoft-Windows-Security-Auditing' dstuser: '(no user)' system_name: 'WinClient.Domain.Local' **Phase 3: Completed filtering (rules). Rule id: '18104' Level: '0' Description: 'Windows audit success event.' So the id is decoded. And this rule successfully captures that log message: rule id=31 level=6 if_sid18104/if_sid id^5142$|^5143$|^5144$|^5145$/id status^AUDIT_SUCCESS|^success/status
Re: [ossec-list] Re: Windows agents not connecting to OSSEC server
That file is definitely required, though I am not sure it has anything to do with the agent connecting in. You showed earlier connections on port 1514 from the devices in question right? Does the ossec.log note any issues with those devices? for what it is worth, here is a sender_counter file from an active working lab install silly-lab-box:/var/ossec/queue/rids# pwd /var/ossec/queue/rids silly-lab-box:/var/ossec/queue/rids# date Fri Oct 17 19:06:38 UTC 2014 silly-lab-box:/var/ossec/queue/rids# ls -lahrt total 28K drwxrwx--- 11 ossec ossec 4.0K Dec 7 2013 .. drwxrwx--- 2 ossec ossec 4.0K Sep 23 18:26 . -rw-r--r-- 1 ossecr ossec8 Oct 17 15:19 4 -rwxrwx--- 1 ossec ossec8 Oct 17 19:03 3 -rwxrwx--- 1 ossec ossec 16 Oct 17 19:06 sender_counter -rwxrwx--- 1 ossec ossec 10 Oct 17 19:06 2 -rwxrwx--- 1 ossec ossec 10 Oct 17 19:06 001 silly-lab-box:/var/ossec/queue/rids# more sender_counter 81:5072:70:4350: Grant Leonard Castra Consulting, LLC http://castraconsulting.com/#/ 919-949-4002 On Fri, Oct 17, 2014 at 2:52 PM, David Masters dmast...@24-7intouch.com wrote: I got most everything to work except at one site. After looking through everything on that server, I noticed that the sender_counter file is missing from rids directory. I know that keeps track/count of something...could that be what's causing some of my agents to not be able to connect? On Sunday, October 12, 2014 4:34:03 AM UTC-5, David Masters wrote: I have searched through the listings and the internet and cannot seem to find a solution to this issue. We have approximately 3200 computers (Windows 7) that we are trying to get configured with OSSEC. The agent is part of the image that we are rolling out to the machines. All the machines have been added to the server (Ubuntu 12.04.4 LTS, OSSEC server v. 2.8) via manage_agents. I have written a script that runs via group policy that stops the ossec service, removes the client.keys and ossec.conf files from the machine, then copies over a new ossec.conf and client.keys file with the correct information (server IP and client key) and restarts the ossec service. If the windows client (v 2.8) is installed clean, it connects to the server and communicates properly. If it is done via the group policy (utilizing the exact same information), the following occurs (pulled from a log file on a clean machine): 2014/10/12 04:16:13 ossec-agent: Using notify time: 600 and max time to reconnect: 1800 2014/10/12 04:16:13 ossec-execd(1350): INFO: Active response disabled. Exiting. 2014/10/12 04:16:13 ossec-agent(1410): INFO: Reading authentication keys file. 2014/10/12 04:16:13 ossec-agent: INFO: No previous counter available for 'FRI-COMPUTER1'. 2014/10/12 04:16:13 ossec-agent: INFO: Assigning counter for agent FRI-COMPUTER1: '0:0'. 2014/10/12 04:16:13 ossec-agent: INFO: Assigning sender counter: 0:179 2014/10/12 04:16:13 ossec-agent: INFO: Trying to connect to server ( 10.50.3.4:1514). 2014/10/12 04:16:13 ossec-agent: INFO: Using IPv4 for: 10.50.3.4 . 2014/10/12 04:16:13 ossec-agent: Starting syscheckd thread. 2014/10/12 04:16:13 ossec-rootcheck: INFO: Started (pid: 6800). 2014/10/12 04:16:13 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Software\Classes\batfile'. 2014/10/12 04:16:13 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Software\Classes\cmdfile'. 2014/10/12 04:16:13 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Software\Classes\comfile'. 2014/10/12 04:16:13 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Software\Classes\exefile'. 2014/10/12 04:16:13 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Software\Classes\piffile'. 2014/10/12 04:16:13 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Software\Classes\AllFilesystemObjects'. 2014/10/12 04:16:13 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Software\Classes\Directory'. 2014/10/12 04:16:13 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Software\Classes\Folder'. 2014/10/12 04:16:13 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Software\Classes\Protocols'. 2014/10/12 04:16:13 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Software\Policies'. 2014/10/12 04:16:13 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Security'. 2014/10/12 04:16:13 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer'. 2014/10/12 04:16:13 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services'. 2014/10/12 04:16:13 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\KnownDLLs'. 2014/10/12 04:16:13 ossec-agent: INFO: Monitoring registry entry: 'HKEY_LOCAL_MACHINE\System\CurrentControlSet
Re: [ossec-list] Windows agents not connecting to OSSEC server
You need the and before port Sorry sent from my phone On Oct 13, 2014 8:59 PM, David Masters dmast...@24-7intouch.com wrote: The exact command I typed is was: tcpdump -i eth1 host xxx.xxx.xxx.xxx port 1514 No other ethernet ports are active on the machine. Did I miss something when I typed it in? On Monday, October 13, 2014 7:43:23 PM UTC-5, Grant L wrote: I guessed at your eth interface the command is sound, I just dont know what your OS looks like SO tcpdump -i replace this with the interface name, like eth0 host replace this with the IP of the sending WIn7 platform and port 1514 -vvv Make sense? Grant Leonard Castra Consulting, LLC http://castraconsulting.com/#/ 919-949-4002 On Mon, Oct 13, 2014 at 8:32 PM, David Masters dmas...@24-7intouch.com wrote: client is installed on Win7 machine with admin credentials (logged in as domain admin and ran as administrator to install, group policy installation runs under system credentials before login). tcpdump gives me a : syntax error on each IP address I have tried it on. On Monday, October 13, 2014 6:18:08 PM UTC-5, Grant L wrote: Do this for about 5 non communicating servers at random. On the OSSEC-SERVER run 'tcpdump -i eth0 host ip of server in question port 1514' see if the connection even makes it to the server Also, note that OSSEC has to be installed as local admin or domain admin, else UAC kind of kills the application. Grant Leonard Castra Consulting, LLC http://castraconsulting.com/#/ 919-949-4002 On Mon, Oct 13, 2014 at 6:55 PM, David Masters dmas...@24-7intouch.com wrote: This is what we did last year Entered in the machines manually to the server to create the account/key on the ossec server once all of the machines were entered, we ran cat client.keys on the ossec server, which reads/prints out all the keys to the screen the session was being recorded to the putty.log (using putty to connect to the ossec server) the key list was copied from the putty.log (txt file) to a spreadsheet this spreadsheet was used to manually enter each key into each individual system when the agent was installed. This year we have roughly 2/3 again as many systems as we did last year, so are trying to automate as much of this as possible. We wrote a script that reads the computer names from a CSV to create the machine accounts on the OSSEC server (utilizing manage_agents (which we wrote before it was found out that they had added that functionality to the 2.8.1 version). This creates the individual machine accounts. Then we read the keys from the server (cat client.keys) just like we did last year, copying the keys from the putty.log file into a spreadsheet. I then copy out those keys into individual text files named with the individual computer name (ie: each line is a computer account/key which then gets copied into its own text file named after itself and with the proper .keys file format)(computer1.keys, computer2.keys, computer3.keys, etc). I have a group policy that uninstalls any previous version of ossec agent, then installs the current version (2.8), copies over the ossec.conf file with the proper server info and copies over the computer name file into a client.keys file on the machine (reads the machine name from the BIOS, then finds the proper computername.keys file and copies it over to that machine into the ossec folder as client.keys, then starts the ossec agent. The machine boots and the agent contains all the proper information except that it won't communicate with the server. The file structure is identical with a freshly installed local agent with the manually entered information, except for the communication errors. Which part of that process is screwing me up? On Monday, October 13, 2014 5:31:09 PM UTC-5, gr...@castraconsulting.com wrote: David You wrote -- The key files I am creating are being created directly from the spreadsheet You are not creating the keys yourself are you? when you run manage-agents and add a new agent, a key gets put into client.keys, that key is associated with the hostname of the sending device and can only be used one. You don't have to have an IP of the remote agent, you can use any instead of 1.1.1.1 in case IP overlap is occuring. I have to ask, port 1514 is accessible from the Windows servers in question, right? They can actually send UDP 1514 packets to the Ossec-server? The scripts we wrote literally just loop through a csv file of ip,hostname and create the placeholder in manage-agent, then map a share connection to the target, move the agent over and attempt to run the agent with the creds provided and I don't do batches larger than 100 at a time just to make sure the ossec-server is keeping up. Has any of this helped you sir? On Monday, October 13, 2014 3:47:12 PM UTC-4, David Masters wrote: I am acquiring the keys originally from the server (cat client.keys
Re: [ossec-list] Windows agents not connecting to OSSEC server
Great point David Grant Leonard Castra Consulting, LLC http://castraconsulting.com/#/ 919-949-4002 On Tue, Oct 14, 2014 at 12:00 PM, Rick McClinton rickm...@gmail.com wrote: David, I'm not confident that notepad, wordpad, or notepad++ wouldn't hide the byte order marker at the start of a Unicode file. You mentioned scripting the creation of the key files; did you use Powershell for this? In one of our (unrelated) projects, we learned we needed to be sure to use the '-Encoding UTF-8' parameter to the 'out-file' commandlet; as the default 'Unicode' would insert the byte order marker in the output file. We were able to see the BOM when I opened the file with GVIM and (IIRC) using the 'type' command, but some other editors did not show it. HTH; Rick McClinton On Monday, October 13, 2014 8:58:07 PM UTC-4, David Masters wrote: I will try the process you suggest tomorrow. As for the rest: there are no duplicate IP's (all agents have been added with the any IP configuration) or ID's (all keys were deleted from the client.keys file (except 001) in order to prevent duplicates)(all rid's were deleted afterwards to make sure there weren't any issues there either, all done while the ossec services were stopped)). both files (client.keys and ossec.conf being pushed out) were examined in notepad, wordpad and notepad++ (multiple languanges) to verify there were no extra non-visible characters/line breaks/carriage returns present. -- --- 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/Zmfag8ajU3s/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.
Re: [ossec-list] Windows agents not connecting to OSSEC server
Assuming agent key and IP are distinct for each server, please put the ossec-control into debug on the server and look for errors such as not allowed and so forth On Monday, October 13, 2014 8:04:41 AM UTC-4, Antonio Querubin wrote: On Sun, 12 Oct 2014, David Masters wrote: Ok...here is the log file from a freshly installed agent (shutdown ossec server, removed all rid files, no rid files on agent system, manually entererd key and server address): This is the log file from same machine after pushing out key file/ossec.conf file and deleting rid files (no change to any other part of the machine or configuration): Verified all information in both files was exactly the same as before and files in rids directory were deleted before service was restarted. Any ideas? Did you remove the corresponding rids file on the server? Antonio Querubin e-mail: to...@lavanauts.org javascript: xmpp: antonio...@gmail.com javascript: -- --- 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] Windows agents not connecting to OSSEC server
David You wrote -- The key files I am creating are being created directly from the spreadsheet You are not creating the keys yourself are you? when you run manage-agents and add a new agent, a key gets put into client.keys, that key is associated with the hostname of the sending device and can only be used one. You don't have to have an IP of the remote agent, you can use any instead of 1.1.1.1 in case IP overlap is occuring. I have to ask, port 1514 is accessible from the Windows servers in question, right? They can actually send UDP 1514 packets to the Ossec-server? The scripts we wrote literally just loop through a csv file of ip,hostname and create the placeholder in manage-agent, then map a share connection to the target, move the agent over and attempt to run the agent with the creds provided and I don't do batches larger than 100 at a time just to make sure the ossec-server is keeping up. Has any of this helped you sir? On Monday, October 13, 2014 3:47:12 PM UTC-4, David Masters wrote: I am acquiring the keys originally from the server (cat client.keys) then copying that information directly from the putty.log file into a spreadsheet. The key files I am creating are being created directly from the spreadsheet. I manually verify the information in the keys file before it is copied down to the computer. Same with the ossec.conf file...it was copied originally from a machine that was communicating properly with the server. If you guys know of any scripts or automation help you can offer, I would be most appreciative. I've been banging my head against a wall on this one. On Monday, October 13, 2014 12:30:10 PM UTC-5, LostInThe Tubez wrote: Many people have created an automated deployment script successfully, so no need to worry there. How are you exporting the agent keys from the manager? More to the point, WHICH key are you using in your group policy script? If you really are using the same key that you would use in the GUI, as you state, then that’s the problem. Here’s an exercise to illustrate the point: manually install an agent, such that it is communicating with the manager successfully. Open client.keys on the agent and look at the key. Now compare that key to the one in /var/ossec/etc/client.keys on the manager. They should be the same. When manually shuffling keys about using scripts, there is no need to extract the key using manage_agents. *From:* ossec...@googlegroups.com [mailto:ossec...@googlegroups.com] *On Behalf Of *David Masters *Sent:* Monday, October 13, 2014 9:19 AM *To:* ossec...@googlegroups.com *Subject:* Re: [ossec-list] Windows agents not connecting to OSSEC server The whole purpose of this exercise is to not have to go to each individual machine to input the key and configuration. We have over 3000 machines so that really is just not feasible. If the key server is input manually when the software is installed it works fine. When the key file and config file are pushed out over the network (containing the exact same information that would have been input manually), it does not. This would be to the same machine, same configuration, no changes between manual input and pushed input. (except that it is not done manually). If this is not possible, I would like to know this as soon as possible so that we can find a different solution for our IPS/IDS/FIM system. Thank you. On Monday, October 13, 2014 10:33:59 AM UTC-5, dan (ddpbsd) wrote: On Mon, Oct 13, 2014 at 11:21 AM, David Masters dmas...@24-7intouch.com wrote: 2014/10/13 10:19:11 ossec-remoted(1403): ERROR: Incorrectly formated message from 'any'. 2014/10/13 10:19:13 ossec-remoted(1408): ERROR: Invalid ID for the source ip: '10.50.107.21'. Try readding the key to one of these agents manually (not one of the any agents, but the ones with the IP address specifically). 2014/10/13 10:19:16 ossec-remoted(1408): ERROR: Invalid ID for the source ip: '10.50.107.20'. 2014/10/13 10:19:16 ossec-remoted(1403): ERROR: Incorrectly formated message from 'any'. 2014/10/13 10:19:17 ossec-remoted(1408): ERROR: Invalid ID for the source ip: '10.50.107.21'. 2014/10/13 10:19:22 ossec-remoted(1408): ERROR: Invalid ID for the source ip: '10.50.107.20'. 2014/10/13 10:19:22 ossec-remoted(1403): ERROR: Incorrectly formated message from 'any'. 2014/10/13 10:19:22 ossec-remoted(1408): ERROR: Invalid ID for the source ip: '10.50.107.21'. 2014/10/13 10:19:28 ossec-remoted(1408): ERROR: Invalid ID for the source ip: '10.50.107.21'. 2014/10/13 10:19:54 ossec-remoted(1408): ERROR: Invalid ID for the source ip: '10.50.111.64'. On Monday, October 13, 2014 7:52:05 AM UTC-5, gr...@castraconsulting.com wrote: Assuming agent key and IP are distinct for each server, please put the ossec-control into debug on the server and look for
Re: [ossec-list] Windows agents not connecting to OSSEC server
Do this for about 5 non communicating servers at random. On the OSSEC-SERVER run 'tcpdump -i eth0 host ip of server in question port 1514' see if the connection even makes it to the server Also, note that OSSEC has to be installed as local admin or domain admin, else UAC kind of kills the application. Grant Leonard Castra Consulting, LLC http://castraconsulting.com/#/ 919-949-4002 On Mon, Oct 13, 2014 at 6:55 PM, David Masters dmast...@24-7intouch.com wrote: This is what we did last year Entered in the machines manually to the server to create the account/key on the ossec server once all of the machines were entered, we ran cat client.keys on the ossec server, which reads/prints out all the keys to the screen the session was being recorded to the putty.log (using putty to connect to the ossec server) the key list was copied from the putty.log (txt file) to a spreadsheet this spreadsheet was used to manually enter each key into each individual system when the agent was installed. This year we have roughly 2/3 again as many systems as we did last year, so are trying to automate as much of this as possible. We wrote a script that reads the computer names from a CSV to create the machine accounts on the OSSEC server (utilizing manage_agents (which we wrote before it was found out that they had added that functionality to the 2.8.1 version). This creates the individual machine accounts. Then we read the keys from the server (cat client.keys) just like we did last year, copying the keys from the putty.log file into a spreadsheet. I then copy out those keys into individual text files named with the individual computer name (ie: each line is a computer account/key which then gets copied into its own text file named after itself and with the proper .keys file format)(computer1.keys, computer2.keys, computer3.keys, etc). I have a group policy that uninstalls any previous version of ossec agent, then installs the current version (2.8), copies over the ossec.conf file with the proper server info and copies over the computer name file into a client.keys file on the machine (reads the machine name from the BIOS, then finds the proper computername.keys file and copies it over to that machine into the ossec folder as client.keys, then starts the ossec agent. The machine boots and the agent contains all the proper information except that it won't communicate with the server. The file structure is identical with a freshly installed local agent with the manually entered information, except for the communication errors. Which part of that process is screwing me up? On Monday, October 13, 2014 5:31:09 PM UTC-5, gr...@castraconsulting.com wrote: David You wrote -- The key files I am creating are being created directly from the spreadsheet You are not creating the keys yourself are you? when you run manage-agents and add a new agent, a key gets put into client.keys, that key is associated with the hostname of the sending device and can only be used one. You don't have to have an IP of the remote agent, you can use any instead of 1.1.1.1 in case IP overlap is occuring. I have to ask, port 1514 is accessible from the Windows servers in question, right? They can actually send UDP 1514 packets to the Ossec-server? The scripts we wrote literally just loop through a csv file of ip,hostname and create the placeholder in manage-agent, then map a share connection to the target, move the agent over and attempt to run the agent with the creds provided and I don't do batches larger than 100 at a time just to make sure the ossec-server is keeping up. Has any of this helped you sir? On Monday, October 13, 2014 3:47:12 PM UTC-4, David Masters wrote: I am acquiring the keys originally from the server (cat client.keys) then copying that information directly from the putty.log file into a spreadsheet. The key files I am creating are being created directly from the spreadsheet. I manually verify the information in the keys file before it is copied down to the computer. Same with the ossec.conf file...it was copied originally from a machine that was communicating properly with the server. If you guys know of any scripts or automation help you can offer, I would be most appreciative. I've been banging my head against a wall on this one. On Monday, October 13, 2014 12:30:10 PM UTC-5, LostInThe Tubez wrote: Many people have created an automated deployment script successfully, so no need to worry there. How are you exporting the agent keys from the manager? More to the point, WHICH key are you using in your group policy script? If you really are using the same key that you would use in the GUI, as you state, then that’s the problem. Here’s an exercise to illustrate the point: manually install an agent, such that it is communicating with the manager successfully. Open client.keys on the agent and look at the key. Now compare that key
Re: [ossec-list] Windows agents not connecting to OSSEC server
I guessed at your eth interface the command is sound, I just dont know what your OS looks like SO tcpdump -i replace this with the interface name, like eth0 host replace this with the IP of the sending WIn7 platform and port 1514 -vvv Make sense? Grant Leonard Castra Consulting, LLC http://castraconsulting.com/#/ 919-949-4002 On Mon, Oct 13, 2014 at 8:32 PM, David Masters dmast...@24-7intouch.com wrote: client is installed on Win7 machine with admin credentials (logged in as domain admin and ran as administrator to install, group policy installation runs under system credentials before login). tcpdump gives me a : syntax error on each IP address I have tried it on. On Monday, October 13, 2014 6:18:08 PM UTC-5, Grant L wrote: Do this for about 5 non communicating servers at random. On the OSSEC-SERVER run 'tcpdump -i eth0 host ip of server in question port 1514' see if the connection even makes it to the server Also, note that OSSEC has to be installed as local admin or domain admin, else UAC kind of kills the application. Grant Leonard Castra Consulting, LLC http://castraconsulting.com/#/ 919-949-4002 On Mon, Oct 13, 2014 at 6:55 PM, David Masters dmas...@24-7intouch.com wrote: This is what we did last year Entered in the machines manually to the server to create the account/key on the ossec server once all of the machines were entered, we ran cat client.keys on the ossec server, which reads/prints out all the keys to the screen the session was being recorded to the putty.log (using putty to connect to the ossec server) the key list was copied from the putty.log (txt file) to a spreadsheet this spreadsheet was used to manually enter each key into each individual system when the agent was installed. This year we have roughly 2/3 again as many systems as we did last year, so are trying to automate as much of this as possible. We wrote a script that reads the computer names from a CSV to create the machine accounts on the OSSEC server (utilizing manage_agents (which we wrote before it was found out that they had added that functionality to the 2.8.1 version). This creates the individual machine accounts. Then we read the keys from the server (cat client.keys) just like we did last year, copying the keys from the putty.log file into a spreadsheet. I then copy out those keys into individual text files named with the individual computer name (ie: each line is a computer account/key which then gets copied into its own text file named after itself and with the proper .keys file format)(computer1.keys, computer2.keys, computer3.keys, etc). I have a group policy that uninstalls any previous version of ossec agent, then installs the current version (2.8), copies over the ossec.conf file with the proper server info and copies over the computer name file into a client.keys file on the machine (reads the machine name from the BIOS, then finds the proper computername.keys file and copies it over to that machine into the ossec folder as client.keys, then starts the ossec agent. The machine boots and the agent contains all the proper information except that it won't communicate with the server. The file structure is identical with a freshly installed local agent with the manually entered information, except for the communication errors. Which part of that process is screwing me up? On Monday, October 13, 2014 5:31:09 PM UTC-5, gr...@castraconsulting.com wrote: David You wrote -- The key files I am creating are being created directly from the spreadsheet You are not creating the keys yourself are you? when you run manage-agents and add a new agent, a key gets put into client.keys, that key is associated with the hostname of the sending device and can only be used one. You don't have to have an IP of the remote agent, you can use any instead of 1.1.1.1 in case IP overlap is occuring. I have to ask, port 1514 is accessible from the Windows servers in question, right? They can actually send UDP 1514 packets to the Ossec-server? The scripts we wrote literally just loop through a csv file of ip,hostname and create the placeholder in manage-agent, then map a share connection to the target, move the agent over and attempt to run the agent with the creds provided and I don't do batches larger than 100 at a time just to make sure the ossec-server is keeping up. Has any of this helped you sir? On Monday, October 13, 2014 3:47:12 PM UTC-4, David Masters wrote: I am acquiring the keys originally from the server (cat client.keys) then copying that information directly from the putty.log file into a spreadsheet. The key files I am creating are being created directly from the spreadsheet. I manually verify the information in the keys file before it is copied down to the computer. Same with the ossec.conf file...it was copied originally from a machine that was communicating properly with the server. If you guys
Re: [ossec-list] OSSEC rule for Shellshock CGI attacks?
You are relying on this if_sid31100/if_sid however that doesn't exist in 2.7.1 Where would I find the Apache rules for 2.8 so I can copy that rule in? On Saturday, October 4, 2014 9:30:57 AM UTC-4, Michael Starks wrote: On 10/04/2014 05:30 AM, Jan Andrasko wrote: Rob, issue with your rule was that this string is not part of url. It is usually in place of user agent, which is not decoded by Ossec. Therefore you need to regex whole log message. Brgds Jan A note about this: I have seen this exploit in several of the HTTP headers, and even in a cookie! Since OSSEC doesn't always decode fields correctly and since there are many parts of the log where this could appear, I would advise against using anything like URL and just stick with the match and regex elements. -- --- 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] how to change web UI password?
I'm new to using OSSEC...does anyone know how to change the Web UI default password? It's installed as 'ossec' for the username and password but we'd like to change it to something more secure. Thanks! Noah
RE: [ossec-list] how to change web UI password?
Thanks Dan, that did it :) Noah Grant Systems Engineer Ext. 3212 -Original Message- From: ossec-list@googlegroups.com [mailto:ossec-list@googlegroups.com] On Behalf Of dan (ddp) Sent: Monday, June 06, 2011 2:55 PM To: ossec-list@googlegroups.com Subject: Re: [ossec-list] how to change web UI password? cd to the wui directory. htpasswd USERNAME This should prompt you for a password On Mon, Jun 6, 2011 at 5:47 PM, Noah Grant noah.gr...@teligence.net wrote: I'm new to using OSSEC...does anyone know how to change the Web UI default password? It's installed as 'ossec' for the username and password but we'd like to change it to something more secure. Thanks! Noah
