[ossec-list] How/where does one get a version of the OSSEC agent-auth application that will run on Windows?

[Chris]

I have successfully configured an OSSEC server running on Ubuntu in AWS.


I have also successfully automated Ubuntu AWS instances automatically 
installing the OSSEC agent and connecting to the OSSEC server via this 
command /var/ossec/bin/agent-auth -m ossec.myprivatedomain.local -p 1515


I am working on automating the installation of the OSSEC agent for Windows 
instances including automating the Windows instances connecting to the 
OSSEC server. I understand that the OSSEC agent for Windows can be 
downloaded from the OSSEC site's "Downloads" page and that it can be 
silently installed using this command line: ossec-agent-win32-2.8.3.exe /S


Despite much research, I cannot find out how to get a version of the OSSEC 
agent-auth executable that will run on Windows to allow me to automate the 
Windows instances connecting to the OSSEC server.


The closest thing I can find to any mention of the agent-auth application 
being available for Windows is from this blog: 
https://github.com/ossec/ossec-hids/issues/166#issuecomment-41461642 ... 
where a comment states ...

The Windows version of agent-auth was compiled on Linux (Fedora 20) and 
tested on Windows 7 Home Premium 64-bit.

None of the tutorials that talk about compiling the OSSEC agent for Windows 
on Linux address how to compile the agent-auth application for Windows.


How/where does one get a version of the OSSEC agent-auth application that 
will run on Windows?

-- 

--- 
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: logs level 0 and level 1

[Maxim Surdu]

no

luni, 21 decembrie 2015, 15:07:06 UTC+2, dan (ddpbsd) a scris:
>
> On Mon, Dec 21, 2015 at 8:03 AM, Maxim Surdu  > wrote: 
> >> but in ossec-wui in stats is showing me what i have alert with level 0 
> and 
> >> 1 
> > 
>
> Are level 0 and level 1 alerts showing up in the alerts.log 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+...@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] File Integrity Monitoring through OSSEC

[Nishant Porwal]

Guys , any comments ?

On Fri, Dec 18, 2015 at 7:06 PM, Nishant Porwal 
wrote:

> Hi Santiago/Dan,
>
> Thanks for the inputs ,i am able to track the changes.
> One more suggestion is needed ,
>
> I want to track the file changes and need to alert only on specific
> changes .
> Example : -
>
> File : - memory.cfg
>
> Content : -
>
> *
>
> *Server* : 1.2.3.4
> *Port *: 8080,80,9090,28443,23
> *Services *: Telnet,SSH, FTPD,
> *log_alert *: Yes
> *log_memory *: Yes
> *log_system *: Yes
> *log_application *: Yes
> *log_tomcat* : Yes
>
> *
>
> Reuirement is : -
>
> If any changes have been done in parameters *Server* ,*Port ,**Services ,*
> *log_tomcat*  notify to certain email , else if *log_alert ,**log_memory
> ,*
> *log_application ,**log_system  *have been changed don't notify .
>
> On Tue, Dec 8, 2015 at 7:01 AM, Santiago Bassett <
> santiago.bass...@gmail.com> wrote:
>
>> More comments:
>>
>> 1.When file have been changed  ?
>> Use realtime option (kernel needs to support inotify, most recent ones do)
>>
>> 2.Who have changed it ?
>> No easy way to do this. I would use Audit tools and parse their output
>> with an OSSEC decoder/rules (I think those would need to be created).
>>
>> 3.What have been changed ?
>>
>> As Dan mentioned, report_changes. Only works on text files (doesn't make
>> sense for binaries).
>>
>> 4.Notify on certain changes .
>>
>> What do you mean? Permission changes, ownership changes are reported by
>> syscheck too.
>>
>> On Sun, Dec 6, 2015 at 9:10 AM, dan (ddp)  wrote:
>>
>>>
>>> On Dec 6, 2015 11:01 AM, "Nishant Porwal" 
>>> wrote:
>>> >
>>> > Hi Guys ,
>>> >
>>> > I need to monitor approx 50 config and flat files on 20 servers ,
>>> means 1000 files .
>>> >
>>> > My requirement is below .
>>> >
>>> > 1.When file have been changed  ?
>>> > 2.Who have changed it ?
>>>
>>> No one has come up with a way to do this through syscheck yet.
>>>
>>> > 3.What have been changed ?
>>> > 4.Notify on certain changes .
>>> >
>>> > Most important part id "What have been changed "
>>> >
>>>
>>> Report_changes I think is the option you want.
>>>
>>> > All are linux servers .
>>> >
>>> > OSSEC can help here ?
>>> > I couldn't find anything in documentation specifying about "what have
>>> beeen changed " .
>>> >
>>> >
>>> > Thanks
>>> > Nishant
>>> >
>>> > --
>>> >
>>> > ---
>>> > You received this message because you are subscribed to the Google
>>> Groups "ossec-list" group.
>>> > To unsubscribe from this group and stop receiving emails from it, send
>>> an email to ossec-list+unsubscr...@googlegroups.com.
>>> > For more options, visit https://groups.google.com/d/optout.
>>>
>>> --
>>>
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "ossec-list" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to ossec-list+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>>
>> ---
>> 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.
>>
>
>
>
> --
> Thanks n Regards
> Nishant Porwal
> 09527916969
>



