On 09/20/2013 02:08 PM, Paul Raines wrote:
OK. ossec regex is the first regex variant I have ever run into where
"." isn't a match for any character. Sorry about that.
Thanks for your help
It does mean match on any character, but it is escaped by the \. OSSEC
regex is intentionally limited s
OK. ossec regex is the first regex variant I have ever run into where "."
isn't a match for any character. Sorry about that.
Thanks 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 rece
On Sep 20, 2013 12:51 PM, "Paul Raines" wrote:
>
> I understand why rule 1002 matches, I just didn't understand why it was
applied to that log line in the first place. But if all decoders are
applied to all log files, I guess that explains why. But it seems a very
inefficient design. When one d
I understand why rule 1002 matches, I just didn't understand why it was
applied to that log line in the first place. But if all decoders are
applied to all log files, I guess that explains why. But it seems a very
inefficient design. When one designates the access_log to be watched, one
shou
On Sep 20, 2013 11:45 AM, "Paul Raines" wrote:
>
> I have recently started using ossec and I am trying to filter out bogus
> alerts from my httpd access_log without success.
>
> I often get email alerts with:
>
> Received From: (surfer) 132.183.202.158->/var/log/httpd/access_log
> Rule: 1002 fired
I have recently started using ossec and I am trying to filter out bogus
alerts from my httpd access_log without success.
I often get email alerts with:
Received From: (surfer) 132.183.202.158->/var/log/httpd/access_log
Rule: 1002 fired (level 2) -> "Unknown problem somewhere in the system."
Porti
