Anonymous FTP settings: Anonymous FTP If the correct settings and management, will be a valuable service. The first section of this document provides the initial setting for General anonymous FTP. The second section proposes issues related to the availability of a writable directory area for a Web site under anonymous FTP. Section III provides CERT previous FTP-related advisories information.
The following settings are made up of experience and suggestions from a number of websites that have accumulated in the past. We think that we can make the website with individual requirements have different choices.
I. Set anonymous FTP
A.ftp Daemon
The website must determine that the latest version of the FTP daemon is currently in use.
B. Setting up directories for anonymous FTP
The root directory (~FTP) of anonymous FTP and the owner of its subdirectories cannot be FTP accounts or accounts with the same group as FTP. This is a common setup problem. If these directories are owned by FTP or an account with the same group as FTP, and do not protect against write protection, intruders may add files (for example:. rhosts) or modify other files. Many web sites allow the use of root accounts. Let anonymous FTP root directory and subdirectory owner is root, belong to group (group) is system, and limited access (such as chmod 0755), so only Root has write power, which can help you maintain the security of the FTP service.
The following is an example of an anonymous FTP directory setting:
Drwxr-xr-x 7 root System 1 15:17./
Drwxr-xr-x root System 4 11:30. /
Drwxr-xr-x 2 root system 15:43 bin/
Drwxr-xr-x 2 root system 16:23 etc/
Drwxr-xr-x root System 5 10:54 pub/ |
All archives and link libraries, especially those used by FTP daemon and those in ~ftp/bin and ~ftp/etc, should be protected in the same way as the directories in the example above. These files and link libraries must also be prevented from being written in addition to the FTP account or the account owned by the same group as FTP.
C. Use of appropriate passwords and group files
We strongly recommend that the Web site do not use/etc/passwd in the system as a password file in the ~ftp/etc directory or/etc/group the system as a group file in the ~ftp/etc directory. Placing these files in the ~FTP/ETC directory will allow intruders to obtain them. These files are customizable and are not used for access control.
We recommend that you use alternative files in ~ftp/etc/passwd and ~ftp/etc/group. These files must be owned by root. The dir command uses this alternative file to display the owner and group names of the files and directories. The Web site must determine that the ~/FTP/ETC/PASSWD file does not contain any account names that are identical to the/etc/passwd files in the system. These files should contain only the names of the owners and groups of files and directories in the FTP hierarchy that need to be displayed. Also, make sure that the password field is "sorted". For example, use "*" to replace the password field.
The following is an example of a 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:
II. Provide writable directories in your anonymous FTP allows an anonymous FTP service to allow users to store files at risk. We strongly advise the site not to automatically create an upload directory unless the associated risks have been considered. CERT/CC Event-Return members receive many events that use the upload directory to cause illegal transfer of copyright software or Exchange account and password information. It also received a maliciously-crafted system archive that caused denial of service issues. This section discusses the use of three methods to solve this problem. The first method is to use a modified FTP daemon. The second method is to provide a write limit to a specific directory. The third method is to use a separate directory. A. Modified FTP Daemon If your site plans to provide a directory for file uploads, we recommend that you use the modified FTP daemon to control access to the directory where the files are uploaded. This is the best way to avoid using an unwanted write area. Here are some suggestions: 1. The file can no longer be accessed by the System Manager, and then put to the appropriate location for download. 2. Limit the size of each uploaded data online. 3. Limit the total amount of data transfer according to the existing disk size. 4. Increase the login record to detect improper use in advance. If you want to modify the FTP daemon, you should be able to get the program code from the manufacturer, or you can obtain the public FTP source code from the following places:
wuarchive.wustl.edu ~ftp/packages/wuarchive-ftpd
Ftp.uu.net ~ftp/systems/unix/bsd-sources/libexec/ftpd
Gatekeeper.dec.com ~ftp/pub/dec/gwtools/ftpd.tar.z |
CERT/CC did not formally detect, evaluate or endorse the mentioned FTP daemon. Which FTP daemon to use is for each user or organization to decide, and CERT/CC recommends that each agency make a thorough assessment before installing these programs. B. Using protected directories If you want to provide an uploaded service at your FTP station, and you can't modify the FTP daemon, we can use a more complex directory architecture to control access. This method requires prior planning and does not fully prevent FTP writable areas from being improperly used, although many FTP stations still use this method. to protect the top-level 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 allow the user to view the contents of the directory. Ex:drwxr-x--x 4 root system 13:29 incoming/in ~ftp/incoming use some directory names that only allow you to let people know that they upload. In order to make it difficult for others to guess the directory name, we can use the rules to set the password to set the directory name. Please do not use the directory name example in this article (avoid being found with your directory name and upload file) drwxr-x-wx root system 13:54 JAJWUTH2/DRWXR-X-WX TEM-June-One 13:54 mhall-if/ It is important to note that once the directory name is inadvertently leaked, this method has little protection. As long as the directory name is known to most people, it is not possible to protect those areas that are limited to use. If the directory name is known, then you have to choose to delete or change those directory names. C. Use only one hard drive if you want to provide an uploaded service at your FTP station, and you can't modify the FTP daemon, you can focus all uploaded data on the same file system that hangs (Mount) on the ~ftp/incoming. If possible, hang a separate hard drive on the ~ftp/incoming. System managers should keep an open view of this directory (~ftp/incoming) so that they can know if there is a problem with the uploaded directory. III. restricting the FTP user directory Anonymous FTP can be a good way to limit users to only the specified directory fanSurround activity, but the official FTP user does not receive this restriction by default, so that he is free to read files in the root directory, system directory, and other user's directory that allow other users to read. How can the specified users be restricted to their own directories like anonymous users? Here's an introduction to Red Hat and wu-ftp. 1 Create a group, using the Groupadd command, you can generally use an 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 establish a user available Adduse R command. If you have previously established testuser this user, you can edit the/etc/passwd file directly 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 it 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 |
In addition to add Guestgroup Ftpuser this line, the other 4 lines also to add, otherwise the user login, although you can not return to the parent 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 this user's root directory, copy ftp s Erver's own directory, the/home/ftp/under the Bin,lib two directories to copy to the user's root directory, because some commands (mainly LS) need Lib support, otherwise can not be listed directories and files. -----Related commands: Cp-rf/home/ftp/lib/home/testuser;cp-rf/home/ftp/bin/home/testuser 5 also do not forget to turn off the user's Telnet right, otherwise it will be done in vain oh. Why don't you let the user Telnet? Very simple: Add a line of/dev/null in/etc/shells, then you can edit the/etc/passwd file directly, the user's shell set to/dev/null can be. -----Related commands: vi/etc/passwd This step can be done first when you create a user in step 2. -----Related commands: AddUser testuser-g ftpuser-s/dev/null Small experience: As long as the/home/ftp under the bin and Lib directory cp to the/etc/skel directory, New users will automatically be the bin and Lib directory CP to the user directory, of course, you can also add public_html directory and Cgi-bin directory. Through the above settings, TestUser all FTP actions for this user will be limited to his/home/testuser directory. please contact the site, timely note your name. Contact Email: edu#chinaz.com (change # to @).
