10.3. Main Settings of the wu-ftp Server

10.3. Main Settings of the wu-ftp Server

The main configuration file for the wu-ftp server is ftpaccess. Its contents are shown in Listing 10.2.

Listing 10.2: The contents of the ftpaccess configuration file
image from book
 # This file was generated by the KDE # wu-ftpd configurator. # (c) 2000 by Bernhard Rosenkrunzer (bero@redhat.com) class all anonymous,guest,real  * noretrieve loginfails 5 private no banner /welcome.msg email root@localhost message /welcome.msg           LOGIN message .message               CWD=* readme           README*       LOGIN readme           README*       CWD=* chmod              no          anonymous,guest delete             no          anonymous overwrite          no          anonymous rename             no          anonymous passwd-check       rfc822      warn log transfers anonymous,guest,real inbound log transfers anonymous,guest,real outbound anonymous-root /home/flenov 
image from book
 

When configuring the FTP server, the default values of many directives are not changed because they do not affect the server's productivity or security. Although some of the directives play a role in preventing incorrect or inefficient use of the server (e.g., the timeout XXXX directive contributes to timely release of resources), their default values are sufficient for this; moreover, changing values of some directives may have negative effects.

Consider the main directives of this file, which I grouped by categories to make working with them easier.

Information about other features, which will not be considered , can be obtained from the ftpaccess man page.

10.3.1. Access

Access directives define the main rights for accessing the FTP server. Consider the main directives of this category:

  • class name type address Organizes user classes by type and address. In the example configuration file (Listing 10.2), there is the following entry:

     class all anonymous,guest,real   * 

    The class is specified as all . It is followed by an enumeration of the user types that will pertain to this class. In this case, all available categories are included in the class: anonymous, guest, and real. The last parameter is an address template, which in this case is a wild card, that is, any address. Thus, any user, with any address, belongs to the all class.

    Classes are a handy concept. You can group certain users into a class and assign them certain rights. For example, you can create a class of users whose IP addresses lie within the address range for your office, company, or country. You then open full FTP access to this class only, prohibiting or limiting access to all others. It is more convenient to assign rights to an entire class at once than to write access rights for each user.

  • noretrieve type class_name file Prohibits the specified file from being read. The type parameter specifies the absolute or relative path to the file. The next parameter, class_name , specifies the class, to which the prohibition applies. The all class described previously can either be specified explicitly or not specified, in which case the prohibition will apply to all users. If the file parameter is specified with a full path, the prohibition will apply to this file only. If only the file name is given, access to all files with this name in all directories will be prohibited .

    The following directive prohibits accesses to any file named passwd:

     noretrieve relative passwd 

    Add this line to your configuration file and then connect to the server using an FTP client. For testing the FTP server, I used the gFTP client program. After connecting to the server, I created a file named passwd in the /home directory and then tried to download it to the /home/flenov directory. In response, the FTP client only created an empty file in the directory. But it could not issue any messages because the prohibition on retrieval made it crash. This sort of termination is specific to the gFTP server; other FTP clients should process the error properly and remain operational.

    If the FTP server is located on the same physical machine as the Web server, it would be logical to also prohibit reading the .htaccess file, in which the access rights to the Web server directories are defined. FTP users should have no right to even view these rights. It is better to assign rights to specific users only, so that each of them could work only with his or her own .htaccess files, or to provide some other way to edit rights.

    Operations with the system directories should be prohibited. For example, the following entry prohibits retrieving any file from the /etc directory and its subdirectories:

     noretrieve /etc 
  • loginfials number Indicates the number of unsuccessful attempts to log onto the server, after which a corresponding record is created in the log. The number of login tries in the example file is 5. If a user cannot log in after five tries , chances are this is not a bona fide user but a hacker trying to crack the password by either trying random combinations or using the dictionary method.

  • private parameter Specifies, if set to yes , that the SITE GROUP and SITE GPASS wu-ftp server commands can be used to change the group. (Command sets of other FTP servers may not contain these commands.) By specifying the correct group and password, the user obtains the rights of the corresponding group, specified in the ftpgroups file.

  • deny address file Prohibits client access from the specified addresses. When a connection attempt is made from a prohibited address, a message stored in the file specified by the file parameter is displayed. The address can be specified as a regular expression.

  • defumask mask Indicates the access rights mask used to create new files. The Linux umask command, which specifies the current value of the mask, was described in Section 4.1 .

  • limit-time type minutes Limits the session's duration. For example, you do not want certain users to hang out for too long on your FTP server. The type parameter can be specified as * (all users), real, anonymous , or guest . The minutes parameter specifies the allowed session duration, after which the connection will be broken off.

  • file-limit direction number class Sets the limit on the number of transferred files. The direction parameter can be specified as in, out , or total . For example, the file-limit total 10 command prohibits transfer of more than ten files in both directions.

  • byte-limit direction number class Limits the number of transferred bytes. The directive operates like the file-limits command, only it works with bytes instead of files.

  • anonymous-root directory Specifies explicitly the directory for anonymous users. These users cannot have their own directory, unlike real users whose root directory when connected to the server is their home directory.

  • guest-root directory Makes all guests use the same directory (analogous to the previous command). If each guest must have a personal directory, it is better to create an account for each guest explicitly (see Section 10.6 ).

  • passwd-check type message Verifies the password validity for anonymous users, that is, for the email address entered as the password complying with the certain standards. The type parameter can have one of the following values: none (no check is performed), trivial (check for the @ character in the address), or rfc822 (full check for compliance with the RFC 882 standard). The message parameter can be set to warn or enforce . In the former case, a warning message is issued, but the user is allowed to proceed; in the latter, the user is denied access.

  • deny-email address Denies access if the specified email address is given as the password. Most FTP clients are configured with some arbitrary valid email address for anonymous access for example, my@mail.com that is rarely changed. Because this address complies with all rules for the email address format, the server cannot determine that it is not a real address. But when this address is specified explicitly in this parameter, users will not be able to use this address as the password unless it is changed to something else. But even this does not guarantee that anonymous users will give their own email addresses as the password.

  • deny-uid identifiers Prohibits users with specified identifiers from accessing the FTP server. The ftpusers file, considered in Section 10.5 , performs the same function. This command is convenient because it can be applied to ranges of users. For example, the deny-uid %-500 command denies access to all users whose user ID is less than 500.

  • deny-gid identifiers Prohibits access the FTP server for the users of the group with the specified identifiers. The ftpusers command performs the same function.

  • restricted_uid identifiers Prohibits guest users with the specified IDs from accessing directories outside their home directory.

  • restricted_gid identifiers Prohibits users with the specified group ID from accessing directories outside their home directory.

  • unrestricted_uid identifiers Allows guest users with the specified ID to access directories outside their home directory.

  • unrestricted_gid identifiers Allows users with the specified group ID to access directories outside their home directory.

  • dns refuse_no_reverse file override Issues a warning message if the client does not provide a return address, and breaks off the connection unless the override parameter is specified.

  • dns refuse_mismatch file override Issues a warning message if the forward and reverse lookups for the site do not match, and breaks off the connection unless the override parameter is specified. I always enable this option and disable it only when real users experience problems working with the server. This is necessary to prevent hackers from faking the IP address to enter the system by circumventing the corresponding check.

