Re: [ossec-list] ossec-logcollector(1103): ERROR [(9)-(Bad file descriptor)]. Can't get my OSSEC agent to monitor my Windows logs.

[Victor Fernandez]

Hi Patrik and Dan,

I wonder if this issue may be related to the file path.
*C:\ProgramData\GlobalSCAPE\**EFT Server Enterprise/Logs* sounds to be a
directory. Could you confirm that?

The *localfile* configuration for logs supports paths or patterns to files
only. If you want to follow all the files inside this directory, you should
use a pattern like "C:\ProgramData\GlobalSCAPE\EFT Server Enterprise/Logs/*"

Hope it help.
Best regards,


*Victor M Fernandez-Castro*
IT Engineer — *Wazuh, Inc.*

On Mon, Apr 23, 2018 at 3:32 PM, dan (ddp)  wrote:

> On Fri, Apr 20, 2018 at 10:25 AM, Patrik Lindh 
> wrote:
> > Hello!
> > I've installed Ossec windoiws agent on a server 2008r2 and want to
> monitor
> > logs residing in:C:\ProgramData\GlobalSCAPE\EFT Server Enterprise/Logs
> >
> > But when i start the agent i get the following error: 2018/04/20 14:54:42
> > ossec-logcollector(1103): ERROR: Could not open file
> > 'C:\ProgramData\GlobalSCAPE\EFT Server Enterprise/Logs' due to [(9)-(Bad
> > file descriptor)].
> >
>
> Possibly unrelated, but your slashes are odd. You use backslashes
> until you get to Logs, then you use a forward slash.
>
> > Any idea why?
> >
> > The folder contains about 150 logs (5 new a day and kept in 30days)
> >
> > What I want to accomplish is to monitor the logs so that nobody changes
> them
> > and if someone do I want OSSEC to report it.
> >
> >
> > //P
> >
> > --
> >
> > ---
> > 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.

Re: [ossec-list] Expected behaviour of syscheck

[Victor Fernandez]

Hi,

The configuration parser allows multiple definitions of . OSSEC
reads the *ossec.conf* file first, and then *agent.conf* (only in agents).

The  option is aggregable so all directories specified will be
monitored. On the other hand, value-based options (like ) are
overwritten. So the option

120


Is applying. The Syscheck frequency is not accurate with low intervals.

This is because Syscheck performs some delays in order to guarantee a
low-performance impact. After performing a complete scan, it makes a pause
depending on the configuration:

   - If any directory has been set for real-time monitoring, Syscheck waits
   for 5 minutes until any file changes. After reporting all the files
   changed, it will wait for 5 minutes while it's not the time to perform a
   new complete scan.
   - If real-time was not enabled for any directory, Syscheck sleeps for 5
   minutes.

This value of 5 minutes is not configurable in OSSEC.

You surely have not enabled real-time, so the frequency of 120 seconds is
applying. However, the application is sleeping for 5 minutes between a scan
ending and the beginning of the next one.

If you use higher values like 20 and 10 minutes, you'll be able to see that
the last  option always applies.

Hope it help.

Best regards,


*Victor M Fernandez-Castro*
IT Engineer — *Wazuh, Inc.*

On Mon, Feb 26, 2018 at 2:03 AM, dan (ddp)  wrote:

> On Wed, Feb 21, 2018 at 2:18 PM, Jorge Martins 
> wrote:
> > Hi,
> >
> >
> > Why wonder if this is the expected behaviour for syscheck
> >
> >
> > I tried having 2 differents frequencies so I tested by adding 2 entries
> of
> >  on the ossec.conf, one having a 5 minutes frequency and other
> 2
> > minutes.
> >
> >
> >   
> > no
> > 300
> >
> > E:/syscheck1
> >   
> >
> >
> >   
> > no
> > 120
> >
> > E:/syscheck2
> >   
> >
> >
> > What happen was this:
> >
> > Either where recognized by the agent
> >
> >
> > 2018/02/21 18:49:30 ossec-agent: INFO: Monitoring directory:
> 'E:/syscheck1',
> > with options perm | size | owner | group | md5sum | sha1sum | mtime |
> inode.
> > 2018/02/21 18:49:30 ossec-agent: INFO: Monitoring directory:
> 'E:/syscheck2',
> > with options perm | size | owner | group | md5sum | sha1sum | mtime |
> inode.
> >
> > The scan frequency anounced on the log was the second one
> >
> >
> > 2018/02/21 18:50:00 ossec-agent: INFO: Syscheck scan frequency: 120
> seconds
> >
> >
> > But the frequency adopted was the first one (5 minutes)
> >
> >
> > 2018/02/21 18:51:00 ossec-agent: INFO: Starting syscheck scan.
> > 2018/02/21 18:51:31 ossec-agent: INFO: Ending syscheck scan.
> > 2018/02/21 18:56:31 ossec-agent: INFO: Starting syscheck scan.
> > 2018/02/21 18:57:15 ossec-agent: INFO: Ending syscheck scan.
> > 2018/02/21 19:02:15 ossec-agent: INFO: Starting syscheck scan.
> > 2018/02/21 19:02:57 ossec-agent: INFO: Ending syscheck scan.
> >
> > The agent reported correctly file changes in both folders
> >
>
> Sounds like a bug in handling a bad configuration.
>
> >
> > Thanks
> >
> > --
> >
> > ---
> > You received this message because you are subscribed to the Google Groups
> > "ossec-list" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to ossec-list+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ossec-list" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ossec-list+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 

--- 
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] Help needed creating local rule to ignore an ossec core alert

[Victor Fernandez]

Hi,

The name of the agent isn't extracted into a field for that rule.

This is an example of an alert of disconnected agent:

** Alert 1515842367.7996: mail  -
ossec,pci_dss_10.6.1,pci_dss_10.2.6,gpg13_10.1,
2018 Jan 13 12:19:27 fedora->ossec-monitord
Rule: 504 (level 3) -> 'Ossec agent disconnected.'
ossec: Agent disconnected: 'ubuntu-any'.


You may use *ossec-logtest* to test and debug your rules:

*# /var/ossec/bin/ossec-logtest*
ossec-testrule: Type one log per line.

*ossec: Agent disconnected: 'ubuntu-any'.*


**Phase 1: Completed pre-decoding.
   full event: 'ossec: Agent disconnected: 'ubuntu-any'.'
   timestamp: '(null)'
   hostname: 'fedora'
   program_name: '(null)'
   log: 'ossec: Agent disconnected: 'ubuntu-any'.'

**Phase 2: Completed decoding.
   decoder: 'ossec'

**Phase 3: Completed filtering (rules).
   *Rule id: '504'*
   *Level: '3'*
   Description: 'Ossec agent disconnected.'
**Alert to be generated.


As you can see, the hostname (*fedora* in my case) matches the name of the
manager, not the name of the agent. The agent is noted as "name-IP" (or "
name-any" if the agent is not restricted to an IP address), but this data
does not appear in a separate field.

So the easiest way to get what you want is to match the entire input log
with the name of your agent (or agents) using the  option.

For example, if we want to silence this rule for the agents "ubuntu-any"
and "server-192.168.1.4" this rule works:

<*rule* id="100400" level="0">
  <*if_sid*>504
  <*match*>ubuntu-any|server-192.168.1.4
  <*description*>Ignore ossec disconnects from ubuntu or server.


Of course, you don't have to put the complete agent info including the IP,
you may specify the name only.

This is the result:

*# /var/ossec/bin/ossec-logtest*
ossec-testrule: Type one log per line.

*ossec: Agent disconnected: 'ubuntu-any'.*


**Phase 1: Completed pre-decoding.
   full event: 'ossec: Agent disconnected: 'ubuntu-any'.'
   timestamp: '(null)'
   hostname: 'fedora'
   program_name: '(null)'
   log: 'ossec: Agent disconnected: 'ubuntu-any'.'

**Phase 2: Completed decoding.
   decoder: 'ossec'

**Phase 3: Completed filtering (rules).
   *Rule id: '100400'*
   *Level: '0'*
   Description: 'Ignore ossec disconnects from ubuntu or server.'


Hope it help.

Best regards,



*Victor M Fernandez-Castro*
IT Engineer — *Wazuh, Inc.*

On Fri, Jan 12, 2018 at 5:03 AM,  wrote:

> I've been trying to create a rule in my local_rules.xml file for a few
> hours now with no success, and I'm hoping someone can help. I'm sure I'm
> doing something really dumb and am just too tired to see it right now.
>
> I would like to create a rule that will basically override Rule 504 (ossec
> agent disconnected) for a few specific clients. I've added this rule to my
> local_rules.xml file:
>
> 
>
>   
> 504
> host1.company.net
> Ignore ossec disconnects from host1.
>   
>
>
>   
> 504
> host2.company.net
> Ignore ossec disconnects from host2.
>   
>
>  
>
> Unfortunately, I am still getting email alerts whenever the ossec clients
> on host1 or host2 disconnect. To complicate matters, I can't figure out how
> to use ossec-logtest to try and test out these rules because the triggering
> condition is not part of any log (as far as I'm aware), so I don't know
> what type of example I could feed into the system.
>
> The only thing I can think of is that the ossec rules invoke a pre-decoder
> that does not provide a hostname for the client, or perhaps provides an
> inconsistent hostname. For example, the hostname that's decoded from syslog
> is (I think) the FQDN of the client. But perhaps the ossec decoder only
> knows the client by its agent name (which may not match the FQDN)?
>
> All of the documentation and examples I can find assume that I'm trying to
> override or augment rules for things like syslog, sshd, or apache; I
> haven't found anything that discusses how to augment an ossec core rule
> (ID's between 0 and 999) *unless *I want to completely silence the rule;
> but in this case, I'd just like to silence the rule for one or two clients.
>
> Any help would be greatly appreciated. Thanks!
>
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ossec-list" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ossec-list+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 

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

Re: [ossec-list] Re: ignore / ignore regex behavior

[Victor Fernandez]

Hi Sean,

if you want to filter by agent name, taking into account that the key is at
the begin of the name, you could simply use this pattern:

<*agent_config* *name*=”^m1”>
  


<*agent_config* *name*=”^g1”>
  


<*agent_config* *name*=”^t5”>
  



The *name* option filters by agent name. If you want to use profiles
instead of agent names, you may use <*agent_config* *profile*=”"> in the
*agent.conf* and set the agents' profile in their *ossec.con*f:

<*client*>
  <*server-ip*>192.168.1.100
  <*config-profile*>production
  <*protocol*>udp
  <*notify_time*>300
  <*time-reconnect*>900



Hope it help.
Best regards.


On Mon, Oct 9, 2017 at 10:13 AM, Sean Roe  wrote:

> I did some more research, found that  might do
> what I need, but how do I define which machines use which profile?  Do I
> define a block of servers in some profile block?  Im still looking at the
> documentation but Im not finding much info on it.
>
> Thanks,
> Sean
>
>
> On Monday, October 9, 2017 at 9:55:50 AM UTC-7, Sean Roe wrote:
>>
>> Hi All,
>>
>> I have been looking for documentation on how to break up out ignores
>> based on server name:
>>
>> example:
>>
>> our prod servers all start with m1x.blah.blah
>> our dev servers all start with g1x.blah.blah
>> our QA servers all start with t5x.blah.blah
>>
>> (dont ask me, I didnt come up with the names).
>>
>> So for m1 servers we would like to have one set of ignores/excludes
>> for g1 a different set, and for t5 pretty much dont care what gets
>> changed as it changes all the time.
>>
>> Is there a way to do this and can somebody point me to the right docs?
>> btw we are using the wazuh install.
>>
>> Thanks,
>> Sean
>>
> --
>
> ---
> 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.
>



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

Re: [ossec-list] Re: Windows agent doesn't synchronize agent.conf

[Victor Fernandez]

Hi all,

I think that the issue you referred is not the cause of this problem: it 
will write the merged.mg as a binary file but this shouldn't matter because 
OSSEC and Wazuh performs the shared file (merged.mg) MD5 as a text file, so 
the hash should match.

As I said before IMHO the issue affects to Windows and UNIX agents but it's 
more common in Windows because the default buffer is shorter. We had this 
problem with a Windows agent on a private VirtualBox network: the shared 
file didn't arrive. With debugging enabled, we saw the message:

ossec-agent: Failed md5 for: merged.mg -- deleting.


So we did this test: we modified the source code to prevent file from being 
deleted although it was corrupted, and compared the received file with the 
original one: some chunks of the file were indeed lost, it was not a line 
ending issue.

Shared file chunks may be lost due to the UDP protocol, as well as any 
other agent event or control message. In fact using TCP seems to be a good 
solution for this problem. We implemented TCP communication in Wazuh a year 
ago from version 1.1 and we reached some advantages:

   - No event losing. Communication is reliable for events, control 
   messages and Active response requests.
   - Agents detect that a manager is down immediately, so they are able to 
   "lock" the transmission in order to prevent events from being dropped.

Agents with TCP connection are working properly in many systems using 
Linux, Windows, OpenBSD, macOS, AIX, etc.

Best regards.

On Wednesday, August 2, 2017 at 10:00:33 PM UTC+2, dan (ddpbsd) wrote:
>
> On Wed, Aug 2, 2017 at 7:19 AM, Stephen Crow <stephe...@gmail.com 
> > wrote: 
> > can this be changed to use TCP instead of UDP? i have the same issue but 
> i 
> > dont think changing the default buffer size is a good idea 
> > 
>
> Yes, just add tcp support to agentd and remoted. 
> Wazuh may already have this, I'm not positive. 
>
> > On Monday, 10 July 2017 12:34:48 UTC+1, Victor Fernandez wrote: 
> >> 
> >> Hi Ricardo, 
> >> 
> >> in this case it's probable that the Windows agent is dropping UDP 
> packages 
> >> from the manager due to overflow. The default UDP buffer size in Linux 
> is 
> >> 212992 (208 KiB) but I think that in Windows it is only 8 KiB. OSSEC 
> resizes 
> >> the buffer to 6 KiB (the maximum message length) when the default size 
> is 
> >> less than 6 KiB. 
> >> 
> >> File ar.conf comes in the merged.mg. Try to send a very little shared 
> file 
> >> (remove every file in the manager's /var/ossec/etc/shared except 
> ar.conf), 
> >> restart the manager and then restart the agent. 
> >> 
> >> You may also try to increase the network buffer size in Windows. This 
> may 
> >> help you: http://smallvoid.com/article/winnt-winsock-buffer.html. 
> >> 
> >> Best regards. 
> >> 
> >> On Fri, Jul 7, 2017 at 10:08 AM, Ricardo Galossi <chacal...@gmail.com> 
> >> wrote: 
> >>> 
> >>> Hi Victor, 
> >>> 
> >>> Thanks for your reply. I did everything you told me, but the error 
> >>> persist. I continuous receiving many logs as below: 
> >>> 
> >>> ossec-agentd: Failed md5 for: shared/merged.mg -- deleting. 
> >>> 
> >>> A new thing that I realized is that the file ar.conf is not present in 
> >>> windows agent installation directory too, I tried to restart the agent 
> >>> remotely and saw it. After I enable debug on the windows agent I was 
> able to 
> >>> see this log: 
> >>> 
> >>> ossec-agent: DEBUG: Sending keep alive: #!-Microsoft Windows Server 
> 2012 
> >>> Datacenter Edition (full)  (Build 9200) - OSSEC HIDS v2.9.0 / 
> >>> e204e0200d4f36c5c80b071e2e1ef79b 
> >>> x merged.mg 
> >>> 
> >>> The point is, this checksum is not the same of agent.conf or merged.mg 
> on 
> >>> ossec server. I kinda gave up about this and tried to do everything 
> >>> manually, I created agent.conf in blank within C:\Program Files 
> >>> (x86)\ossec-agent\shared directory and restart the agent, in the log 
> file 
> >>> the error (ERROR: Error reading XML file 'shared/agent.conf': XMLERR: 
> File 
> >>> 'shared/agent.conf' not found) isn't being shown anymore, but the 
> agent.conf 
> >>> doesn't synchronize, it remains in blank. 
> >>> 
> >>> I don't know what to do anymore, reinstalled the agent and the server, 
> >>> tried in different windows installations and tried with ossec 2.8.3, 
> but the 
> >>>

Re: [ossec-list] ossec-agent buffer and/or cache configurations

[Victor Fernandez]

Hello Grant,

OSSEC tracks logs from the file end when it starts. I mean, when OSSEC
starts it opens every monitored file and jumps to the current file end.
>From that moment on it will report all new data arriving to the log.

If OSSEC detects that a log was rotated, it re-opens the file and tracks it
from the end. It saves no file-position data when it gets stopped, so if
new data is written into the log while OSSEC is stopped will be discarded.

Hope it help.
Kind regards.

On Wed, Jul 19, 2017 at 8:13 PM, Grant Leonard 
wrote:

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



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

Re: [ossec-list] syslog_output question

[Victor Fernandez]

Hi Robert,

OSSEC should take these settings independently:

   - Configuration A will send alerts with level 8 or higher.
   - Configuration B will send alerts with level 4 or higher (including
   alerts sent by the former setting) belonging to these groups.

So you'll receive duplicate alerts. One option would be to enter every
groups but the specified in the configuration B.

Let me tell you that Wazuh agents include an improvement that allow to
negate expressions. So you may use a setting like this one::


8
192.168.0.5
!invalid_login|adduser|blah|andsoon



4
invalid_login|adduser|blah|andsoon
192.168.0.5



Hence you'll have alerts with level 4 or higher (even 8 or more) belonging
to these groups, plus alerts with level 8 or higher of any other group.

Hope it help.
Best regards.


On Mon, Jul 10, 2017 at 10:29 PM, Robert B  wrote:

> This was a little unclear to me after reading the documenation and
> searching around...pardon if it's been asked and answered, I simply have
> not found it.
>
> We have a single server we want to send syslog output to, however, we also
> want to have different levels for some alerts.   Would it be as simple as
> two syslog_output sections, such as below, or would this create duplicate
> alerts, take the last syslog_output section, or can it be done in a single
> section?
>
> 
> 8
> 192.168.0.5
> 
>
> 
> 4
> invalid_login|adduser|blah|andsoon
> 192.168.0.5
> 
>
>
> Thanks!
> Bob
>
>
> --
>
> ---
> 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.
>



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

Re: [ossec-list] Re: Windows agent doesn't synchronize agent.conf

[Victor Fernandez]

Hi Ricardo,

in this case it's probable that the Windows agent is dropping UDP packages
from the manager due to overflow. The default UDP buffer size in Linux
is 212992 (208 KiB) but I think that in Windows it is only 8 KiB. OSSEC
resizes the buffer to 6 KiB (the maximum message length) when the default
size is less than 6 KiB.

File ar.conf comes in the merged.mg. Try to send a very little shared file
(remove every file in the manager's /var/ossec/etc/shared except ar.conf),
restart the manager and then restart the agent.

You may also try to increase the network buffer size in Windows. This may
help you: http://smallvoid.com/article/winnt-winsock-buffer.html.

Best regards.

On Fri, Jul 7, 2017 at 10:08 AM, Ricardo Galossi <chacalito2...@gmail.com>
wrote:

> Hi Victor,
>
> Thanks for your reply. I did everything you told me, but the error
> persist. I continuous receiving many logs as below:
>
> ossec-agentd: Failed md5 for: shared/merged.mg -- deleting.
>
> A new thing that I realized is that the file ar.conf is not present in
> windows agent installation directory too, I tried to restart the agent
> remotely and saw it. After I enable debug on the windows agent I was able
> to see this log:
>
> ossec-agent: DEBUG: Sending keep alive: #!-Microsoft Windows Server 2012
> Datacenter Edition (full)  (Build 9200) - OSSEC HIDS v2.9.0 /
> e204e0200d4f36c5c80b071e2e1ef79b
> x merged.mg
>
> The point is, this checksum is not the same of agent.conf or merged.mg on
> ossec server. I kinda gave up about this and tried to do everything
> manually, I created agent.conf in blank within C:\Program Files
> (x86)\ossec-agent\shared directory and restart the agent, in the log file
> the error (ERROR: Error reading XML file 'shared/agent.conf': XMLERR: File
> 'shared/agent.conf' not found) isn't being shown anymore, but the
> agent.conf doesn't synchronize, it remains in blank.
>
> I don't know what to do anymore, reinstalled the agent and the server,
> tried in different windows installations and tried with ossec 2.8.3, but
> the problem remains. The funny point is that it only happens on Windows
> agents, on Linux agents everything works perfectly.
>
> If I copy the content of agent.conf from the server to the windows agent,
> everything works. But I don't know if it can bring me some problem in the
> future.
>
> Em segunda-feira, 3 de julho de 2017 11:39:52 UTC-3, Victor Fernandez
> escreveu:
>>
>> Hi,
>>
>> it is strange that the log indicates line 147 when it was not able to
>> read it. Maybe the agent.conf file is not arriving to the agent or it is
>> being discarded due to a checksum error.
>>
>> First, please remove file *merged.mg <http://merged.mg>* from folder
>> *shared* in the agent and the manager. Then enable debugging log in
>> order to know where the problem is.
>>
>>- On the manager:
>>
>> /var/ossec/bin/ossec-control enable debug
>> /var/ossec/bin/ossec-control restart
>>
>>
>>
>>- On the agent, add this line to file *local_internal_options.conf*:
>>
>> windows.debug=1
>>
>>
>> and restart the agent. When it gets connected, the manager should log a
>> message like:
>>
>> ossec-remoted: Sending file 'merged.mg' to agent.
>>
>>
>> and that file should appear immediately in the agent (folder *shared*).
>> After few seconds, when the file is completely delivered, it should be
>> unmerged into every file that exists in the manager's shared folder.
>>
>> A common issue is that the file doesn't arrive properly (e.g. some
>> packets were lost or corrupted) the file *merged.mg <http://merged.mg>* will
>> disappear suddenly and the Windows agent should log:
>>
>> ossec-agent: Failed md5 for: merged.mg -- deleting.
>>
>>
>> In this case, the manager will retry to send the file every 10 minutes.
>>
>> But as I mentioned before, an error message about reading file that
>> indicates a line different from 0 has no sense. However I hope this help
>> you.
>>
>> Best regards.
>>
>>
>>
>> On Mon, Jul 3, 2017 at 11:44 AM, Jesus Linares <je...@wazuh.com> wrote:
>>
>>> Hi
>>>
>>> ossec-agent(1226): ERROR: Error reading XML file 'shared/agent.conf':
>>>> XMLERR: File 'shared/agent.conf' not found. (line 147).
>>>
>>>
>>> what is in the line 147?.
>>>
>>> More information about the agent.conf and the process to synchronize it:
>>> https://documentation.wazuh.com/current/user-manual/referenc
>>> e/centralized-configuration.html
>>>
>>> I hope it helps.
>>>

[ossec-list] Re: makefile compile g++: error: server.o: No such file or directory

[Victor Fernandez]

Hi,

try:

$(CC) server.cpp config.h $(CFLAGS) -c -o $@ $< -I./$(INCLUDE_PATH)


instead of:

 
$(CC) server.cpp config.h $(CFLAGS) -c $@ -I./$(INCLUDE_PATH)


Option -c tells the compiler that it shouldn't compile, but you have to use 
"-o" in order to specify the output. $@=server.o. Then use $< to enter the 
first dependency (server.cpp).

I hope this help.
BTW, is this related to OSSEC project?

Best regards.


On Friday, July 7, 2017 at 6:06:05 PM UTC+2, jackfruit1...@gmail.com wrote:
>
> I'am a rookie in makefile.this is the problem I have.It has been boring me 
> for a day.please give me some advice.
>
> this is my makefile
>
> CC = g++
> LINK = g++
> CFLAGS = -Wall
>
> INCLUDE_PATH = install/include
> LIB_PATH = install/lib
> LIBS = -lboost_thread -lboost_system -Llib #-ljsoncpp
>
> SRC_DIR = .
> VPATH = $(SRC_DIR)
> VPATH += $(SRC_DIR)/install/include
> VPATH += $(SRC_DIR)/install/include/libavcodec
> VPATH += $(SRC_DIR)/install/include/libavutil
> VPATH += $(SRC_DIR)/install/include/libavformat
> VPATH += $(SRC_DIR)/install/lib
>
> #object_server = server.o
>
> #server:$(object_server)
> # $(LINK) $(object_server) -o $@ -I./$(LIB_PATH)
>
> server.o:server.cpp config.h #$(INCLUDE_PATH)
> $(CC) server.cpp config.h $(CFLAGS) -c $@ -I./$(INCLUDE_PATH)
>
> clean:
> rm server.o server
>
>
> when I compile,this error occurs,"g++: error: server.o: No such file or 
> directory"
> I have got a halo.
>
>
>

-- 

--- 
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 agent doesn't synchronize agent.conf

[Victor Fernandez]

Hi,

it is strange that the log indicates line 147 when it was not able to read
it. Maybe the agent.conf file is not arriving to the agent or it is being
discarded due to a checksum error.

First, please remove file *merged.mg * from folder
*shared* in the agent and the manager. Then enable debugging log in order
to know where the problem is.

   - On the manager:

/var/ossec/bin/ossec-control enable debug
/var/ossec/bin/ossec-control restart



   - On the agent, add this line to file *local_internal_options.conf*:

windows.debug=1


and restart the agent. When it gets connected, the manager should log a
message like:

ossec-remoted: Sending file 'merged.mg' to agent.


and that file should appear immediately in the agent (folder *shared*).
After few seconds, when the file is completely delivered, it should be
unmerged into every file that exists in the manager's shared folder.

A common issue is that the file doesn't arrive properly (e.g. some packets
were lost or corrupted) the file *merged.mg * will
disappear suddenly and the Windows agent should log:

ossec-agent: Failed md5 for: merged.mg -- deleting.


In this case, the manager will retry to send the file every 10 minutes.

But as I mentioned before, an error message about reading file that
indicates a line different from 0 has no sense. However I hope this help
you.

Best regards.



On Mon, Jul 3, 2017 at 11:44 AM, Jesus Linares  wrote:

> Hi
>
> ossec-agent(1226): ERROR: Error reading XML file 'shared/agent.conf':
>> XMLERR: File 'shared/agent.conf' not found. (line 147).
>
>
> what is in the line 147?.
>
> More information about the agent.conf and the process to synchronize it:
> https://documentation.wazuh.com/current/user-manual/reference/centralized-
> configuration.html
>
> I hope it helps.
> Regards.
>
> On Sunday, July 2, 2017 at 3:30:07 AM UTC+2, Ricardo Galossi wrote:
>>
>> Hi guys,
>>
>> I'd like to ask for some help here..
>>
>> My windows agents are not synchronizing shared/agent.conf,
>> within C:\Program Files (x86)\ossec-agent\shared direrectory there is no
>> agent.conf even after restarting windows agent. Follow my agent.cong below:
>>
>> 
>> 
>> C:\labtest> rectories>
>> 
>> 
>>
>> In the agent log file I receive the following message:
>>
>> ossec-agent(1226): ERROR: Error reading XML file 'shared/agent.conf':
>> XMLERR: File 'shared/agent.conf' not found. (line 147).
>>
>> If I create the file agent.conf manually the configuration works (what
>> proof that the configuration is ok), but also doesn't synchronize if i try
>> to change it.
>>
>> Am I making some mistake? Please, help me!!
>>
> --
>
> ---
> 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.
>



-- 
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] Re: Rule on server only for specific agents

[Victor Fernandez]

Hi Tom,

there is a rule option, , that should work for you.

Alerts start this way:

** Alert 1488922301.778562: mail  - ossec,syscheck,pci_dss_11.5,
2017 Mar 07 13:31:41 (myagent) 192.168.66.1->syscheck

 
The text in red is the agent hostname, it has form "(name) IP". Another 
instance may be "(myagent) any", when the agent was registered using 
IP="any".

So if you want to create a rule that only applies to an agent called 
"myagent" you may use a rule such this one:

<*rule* id="11" level="3">

<*hostname*>^(myagent)




Hope it help.

Best regards,
Victor.

On Friday, June 2, 2017 at 4:40:29 PM UTC+2, Tom Lobato wrote:
>
> Is it possible specify in which agents you want certain rule enabled?
>

-- 

--- 
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: OSSEC Agent not works

[Victor Fernandez]

Hi,

have you more than one network interface on your manager? I see your tcpdump
log a bit unusual:

00:58:11.619862 IP 10.2.2.3.43453 > *10.2.2.12*.fujitsu-dtcns: UDP, length
73
00:58:11.620415 IP *10.2.2.13*.fujitsu-dtcns > 10.2.2.3.43453: UDP, length
73


It seems that the manager is responding (probably an ACK message) but it is
doing it from a different IP (10.2.2.13 instead of 10.2.2.12).

Do you see any error at /var/ossec/log/ossec.log at the agent?

Best regards.

On Sat, Apr 15, 2017 at 11:59 PM, Kat  wrote:

> It really sounds like you are missing a step -- perhaps post the steps you
> do for the install, adding an agent etc, showing the commands and results.
> We need something more to help you.
>
> Kat
>
>
> On Thursday, April 13, 2017 at 5:24:32 PM UTC-5, Руслан Аминджанов wrote:
>>
>> Hello!
>> I installed OSSEC server and client on 2 hosts whoever agent showed as
>> "Never connected". There is no firewall between these hosts and if I use
>> netcat to connect to server It log shows that message is not properly
>> formated.
>> Output of tcpdump:
>>
>> 00:58:11.619862 IP 10.2.2.3.43453 > 10.2.2.12.fujitsu-dtcns: UDP, length
>> 73
>>
>> 00:58:11.620415 IP 10.2.2.13.fujitsu-dtcns > 10.2.2.3.43453: UDP, length
>> 73
>>
>> 00:58:15.620201 IP 10.2.2.3.43453 > 10.2.2.12.fujitsu-dtcns: UDP, length
>> 73
>>
>> 00:58:15.620618 IP 10.2.2.13.fujitsu-dtcns > 10.2.2.3.43453: UDP, length
>> 73
>>
>> 00:58:20.620619 IP 10.2.2.3.43453 > 10.2.2.12.fujitsu-dtcns: UDP, length
>> 73
>>
>> 00:58:20.621167 IP 10.2.2.13.fujitsu-dtcns > 10.2.2.3.43453: UDP, length
>> 73
>>
>> 00:58:26.621162 IP 10.2.2.3.43453 > 10.2.2.12.fujitsu-dtcns: UDP, length
>> 73
>>
>> 00:58:26.621703 IP 10.2.2.13.fujitsu-dtcns > 10.2.2.3.43453: UDP, length
>> 73
>>
> --
>
> ---
> 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.
>



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

Re: [ossec-list] Redundancy manager (backup)

[Victor Fernandez]

Hi Martin,

I'm glad to know that everything is OK.

Your firewall configuration for the manager is good, filtering by source IP
is fine.

However the configuration for the agent should filter by source port,
because we do not know which port the agent communicates from.

I mean, the agent does not actually listen to port 1514, it communicates
with manager's port 1514 (it really creates an ephemeral port to establish
the communication). For example:

