[CENTOS] [Linux] su, sudo settings

Prohibit basic users from becoming root And I want to leave a trail when using the sudo command The setting at that time.

I will write separately for CentOS 7 and Ubuntu 16.04.

1.1 su prohibition setting (CentOS)

Edit the /etc/pam.d/su </ font> file. Uncomment ʻauth required pam_wheel.so use_uid`.

/etc/pam.d/su


# Uncomment the following line to require a user to be in the "wheel" group.
auth required pam_wheel.so use_uid

With this, only users belonging to the wheel group can su, and others are prohibited.

1.2 su prohibition setting (Ubuntu)

The file is the same as CentOS, but the description of the item is changed. Add group = adm.

/etc/pam.d/su


auth required pam_wheel.so group=adm

ubuntu doesn't have a wheel group, so leave it as adm. → Only users who belong to the adm group can su It is a setting.

2. sudo settings (common)

visudo

Edit the / etc / sudoers </ font> file with the command.

How to write

visudo


[User name] ALL= (ALL:ALL) ALL

Specify the user to be authorized by [User name]. You can specify by group by adding% at the beginning.

The first ALL is permission for the host, so ALL is usually fine.

The second ALL is "Which user will you be?"

The third ALL is the group version above You can specify it by adding a colon (:). OK without

The fourth ALL is "Which command can be executed?" Write the command path separated by.

Also, adding a! At the beginning of the command means that it will not be executed.

visudo(Example)


%group01 ALL=(ALL:ALL) ALL,!/bin/su,!/usr/sbin/visudo,!/usr/bin/bash,!/usr/bin/sh,!/usr/bin/vi /etc/sudoers

→ group01 Users belonging to the group can execute all commands with sudo as all users. However, you cannot edit su and sudoers files.

By the way, You can also combine the commands you want to prohibit into one.

visudo(Summarize prohibited commands)


##kinshi
Cmnd_Alias KINSHI = /bin/su,/usr/sbin/visudo
dangogrp ALL=(ALL) ALL, !KINSHI 

Like this. Prohibit su command and sudoers editing with sudo to prevent the prohibition setting itself from being changed.

※ The above methods cannot be completely banned and there are loopholes. For example, copy a shell command to another directory, rename it, invoke an external command, use a shell command other than those prohibited above. As a countermeasure, there is a whitelist format for command permission, but I feel that the operation is difficult ...

3 Leave a trail of sudo (only syslog configuration file differs depending on OS)

The execution result itself is spit out in the audit log, CentOS：/var/log/secure Ubuntu：/var/log/auth.log

Since these files will be buried in the execution result, let's change the output destination. Create a file to output the log and change the owner and group. (CentOS log file owner is root, so no change is OK)

touch /var/log/sudo.log
chown syslog /var/log/sudo.log
chgrp adm /var/log/sudo.log

Settings in / etc / sudoers

visudo

Set to transfer to syslog with. Added below the place where Defaults are lined up

visudo(/etc/sudoers)


# sudo log
Defaults syslog=local3

The local3 part can be any of 0-7. With a vacant one.

syslog settings

・ For Centos

vi /etc/rsyslog.conf 

・ For ubuntu

vi /etc/rsyslog.d/50-default.conf

Add the following. Match it with the local number.

#sudo log
local3.*　　　　-/var/log/sudo.log

Syslog service restart

systemctl restart rsyslog

This will leave a trail of the sudo command in /var/log/sudo.log. If you try running the ls -l command with root privileges, 
sudo ls -l /

It remains in the log like this.

/var/log/sudo.log


May 28 14:16:10 host01 sudo: user01 : TTY=pts/0 ; PWD=/home/user01 ; USER=root ; COMMAND=/bin/ls -l

With this, even if the user types a bad command with root privileges, he can identify and preach.

That's it