Thanks again Jesus!
I will definitely share what I come up with and thanks for all your
suggestions and bearing with me through this (long) thread :)
Fredrik
On Thursday, August 18, 2016 at 12:17:20 PM UTC+2, Jesus Linares wrote:
>
> Hi Fredik,
>
> Long time no see!. It is a hot summer here
Hi Fredik,
Long time no see!. It is a hot summer here and, as always, playing with
OSSEC ;).
I don't have time to create all the decoders, but here a template to help
you:
^redirect \p|^prevent \p|^allow \p|^block \p|^mail System
Alert|\S+ alert Protection Name:
firewall
Hi Jesus!
Hope you have had a nice summer so far :) I'm revisiting this decoder with,
what I hoped would be, a fresh (rested) pair of eyes ;) Unfortunately, I
realize I still have trouble sorting this one out in an efficient manner. I
was hoping I could ask you for a few additional pointers
Thanks Antonio! Noted!
Best regards,
Fredrik
On Saturday, April 16, 2016 at 1:14:53 AM UTC+2, Antonio Querubin wrote:
>
> On Fri, 15 Apr 2016, Fredrik wrote:
>
> > Thanks for getting back to me. Again :) :) I'm trying out your
> enhancement
> > to the first decoder and trying to combine it
On Fri, 15 Apr 2016, Fredrik wrote:
Thanks for getting back to me. Again :) :) I'm trying out your enhancement
to the first decoder and trying to combine it with child-decoders from our
previous posts. I currently have this (which obviously doesn't work), but
how do I best create the
Hi Fredrik,
It is good progress. You can capture all events with:
^redirect \p|^prevent \p|^allow \p|^block \p|^mail System
Alert|\S+ alert Protection Name:
firewall
I know... It is not very elegant, but it controls all your events. Also,
you can add a tag in the beginning of the log
Hello Jesus!
Story continues. Just wanted to let you know that I have been able, with
help, to unify ALL the messages for easier handling in OSSEC. Thing is now
that the hostname is extracted automagically (by OSSEC) from the message
and I guess can't be used for my prematch, or?
Hello Jesus!
Story continues. Just wanted to let you know that I have been able, with
help, to unify ALL the messages for easier handling in OSSEC. It seems I
will be able to only use the hostname for the decoder (see new messages
samples below). However, how do I handle the fact that I would
Very sorry about the mistake with your name - hope I haven't done it
before!?
Will try out your much much appreciated suggestions for decoders over the
weekend! Very excited! :)
Thanks,
Fredrik
On Friday, April 1, 2016 at 1:18:17 PM UTC+2, Jesus Linares wrote:
>
> Hi Fredrik,
>
> here an
Hi Fredrik,
here an example of decoding allow/block events (with the option
*after_regex*):
^\w\w\w \d+ \d+:\d+:\d+ \S+
firewall
Checkpoint-test
^block|^allow
(\w+) \S+ \S+ src: (\d+.\d+.\d+.\d+); dst:
(\d+.\d+.\d+.\d+)
action,srcip,dstip
Checkpoint-test
resource:
Hi Jose,
I got some help to sort out the different timestamps (format) and all log
types now use "Jan 27 09:41:01". You asked about the firewall, this
particular one is a Checkpoint currently running version R77.20.
The remaining question, that might be of interest to others on the path to
Hi,
first, I would use the same format for both messages. Two options:
- Change log format in each device.
- Choose one:
- 1Mar2016 15:17:09 redirect st4600fw01n1
- Jan 27 09:41:01 127.0.0.1 Jan 27 9:32:28 st4600fw01n1
- This part could be your parent decoder
Hi Jesus,
Got sidetracked with other projects, and finally getting back to my
questions about handling different messages from the same device
(firewall). Also, Jesus your suggestion about placing a prematch in the
suggested decoder in this thread - what would be a good prematch here?
Hi Fredrik,
The expression "\.+" matches for anything. Usually, it is not a good idea
because is slow and maybe you capture something that you don't want. So, *when
it is possible*, it is better to use something specific.
When you have different decoders (different name) with the same parent,
Hi All,
In this context and with your great response. What would you PROs suggest I
do when decoding another type of message from the same firewall - but a
different blade (i.e. module). Turns out that the messages look somewhat
different. This is a sample from the other module and it won't
Hi (again) Jesus!
Big thanks for your time and effort! Greatly appreciated!
I tried your example below, to better understand why each decoder should
have a prematch. I haven't quite figured out yet, but I see (obviously)
that different results are produced. What would be a good prematch in my
Fantastic! Thank you so much! Makes sense what you wrote about my suggested
(mis)use of regex to try and get it start reading backwards. I should have
realised that wildcard (*) was the way to go, without having to match the
full string with the expressions available. I guess Jesus'
Hi,
I would add a *prematch *tag:
Checkpoint
**
(\w+) \p\w+ \w+
src:\s(\d+.\d+.\d+.\d+);\sdst:\s(\d+.\d+.\d+.\d+)
action,srcip,dstip
Checkpoint
\.*resource: (\.*);\.*product: (\.*);
url,extra_data
Each decoder must have a *prematch* tag. Try this example without
Hi Fredrik,
I don't think OSSEC allow regex to work backwards, from end to beginning, I
know that can be specify on other languages with some flags, but I am not
sure if we can do that here.
Regarding to your decoder, we have two options, include the extraction of
"resource" and product"
19 matches
Mail list logo