Agent (10.0.1.100:49152) → Manager (10.0.0.1:1514)


The communication protocol is UDP, it is not connection-oriented (like
TCP), but network routers often create a NAT mapping that makes possible to
send a message in reverse direction:

Manager (10.0.0.1:1514) → Agent (10.0.1.100:49152)


This is why the agent's firewall configuration should filter packets by
source port (1514) and not destination port (e.g. 49152) since this is an
ephemeral port. So I propose this configuration:

   - sudo iptables -D INPUT -j DROP
   - iptables -A INPUT -p UDP --sport 1514 -s 10.0.0.1 -j ACCEPT
   - iptables -A INPUT -p UDP --sport 1514 -s 10.0.0.2 -j ACCEPT
   - iptables -A OUTPUT -j ACCEPT
   - sudo iptables -A INPUT -j DROP

Best regards.

On Tue, Apr 11, 2017 at 5:11 PM, Martin  wrote:

> Hello,
>
> Thank you for your answers !
>
> This is finaly working, what I had to do was to allow the traffic through
> 1514 with the following ;
>
> *On the agent :*
>
>
>- sudo iptables -D INPUT -j DROP
>- iptables -A INPUT -p UDP --dport 1514 -s 10.0.0.1 -j ACCEPT
>- iptables -A INPUT -p UDP --dport 1514 -s 10.0.0.2 -j ACCEPT
>- iptables -A OUTPUT -j ACCEPT
>- sudo iptables -A INPUT -j DROP
>
> *On the manager :*
>
>
>- sudo iptables -D INPUT -j DROP
>- iptables -A INPUT -p UDP --dport 1514 -s IP_agent_1 -j ACCEPT
>- iptables -A INPUT -p UDP --dport 1514 -s IP_agent_2 -j ACCEPT
>- iptables -A INPUT -p UDP --dport 1514 -s IP_agent_3 -j ACCEPT
>- iptables -A OUTPUT -j ACCEPT
>- sudo iptables -A INPUT -j DROP
>
> I don't think that this is the right way to do it, but it works now..
>
> Best regards.
>
> --
>
> ---
> 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.
>



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

Re: [ossec-list] Redundancy manager (backup)

[Victor Fernandez]

Hi Martin,

please give us a clue: do you see any issue at the logs?

For example, when the agent switches to other server you should see logs
such:

ossec-agentd: INFO: Closing connection to server (10.0.0.1:1514).
ossec-agentd: INFO: Trying to connect to server (10.0.0.2:1514).


If the agent gives up:

ossec-agentd: ERROR: Unable to connect to any server.


If there is an issue with the agent key, the manager log may print:

ossec-remoted(1403): ERROR: Incorrectly formated message from '10.0.0.X'.
  (or)
ossec-remoted(1408): ERROR: Invalid ID %s for the source ip: '10.0.0.X'.
  (or)
ossec-remoted(1213): WARN: Message from '10.0.0.X' not allowed.


On the other hand, if any of the peers (agent or manager) rejects a remote
ID (Rid):

ossec-remoted(1407): ERROR: Duplicated counter for '10.0.0.1'.


Only for testing purposes, you may use this configuration at agent, it will
speed up the connection switching:

 10.0.0.1 10.0.0.2  5 <
time-reconnect>15 


And you may also disable Rid verification by adding this line to file
/var/ossec/etc/local_internal_options.conf (manager and agent):

remoted.verify_msg_id=0


Please look for any suspicious log, try to use these configurations and
write back to us.

Best regards.


On Mon, Apr 10, 2017 at 4:57 PM, Martin  wrote:

> Even after 1 hour my agents won't connect to the second manager.
>
> Here are the step that i've done so far;
>
>- Having my two managers with the same ossec.conf, local_decoder,
>local_rules, client, client.keys
>- Opening the port 1514 on all the agents and the manager.
>- Specify the manager's ip on the agents
>
>   
> 10.0.0.1 10.0.0.2 
>
> Maybe it has to do with what Viktor said about Rids counter, i'm not sure.
>
> Best regards.
>
> --
>
> ---
> 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.
>



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

Re: [ossec-list] OSSEC fails to start after install from RPM on RHEL7

[Victor Fernandez]

Hi Felix,

I followed your steps and got the same result. Maybe the OSSEC log could
help us:

root@centos ~]# tail /var/ossec/logs/ossec.log
2017/04/07 00:59:35 ossec-testrule: INFO: Reading local decoder file.
2017/04/07 00:59:35 ossec-testrule: INFO: Started (pid: 2303).
2017/04/07 00:59:50 ossec-maild(1501): ERROR: Invalid SMTP Server:
smtp.example.com.
2017/04/07 00:59:50 ossec-maild(1202): ERROR: Configuration error at
'/var/ossec/etc/ossec.conf'. Exiting.
2017/04/07 00:59:50 ossec-maild(1202): ERROR: Configuration error at
'/var/ossec/etc/ossec.conf'. Exiting.


I think that the problem is that email notifications are enabled but no
valid SMTP server is configured, so if you get the same error edit file
"/var/ossec/etc/ossec.conf" and try to configure the email settings, or
disable email notifications if you won't use them:


  *no*
  daniel@example.com
  smtp.example.com.
  oss...@ossec.example.com.



Then try to start OSSEC again:

[root@centos ~]# systemctl start ossec-hids

[root@centos ~]# systemctl status ossec-hids

*●* ossec-hids.service - SYSV: OSSEC-HIDS is an Open Source Host-based
Intrusion Detection System.

   Loaded: loaded (/etc/rc.d/init.d/ossec-hids; bad; vendor preset:
disabled)

   Active: *active (running)* since Fri 2017-04-07 01:03:08 PDT; 6s ago

 Docs: man:systemd-sysv-generator(8)

  Process: 2386 ExecStart=/etc/rc.d/init.d/ossec-hids start (code=exited,
status=0/SUCCESS)

   CGroup: /system.slice/ossec-hids.service

   ├─2414 /var/ossec/bin/ossec-execd

   ├─2418 /var/ossec/bin/ossec-analysisd

   ├─2422 /var/ossec/bin/ossec-logcollector

   ├─2433 /var/ossec/bin/ossec-syscheckd

   └─2437 /var/ossec/bin/ossec-monitord


Hope it help.

Best regards.


On Fri, Apr 7, 2017 at 4:12 AM, Felix Martel  wrote:

> Hello,
>
> Not finding any useful information regarding my problems anywhere. I'm new
> to OSSEC HIDS. I played around a little bit with an appliance version, but
> now want to install it on a DevOps host.
>
> I just did a fresh install of OSSEC HIDS from the atomicorp repo. Install
> seemed to go normally, although none of the usual installation questions
> were asked with respect to the questions asked by /install.sh in the manual
> (ie installation type, e-mail address, notifications, different engines,
> etc.). Haven't found any instructions on how to do those configuration
> steps post-install either.
>
> Anyways, I installed using the command
>
> yum install ossec-hids ossec-hids-server
>
>
> Everything seemed normal. No error messages during the installation.
>
> After the installation, I attempted to start OSSEC-HIDS with the command
>
> /etc/init.d/ossec-hids start
>
> At this point I got an error "Command not found".
>
> I rebooted the server and was then able to run the command. At this point
> I got the following errors:
>
> Starting ossec-hids (via systemctl):  Job for ossec-hids.service failed
> because the control process exited with error code. See "systemctl status
> ossec-hids.service" and "journalctl -xe" for details.
>[FAILED]
>
>
> I then ran journalctl -xe and gotr the following output:
>
> -- Unit ossec-hids.service has begun starting up.
> Apr 06 21:35:48 RHEL7HOST realmd[1698]: quitting realmd service after
> timeout
> Apr 06 21:35:48 RHEL7HOST realmd[1698]: stopping service
> Apr 06 21:36:01 RHEL7HOST ossec-hids[2382]: Starting ossec-hids: [FAILED]
> Apr 06 21:36:01 RHEL7HOST systemd[1]: ossec-hids.service: control process
> exited, code=exited status=1
> Apr 06 21:36:01 RHEL7HOST systemd[1]: Failed to start SYSV: OSSEC-HIDS is
> an Open Source Host-based Intrusion Detection System..
> -- Subject: Unit ossec-hids.service has failed
> -- Defined-By: systemd
> -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
> --
> -- Unit ossec-hids.service has failed.
> --
> -- The result is failed.
> Apr 06 21:36:01 RHEL7HOST systemd[1]: Unit ossec-hids.service entered
> failed state.
> Apr 06 21:36:01 RHEL7HOST systemd[1]: ossec-hids.service failed.
>
> I'm stumped. What I find really curious is the fact that realmd seems to
> stop (and immediately restarts after the failed start). Any help
> appreciated.
>
>
>
>
>
>
>
> --
>
> ---
> 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.
>



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

Re: [ossec-list] Redundancy manager (backup)

[Victor Fernandez]

Sorry I forgot to mention Chef, you can definitely use it to deploy your
agents.

If you are interested on it, take a look at:
https://github.com/sous-chefs/ossec.

Best regards.

On Tue, Apr 4, 2017 at 2:55 PM, Martin  wrote:

> Is it possible to deploy them (agents) easily via chef ?
>
> THank you again for your answers!
>
> Best regards.
>
> --
>
> ---
> 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.
>



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

Re: [ossec-list] Redundancy manager (backup)

[Victor Fernandez]

Hi Martin,

there are actually some options to deploy agents, you can use Puppet or
Ansible to make a large deployment. A very simple unattended installation
could be installing the agent with preloaded variables. You can find file
etc/preloaded-vars.conf at the source code, fill it (uncomment and set the
options) and launch the install.sh. With a proper filled preloaded-vars.conf,
it will make an unattended installation.

The next step is adding the agent to the manager, you may use the Auth
system (ossec-authd server on manager and agent-auth on agents) to register
automatically agents.

There are some approaches to get a high availability system, the most
important task is to ensure that file /var/ossec/etc/client.keys is always
synchronized between every manager in your system. If you have Rids
counters enabled (OSSEC has them enabled by default) you should make the
same with file /var/ossec/queue/rids/sender_counter, that stores the
message counter (it does this to numerate each message and avoid some
security threats like replay attacks).  There is no an unique way to
achieve high availability, it depends on your system (how many managers you
have, whether they are parallel or there is a main manager and a backup
server, whether you will use shared storage, etc).

Best regards.

On Tue, Apr 4, 2017 at 10:32 AM, Martin  wrote:

> I know it is possible with "Unattended Source Installation" but i'd still
> have to add manually these agents on the manager or is there another way :)
> ?
>
> --
>
> ---
> 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.
>



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

Re: [ossec-list] Redundancy manager (backup)

[Victor Fernandez]

Hi Martin,

when agents connect to manager, the latter sends an ACK message to confirm
that the connection is established. From that moment on, agents send data
with no arrival confirmation. This means that, if the server went down,
agents would keep sending data, that will be lost.

There is a mechanism to test connections: every 10 minutes agents send
keep-alive messages to the manager, and the server responds with an ACK
message. If an agent does not send a keep-alive in 30 minutes, the manager
marks it as disconnected and produces an alert.

On the other hand, if the manager does not answer 3 keep-alive messages in
a row, the agent considers that the server is down and tries to reconnect,
in the meanwhile it "locks" every component (File Integrity Monitoring, Log
collecting, etc.) in order to prevent them from sending data that would be
lost.

You may use a secondary manager and configure two remote servers, with a
configuration such this:

 10.0.0.1 10.0.0.2 


The agent will always try to connect first to the first defined server. In
case that it could not connect to it, it will try do to it with the next
one. You can define as many servers as you want.

Best regards.


On Mon, Apr 3, 2017 at 6:47 PM, Martin  wrote:

> Hello everyone,
>
> I was wondering, what happen if the "manager" bug / shutdown ?
>
> It might sounds stupid but what behavior will the agents have ? Will they
> make my server bug, consume too much cpu/ram or trying to send message all
> the time etc ?
>
> Is there a way to have a second manager as a backup or make redundancy ?
>
> Best regards !
>
> --
>
> ---
> 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.
>



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

Re: [ossec-list] install ossec - bind to port 1514 fail | getaddrinfo: name or service not know

[Victor Fernandez]

Sorry Eduardo, maybe the method that I told you (enabling on the fly) does
not work properly.

If followed those steps to disable IPv6, better undo what you did to
disable it.

I have done it by editing file "/etc/sysctl.conf" and adding (to disable)
or removing (to enable back) these lines:

net.ipv6.conf.all.disable_ipv6 = 1

net.ipv6.conf.default.disable_ipv6 = 1


You probably used this method to disable IPv6, so please try to remove (or
comment) those lines, reboot your system and start OSSEC again.

Best regards.

On Wed, Mar 29, 2017 at 3:30 PM, Eduardo Reichert Figueiredo <
eduardo.reich...@hotmail.com> wrote:

> Hi Victor,
> i validated and ipv6 feature is enable in my redhat 7.3, but ossec remoted
> continue is same error reported above.
>
> The file of installation is same that used in other installations
> (rhel6.8).
>
> Em quinta-feira, 23 de março de 2017 15:37:50 UTC-3, Victor Fernandez
> escreveu:
>>
>> Hi Eduardo,
>>
>> I agree with Dan, I tested OSSEC v2.9 on a clean CentOS 7 with your
>>  configuration and it worked. But when I disabled IPv6 I got the
>> same errors you have.
>>
>> Please try to enable IPv6 on the running system with:
>>
>> sysctl -w net.ipv6.conf.all.disable_ipv6=1
>> sysctl -w net.ipv6.conf.default.disable_ipv6=1
>>
>>
>> And try to start OSSEC. If it works, consider enabling IPv6 permanently
>> by editing file */etc/sysctl.conf*.
>>
>> Hope it help. If I find another way to run OSSEC with IPv6 disabled I
>> will let you know.
>>
>> Best regards.
>>
>> On Thu, Mar 23, 2017 at 11:19 AM, dan (ddp) <ddp...@gmail.com> wrote:
>>
>>> On Thu, Mar 23, 2017 at 1:08 PM, Eduardo Reichert Figueiredo
>>> <eduardo@hotmail.com> wrote:
>>> > Hi dan, i dont have ipv6 enabled in my system linux, so i dont have
>>> inet6 in
>>> > my ifconfig configurations, only ipv4.
>>> >
>>> > This can caused for the problem?
>>> >
>>>
>>> I think having ipv6 support is necessary now. You don't need to have
>>> addresses or anything, but the facilities need to be available.
>>>
>>> > Em quarta-feira, 22 de março de 2017 20:30:08 UTC-3, dan (ddpbsd)
>>> escreveu:
>>> >>
>>> >> On Tue, Mar 21, 2017 at 10:46 AM, Eduardo Reichert Figueiredo
>>> >> <eduardo@hotmail.com> wrote:
>>> >> > When i install ossec 2.9.0 on rhel 7.3 (no ipv6 feature and
>>> address) i
>>> >> > have
>>> >>
>>> >> Is IPv6 totally disabled for your system (support for IPv6 was
>>> removed)?
>>> >>
>>> >> > a problem to ossec-remoted and ossec-auth, this services cant bind
>>> ports
>>> >> > 1514, log error below.
>>> >> > I generated my certificated with commands "openssl genrsa -out" and
>>> >> > "openssl
>>> >> > req -new -x509 -key ".
>>> >> >
>>> >> > ##Log OSSEC.LOG
>>> >> > 2017/03/21 11:34:34 ossec-remoted: DEBUG: Forking remoted: '0'.
>>> >> > 2017/03/21 11:34:34 ossec-remoted: Remote syslog allowed from:
>>> >> > '0.0.0.0/0'
>>> >> > 2017/03/21 11:34:34 ossec-remoted: DEBUG: Forking remoted: '1'.
>>> >> > 2017/03/21 11:34:34 getaddrinfo: Name or service not known
>>> >> > 2017/03/21 11:34:34 getaddrinfo: Name or service not known
>>> >> > 2017/03/21 11:34:34 ossec-remoted(1206): ERROR: Unable to Bind port
>>> >> > '1514'
>>> >> > 2017/03/21 11:34:34 ossec-remoted(1206): ERROR: Unable to Bind port
>>> >> > '514'
>>> >> > 2017/03/21 11:34:41 ossec-syscheckd: INFO: Starting syscheck scan
>>> >> > (forwarding database).
>>> >> > 2017/03/21 11:34:41 ossec-syscheckd: INFO: Starting syscheck
>>> database
>>> >> > (pre-scan).
>>> >> > 2017/03/21 11:35:47 ossec-authd: DEBUG: Starting ...
>>> >> > 2017/03/21 11:35:47 ossec-authd: INFO: Started (pid: 24420).
>>> >> > 2017/03/21 11:35:47 ossec-authd: DEBUG: Returning CTX for server.
>>> >> > 2017/03/21 11:35:47 getaddrinfo: Name or service not known
>>> >> > 2017/03/21 11:35:47 ossec-authd: Unable to bind to port 1514
>>> >> >
>>> >> > in other cases for unable to bind port 1514, my error was my
>>> >> > client.keys,
>>> &g

Re: [ossec-list] Re: %AppData% alert on new file creation proper setup

[Victor Fernandez]

Hi,

I tested that configuration at Windows agent's ossec.conf:

 300 
C:\Users/Administrator/AppData/Local/Temp 


And I added this new rule on manager's local_fules.xml:

  554 <
regex>C:\\Users/\S+/AppData/Local/Temp File added to
the system at Temp directory. syscheck,pci_dss_11.5,  


