Improve network service security Anonymous FTP security settings

                  Anonymous FTP Settings Anonymous FTP will be a valuable service if it is properly configured and managed. The first section of this document provides the most basic way to set up an anonymous FTP. The second section presents related issues and issues when a website is to provide a writable directory area under anonymous FTP. The third section provides information about the FTP related Advisories before CERT. The following settings are made up of experiences and suggestions accumulated by many websites in the past. We believe that websites with individual needs can have different settings. I. Setting up anonymous FTP The A.FTP daemon website must be sure that the latest version of the FTP daemon is currently in use. B. Setting the directory for anonymous FTP The root directory of the anonymous ftp (~ftp) and the owner of its subdirectories cannot be ftp accounts, or accounts of the same group as ftp. This is a common setting problem. If these directories are owned by ftp or an account with the same group as ftp, and there is no protection against writes, the intruder may add files (for example: .rhosts) or modify other files. Many websites allow the use of a root account. Let the root directory of the anonymous FTP and the subdirectory owner be root, the group is system, and restrict access (such as chmod 0755), so only root has the right to write, which can help you maintain the FTP service. Security. The following is an example of setting up an anonymous ftp directory:

drwxr-xr-x 7 root system 512 Mar 1 15:17 ./drwxr-xr-x 25 root system 512 Jan 4 11:30 ../drwxr-xr -x 2 root system 512 Dec 20 15:43 bin/drwxr-xr-x 2 root system 512 Mar 12 16:23 etc/drwxr-xr-x 10 root system 512 Jun 5 10:54 pub/all files and links Libraries, especially those used by FTP daemons and those in ~ftp/bin and ~ftp/etc, should be protected the same as the directories in the example above. These files and link libraries must be protected from writing in addition to being owned by an ftp account or an account with the same group as ftp. C. Using the appropriate password and group files We strongly recommend that the website do not use /etc/passwd on the system as the password file in the ~ftp/etc directory or the /etc/group in the system as ~ftp/etc directory. Group file. Placing these files in the ~ftp/etc directory will allow intruders to get them. These files are customizable and are not used for access control. We recommend that you use an alternate file in ~ftp/etc/passwd and ~ftp/etc/group. These files must be owned by root. The DIR command will use this alternate file to display the owner and group name of the file and directory. The website must be certain that the ~/ftp/etc/passwd file does not contain any of the same account names as in the /etc/passwd file on the system. These files should only contain the owner and group name of the files and directories in the FTP hierarchy that need to be displayed. Also, make sure the password field is "organized". For example, use "*" instead of the password field. The following is an example of the password file for anonymous ftp in cert
ssphwg:*:3144:20:Site Specific Policy Handbook Working Group::cops:*:3271:20:COPS Distribution::cert:*:9920:20:CERT ::tools:*:9921:20:CERT Tools::ftp:*:9922:90:Anonymous FTP::nist:*:9923:90:NIST Files::The following is an example of a group file for anonymous ftp in cert< PRE>cert:*:20:ftp:*:90:II. Provide a writable directory on your anonymous ftp so that an anonymous ftp service allows users to store files at risk. We strongly encourage the website not to automatically create an upload directory unless the relevant risks have been considered. CERT/CC's event-returning members received many events that use the upload directory to illegally transfer copyrighted software or exchange account and password information. Also received a malicious report of the system file caused by the problem of denial of service. This section discusses three ways to solve this problem. The first method is to use a modified FTP daemon. The second method is to provide write restrictions on specific directories. The third method is to use a separate directory. A. Modified FTP daemon If your website plans to provide a directory for file uploading, we recommend using the modified FTP daemon to control the file upload directory. This is the best way to avoid using unwanted write areas. Here are some suggestions: 1. The limited uploaded file can no longer be accessed, so it can be detected by the system administrator and then placed in the appropriate location for download. 2. Limit the size of each online upload. 3. Limit the total amount of data transfer according to the existing disk size. 4. Increase login records to detect inappropriate usage in advance. If you want to modify the FTP daemon, you should be able to get the program code from the vendor, or you can get the public FTP program source code from: 
wuarchive.wustl.edu ~ftp/packages/wuarchive-ftpdftp.uu .net ~ftp/systems/unix/bsd-sources/libexec/ftpdgatekeeper.dec.com ~ftp/pub/DEC/gwtools/ftpd.tar.ZCERT/CC does not officially detect the FTP daemon mentioned, Evaluation or endorsement. The FTP daemon to be used is determined by each user or organization, and CERT/CC recommends that each authority perform a thorough evaluation before installing and using these programs. B. Using protected directories If you want to provide uploaded services on your FTP site and you have no way to modify the FTP daemon, we can use a more complex directory architecture to control access. This method requires prior planning and is not 100% to prevent improper use of the FTP writable area, but many FTP stations still use this method. In order to protect the upper directory (~ftp/incoming), we only give anonymous users access to the directory (chmod751~ftp/incoming). This action will enable the user to change the directory location (cd) but not the user to view the directory contents. Ex:drwxr-x--x 4 root system 512 Jun 11 13:29 incoming/Use some directory names in ~ftp/incoming only let people who you allow them to upload know. In order to make it difficult for others to guess the directory name, we can set the directory name with the rules for setting the password. Please do not use the directory name example in this article (to avoid being discovered by someone who is interested in it and upload the file) drwxr-x-wx 10 root system 512 Jun 11 13:54 jAjwUth2/drwxr-x-wx 10 root system 512 Jun 11 13:54 MhaLL-iF/It's important to note that once the directory name is leaked intentionally or unintentionally, this method has no protection. As long as the directory name is known to most people, it is impossible to protect the areas that you want to limit. If the directory name is known to everyone, then you have to choose to delete or change those directory names. C. Use only one hard disk. If you want to provide the uploaded service on your FTP station, and you can't modify the FTP daemon, you can put all the uploaded data in the same mount at ~ftp/The file system on incoming. If possible, mount a separate hard drive on ~ftp/incoming. The system administrator should continue to view this directory (~ftp/incoming) so that you can see if there is a problem with the open upload directory. III. Restricting FTP User Directory Anonymous FTP can very well restrict users from being active within the specified directory. However, official FTP users are not subject to this restriction by default, so that they are free to use the root directory, system directory, and other The user's directory reads some files that are allowed to be read by other users. How can I limit the specified users to their own directories like anonymous users? Below we take red hat and wu-ftp as an example. 1 Create a group, use the groupadd command, you can generally use the ftp group, or any group name. ----- Related commands: groupadd ftpuser ----- Related files: /etc/group ----- Related help: man groupadd 2 Create a user, such as testuser, to create a user adduser command. If you have previously created the testuser user, you can directly edit the /etc/passwd file and add the user to the ftpuser group. ----- Related commands: adduser testuser -g ftpuser ----- Related files: /etc/passwd ----- Related help: man adduser 3 Modify /etc/ftpaccess file, add the definition of guestgroup: guestgroup ftpuser I changed this way, plus the last 5 lines: 
compress yes all tar yes all chmod no anonymous delete no anonymous overwrite no anonymous rename no anonymous chmod yes guest delete yes guest overwrite yes guest rename yes guest guestgroup ftpuser Guestgroup ftpuser This line, the other 4 lines should also be added, otherwise the user can log in, although the user can not return to the upper directory, but can only upload, can not overwrite, delete files! ----- Related commands: vi /etc/ftpaccess ----- Related files: /etc/ftpaccess ----- Related help: man ftpaccess, man chroot 4 Copy the necessary files to the root directory of this user, copy the directory that comes with ftp server, Copy the bin and lib directories under /home/ftp/to the root directory of this user, because some commands (mainly ls) require Lib support, otherwise they cannot be listed and Pieces. ----- Related commands: cp -rf /home/ftp/lib /home/testuser;cp -rf /home/ftp/bin /home/testuser 5 Also don't forget to turn off the user's telnet right, otherwise White did it. Why not let users telnet? Very simple: add /dev/null to /etc/shells, then edit the /etc/passwd file directly and set the user's shell to /dev/null. ----- Related commands: vi /etc/passwd This step can be done first when creating a user in step 2. ----- Related commands: adduser testuser -g ftpuser -s /dev/null Small experience: Just put the bin and lib directory under /home/ftp to the /etc/skel directory, the new user will automatically put the bin And the lib directory CP to the user directory, of course you can also add the public_html directory and cgi-bin directory. After the above settings, all FTP actions of the testuser user will be restricted to his /home/testuser directory.