RE: [ossec-list] eventchannel decoder testing

[lostinthetubez]

Response inline

> -Original Message-
> From: ossec-list@googlegroups.com [mailto:ossec-list@googlegroups.com]
> On Behalf Of dan (ddp)
> Sent: Wednesday, August 3, 2016 5:52 AM
> To: ossec-list@googlegroups.com
> Subject: Re: [ossec-list] eventchannel decoder testing
> 
> On Tue, Aug 2, 2016 at 10:40 PM, lostinthetubez
>  wrote:
> > I’d give Wazuh a whirl, if I were you. They’ve got decoders and rules for
> > sysmon, as well as eventchannel working (or I assume they do, if they have
> > that stuff setup for sysmon).
> >
> >
> >
> > My current decoder/rule development server and agents have been
> around long
> > enough that I don’t recall what sort of Frankenstein mixture of agent and
> > server versions I am running. Now that I think back on it, I’m fairly
> > certain I had to track down a fixed version of the Windows agent in the
> > listserv archives to make 2.8.3 work.
> >
> 
> Do you have more information on this? It doesn't sound familiar.

Pretty sure I snagged Josh's fixed binary, back when the onedrive link in this 
thread still worked:
https://groups.google.com/forum/#!topic/ossec-list/o1SXX5Wk0A0

I will try to do more testing with the current 2.9 beta code in a week or two, 
see if I can validate any of the issues I observed earlier in the thread.

> 
> >
> >
> > From: ossec-list@googlegroups.com [mailto:ossec-list@googlegroups.com]
> On
> > Behalf Of Craig Mitchell
> > Sent: Tuesday, August 2, 2016 7:13 PM
> > To: ossec-list@googlegroups.com
> >
> >
> > Subject: Re: [ossec-list] eventchannel decoder testing
> >
> >
> >
> > Thanks for the input! I'll take a closer look at 2.8.3 but the whole reason
> > I was looking at 2.9RC2 was because it supported the eventchannel log
> type.
> > From what I understand, 2.8.x had trouble with this and therefore had
> > trouble with sysmon. Has that been your experience with 2.8.3? Thanks
> again
> > everyone for the help.
> >
> >
> >
> > On Tue, Aug 2, 2016 at 8:49 PM, lostinthetubez
> 
> > wrote:
> >
> > Craig,
> >
> >
> >
> > Hm... I just now noticed your exact symptoms while playing with a test
> OSSEC
> > server that was created from a relatively recent git clone of the repository
> > (cloned within the last month or two?). Take a look at your original output
> > of ossec-logtest, under “Prepended Data Removed”. Look at the parsed
> “log:”
> > field. Ossec-logtest is stripping “2016 Jul 29 22:32:24 WinEvtLog:” before
> > processing it against the decoders. It isn’t supposed to be doing this. At
> > least, this was not the behavior under 2.8.3. I do not have time to test the
> > latest build from the repo to see if this problem has been fixed, though you
> > might give that a whirl if you have the luxury of time. If you just want to
> > make things work correctly, build your OSSEC server from the last known-
> good
> > release, which is 2.8.3, or just follow Jesus’ suggestion and try out the
> > Wazuh build.
> >
> >
> >
> >
> >
> > From: ossec-list@googlegroups.com [mailto:ossec-list@googlegroups.com]
> On
> > Behalf Of Craig
> > Sent: Sunday, July 31, 2016 3:14 PM
> > To: ossec-list 
> > Subject: Re: [ossec-list] eventchannel decoder testing
> >
> >
> >
> > Great, thank you. That does help troubleshoot. So, I do have a follow up
> > question. Here is the default decoder:
> >
> >
> >
> > 
> >
> >   windows
> >
> >   INFORMATION\(1\)
> >
> >   Image: (\.*) \s*CommandLine: \.*
> \s*User:
> > (\.*) \s*LogonGuid: \S* \s*LogonId: \S* \s*TerminalSessionId: \S*
> > \s*IntegrityLevel: \.*HashType: \S* \s*Hash: (\S*) \s*ParentProcessGuid:
> \S*
> > \s*ParentProcessID: \S* \s*ParentImage: (\.*)
> \s*ParentCommandLine:
> >
> >   status,user,url,data
> >
> > 
> >
> >
> >
> > However, when I remove the prepended data from my archives.log file
> and send
> > it through logtest, the decoder doesn't work (if I leave the prepended data
> > there, the decoder works). Any ideas why this might be happening? See
> below
> > for my logtest:
> >
> >
> >
> > Prepended Data Removed:
> >
> >
> >
> > **Phase 1: Completed pre-decoding.
> >
> >full event: '2016 Jul 29 22:32:24 WinEvtLog:
> > Microsoft-Windows-Sysmon/Operational: INFORMATION(1):
> > Microsoft-Windows-Sysmon: SYSTEM: NT AUTHORITY: Win7-x64-
> PC1.hackme.local:
> > Process Create:  UtcTime: 2016-07-30 03:32:24.846  ProcessGuid:
> > {67C360F4-1FC8-579C--001017F41E00}  ProcessId: 3988  Image:
> > C:\Users\administrator\Desktop\svchost.exe  CommandLine:
> > "C:\Users\administrator\Desktop\svchost.exe"   CurrentDirectory:
> > C:\Users\administrator\Desktop\  User: HACKME\Administrator
> LogonGuid:
> > {67C360F4-1C55-579C--00206BBC0600}  LogonId: 0x6bc6b
> TerminalSessionId:
> > 1  IntegrityLevel: High  Hashes:
> MD5=C019D10F80409FC4C7D45EBFA48B0076
> > ParentProcessGuid: {67C360F4-1C57-579C--001092EC0600}
> ParentProcessId:
> > 3056  ParentImage: C:\Windows\explorer.exe  ParentCommandLine:
> > 