-- 
Thanks n Regards
Nishant Porwal
09527916969

-- 

--- 
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: logs level 0 and level 1

[dan (ddp)]

On Dec 21, 2015 8:32 AM, "Maxim Surdu"  wrote:
>
> no
>

Then I have no idea where the wui is getting that stat from.

> luni, 21 decembrie 2015, 15:07:06 UTC+2, dan (ddpbsd) a scris:
>>
>> On Mon, Dec 21, 2015 at 8:03 AM, Maxim Surdu  wrote:
>> >> but in ossec-wui in stats is showing me what i have alert with level
0 and
>> >> 1
>> >
>>
>> Are level 0 and level 1 alerts showing up in the alerts.log 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+...@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 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] Clients authenticate, but don't connect (Corp env)

[Jamey B]

Hi Dan,

When we use manage_agents and export the key to the agent, the agent works
fine. We've had success this way, but obviously it's tedious for over 5000
servers. Isn't this similar how authd works? I'm wondering if there's
something we're not executing after the agent gets a key.

I've regenerated the SSL key on the server (somehow it was missing), so
agents no longer have issues connecting for their key -- this is what
caused all the agent alerts a few posts ago. We are following the guide
below, but the agents just don't connect after getting their key:

http://dcid.me/blog/2011/01/automatically-creating-and-setting-up-the-agent-keys/
On Dec 21, 2015 8:05 AM, "dan (ddp)"  wrote:

> On Thu, Dec 17, 2015 at 1:21 PM, Jamey B  wrote:
> > Hi,
> >
> > SELINUX isn't enabled, we also looked at all the permissions and they
> appear
> > fine.
> >
> > We manually added an agent on the server and manually imported a fresh
> > client key,  then restarted the agent. It successfully added itself
> without
> > using authd that we had success with in a different environment (done via
> > Puppet using command agent-auth -m  -p ). Should we use
> > port 1515, then 1514 when using this?
> >
> > Perhaps we're not adding the agents correctly?
> >
>
> agent-auth connects to an authd process. So the power used there
> should be the port authd is listening on.
>
> What happens if you use manage_agents on the server to add an agent
> and export the key. Then use manage_agents on the agent to import the
> key?
>
> > On Dec 16, 2015 10:37 AM, "lostinthetubez" 
> wrote:
> >>
> >> Is selinux enabled? Long shot, I know. Regardless, OSSEC needs to be
> able
> >> to access the client.keys file, both on the agent and the manager,
> before it
> >> can communicate. If permissions and ownership aren’t the problem –
> which,
> >> they look fine btw – then I don’t honestly know why it would be
> complaining.
> >> You haven’t customized the users under which the services start, have
> you?
> >> Compare a client.keys from a working agent with a non-working agent.
> Perhaps
> >> there is a problem with the file format, encoding, or non-printable
> >> characters. Can’t really think of anything else at the moment.
> >>
> >>
> >>
> >> From: ossec-list@googlegroups.com [mailto:ossec-list@googlegroups.com]
> On
> >> Behalf Of Jamey B
> >> Sent: Tuesday, December 15, 2015 5:55 PM
> >> To: ossec-list@googlegroups.com
> >> Subject: RE: [ossec-list] Clients authenticate, but don't connect (Corp
> >> env)
> >>
> >>
> >>
> >> Sorry about that, that's my local VirtualBox image that I use for
> testing.
> >> OSSEC on the server with the client keys shows the same permissions as
> my
> >> local VM. Could it be a local OS issue that the server is on?
> >>
> >> On Dec 15, 2015 10:18 AM, "lostinthetubez" 
> >> wrote:
> >>
> >> Your commandline prompt indicates that this is not the same machine that
> >> you were talking about in the previous post. Please look at the
> situation on
> >> adr318, whatever that box is.
> >>
> >>
> >>
> >> From: ossec-list@googlegroups.com [mailto:ossec-list@googlegroups.com]
> On
> >> Behalf Of Jamey B
> >> Sent: Tuesday, December 15, 2015 7:06 AM
> >> To: ossec-list@googlegroups.com
> >> Subject: Re: [ossec-list] Clients authenticate, but don't connect (Corp
> >> env)
> >>
> >>
> >>
> >> Hi lostinthetubez,
> >>
> >>
> >>
> >> Yes, the client.keys file exists on the server and the client has the
> >> correct key. The permissions are as follows for /var/ossec/etc/:
> >>
> >>
> >>
> >> root@ccisprlx11 # ls -la ../etc/
> >>
> >> total 136
> >>
> >> dr-xr-x---  3 root ossec  4096 Dec 14 17:23 .
> >>
> >> dr-xr-x--- 13 root ossec  4096 Dec 14 16:59 ..
> >>
> >> -r--r-  1 root ossec84 Dec 14 17:24 client.keys
> >>
> >> -r--r-  1 root ossec 97786 Jun 10  2015 decoder.xml
> >>
> >> -r--r-  1 root ossec  2842 Jun 10  2015 internal_options.conf
> >>
> >> -r--r-  1 root ossec  3519 May  4  2010 localtime
> >>
> >> -r--r-  1 root ossec  8360 Dec 14 16:59 ossec.conf
> >>
> >> -rw-r-  1 root root 88 Dec 14 16:59 ossec-init.conf
> >>
> >> drwxrwx---  2 root ossec  4096 Dec 14 16:59 shared
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> Do you see anything odd with the permissions?
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Mon, Dec 14, 2015 at 4:28 PM, lostinthetubez <
> lostinthetu...@gmail.com>
> >> wrote:
> >>
> >> Looks like permissions or ownership are wrong on your client.keys file,
> >> which would certainly explain the agent not being able to connect. I
> assume
> >> you’ve checked that the client.keys file exists and contains the correct
> >> information for the agent you are using as an example here?
> >>
> >>
> >>
> >> >> 2015/12/14 07:31:08 ossec-agentd(1103): ERROR: Unable to open file
> >> >> '/etc/client.keys'.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> From: ossec-list@googlegroups.com 

Re: [ossec-list] Re: logs level 0 and level 1

[Maxim Surdu]

>
> i check ossec.conf and i have 
>
 
 
1
  
 but in ossec-wui or kibana is showing just alerts with minum 2, but i know 
what i have alerts with level 0 and 1 and i need them to be showed 
ossec-wui or kibana

-- 

--- 
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 for apache access log on ubuntu - not generating alerts

[Venkata Venamma]

Hello experts,

I want to monitor apache access.log on ubunu using ossec. Have configured 
local_rules.xml as below, in addition to adding the log file 
/var/log/apache2/acces.log to ossec.conf file.

Entry in local_rules.xml:

apache,

  
31100
Web server 400 error code.
  



When I hit the apache server with too many not existent URLs ( this forcing 
too many 404 in access.log), I was expecting to receive email and generate 
alerts. I don't see any activity in the ossec log or alert log.
Can you please provide some pointers how to solve?

Thanks in advance,

-R


-- 

--- 
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: logs level 0 and level 1

[dan (ddp)]

On Mon, Dec 21, 2015 at 3:27 AM, Maxim Surdu  wrote:
>> i check ossec.conf and i have
>
>
>  
> 1
>   
>  but in ossec-wui or kibana is showing just alerts with minum 2, but i know
> what i have alerts with level 0 and 1 and i need them to be showed ossec-wui
> or kibana
>

Level 0 alerts should not be logged. That's kind of the point.
Are level 1 alerts showing up in your alerts.log file? If not, you
haven't triggered any, and they will not show up.

> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ossec-list" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ossec-list+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ossec-list] ossec for apache access log on ubuntu - not generating alerts

[dan (ddp)]

On Mon, Dec 21, 2015 at 7:40 AM, Venkata Venamma  wrote:
> Hello experts,
>
> I want to monitor apache access.log on ubunu using ossec. Have configured
> local_rules.xml as below, in addition to adding the log file
> /var/log/apache2/acces.log to ossec.conf file.
>
> Entry in local_rules.xml:
>
> apache,
> 
>   
> 31100
> Web server 400 error code.
>   
> 
>

You're missing the "^4" from the rule.


