Hi all,
Can somebody hint me in the right direction on this?
I have two dynamic hosts with a ddns hostname and I don't want those to trigger
events. But I can't find a way to do that anywhere.
Thanks in advance.
Herman
--
---
You received this message because you are subscribed to the Goog
I’d give Wazuh a whirl, if I were you. They’ve got decoders and rules for
sysmon, as well as eventchannel working (or I assume they do, if they have that
stuff setup for sysmon).
My current decoder/rule development server and agents have been around long
enough that I don’t recall what sort
Thanks for the input! I'll take a closer look at 2.8.3 but the whole reason
I was looking at 2.9RC2 was because it supported the eventchannel log type.
>From what I understand, 2.8.x had trouble with this and therefore had
trouble with sysmon. Has that been your experience with 2.8.3? Thanks again
Craig,
Hm... I just now noticed your exact symptoms while playing with a test OSSEC
server that was created from a relatively recent git clone of the repository
(cloned within the last month or two?). Take a look at your original output of
ossec-logtest, under “Prepended Data Removed”. Look
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 rem
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-standa
This is perfect, exactly what i was looking for. Thank you very much for
the help!
On Tue, Aug 2, 2016 at 1:44 PM, Pedro Sanchez wrote:
> Thanks Victor.
>
> Quick fix to your useful command, it is missing queue folder:
>
> $ find /var/ossec/queue/agent-info/* -mtime +60 -ls
>
>
>
>
> On Tue, Aug
Thanks Victor.
Quick fix to your useful command, it is missing queue folder:
$ find /var/ossec/queue/agent-info/* -mtime +60 -ls
On Tue, Aug 2, 2016 at 11:37 AM, Victor Fernandez wrote:
> Hi Derek.
>
> You can do that by watching the modification time (with ls or stat) of
> the agent's info
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
Hi, try checking the last keep alive or the last modification date of
agent-info file.
/var/ossec/bin/agent_control -i 005
Output:
>Agent ID: 005
>Agent Name: agent-ubuntu
>IP address: 10.0.0.xx
>Status: Disconnected
>Operating system:Linux vpc-agent-ubuntu-public 3
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
Thanks. This is helpful.
On Tuesday, August 2, 2016 at 4:19:56 AM UTC-4, Jesus Linares wrote:
>
> Hi JDS,
>
>
--
---
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
Dan,
Really appreciate your help and attention to this. I guess I will just have
to drop the idea of "nightly scans", and go with something like this:
28800
no
yes
yes
This should force the scan on start, and thereby force the realtime scan to
kick in soon after that complete
On Tue, Aug 2, 2016 at 8:55 AM, Daniel Bray wrote:
> OK, I think that is the issue. With the settings like this:
>
> 1am
> 82800
> no
> yes
> no
>
> It is not doing the realtime scan until after 1am. I confirmed this today.
> When I got in this morning and started editing some
OK, I think that is the issue. With the settings like this:
1am
82800
no
yes
no
It is not doing the realtime scan until after 1am. I confirmed this today.
When I got in this morning and started editing some files on one of the
servers, I started to get realtime alerts. I quick
On Mon, Aug 1, 2016 at 10:32 AM, 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 availab
On Fri, Jul 29, 2016 at 2:37 PM, Christopher J. Bischoff
wrote:
> Its been a while, but few years (I forgot the version) it was required to
> have separate OSSEC Managers per ruleset/alerting deployment. For example
> if I have 2x completely deployments (OS + applications installed + alerting
> t
On Mon, Aug 1, 2016 at 9:11 AM, Craig wrote:
> So, interesting. I guess that is my question. In my testing (using 2.9RC2),
> the decoder below won't recognize the log entry unless I keep the header
> from archives.log (you can see the output in my post above). If I remove the
> header, the decoder
Victor,
The nightly scans are working just fine. That's not the problem The problem
is the real time scans are not working. Each night around 1am, I get
various reports of changed or added filesall good there. However,
during the day or really any time, if I edit/add/delete files in /etc or
/r
Hi JDS,
rootcheck does a lot of things: check rootkit_files and rootkit_trojans,
scan the /dev directory looking for anomalies, check the file system
looking for unusual files and permissions, inspect all process IDs, look
for the presence of hidden ports, scan all network interfaces, etc. I
g
20 matches
Mail list logo