[ossec-list] Re: Agents not connecting, traffic visible in tcpdump

[Cal]

Pedro,

Awesome! Your method worked flawlessly. Thanks!

Cal

On Tuesday, August 2, 2016 at 8:51:59 PM UTC-4, Pedro S wrote:
>
> Hi Cal,
>
>
> Try disabling counters. They lose synchronisation specially when agents 
> are reinstalled.
> Edit /var/ossec/etc/internal_options.conf and set 
> "remoted.verify_msg_id=0", both agent & manager.
>
> Enable debug mode on both hosts, open internal_options and set debug to 
> level 2 (specially in remoted.debug variable).
>
> Sometimes the problem could be related with NAT, try adding the agent with 
> "any" option and test if it works (use manage_agent and when prompting for 
> IP enter "any").
>
> Open etc/client.keys on OSSEC Manager (be careful! this file is critical) 
> and remove duplicated entries, the agent will fail to connect if there is 
> more than one entry with the same IP.
>
> Hope it helps,
>
> best regards,
>
> Pedro S.
>
>
>
> On Tuesday, August 2, 2016 at 2:08:14 PM UTC-7, Cal wrote:
>>
>> Hi all,
>>
>> Been debugging an issue for a few hours, thought I'd ask for another 
>> opinion.
>>
>> The situation:
>> I have an OSSEC server with approximately 70 agents connected and 15 or 
>> so that won't connect.
>>
>> Tested so far:
>> Tcpdump shows UDP packets from both OSSEC agents and server (running on 
>> non-standard port 1520)
>> Traceroute from agent to server and other direction, no problem
>> Can ping the server from agent
>> Can ping the agent from server
>>
>> Ex:
>> server:
>> 15:51:00.135367 IP 172.28.156.XX.60625 > 172.28.29.XX.1520: UDP, length 73
>>
>> agent:
>> 15:51:00.135916 IP 172.28.156.XX.60625 > 172.28.29.XX.1520: UDP, length 73
>>
>> I've tried re-adding the keys to agents several times. Enabled debugging 
>> on server, but only noted logs are from the agent:
>> 2016/08/02 15:56:39 ossec-agentd: INFO: Trying to connect to server 
>> (172.28.29.XX:1520).
>> 2016/08/02 15:56:39 ossec-agentd: INFO: Using IPv4 for: 172.28.29.XX
>>
>> Any ideas where to look next? I've also tried removing the agents, 
>> re-adding, re-installing, etc.
>>
>> 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] Filter out dynamic dns hostnames