This rule works with temporary files for any user. Unfortunately it seems
that wildcards (C:\Users/*/AppData/Local/Temp) do not work on Windows
agents, so you should add a  entry for each user.

Note that new files are not reported on the first scan, so wait for this
message at agent's ossec.log:

2017/03/29 11:44:32 ossec-syscheckd: INFO: Ending syscheck scan (forwarding
database).


Now add any file to the Temp directory. When next scan is performed, an
alert like this one should appear in the manager:

** Alert 1490788534.45426831: - ossec,syscheck,pci_dss_11.5,
2017 Mar 29 04:55:34 (windows-agent) 10.1.2.3->syscheck
Rule: 100554 (level 10) -> 'File added to the system at Temp directory.'
New file 'C:\Users/Administrator/AppData/Local/Temp/Test Document.txt'
added to the file system.
File: C:\Users/Administrator/AppData/Local/Temp/Test Document.txt
New size: 0
New permissions: 100666
New user: Administrators (0)
New group:  (0)
New MD5: d41d8cd98f00b204e9800998ecf8427e
New SHA1: da39a3ee5e6b4b0d3255bfef95601890afd80709


Hope it help.

Best regards.



On Tue, Mar 28, 2017 at 4:01 AM, dan (ddp)  wrote:

> On Mon, Mar 27, 2017 at 4:26 AM,   wrote:
> > Hello Dan,
> >
> > Thank you for your feedback. I have changed the frequency to 900
> > sec, and inspected the ossec.log. I noted that inside the log file none
> of
> > the agent.conf directories where present. Any theories on why the
> ossec.conf
> > syscheck content is showing up in ossec.log, and the agent.conf syscheck
> is
> > not?
> >
>
> Can OSSEC read the agent.conf (permissions)?
> Is the updated agent.conf transferred to the agent (you can open the
> file in a text editor to check)?
> Other than that, no real idea.
>
> > cheers,
> > Henry
> >
> > On Saturday, March 25, 2017 at 6:50:03 AM UTC-6, henry.wil...@gmail.com
> > wrote:
> >>
> >> Hello fellow googlers,
> >>
> >>
> >> The GOAL:
> >>
> >> For every user on my windows OSSEC agent, generate OSSEC alert severity
> 10
> >> when new file added to
> >>
> >> C:\Users/*/%AppData%/Local/Temp directory
> >>
> >> Where star was supposed to be the wildcard place holder to instruct
> OSSEC
> >> to mean ANY user
> >>
> >>
> >>
> >> The Attempt & RESULTS:
> >>
> >>
> >> In an effort to get OSSEC to generate an alert upon new file created in
> >> %AppData% I have conducted the following steps.
> >>
> >>
> >> http://ossec-docs.readthedocs.io/en/latest/faq/syscheck.
> html#why-aren-t-new-files-creating-an-alert
> >>
> >> Why aren’t new files creating an alert?
> >>
> >> By default OSSEC does not alert on new files. To enable this
> >> functionality,  must be set to yes inside the
> 
> >> section of the manager’s ossec.conf. Also, the rule to alert on new
> files
> >> (rule 554) is set to level 0 by default. The alert level will need to be
> >> raised in order to see the alert. Alerting on new files does not work in
> >> realtime, a full scan will be necessary to detect them.
> >>
> >> Add the following to local_rules.xml:
> >>
> >> 
> >>
> >>   ossec
> >>
> >>   syscheck_new_entry
> >>
> >>   File added to the system.
> >>
> >>   syscheck,
> >>
> >> 
> >>
> >> The  entry should look something like this:
> >>
> >> 
> >>
> >>   7200
> >>
> >>   yes
> >>
> >>   /etc,/bin,/sbin
> >>
> >> 
> >>
> >>
> >>
> >> In my OSSEC environment, I have a CENTos (current build) host for my
> OSSEC
> >> manager. I also have windows OS host for my OSSEC agent (agent id=001).
> To
> >> test the agent.conf setup of OSSEC I have on the OSSEC Manger host two
> >> configuration files, both the original ossec.conf file located @
> directory
> >> var/ossec/etc/ as well as the agent.conf file located @ directory
> >> var/ossec/etc/shared. I have made the  entry in both
> these
> >> configuration files. As well as add rule id 554 to local_rules.xml as
> >> depicted above from OSSEC documentation.
> >>
> >>
> >> To confirm settings are correct I ran logtest without error.
> Additionally,
> >> I preformed the following self-checks:
> >>
> >>
> >> Confirmed level=”10” for rule id 554 in local_rules.xml AND
> >> On OSSEC Manager inside the ossec.conf file that setting for alert
> >> threshold was set to alert on level>=1
> >> Md5sum on Manager = on Agent copy of agent.conf
> >> Reduced frequency to 60 for troubleshooting/testing create new file
> >> feature.
> >> create new file in directory %AppData%  ‘test.txt’
> >>
> >> No immediate result, additionally let sit and wait for 24hrs to ensure
> >> syscheck could run multiple times.
> >> Result new file ‘test.txt’ was not alerted on.
> >>
> >> To arrive at this conclusion, I inspected the following results:
> >>
> >> nano 

Re: [ossec-list] Custom decoder & rule not working

[Victor Fernandez]

Hi Martin,

the problem is that this log also matches with rule 2501 (from Syslog) that
has level 5. Since your rule 100201 has level 1 OSSEC discards it in favor
of rule 2501.

So increasing the level to 6 it should work:

 app.ERROR Multiple login attempts bepark.eu/fr/connexion   100201
  Multiple login attempts
bepark.eu/fr/connexion authentication_failures,



Hope it help.

Best regards.


On Thu, Mar 23, 2017 at 9:37 AM, Martin  wrote:

> Hello,
>
> I've those kind of log comming from a custom app
>
>>
>> [2017-03-23 10:18:01] app.ERROR: Authentication failure for IP:
>> 172.17.0.1 [] []
>
>
> I'm trying to block an ip with to much authentication failure.
>
> So I did a custom decoder which is working ;
>
> 
>   ^\p\d\d\d\d-\d\d-\d\d \d\d:\d\d:\d\d\p 
> 
>
>
> 
>   app.ERROR
>   ^app.ERROR: \.+ (\S+) for IP: (\S+)
> (\.+)\s(\.+)$
>   status,srcip,extra_data,extra_data
> 
>
> and I want theses rules working with this log .
>
> 
> app.ERROR
> Multiple login attempts bepark.eu/fr/connexion description>
>   
>
>
>   
> 100201
> 
> Multiple login attempts bepark.eu/fr/connexion description>
> authentication_failures,
>   
>
>
> But this what I get when testing with */var/ossec/bin/ossec-logtest*
>
>
>
> [2017-03-23 10:18:01] app.ERROR: Authentication failure for IP: 172.17.0.1
> [] []
>
>
>
>
> **Phase 1: Completed pre-decoding.
>full event: '[2017-03-23 10:18:01] app.ERROR: Authentication
> failure for IP: 172.17.0.1 [] []'
>hostname: 'Digital-Ocean-1'
>program_name: '(null)'
>log: '[2017-03-23 10:18:01] app.ERROR: Authentication failure for
> IP: 172.17.0.1 [] []'
>
>
> **Phase 2: Completed decoding.
>decoder: 'app.ERROR'
>status: 'failure'
>srcip: '172.17.0.1'
>extra_data: '[]'
>extra_data: '[]'
>
>
> **Phase 3: Completed filtering (rules).
>Rule id: '2501'
>Level: '5'
>Description: 'User authentication failure.'
> **Alert to be generated.
>
> why are my rules not working over the 2501 one ?
>
> --
>
> ---
> 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.
>



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

Re: [ossec-list] install ossec - bind to port 1514 fail | getaddrinfo: name or service not know

[Victor Fernandez]

Hi Eduardo,

I agree with Dan, I tested OSSEC v2.9 on a clean CentOS 7 with your
 configuration and it worked. But when I disabled IPv6 I got the
same errors you have.

Please try to enable IPv6 on the running system with:

sysctl -w net.ipv6.conf.all.disable_ipv6=1
sysctl -w net.ipv6.conf.default.disable_ipv6=1


And try to start OSSEC. If it works, consider enabling IPv6 permanently by
editing file */etc/sysctl.conf*.

Hope it help. If I find another way to run OSSEC with IPv6 disabled I will
let you know.

Best regards.

On Thu, Mar 23, 2017 at 11:19 AM, dan (ddp)  wrote:

> On Thu, Mar 23, 2017 at 1:08 PM, Eduardo Reichert Figueiredo
>  wrote:
> > Hi dan, i dont have ipv6 enabled in my system linux, so i dont have
> inet6 in
> > my ifconfig configurations, only ipv4.
> >
> > This can caused for the problem?
> >
>
> I think having ipv6 support is necessary now. You don't need to have
> addresses or anything, but the facilities need to be available.
>
> > Em quarta-feira, 22 de março de 2017 20:30:08 UTC-3, dan (ddpbsd)
> escreveu:
> >>
> >> On Tue, Mar 21, 2017 at 10:46 AM, Eduardo Reichert Figueiredo
> >>  wrote:
> >> > When i install ossec 2.9.0 on rhel 7.3 (no ipv6 feature and address) i
> >> > have
> >>
> >> Is IPv6 totally disabled for your system (support for IPv6 was removed)?
> >>
> >> > a problem to ossec-remoted and ossec-auth, this services cant bind
> ports
> >> > 1514, log error below.
> >> > I generated my certificated with commands "openssl genrsa -out" and
> >> > "openssl
> >> > req -new -x509 -key ".
> >> >
> >> > ##Log OSSEC.LOG
> >> > 2017/03/21 11:34:34 ossec-remoted: DEBUG: Forking remoted: '0'.
> >> > 2017/03/21 11:34:34 ossec-remoted: Remote syslog allowed from:
> >> > '0.0.0.0/0'
> >> > 2017/03/21 11:34:34 ossec-remoted: DEBUG: Forking remoted: '1'.
> >> > 2017/03/21 11:34:34 getaddrinfo: Name or service not known
> >> > 2017/03/21 11:34:34 getaddrinfo: Name or service not known
> >> > 2017/03/21 11:34:34 ossec-remoted(1206): ERROR: Unable to Bind port
> >> > '1514'
> >> > 2017/03/21 11:34:34 ossec-remoted(1206): ERROR: Unable to Bind port
> >> > '514'
> >> > 2017/03/21 11:34:41 ossec-syscheckd: INFO: Starting syscheck scan
> >> > (forwarding database).
> >> > 2017/03/21 11:34:41 ossec-syscheckd: INFO: Starting syscheck database
> >> > (pre-scan).
> >> > 2017/03/21 11:35:47 ossec-authd: DEBUG: Starting ...
> >> > 2017/03/21 11:35:47 ossec-authd: INFO: Started (pid: 24420).
> >> > 2017/03/21 11:35:47 ossec-authd: DEBUG: Returning CTX for server.
> >> > 2017/03/21 11:35:47 getaddrinfo: Name or service not known
> >> > 2017/03/21 11:35:47 ossec-authd: Unable to bind to port 1514
> >> >
> >> > in other cases for unable to bind port 1514, my error was my
> >> > client.keys,
> >> > but now i have a new error "getaddrinfo".
> >> >
> >> > Can you help me?
> >> >
> >> > Kind regards
> >> >
> >> > --
> >> >
> >> > ---
> >> > 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.
>



-- 
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] Re: install ossec - bind to port 1514 fail | getaddrinfo: name or service not know

[Victor Fernandez]

Hi Eduardo,

It seems that the error from "getaddrinfo" does not show which process logs 
it, but both remoted and authd processes are logging errors.

Could you share your  configuration and the command that you use to 
run ossec-authd? It could be very useful for us to help you.

Best regards.


On Tuesday, March 21, 2017 at 7:46:37 AM UTC-7, Eduardo Reichert Figueiredo 
wrote:
>
> When i install ossec 2.9.0 on rhel 7.3 (no ipv6 feature and address) i 
> have a problem to ossec-remoted and ossec-auth, this services cant bind 
> ports 1514, log error below.
> I generated my certificated with commands "openssl genrsa -out" and 
> "openssl req -new -x509 -key ".
>
> ##Log OSSEC.LOG
> 2017/03/21 11:34:34 ossec-remoted: DEBUG: Forking remoted: '0'.
> 2017/03/21 11:34:34 ossec-remoted: Remote syslog allowed from: '0.0.0.0/0'
> 2017/03/21 11:34:34 ossec-remoted: DEBUG: Forking remoted: '1'.
> 2017/03/21 11:34:34 getaddrinfo: Name or service not known
> 2017/03/21 11:34:34 getaddrinfo: Name or service not known
> 2017/03/21 11:34:34 ossec-remoted(1206): ERROR: Unable to Bind port '1514'
> 2017/03/21 11:34:34 ossec-remoted(1206): ERROR: Unable to Bind port '514'
> 2017/03/21 11:34:41 ossec-syscheckd: INFO: Starting syscheck scan 
> (forwarding database).
> 2017/03/21 11:34:41 ossec-syscheckd: INFO: Starting syscheck database 
> (pre-scan).
> 2017/03/21 11:35:47 ossec-authd: DEBUG: Starting ...
> 2017/03/21 11:35:47 ossec-authd: INFO: Started (pid: 24420).
> 2017/03/21 11:35:47 ossec-authd: DEBUG: Returning CTX for server.
> 2017/03/21 11:35:47 *getaddrinfo*: Name or service not known
> 2017/03/21 11:35:47 ossec-authd: Unable to bind to port 1514
>
> in other cases for unable to bind port 1514, my error was my client.keys, 
> but now i have a new error "getaddrinfo".
>
> Can you help me?
>
> Kind regards
>

-- 

--- 
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: Modify rules

[Victor Fernandez]

Hi,

You have some options to achieve this:

One of them is to increase the rule level. Changing the value at the 
original rule would work but I'd recommend you to create a new rule (at 
file *local_rules.xml*), adding attribute 'overwrite="yes" ' and changing 
the rule level:


5700 ^Failed|^error: PAM: Authentication <
description>SSHD authentication failed. 
authentication_failed, 


Another option would be enabling Active response for rule 5716 in 
particular, using option "rules_id" inside  group:

  host-deny local 6 5711 600 


Hope it help.
Best regards.




On Monday, March 20, 2017 at 11:56:29 AM UTC-7, The Dude wrote:
>
> I am new to ossec and I am trying to figure out what is the best way to 
> change a rule.  In the ossec.conf it says this
>
> 
>>   
>> 
>> host-deny
>> local
>> 6
>> 600
>>   
>
>
>
>
> I am assuming the level it is referring to is the level set in the 
> rule.xml So the sshd_rules.xml has this line.
>
>>
>> 
>> 5700
>> ^Failed|^error: PAM: Authentication
>> SSHD authentication failed.
>> authentication_failed,
>
>   
>
>  
>
> When testing failed ssh logins I see the alert in the alert.log for the 
> rule above. How should I go about changing the level to 6 so it will get 
> blocked? I tried editing the sshd_rules.xml but get the read only warning. 
>

-- 

--- 
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: Syscheck real-time monitoring

[Victor Fernandez]

Hi Thiago,

the previous messages "Event count after '2':" make me think that your 
system is receiving a large amount of Syscheck events in real-time. 

I think that the error "real time call back called, but 0 bytes" happens 
only in Windows agents when the internal Windows directory monitor reports 
an error. Unfortunately the error message is not more descriptive, but 
maybe the issue is that there are too much changes at monitored files and 
the system is unable to handle them all.

I would suggest you to unset the realtime="yes" option from file ossec.conf for 
non-critical files, or files that are supposed to change too often (like 
logs).

I will try to reproduce this problem and write back to you if I get more 
information.

Hope it help.

Best regards.


On Friday, March 10, 2017 at 12:46:09 PM UTC-8, Thiago Campos wrote:
>
> Hi all! 
>
> I'm having an error on windows agent and real time monitoring appears not 
> working properly. i have had searched about this error but i'm not finding 
> any clue for that issue. 
>
> Any help is welcome. Thanks.
>
> -- ossec.log ---
> 2017/03/10 16:40:41 ossec-agent: INFO: Started (pid: 12060).
> 2017/03/10 16:41:13 ossec-agent: INFO: Starting syscheck scan (forwarding 
> database).
> 2017/03/10 16:41:13 ossec-agent: INFO: Starting syscheck database 
> (pre-scan).
> 2017/03/10 16:45:51 ossec-agent: INFO: Initializing real time file 
> monitoring (not started).
> 2017/03/10 16:46:39 ossec-agent: INFO: Event count after '2': 
> 4627336->3894552 (84%)
> 2017/03/10 16:49:39 ossec-agent: INFO: Event count after '2': 
> 4690104->3989920 (85%)
> 2017/03/10 16:53:51 ossec-agent: INFO: Event count after '2': 
> 4677575->3959152 (84%)
> 2017/03/10 16:57:58 ossec-agent: INFO: Event count after '2': 
> 4320003->3598760 (83%)
> 2017/03/10 17:01:38 ossec-agent: INFO: Event count after '2': 
> 4023516->3354320 (83%)
> 2017/03/10 17:06:28 ossec-agent: INFO: Event count after '2': 
> 4344369->3684992 (84%)
> 2017/03/10 17:08:55 ossec-agent: INFO: Real time file monitoring started.
> 2017/03/10 17:08:55 ossec-agent: INFO: Finished creating syscheck database 
> (pre-scan completed).
> 2017/03/10 17:09:05 ossec-agent: INFO: Ending syscheck scan (forwarding 
> database).
> 2017/03/10 17:09:15 ossec-agent: INFO: Starting rootcheck scan.
> 2017/03/10 17:09:22 ossec-agent: INFO: Ending rootcheck scan.
> 2017/03/10 17:09:22 ossec-agent: *ERROR: real time call back called, but 
> 0 bytes*.
> 2017/03/10 17:09:22 ossec-agent: *ERROR: real time call back called, but 
> 0 bytes.*
> -
>

-- 

--- 
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: Syscheck on windows agent taking too long

[Victor Fernandez]

Glad to solve your problem!

Best regards.

El 10 mar. 2017 10:31 a. m., "Thiago Campos" 
escribió:

>
> Victor,its work! Thanks again.
>
> 2017/03/10 11:55:42 ossec-agent: INFO: Starting syscheck scan (forwarding
> database).
> 2017/03/10 11:55:42 ossec-agent: INFO: Starting syscheck database
> (pre-scan).
> 2017/03/10 11:59:26 ossec-agent: INFO: Initializing real time file
> monitoring (not started).
> 2017/03/10 12:00:18 ossec-agent: INFO: Event count after '2':
> 4630741->3896560 (84%)
> 2017/03/10 12:03:21 ossec-agent: INFO: Event count after '2':
> 4683558->3978416 (84%)
> 2017/03/10 12:07:46 ossec-agent: INFO: Event count after '2':
> 4683863->3962296 (84%)
> 2017/03/10 12:11:53 ossec-agent: INFO: Event count after '2':
> 4363955->3632656 (83%)
> 2017/03/10 12:15:40 ossec-agent: INFO: Event count after '2':
> 4027583->3348784 (83%)
> 2017/03/10 12:20:17 ossec-agent: INFO: Event count after '2':
> 4392205->3710160 (84%)
> 2017/03/10 12:24:16 ossec-agent: INFO: Real time file monitoring started.
> 2017/03/10 12:24:16 ossec-agent: INFO: Finished creating syscheck database
> (pre-scan completed).
> 2017/03/10 12:24:26 ossec-agent: INFO: Ending syscheck scan (forwarding
> database).
> 2017/03/10 12:24:36 ossec-agent: INFO: Starting rootcheck scan.
> 2017/03/10 12:24:42 ossec-agent: INFO: Ending rootcheck scan.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ossec-list" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ossec-list+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 

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

[ossec-list] Re: Syscheck on windows agent taking too long

[Victor Fernandez]

Hi Thiago,

Maybe this is not exactly an issue, if you have configured a large amount 
of files –or Windows Registry entries– to be monitored.

The thing is that Syscheck is actually sleeping most of the time, and does 
so in order not to congest the network. 

You can do some tuning on Syscheck settings: there are two parameters at 
file "/var/ossec/etc/internal_options.conf":

syscheck.sleep=2
syscheck.sleep_after=15


syscheck.sleep means the number of seconds to sleep between "scanning 
stages". syscheck.sleep_after refers to the number of items to be scanned 
on each stage. Increasing  or decreasing  would improve performance but 
would attenuate reliability. If you have few agents (around 10) you may set 
these values:

syscheck.sleep=1
syscheck.sleep_after=150


This would improve the scan speed up to 20x. I tested this scenario with 8 
agents, with more than 99% packages received.

Hope it help.
Best regards.


On Thursday, March 9, 2017 at 2:05:17 PM UTC-8, Thiago Campos wrote:
>
> Hi everyone! 
>
> I'm having an issue. Syschek on windows agent is taking six hours to 
> perfom. 
>
> --- Log on agent --- 
>
> 2017/03/09 02:44:39 ossec-agent: INFO: Starting syscheck scan.
>
> 2017/03/09 08:24:18 ossec-agent: INFO: Ending syscheck scan.
>
> ---
>
> Has anyone ever had this issue?
>
> Thanks,
>
> Thiago Campos
>
>

-- 

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

[ossec-list] Re: queue/ossec/queue' not accessible after fresh install

[Victor Fernandez]

Hi Barry,

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


local_decoder_example



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

Hope it help.
Best regards.

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

-- 

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

[ossec-list] Re: Implementing ossec-local at scale in Docker containers

[Victor Fernandez]

Hi Sushan,

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

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

I did some experiments with a configuration like this:

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

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

Best regards.


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

-- 

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

[ossec-list] Re: Had to rebuild the server, now how to get agent to reconnect

[Victor Fernandez]

Hi Barry, 

the AR queue is managed by process *ossec-remoted*. Please confirm that 
it's up with:

/var/ossec/bin/ossec-control status


And take a look for the ossec.log file:

grep ossec-remoted /var/ossec/logs/ossec.log | tail -n 20


The *ossec-remoted* process dies if file */var/ossec/etc/client.keys* is 
empty. Please check that you have registered one agent at less.

Hope it help.

Best regards.


On Monday, March 6, 2017 at 10:17:41 AM UTC-8, Barry Kaplan wrote:
>
> The ec2 instance that was running the ossec server died. I rebuilt the 
> instance, remounted the disk that had the ossec data files. The server is 
> up, and 'bin/agent_control  -l' shows all the agents. But agents cannot 
> connect.
>
> I have tried restarting agents. I have also updated the client.key. And I 
> have manually unregistered the client and tried to reregister. This last 
> bit failed with
>
> ERROR: Queue '/var/ossec/queue/ossec/queue' not accessible: 'Connection 
> refused'.
>
> I'm not sure which queue that is refering to, the one on the agent or the 
> server. 
>
> But when I start the server I do get these errors
>
> 2017/03/06 17:51:21 ossec-analysisd(1210): ERROR: Queue '/queue/alerts/ar' 
> not accessible: 'Connectio
> 2017/03/06 17:51:21 ossec-analysisd(1301): ERROR: Unable to connect to 
> active response queue.
> 2017/03/06 17:51:21 ossec-analysisd: INFO: Connected to 
> '/queue/alerts/execq' (exec queue)
>
> Not sure why this is. Could it be file ownership
>
> srw-rw  1 ossecr ossec0 Mar  6 17:51 ar=
> srw-rw  1 root   ossec0 Mar  6 17:51 execq=
>
> Should all the queues be owned by ossec?
>

-- 

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

[Victor Fernandez]

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 
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+unsubscr...@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.

Re: [ossec-list] Supressing notification {Scanned}

[Victor Fernandez]

Hi,

I think that your configuration is correct. What's exactly the problem that
you have? I mean, is the rule 1002 still appearing even with that message,
or does the rule 3752 appear at the alert log?

Best regards.

On Tue, Feb 14, 2017 at 4:11 PM,  wrote:

> Hi! I'm trying to remove these notifications from mailscanner.
>
>
> OSSEC HIDS Notification.
> 2017 Feb 14 06:29:41
>
> Received From: hostname->/var/log/syslog
> Rule: 1002 fired (level 2) -> "Unknown problem somewhere in the system."
> Portion of the log(s):
>
> Feb 14 06:29:39 hostname update.bad.phishing.sites: Phishing bad sites
> list updated
>
>
> --END OF NOTIFICATION
>
>
> I've tried to make a rule for it but it's not working. Any help is
> appreciated!
>
> 
> 1002
> update.bad.phishing.sites: Phishing bad sites list updated
> Ignore mailscanner update messages.
> 
>
> --
> Göran Lundberg
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* , and is
> believed to be clean.
>
> --
>
> ---
> 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.
>



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

Re: [ossec-list] Inconsistencies with syscheck realtime + report_changes

[Victor Fernandez]

Hi Chris,

It's really curious that Syscheck creates the diff file but doesn't send
it. There should be no difference between configuring it in real-time or
not.

I see that the diff file matches the actual change by the size difference.
However, did you see any error at the /var/ossec/logs/ossec.log file that
could be related to this issue? Anything like:

ERROR: Unable to generate diff alert.


Best regards.


On Thu, Feb 9, 2017 at 1:51 PM, Chris Decker  wrote:

> All,
>
> I have hundreds of machines that are (supposed to be) all configured
> exactly the same way via kickstarts and periodic Puppet runs.  I've noticed
> that sometimes a Puppet push will modify a file across all of our machines,
> and the resulting syscheck notifications are a mixed bag - some have the
> report_change included (the *diff*), and others generate an alert but
> lack the report_change details.
>
> I'm scratching my head trying to figure out why it's working on some and
> not others.  Below are some details on a machine where report_change is
> failing:
>
> *OSSEC Agent Version:*
>
> ossec-hids-agent-2.9.0-48.el6.art.x86_64
> ossec-hids-2.9.0-48.el6.art.x86_64
>
>
> *inotify-tools Version:*
>
> rpm -qa | grep -i inotify
> inotify-tools-3.14-1.el6.x86_64
>
>
> *E-mail Notification:*
>
> Received From: (removed) 1.2.3.4->syscheck
> Rule: 102907 fired (level 7) -> "File integrity changed, likely security
> relevant"
> Portion of the log(s):
>
> Integrity checksum changed for: '/etc/security/limits.conf'
> Size changed from '1885' to '1927'
> Old md5sum was: 'a639c5c0ea72bcb59c6a1379f6baa797'
> New md5sum is : '301d246e310c78c2c76ef69cdefe00d1'
> Old sha1sum was: '579006cf4e04899e05ff7812dc6a6c17500753fb'
> New sha1sum is : '714e5ffa5da1b684d0d591b5a822460b8c8ba4c3'
>
>
> *OSSEC Manager syscheck_control Output:*
>
> /var/ossec/bin/syscheck_control -i 2337 -f /etc/security/limits.conf
>
> Integrity changes for agent 'removed (2337) - 1.2.3.4':
> Detailed information for entries matching: '/etc/security/limits.conf'
>
> 2017 Jan 31 12:55:42,0 - /etc/security/limits.conf
> File added to the database.
> Integrity checking values:
>Size: 1885
>Perm: rw-r--r--
>Uid:  0
>Gid:  0
>Md5:  a639c5c0ea72bcb59c6a1379f6baa797
>Sha1: 579006cf4e04899e05ff7812dc6a6c17500753fb
>
> 2017 Feb 09 15:51:49,0 - /etc/security/limits.conf
> File changed. - 1st time modified.
> Integrity checking values:
>Size: >1927
>Perm: rw-r--r--
>Uid:  0
>Gid:  0
>Md5:  >301d246e310c78c2c76ef69cdefe00d1
>Sha1: >714e5ffa5da1b684d0d591b5a822460b8c8ba4c3
>
>
> *The logs on the Agent do show that real-time monitoring was started prior
> to this change…*
>
> 2017/02/07 20:56:23 ossec-syscheckd: INFO: Initializing real time file
> monitoring (not started).
> …
> 2017/02/07 21:30:07 ossec-syscheckd: INFO: Real time file monitoring
> started.
>
>
> *Strangely enough, the diff file does exist on the filesystem for this
> machine:*
>
> cat /var/ossec/queue/diff/local/etc/security/limits.conf/diff.1486673498
> 52a53,54
> > * soft stack 10240
> > * hard stack unlimited
>
>
> # 1486673498 converts to Thursday February 09, 2017 15:51:38 (pm)
>
>
> *As far as I can tell my agent.conf is correct (and remember I use this
> agent.conf across hundreds of nodes):*
>
> 
>   
> no
> 79200
>
> /etc directories>
>   
> …
>
>
> *Permissions of /var/ossec/tmp:*
>
> ls -ld /var/ossec/tmp/
> dr-xr-x--- 2 root ossec 4096 Feb  9 16:27 /var/ossec/tmp/
>
>
>
>
> Any thoughts on what could be causing this?
>
>
> --
>
> ---
> 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.
>



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

Re: [ossec-list] Maximum Number of Agents Allowed

[Victor Fernandez]

Hi Patrick,

unfortunately there is no way to do this, since the maximum agents
parameter is used to create some static arrays into the code. This makes
necessary to re-compile and install the binaries.

Best regards.

On Fri, Jan 20, 2017 at 1:51 PM,  wrote:

> Is there a way to set the max number of agents without recompiling the
> installer?
>
> On Saturday, August 20, 2011 at 11:01:06 PM UTC-4, Michael Starks wrote:
>>
>> On 08/18/2011 07:52 AM, Swartz, Patrick H wrote:
>> > That is the default maximum, however it is modifiable by going into the
>> > /src directory (of the install package) and running "make setmaxagents",
>> > this will prompt you asking for a new maximum value.
>> > You will then need to recompile to take advantage of the new value.
>> > We currently use 4096 (with close to 2000 active agents) with no issues.
>> >
>> > Patrick Swartz
>>
>> I would also recommend some OS tuning with that many agents:
>> http://www.immutablesecurity.com/index.php/2010/10/20/2woo-tips-tricks/
>>
> --
>
> ---
> 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.
>



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

Re: [ossec-list] Re: Update Wazuh with standard Ossec files

[Victor Fernandez]

Hi Alejandro,

The issue seems to be a counter problem since any other error would print
an additional error message.

Try to remove the file: "/var/ossec/queue/rids/" from the agent, for N
being the agent ID. For example:

rm /var/ossec/queue/rids/$(cut -d' ' -f1 /var/ossec/etc/client.keys)

/var/ossec/bin/ossec-control restart


An easier option is to disable the message verification:

echo "remoted.verify_msg_id=0" >> /var/ossec/etc/local_internal_options.conf
/var/ossec/bin/ossec-control restart


Hope it helps.

Best regards.

On Mon, Jan 23, 2017 at 5:22 AM, Alejandro M  wrote:

> These are the messages I'm getting from Ossec on the side of the agent:
>
> 2017/01/22 09:42:44 ossec-agentd: INFO: Trying to connect to server
> (x.x.x.10:1514).
> 2017/01/22 09:42:44 ossec-agentd: INFO: Using IPv4 for: x.x.x.10 .
> 2017/01/22 09:42:45 ossec-agentd(1214): WARN: Problem receiving message
> from x.x.x.10.
> 2017/01/22 09:42:54 ossec-agentd(1214): WARN: Problem receiving message
> from x.x.x.10.
> 2017/01/22 09:42:59 ossec-agentd(1214): WARN: Problem receiving message
> from x.x.x.10.
> 2017/01/22 09:43:05 ossec-agentd(1214): WARN: Problem receiving message
> from x.x.x.10
>
> --
>
> ---
> 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.
>



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

Re: [ossec-list] Re: Compile issue : undefined reference ?

[Victor Fernandez]

Hi,

I did compile OSSEC v2.8.3 on a clean CentOS 7 following these steps:

1. Install MySQL Community repository:

curl -Lo mysql.rpm 
http://dev.mysql.com/get/mysql57-community-release-el7-9.noarch.rpm
mysql -y install mysql.rpm
rm mysql.rpm


2. Download OSSEC v2.8.3 sources:

yum -y install git
git clone https://github.com/ossec/ossec-hids.git -b v2.8.3


3. Install dependencies:

cd ossec-hids/src
yum -y install gcc make mysql-community-devel 


4. Configure the project to compile with MySQL database support. We've two 
options to do it:

  Option 1: Using the utility by OSSEC, we must install two more packages:

yum -y install which mysql-community-client
make setdb


  Option 2: Writing directly onto the configuration file:

echo CDB=$(mysql_config --cflags) $(mysql_config --libs) -DDBD -DUMYSQL > 
Config.OS


5. Compile OSSEC:

make all


Hope it helps.

Best regards.


On Tuesday, December 20, 2016 at 7:52:53 PM UTC+1, dan (ddpbsd) wrote:
>
> On Sun, Dec 18, 2016 at 9:36 PM, Mohd Zainal Abidin Mamat 
>  wrote: 
> > I'm getting same error using ver 2.8.3 on centos 7. Still seeking 
> solution. 
> > 
>
> Verify that you have the devel packages installed. 
> I just setup a Centos 7 VM, added the mysql community packages, and 
> installed OSSEC without any errors. 
>
> [root@localhost ossec-hids-2.8.3]# rpm -qa | grep -i mysql 
> mysql-community-devel-5.7.17-1.el7.x86_64 
> mysql-community-libs-5.7.17-1.el7.x86_64 
> mysql57-community-release-el7-9.noarch 
> mysql-community-libs-compat-5.7.17-1.el7.x86_64 
> mysql-community-client-5.7.17-1.el7.x86_64 
> mysql-community-common-5.7.17-1.el7.x86_64 
>
>
> > On Saturday, July 10, 2010 at 5:11:07 AM UTC+8, Jason 'XenoPhage' 
> Frisvold 
> > wrote: 
> >> 
> >> -BEGIN PGP SIGNED MESSAGE- 
> >> Hash: SHA1 
> >> 
> >> Hi all, 
> >> 
> >> I'm having a problem compiling ossec on a local server I have. 
> >> The 
> >> server is an CentOS 5.5 machine using the official MySQL RPMs rather 
> >> than the CentOS version.  Specifically, I have the following installed 
> : 
> >> 
> >> MySQL-devel-community-5.0.67-0.rhel5 
> >> MySQL-shared-compat-5.0.67-0.rhel5 
> >> MySQL-server-community-5.0.67-0.rhel5 
> >> MySQL-client-community-5.0.67-0.rhel5 
> >> 
> >> The error I'm receiving is as follows : 
> >> 
> >>  *** Making os_dbd *** 
> >> 
> >> make[1]: Entering directory 
> >> `/usr/src/redhat/BUILD/ossec-hids-2.4.1/src/os_dbd' 
> >> Compiling DB support with: 
> >> gcc -g -Wall -I../ -I../headers   -DUSE_OPENSSL -DUSEINOTIFY 
> >> - -DARGV0=\"ossec-dbd\" -DXML_VAR=\"var\" -DOSSECHIDS 
> >> - -I/usr/include/mysql  -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions 
> >> - -fstack-protector --param=ssp-buffer-size=4 -m32 
> >> - -fasynchronous-unwind-tables -rdynamic -L/usr/lib/mysql -lmysqlclient 
> >> - -lz -lcrypt -lnsl -lm -DDBD -DUMYSQL  *.c ../config/lib_config.a 
> >> ../shared/lib_shared.a ../os_net/os_net.a ../os_regex/os_regex.a 
> >> ../os_xml/os_xml.a -o ossec-dbd 
> >> /tmp/ccKCtW2N.o: In function `mysql_osdb_connect': 
> >> /usr/src/redhat/BUILD/ossec-hids-2.4.1/src/os_dbd/db_op.c:164: 
> undefined 
> >> reference to `mysql_init' 
> >> /usr/src/redhat/BUILD/ossec-hids-2.4.1/src/os_dbd/db_op.c:178: 
> undefined 
> >> reference to `mysql_options' 
> >> /usr/src/redhat/BUILD/ossec-hids-2.4.1/src/os_dbd/db_op.c:183: 
> undefined 
> >> reference to `mysql_options' 
> >> /usr/src/redhat/BUILD/ossec-hids-2.4.1/src/os_dbd/db_op.c:186: 
> undefined 
> >> reference to `mysql_real_connect' 
> >> /usr/src/redhat/BUILD/ossec-hids-2.4.1/src/os_dbd/db_op.c:189: 
> undefined 
> >> reference to `mysql_error' 
> >> /usr/src/redhat/BUILD/ossec-hids-2.4.1/src/os_dbd/db_op.c:190: 
> undefined 
> >> reference to `mysql_close' 
> >> /tmp/ccKCtW2N.o: In function `mysql_osdb_close': 
> >> /usr/src/redhat/BUILD/ossec-hids-2.4.1/src/os_dbd/db_op.c:204: 
> undefined 
> >> reference to `mysql_close' 
> >> /tmp/ccKCtW2N.o: In function `mysql_osdb_query_insert': 
> >> /usr/src/redhat/BUILD/ossec-hids-2.4.1/src/os_dbd/db_op.c:215: 
> undefined 
> >> reference to `mysql_query' 
> >> /usr/src/redhat/BUILD/ossec-hids-2.4.1/src/os_dbd/db_op.c:218: 
> undefined 
> >> reference to `mysql_error' 
> >> /tmp/ccKCtW2N.o: In function `mysql_osdb_query_select': 
> >> /usr/src/redhat/BUILD/ossec-hids-2.4.1/src/os_dbd/db_op.c:240: 
> undefined 
> >> reference to `mysql_query' 
> >> /usr/src/redhat/BUILD/ossec-hids-2.4.1/src/os_dbd/db_op.c:243: 
> undefined 
> >> reference to `mysql_error' 
> >> /usr/src/redhat/BUILD/ossec-hids-2.4.1/src/os_dbd/db_op.c:250: 
> undefined 
> >> reference to `mysql_use_result' 
> >> /usr/src/redhat/BUILD/ossec-hids-2.4.1/src/os_dbd/db_op.c:254: 
> undefined 
> >> reference to `mysql_error' 
> >> /usr/src/redhat/BUILD/ossec-hids-2.4.1/src/os_dbd/db_op.c:261: 
> undefined 
> >> reference to `mysql_fetch_row' 
> >> /usr/src/redhat/BUILD/ossec-hids-2.4.1/src/os_dbd/db_op.c:268: 
> undefined 
> >> reference to `mysql_free_result' 
> >> 

Re: [ossec-list] remoted Dropping Events

[Victor Fernandez]

Hi,

quite so, TCP is supported on Wazuh manager and agents, version 1.1 and 
above.

If you are experiencing this issue, you may activate the archives on the 
manager, with this line at ossec.conf:


  
*yes*
  



Restart your agent and look out the file 
/var/ossec/logs/archives/archives.log. Then search for an agent that should 
be active but appears as disconnected and generate any message on it. The 
manager should print that message although it doesn't produce an alert.

If the message arrives, it's OK and we should only find why the agent 
appears as disconnected. If you don't find the message on the archives 
file, look for an error by "ossec-remoted" at /var/ossec/logs/ossec.log 
and, if you see nothing related to it, use the tcpdump tool to watch 
whether packages from the agent are arriving.

Hope it helps.

Best regards.



On Tuesday, December 13, 2016 at 3:45:04 PM UTC+1, dan (ddpbsd) wrote:
>
> On Tue, Dec 13, 2016 at 9:11 AM, Chris Decker <ch...@chris-decker.com 
> > wrote: 
> > Victor, 
> > 
> > I'm at the point where my agents all have valid keys, so I'm unsure as 
> to 
> > why I have ~ 750 clients and only ~225 are reported as "active" at any 
> one 
> > time (all of the machines are alive and well, and generating mountains 
> of 
> > log data  :)).  I wanted to give tcp communication a shot, but it 
> appears 
> > that  isn't valid within the client tag: 
> > 
> > 2016/12/13 09:05:49 ossec-config(1230): ERROR: Invalid element in the 
> > configuration: 'protocol'. 
> > 
> > 2016/12/13 09:05:49 ossec-config(1202): ERROR: Configuration error at 
> > '/var/ossec/etc/ossec.conf'. Exiting. 
> > 
> > 2016/12/13 09:05:49 ossec-agentd(1215): ERROR: No client configured. 
> > Exiting. 
> > 
> > 
> > The documentation also doesn't make it appear that  is an 
> option 
> > there: 
> > 
> > http://ossec.github.io/docs/syntax/head_ossec_config.client.html 
> > 
>
> I believe that's a wazuh extension. 
>
> > 
> > Is there something I am missing? 
> > 
> > 
> > 
> > On Friday, December 9, 2016 at 6:42:27 AM UTC-5, Victor Fernandez wrote: 
> >> 
> >> Hi, 
> >> 
> >> Agents should send a keepalive each 10 minutes (600 seconds) by 
> default, 
> >> and this should be enough. But you can go down that time at the agent's 
> >> ossec.conf: 
> >> 
> >> 
> >>  
> >> 
> >>   1.2.3.4 
> >>   60 
> >> 
> >> 
> >> 
> >> If you see any agent disconnected, check its ossec.log file. 
> >> 
> >> On the other hand, as Dan says, the manager will discard two identical 
> >> consecutive messages, so you should generate different messages for the 
> logs 
> >> (using a random string or the date). 
> >> 
> >> If you think that there could be network congestion, you may try to 
> >> connect using TCP, adding, at the agent's ossec.conf: 
> >> 
> >>  
> >> 
> >>   1.2.3.4 
> >>   tcp 
> >> 
> >> 
> >> And, on the manager's ossec.conf: 
> >> 
> >>  
> >>
> >> secure 
> >> tcp 
> >>
> >> 
> >> 
> >> Please test it and write back to us if this doesn't solve the problem. 
> All 
> >> feedback is welcome. 
> >> 
> >> Hope it helps. 
> >> Best regards. 
> >> 
> >> 
> >> On Friday, December 9, 2016 at 6:30:08 AM UTC+1, dan (ddpbsd) wrote: 
> >>> 
> >>> 
> >>> 
> >>> On Dec 8, 2016 4:41 PM, "Chris Decker" <ch...@chris-decker.com> 
> wrote: 
> >>> 
> >>> All, 
> >>> 
> >>> I have an OSSEC instance (running the latest/greatest Wuzuh code 
> cloned 
> >>> from GitHub) that has about 1k active hosts.  I've noticed recently 
> that 
> >>> hosts are flipping back and forth between Active and Disconnected. 
> >>> 
> >>> 
> >>> Perhaps the manager is too busy? I can't remember the host limit 
> offhand, 
> >>> but I believe ossec limits the number of agents to a number smaller 
> than 
> >>> 1000. 
> >>> 
> >>> 
> >>> I've also noticed that not all of the log messages from "Active" hosts 
> >>> are being received by the Manager.  For example, I have an agent that 
> >>> generates the same log message every second.  I h

Re: [ossec-list] remoted Dropping Events

[Victor Fernandez]

Hi Chris,

since you compiled the project with "TARGET=server", maybe you chose 
"local" when installed it. A local installation is a profile like a server 
but without Remoted, that's why that daemon doesn't start with "ossec-control 
start".

The line at ossec-init.conf has only informational purposes, changing it 
will be useless. The local profile compiles OSSEC with option "TARGET=local", 
copies the script at "src/init/ossec-local.sh" as "
/var/ossec/bin/ossec-control" and applies a local setting template (without 
 configuration, for example).

The best option would be to uninstall OSSEC, clean the compilation (make 
clean) and re-install it. If you can't uninstall it, these steps may help 
you:

   1. Change to the "Wazuh" directory.
   2. Clean the project: make -C src clean
   3. Compile and install again: make -C src TARGET=server install
   4. Create a default remote setting on /var/ossec/etc/ossec.conf:
   
   
 
   
 **
   *secure*
   *  *
   
 
   
   
   5. Restart OSSEC: /var/ossec/bin/ossec-control restart
   
This may fix your problem.

Best regards.



On Monday, December 12, 2016 at 7:11:07 PM UTC+1, Chris Decker wrote:
>
> Victor,
>
> ossec-init.conf is showing the the installation is a *local* installation.
>
> However, I know that I performed a server installation per my notes and 
> bash history…
>
> make clean
>
> make TARGET=server
>
>
>
> Obviously I could change this value back to 'server', but will this fix 
> the issue?
>
>
>
> Thanks,
> Chris
>
>
> On Saturday, December 10, 2016 at 6:04:45 AM UTC-5, Victor Fernandez wrote:
>>
>> Hi Chris,
>>
>> as you guessed, there is one *remoted* process for each  
>> configuration. Although it's strange that "ossec-control stop" does stop 
>> the *remoted *processes but "ossec-control start" doesn't run them.
>>
>> How did you install Wazuh? Please make sure that the file "
>> /var/ossec/etc/ossec-init.conf" has the line:
>>
>> TYPE="server"
>>
>>
>> Regards.
>>
>>
>> On Friday, December 9, 2016 at 5:24:38 PM UTC+1, Chris Decker wrote:
>>>
>>> Dan,
>>>
>>> Thanks for your help.
>>>
>>> Is ossec-remoted listed in the DAEMONS variable in the script?
>>>>
>>> It was *not*, but I added it after noticing it wasn't in there.  If I 
>>> tell ossec-control to stop, remoted stops as expected:
>>>
>>> [root@logger01 limits.d]# /var/ossec/bin/ossec-control stop
>>> Killing ossec-monitord .. 
>>> Killing ossec-logcollector .. 
>>> Killing ossec-syscheckd .. 
>>> Killing ossec-analysisd .. 
>>> Killing ossec-maild .. 
>>> Killing ossec-remoted .. 
>>> Killing ossec-execd .. 
>>> Wazuh v1.2 Stopped
>>>
>>>
>>> However, if I tell ossec-control to start, it starts everything but I 
>>> don't see remoted referenced:
>>> [root@logger01 limits.d]# /var/ossec/bin/ossec-control start
>>>
>>> Starting Wazuh v1.2 (maintained by Wazuh Inc.)...
>>> Started wazuh-moduled...
>>> Started ossec-maild...
>>> Started ossec-execd...
>>> Started ossec-analysisd...
>>> Started ossec-logcollector...
>>> 2016/12/09 11:22:51 rootcheck: Rootcheck disabled. Exiting.
>>> 2016/12/09 11:22:51 ossec-syscheckd: WARN: Rootcheck module disabled.
>>> Started ossec-syscheckd...
>>> Started ossec-monitord...
>>> Completed.
>>>
>>>
>>> The only thing I *removed* from that list of modules was the 
>>> ossec-wuzuh module because I do not currently use it.
>>>  
>>>
>>>> What is your remote condiguration in your ossec.conf?
>>>
>>>  
>>>  
>>> secure
>>>   
>>>
>>>
>>>   
>>> syslog
>>> tcp
>>> 514
>>> 10.0.0.0/8
>>>   
>>>   
>>> syslog
>>> udp
>>> 514
>>> 10.0.0.0/8
>>>
>>>
>>> Dave's comment jogged my memory about why remoted is running 3 separate 
>>> processes - 1514/udp, 514/udp and 514/tcp.
>>>
>>>
>>>
>>> On Friday, December 9, 2016 at 10:33:50 AM UTC-5, dan (ddpbsd) wrote:
>>>>
>>>>
>>>>
>>>> On Dec 9, 2016 9:17 AM, "Chris Decker" <ch...@chris-decker.com> wrote:
>>>>
>>>> Victor,
>>>>
>>>> On F

Re: [ossec-list] remoted Dropping Events

[Victor Fernandez]

Hi Chris,

as you guessed, there is one *remoted* process for each  
configuration. Although it's strange that "ossec-control stop" does stop 
the *remoted *processes but "ossec-control start" doesn't run them.

How did you install Wazuh? Please make sure that the file "
/var/ossec/etc/ossec-init.conf" has the line:

TYPE="server"


Regards.


