Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
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.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
An audit trail usually refers to enabling the linux (2.6+) audit subsystem to basically log system calls of the criteria you specify. You can install the tools for centos with (i think) up2date install audit.
Once that's done, you can use auditctl to control it, and use ausearch to search the audit trail for rules matching a specific criteria.
An audit trail usually refers to enabling the linux (2.6+) audit subsystem to basically log system calls of the criteria you specify. (..) search the audit trail for rules matching a specific criteria.
I disgree. Having an audit trail is not confined to kernel 2.6 as you can have one in 2.4 as well. Requirements should dictate if using Auditd is the right tool for the job or if it is enough. Auditd logging is not all-encompassing, unless you can determine from a line like this 'type=SYSCALL msg= arch= syscall=128 success=yes exit=0 a0=8067750 a1=c6fc a2=80611b8 a3=80611b8 items=0 ppid= pid= auid=666 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 comm="modprobe" exe="/sbin/modprobe"' what just got loaded, you'll see it only logs whats within its scope, and can not for instance log commandline or screen output.
You don't need the audit trail to see all the su's.
Problem is su's can overlap and it's hard to pin point which su'd user did which command. The su and login info is normally written to /var/log messages.
I have posted more than once in the past about auditing trails, maybe search this forum? One way could be to patch the kernel with GRSecurity as it allows for more finegrained logging and it seems it can currently live together with SELinux but I haven't tried that yet, the easiest way would be to use a "wrapper" shell like Rootsh. It logs all commands and screen output to either file or syslog. If run right the client can't mess with it (requirement) but can *flood* logs so next to only allowing trusted personnel in, this emphasises again that having an auditing trail *also* implies having a properly hardened box in the first place.
One way could be to patch the kernel with GRSecurity as it allows for more finegrained logging and it seems it can currently live together with SELinux but I haven't tried that yet,
Do you mean with the grsecurity's gradm or just the grsecurity kernel patches?
You don't need the audit trail to see all the su's.
Problem is su's can overlap and it's hard to pin point which su'd user did which command. The su and login info is normally written to /var/log messages.
You can use something like this in /etc/profile to separate the history of each su:
HISTFILE=`tty | sed -e 's/\///g'`.hist
export HISTFILE
Each su will generate its own history file with a tty in the name so you can trace it back to the individual login.
If I use auditd will I be able to know which user su'd to root and then ran the commands?
You should discourage or disable users su'ing to root and set these users up with sudo access. This can be simply be logged through syslog in most cases and it will usually notify the root user if they try to run a command they are not setup for, etc.
Unless you're wanting more details logged, I'd take the simple approach if this is all you're needing is who's su'ing to root and the like.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