[Herman Harperink]

I know that, but maybe somebody know a way around that. Thats why I
ask.There is always a way, and I will find it :-)

Thanks.


On Wed, Aug 3, 2016 at 4:16 PM, dan (ddp)  wrote:

> On Wed, Aug 3, 2016 at 9:07 AM, Herman Harperink
>  wrote:
> > Hi Dan,
> >
> > When my phone / pc /ipad collects email I get an "dovecot authentication
> > success" event. I could ignore this event by downrating it to zero in
> > local_rules so it won't be logged, but I want to see all succesful
> > authentications on my mailserver from hosts that are not my own (since I
> am
> > the only one using it). Same goes for ftp, ssh etc
> > In case someone hacks my server, or steals my credentials that would
> light
> > up on my dash.
> >
> > My home internet connection has a dynamic ip, but by using a dyndns
> provider
> > (duckdns) I have a static own domainname. However, ossec lookups always
> > return the dynamic hostname my provider gave me, and never my dyndns
> > hostname since they don't update dns records (no authority).
> > If I lookup my dyndns hostname on my ossec manager I get my ip. But if I
> > lookup my ip I get my providers hostname wich is not static.
> >
> > So: connection from xxx.xxx.xxx.xxx resolves to dip-t-somewhat-hostname
> > (within ossec). I am looking for a way to let ossec check if ip
> > xxx.xxx.xxx.xxx is my myhost.duckdns.org hostname, and if it is, ignore
> the
> > event.
> >
>
> There is no facility to do DNS lookups in the analysis engine.
>
> >
> >
> > On Wed, Aug 3, 2016 at 2:47 PM, dan (ddp)  wrote:
> >>
> >> On Wed, Aug 3, 2016 at 1:48 AM, Herman Harperink
> >>  wrote:
> >> > Hi all,
> >> >
> >> > Can somebody hint me in the right direction on this?
> >> > I have two dynamic hosts with a ddns hostname and I don't want those
> to
> >> > trigger events. But I can't find a way to do that anywhere.
> >> >
> >> > Thanks in advance.
> >> >
> >>
> >> Remove the agents from those hosts? I'm probably misunderstanding
> >> something, maybe an example of what you don't want to see would help?
> >>
> >> >  Herman
> >> >
> >> > --
> >> >
> >> > ---
> >> > 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/6e9ehDQW_jE/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.
>
> --
>
> ---
> 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/6e9ehDQW_jE/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: ERROR: Unable to send file 'merged.mg' to agent.

[Kat]

One thing to also check is permissions and ownership on "merged.mg" - many 
times I see it get mucked up and OSSEC can't read it. I have found that if 
I delete it, then restart OSSEC it will be re-created and it no longer has 
issues sending the file after that.  (Not sure WHY it happens though)

Cheers
Kat

(PS - Hi Graeme!)