On Friday, December 9, 2016 at 5:24:38 PM UTC+1, Chris Decker wrote:
>
> Dan,
>
> Thanks for your help.
>
> Is ossec-remoted listed in the DAEMONS variable in the script?
>>
> It was *not*, but I added it after noticing it wasn't in there.  If I 
> tell ossec-control to stop, remoted stops as expected:
>
> [root@logger01 limits.d]# /var/ossec/bin/ossec-control stop
> Killing ossec-monitord .. 
> Killing ossec-logcollector .. 
> Killing ossec-syscheckd .. 
> Killing ossec-analysisd .. 
> Killing ossec-maild .. 
> Killing ossec-remoted .. 
> Killing ossec-execd .. 
> Wazuh v1.2 Stopped
>
>
> However, if I tell ossec-control to start, it starts everything but I 
> don't see remoted referenced:
> [root@logger01 limits.d]# /var/ossec/bin/ossec-control start
>
> Starting Wazuh v1.2 (maintained by Wazuh Inc.)...
> Started wazuh-moduled...
> Started ossec-maild...
> Started ossec-execd...
> Started ossec-analysisd...
> Started ossec-logcollector...
> 2016/12/09 11:22:51 rootcheck: Rootcheck disabled. Exiting.
> 2016/12/09 11:22:51 ossec-syscheckd: WARN: Rootcheck module disabled.
> Started ossec-syscheckd...
> Started ossec-monitord...
> Completed.
>
>
> The only thing I *removed* from that list of modules was the ossec-wuzuh 
> module because I do not currently use it.
>  
>
>> What is your remote condiguration in your ossec.conf?
>
>  
>  
> secure
>   
>
>
>   
> syslog
> tcp
> 514
> 10.0.0.0/8
>   
>   
> syslog
> udp
> 514
> 10.0.0.0/8
>
>
> Dave's comment jogged my memory about why remoted is running 3 separate 
> processes - 1514/udp, 514/udp and 514/tcp.
>
>
>
> On Friday, December 9, 2016 at 10:33:50 AM UTC-5, dan (ddpbsd) wrote:
>>
>>
>>
>> On Dec 9, 2016 9:17 AM, "Chris Decker" <ch...@chris-decker.com> wrote:
>>
>> Victor,
>>
>> On Friday, December 9, 2016 at 6:42:27 AM UTC-5, Victor Fernandez wrote:
>>>
>>> Hi,
>>>
>>> Agents should send a keepalive each 10 minutes (600 seconds) by default, 
>>> and this should be enough. But you can go down that time at the agent's 
>>> ossec.conf:
>>>
>>>
>>> 
>>>
>>>   1.2.3.4
>>>   *60*
>>>
>>>
>>>
>>> If you see any agent disconnected, check its ossec.log file.
>>>
>>> On the other hand, as Dan says, the manager will discard two identical 
>>> consecutive messages, so you should generate different messages for the 
>>> logs (using a random string or the date).
>>>
>> These events were from auditd and were unique enough that OSSEC should 
>> treat them as such. 
>>
>>
>> Sorry, I thought you wrote that the logs were the same.
>>
>>
>>
>>> If you think that there could be network congestion, you may try to 
>>> connect using TCP, adding, at the agent's ossec.conf:
>>>
>>> 
>>>
>>>   1.2.3.4
>>>   *tcp*
>>>
>>>
>>> And, on the manager's ossec.conf:
>>>
>>> 
>>>   
>>> secure
>>> *tcp*
>>>   
>>>
>>> I'm going to give this a try.
>>
>> One thing I've noticed is that the ossec-control script isn't starting up 
>> remoted.  If I start remoted by hand it starts, but then I see 3 remoted 
>> processes.  I've never come across this issue before.  Do you know what 
>> could be causing it?
>>
>>
>>
>> Is ossec-remoted listed in the DAEMONS variable in the script?
>> What is your remote condiguration in your ossec.conf?
>>
>>
>>> Please test it and write back to us if this doesn't solve the problem. 
>>> All feedback is welcome.
>>>
>>> Hope it helps.
>>> Best regards.
>>>
>>>
>>> On Friday, December 9, 2016 at 6:30:08 AM UTC+1, dan (ddpbsd) wrote:
>>>>
>>>>
>>>>
>>>> On Dec 8, 2016 4:41 PM, "Chris Decker" <ch...@chris-decker.com> wrote:
>>>>
>>>> All,
>>>>
>>>> I have an OSSEC instance (running t

Re: [ossec-list] remoted Dropping Events

[Victor Fernandez]

Hi,

Agents should send a keepalive each 10 minutes (600 seconds) by default, 
and this should be enough. But you can go down that time at the agent's 
ossec.conf:



   
  1.2.3.4
  *60*
   


If you see any agent disconnected, check its ossec.log file.

On the other hand, as Dan says, the manager will discard two identical 
consecutive messages, so you should generate different messages for the 
logs (using a random string or the date).

If you think that there could be network congestion, you may try to connect 
using TCP, adding, at the agent's ossec.conf:


   
  1.2.3.4
  *tcp*
   

And, on the manager's ossec.conf:


  
secure
*tcp*
  


Please test it and write back to us if this doesn't solve the problem. All 
feedback is welcome.

Hope it helps.
Best regards.


On Friday, December 9, 2016 at 6:30:08 AM UTC+1, dan (ddpbsd) wrote:
>
>
>
> On Dec 8, 2016 4:41 PM, "Chris Decker"  > wrote:
>
> All,
>
> I have an OSSEC instance (running the latest/greatest Wuzuh code cloned 
> from GitHub) that has about 1k active hosts.  I've noticed recently that 
> hosts are flipping back and forth between *Active* and *Disconnected*.
>
>
> Perhaps the manager is too busy? I can't remember the host limit offhand, 
> but I believe ossec limits the number of agents to a number smaller than 
> 1000.
>
>
> I've also noticed that not all of the log messages from "*Active" *hosts 
> are being received by the Manager.  For example, I have an agent that 
> generates the same log message every second.  I have debug enabled on the 
> Agent and I can see logcollector reading each message, but only *some* of 
> the messages are received on the Manager (I monitored it for awhile and 
> it's not that the messages show up later due to network congestion--I don't 
> see the messages ever being received).  I tried disabling the agent ID 
> checks on both the Manager and Agent but that didn't have any impact.
>
>
> Ossec will discard some repeated messages. I forget the timeframe offhand 
> though.
>
>
>
> I suspect there is a misconfiguration or limit I am running into on my 
> Manager running RHEL 7, but I haven't been able to track it down.  I did a 
> simple netcat test between the same two hosts and there was no lag in 
> transmissions.
>
> Any suggestions/thoughts from the community?
>
>
>
>
> 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+...@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] Still having problems with OSSEC 2.8 on FreeBSD 10.3

[Victor Fernandez]

Hello,

The "ossec/queue" file is actually a socket that *ossec-agentd* creates to
allow *Syscheck *and *Logcollector *to send data. Then *ossec-agentd* delivers
that data to the manager.

When you launched "/usr/local/ossec-hids/bin/ossec-control start", the
application logged that *ossec-execd* was already running, but
*ossec-agend* doesn't.
This makes me think that there is an issue with the *ossec-agentd* program
and, since it can't create the "ossec/queue" socket, no other program can
continue working.

So, please make sure that a valid key is installed. For this, run

cat /usr/local/ossec-hids/etc/client.keys


There should be any content. If no such content is shown, reinstall the key
(with *manage_agents*). If everything is OK, restart the complete OSSEC
agent, wait for about a minute, check the logs related to *ossec-agent* and
check whether it's yet running:

/usr/local/ossec-hids/bin/ossec-control restart
cat ossec-agentd /usr/local/ossec-hids/logs/ossec.log
/usr/local/ossec-hids/bin/ossec-control status


If, after restarting the OSSEC agent, you see an error with "cat", share it
with us so we may help you. But if you don't see any error log, and
"ossec-control status" tells that *ossec-agentd* isn't running, this means
that the program has crashed and then it would be interesting to reinstall
it from sources with debugging features enabled and re-run it with the
*valgrind* utility, in order to search for bugs.

Hope it helps.
Regards.


On Sun, Dec 4, 2016 at 1:27 AM, dan (ddp)  wrote:

>
>
> On Dec 3, 2016 4:54 PM, "Eponymous -"  wrote:
>
> Hi all,
>
> I've had many problems getting the OSSEC agent to start up correctly on
> FreeBSD 10.3 (see: https://groups.google.com/forum/#!topic/ossec-list/VDT
> 4cTObDPQ - "Chroot directory change option.) I figured it would best to
> start a separate discussion.
>
> I've done a completely fresh install of *ossec-hids-client-2.8.2* from
> pkg.freebsd.org and then simply changed the IP address to the correct
> server address in ossec.conf and then added the key using manage-agents.
>
> Every time I start I get issues with permissions.
>
> /usr/local/ossec-hids/bin/ossec-control start
> Starting OSSEC HIDS v2.8 (by Trend Micro Inc.)...
> ossec-execd already running...
> 2016/12/03 21:42:08 ossec-agentd: INFO: Using notify time: 600 and max
> time to reconnect: 1800
> Started ossec-agentd...
> Started ossec-logcollector...
> 2016/12/03 21:42:11 ossec-syscheckd(1210): ERROR: Queue
> '/usr/local/ossec-hids/queue/ossec/queue' not accessible: 'Connection
> refused'.
> 2016/12/03 21:42:11 ossec-rootcheck(1210): ERROR: Queue
> '/usr/local/ossec-hids/queue/ossec/queue' not accessible: 'Connection
> refused'.
> 2016/12/03 21:42:19 ossec-syscheckd(1210): ERROR: Queue
> '/usr/local/ossec-hids/queue/ossec/queue' not accessible: 'Connection
> refused'.
> 2016/12/03 21:42:19 ossec-rootcheck(1210): ERROR: Queue
> '/usr/local/ossec-hids/queue/ossec/queue' not accessible: 'Connection
> refused'.
> 2016/12/03 21:42:32 ossec-syscheckd(1210): ERROR: Queue
> '/usr/local/ossec-hids/queue/ossec/queue' not accessible: 'Connection
> refused'.
> 2016/12/03 21:42:32 ossec-rootcheck(1211): ERROR: Unable to access queue:
> '/usr/local/ossec-hids/queue/ossec/queue'. Giving up..
> ossec-syscheckd did not start
>
> This page: http://ossec-docs.readthedocs.io/en/latest/faq/unexpected.html
> talks about checking that "ossec-analysisd" is running, but I can't see
> that file anywhere in the install location so my guess is it was removed
> and possibly merged into another binary.
>
>
> That advice is for the server install or local install only.
>
>
> Using tree, I checked all the permissions:
>
> # tree -ugap /usr/local/ossec-hids/
> /usr/local/ossec-hids/
> |-- [drwx-- ossecossec   ]  .ssh
> |-- [drwxr-xr-x root ossec   ]  active-response
> |   `-- [drwxr-xr-x root ossec   ]  bin
> |   |-- [-rwxr-xr-x root wheel   ]  disable-account.sh
> |   |-- [-rwxr-xr-x root wheel   ]  firewall-drop.sh
> |   |-- [-rwxr-xr-x root wheel   ]  host-deny.sh
> |   |-- [-rwxr-xr-x root wheel   ]  ip-customblock.sh
> |   |-- [-rwxr-xr-x root wheel   ]  ipfw.sh
> |   |-- [-rwxr-xr-x root wheel   ]  ipfw_mac.sh
> |   |-- [-rwxr-xr-x root wheel   ]  ossec-tweeter.sh
> |   |-- [-rwxr-xr-x root wheel   ]  pf.sh
> |   |-- [-rwxr-xr-x root wheel   ]  restart-ossec.sh
> |   `-- [-rwxr-xr-x root wheel   ]  route-null.sh
> |-- [drwxr-xr-x root ossec   ]  agentless
> |   |-- [-rwxr-x--- root ossec   ]  main.exp
> |   |-- [-rwxr-x--- root ossec   ]  register_host.sh
> |   |-- [-rwxr-x--- root ossec   ]  ssh.exp
> |   |-- [-rwxr-x--- root ossec   ]  ssh_asa-fwsmconfig_diff
> |   |-- [-rwxr-x--- root ossec   ]  ssh_foundry_diff
> |   |-- [-rwxr-x--- root ossec   ]  ssh_generic_diff
> |   |-- [-rwxr-x--- root ossec   ]  ssh_integrity_check_bsd
> |   |-- 

Re: [ossec-list] OSSEC Agent to server communication issue

[Victor Fernandez]

Hi Vipin,

Prior to connect to the manager, agents must be registered onto it. For 
example, let the manager's IP be 1.1.1.1 and the agent's IP be 2.2.2.2.

In first place, use /var/ossec/bin/manage_agents to add an agent. Choose an 
arbitrary name for it, then you'll be asked for the agent's IP. If the 
agent's IP will always be the same (2.2.2.2), write it; else, if the 
agent's IP is dynamic or can change, write "*any*" as the IP. The manager 
will reject an agent if its IP doesn't match with the registered IP (unless 
it is "any").

When the agent is registered, use the option E (at manage_agents) to 
extract the agent's key. After, go to the agent and run 
/var/ossec/bin/manage_agents, in this cas you'll see that there's no option 
to add an agent but you can import (option I) a key. Select that option and 
paste the key that you extracted from the manager.

You can get more information about agents management at: 
http://ossec-docs.readthedocs.io/en/latest/manual/agent/agent-management.html
.

Now, restart the manager (in order to reload the agents' keys) and the 
agent. You should get a message at the log such:

2016/11/07 10:55:27 ossec-agentd(4102): INFO: Connected to the server 
(1.1.1.1:1514).

The manager should trigger this alert:

** Alert 1478512792.55161: mail  - ossec,pci_dss_10.6.1,
2016 Nov 07 10:59:52 (CentOS) 2.2.2.2->ossec
Rule: 501 (level 3) -> 'New ossec agent connected.'
ossec: Agent started: 'CentOS->2.2.2.2'.

A common error is that the agent was no registered with the proper IP, or 
the key is not correctly imported into the agent. In this case, the 
manager's log would print messages like:

2016/11/07 10:28:18 ossec-remoted(1403): ERROR: Incorrectly formated 
message from 'any'.
or:
2016/11/07 10:59:06 ossec-remoted(1408): ERROR: Invalid ID 003 for the 
source ip: '2.2.2.2'.

If you see those messages, check the previous steps. But if no message 
appears in the manager, packages may not be arriving to the server, so use 
tools such netstat or tcpdump to check your network. By default, OSSEC uses 
the port 1514/UDP.

Hope it helps.

Kind regards,
Victor.


On Saturday, November 5, 2016 at 10:24:25 AM UTC+1, vi...@acpl.com wrote:
>
> Hi,
>
> Can you help me with detailed information (Does the IP address of the 
> packets from this agent (as seen with tcpdump on the OSSEC server) match 
> the IP address in client.keys on the server). I am new to this product.
>
> Regards
> Vipin Hooda  
>
> On Tuesday, October 25, 2016 at 6:22:45 PM UTC+5:30, dan (ddpbsd) wrote:
>
>> On Tue, Oct 25, 2016 at 8:49 AM,   wrote: 
>> > Hi, 
>> > 
>> > Agent to server communication issue is occurring on multiple machines 
>> and 
>> > below logs are getting generated on client machine. We have requested 
>> > customer to check packet drop on firewall but according to customer 
>> there is 
>> > no packet drop on firewall for client machines. 
>> > 
>> > 2016/10/25 16:33:19 ossec-agent(4101): WARN: Waiting for server reply 
>> (not 
>> > started). Tried: 'x.x.x.x'. 
>> > 2016/10/25 17:00:03 ossec-agent: INFO: Trying to connect to server 
>> > (x.x.x.x:1514). 
>> > 2016/10/25 17:00:03 ossec-agent: INFO: Using IPv4 for: x.x.x.x 
>> > 
>>
>> Are there any log messages related to this agent in the ossec.log on the 
>> server? 
>> Does the IP address of the packets from this agent (as seen with 
>> tcpdump on the OSSEC server) match the IP address in client.keys on 
>> the server? 
>>
>> > Kindly help.. 
>> > 
>> > Regards 
>> > Vipin 
>> > 
>> > -- 
>> > 
>> > --- 
>> > 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] ossec-authd TLS1.2 only

[Victor Fernandez]

Hi,

OSSEC v2.8.3 uses the method SSLv23, that is version-flexible and 
negotiates the highest protocol mutually supported by the manager and the 
agent, preferably TLS v1.2.

The new OSSEC v2.9 will use the method TLSv12, that forces to establish the 
TLS v1.2 protocol and rejects the connection if one of the peers doesn't 
support it.

Best regards.
Victor.


On Thursday, November 3, 2016 at 5:29:33 PM UTC+1, dan (ddpbsd) wrote:
>
> On Thu, Nov 3, 2016 at 12:18 PM, john homer alvero  > wrote: 
> > Hello, 
> > 
> > Is there a way for ossec-authd to establish TLS1.2 only? The reason im 
> > asking is that our vulnerability scanner is flagging the ossec-authd 
> port 
> > 1515 as insecure because of support for RC4 and other non-tls1.2 
> protocols. 
> > 
>
> You'll have to modify the source. 
>
> > -- 
> > 
> > --- 
> > 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] Re: ossec-syscheckd realtime scanning does not detect file integrity changes when rootcheck is enabled

[Victor Fernandez]

Hi Liam,

unfortunately Syscheck and Rootcheck features are run in the same process 
and can't work together (at the same time). In short, the process works 
looping over three steps:

   1. Complete Syscheck scan.
   2. Rootcheck test.
   3. Real-time Syscheck monitoring.

So, every file changed during the Rootcheck scan should be checked just 
after Rootcheck ends, but events aren't being lost.


The setting  doesn't work for that. This option must be at the 
manager (not the agent) and, when set to yes, makes it to discard any 
modified file event if that file has been changed more that 3 times, so 
files that change too often won't trigger an alert.


Best regards,

Victor.


On Wednesday, October 19, 2016 at 4:29:45 AM UTC+2, Liam Curtis wrote:
>
> But Alsoany way to speed up the PID_CHECK? seems to take a very long 
> time to finish, during which realtime monitoring does not work.
>
> On Tuesday, October 18, 2016 at 10:22:11 PM UTC-4, Liam Curtis wrote:
>>
>> Well think I got it...details here:
>>
>> https://github.com/ossec/ossec-hids/issues/973
>>
>> seems like  was biting mealso check_pids on rootkit 
>> taking forever to process, so between the two
>>
>> Hopefully this all helps someone down the road.
>>
>>
>> On Tuesday, October 18, 2016 at 8:32:27 PM UTC-4, Liam Curtis wrote:
>>>
>>> Hello all,
>>>
>>> Enjoying getting to know ossec deeper than when I have used in the past. 
>>> Unfortunately, have run into an issue with realtime file integrity 
>>> checking. This also happens on other machines with 2.8 debian package or by 
>>> compiling from latest wazuh source or ossec-hids source. Have tried on 
>>> ubuntu 16.04 and 14.04. 
>>>
>>> With rootcheck disabled, realtime detection works instantly and without 
>>> a hitch, but with rootcheck enabled, I get sporadic results...alert is 
>>> delayed or does not occur at all.
>>>
>>> I can see from strace of ossec-syscheckd that rootcheck gets quite busy 
>>> checking PIDS
>>>
>>>
>>> Is this a known issue? Thank you 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.
For more options, visit https://groups.google.com/d/optout.

[ossec-list] Re: Unexpected FIM behavior

[Victor Fernandez]

Hi Matt,

As we can see, Syscheck isn't very accurate with time for three main 
reasons:

   1. In order not to impact the system performance, Syscheck sleeps two 
   seconds for every 15 checked files. You can change this by changing the 
   settings "syscheck.sleep" and "syscheck.sleep_after" at file 
   *internal_options.conf*. For example, you can set "syscheck.sleep=0" in 
   a testing environment. I don't recommend you to set this value in a 
   production environment, although you can reduce the sleep time to 1 second 
   or increase the sleep_after to 50 files.
   2. After the Syscheck scan, the Rootcheck scan gets launched, and the 
   real-time monitor doesn't work until Rootcheck has ended.
   3. Sometimes Syscheck sleeps 5 minutes after a complete cycle 
   (syscheck+rootcheck+realtime monitoring).

I saw a little misconfiguration in your ossec.conf file: settings 
 and  are OK but they must be at the manager, 
not at the agent.


By last, note that the first Syscheck scan will never produce neither 
alerts about new files nor file changes reports, this is because Syscheck 
generates and sends a database to the server at each scan. The manager 
works by analyzing the differences between different versions of the 
database, but the first time the manager has no database and can't produce 
alerts.


Hope it helps.

Best regards,


Victor.


On Saturday, October 15, 2016 at 1:10:25 AM UTC+2, Matt wrote:
>
> I've changed the scan frequency to 40 minutes, and realtime isn't working. 
> I've edited files 2 times, nothing. Hopefully it at least fires off when 
> the next scan happens.
>
>
>
> On Friday, October 14, 2016 at 11:06:53 AM UTC-7, Matt wrote:
>
>> Hello,
>>
>> I just installed OSSEC in the Azure space, HIDS seems ok but FIM isn't 
>> behaving consistently.
>>
>> First realtime monitoring simply isn't working. FIM only seem to work 
>> when the scan runs, which I have set to 10 minutes for testing. Second I 
>> only seem to get a fraction of the changes I've made. For testing I have 4 
>> folder, and I make 2 changes in each folder, usually an edit and a delete 
>> and/or add. I just did that 2 time sin the last hour, so 16 changes, and I 
>> received only alerts for 3 of those changes.
>>
>> The OSSEC Manager server is CentOS, the agent is Windows Server 2012 R2. 
>> The agent does say "INFO: Real time file monitoring started.".
>>
>> Following are the configs for the manager server and the agent server. Is 
>> there something I am missing? 
>>
>> Manager
>>
>> 
>>   
>> yes
>> 500
>> reda...@redacted.com 
>> redacted.redacted.com
>> reda...@redacted.com 
>> yes
>>   
>>
>> Agent, yes the lines are intentionally each a little different for the 
>> directories to monitor while fiddling with this. If one is wrong please let 
>> me know.
>>
>>   
>>   
>>   
>> 
>> 600
>> yes
>> no
>> 
>> no  
>>
>> C:\TestOSS1
>> C:\TestOSS2
>> > realtime="yes">C:\TestOSS3
>> > check_all="yes">C:\TestOSS4
>>
>> 
>> %WINDIR%/win.ini
>> %WINDIR%/system.ini
>>
>> Thanks,
>> Matt
>>
>>

-- 

--- 
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: Question:Edit/change agent's IP Address

[Victor Fernandez]

Hi,

Do you refer to changing the agent's IP on registering at manage_agents?

In that case you may use the word *"any"* when the program asks for the IP 
address:

$ sudo /var/ossec/bin/manage_agents 

 
>

> * OSSEC HIDS v2.9.0 Agent manager. *
> * The following options are available: *
> 
>(A)dd an agent (A).
>(E)xtract key for an agent (E).
>(L)ist already added agents (L).
>(R)emove an agent (R).
>(Q)uit.
> Choose your action: A,E,L,R or Q: A
>
> - Adding a new agent (use '\q' to return to the main menu).
>   Please provide the following:
>* A name for the new agent: TestAgent
>* The IP Address of the new agent: any
>* An ID for the new agent[001]: 
>

This way the manager will always accept the client (if the agent's name and 
key match) no matter the IP address.

Hope it helps. 

Best regards,
Victor.


On Friday, October 14, 2016 at 8:47:43 PM UTC+2, Tristan wrote:
>
>
>
> On Tuesday, 28 September 2010 22:48:23 UTC-5, Mike Smith wrote:
>>
>> Hello,
>>
>> Can you edit or change an Agent's IP Address if it has changed.
>> Either Windows or Linux?
>>
>> Can you use OSSEC on a DHCP client or only Static IP Addressed Servers?
>>
>> Thanks,
>>
>> Mike
>>
>
>
> Hi Mike.
>
> I work on Datto problems often as we use them for our clients at our IT 
> Office. I found out we do not have the rights to make changes to Agent ip 
> addresses once they are already made. So, you have two options...1) call 
> Datto to have them do it on their back end...2) remove and setup the agents 
> again from scratch. Sucks but that is all you can do.
>
> Tristan 
>

-- 

--- 
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 you explain remoted.recv_counter_flush and remoted.comp_average_printout?

[Victor Fernandez]

Hi Jon,

these settings belong to arriving messages management. When agents delivery 
messages to the manager, Remoted decrypts, decompress and checks the 
counter from every message.

OSSEC saves the counters on files at /var/ossec/queue/rids in order to 
reload them when the manager is restarted, but it doesn't do it for every 
message, but each "*recv_counter_flush*". So, by default, OSSEC saves the 
counters every 128 messages.

The "*comp_average_printout*" setting is used to print statistics about 
compression on the OSSEC log, so every 19.999 messages OSSEC will print the 
total size of compressed and uncompressed data, as well as compression rate.

Hope it helps.
Victor.


On Tuesday, October 11, 2016 at 9:01:53 PM UTC+2, Jon Goodgion wrote:
>
> I would be super grateful if someone could explain what the 
> *remoted.recv_counter_flush* and *remoted.comp_average_printout *options 
> signify in the internal_options.conf file.
>
> By default they are set to 128 and 1 respectively. How will it affect 
> the system if I raise or lower these values?
>
> I appreciate your 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.

[ossec-list] Re: Simultaneous Events at 25 EPS, but Missing Alerts

[Victor Fernandez]

Hi Jon,

OSSEC connects through UDP protocol, that doesn't guarantee that messages 
arrive in the same order they were delivered.

In order to prevent replay attacks, OSSEC verifies the counter from every 
message. I think there is a network issue, perhaps congestion, so messages 
arrive disordered.
In your case, disabling remoted.verity_msg_id is a good solution.

Best regards,
Victor.