10.3.2. Controlling File Upload

File upload is the most dangerous operation for the server. Each user should only be able to access his or her own directory. But what if anonymous users also need to upload files? In this case, you should prohibit uploads by anonymous users to vulnerable directories, into which scripts could be uploaded and executed afterwards.

The upload parameters command defines a directory that permits or denies uploads. For example, the following command denies uploads to the /etc directory:

 upload /etc          no 

The following command permits uploads to the /home directory:

 upload /home         yes root root 0600 nodir 

The third and fourth parameters specify the owner and group that will be set for the file. I specified both of them as root, so that a regular user could not do anything with the document. The fifth parameter specifies the file permission, 0600 in this case. This means that only the administrator can read from and write to it. The last parameter nodir prohibits directory creation.

The following example allows the user to create directories:

 upload /home/robert    yes root root 0600 dir 0700 

The penultimate parameter is dir , which permits the user to create directories. The last parameter is 0700 , which assigns exclusive rights to the directory to the administrator. This way, even if hackers upload a malicious program into this directory, they will not be able to execute it because they will not have the proper rights for this.

You should prohibit uploading of files into any system directories open to users for viewing. But if you are using only guest access, where a user can work only in his or her own environment, there is no need for this.

10.3.3. Controlling Operation Rights

The ftpaccess file can also be used to describe the main operations and their permissions. The general format of such commands is as follows :

 Action yesno user 

