[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[ossec-dev] Re: Understanding EventInfo datastructure



Daniel Cid wrote:
>> However sometime you can get the source user. Which means there is a
>> need for srcuser and dstuser. In that case user means dst, which will
>> confuse anyone reading the datastructure unless you know it ;-) are you
>> ok to get patches for this ?
>>     
>
> I am always ok for patches :) I also don't like this usage of
> user/dstuser, but I don't
> like either srcuser/dstuser ... Basically, the way I like to think is
> user X on device Z,
> user A on device B, etc. The problem with dstuser started with sudo/su
> where you can
> have user X becoming Y on device Z.... Anyway, I am open to
> suggestions and patches
> to make it more clear.
>   

Or in the case of a remote application you also have a user X becoming Y.
We are always in the source/target scheme. We we connect to user X,
since it is a connection endpoint it is a target.

>
>   
>> Good! it is fixed now right ? in 1.3 only ? why not releasing a last 1.2
>> with prelude support and this fixed ?
>>     
>
>
> The port information on sshd? Nope :) We are currently on "locked" mode while
> we prepare for the version 1.3 (going to beta 2).  So, the prelude
> support will not be included on the version 1.3  too (unless you can
> finish it in a few hours :)).
>   

No :-) it will be for 1.4 then ?

> However, since we have very frequently releases, we can do a 1.4 very soon with
> prelude support and a few more things. What do you say?
>
>   

It is a good release management policy.

>
> True, that should be easy to do :) Btw, on prelude do you guys track
> application
> protocols, like httpd, sshd or in your protocol fields you only use
> tcp/udp/icmp/etc?
>
>   
Each application is responsible for filling correct data according to
what is specified from the IDMEF RFC.

If you are thinking of Prelude LML, this is defined in rulesets where
the ruleset maintainer, from what I can read, write the transport
protocol for the log matched. I think this could be improved using more
accurate information.

As for myself, since I am implementing the Prelude communication
capability in Ossec, I prefer having the application protocol, which is
better for analysis in case of an attack.

This is why I think it should be done in the datastructure whenever
possible.

Actually that could be nice to have two protocols in the data structure
(transport and application) in Ossec.



Thanks,
Sebastien.





OSSEC home | Main Index | Thread Index


OSSEC project: www.ossec.net.
Mailling list information: http://www.ossec.net/en/mailing_lists.html.