On Tuesday, October 11, 2016 at 8:57:26 PM UTC+2, Jon Goodgion wrote:
>
> Hey there! I think it's actually due to the *remoted.verify_msg_id* 
> option in internal_options.conf
>
> Once I turned this off, messages were coming in out of order, but all 
> messages were getting received!
>
> On Tuesday, October 4, 2016 at 5:15:25 AM UTC-4, Pedro S wrote:
>>
>> Hi Jon,
>>
>> This is an interesting test, I think we can get a lot of useful 
>> information from here.
>>
>> On my experience probably the bottleneck is on remoted socket/buffer or 
>> logcollector speed performance to read each log line.
>>
>> For Remoted, try to enable debug mode at the agent, internal_options.conf 
>> file, remoted.debug=2, and agent.debug=2. You will find at ossec.log each 
>> line read by logcollector and sent to remoted, this way we can figure out 
>> if the problem is related to gathering/sending or lately 
>> receiving/proccesing.
>>
>> On my tests I can see how everything is being pushed, but just a few 
>> events on archives are displayed, I think OSSEC also have some protection 
>> for multiple identical messages.
>>
>> 2016/10/04 11:07:39 ossec-agent: DEBUG: Sending message to server: 
>>> 'test55'
>>> 2016/10/04 11:07:39 ossec-logcollector: DEBUG: Reading syslog message: 
>>> 'test55'
>>> 2016/10/04 11:07:39 ossec-agent: DEBUG: Attempting to send message to 
>>> server.
>>> 2016/10/04 11:07:39 ossec-agent: DEBUG: Sending message to server: 
>>> 'test55'
>>> 2016/10/04 11:07:39 ossec-logcollector: DEBUG: Reading syslog message: 
>>> 'test55'
>>> 2016/10/04 11:07:39 ossec-agent: DEBUG: Attempting to send message to 
>>> server.
>>> 2016/10/04 11:07:39 ossec-agent: DEBUG: Sending message to server: 
>>> 'test55'
>>> 2016/10/04 11:07:39 ossec-logcollector: DEBUG: Reading syslog message: 
>>> 'test55'
>>> 2016/10/04 11:07:39 ossec-agent: DEBUG: Attempting to send message to 
>>> server.
>>> 2016/10/04 11:07:39 ossec-agent: DEBUG: Sending message to server: 
>>> 'test55'
>>> 2016/10/04 11:07:39 ossec-logcollector: DEBUG: Reading syslog message: 
>>> 'test55'
>>> 2016/10/04 11:07:39 ossec-agent: DEBUG: Attempting to send message to 
>>> server.
>>> 2016/10/04 11:07:39 ossec-agent: DEBUG: Sending message to server: 
>>> 'test55'
>>> 2016/10/04 11:07:39 ossec-agent: DEBUG: Attempting to send message to 
>>> server.
>>> 2016/10/04 11:07:39 ossec-agent: DEBUG: Sending message to server: 
>>> '--MARK--: '
>>> 2016/10/04 11:07:43 ossec-agent: DEBUG: Attempting to send message to 
>>> server.
>>
>>
>>
>>
>>
>> On Monday, October 3, 2016 at 8:27:04 PM UTC+2, Jon Goodgion wrote:
>>>
>>> I've been curious about the performance of OSSEC in a server/agent 
>>> architecture, so I have been emulating simultaneous events on a single 
>>> agent by appending log entries to the agent's syslog.
>>>
>>> Using a shell script for loop on the agent, I append 25 consecutive logs 
>>> that match the format of a telnet failed password log. I figured 25 EPS 
>>> should be easily captured by OSSEC.
>>>
>>> However, on the server, (after enabling logall to archives), it doesn't 
>>> seem like it is processing all the logs. 
>>> /var/ossec/logs/archives/archives.log shows:
>>>
>>> 2016 Oct 03 13:53:31 (agent101) 192.168.0.101->/var/log/syslog Oct 1 
>>> 14:15:55 queen telnetd[*1*]: refused connect from 81.215.42.24
>>>
>>> 2016 Oct 03 13:53:31 (agent101) 192.168.0.101->/var/log/syslog Oct 1 
>>> 14:15:55 queen telnetd[*13*]: refused connect from 81.215.42.158
>>>
>>> 2016 Oct 03 13:53:31 (agent101) 192.168.0.101->/var/log/syslog Oct 1 
>>> 14:15:55 queen telnetd[14]: refused connect from 81.215.42.69
>>>
>>> 2016 Oct 03 13:53:31 (agent101) 192.168.0.101->/var/log/syslog Oct 1 
>>> 14:15:55 queen telnetd[15]: refused connect from 81.215.42.32
>>>
>>> 2016 Oct 03 13:53:31 (agent101) 192.168.0.101->/var/log/syslog Oct 1 
>>> 14:15:55 queen telnetd[16]: refused connect from 81.215.42.41
>>>
>>> 2016 Oct 03 13:53:31 (agent101) 192.168.0.101->/var/log/syslog Oct 1 
>>> 14:15:55 queen telnetd[17]: refused connect from 81.215.42.74
>>>
>>> 2016 Oct 03 13:53:31 (agent101) 192.168.0.101->/var/log/syslog Oct 1 
>>> 14:15:55 queen telnetd[18]: refused connect from 81.215.42.32
>>>
>>> 2016 Oct 03 13:53:31 (agent101) 192.168.0.101->/var/log/syslog Oct 1 
>>> 14:15:55 queen telnetd[19]: refused connect from 81.215.42.222
>>>
>>> 2016 Oct 03 13:53:31 (agent101) 192.168.0.101->/var/log/syslog Oct 1 
>>> 14:15:55 queen telnetd[20]: refused connect from 81.215.42.25
>>>
>>> 2016 Oct 03 13:53:31 (agent101) 192.168.0.101->/var/log/syslog Oct 1 
>>> 14:15:55 queen telnetd[21]: refused connect 

Re: [ossec-list] Windows Eventlogs

[Victor Fernandez]

Hi Kumar,

please ensure that folders "tmp" and "bookmarks" have total permissions for 
the "SYSTEM" user and the "Administrators" group.

Regarding the usage of Event Channel, it's advisable and almost necessary 
since if your system has certain Windows monitoring events activated —such 
events 5145 and 5156— your agent could get to flood the network.

Best regards.
Victor.


On Tuesday, September 27, 2016 at 9:33:21 PM UTC+2, Kumar G wrote:
>
> Hi Victor,
>
> It took a while for this data. We did the book mark deletion and restarted 
> the agent. Still we see the bookmark messages coming in ossec.log and the 
> log file increase is so high. Easily getting about 30 MB in a week and 
> majority of the logs are these bookmark messages. 
>
> So is it advisable to have the eventchannel way for filtering out event id 
> for Windows eventlogs at agent level?
>
> Thanks
> Kumar
>
> On Friday, 16 September 2016, Victor Fernandez <vic...@wazuh.com 
> > wrote:
>
>> Hi Kumar,
>>
>> The moving error is not usual, the return code 5 refers to an access 
>> denegation. So try to stop the agent, delete the file "C:\Program Files 
>> (x86)\ossec-agent\bookmarks\Security" and re-start the agent.
>>
>> Regarding the 2nd problem seems to be a connection problem between the 
>> agent and the manager. Since the agent "locks" the communication socket, no 
>> other component can send its message and then it prints that error. Please 
>> review the manager IP address and look at the manager's log for any error 
>> referred to the Windows agent.
>>
>> Hope it helps.
>> Best regards.
>>
>> Victor.
>>
>>
>> On Thursday, September 15, 2016 at 8:32:20 PM UTC+2, Kumar G wrote:
>>>
>>> Hi Jesus, 
>>>
>>> Apologize for the late reply. Was away from the OSSEC for a while. 
>>>
>>> The configuration for eventlog ID was implemented however, I started 
>>> getting some of the new message in ossec logs on the agent box. Do you 
>>> think if these are normal?
>>>
>>>
>>> 2016/09/06 07:04:43 ossec-agent(1951): INFO: Analyzing event log: 
>>> 'Application'.
>>> 2016/09/06 07:04:43 ossec-agent(1951): INFO: Analyzing event log: 
>>> 'Security'.
>>> 2016/09/06 07:04:43 ossec-agent(1951): INFO: Analyzing event log: 
>>> 'Security'.
>>> 2016/09/06 07:04:43 ossec-agent(1951): INFO: Analyzing event log: 
>>> 'System'.
>>> 2016/09/06 07:04:43 ossec-agent: INFO: Started (pid: 3572).
>>> 2016/09/06 07:04:45 ossec-agent: INFO: Lock free. Continuing...
>>> 2016/09/06 07:04:59 ossec-agent: ERROR: Could not move 
>>> (tmp/Security-a11968) to (bookmarks/Security) which returned (5)
>>> 2016/09/06 07:04:59 ossec-agent: ERROR: Could not rename_ex() temporary 
>>> bookmark (tmp/Security-a11968) to (bookmarks/Security) for (Security)
>>> 2016/09/06 07:05:01 ossec-agent: ERROR: Could not move 
>>> (tmp/Security-a20532) to (bookmarks/Security) which returned (5)
>>> 2016/09/06 07:05:01 ossec-agent: ERROR: Could not rename_ex() temporary 
>>> bookmark (tmp/Security-a20532) to (bookmarks/Security) for (Security)
>>> 2016/09/06 07:05:21 ossec-agent: ERROR: Could not move 
>>> (tmp/Security-a14540) to (bookmarks/Security) which returned (5)
>>> 2016/09/06 07:05:21 ossec-agent: ERROR: Could not rename_ex() temporary 
>>> bookmark (tmp/Security-a14540) to (bookmarks/Security) for (Security)
>>> 2016/09/06 07:05:35 ossec-agent: INFO: Starting syscheck scan 
>>> (forwarding database).
>>> 2016/09/06 07:05:35 ossec-agent: INFO: Starting syscheck database 
>>> (pre-scan).
>>> 2016/09/06 07:05:37 ossec-agent: INFO: Initializing real time file 
>>> monitoring (not started).
>>> 2016/09/06 07:05:37 ossec-agent: INFO: Real time file monitoring started.
>>> 2016/09/06 07:05:37 ossec-agent: INFO: Finished creating syscheck 
>>> database (pre-scan completed).
>>> 2016/09/06 07:05:47 ossec-agent: INFO: Ending syscheck scan (forwarding 
>>> database).
>>> 2016/09/06 07:05:59 ossec-agent: ERROR: Could not move 
>>> (tmp/Security-a20532) to (bookmarks/Security) which returned (5)
>>> 2016/09/06 07:05:59 ossec-agent: ERROR: Could not rename_ex() temporary 
>>> bookmark (tmp/Security-a20532) to (bookmarks/Security) for (Security)
>>> 2016/09/06 07:05:59 ossec-agent: ERROR: Could not move 
>>> (tmp/Security-a14540) to (bookmarks/Security) which returned (5)
>>> 2016/09/06 07:05:59 ossec-agent: ERROR: Could not renam

[ossec-list] Re: OSSEC - sudo

[Victor Fernandez]

Hi Kumar,

The ossec group is intended to access shared files and write only onto logs 
and queues, but not on settings and rules files. Nevertheless, if you need 
to write those files, it's more secure to create a new user and add it to 
the ossec group and give it the needed permissions that run maintenance 
scripts as root, IMHO.

So I'd make the following changes:

$ adduser  ossec

If you need to modify the rules files:

$ chmod g+w /var/ossec/rules/*.xml

And/or, if you need to create or delete rules files:

$ chmod g+w /var/ossec/rules

Hope it helps.
Victor.

On Tuesday, September 27, 2016 at 9:26:49 PM UTC+2, Kumar G wrote:
>
> Hi Dan, 
>
> The main concern was we have to get the sudo command in place for 
> maintaining ossec. With our setup the sudo commands started growing and 
> increasing with any additional customizations. We are reluctant to change 
> the permissions for files / directory, however checking if we are able to 
> do them by any alternatives. 
>
>
>
> Thanks
> Kumar
>
> On Tuesday, 27 September 2016, dan (ddp)  
> wrote:
>
>> On Thu, Sep 15, 2016 at 2:38 PM, Kumar G  wrote:
>> > Hi team,
>> >
>> > We are in the process of getting the sudo rules worked out for OSSEC
>> > environment. However there came up a question like if we can have the 
>> ossec
>> > user have read/write access on them.(eg: /var/ossec/rules, 
>> /var/ossec/etc -
>> > ossec accountshould have the write permission). Is it advisable to 
>> change
>> > the chmod permissions of files / folders under /var/ossec directory?
>> >
>>
>> I prefer to not let the ossec user have write permissions to anything
>> it doesn't need to write to.
>> There's no reason for the ossec user to write to the rules.
>>
>> > Any one has the list of sudo commands required on the OSSEC server / 
>> agent
>> > t?
>> >
>>
>> What problem are you trying to solve exactly?
>>
>> >
>> > Thanks
>> > Kumar
>> >
>> > --
>> >
>> > ---
>> > 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.

Re: [ossec-list] Re: How to change the OSSEC installation directory in windows

[Victor Fernandez]

Hi Dustin.

Since OSSEC is installed onto another partition, and I suppose that it 
won't be overwritten when you recreate the C: partition, the OSSEC settings 
and the key will remain unaltered.

On the other hand, we are working on a Auth version for Windows clients, so 
you are able to request a new key to the manager when the system boots or 
if you find a connection issue.

Regards.
Victor.


On Thursday, September 29, 2016 at 7:53:26 PM UTC+2, jose wrote:
>
> Hi Dustin
>
> You can use Wazuh API and one PowerShell script.
>
>
> http://blog.wazuh.com/automatically-deploying-ossec-to-windows-using-wazuh-api/
>
> And in our documentation you have the procedure to install Wazuh RESTful 
> API
>
> http://documentation.wazuh.com/en/latest/ossec_api.html
>
> I hope this helps.
>
> Regards
> ---
> Jose Luis Ruiz
> Wazuh Inc.
> jo...@wazuh.com 
>
> On September 29, 2016 at 12:55:19 PM, Dustin Church (chur...@gmail.com 
> ) wrote:
>
> Victor, 
>
> I currently have 78 servers that will be recreated nightly using a single 
> image. I understand that I can install OSSEC to a secondary partition, but 
> how do I handle the keys for each server that is created from the image, 
> and ensure proper communication after the image is built without having to 
> manually enter the server IP and key for the server at boot time?
>
> On Friday, September 23, 2016 at 4:22:59 AM UTC-6, Victor Fernandez wrote: 
>>
>> You may follow these steps:
>>
>>1. Run the OSSEC installer and click "Next" until you reach the 
>>screen "Choose the Install Location". 
>>2. Select the directory where you want to install OSSEC in (another 
>>disk partition).
>>3. Finish the installation steps. 
>>4. At this point, OSSEC has been installed into the partition that 
>>you chose, but it has be also registered a service on Windows. 
>>5. Now create the Windows C: drive image (which now contains the 
>>OSSEC agent service). 
>>6. You can configure the agents independently.
>>
>> Kind regards.
>> Victor.
>>
>>
>>
>> On Thursday, September 22, 2016 at 12:00:29 PM UTC+2, Eero Volotinen 
>> wrote: 
>>>
>>> How about modifying the installation package?
>>>
>>> Eero
>>>
>>> 2016-09-22 12:56 GMT+03:00 Victor Fernandez <vic...@wazuh.com>:
>>>
>>>> Hi,
>>>>
>>>> when you run the OSSEC installer for Windows, you can choose the 
>>>> location where OSSEC will be installed. This shouldn't be a problem.
>>>>
>>>> Since OSSEC registers a background service on Windows, you should first 
>>>> install OSSEC into another partition and then create the C:\ drive image.
>>>>
>>>> Hope it helps.
>>>> Best regards.
>>>>
>>>> Victor. 
>>>>
>>>>
>>>>
>>>> On Thursday, September 22, 2016 at 10:13:30 AM UTC+2, vikas wrote: 
>>>>>
>>>>> Hello all, 
>>>>>
>>>>> We have a group of servers where the C:/ drive gets re-imaged daily 
>>>>> with a standard image. Since its going to be same image that all the 
>>>>> servers use, not sure how to make OSSEC part of that image and avoid 
>>>>> agent-server registration issues. So we wanted to install it on a 
>>>>> different 
>>>>> drive to avoid the complications, but couldn't find an option to specify 
>>>>> custom path for installation. Is it possible? 
>>>>>
>>>>> Thank you for your 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+...@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.

Re: [ossec-list] OpenBSD 6 - Real Monitoring

[Victor Fernandez]

Hello,

I've never done this on OpenBSD, but try to force the inotify support with 
Make:

cd src
make TARGET=agent USE_INOTIFY=yes

Hope it helps.
Regards.


On Friday, September 30, 2016 at 12:38:30 AM UTC+2, dan (ddpbsd) wrote:
>
> On Sep 29, 2016 4:10 PM, "R0me0 ***"  
> wrote:
> >
> > Hello guys.
> >
> > I'm trying to use real monitoring.
> >
> > I have installed inotify-tools from OpenBSD packages 
> >
> > Initially I guess something related with run_realtime.c and I point 
> inotify.h path.
> >
> > But I still without be able to use Real monitoring with the follow error 
> in ossec.conf
> >
> > ( OpenBSD - OSSEC AGENT )
> >
> > ossec-syscheckd: WARN: Ignoring flag for real time monitoring on 
> directory: '/etc/pf'.
> >
> > Anyone has this setup working ? Any directions will be really appreciated
> >
> > Thanks in advance,
> >
>
> I spent some time messing with it awhile back, but never got it working. 
> There are some Makefile changes you have to make, as well as possible src 
> changes.
>
> >
> >
> >
> > -- 
> >
> > --- 
> > 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] Re: Can I build the OSSEC server without the three GeoIP packages?

[Victor Fernandez]

Hi Shawn,

you can compile OSSEC from sources without enabling GeoIP by following 
these steps:

   - Download OSSEC source code: git clone 
   https://github.com/ossec/ossec-hids.git
   - Install GCC compiler and Make tool if you haven't them:
  - sudo apt-get install gcc make [Debian/Ubuntu]
  - sudo yum install gcc make [CentOS]
  - sudo dnf install gcc make [Fedora]
   - Compile OSSEC: make -C src TARGET=server
   - Install OSSEC: sudo ./install.sh

This way, OSSEC won't include GeoIP support.


Hope it helps.

Best regards.

Victor.


On Friday, September 23, 2016 at 5:01:43 PM UTC+2, Shawn Wiley wrote:
>
>
>  What I was trying to say...
>  
> Is there a way to install the OSSEC server package without the three GeoIP 
> packages? Also if I do not turn on the GeoIP functionality in the 
> ossec.conf file will the packages just sit dormant? I want to install the 
> least amount of additional packages to my web server as possible, my 
> thoughts are why introduce any additional files which may be used to 
> exploit the server..
>
>>  
> Thanks,
> Shawn 
>

-- 

--- 
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: How to change the OSSEC installation directory in windows

[Victor Fernandez]

You may follow these steps:

   1. Run the OSSEC installer and click "Next" until you reach the screen 
   "Choose the Install Location".
   2. Select the directory where you want to install OSSEC in (another disk 
   partition).
   3. Finish the installation steps.
   4. At this point, OSSEC has been installed into the partition that you 
   chose, but it has be also registered a service on Windows.
   5. Now create the Windows C: drive image (which now contains the OSSEC 
   agent service).
   6. You can configure the agents independently.
   
Kind regards.
Victor.



On Thursday, September 22, 2016 at 12:00:29 PM UTC+2, Eero Volotinen wrote:
>
> How about modifying the installation package? 
>
> Eero
>
> 2016-09-22 12:56 GMT+03:00 Victor Fernandez <vic...@wazuh.com 
> >:
>
>> Hi,
>>
>> when you run the OSSEC installer for Windows, you can choose the location 
>> where OSSEC will be installed. This shouldn't be a problem.
>>
>> Since OSSEC registers a background service on Windows, you should first 
>> install OSSEC into another partition and then create the C:\ drive image.
>>
>> Hope it helps.
>> Best regards.
>>
>> Victor.
>>
>>
>>
>> On Thursday, September 22, 2016 at 10:13:30 AM UTC+2, vikas wrote:
>>>
>>> Hello all,
>>>
>>> We have a group of servers where the C:/ drive gets re-imaged daily with 
>>> a standard image. Since its going to be same image that all the servers 
>>> use, not sure how to make OSSEC part of that image and avoid agent-server 
>>> registration issues. So we wanted to install it on a different drive to 
>>> avoid the complications, but couldn't find an option to specify custom path 
>>> for installation. Is it possible? 
>>>
>>> Thank you for your 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+...@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: How to change the OSSEC installation directory in windows

[Victor Fernandez]

Hi,

when you run the OSSEC installer for Windows, you can choose the location 
where OSSEC will be installed. This shouldn't be a problem.

Since OSSEC registers a background service on Windows, you should first 
install OSSEC into another partition and then create the C:\ drive image.

Hope it helps.
Best regards.

Victor.


On Thursday, September 22, 2016 at 10:13:30 AM UTC+2, vikas wrote:
>
> Hello all,
>
> We have a group of servers where the C:/ drive gets re-imaged daily with a 
> standard image. Since its going to be same image that all the servers use, 
> not sure how to make OSSEC part of that image and avoid agent-server 
> registration issues. So we wanted to install it on a different drive to 
> avoid the complications, but couldn't find an option to specify custom path 
> for installation. Is it possible? 
>
> Thank you for your 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.

[ossec-list] Re: Question on agent authentication and use of counters

[Victor Fernandez]

Hi Abhi.

OSSEC counters were designed to avoid a repetition attack and consists on 
numbering messages from agents and manager. The manager has a file "
/var/ossec/queue/rids/sender_counter" where stores its own counter. Just as 
the server checks the agent counter, the agent also checks the manager 
counter. Every machine (agents and manager) only accepts a message if its 
counter is greater than the stored number.

In this case, if you migrated your manager but you didn't copy the rids 
folder, the following occurred:

   - Since the agents' counters didn't exist, the manager expected a 
   message numbered from 0. If it received the number "1000" (for example), it 
   toke it as correct and updated the agent's counter file.
   - But agents kept the manager's counter (for example, 500). The manager 
   started to number its own messages from 0. When it tried to send the 
   connection confirmation message to the agent, this one rejected the message 
   because the counter was lower than the stored counter. If you'd do nothing, 
   some later time the manager would reach the counter 500 and could connect 
   with agents.

I recommend you copy the file "/var/ossec/queue/rids/sender_counter" from 
the manager to a new instance the next time you migrate a server. On the 
other hand, you can also delete the agents' counter folder.


Kind regards.


Victor Fernandez.



On Thursday, September 15, 2016 at 9:08:46 PM UTC+2, Abhi wrote:
>
> Hi,
>
> We recently migrated one of our OSSEC instance to a new server. We are 
> using Linux(CentOS) as the platform. Post migration, we noticed that none 
> of the agents were connected to the server and agents had the following 
> error in the logs:
>  
> 2016/09/15 09:05:56 ossec-agentd: INFO: Trying to connect to server 
> (X.X.X.X:1514).
> 2016/09/15 09:05:56 ossec-agentd: INFO: Using IPv4 for: X.X.X.X .
> 2016/09/15 09:05:57 ossec-agentd(1214): WARN: Problem receiving message 
> from X.X.X.X.
> 2016/09/15 09:06:06 ossec-agentd(1214): WARN: Problem receiving message 
> from X.X.X.X
>
> We were able to fix this by removing the files under /var/ossec/queue/rids 
> ( on the agent ), corresponding agent file on server then doing the 
> restarts. Agent immediately connected after this, but I wanted to know 
> which steps could have caused this to happen? There are 2 agents which did 
> connect by themselves without needing the fix, but it took few hours. 
> Others are still in the error state and most likely will require the manual 
> correction.
>
> Entire directory structure was copied as it is from the old server, 
> followed by OSSEC install over those files by choosing upgrade option. The 
> content and permissions on these RIDS files were not changed during the 
> copy and IP address for the server is the same.
>
> It would be good to know what goes on between agent-server as far as these 
> counters are concerned and if there is a way to avoid this manual fix?
>
> Many Thanks,
>
> ~ Abhi
>
>
>

-- 

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

[Victor Fernandez]

Hi Kumar,

The moving error is not usual, the return code 5 refers to an access 
denegation. So try to stop the agent, delete the file "C:\Program Files 
(x86)\ossec-agent\bookmarks\Security" and re-start the agent.

Regarding the 2nd problem seems to be a connection problem between the 
agent and the manager. Since the agent "locks" the communication socket, no 
other component can send its message and then it prints that error. Please 
review the manager IP address and look at the manager's log for any error 
referred to the Windows agent.

Hope it helps.
Best regards.

Victor.


On Thursday, September 15, 2016 at 8:32:20 PM UTC+2, Kumar G wrote:
>
> Hi Jesus, 
>
> Apologize for the late reply. Was away from the OSSEC for a while. 
>
> The configuration for eventlog ID was implemented however, I started 
> getting some of the new message in ossec logs on the agent box. Do you 
> think if these are normal?
>
>
> 2016/09/06 07:04:43 ossec-agent(1951): INFO: Analyzing event log: 
> 'Application'.
> 2016/09/06 07:04:43 ossec-agent(1951): INFO: Analyzing event log: 
> 'Security'.
> 2016/09/06 07:04:43 ossec-agent(1951): INFO: Analyzing event log: 
> 'Security'.
> 2016/09/06 07:04:43 ossec-agent(1951): INFO: Analyzing event log: 'System'.
> 2016/09/06 07:04:43 ossec-agent: INFO: Started (pid: 3572).
> 2016/09/06 07:04:45 ossec-agent: INFO: Lock free. Continuing...
> 2016/09/06 07:04:59 ossec-agent: ERROR: Could not move 
> (tmp/Security-a11968) to (bookmarks/Security) which returned (5)
> 2016/09/06 07:04:59 ossec-agent: ERROR: Could not rename_ex() temporary 
> bookmark (tmp/Security-a11968) to (bookmarks/Security) for (Security)
> 2016/09/06 07:05:01 ossec-agent: ERROR: Could not move 
> (tmp/Security-a20532) to (bookmarks/Security) which returned (5)
> 2016/09/06 07:05:01 ossec-agent: ERROR: Could not rename_ex() temporary 
> bookmark (tmp/Security-a20532) to (bookmarks/Security) for (Security)
> 2016/09/06 07:05:21 ossec-agent: ERROR: Could not move 
> (tmp/Security-a14540) to (bookmarks/Security) which returned (5)
> 2016/09/06 07:05:21 ossec-agent: ERROR: Could not rename_ex() temporary 
> bookmark (tmp/Security-a14540) to (bookmarks/Security) for (Security)
> 2016/09/06 07:05:35 ossec-agent: INFO: Starting syscheck scan (forwarding 
> database).
> 2016/09/06 07:05:35 ossec-agent: INFO: Starting syscheck database 
> (pre-scan).
> 2016/09/06 07:05:37 ossec-agent: INFO: Initializing real time file 
> monitoring (not started).
> 2016/09/06 07:05:37 ossec-agent: INFO: Real time file monitoring started.
> 2016/09/06 07:05:37 ossec-agent: INFO: Finished creating syscheck database 
> (pre-scan completed).
> 2016/09/06 07:05:47 ossec-agent: INFO: Ending syscheck scan (forwarding 
> database).
> 2016/09/06 07:05:59 ossec-agent: ERROR: Could not move 
> (tmp/Security-a20532) to (bookmarks/Security) which returned (5)
> 2016/09/06 07:05:59 ossec-agent: ERROR: Could not rename_ex() temporary 
> bookmark (tmp/Security-a20532) to (bookmarks/Security) for (Security)
> 2016/09/06 07:05:59 ossec-agent: ERROR: Could not move 
> (tmp/Security-a14540) to (bookmarks/Security) which returned (5)
> 2016/09/06 07:05:59 ossec-agent: ERROR: Could not rename_ex() temporary 
> bookmark (tmp/Security-a14540) to (bookmarks/Security) for (Security)
> 2016/09/06 07:06:07 ossec-agent: ERROR: Could not move 
> (tmp/Security-a14540) to (bookmarks/Security) which returned (5)
> 2016/09/06 07:06:07 ossec-agent: ERROR: Could not rename_ex() temporary 
> bookmark (tmp/Security-a14540) to (bookmarks/Security) for (Security)
> 2016/09/06 07:06:37 ossec-agent: ERROR: Could not move 
> (tmp/Security-a20532) to (bookmarks/Security) which returned (5)
> 2016/09/06 07:06:37 ossec-agent: ERROR: Could not rename_ex() temporary 
> bookmark (tmp/Security-a20532) to (bookmarks/Security) for (Security)
> 2016/09/06 07:06:55 ossec-agent: ERROR: Could not move 
> (tmp/Security-a20532) to (bookmarks/Security) which returned (5)
> 2016/09/06 07:06:55 ossec-agent: ERROR: Could not rename_ex() temporary 
> bookmark (tmp/Security-a20532) to (bookmarks/Security) for (Security)
> 2016/09/06 07:07:15 ossec-agent: ERROR: Could not move 
> (tmp/Security-a20532) to (bookmarks/Security) which returned (5)
> 2016/09/06 07:07:15 ossec-agent: ERROR: Could not rename_ex() temporary 
> bookmark (tmp/Security-a20532) to (bookmarks/Security) for (Security)
> 2016/09/06 07:07:27 ossec-agent: ERROR: Could not move 
> (tmp/Security-a20532) to (bookmarks/Security) which returned (5)
>
>
> This is another set of logs I see in the ossec.log file. "Error waiting 
> mutex (timeout)"
> 2016/09/06 11:51:46 ossec-agent: INFO: Trying to connect to server 
> (XX.XX.XX.XX:).
> 2016/09/06 11:51:46 ossec-agent: INFO: Using IPv4 for: XX.XX.XX.XX .
> 2016/09/06 11:52:48 ossec-agent: Error waiting mutex (timeout).
> 2016/09/06 11:55:03 ossec-agent: Error waiting mutex (timeout).
> 2016/09/06 11:56:35 ossec-agent: Error waiting mutex (timeout).
> 2016/09/06 11:57:03 ossec-agent(1114): 

[ossec-list] Re: Syscheck - scan only selected extensions

[Victor Fernandez]

Hi,

you can select file extensions easily using wildcards, for example:


  C:\Windows\*.exe,C:\Windows\*.dll


This method works only with files that already exist. If you want to scan 
files that are created after OSSEC starts, you may use  and create 
a regular expression that matches any path except those that end with 
".exe" or ".dll". To do this more easily, the new OSSEC 2.9 and Wazuh 1.2 
will bring a new feature that negates a regex with a "!" symbol, and you 
may use it in the following way:


  C:\Windows
  !.exe$


Hope it helps.
Best regards.


On Thursday, August 4, 2016 at 6:19:42 AM UTC-7, vary...@mail.ru wrote:
>
> Hello!
>
> I want to check on integrity files with selected extensions - .exe, .dll. 
> But in documentation I find only example with ignore function which use 
> sregex or regex. I try this configuration but it does not work:
>
> 
>
> 
> check_all="yes" type="sregex">C:\Windows\,exe|.dll
>
> 
>
> Is there any way to check files with selected extensions in OSSEC?
>
>
>
>
>

-- 

--- 
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: Agents not connecting, traffic visible in tcpdump

[Victor Fernandez]

Hi Cal.

As you can see when an agent connects successfully, the server answers it 
with an UDP message from server:1520 —in your case— to the agent. Usually 
the server prints an error into the log when it receives a bad message 
(unauthorized key, counter error, incorrectly formatted message...) so 
maybe the message couldn't return back to the agent. 

Please check that every message generated by the server is arriving to the 
agent. If it isn't, you may have a network problem. If you don't find such 
messages, please write back to us and copy the remoted log.

Hope it helps.
Kind regards.



On Friday, August 5, 2016 at 2:53:39 PM UTC-7, Cal wrote:
>
> Pedro,
>
> Maybe I spoke too soon. It worked for most of the agents, but I have a few 
> stubborn ones having the same issues. I tried the steps you outline earlier 
> that worked on the other agents, but not on these. Any other ideas for 
> something I could be missing? Thanks again!
>
>
> On Wednesday, August 3, 2016 at 1:48:40 PM UTC-4, Cal wrote:
>>
>> 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.

[ossec-list] Re: Last time agent connected to server

[Victor Fernandez]

Hi Derek.

You can do that by watching the modification time (with ls or stat) of the 
agent's information file at /var/ossec/queue/agent-info. For example, if 
the agent name is "myagent" and the IP is "1.2.3.4", the file will be "
/var/ossec/queue/agent-info/myagent-1.2.3.4".

When an agent sends a keep-alive message (every 10 minutes), its 
corresponding file gets updated. In fact, the agent-control utility reads 
internally the modification time of those files in order to know whether 
agents are connected or disconnected. If it's been more than half hour 
since the last update time, OSSEC assumes that the agent is disconnected.

This is an example to list the agents that have not connected since 2 
months (60 days):

$ find /var/ossec/agent-info/* -mtime +60 -ls

Kind regards.


On Tuesday, August 2, 2016 at 10:52:05 AM UTC-7, Derek Day wrote:
>
> Is there a simple way to show the last time an agent connected to the 
> server? I'm looking for a way to identify agents that haven't been used for 
> say 2 months. 
>

-- 

--- 
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: Syscheck not alerting on realtime scans

[Victor Fernandez]

Hi Daniel.

I had never used  before, but I think it works for weekly scans 
since OSSEC prints this log (even when setting frequency=84800):

2016/08/01 14:27:33 ossec-syscheckd: INFO: Syscheck scan frequency: 604800 
seconds

This amount of time is one week, so I think that  works only for 
weekly scans, and then you should also introduce the the  
parameter, since it appears to have no default value. For example:

1am
monday

I tested that configuration and Syscheck appears to work properly. 

Hope it helps.

Best regards.


On Monday, August 1, 2016 at 7:32:13 AM UTC-7, Daniel Bray wrote:
>
> Can someone verify that all the proper settings are in place to allow for 
> realtime scans on some directories? We are running CentOS 6 servers 
> (manager and agents/clients), and we use the Atomic install method.
>
> Here is the latest available Atomic version installed (also noted inotify 
> is installed)
> $ rpm -qa | egrep "inotify|ossec"
> ossec-hids-2.8.3-53.el6.art.x86_64
> inotify-tools-3.14-1.el6.x86_64
> ossec-hids-client-2.8.3-53.el6.art.x86_64
>
>
> Here is the important part of /var/ossec/etc/shared/agent.conf
> 
>   
> 1am
> 82800
> no
> yes
> no
>
> 
> /bin,/sbin,/usr,/opt
>  report_changes="yes" 
> realtime="yes">/etc,/root,/var/named,/var/www
> ...
>
> Here is the agent /var/ossec/etc/ossec.conf file
> 
>   
> 10.10.10.10
>   
> 
>
> The above exists on all our agents/clients. 
>
> On the manager, it pretty much matches up exactly, with the exception that 
> the server is installed, and not the client:
> $  rpm -qa | egrep "inotify|ossec"
> inotify-tools-3.14-1.el6.x86_64
> ossec-hids-server-2.8.3-53.el6.art.x86_64
> ossec-hids-2.8.3-53.el6.art.x86_64
>
>
> I have gone in an updated all servers (yum -y update) and rebooted to the 
> latest kernel available on CentOS 6. I've waited a few days for the normal 
> scans to complete, and I am seeing alerts for nightly changed files. 
> However, when I run a test on a file that exists in /root or /etc, I never 
> get alerted. The test is simply
> $ sudo vim /etc/hosts.allow
> ...and I add/remove some entries, and :wq out for the update.
>
> After a clean update and reboot, here is the relevant log entries:
> 2016/08/01 14:25:13 ossec-syscheckd: DEBUG: Starting ...
> 2016/08/01 14:25:13 ossec-rootcheck: DEBUG: Starting ...
> 2016/08/01 14:25:13 ossec-rootcheck: Starting queue ...
> 2016/08/01 14:25:13 ossec-syscheckd: INFO: (unix_domain) Maximum send 
> buffer set to: '124928'.
> 2016/08/01 10:25:14 ossec-agentd(4102): INFO: Connected to the server (
> 10.10.10.10:1514).
> 2016/08/01 14:25:19 ossec-logcollector(1950): INFO: Analyzing file: 
> '/var/log/messages'.
> 2016/08/01 14:25:19 ossec-logcollector(1950): INFO: Analyzing file: 
> '/var/log/secure'.
> 2016/08/01 14:25:19 ossec-logcollector(1950): INFO: Analyzing file: 
> '/var/log/maillog'.
> 2016/08/01 14:25:19 ossec-logcollector: INFO: Started (pid: 2120).
> 2016/08/01 14:25:19 ossec-syscheckd: INFO: (unix_domain) Maximum send 
> buffer set to: '124928'.
> 2016/08/01 14:25:19 ossec-syscheckd: INFO: Started (pid: 2124).
> 2016/08/01 14:25:19 ossec-rootcheck: INFO: Started (pid: 2124).
> 2016/08/01 14:25:19 ossec-syscheckd: INFO: Monitoring directory: '/bin'.
> 2016/08/01 14:25:19 ossec-syscheckd: INFO: Monitoring directory: '/sbin'.
> 2016/08/01 14:25:19 ossec-syscheckd: INFO: Monitoring directory: '/usr'.
> 2016/08/01 14:25:19 ossec-syscheckd: INFO: Monitoring directory: '/opt'.
> 2016/08/01 14:25:19 ossec-syscheckd: INFO: Monitoring directory: '/etc'.
> 2016/08/01 14:25:19 ossec-syscheckd: INFO: Monitoring directory: '/root'.
> 2016/08/01 14:25:19 ossec-syscheckd: INFO: Monitoring directory: 
> '/var/named'.
> 2016/08/01 14:25:19 ossec-syscheckd: INFO: Monitoring directory: 
> '/var/www'.
> 2016/08/01 14:25:19 ossec-syscheckd: INFO: Directory set for real time 
> monitoring: '/etc'.
> 2016/08/01 14:25:19 ossec-syscheckd: INFO: Directory set for real time 
> monitoring: '/root'.
> 2016/08/01 14:25:19 ossec-syscheckd: INFO: Directory set for real time 
> monitoring: '/var/named'.
> 2016/08/01 14:25:19 ossec-syscheckd: INFO: Directory set for real time 
> monitoring: '/var/www'.
> 2016/08/01 14:25:33 ossec-syscheckd: Setting SCHED_BATCH returned: 0
>
>
>
> Is there anything obvious that I'm missing in the configs?
>
>
>

-- 

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

[Victor Fernandez]

Hi Graeme.

I agree, it would be great to print on the log that the agent became 
disconnected. The SEC_ERROR definition is shared between manager and 
agents, but it's possible to extend some other messages. In fact, the line 
at sendmsg.c that tests if the agent is disconnected (more than 20 minutes 
since the last keep-alive) is the only one that doesn't log an error.

I did some modifications at the Wazuh repository, maybe it's useful to you:

https://github.com/wazuh/ossec-wazuh/commit/efbd5c17cc3ea5109ea978208b11da6c98fa3083

See below an example of the new log format for the error:

2016/07/29 11:43:57 ossec-remoted(1245): ERROR: Sending message to 
disconnected agent '001'.
2016/07/29 11:43:57 ossec-remoted(1217): ERROR: Error creating encrypted 
message.
2016/07/29 11:43:57 ossec-remoted(1246): ERROR: Unable to send file 
'merged.mg' to agent '001' (centos).

I hope this leads you to find the problem.

Kind regards.


On Friday, July 29, 2016 at 8:19:56 AM UTC-7, Graeme Stewart wrote:
>
> Hi Victor,
>
> Huge thanks for the detail, this would explain exactly why we're seeing 
> this; our OSSEC managers are likely overloaded.
>
> It would be very helpful to include the agentid in the logfile to 
> understand / track where this is occurring and the number of unique agents 
> that are impacted, perhaps something like:
>
> From: src/error_messages/error_messages.h
> #define SEC_ERROR   "%s(1217): ERROR: Error creating encrypted message 
> for: '%s')."
>
> Then inside: src/remoted/sendmsg.c
> msg_size = CreateSecMSG(, msg, crypt_msg, agentid);
> if (msg_size == 0) {
> merror(SEC_ERROR, ARGV0, agentid);
> return (-1);
> }
>
> The clustered nature of this issue leads me to suspect it's repeating this 
> error in the logfiles multiple times for a connection attempt across only 
> one or two agents.
>
> Again, many thanks for the detailed response.
>
> Graeme
>
> On Thursday, July 28, 2016 at 5:33:29 PM UTC-7, Victor Fernandez wrote:
>>
>> Hi Graeme.
>>
>> According to the log, I think the problem occurs when the manager tries 
>> to send the merged.mg to an agent that has not sent the keep-alive in 
>> the last 20 minutes. This may happen if a lot of agents get connected, or 
>> send the keep-alive at the same time. 
>>
>> So, if many agents send a keep-alive, the manager takes more than 20 
>> minutes to send the merged.mg to an agent, and that agent hasn't sent 
>> the keep-alive again, this problem occurs.
>>
>> I did some math: the manager sleeps one second every time it sends 27 KB. 
>> With a 150 KB merged.mg, OSSEC takes 20 minutes to send the complete 
>> file to about 216 agents.
>>
>> The 20-minutes check appears on src/remoted/sendmsg.c:
>>
>> /* If we don't have the agent id, ignore it */
>> if (keys.keyentries[agentid]->rcvd < (time(0) - (2 * NOTIFY_TIME))) {
>> return (-1);
>> }
>>
>> NOTIFY_TIME is 600 (10 minutes) by default. Nevertheless OSSEC labels an 
>> agent as disconnected when it hasn't send the keep-alive in the last 30:30 
>> minutes, as we can see at src/shared/read-agents.c:
>>
>> if (file_status.st_mtime > (time(0) - (3 * NOTIFY_TIME + 30))) {
>> return (GA_STATUS_ACTIVE);
>> }
>>
>> Because of this, I think that this may be an issue.
>>
>> I think that a good approach would be to check that there aren't alerts 
>> about disconnected agents that connected recently.
>>
>> Kind regards.
>>
>>
>> On Thursday, July 28, 2016 at 9:43:32 AM UTC-7, 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 
>

[ossec-list] Re: can we re-use agentID's

[Victor Fernandez]

Hi Chanti.

By default, OSSEC doesn't allow to add an agent with a removed agent's ID. 
When OSSEC adds a new agent, the information about it is written at 
/var/ossec/etc/client.keys. When you remove an agent, the corresponding 
line isn't removed but "tainted" with a "!" symbol.

