• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1035
  • Last Modified:

Tracking Root Activities (Linux)

How can track users activities, especially root user under openSuse 10.2. I know about the history command and the .bash_history file. However, I am looking for a log file that records all userss activities with dates, commands, files names and other information...  
I am looking for a best practice method to keep track of users activities?

Thanks in advance

-AbdellahT
0
AbdellahT
Asked:
AbdellahT
  • 4
  • 3
  • 2
  • +1
1 Solution
 
mp022Commented:
Direct root logins should be allowed only for emergency use. In normal situations, the administrator should access the system via a unique unprivileged account, and use su or sudo to execute privileged commands. Discouraging administrators from accessing the root account directly ensures an audit trail in organizations with multiple administrators.

Root should also be prohibited from connecting via network protocols like SSH.
1 - In /etc/sshd you should set PermitRootLogin=no

The sudo command allows fine-grained control over which users can execute commands using other accounts. The primary benefit of sudo is that it provides an audit trail of every command run by a privileged user (var/log/secure). It is possible for a malicious administrator to circumvent this restriction, but, if there is an established procedure that all root commands are run using sudo, then it is easy for an auditor to detect unusual behavior when this procedure is not followed.
2- Add all administrators to the wheel group
3- Edit the file /etc/sudoers and uncomment the line
%wheel ALL=(ALL) ALL


0
 
joolsCommented:
auditing?

loads of information on the net, this gives an overview, I'll see if I can find a more detailed doc.

   http://www.cyberciti.biz/tips/linux-audit-files-to-see-who-made-changes-to-a-file.html
0
 
joolsCommented:
also found this;

http://secureaudit.sourceforge.net/

You dont want to audit too much or your logs will fill up with unimportant information and you'll then miss something critical.

Just keep auditing to important areas and files.

0
Cloud Class® Course: Microsoft Azure 2017

Azure has a changed a lot since it was originally introduce by adding new services and features. Do you know everything you need to about Azure? This course will teach you about the Azure App Service, monitoring and application insights, DevOps, and Team Services.

 
arrkerr1024Commented:
You just need to enable process accounting. The kernel will keep a log of executed commands.  This is a fail-safe way to catch everything, rather than having to know what files you want to watch (which also has its place, of course).

BTW, the first poster is right about sudo, however you do NOT want to enable ALL=ALL.  Any user could then "sudo su -" and become root, and you have no more logging.
0
 
AbdellahTAuthor Commented:
Thanks guys,

I added admins accounts to the wheel group in the /etc/group file.
I changed the sudors file to read %wheel ALL=(ALL) ALL
Then i created a test account called test. but the test account can still su(not sudo su) to the root account.
I thought by adding users to the wheel group will prevent everybody else from suing to root shell
or is there something i am missing?

Thanks
0
 
joolsCommented:
su still means you have to enter a password so it's still secure.

you could, I guess, rename it so only admins know to run sume, for example :-)
0
 
joolsCommented:
also, su attempts are logged in /var/log/secure
0
 
mp022Commented:
Poster arrkerr1024 has a point.
Process accounting will help you get what you want. See
http://www.cyberciti.biz/tips/howto-log-user-activity-using-process-accounting.html

That, combined with my previous best practices recommendation, will record who is doing what on the server. Even if the admin uses su to become root. That's because now you can see who issued the command to become root as well as what he did as root.

Of course, any user who becomes root can delete records from the local logs. So, if you are concerned about that, you should be saving these logs to another server where these admins don't have access. From here it becomes a matter of how paranoid do you need to get...
0
 
mp022Commented:
If your test user was able to use sudo, then check the /etc/sudoers file for other group permissions (start with %) assigned there. All of the group permissions should be commented out except for the "%wheel..." line.
0
 
AbdellahTAuthor Commented:

Hi all

I used the acct tool on openSuse. However it does not provide enough valuable information. For example, the lastcomm utility prints out the following output.

vi                    testuser stderr     0.10 secs Thu Nov 13 11:01
su                   testuser stderr     0.02 secs Thu Nov 13 11:02

I would like to know the arguments passed to the commands for example;The vi command was vi /etc/passwd, but the output I would not be able to know which file the user tried to modified or has modified.

Sudos approach gives better logging.

Sudo.log entry:

Nov 13 11:27:20 : testuser : TTY=pts/0 ; PWD=/var/log ; USER=root  COMMAND=/usr/bin/vi /etc/passwd


The issue I have with sudo is that I want to be able to get the same logging when a user su and get the root shell; wheel users including root does not have to use sudo to execute system commands after they su, therefore I would not be able to track their activities in sudo.log or any other log file. So I thought of prevent su-ing completely, that way I will force everyone to use sudo.

What do you guys think about this?

By the way thanks to you all,

Abdellah


0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Cloud Class® Course: Certified Penetration Testing

This CPTE Certified Penetration Testing Engineer course covers everything you need to know about becoming a Certified Penetration Testing Engineer. Career Path: Professional roles include Ethical Hackers, Security Consultants, System Administrators, and Chief Security Officers.

  • 4
  • 3
  • 2
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now