Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
That's not really accounting (since the .bash_history can be turned off or deleted by the user, I certainly wouldn't rely on it for anything security related). Your can use the accton command to turn on process accounting (see the man page for details).I think SELinux may have some monitoring tools too, but I'm not really up on that...
The main problem with people wanting to "monitor all the users commands and movement within the server" is that they do not specify the purpose for doing that (please elaborate) and do not know that judicial implications, governing network, security and privacy policies and machine and network ownership may prohibit blindly logging everything or prohibit you from doing it. The second main problem is people expect GNU/Linux to have some sort of on/off switch to enable centralised, all-encompassing, easy-to-correlate, human-readable logging which is not the case. The third problem is that people often have no idea what goes on process-wise between userland and the kernel.
To elaborate on what was said earlier: the problem is that the DAC rights of the history file match, and the process owner writing to the history file is the same, user who executes any commands to be logged.
This makes shell history logging (and any 'script'-like kludges):
- voluntary as the user can override system-wide settings, deny writing by reconfiguring or symlinking,
- susceptible to tampering by writing into it, modifying it or deleting lines, and
- also this type of logging is inexact because it does not log timestamps by default (only more recent bash can do that).
If you need shell history logging (and this goes for all typs of logging) you should know what you need to log in terms of expected output and use a logging patch (for Bash search for "Anotatla" or see the Honeypot project) or a syslog-capable shell wrapper (Rootsh or Sudosh) .
The problem with process accounting is simply that it does not log everything. I could elaborate further but I'd rather first read the OP write in detail about the purpose.
Basically i am designing our network to be PCI DSS compliance and a few of the conditions is to keep an audit off user activities on every server
i am not really bothered about the bacis commands but i do want to see if someone is copying our database dump or copying stuff they should not be
so i know the have right but also i have to meet the standards first then i can tune it.
Thanks "btmiller" for the accton will look into it.
My comment was inspired by how you phrased what you would or wouldn't log (e.g.: lacking absolute criteria). That just made me wonder (wrt PCI-DSS 10.2.1 - 10.2.7) if what you are doing will answer the "when, who, what, where, and where from" questions that an audit or investigation may ask. Maybe you have deployed other methods already but in case you haven't and are only enabling process accounting then the answer IMHO would be "no".