>
> When I hit the apache server with too many not existent URLs ( this forcing
> too many 404 in access.log), I was expecting to receive email and generate
> alerts. I don't see any activity in the ossec log or alert log.
> Can you please provide some pointers how to solve?
>
> Thanks in advance,
>
> -R
>
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ossec-list" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ossec-list+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ossec-list] Re: logs level 0 and level 1

[dan (ddp)]

On Mon, Dec 21, 2015 at 8:03 AM, Maxim Surdu  wrote:
>> but in ossec-wui in stats is showing me what i have alert with level 0 and
>> 1
>

Are level 0 and level 1 alerts showing up in the alerts.log 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.

-- 

--- 
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: logs level 0 and level 1

[Maxim Surdu]

> but in ossec-wui in stats is showing me what i have alert with level 0 and 
> 1 

-- 

--- 
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] Clients authenticate, but don't connect (Corp env)

[dan (ddp)]

On Thu, Dec 17, 2015 at 1:21 PM, Jamey B  wrote:
> Hi,
>
> SELINUX isn't enabled, we also looked at all the permissions and they appear
> fine.
>
> We manually added an agent on the server and manually imported a fresh
> client key,  then restarted the agent. It successfully added itself without
> using authd that we had success with in a different environment (done via
> Puppet using command agent-auth -m  -p ). Should we use
> port 1515, then 1514 when using this?
>
> Perhaps we're not adding the agents correctly?
>

agent-auth connects to an authd process. So the power used there
should be the port authd is listening on.

What happens if you use manage_agents on the server to add an agent
and export the key. Then use manage_agents on the agent to import the
key?

> On Dec 16, 2015 10:37 AM, "lostinthetubez"  wrote:
>>
>> Is selinux enabled? Long shot, I know. Regardless, OSSEC needs to be able
>> to access the client.keys file, both on the agent and the manager, before it
>> can communicate. If permissions and ownership aren’t the problem – which,
>> they look fine btw – then I don’t honestly know why it would be complaining.
>> You haven’t customized the users under which the services start, have you?
>> Compare a client.keys from a working agent with a non-working agent. Perhaps
>> there is a problem with the file format, encoding, or non-printable
>> characters. Can’t really think of anything else at the moment.
>>
>>
>>
>> From: ossec-list@googlegroups.com [mailto:ossec-list@googlegroups.com] On
>> Behalf Of Jamey B
>> Sent: Tuesday, December 15, 2015 5:55 PM
>> To: ossec-list@googlegroups.com
>> Subject: RE: [ossec-list] Clients authenticate, but don't connect (Corp
>> env)
>>
>>
>>
>> Sorry about that, that's my local VirtualBox image that I use for testing.
>> OSSEC on the server with the client keys shows the same permissions as my
>> local VM. Could it be a local OS issue that the server is on?
>>
>> On Dec 15, 2015 10:18 AM, "lostinthetubez" 
>> wrote:
>>
>> Your commandline prompt indicates that this is not the same machine that
>> you were talking about in the previous post. Please look at the situation on
>> adr318, whatever that box is.
>>
>>
>>
>> From: ossec-list@googlegroups.com [mailto:ossec-list@googlegroups.com] On
>> Behalf Of Jamey B
>> Sent: Tuesday, December 15, 2015 7:06 AM
>> To: ossec-list@googlegroups.com
>> Subject: Re: [ossec-list] Clients authenticate, but don't connect (Corp
>> env)
>>
>>
>>
>> Hi lostinthetubez,
>>
>>
>>
>> Yes, the client.keys file exists on the server and the client has the
>> correct key. The permissions are as follows for /var/ossec/etc/:
>>
>>
>>
>> root@ccisprlx11 # ls -la ../etc/
>>
>> total 136
>>
>> dr-xr-x---  3 root ossec  4096 Dec 14 17:23 .
>>
>> dr-xr-x--- 13 root ossec  4096 Dec 14 16:59 ..
>>
>> -r--r-  1 root ossec84 Dec 14 17:24 client.keys
>>
>> -r--r-  1 root ossec 97786 Jun 10  2015 decoder.xml
>>
>> -r--r-  1 root ossec  2842 Jun 10  2015 internal_options.conf
>>
>> -r--r-  1 root ossec  3519 May  4  2010 localtime
>>
>> -r--r-  1 root ossec  8360 Dec 14 16:59 ossec.conf
>>
>> -rw-r-  1 root root 88 Dec 14 16:59 ossec-init.conf
>>
>> drwxrwx---  2 root ossec  4096 Dec 14 16:59 shared
>>
>>
>>
>>
>>
>>
>>
>> Do you see anything odd with the permissions?
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Mon, Dec 14, 2015 at 4:28 PM, lostinthetubez 
>> wrote:
>>
>> Looks like permissions or ownership are wrong on your client.keys file,
>> which would certainly explain the agent not being able to connect. I assume
>> you’ve checked that the client.keys file exists and contains the correct
>> information for the agent you are using as an example here?
>>
>>
>>
>> >> 2015/12/14 07:31:08 ossec-agentd(1103): ERROR: Unable to open file
>> >> '/etc/client.keys'.
>>
>>
>>
>>
>>
>>
>>
>> From: ossec-list@googlegroups.com [mailto:ossec-list@googlegroups.com] On
>> Behalf Of Jamey B
>> Sent: Monday, December 14, 2015 12:55 PM
>> To: ossec-list@googlegroups.com
>> Subject: Re: [ossec-list] Clients authenticate, but don't connect (Corp
>> env)
>>
>>
>>
>> Thanks for that, I think this is a bigger issue than I believed judging by
>> the read out below from one of the agents not connecting. Do you think the
>> command you provided will fix it? It seems the install or CONF file went
>> wonky during the install, but the agent has been reinstalled multiple times.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> root@adr318 # cat /var/ossec/logs/ossec.log
>>
>> 2015/12/14 07:30:51 ossec-authd: INFO: Started (pid: 3787).
>>
>> 2015/12/14 07:30:58 ossec-execd(1314): INFO: Shutdown received. Deleting
>> responses.
>>
>> 2015/12/14 07:30:58 ossec-execd(1225): INFO: SIGNAL Received. Exit
>> Cleaning...
>>
>> 2015/12/14 07:31:08 ossec-execd: INFO: Started (pid: 3875).
>>
>> 2015/12/14 07:31:08 ossec-agentd: INFO: Using notify time: 600 and max
>> time to reconnect: 

