Basic Linux protection measures

1. Case 1:linux Basic protection measures
2. Case 2: Assigning administrative rights with Sudo
3. Case 3: Improve SSH service security
4. Case 4:selinux Safety Protection
1 Case 1:linux Basic protection measures
1.1 Questions
This case requires practicing the basic safeguards of the Linux system to accomplish the following tasks:
1. Modify the user Zhangsan account attributes, set to 2019-12-31 Day expiration (no login)
2. Temporarily lock the user Lisi account so that it cannot log in, verify the effect and unlock it
3. Modify the TTY terminal prompt so that the first line of text you see before login is "Windows Server Enterprise R2" and the second line is "NT 6.2 Hybrid"
4. Lock the file/etc/resolv.conf,/etc/hosts, to prevent its contents from being unintentionally modified
1.2 Steps
The implementation of this case needs to follow the steps below.
Step One: Modify the user Zhangsan account attributes, set to 2019-12-31 Day expiration (no login)
1) Under normal circumstances, non-expired accounts can log in normally, using chage can modify the validity of the account.
Syntax format for 1.chage commands:
2.chage–l???? Account name???????????????????????????????? View account Information
3.chage–e Time Account name???????????????????????????? Modify your account validity period
2) Invalid user will not be able to log in
Use the Chage command to set the user Zhangsan account to be currently invalidated (for example, a time that has elapsed):
1.[[email protected] ~]# useradd Zhangsan
2.[[email protected] ~]# chage-e 2015-05-15 Zhangsan
Try to re-login with the user Zhangsan, enter the correct user name, password and then flash back, return to the login page, stating that this account is invalid.
3) Reset the user Zhangsan attribute, set the expiration time to 2015-12-31
1.[[email protected] ~]# chage-e 2019-12-31 Zhangsan???????????? Modify Expiration Date
2.[[email protected] ~]# chage-l Zhangsan???????????????????? View account Age Information
3.Last Password????????????????????: May 15, 2017
4.Password Expires????????????????????: Never
5.Password Inactive????????????????????: Never
6.Account expires????????????????????????: Dec 31, 2019
7.Minimum number of days between password change????????: 0
8.Maximum number of days between password change????????: 99999
9.Number of days of warning before password expires????????: 7
4) Define the default validity period (extended knowledge)
/etc/login.defs This configuration file determines the default expiration date of the account password.
1.[[email protected] ~]# cat/etc/login.defs
2.pass_max_days???? 99999???????????????????????? Maximum password duration
3.pass_min_days???? 0???????????????????????????? Minimum password expiration
4.pass_min_len???? 5???????????????????????????? Minimum password length
5.pass_warn_age???? 7???????????????????????????? Prompt warning message days before password expires
6.uid_min???????????????? UID Minimum value
7.uid_max 60000???????????????? UID Maximum value
Step two: Temporarily lock the user Lisi account, make it unable to log in, verify the effect unlocked
1) Lock user account
Use the passwd or USERMOD command to lock the user's account Lisi.
1.[[email protected] ~]# passwd-l Lisi???????????????????????? Lock user account Lock
2. Lock the password of the user Lisi.
3.PASSWD: Successful operation
4.
5.[[email protected] ~]# passwd-s Lisi???????????????????????? To view state status
6.lisi LK 2018-02-22 0 99999 7-1 (password has been locked.) )
2) Verify that the user Lisi is unable to log in, indicating that the lock is active
Enter the correct user name, password, always prompt "login incorrect", unable to log in.
3) Unlock the user Lisi
1.[[email protected] ~]# passwd-u Lisi???????????????????????? Unlock user account
2. Unlock the user Lisi password.
3.PASSWD: Successful operation
4.
5.[[email protected] ~]# passwd-s Lisi???????????????????????? View status
6.lisi PS 2018-08-14 0 99999 7-1 (password is set, use SHA512 encryption.) )
Step Three: Modify the message of TTY login, hide the system version
1) The login information (including operating system kernel information) is displayed by default when the account is logged into the Linux system.
/etc/issue This configuration file is stored in the login information, modify the file to prevent the disclosure of the kernel information.
1.[[email protected] ~]# cat/etc/issue???????????????????????????? Confirm Original File
2.Red Hat Enterprise Linux Server release 6.5 (Santiago)
3.Kernel \ R on \m
4.
5.[[email protected] ~]# cp/etc/issue/etc/issue.origin???????????? Backup files
6.
7.[[email protected] ~]# vim/etc/issue???????????????????????????? Modify File Contents
8.Windows Server Enterprise R2
9.NT 6.2 Hybrid
2) test version camouflage effect
Exit the logged-in TTY terminal, or restart the Linux system, the refreshed terminal prompt will become a custom text content, as shown in 1.

