On 07/06/2011 08:00 PM, Jeremy Lee wrote:
Thanks Michael.
I guess that means that in the actual alert, once it triggers, the alert
will come from whatever box it got triggered at?
Well, the *alert* actually comes from the OSSEC manager, and the alert
will contain the logs that compromise the composite alert.
So if I have web1, web2, web3 and web 4, and have a rule setup to send
an alert after the same IP is seen 3 or more times, and the request goes
as such:
GET web1/index.html
GET web2/index.html
GET web3/index.html
*GET web4/index.html*
Then the one I put in bold will always show up as the one sending the
alert no? Or the source of the alert may get shuffled eventually if it's
a one-off type of thing.
Am I roughly right in my understanding?
I think you have the idea. Just remember that to OSSEC, these are all
just strings of text. The decoders determine the meaning. When a
composite alert is sent, the email will contain the location of the last
one to trigger the alert.
If this is the case, this could become somewhat misleading and not work
out so well for AR (especially if it's setup to fire locally per box
where the source alert came from).
Yes, I would not expect AR to work as you might expect with composite rules.
Basically, if an alert based on same source IP across multiple servers
is triggered, I'd want to be able to see *all* the servers that were
touched by that IP leading up to the alert.
I think you need to restrict the alerts to the same src IP so that they
can be individually blocked. You'll notice that there are already rules
that do this.