Re: [ossec-list] ossec-maild Error Sending email to 127.0.0.1

[dan (ddp)]

On Sun, Dec 20, 2015 at 7:50 AM, theresa mic-snare
 wrote:
> Hi everyone,
>
> today I've noticed a problem with the ossec-maild process.
> The ossec.log keeps saying
>
> ossec-maild(1223): ERROR: Error Sending email to 127.0.0.1 (smtp server)
>
> Of course I started troubleshooting the problem and tried to send several
> test-emails from the ossec master.
> I'm using ssmtp through my google-mail account by the way.
> All test mails that I sent arrived immediately, so sending mails through my
> MTA seems to work as usual.
>
> Then I checked the mail log /var/log/maillog-20151220
> which to my surprise has the latest mail entry from yesterday 19:30
> Dec 19 19:30:03 tron sSMTP[3943]: Sent mail for b...@bla.org (221 2.0.0
> closing connection u126sm11888435wme.3 - gsmtp) uid=48 username=apache
> outbytes=1898
>
> changed the email address to b...@bla.org for demonstration purposes...
>
>
> at least the two test emails that I just send should appear in this log,
> right?
>
> I know that the root cause to this problem is NOT an ossec problembut
> maybe you have an idea what the problem might be?
> I've checked the quota settings in my gmail account, (so far only 10%
> used...)
> I've also checked the disk space on my ossec master, still 21GB left on /
> (where also /var is mounted)
>
> so I doubt it's a quota or diskspace problem.
> i've also restarted (stopped and started) ossec, to see if any zombie
> processes still allocated the filesystem, and it therefore showed that
> plenty of diskspace was available.
> but even after the restart of ossec it still shows that it has plenty of
> diskspace available.
>
> any other ideas how I could troubleshoot this problem?
>

Make sure ssmtp is still listening on 127.0.0.1.
Use tcpdump or something similar to sniff the traffic between
ossec-maild and ssmtp.
Turn on debugging on ssmtp?

> thanks,
> theresa
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ossec-list" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ossec-list+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ossec-list] Trouble matching hash from 550 alert for CDB lookup

[dan (ddp)]