On Thursday, July 28, 2016 at 11:43:32 AM UTC-5, Graeme Stewart wrote:
>
> Seeing a lot of errors in the logfiles like this:
>
> 2016/07/28 16:41:48 ossec-remoted: ERROR: Unable to send file 'merged.mg' 
> to agent.
> 2016/07/28 16:41:50 ossec-remoted(1217): ERROR: Error creating encrypted 
> message.
> 2016/07/28 16:41:50 ossec-remoted: ERROR: Unable to send file 'merged.mg' 
> to agent.
> 2016/07/28 16:41:50 ossec-remoted(1217): ERROR: Error creating encrypted 
> message.
> 2016/07/28 16:41:50 ossec-remoted: ERROR: Unable to send file 'merged.mg' 
> to agent.
> 2016/07/28 16:41:52 ossec-remoted(1217): ERROR: Error creating encrypted 
> message.
> 2016/07/28 16:41:52 ossec-remoted: ERROR: Unable to send file 'merged.mg' 
> to agent.
> 2016/07/28 16:41:52 ossec-remoted(1217): ERROR: Error creating encrypted 
> message.
> 2016/07/28 16:41:52 ossec-remoted: ERROR: Unable to send file 'merged.mg' 
> to agent.
> 2016/07/28 16:41:54 ossec-remoted(1217): ERROR: Error creating encrypted 
> message.
> 2016/07/28 16:41:54 ossec-remoted: ERROR: Unable to send file 'merged.mg' 
> to agent.
> 2016/07/28 16:41:56 ossec-remoted(1217): ERROR: Error creating encrypted 
> message.
>
> Any guidance on troubleshooting? Search hasn't turned up much other than 
> delete merged.mg and restart (which we've tried to no success)...
>

-- 

--- 
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: can we re-use agentID's

[Kat]

Hmm -- I re-use IDs all the time. Did it when I had 30,000+ agents, and now 
with only 10,000.  You just have to delete the key (I don't like that they 
are commented out) and make sure you remove the rids agent files in 
/var/ossec/queue/ossec/rids - find the number of the agent you removed and 
remove that file. Then you are free to re-use agent IDs all the time.  

Cheers
Kat

On Thursday, July 28, 2016 at 2:03:34 PM UTC-5, Chanti Naani wrote:
>
> Hi,
> We have a pretty decent implementation of the ossec with max clients set 
> to 3000. 
> So far we have generated close to 2900 client keys  with in the past 1 
> year. 
> But at the same time , a lot of people moved out and almost 500 endpoints 
> are not in use. 
>
> If we delete those 500 endpoints (using /var/ossec/bin/manage_agents -r 
> $id) , will we be able to add 500 new clients to the ossec server? 
> without re-compiling the ossec authd server with increased set MAX_AGENTS)
>
> we are running:
>
> OSSEC HIDS v2.8 
>
> 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: Unable to start agent (check config)

[Семён С]

my user is an administrator. On his behalf, I ran the executable file

-- 

--- 
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] eventchannel decoder testing

[Jesus Linares]

Hi Craig, 

did you try to use the new decoders?. I think it could be work.

Steps:

   - Create a backup of your decoder.xml
   - Replace "windows decoder" copying from line 174 to 417 of this file

