That file is definitely required, though I am not sure it has anything to
do with the agent connecting in.
You showed earlier connections on port 1514 from the devices in question
right?
Does the ossec.log note any issues with those devices?
for what it is worth, here is a sender_counter file fr
I got most everything to work except at one site. After looking through
everything on that server, I noticed that the sender_counter file is
missing from rids directory. I know that keeps track/count of
something...could that be what's causing some of my agents to not be able
to connect?
On
Kevin,
Oh! I see "Error" now, thanks. I must not have used grep -i when I was
reviewing it!
8^)
thanks again,
Rick
On Friday, October 17, 2014 11:21:57 AM UTC-4, Rick McClinton wrote:
>
> **Phase 1: Completed pre-decoding.
>full event: '2014-10-17 15:06:09 192.168.2X.228 GET
> /perso
Has "Error" in the log and it didn't match anything else?
--
Kevin Kelly
Director, Network Technology
Whitman College
- Original Message -
From: "Rick McClinton"
To: ossec-list@googlegroups.com
Sent: Friday, October 17, 2014 8:21:57 AM
Subject: [ossec-list] why is 1002 firing on
I can't figure out why this log line triggers rule 1002. Can anyone see it?
background - I recently updated server to 2.8.1. Today I added this web
server's iis log file to its agent's and now that it is
sending the entries to the server,I am getting this alert from rule 1002.
Have not overri
On Fri, Oct 17, 2014 at 1:45 AM, Artien Bel wrote:
> OSSEC on it's own does not allow for alerting on POODLE, since it's a
> protocol issue. However if any org runs a network sniffer or IPtables, the
> SSLv3 handshake is pretty easy to distinguish.
Yes, if you're running Bro to monitor your netwo
OSSEC on it's own does not allow for alerting on POODLE, since it's a
protocol issue. However if any org runs a network sniffer or IPtables,
the SSLv3 handshake is pretty easy to distinguish.
I would think a quick and easy hack would be to make IPTABLES log the
SSLv3 connection and alert on that.