On Thu, Dec 17, 2015 at 3:36 PM, Jon Schipp  wrote:
> Hey all, my goal is to lookup the sha1 hash from the 550 syscheck alert in a
> CDB database but I'm not having any luck.
> I've tried the following things to get an alert to happen on a hash from the
> 550 alert
>
> 1. Wrote a simple decoder to decode the sha1sum as the id field and then
> look up the key in a CDB (see bottom of e-mail). I rebuilt the CDB files
> after each change
>
> 2. Match the sha1sum from a 550 alert using 
>
>   
> 550
> b493df1da32686b27ec147987882c805d3ff6263
> no_email_alert
> Hash found
>   
>
> 3. Match the sha1sum from a 550 alert using  (decoder is shown at bottom
> of e-mail)
>
>   
> 550
> New sha1sum
> integrity_new_hash
> b493df1da32686b27ec147987882c805d3ff6263
> no_email_alert
> Hash found
>   
>
> Regarding number 2.) I can  on the changed file (e.g.
> /etc/shadow) from a 550 alert without problem so this leads
> me to believe that it's not possible to match on hash from the alert
> (hopefully instead I'm making a mistake)
>
> Here's an alert example alert that contains the hash in the rules above that
> I'm trying to work with.
>
> ** Alert 1450383324.3842774: - ossec,syscheck,
> 2015 Dec 17 20:15:24 (server2) 1.1.1.2 ->syscheck
> Rule: 550 (level 7) -> 'Integrity checksum changed.'
> Integrity checksum changed for: '/etc/sysconfig/sshd'
> Size changed from '438' to '0'
> Old sha1sum was: '95bb6b667f597ac3a9146c184865b2a3efe50047'
> New sha1sum is : 'b493df1da32686b27ec147987882c805d3ff6263'   # <--- this is
> the hash I'm trying to match on in the rules above
>
>
> I have a simple decoder that will put the sha1sum in the id file.
>
> 
>   New sha1sum is : |New md5sum is : 
> 
>
> 
>   integrity_new_hash
>   '(\w+)'
>   id
> 
>
>  
> 550
> sha1sum
>
> no_email_alert
> Hash found in malware database!
>   
>
> ossec-testrule: Type one log per line.
>
> New sha1sum is : 'b493df1da32686b27ec147987882c805d3ff6263'   # <-- pasted
> hash line
>
>
> **Phase 1: Completed pre-decoding.
>full event: 'New sha1sum is :
> 'b493df1da32686b27ec147987882c805d3ff6263''
>hostname: 'ossec-sec'
>program_name: '(null)'
>log: 'New sha1sum is : 'b493df1da32686b27ec147987882c805d3ff6263''
>
> **Phase 2: Completed decoding.
>decoder: 'integrity_new_hash'
>id: 'b493df1da32686b27ec147987882c805d3ff6263'  # <--- yay, it's now
> referenced as id.
>
> Any help is appreciated
>

I think syscheck entries are decoded differently than most log
messages. Check src/analysisd/decoders/syscheck.c.

> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ossec-list" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ossec-list+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"ossec-list" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

RE: [ossec-list] ossec for apache access log on ubuntu - not generating alerts

[lostinthetubez]

You may very well have to download the latest rule files from the github 
repository in order to recognize the latest apache log format. You can verify 
by copy/pasting a line from your apache log into ossec-logtest and seeing if it 
knows how to decode it.

> -Original Message-
> From: ossec-list@googlegroups.com [mailto:ossec-list@googlegroups.com]
> On Behalf Of dan (ddp)
> Sent: Monday, December 21, 2015 5:52 AM
> To: ossec-list@googlegroups.com
> Subject: Re: [ossec-list] ossec for apache access log on ubuntu - not
> generating alerts
> 
> On Mon, Dec 21, 2015 at 7:40 AM, Venkata Venamma
>  wrote:
> > Hello experts,
> >
> > I want to monitor apache access.log on ubunu using ossec. Have configured
> > local_rules.xml as below, in addition to adding the log file
> > /var/log/apache2/acces.log to ossec.conf file.
> >
> > Entry in local_rules.xml:
> >
> > apache,
> > 
> >   
> > 31100
> > Web server 400 error code.
> >   
> > 
> >
> 
> You're missing the "^4" from the rule.
> 
> 
> >
> > When I hit the apache server with too many not existent URLs ( this forcing
> > too many 404 in access.log), I was expecting to receive email and generate
> > alerts. I don't see any activity in the ossec log or alert log.
> > Can you please provide some pointers how to solve?
> >
> > Thanks in advance,
> >
> > -R
> >
> >
> > --
> >
> > ---
> > You received this message because you are subscribed to the Google
> Groups
> > "ossec-list" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to ossec-list+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
> 
> --
> 
> ---
> You received this message because you are subscribed to the Google Groups
> "ossec-list" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ossec-list+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 

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