(https://github.com/wazuh/ossec-rules/blob/master/rules-decoders/ossec/decoders/windows_decoders.xml#L174)
   - Restart ossec

Let me know if it works.

On Wednesday, August 3, 2016 at 4:40:29 AM UTC+2, LostInThe Tubez wrote:
>
> I’d give Wazuh a whirl, if I were you. They’ve got decoders and rules for 
> sysmon, as well as eventchannel working (or I assume they do, if they have 
> that stuff setup for sysmon). 
>
>  
>
> My current decoder/rule development server and agents have been around 
> long enough that I don’t recall what sort of Frankenstein mixture of agent 
> and server versions I am running. Now that I think back on it, I’m fairly 
> certain I had to track down a fixed version of the Windows agent in the 
> listserv archives to make 2.8.3 work. 
>
>  
>
> *From:* ossec...@googlegroups.com  [mailto:
> ossec...@googlegroups.com ] *On Behalf Of *Craig Mitchell
> *Sent:* Tuesday, August 2, 2016 7:13 PM
> *To:* ossec...@googlegroups.com 
> *Subject:* Re: [ossec-list] eventchannel decoder testing
>
>  
>
> Thanks for the input! I'll take a closer look at 2.8.3 but the whole 
> reason I was looking at 2.9RC2 was because it supported the eventchannel 
> log type. From what I understand, 2.8.x had trouble with this and therefore 
> had trouble with sysmon. Has that been your experience with 2.8.3? Thanks 
> again everyone for the help.
>
>  
>
> On Tue, Aug 2, 2016 at 8:49 PM, lostinthetubez  > wrote:
>
> Craig,
>
>  
>
> Hm... I just now noticed your exact symptoms while playing with a test 
> OSSEC server that was created from a relatively recent git clone of the 
> repository (cloned within the last month or two?). Take a look at your 
> original output of ossec-logtest, under “Prepended Data Removed”. Look at 
> the parsed “log:” field. Ossec-logtest is stripping “2016 Jul 29 22:32:24 
> WinEvtLog:” before processing it against the decoders. It isn’t supposed to 
> be doing this. At least, this was not the behavior under 2.8.3. I do not 
> have time to test the latest build from the repo to see if this problem has 
> been fixed, though you might give that a whirl if you have the luxury of 
> time. If you just want to make things work correctly, build your OSSEC 
> server from the last known-good release, which is 2.8.3, or just follow 
> Jesus’ suggestion and try out the Wazuh build.
>
>  
>
>  
>
> *From:* ossec...@googlegroups.com  [mailto:
> ossec...@googlegroups.com ] *On Behalf Of *Craig
> *Sent:* Sunday, July 31, 2016 3:14 PM
> *To:* ossec-list 
> *Subject:* Re: [ossec-list] eventchannel decoder testing
>
>  
>
> Great, thank you. That does help troubleshoot. So, I do have a follow up 
> question. Here is the default decoder:
>
>  
>
> 
>
>   windows
>
>   INFORMATION\(1\)
>
>   Image: (\.*) \s*CommandLine: \.* \s*User: 
> (\.*) \s*LogonGuid: \S* \s*LogonId: \S* \s*TerminalSessionId: \S* 
> \s*IntegrityLevel: \.*HashType: \S* \s*Hash: (\S*) \s*ParentProcessGuid: 
> \S* \s*ParentProcessID: \S* \s*ParentImage: (\.*) 
> \s*ParentCommandLine:
>
>   status,user,url,data
>
> 
>
>  
>
> However, when I remove the prepended data from my archives.log file and 
> send it through logtest, the decoder doesn't work (if I leave the prepended 
> data there, the decoder works). Any ideas why this might be happening? See 
> below for my logtest:
>
>  
>
> *Prepended Data Removed:*
>
>  
>
> **Phase 1: Completed pre-decoding.
>
>full event: '2016 Jul 29 22:32:24 WinEvtLog: 
> Microsoft-Windows-Sysmon/Operational: INFORMATION(1): 
> Microsoft-Windows-Sysmon: SYSTEM: NT AUTHORITY: Win7-x64-PC1.hackme.local: 
> Process Create:  UtcTime: 2016-07-30 03:32:24.846  ProcessGuid: 
> {67C360F4-1FC8-579C--001017F41E00}  ProcessId: 3988  Image: 
> C:\Users\administrator\Desktop\svchost.exe  CommandLine: 
> "C:\Users\administrator\Desktop\svchost.exe"   CurrentDirectory: 
> C:\Users\administrator\Desktop\  User: HACKME\Administrator  LogonGuid: 
> {67C360F4-1C55-579C--00206BBC0600}  LogonId: 0x6bc6b 
>  TerminalSessionId: 1  IntegrityLevel: High  Hashes: 
> MD5=C019D10F80409FC4C7D45EBFA48B0076  ParentProcessGuid: 
> {67C360F4-1C57-579C--001092EC0600}  ParentProcessId: 3056  ParentImage: 
> C:\Windows\explorer.exe  ParentCommandLine: C:\Windows\Explorer.EXE'
>
>hostname: 'ubuntu-srv1'
>
>program_name: 'WinEvtLog'
>
>log: 'Microsoft-Windows-Sysmon/Operational: INFORMATION(1): 
> Microsoft-Windows-Sysmon: SYSTEM: NT AUTHORITY: Win7-x64-PC1.hackme.local: 
> Process Create:  UtcTime: 2016-07-30 03:32:24.846  ProcessGuid: 
> {67C360F4-1FC8-579C--001017F41E00}  ProcessId: 3988  Image: 
> C:\Users\administrator\Desktop\svchost.exe  CommandLine: 
> "C:\Users\administrator\Desktop\svchost.exe"   CurrentDirectory: 
>