Audit logging of all Unix Flavours

[Security_1]

Hi,

We have around 1000 boxes of UNIX, Solaris, Linux, HP-Unix and AIX. We would like to have audit logging and would like to send all Syslog from these boxes to a SIM tool.

My questions are:

1) If some user or root user, creates/modifies/deletes user accounts/groups will those actions get logged in the Syslog of all the boxes mentioned above. If it is not possible on all UNIX flavors then what are those flavors on which these actions will be logged in to Syslog and for the rest of flavors on which these actions will not be logged, what is the procedure to follow to enable the same to make sure those actions are logged into Syslog?

2) I have also found that create/modify/delete accounts actions could be performed other than running commands directly, I mean a person could modify the /etc/password file directly to do those actions and this would not be captured in the Syslog. Is that true? If yes, then how to go about logging the same into the Syslog

Hope my information is clear enough.

Thanks!

[Rick Garland]

With the various flavors you might want to look into tripwire. You can make the configuration to be standard across the flavors and can be configured to email the admins and put an entry into the syslog on the respective system.

[Security_1]

To add to the my questions above: I found few work arounds:

1)Keep an old copy of the file somewhere and then compare it at scheduled times (eg. every day at noon), any changes to the file should be audited.
2) Modify /usr/lib/security/mkuser.sys, this is being executed during user creation process. Use â logger" to generate a custom event. Of course this would not prevent a compromised root account user from changing the script back and adding users without being noticed.
3) Using File Integrity Monitor like tripwire
or
4) Powerbroker

However, we still prefer if all those actions could be audit logged via some kind of script or configuration to make use of syslog itself (into SIM tool) instead of alternative solutions.

Any thoughts!!?

Thanks

[WSM_1]

As a consultant might suggest, "It depends." ï

Such a BIG question is going to have a big answer, unless you use a third party with more resources like Tripwire which Rick mentioned above. Tripwire has support for: Windows, Solaris, Linux, HP-UX, AIX, IBM. Tripwire also has solutions for Databases, Desktops, and Network devices. If you specialize in something, it's more likely to be what you do best.

Those system you mentioned are Unix like, but not all are a like when it comes to detailed auditing, so solutions are going to vary, unless you have a third party application that has been created for each platform, and to the end user it works the same although it's really different in the background. The installs steps will be different as well, unless Tripwire has automated that these days.

It's worth noting that there are work a rounds with almost any solution, given time and knowledge. I've never seen a system that provides a service which hasn't had a security patch at some point. If someone is expecting someone with bad intentions (as all System Admins should) or just limited knowledge with creatively driven thought processing for getting things done in other manners that the best manner, which isn't always the normal way, you should consider multiple implementation. At any point, one shared solution could leave you blind.

It's not just user additions that should be concern. It's easier to use existing users. Each system has its own expectations as to what is normal and what isn't. An example would be, if you had an application system in which shell access was rarely needed, you would want to monitor any time someone even made a connection by other means than the primary application.

Systems loaded on the internet should only have CORE features/packages/applications loaded and none that are not required, this then limits what additional tools the hacker or you will have to cause problems.

Finally, specific implementations recommended in detail, in a public forum for example, might leave others to assume that the person recommending such tools actually uses them in their workplace. I would caution anyone providing too many details for used solutions. Although this is often the argument to Open Source being secure since everyone that cares has the opportunity to review security and make suggestions are keep them to themselves. In case you do share, be sure to use some anonymity. ï

W

PS - I'm in the book.

[F Verschuren]

yes this is poseble,
please be aware that the normal syslog is not encripting over your network so sending vital information though the network is not verry advisable,
example somebody id typing his passwd instet of user name, a unsucssful passwd login wil be in the syslog, some secents later a succesfull passwd atemt form the same ip is logged. so if there is one server in the network that is reading trou the network your user name and passwd where "mailed" to him. If you do not trust all systems on you network (if you do you please change you name...) you can use syslogng (this will incript the netwerk trafic.

changes to the passwd file are not logged in the syslog, if you want that you need to create scripting arount that. whithin my company we have some discriptions how to do this. I can not chare them here du to that sharing the way your securty is built, is helping hackers a lot....