Figure-1
Step four: Lock files/etc/resolv.conf,/etc/hosts
1) syntax format:
1.# chattr +i file name???????????????????? Lock files (cannot be modified, deleted, etc.)
2.# chattr-i file name???????????????????? Unlocking files
3.# chattr +a file name???????????????????? Files can only be appended after locking
4.# chattr-a file name???????????????????? Unlocking files
5.# lsattr file name???????????????????????? viewing File Special properties
2) Use +i to lock files, use Lsattr to view properties
1.[[email protected] ~]# chattr +i/etc/resolv.conf/etc/hosts
2.[[email protected] ~]# lsattr/etc/resolv.conf/etc/hosts
3.----I--------e-/etc/resolv.conf
4.----I--------e-/etc/hosts
2) test file lock effect
1.[[email protected] ~]# rm-rf/etc/resolv.conf
2.RM: Unable to delete "/etc/resolv.conf": Operation not allowed
3.[[email protected] ~]# echo "192.168.4.1 gateway.tarena.com" >>/etc/hosts
4.bash:/etc/hosts: Insufficient Authority
3) Restore the original properties of these two files (to avoid impact on subsequent experiments)
1.[[email protected] ~]# chattr-i/etc/resolv.conf/etc/hosts
2.[[email protected] ~]# lsattr/etc/resolv.conf/etc/hosts
3.-------------e-/etc/resolv.conf
4.-------------e-/etc/hosts
2 Case 2: Assigning administrative rights with Sudo
2.1 Questions
This case requires that the sudo mechanism be used to assign administrative operations permissions, which mainly accomplish the following tasks:
1. Use the SU command to temporarily switch account identities and execute commands
2. Allow Softadm to manage system service permissions
3. Allow users to add/remove/modify user accounts except root useradm via sudo
4. Allow wheel group members to execute commands under/usr/bin/with privileges
5. Enable logging for the sudo mechanism so that sudo can be tracked to perform actions
2.2 Steps
The implementation of this case needs to follow the steps below.
Step one: Use the SU command to temporarily switch account identities and execute commands as root
The SU (substitute user) command can switch the account identity quickly, the ordinary user needs to enter the password when switching the account identity, the root uses the SU command to switch any identity does not need the password, in the law format as follows:
1.# su–[account name]
2.# Su-[account name]-C ' command '
1) switch from normal user to root account (if no regular account is required to create first)
1.[[email protected] ~]# WhoAmI
2.jacob
3.[[email protected] ~]# su–???????????????????? Switch account, switch to root account by default
4. Password:
5.[[email protected] ~]# whoami???????????????????? Confirm Results
6.root
2) Create directory in normal status (if no regular account is required to create first), restart the service as root
1.[[email protected] ~]# su-tom-c "Mkdir/home/tom/test"???????? Admin switch for normal users
2.[[email protected] ~]# ll-d/home/tom/test
3.[[email protected] ~]# Su-C "systemctl restart sshd"???????????? Restart the service with the administrator
4. Password:
5. SSHD.SERVICE-OPENSSH Server Daemon
6.loaded:loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset:enabled)
7.active:active (running) since five 2018-01-19 08:59:40 CST; 1 months 4 days ago
Step two: Allow Softadm to manage system service permissions
1) Modify the/etc/sudoers configuration
Modify/etc/sudoers to edit the file directly using Vim, or modify the file using the Visudo command.
Grant Softadm the Execute permission for the relevant script, allowing the system services to be managed through the Systemctl tool.
If you do not have a SOFTADM account you can create it first.
1.[[email protected] ~]# vim/etc/sudoers???????????? After modifying a file, you need to use WQ to force the Save
2 .....
3.softadm all= (All)/usr/bin/systemctl????????
4.//Authorization Softadm Execute systemctl command as root
2) switch to Softadm user and verify sudo execute permissions
1.[[email protected] ~]# Su–softadm
2.[[email protected] ~]$ sudo-l
3 .....
4.[sudo] Password for softadm:???????????????????????? Enter the password for the Softadm
5 .....
6. User Softadm can run the following command on the host:

8. (All)/usr/bin/systemctl

10. 9.[[email protected] ~]$ systemctl start httpd???????????????? Start service failure without sudo
    10.Authentication is required
    11 .....
    12.[[email protected] ~]$ sudo systemctl restart httpd???????? Start the service successfully with Sudo
    Step three: Allow user useradm to add/remove/modify user accounts other than root by sudo
    1) Modify the/etc/sudoers configuration
    Grant the user the Execute permission to manage related commands for Useradm, and the exception is reversed with a! Symbol and placed behind. Wildcard characters can be used when executing a related program .
    1.[[email protected] ~]# vim/etc/sudoers
    2 .....
    3.useradm all= (All)/usr/bin/passwd,!/usr/bin/passwd Root,/usr/sbin/user,

12. !/usr/sbin/user Root
    2) switch to Useradm user, verify sudo permissions
    You can add/remove/modify regular users via sudo:
    1.[[email protected] ~]# Su–useradm
    2.[[email protected] ~]$ sudo-l
    3 .....
    4. User Useradm can run the following command on the host:
13. (root)/usr/bin/passwd,!/usr/bin/passwd root,/usr/sbin/user,
    6.!/usr/sbin/user Root
    7.[[email protected] ~]$ sudo useradd newuser01???????????????? You can add users
    8.[[email protected] ~]$ sudo passwd newuser01???????????????? You can modify passwords for ordinary users
    9. Change the password of the user Newuser01.
    10. New Password:
    11. Re-enter the new password:
    12.PASSWD: All the authentication tokens have been successfully updated.
    However, the root user's password cannot be modified:
    1.[[email protected] ~]$ sudo passwd root
    2. Sorry, user useradm is not entitled to root on localhost
    3. Execute/USR/BIN/PASSWD root.
    Step four: Allow wheel group members to execute all commands under/bin/with privileges
    This case is used to demonstrate the convenience of sudo and the risk of improper setting, using caution in production environments.
    When implemented, refer to the following actions (if no ordinary user creates the account first):
    1.[[email protected] ~]# vim/etc/sudoers
    2 .....
    3.%wheel all= (All)/bin/
    4.[[email protected] ~]# usermod-a-G wheel Zengye
    5.[[email PROTECTED]SVR5 ~]$ sudo-l
    6 .....
    7. User Zengye can run the following command on the host:
    8. (root)/bin/*
    Step five: Enable logging for the sudo mechanism so that sudo can be tracked to perform actions
    1) Modify/etc/sudoers configuration, add log Settings
    1.[[email protected] ~]# Visudo
    2.Defaults logfile= "/var/log/sudo"
    3 .....
    2) perform sudo operation with root (all permissions by default)
    1.[[email protected] ~]# sudo-l???????????????????????????????? View authorized sudo actions
    2.[[email protected] ~]# sudo systemctl status httpd???????????? View authorized sudo actions
    3) Confirm that the log record is in effect
    1.[[email protected] ~]# Tail/var/log/sudo
    2 .....
    3.May 22:14:49:ROOT:TTY=PTS/1; Pwd=/root; User=root; Command=list
    4.Feb 22:35:43:SOFTADM:TTY=PTS/11; Pwd=/home/softadm; User=root;
14. Command=/bin/systemctl Status httpd
    3 Case 3: Improving SSH Service security
    3.1 Questions
    This case requires increasing the security of the SSH server on the Linux host to accomplish the following tasks:
    1. Configure basic security Policy (no root, no null password)
    2. Only allowed policies are used for SSH access, and users who are not explicitly listed are denied login
    3. Implement key authentication login (private key password), password-free login
    4. After confirming that the key verification is working properly, disable password verification
    3.2 Steps
    The implementation of this case needs to follow the steps below.
    Step One: Configure the basic security policy
    1) Adjust the sshd service configuration and reload the service
    1.[[email protected] ~]# vim/etc/ssh/sshd_config
    2 .....
    3.Protocol 2???????????????????????????????????????? Remove SSH Protocol V1
    4.PermitRootLogin No???????????????????????????????? Disable root User Login
    5.PermitEmptyPasswords No???????????????????????????? Prohibit user login with password blank
    6.UseDNS No???????????????????????????????????????? Client Address not resolved
    7.LoginGraceTime 1m???????????????????????????????? Login time limit
    8.MaxAuthTries 3???????????????????????????????????? Maximum number of authentications per connection
    9 .....
    10.[[email protected] ~]# systemctl restart sshd
    2) test the basic security policy
    Attempt to log in as root user ssh, failed:
    1.[[email protected] ~]# ssh [email protected]
    [email protected] ' s password:
    3.Permission denied, please try again.
    If you set the password for the user Kate on the server to empty, such as if no account was created first, attempting SSH login will also fail:
    1.[[email protected] ~]# passwd-d Kate???????????????????????? Clear User Password
    2. Clear the user's password Kate.
    3.PASSWD: Successful operation

15. 5.[[email protected] ~]# ssh [email protected]
    [email protected] ' s password:
    7.Permission denied, please try again.
    Step two: Use only allowed policies for SSH access, and users who are not explicitly listed are denied login
    1) Adjust the SSHD service configuration, add the Allowusers policy, allow only the user Zengye, John, Useradm, where useradm can only log in from the network segment 192.168.4.0/24.
    1.[[email protected] ~]# vim/etc/ssh/sshd_config
    2 .....
    3.AllowUsers Zengye John [email protected]/24???????????? Define a whitelist of accounts
    4.# #DenyUsers USER1 USER2???????????????????????????????? Define the account blacklist
    5.# #DenyGroups GROUP1 GROUP2???????????????????????????? Define a group blacklist
    6.# #AllowGroups GROUP1 GROUP2???????????????????????????? Define a group whitelist
    7.[[email protected] ~]# systemctl restart sshd
    2) to verify SSH access control, unauthorized users will be denied login.
    1.[[email protected] ~]# ssh [email protected]???????????????? Authorized users are allowed to sign in
    [email protected] ' s password:
    3.[[email protected] ~]$ exit
    4.[[email protected] ~]# ssh [email protected]???????????????? Unauthorized user is denied login
    [email protected] ' s password:
    6.Permission denied, please try again.
    Step three: Implement key pair authentication login (private key password), password-free login
    1) Prepare the client test environment
    To establish an SSH key pair for the user root of the client
    Using Ssh-keygen to create a key pair, set the private key password to null (direct carriage return):
    1.[[email protected] ~]$ ssh-keygen-t RSA
    2.Generating public/private RSA key pair.
    3.Enter file in which to save the key (/ROOT/.SSH/ID_RSA):
    4.Created directory '/root/.ssh '.
    5.Enter passphrase (empty for no passphrase):???????????? Direct enter to set password to NULL
    6.Enter same passphrase again:???????????????????????????? Enter again to confirm
    7.Your identification has been saved In/root/.ssh/id_rsa.
    8.Your public key has been saved in/root/.ssh/id_rsa.pub.
    9.The Key fingerprint is:
    10.63:6e:cf:45:f0:56:e2:89:6f:62:64:5a:5e:fd:68:d2
    11.The key ' s randomart image is:
    12.+--[RSA 2048]----+
    13.| |
    14.| |
    15.| . . . |
    16.| = = |
    17.| S = B. |
    18.| o B =. o |
    19.| + + = E. |
    20.|. + + O |
    21.| o |
    22.+-----------------+
    23.[[email protected] ~]$ LS-LH ~/.ssh/id_rsa*???????????????? Confirm Key Pair File
    24.-RW-------. 1 root root 1.8K August 10:35/root/.ssh/id_rsa
    25.-rw-r--r--. 1 root root 403 August 10:35/root/.ssh/id_rsa.pub
    2) Deploy the public key of the user root on the client computer to the SSH server
    Log in to the client as user root and use the Ssh-copy-id command to deploy your public key to the server:
    1.[[email protected] ~]$ Ssh-copy-id [email protected]
    [email protected] ' s password:
    3.Now try logging into the machine, with "ssh" [email protected] ' ", and check in:

16. . Ssh/authorized_keys
    5.to Make sure we haven ' t added extra keys so you weren ' t expecting.
    3) Confirm the public key information uploaded by the client user root on the server
    The default deployment location is the target user's home directory under the ~/.ssh/authorized_keys file:
    1.[[email protected] ~]# tail-2 ~/.ssh/authorized_keys
    2.ssh-rsa aaaab3nzac1yc2eaaaabiwaaaqeazz+5aifmgq7lfuiv7ebnocmro9jrtcqroyngo2y5
    3.ryfl+lxr1ipebknruyizdk5uax1y8rwsf+pa7uz2nyqmuevnsuo0hqydgsu9spyadzrccvdgwpofhahi/ofnt+ zqjaqxh2m9ffyevuu4pivl8ht19zcqrvz/q3acqa34usqur0ppljaobsf1ble2edm8bsshckdgsnodt9vk+ u3e83raehbmuy1cven5slaairieym8q0wxqnlqknl908hrktltekrrohbmnobfj8stwlnsckhlkrskkhuf8a9wwz/ vl4gdwgnd5jdca3i2hditaysjmdfl1hmhnmyogmjpm0q== [email protected]
    4) test the SSH key pair verification on the client
    In the context of the client user root, when logging in to the 192.168.4.5 host with the remote user root, you can log in without verifying the password (because the private key password is empty):
    1.[[email protected] ~]$ ssh [email protected]???????????????????? Non-interactive Direct login
    2.Last Login:thu 10:48:09 from 192.168.4.100
    Step four: Verify that the key verification is used properly, disable password verification
    1) Adjust the SSHD service configuration to set Passwordauthentication to No
    1.[[email protected] ~]# vim/etc/ssh/sshd_config
    2 .....
    3.PasswordAuthentication No???????????????????????????? Change this line yes to No

17. 5.[[email protected] ~]# systemctl restart sshd
    4 Case 4:selinux Safety protection
    4.1 Questions
    This case requires familiarity with the switch and policy configuration of the SELinux protection mechanism to accomplish the following tasks:
    1. Set the Linux server's selinux to enforcing mandatory mode
    2. Move a package file from the/root directory to the FTP download directory and adjust the policy to allow it to be downloaded
    3. In the SELinux enabled state, adjust the policy to open anonymous upload access to the VSFTPD service
    4.2 Steps
    The implementation of this case needs to follow the steps below.
    Step one: Set the Linux server's selinux to enforcing mandatory mode
    1) Fixed configuration: Modify/etc/selinux/config File
    Confirm or modify SELinux for enforcing mode:
    1.[[email protected] ~]# vim/etc/selinux/config
    2.selinux=enforcing???????????????????????????????? Set SELinux to mandatory mode
    3.selinuxtype=targeted???????????????????????????? Protection policy to protect the primary Network service security
    2) Temporary configuration: Use the Setenforce command
    To view the current SELinux status, if it is disabled, you need to restart the system according to the 1th step configuration, and if it is permissive, use the Setenforce command to change to enforcing:
    1.[[email protected] ~]# Getenforce???????????????????????? View current status as warning mode
    2.Permissive
    3.[[email protected] ~]# Setenforce 1???????????????????? Set SELinux to mandatory mode
    4.[[email protected] ~]# Getenforce???????????????????????? View current mode as mandatory mode
    5.Enforcing
    6.[[email protected] ~]# Setenforce 0???????????????????? Set SELinux to mandatory mode
    7.[[email protected] ~]# Getenforce???????????????????????? View current mode as warning mode
    8.Permissive
    Step two: In the SELinux enabled state, adjust the policy to open the VSFTPD service anonymous upload access
    1) Configure a VSFTPD service that allows anonymous uploads as a test environment
    1.[[email protected] ~]# yum–y install VSFTPD
    2 .....
    3.[[email protected] ~]# vim/etc/vsftpd/vsftpd.conf
    4.anonymous_enable=yes???????????????????????????????? Turn on anonymous access
    5.write_enable=yes
    6.anon_upload_enable=yes???????????????????????????? Allow uploading of files
    7.anon_mkdir_write_enable=yes???????????????????????? Allow uploading of directories
    8.[[email protected] ~]# systemctl start vsftpd???????????????? Start the service

19. 10.//default VSFTPD shared directory is/var/ftp/
    Step Three: Move 2 package files from the/root directory to the FTP download directory, adjust the file's security context
    1) Set up two test files for FTP download
    The root user creates two test packs, one directly into the/var/ftp/directory, the other under/root/, and then to the/var/ftp/directory.
    1.//test file 1, create a file directly in the FTP directory
    2.[[email protected] ~]# Tar–czf/var/ftp/log1.tar/var/log
    3.[[email protected] ~]# mv log1.tar/var/ftp/
    4.[[email protected] ~]# ls-lh/var/ftp/
    5.-rw-r--r--. 1 root root 8M August 10:16 Log1.tar
    6.[[email protected] ~]# ls-z/var/ftp/
    7.-rw-r--r--. Root root Unconfined_u:object_r:public_content_t:s0 Log1.tar

21. 9.//test File 2, build under/root, then move to/var/ftp directory
    10.[[email protected] ~]# tar–czf Log2.tar/var/log
    11.[[email protected] ~]# mv log2.tar/var/ftp/
    12.[[email protected] ~]# ls-lh/var/ftp/
    13.-rw-r--r--. 1 root root 8M August 10:16 Log2.tar
    14.[[email protected] ~]# ls-lz/var/ftp/
    15.-rw-r--r--. 1 root root Unconfined_u:object_r:admin_home_t:s0 Log2.tar
    3) test download by FTP mode
    Download the two package files separately using the wget command, and the second package will fail to download (no files are visible).
    1.[[email protected] ~]# wget ftp://192.168.4.5/log1.tar????????????//Download first file, successful

23. 3.[[email protected] ~]# wget ftp://192.168.4.5/log2.tar????????????//Download a second file, failed
    4) Check the security context of the test package and correctly adjust the second package successfully after downloading again.
    The file has been stored in the shared directory, but the client cannot access the download because it was intercepted by SELinux!
    1.[[email protected] ~]# ls-lz/var/ftp/
    2.-rw-r--r--. Root root Unconfined_u:object_r:public_content_t:s0 Log1.tar
    3.-rw-r--r--. 1 root root Unconfined_u:object_r:admin_home_t:s0 Log2.tar

25. 5.[[email protected] ~]# chcon-t public_content_t/var/ftp/d2.tar.gz
    6.[[email protected] ~]# ls-z/var/ftp/lo2.tar
    7.-rw-r--r--. Root root Unconfined_u:object_r:public_content_t:s0 Log2.tar

27. 9.[[email protected] ~]# wget ftp://192.168.4.5/log2.tar????????????//download again, success
    Note: The Chcon action in the example above can be replaced with the same effect:
    #restorecon/var/ftp/d2.tar.gz
    Or
    #chcon--reference=/var/ftp/d1.tar.gz/var/ftp/d2.tar.gz
    2) Verify FTP upload Access when SELinux is enabled
    In the Boolean setting of the targeted policy, FTP anonymous write and full access is disabled by default:
    1.[[email protected] ~]# ls > test.txt
    2.[[email protected] ~]# FTP 192.168.4.5
    3 .....
    4.Name (192.168.4.7:root): FTP???????????????????? FTP Login using anonymous account
    5.331 Specify the password.
    6.Password:???????????????????????????????????????? Password is empty (enter)

28. 8.ftp> CD Pub???????????????????????????????????????????????? Toggle shared Directory
    9.250 Directory successfully changed.
    10.ftp> put Test.txt???????????????????????????????????????? Try uploading a test file
    11.local:test.txt Remote:test.txt
    12.227 Entering Passive Mode (192,168,4,5,121,146).
    13.553 Could not create file. ???????????????????????????????? Upload failed
    14.ftp> quit
    15.221 Goodbye.
    3) Adjust the SELinux boolean value associated with FTP, open upload Write permission
    Check the SELinux boolean value associated with ALLOW_FTPD, and if it is off, modify it to on:
    1.[[email protected] ~]# getsebool-a |grep allow_ftpd???????????????? viewing Boolean values
    2.allow_ftpd_anon_write--off
    3.allow_ftpd_full_access--off
    4 .....
    5.[[email protected] ~]# setsebool-p allow_ftpd_anon_write=1???????? Setting a Boolean value
    6.[[email protected] ~]# setsebool-p Allow_ftpd_full_access=1
    7.[[email protected] ~]# getsebool-a |grep allow_ftpd???????????????? Confirm the result of the modification
    8.allow_ftpd_anon_write-On
    9.allow_ftpd_full_access-On
    4) Visit the VSFTPD service again and test that anonymous uploads are available
    1.[[email protected] ~]# FTP 192.168.4.5
    2 .....
    3.Name (192.168.4.5:root): FTP
    4.331 Specify the password.
    5.Password:

30. 7.ftp> CD Pub
    8.250 Directory successfully changed.
    9.ftp> put Test.txt???????????????????????????????????????? Try uploading a test file
    10.226 Transfer complete. ???????????????????????????????????? Upload successful
    11.237 Bytes Sent in 6.3e-05 secs (3761.90 kbytes/sec)
    12.ftp> quit
    13.221 Goodbye

Linux Basic precautions