If you want to reuse the ID but you can't recompile OSSEC, I recommend you 
to follow these steps:

   1. Identify the agents that you want to remove.
   2. Remove them with manage_agents (it comments the line and removes some 
   more files)
   3. Delete the lines at client.keys referred to the removed agents.
   4. Ensure that these folders have not files about the removed agents:


   - /var/ossec/queue/rids (files are named with the agent's ID)
  - /var/ossec/queue/agent-info (files are named with "name-ip"
  - /var/ossec/queue/syscheck, files are named with "(name) 
  ip->syscheck"
  - /var/ossec/queue/rootcheck, the same as syscheck
   
I hope it helps.
Kind regards.

On Thursday, July 28, 2016 at 12:03:34 PM UTC-7, 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: ERROR: Unable to send file 'merged.mg' to agent.

[Victor Fernandez]

Hi Graeme.

According to the log, I think the problem occurs when the manager tries to 
send the merged.mg to an agent that has not sent the keep-alive in the last 
20 minutes. This may happen if a lot of agents get connected, or send the 
keep-alive at the same time. 

So, if many agents send a keep-alive, the manager takes more than 20 
minutes to send the merged.mg to an agent, and that agent hasn't sent the 
keep-alive again, this problem occurs.

I did some math: the manager sleeps one second every time it sends 27 KB. 
With a 150 KB merged.mg, OSSEC takes 20 minutes to send the complete file 
to about 216 agents.

The 20-minutes check appears on src/remoted/sendmsg.c:

/* If we don't have the agent id, ignore it */
if (keys.keyentries[agentid]->rcvd < (time(0) - (2 * NOTIFY_TIME))) {
return (-1);
}

NOTIFY_TIME is 600 (10 minutes) by default. Nevertheless OSSEC labels an 
agent as disconnected when it hasn't send the keep-alive in the last 30:30 
minutes, as we can see at src/shared/read-agents.c:

if (file_status.st_mtime > (time(0) - (3 * NOTIFY_TIME + 30))) {
return (GA_STATUS_ACTIVE);
}

Because of this, I think that this may be an issue.

I think that a good approach would be to check that there aren't alerts 
about disconnected agents that connected recently.

Kind regards.


On Thursday, July 28, 2016 at 9:43:32 AM UTC-7, 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.

Re: [ossec-list] Solaris Compilation - Visibility

[Victor Fernandez]

Hi.

I haven't Solaris available to compile OSSEC, but in view of the code, I 
think you can solve those issues:

generate_reports.c:59: Force casting to integer of getpid():

/*(old)*/ *snprintf**(fname, 255, "/logs/.report-%d.log", getpid());*
/*(new)*/ *snprintf**(fname, 255, "/logs/.report-%d.log", (int)getpid());*

main-server.c:49: Remove the const qualifier:

/*old*/ *int** ssl_error(const SSL* ssl, int ret)*
/*new*/ *int** ssl_error(SSL* ssl, int ret)*

Because of the compiler version, it's possible that new similar problems 
appear.

Hope it helps.
Kind regards.

Victor Fernandez.


On Wednesday, July 20, 2016 at 1:04:04 AM UTC-7, Eero Volotinen wrote:
>
> Tried compiling ossec 2.8.3 under Solaris/x86 5.10 and it worked. Any of 
> these messages are not errors, they are just warnings.
>
> Please provide complete output from compiling.
>
> Eero
>
> 2016-07-19 22:28 GMT+03:00 Kumar Mg <mkg...@gmail.com >:
>
>> Hi, 
>>
>> We also have the agent compilation issue on the Solaris platform with the 
>> 2.8.3 version of code. How can we fix the "Checking for 
>> attribute(visibility) support... No"? 
>>
>> For time being we updated the lua* conf updated to remove the warning 
>> message, however the below warning are still showing up. 
>>
>>
>> *** Making zlib (by Jean-loup Gailly and Mark Adler)  *** 
>> cd zlib-1.2.8/; ./configure; make libz.a;
>> Checking for shared library support...
>> Building shared library libz.so.1.2.8 with /usr/sfw/bin/gcc.
>> Checking for off64_t... Yes.
>> Checking for fseeko... Yes.
>> Checking for strerror... Yes.
>> Checking for unistd.h... Yes.
>> Checking for stdarg.h... Yes.
>> Checking whether to use vs[n]printf() or s[n]printf()... using 
>> vs[n]printf().
>> Checking for vsnprintf() in stdio.h... Yes.
>> Checking for return value of vsnprintf()... Yes.
>> Checking for attribute(visibility) support... No.
>>
>>
>>
>> *** Making monitord *** 
>>
>> /usr/sfw/bin/gcc -g -Wall -I../ -I../headers  -DCLIENT -DUSE_OPENSSL 
>> -DSOLARIS -DHIGHFIRST  -DARGV0=\"ossec-monitord\" -DOSSECHIDS -lsocket 
>> -lnsl -lresolv compress_log.c main.c manage_files.c monitor_agents.c 
>> monitord.c sign_log.c generate_reports.c ../os_maild/sendcustomemail.c 
>> ../config/lib_config.a ../shared/lib_shared.a ../os_net/os_net.a 
>> ../os_regex/os_regex.a ../os_xml/os_xml.a ../os_crypto/os_crypto.a 
>> ../os_zlib/os_zlib.c ../external/libz.a -o ossec-monitord
>> generate_reports.c: In function `generate_reports':
>> generate_reports.c:59: warning: int format, pid_t arg (arg 4)
>> /usr/sfw/bin/gcc -g -Wall -I../ -I../headers  -DCLIENT -DUSE_OPENSSL 
>> -DSOLARIS -DHIGHFIRST  -DARGV0=\"ossec-monitord\" -DOSSECHIDS -lsocket 
>> -lnsl -lresolv -UARGV0 -DARGV0=\"ossec-reportd\" report.c 
>> ../config/lib_config.a ../shared/lib_shared.a ../os_net/os_net.a 
>> ../os_regex/os_regex.a ../os_xml/os_xml.a ../os_crypto/os_crypto.a 
>> ../os_zlib/os_zlib.c ../external/libz.a -o ossec-reportd
>>
>>
>> *** Making os_auth *** 
>>
>> /usr/sfw/bin/gcc -g -Wall -I../ -I../headers  -DCLIENT -DUSE_OPENSSL 
>> -DSOLARIS -DHIGHFIRST  -DARGV0=\"ossec-authd\" -DOSSECHIDS -lsocket 
>> -lnsl -lresolv main-server.c ssl.c ../addagent/validate.c 
>> ../config/lib_config.a ../shared/lib_shared.a ../os_net/os_net.a 
>> ../os_regex/os_regex.a ../os_crypto/os_crypto.a ../os_zlib/os_zlib.c 
>> ../external/libz.a -lssl -lcrypto -o ossec-authd
>> main-server.c: In function `ssl_error':
>> main-server.c:53: warning: passing arg 1 of `SSL_get_error' discards 
>> qualifiers from pointer target type
>> /usr/sfw/bin/gcc -g -Wall -I../ -I../headers  -DCLIENT -DUSE_OPENSSL 
>> -DSOLARIS -DHIGHFIRST  -DARGV0=\"ossec-authd\" -DOSSECHIDS -lsocket 
>> -lnsl -lresolv main-client.c ssl.c ../addagent/validate.c 
>> ../config/lib_config.a ../shared/lib_shared.a ../os_net/os_net.a 
>> ../os_regex/os_regex.a ../os_crypto/os_crypto.a ../os_zlib/os_zlib.c 
>> ../external/libz.a -lssl -lcrypto -o agent-auth
>>
>>
>>
>> If any one can shower some light on this, that will be great. 
>>
>>
>> Thanks
>> Kumar
>>
>> -- 
>>
>> --- 
>> 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] Re: ERROR: Agent '(empty)' not found.

[Victor Fernandez]

Hi Brian.

It seems to be an Active Response issue. This message appears when AR fails 
to find the name of the agent among the registered agents. But the log 
should show the name of the agent, and it doesn't appear in the message. 
The problem isn't related to the network.

Could you find the alert that triggers this AR? If you can do that, find 
the name of the agent in the alert and make sure that this agent is 
properly registered (i.e. with the program manage_agents).

Remoted saves the source IP of an agent when it receives a message. This is 
important, particularly if the agent is registered with "any" IP. In order 
to log the source IP you need to write the code into file 
src/remoted/secure.c. But if you registered the agent with an IP other than 
"any", then the source IP will always match the registered IP.

I think that there is an issue when analysisd sends an active response to 
remoted.

Hope it helps.

Best regards.

Victor Fernandez.


On Thursday, July 7, 2016 at 8:03:46 AM UTC-7, BP9906 wrote:
>
> I'm facing an odd issue where we have some server partially configured 
> (dont ask) and so as a result the ossec server logs this every one in a 
> while.
>
> 2016/07/07 05:13:25 ossec-remoted(1320): ERROR: Agent '' not found.
>
>
> I've enabled iptables logging, searched through all servers in those time 
> periods and found nothing. 
>
>
> I'm wondering how I can add a source IP address to the remoted logging? 
>
>
>
> Thank you for your help
>
> Brian
>
>
>

-- 

--- 
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: inode changes for syscheck

[Victor Fernandez]

Hi.

Syscheck doesn't monitor inode changes on files at the present. In fact I 
don't know a way to change the inode number without modifying it.

When a file is renamed, it keeps the inode, but if it's deleted, when you 
eventually create a new one, with the same or different name, the operating 
system can assign the inode of the same file (as Linux does) or create 
always a different inode (as OS X does).

This is a way to change an inode and OSSEC doesn't notify about it:

$ touch test.txt
(OSSEC fires rule 554, if enabled)
$ cp test.txt copy.txt && rm test.txt && mv copy.txt test.txt

In this case, the inode has changed, but since neither the size nor the 
content of the file have changed, OSSEC doen't detect it.

Could you give us an use case in which it would be interesting to detect 
inode changes?

Kind regards.

Victor Fernandez.


On Wednesday, June 29, 2016 at 1:30:33 PM UTC-7, Kumar Mg wrote:
>
> Hi Dan,
>
> I am referring to have inode alerts similar way we have the MD5 alerts 
> from syscheck. 
>
>
> Thanks
> Kumar
>
>
> On Thursday, 30 June 2016, dan (ddp) <ddp...@gmail.com > 
> wrote:
>
>>
>> On Jun 29, 2016 4:24 PM, "Kumar Mg" <mkg...@gmail.com> wrote:
>> >
>> > Hi, 
>> >
>> > Is there a way we can have Syscheck to alert the inode changes 
>> separately. 
>> >
>> >
>>
>> Is there a rule specifically for inode changes? If so, it should be easy 
>> (depending on what you mean exactly).
>>
>> > Thanks
>> > Kumar
>> >
>> > -- 
>> >
>> > --- 
>> > 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.

[ossec-list] Re: General questions I can't find an answer to

[Victor Fernandez]

Hi.

A1: In fact you should enable  on your ossec.conf file, 
but it only enables the agent to receive commands from the server. However, 
the syscheck/rootcheck restarting is not immediate, but it will be done 
after a cycle of syscheck.

A2: That line seems so be correct, and that verbatim do work in our labs. 
You can find a larger file here, as example:

https://github.com/wazuh/ossec-wazuh/blob/master/src/rootcheck/db/system_audit_ssh.txt

If you tell us what you want to do, we might help you.

A3: Yes, you can add multiple  to your ossec.conf file, it's 
not necessary to join them into a single file.

Best regards.

-- 

--- 
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.conf settings not syncing to agents

[Victor Fernandez]

Hi.

Every setting at agent.conf needs to be inside a  section, 
otherwise the configuration reader may fail. So, please relocate the tags 
 and  that are outside  and 
restart the agent.

If the problem persists, enable debugging logs editing the file 
internal_options.conf and changing the setting windows.debug from 0 to 2 
and restart the agent. This way you can see more details at the log.

Kind regards.

-- 

--- 
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 local logfile ignored

[Victor Fernandez]

Hi Jacob.

When does that message appear? I mean, does it happen on OSSEC start, or 
after a while?

Can you see a message like the following, when OSSEC starts?

ossec-logcollector(1950): INFO: Analyzing file: 
> '/home/mis/admin-tools/logs/ping-domain.log`

ossec-logcollector(1950): ERROR: Could not open file 
> '/home/mis/admin-tools/logs/ping-domain.log'


I think the message "File not available, ignoring it" appears when OSSEC 
opens successfully the file but fails on reading it, maybe due to a 
rotation.

Kind regards. 

-- 

--- 
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 Send Log Size

[Victor Fernandez]

Hi.

In normal operation, OSSEC connects once, on startup, and closes the socket 
on exiting. But, for the behavior of UDP, there isn't an actual 
"connection", instead of this, every datagram is independent of the rest. 
Maybe this is the reason why the firewall considers every delivery as a 
connection.

But, if you are using the EventChannel log format at ossec.conf, I wonder 
if it's possible to discriminate the destination IP using the query.

Best regards.

-- 

--- 
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 Send Log Size

[Victor Fernandez]

Hi Abdulvehhab.

It has sense, it falls into a infinite recursivity, But it's a bit 
difficult to store some messages and send them to the server since the 
protocol consists on one datagram per message. Even if the agent stores 
some messages and sends all of them at a time, the firewall would detect 
one delivery per message.

Out of curiosity, what is the EventLog configuration? Maybe it's possible 
to ignore connections towards the OSSEC server.

Best regards.

-- 

--- 
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: fim/hids on laptops

[Victor Fernandez]

Hi Derek.

Unfortunately, OSSEC is not designed to work offline. Messages are actually 
queued while the agent tries to connect to the server, but this memory is 
very small and will be filled quickly.

If you stop or restart the agent, the queued data will be lost.

Regards.

-- 

--- 
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: monitor hostname changes

[Victor Fernandez]

Hi Francesco.

A good way to achieve this is to monitor the command "hostname", adding the 
following lines to ossec.conf:


  command
  hostname
  3600


Then, create a rule like this one, as child of rule 530 (about OSSEC 
command monitoring), with the option , in order to be alerted 
only when the hostname changes:


  530
  output: 'hostname':
  
  Hostname changed


Kind regards.

-- 

--- 
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: New File Alert works "sometimes". Can't seem to get Realtime working.

[Victor Fernandez]

Hi Ferdia.

In order to be alerted about new files, you should add the option 
 to Syscheck on the server side. Here is an example:


  7200
  *yes*
  https://groups.google.com/d/optout.

[ossec-list] Re: How to give priority to custom rules

[Victor Fernandez]

Hi Luca.

You need to create a "child rule" that matches with 1003 for large 
messages, and another rule for short messages. After that, you migh make a 
rule that matches with the previous two. A good way to do it is using a 
rule group. For example, if your decoder is called "oracle", you should 
create the following rules:






  oracle
  Short message accepted



  
  1003
  oracle
  Large message accepted





  oracle_prerules
  Oracle sent log.





In this way, every alert decoded by "oracle" will match the rule 17, no 
matter the message is long or short.

Kind regards.

Victor Fernandez.

-- 

--- 
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] Disk usage monitor not working in RHEL5

[Victor Fernandez]

I think the problem is the option "-h", because it introduces arbitrary 
line feeds in order to be more readable by people, but it makes more 
difficult to decode. This happened in RHEL5 but it can happen at any system 
with a long filesystem path.

"-P" is an interesting option to preserve compatibility. So I think the 
best solution is to use only "df" or "df -P" at "ossec.conf" and rule 531.

Thank you for letting us know!

Regards.

-- 

--- 
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 service in windows 10

[Victor Fernandez]

I had the Erorr 5 when the file "ossec-agent.exe" has no permissions for 
"SYSTEM".

Unfortunately, when we change the IP in the UI, the file "ossec.conf" is 
re-created without SYSTEM permissions, so the service starts and exits 
suddenly, but it prints the access error in the "ossec.log".

So, make sure that SYSTEM has permissions for executable files inside 
directory "ossec-agent" and "ossec.conf".

Kind regards.

-- 

--- 
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 service in windows 10

[Victor Fernandez]

P.D.: I detected that sometimes, if I already created the group 
"Administrators" (for non-English Windows versions), the OSSEC grants files 
permissions only to the group "Administrators".

In order to start a service, executable files must have execution 
permissions for "SYSTEM". So, please make sure that "ossec-agent.exe" and 
every ".exe" file has permissions for SYSTEM. I did the following steps:

   1. Open properties for directory "C:\Program Files\ossec-agent" (or 
   "C:\Program Files (x86)\ossec-agent")
   2. Go to tab "Security". Make sure there are permissions for "SYSTEM".
   3. Now click on button "Advanced".
   4. On tab "Permissions", you may have to click "Change permissions".
   5. Mark box "Replace all child object permission entries with 
   inheritable permission entries from this object". (In Spanish: "Reemplazar 
   todas las entradas de permisos secundarios por entradas de permisos 
   heredables de este objeto".)
   6. Click "Accept" and confirm the dialog box that will appear.
   7. Try to start the agent.

I hope this will be useful for you.
Best regards.

Victor Fernandez.

-- 

--- 
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 Agent Compilation

[Victor Fernandez]

Hi Kumar.

As you wrote:

rc\win-pkg>"C:\MinGW\bin\gcc.exe" -o "ossec-agent" -Wall 
>  -DARGV0=\"ossec-agent\
> " -DCLIENT -DWIN32 -DOSSECHIDS icon.o os_regex/*.c os_net/*.c os_xml/*.c 
> zlib-1.
> 2.8/*.c config/*.c shared/*.c os_execd/*.c os_crypto/blowfish/*.c 
> os_crypto/md5/
> *.c os_crypto/sha1/*.c os_crypto/md5_sha1/*.c os_crypto/shared/*.c 
> rootcheck/*.c
> *.c -I. -Iheaders/ -lwsock32


It doesn't seem to link the library "shlwapi", which contains the function 
PathFindFileName().


Please review the file "make.bat" and make sure that the option "-lshlwapi" 
appears at every line of an executable that fails on compile.


As an example:

"C:\MinGW\bin\gcc.exe" -o "ossec-agent" -Wall  -DARGV0=\"ossec-agent\" 
-DCLIENT -DWIN32 -DOSSECHIDS icon.o os_regex/*.c os_net/*.c os_xml/*.c 
zlib-1.2.8/*.c config/*.c shared/*.c os_execd/*.c os_crypto/blowfish/*.c 
os_crypto/md5/*.c os_crypto/sha1/*.c os_crypto/md5_sha1/*.c 
os_crypto/shared/*.c rootcheck/*.c *.c -I. -Iheaders/ -lwsock32 -lshlwapi

Best regards.

Victor Fernandez.

-- 

--- 
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 service in windows 10

[Victor Fernandez]

Hi Diego.

How do you start the service, with the UI or from Services?

Does OSSEC print something into the file "ossec.log"?

Best regards.

Victor Fernandez.



On Tuesday, April 19, 2016 at 12:15:49 PM UTC+2, Diego Arranz wrote:
>
> Hi all,
>
>I´m testing wazuh server on CentOS and ossec 2.8.3 as agent in windows 
> 10 profesional (spanish language), the problem is when i try to start the 
> ossec service as local account, the service don´t run with error 5: acces 
> deny error, if i setup any administrator account to run the service is all 
> ok.
>
>   I try to do full permissions to network service account and local 
> services account over the folder but the error is the same (error 5: acces 
> deny)
>
>   
>
>   Somebody have any idea about this problem??
>
> 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.
For more options, visit https://groups.google.com/d/optout.

[ossec-list] Re: Windows Agent Compilation

[Victor Fernandez]

Hi Kumar.

It seems difficult to install OSSEC in Windows. Are you compiling the 
version 2.8.2 for a particular reason?

I tried to compile OSSEC 2.8.2 in my lab and I got some linker errors on 
memory allocation, I have not found a solution. I have downloaded the 
version 2.8.3 and I have got some errors but at less some binaries were 
compiled. There are errors on ossec-agent, ossec-rootcheck and 
setup-windows.

I have resolved it in the following way:

   1. After run gen_win.cmd, open (ossec)\src\win-pkg\headers\shared.h with 
   an editor and comment the line 86: // #include 
   2. Edit also the file win-pkg\make.bat and add -lshlapi (how appears on 
   line 6) to lines 4, 5, and 7 (where are compiled the problematic binaries).
   3. Now launch make.bat and every executable would appear.

I get every binary but I was not able to compile the installer, I think the 
cause of this is that ossec-lua and ossec-luac are not compiled by 
make.bat. If you need the installer, maybe you could try to add the proper 
lines to compile these files.

I hope it will help you.

Best regards.

Victor Fernandez.


On Wednesday, April 6, 2016 at 9:08:55 PM UTC+2, Kumar Mg wrote:
>
> Hi, 
>
> We are in the process of getting the OSSEC agents compiled on different 
> platforms (UNIX and Windows). To start with we were getting the Windows 
> agent compilation and was trying it out in the Windows 7 as well as Windows 
> 2008 versions. Followed the steps mentioned here - 
> http://ossec-docs.readthedocs.org/en/latest/manual/installation/compile-ossec-on-windows.html
> .
>
> The win-pkg folders were created and it failed with following messages at 
> the time of make.sh. 
>
>
>
>
> C:\Users\ossec\Downloads\ossec-hids-2.8.2\ossec-hids-2.8.2\src\win-pkg>make.bat
>
> C:\Users\ossec\Downloads\ossec-hids-2.8.2\ossec-hids-2.8.2\src\win-pkg>echo 
> Maki
> ng windows agent
> Making windows agent
>
>
> C:\Users\ossec\Downloads\ossec-hids-2.8.2\ossec-hids-2.8.2\src\win-pkg>"C:\MinGW
> \bin\windres.exe" -i icofile.rc -o icon.o
>
>
> C:\Users\ossec\Downloads\ossec-hids-2.8.2\ossec-hids-2.8.2\src\win-pkg>"C:\MinGW
> \bin\gcc.exe" -o "ossec-agent" -Wall  -DARGV0=\"ossec-agent\" -DCLIENT 
> -DWIN32 -
> DOSSECHIDS icon.o os_regex/*.c os_net/*.c os_xml/*.c zlib-1.2.8/*.c 
> config/*.c s
> hared/*.c os_execd/*.c os_crypto/blowfish/*.c os_crypto/md5/*.c 
> os_crypto/sha1/*
> .c os_crypto/md5_sha1/*.c os_crypto/shared/*.c rootcheck/*.c *.c -I. 
> -Iheaders/
> -lwsock32
> rootcheck/win-common.c: In function '__os_winreg_querykey':
> rootcheck/win-common.c:212:11: warning: variable 'sub_key_name_b' set but 
> not us
> ed [-Wunused-but-set-variable]
>  TCHAR sub_key_name_b[MAX_KEY_LENGTH +1];
>^
> In file included from run_realtime.c:45:0:
> headers/shared.h:181:0: warning: "os_calloc" redefined
>  #define os_calloc(x,y,z) ((z = calloc(x,y)))?(void)1:ErrorExit(MEM_ERROR, 
> ARGV0
> )
>  ^
> run_realtime.c:29:0: note: this is the location of the previous definition
>  #define os_calloc(x,y,z) (z = calloc(x,y))?(void)1:ErrorExit(MEM_ERROR, 
> ARGV0)
>  ^
> In file included from run_realtime.c:45:0:
> headers/shared.h:183:0: warning: "os_strdup" redefined
>  #define os_strdup(x,y) ((y = strdup(x)))?(void)1:ErrorExit(MEM_ERROR, 
> ARGV0)
>  ^
> run_realtime.c:30:0: note: this is the location of the previous definition
>  #define os_strdup(x,y) (y = strdup(x))?(void)1:ErrorExit(MEM_ERROR, ARGV0)
>  ^
> seechanges.c: In function 'seechanges_addfile':
> seechanges.c:347:5: warning: implicit declaration of function 'symlink' 
> [-Wimpli
> cit-function-declaration]
>  if (symlink(old_location, old_tmp) == -1) {
>  ^
> C:\Users\ossec\AppData\Local\Temp\cc4a5eCY.o:seechanges.c:(.text+0x6f5): 
> undefin
> ed reference to `symlink'
> C:\Users\ossec\AppData\Local\Temp\cc4a5eCY.o:seechanges.c:(.text+0x75f): 
> undefin
> ed reference to `symlink'
> C:\Users\ossec\AppData\Local\Temp\cc4a5eCY.o:seechanges.c:(.text+0x7c9): 
> undefin
> ed reference to `symlink'
> collect2.exe: error: ld returned 1 exit status
>
>
> C:\Users\ossec\Downloads\ossec-hids-2.8.2\ossec-hids-2.8.2\src\win-pkg>"C:\MinGW
> \bin\gcc.exe" -o "ossec-rootcheck" -Wall  -DARGV0=\"ossec-rootcheck\" 
> -DCLIENT -
> DWIN32 icon.o os_regex/*.c os_net/*.c os_xml/*.c config/*.c shared/*.c 
> win_servi
> ce.c rootcheck/*.c -Iheaders/ -I. -lwsock32
> rootcheck/rootcheck-config.c: In function 'Read_Rootcheck_Config':
> rootcheck/rootcheck-config.c:69:18: warning: variable 'xml_time' set but 
> not use
> d [-Wunused-but-set-variable]
>  const char *(xml_time[])={xml_rootcheck, "frequency", NULL}

[ossec-list] Re: new file does not create any alert

[Victor Fernandez]

P.S.: This is a duplicated topic.

There is a more detailed explanation to your problem at the other topic:

https://groups.google.com/forum/#!topic/ossec-list/eSbdMTPLG7A

Regards.



On Friday, April 1, 2016 at 3:17:24 PM UTC+2, Victor Fernandez wrote:
>
> Hi.
>
> I did the same as you: changed the rule's level from 0 to 10 and added
>
> yes
>
> on "ossec.conf", both at server, and I had no error.
>
> You should check the Syscheck database (tail of file at 
> /var/ossec/queue/syscheck) and verify that new files are on it.
>
> Depending on whether the file appears in the database or not, the problem 
> may be with the agent or the manager.
>
> Best regards.
>
>
>
> On Thursday, March 31, 2016 at 9:08:36 PM UTC+2, jingxu...@bettercloud.com 
> wrote:
>>
>> I followed the instruction as 
>>
>> Add the following to local_rules.xml:
>>
>> 
>>   ossec
>>   syscheck_new_entry
>>   File added to the system.
>>   syscheck,
>>
>> The  entry should look something like this:
>>
>> 
>>   7200
>>   yes
>>   /etc,/bin,/sbin
>>
>> And then restart the agent and server, but I did not get alerts forever.
>>
>

-- 

--- 
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: new file does not create any alert

[Victor Fernandez]

Hi.

I did the same as you: changed the rule's level from 0 to 10 and added

yes

on "ossec.conf", both at server, and I had no error.

You should check the Syscheck database (tail of file at 
/var/ossec/queue/syscheck) and verify that new files are on it.

Depending on whether the file appears in the database or not, the problem 
may be with the agent or the manager.

Best regards.



On Thursday, March 31, 2016 at 9:08:36 PM UTC+2, jingxu...@bettercloud.com 
wrote:
>
> I followed the instruction as 
>
> Add the following to local_rules.xml:
>
> 
>   ossec
>   syscheck_new_entry
>   File added to the system.
>   syscheck,
>
> The  entry should look something like this:
>
> 
>   7200
>   yes
>   /etc,/bin,/sbin
>
> And then restart the agent and server, but I did not get alerts forever.
>

-- 

--- 
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 agent - unable to start agent (check config)

[Victor Fernandez]

Hi.

I remember a problem that I had with permissions in Windows: please check 
that your OSSEC directory (like C:\Program Files\ossec-agent) and every 
file contained in it have full permissions for "Administrators".

I hope this solves your problem.

Best regards.


On Thursday, March 31, 2016 at 8:45:42 PM UTC+2, Krzysztof Zaklikiewicz 
wrote:
>
> Hi
>
> Thanks guys now it's works fine, but on Windows 2012 Server is still 
> problem. I was doing exectly the same how on Windows 7 but when I start 
> agent show error UNABLE TO START AGENT (CHCECK CONFIG), my ossec.log:
>
> 2016/03/31 20:31:45 ossec-agent: INFO: Service does not exist (OssecSvc) 
> nothing to remove.
>
> 2016/03/31 20:31:45 ossec-agent: INFO: Successfully added to the service 
> database.
>
> 2016/03/31 20:31:45 setup-windows: INFO: System is Vista or newer 
> (Microsoft Windows Server 2012 Standard Edition  (Build 9200) - OSSEC HIDS 
> v2.8.3).
>
> 2016/03/31 20:31:56 ossec-win32ui: INFO: Running the following command 
> (C:\Windows\system32\cmd.exe /c echo y|cacls "new-ossec.conf" /T /G 
> Administrators:f)
>
> 2016/03/31 20:31:58 ossec-win32ui: INFO: Running the following command 
> (C:\Windows\system32\cmd.exe /c echo y|cacls "client.keys" /T /G 
> Administrators:f)
>
> What's wrong??
>
> W dniu wtorek, 29 marca 2016 22:51:25 UTC+2 użytkownik Victor Fernandez 
> napisał:
>>
>> Hi.
>>
>> Have you added the original administrator and your own account to the 
>> "Administrators" group?
>>
>> I followed your steps, added my user account to "Administrators", closed 
>> and reopened my session, and it did work.
>>
>> Regards.
>>
>

-- 

--- 
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 agent - unable to start agent (check config)

[Victor Fernandez]

Hi.

Have you added the original administrator and your own account to the 
"Administrators" group?

I followed your steps, added my user account to "Administrators", closed 
and reopened my session, and it did work.

Regards.

-- 

--- 
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't find resolution for these error messages

[Victor Fernandez]

Hi Ben.

The first error is normal, or at less, predictable to happen: since an 
agent-less isn't an agent, it can't receive active-responses. Active 
responses are generated by the rule analyzer (analisisd), that doesn't 
distinguish between agents and agent-less, so the remote daemon, that 
 sends the active-response commands, shows that error because it can't find 
the agent. But it isn't a critical error.

Regarding to the second problem, there is a hardcoded limit of 10 attempts 
at agentless/agentless.c:

/* Main monitor loop */

/* (...) */

while(lessdc.entries[i])
{
if(lessdc.entries[i]->error_flag >= 10)
{
if(lessdc.entries[i]->error_flag != 99)
{
merror("%s: ERROR: Too many failures for '%s'. Ignoring 
it.",
   ARGV0, lessdc.entries[i]->type);
lessdc.entries[i]->error_flag = 99;
}

i++;
sleep(i);
continue;
}

The last 3 lines make that, after 10 attempts, the program continues and no 
longer tries to execute the command. Maybe, deleting them (i++; sleep(i); 
continue;) the program retries to execute the command.

We're testing it at our development environment and we'll include the 
changes in our repository at Wazuh.

Best regards.
Victor.

-- 

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

[Victor Fernandez]

Hi,

Please tell us your version of OSSEC, how many agents you want to register 
and your limit of agents, so we can reproduce your problem.

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.

[ossec-list] Re: Get actual Agent IP

[Victor Fernandez]

IP is used in OSSEC for assigning permissions to agents. It would be 
possible to add information about the IP address in the agent's queue and 
show it with *agent_control*, or include the IP in the alert generated when 
an agent connects to the manager.

Another solution that won't imply to modify the OSSEC code is using a 
script to log the agent's IP and configuring OSSEC to read it and generate 
an alert when that IP changes.

Anyway, if you use "any" as IP address on registering agents is because you 
use DHCP and that IP is dynamic, so the IP address would be informative 
data, never used to identify an agent.

Best regards.

-- 

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