Operating System - HP-UX
1827435 Members
5302 Online
109965 Solutions
New Discussion

User and group changes monitor

 
Isgleas
Occasional Advisor

User and group changes monitor

Hey there,

We have a mixed Unix environment, with HP-UX 11.X servers (100+). I'm looking after a method for monitor changes on the user and/or group database on both trusted and untrusted deploys.

I've tried turning on auditing with "-P -F -e admin", and such events gets logged but I can't figure out how to read the audisp output:

081029 12:05:51 17892 S 57 8783 0 0 3 0 3 ?????
[ Event=utssys; User=root; Real Grp=sys; Eff.Grp=sys; ]

RETURN_VALUE 1 = 0;
PARAM #1 (addr of char) = 2139039088
PARAM #2 (int) = 0
PARAM #3 (int) = 0
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Seems "Event=utssys" is a generic ID for admin class, and user is always root even if done by su or sudo calls. So audit seems not to fullfil the requirements.

Do you know any other way to achieve the task? Default Unix tools would be preferrable method, I've considered tools like HIDS, Bastille or Tripwire, but in such a large environment it would add a complexity layer.

Version control on the files/databases would be another approach, but it'd require cron jobs running within every few seconds which may increase load, and cannot insure tracing for the user. This could be a second stage task.

Any Ideas?
Thnx.
7 REPLIES 7
Dennis Handly
Acclaimed Contributor

Re: User and group changes monitor

>I've tried turning on auditing with "-P -F -e admin", and such events gets logged

What events are you logging and what command?

>I can't figure out how to read the audisp output:
081029 12:05:51 17892 S 57 8783 0 0 3 0 3 ?????
[ Event=utssys; User=root; Real Grp=sys; Eff.Grp=sys; ]

It says the utssys, uname(2), was made by root.

>RETURN_VALUE 1 = 0;
>PARAM #1 (addr of char) = 2139039088

It had a good return.

>Seems "Event=utssys" is a generic ID for admin class

No, it is a system call.

>user is always root even if done by su or sudo calls. So audit seems not to fulfill the requirements.

What requirement? I don't see two users logged. But you should be logging su/sudo calls, if that makes a difference.
Isgleas
Occasional Advisor

Re: User and group changes monitor

'audsys -n' to turn on the audit system, then set the events to be audited with 'audevent -P -F -e admin' and get 'audisp -e admin audfileX' to display the records.

Still got no clue on how to read the headers of every record. You mention the 'uname' triggered the auditable event, but I don't see where you read that. Is there a list of codes for those events?

The main idea is to know if there have been any changes to the users or groups databases, no matter if it was done by commands like useradd, usermod, userdel, groupadd, etc, or via SAM. I do not want to restrict such changes, but to know when and who did.

I do log su/sudo, but still cannot identify the real ID of the user that made the change, but the effective ID. I was expecting that auditing "admin" events could cover it, but can't identify which system calls could fit.
Isgleas
Occasional Advisor

Re: User and group changes monitor

Found this link ( http://docs.hp.com/en/B2355-90121/apas01.html#jumpid;reg_R1002_USEN&pos=1 ), where the audit record format is explained.

Still unsuccessful on the user/group databases change tracing, do you monitor/audit those events? how?

Thnx
Dennis Handly
Acclaimed Contributor

Re: User and group changes monitor

>You mention the 'uname' triggered the auditable event, but I don't see where you read that. Is there a list of codes for those events?

utssys is the system call for uname(2). There may be a header named *syscall* or or something that lists the numbers. But that will just say UTSSYS?
Appendix B lists them:
http://docs.hp.com/en/B2355-90121/apb.html

>The main idea is to know if there have been any changes to the users or groups databases, no matter if it was done by commands like useradd, usermod, userdel, groupadd, etc, or via SAM.

Well, if everyone used sudo, it would be logged. If you use auditing, then every open/write for every file will be logged. But I guess you can limit it to only logging root.

>I do log su/sudo, but still cannot identify the real ID of the user that made the change, but the effective ID.

Why not? You go through sulog and match up the times?

>I was expecting that auditing "admin" events could cover it, but can't identify which system calls could fit.

Well, open on those files.

>Still unsuccessful on the user/group databases change tracing

There doesn't seem to be an unique event for those. It's probably through the open system call.
Isgleas
Occasional Advisor

Re: User and group changes monitor

> Well, open on those files.
> There doesn't seem to be an unique event for those. It's probably through the open system call.

Audit the open system call would fill up storage quickly, would be the success of write system calls and then catch the selected ones.

As I told earlier, I'm trying to make the event logging done as trasparent as I can, without any more coding.

I'll try setting up a custom audit class after events grpck, pwck, newgrp, passwd and sam, and see if that'd do the trick.
Dennis Handly
Acclaimed Contributor

Re: User and group changes monitor

newgrp is like login(1), probably a waste of time to log.

If you had LDAP? or NIS (won't work with trusted), you could just restrict access to that machine and would only need to monitor that machine.
Isgleas
Occasional Advisor

Re: User and group changes monitor

> newgrp is like login(1), probably a waste of time to log.

Maybe, but it's not up to me to decide that (login logging is achieved through other methods, and as far as I know, audit login won't work for ssh sessions)

> If you had LDAP? or NIS (won't work with trusted), you could just restrict access to that machine and would only need to monitor that machine

Quite complex scenarios, every login to every machine has to obtain "blessing" from the security team, then ask provisioning to add the IP to ACL (temporaly), then, and then, and then... The problem is not knowing who logs in, but identify if in the meaning of the session a user/group change occurred, ASAP.

Right now, keystroke logging is the method, figure out the time needed to find useful info. Such hardened scenario is great, and auditing gets all the info needed, but in a slow response.

That's why I don't want to add any other layer of complexity, meaning coding or maintaining extra apps.

I have not developed such processess, I cannot change them either, Is not up to me to determine if it is the best model to follow, but is up to me to suggest alternatives, and I just won't suggest adding any other application if the OS native tools can provide with minimal configuration (not coding).

Regards,