The value of the action parameter can be one of the following: chmod, delete, overwrite, rename , or umask . The value of the user parameter can be one of, or a combination of the anonymous, guest , and real user types, or a user class.

By default, all actions and all users are allowed. But it would be logical to prohibit deleting, renaming, and modifying files or changing their attributes by unauthorized (anonymous) users.

For example, Listing 10.2 contains the following lines to prohibit access to these operations:

 chmod              no          anonymous,guest delete             no          anonymous overwrite          no          anonymous rename             no          anonymous 

10.3.4. Informational Directives

These directives are responsible for providing information about the system that the remote user sees when logging into the FTP server. These are the following:

  • banner name Specifies a text file (in the name parameter) whose contents will be displayed to the user when starting the login process. The contents are arbitrary; these may be a greeting, some information, or the FTP server usage rules. You should remember that the banner is displayed before the authentication process; therefore, it should not contain any information that may help hackers break into the system.

  • greeting fullbrieftersetext Specifies how much information about the system is given to the user before the login. The greeting is a string that may look like this: "220 flenovm.ru FTP server (Version wu-2.6.2-5) ready." As explained in Section 10.1 , this string is displayed before the authorization process and contains information about the system and the FTP server version. It is not a good idea to display either full or correct information; you are better off showing the least possible amount of correct information or, even better, displaying something that is not true. The meanings of the parameter values as follows:

    • full The host name and daemon name and version are displayed.

    • brief Only the host name is displayed.

    • terse The "FTP server ready" message is displayed.

    • text A custom message is displayed.

I like the last option the best. The custom text to be displayed is entered after a space following the text parameter, as follows:

 greeting text text_string 

On my servers, I use a custom message saying either greeting text flenovm.ru FTP Server (MS IIS 4.1.0) ready or greeting text flenovm.ru FTP Server (cd-ftpd 2.1.9) ready .

Neither of these two messages provides any information about what FTP server is installed. The first one may make hackers think they are dealing with the Internet information server from Microsoft, which is used only in Windows systems. This can confuse even an experienced hacker. Unfortunately, this message does not prevent the same hacker from using special utilities to determine that the operating system is actually Linux. Even though these utilities will not be able to determine the exact version of Linux, they establish that the FTP server greeting message is a fake.

In the second case, I specify a nonexistent server. Not being able to find an exploit to break into the server because of the lack of information about the server used, the potential computer burglar may prefer looking for easier prey.

Or you could display that you have the ProFTP server installed, which exists and is often used by Linux administrators.

  • hostname host_name Defines the default host name of the FTP server.

  • email email_address Specifies the administrator's email.

  • message file type Displays the contents of the specified text file in the following cases:

    • When logging into the system if the type parameter is specified as LOGIN

    • When changing the directory if the type parameter is specified as CWD=directory and the user has switched to the specified directory

10.3.5. Logging

Some administrators log activities of anonymous and guest users only. Their rationale for this is that real system users will not do anything damaging to the server that they need for their work. This is fundamentally flawed thinking, because quite a few break-ins are perpetrated by real users; moreover, most often hackers use real user accounts to break in.

It is difficult, impossible with the proper assignment of access rights, to do anything damaging to the server when logged in as an anonymous user or a guest. Only when there is a bug in the server software can this be done. Thus, in most cases malefactors try to obtain access to a real user account for their activities.

Should a nonstandard situation develop, logs will provide you with detailed information about the reasons for this. You can then take steps to eliminate those particular causes. (The logging subject is covered in detail in Chapter 12 .)

The default file for storing the wu-ftp log is /var/log/xferlog. The history of activity for the last six days can be viewed in the /var/log/xferlog.X file, where X is a number from 0 to 5.

The following are some examples of configuring the wu-ftp server's logging functions:

  • log commands type_list Enables logging of all client commands. The type_list parameter's value can be one of the following: anonymous, guest , or real .

  • log transfers type_list directions Enables logging of files uploaded or downloaded by users. The value of the directions parameter is a comma-separated list of any of the two keywords: inbound and outbound .

  • log security type_list Enables logging of all security violations, such as attempts to execute prohibited commands.

  • log syslog Redirects the logging messages to the syslog file.

  • log syslog+xferlog Sends the transfer logs to both the syslog and the xferlog files.



Hacker Linux Uncovered
Hacker Linux Uncovered
ISBN: 1931769508
EAN: 2147483647
Year: 2004
Pages: 141

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net