the following patch makes things clear towards datastructure and
improves usability.
Previously, when defining/receiving rulesets, you'd never know whether
user meant source user or target user.
Even though it is almost always a target user, things were not clear enough.
For example, when doing:
toady@achilles% su root
Password:
su: Authentication failure
Sorry.
The following email will be now sent:
OSSEC HIDS Notification.
2007 Aug 02 16:18:52
Received From: achilles->/var/log/auth.log
Rule: 5302 fired (level 9) -> "User missed the password to change UID to
root."
Portion of the log(s):
Source User: toady
Target User: root
Aug 2 16:18:51 achilles su[29634]: - pts/3 str:root
--END OF NOTIFICATION
As you can see, the source user here is toady, whois is performing a su
into root.
In this patch, rulesets are updated, xml parser and analysis as well.
Feel free to provide any comments,
Thanks,
Sebastien.
Sorry for taking so long to reply, I was quite busy with the release of 1.3.
Anyway, your patched worked fine and it clarifies the internal structures of
ossec a bit, but I am afraid that it can make it more confusing for the users
writing rules and using ossec (which were used with the user field). It will
also break backwards compatibility with previous versions...
I am still struggling where this is the best option for both the code standpoint
and for the final user.
Anyone has other suggestions? If you didn't follow this thread, currently we
have "user" and "dstuser" on ossec. User is used all the time and "dstuser"
is only used with sudo and su. The proposed patch changes user to be "srcuser"
(internally) and on the rules/decoders, user becomes dstuser (as in target
user).
*btw, how is the prelude work going? Do you asked me for cvs access? I thought
so , but I can't record.. If yes, let me know and I will create an
account for you.
Thanks,
--
Daniel B. Cid
dcid ( at ) ossec.net
> Sorry for taking so long to reply, I was quite busy with the release of 1.3.
>
I understand! Moreover I was in holidays. By the way, congratulations
for 1.3!
> Anyway, your patched worked fine and it clarifies the internal structures of
> ossec a bit, but I am afraid that it can make it more confusing for the users
> writing rules and using ossec (which were used with the user field). It will
> also break backwards compatibility with previous versions...
>
That's right. But since it provides clarification, I think this change
is worth doing.
Why not going into 2.0 release with all stuff you would like to see
merged but breaking backward compatibility ?
If this is a path taken, that would be good to consider IDMEF [1] and
add elements in the datastructure that could complete the IDMEF message.
This would bring OSSEC to a standardized IDS regarding IDMEF (and ease
my work with prelude ;)).
> I am still struggling where this is the best option for both the code standpoint
> and for the final user.
>
> Anyone has other suggestions? If you didn't follow this thread, currently we
> have "user" and "dstuser" on ossec. User is used all the time and "dstuser"
> is only used with sudo and su. The proposed patch changes user to be "srcuser"
> (internally) and on the rules/decoders, user becomes dstuser (as in target
> user).
>
Why not writing scripts which perform the backward compatibility ?
> *btw, how is the prelude work going? Do you asked me for cvs access? I thought
> so , but I can't record.. If yes, let me know and I will create an
> account for you.
>
The work is done on 1.2. I asked the CVS access just to port the patch
to the state-of-the-art sources; A guest account is enough for what I
need to do.
Thanks,
Sebastien.