Server:extras:ftp
From Linux How-To Repository
Contents |
Intro Notes
Installing Proftpd as part of initial server setup:
Also see: http://www.castaglia.org/proftpd/doc/contrib/ProFTPD-mini-HOWTO-Limit.html
The Directory Directive
Directory /*
The Directory directive specifies that the options within it are to be applied to the aforementioned directory. In this case, we are looking at /* which encompasses the entire file system. Inside this directive, we have AllowOverwrite set to "on". This will allow all uses the overwrite files in all directories that they have WRITE permission.
Limit LOGIN
Order allow,deny states the precedence of the allow and deny directives. We have set up this example server to only allow connections from someone comming from the domain .clarkson.edu. We then Deny access to everyone. You may be wondering how people at Clarkson can access this server if we have denied access to all. Well, because allow is of higher precedence than deny, when someone tried to connect from clarkson they are allowed because they fit the "Allow from .clarkson.edu" rule. However, when someone comes from .aol.com they will not fit the Allow rule, and will then be checked against the deny rule and since it is set to "Deny from all" the AOL user will be denied.
Limit WRITE
This directive, as we've set it up, allows all users of ther server to write. This is known as a global directive because it is not found inside another directive such as a user directive or a directory directive. This means that it applies to ALL users who do not have their own Limit WRITE directive. If you do not set this globaly, your users will not be able to do anything but read files on your server.
Examples
- A private directory that we don't want the user getting in to.
<Directory logs>
<Limit READ WRITE DIRS>
DenyAll
</Limit>
</Directory>
- Normally, we want files to be overwriteable.
<Directory /*>
AllowOverwrite on
</Directory>
<Limit LOGIN>
Order allow,deny
Allow from .clarkson.edu
Deny from all
</Limit>
<Limit LOGIN>
Order Allow,Deny
Allow 192.168.2.8, mydomain.com, anotherdomain.net,
Deny from all
</Limit>
<Limit WRITE>
Allow from all
</Limit>
Limit Commands
By default, anonymous FTP (File Transfer Protocol) users can only upload and/or download files and directories. Anonymous users cannot delete, rename, or overwrite files or directories. However, using an .ftpaccess file, it is possible to override the default permissions. Only permissions that are specified are overridden, all others will remain unchanged. For example, if you choose to write an .ftpaccess file to override the ability to delete files, the default configuration for uploading and downloading will remain the same.
Note: To work properly, the .ftpaccess file needs to be placed in the "/aftp" directory,
so that it only affects anonymous FTP users.
The Limit directive is one of the most useful features of .ftpaccess and is used to place access restrictions on one or more FTP commands in the "/aftp" directory. For example, using the Limit directive, this .ftpaccess file denies all anonymous users the ability to upload (STOR*) files:
<Limit STOR>
DenyAll
</Limit>
The Limit directive can also be used to limit access to the "/aftp" directory by IP address. For example, the following example only allows anonymous FTP access to users that come from IP addresses that begin with either w.x.y or w.x.y.z:
<Limit ALL>
DenyAll
Allow w.x.y.z
</Limit>
You can also combine the aforementioned restrictions in to one .ftpaccess file to create a very flexible solution. For example, you can allow all anonymous users to access the site and download files, and only users from certain IP addresses to upload files. Since the default is to allow all anonymous users the ability to upload and download files, you only need to restrict the ability to upload files. This can be done in one .ftpaccess file:
<Limit STOR>
DenyAll
Allow w.x.y.z
</Limit>
The default configuration for anonymous FTP does not allow users to delete (DELE*) or overwrite files. Those features can also be overridden with an .ftpaccess file:
AllowOverwrite On
<Limit DELE>
AllowAll
</Limit>
Multiple FTP commands can also be combined in an .ftpaccess file. In this example, only anonymous users from certain IP addresses can upload and delete files. All users can still download files because this .ftpaccess file does not affect download permissions:
<Limit STOR DELE>
DenyAll
Allow w.x.y.z
</Limit>
STOR - The command that an FTP client sends to the server when a user wants to upload a file to the server
(i.e., STOR filename.txt).
DELE - The command that an FTP client sends to the server when a user wants to delete a file from the server
(i.e., DELE filename.txt).
Umask
Umask is *not* the same as the permissions; it is a mask applied to the default permissions as follows. In the default vsftpd config, it appears that the following defaults apply:
file_open_mode = 0666 # symbolically -rw-rw-rw local_umask = 077
So combining those two upon file creation via the FTP server you'd get files with default permissions (as far as I can tell) of 0600, or (symbolically) -rw-------
Consider changing them as follows:
file_open_mode = 0755 # symbolically -rwx-r-xr-x local_umask = 000
AuthPAM
Used to set whetheror not users with accounts on the host machine can ftp in to their home directories. This is on by default so if you want to disable this type of access, you must specifically do so.
Setting up permissions and symlinks
* Set the proper permissions
chmod 755 /etc/init.d/proftpd
* Create the necessary symlinks by running:
cd /etc/rc2.d; ln -s ../init.d/proftpd S40proftpd cd ../rc0.d; ln -s ../init.d/proftpd K40proftpd cd ../rc6.d; ln -s ../init.d/proftpd K40proftpd
Misc.
Check to make sure the FTP server is uncommented in
/etc/inetd.conf.
Debugging Mode:
shut it down from the init script, /etc/rc.d/init.d/proftpd stop
and start it up from the shell with
proftpd -nd9
(you might need to type the full path, by default /usr/sbin/proftpd)
Running ProFTPD As A Nonroot User
Occasionally, one might want to run ProFTPD on a system where root privs are not available to you as a user. It is still possible to setup a functioning FTP server without root privileges. There are a few catches and special considerations for this, however.
Here are the configuration directives that you will need to use in order to run the server without root privileges:
* Port
This needs to be a number greater than 1023. Lower number ports require root privileges in order for the process to bind to that address. This will also mean that clients wishing to contact your server will need to know the port on which it is listening. Most FTP clients connect to the standard FTP port (21).
Example:
Port 20021
* AuthUserFile, AuthGroupFile
In order to authenticate users, by default the server looks in /etc/passwd for account information, and in /etc/shadow for the password. Comparing stored passwords requires root privileges, which this nonroot-running daemon will not have. You can get around this requirement by supplying your own passwd (and possibly group) files via the AuthUserFile and AuthGroupFile directives. Make sure the permissions on your custom files allow for the daemon to read them (but hopefully not other users).
Example:
AuthUserFile /path/to/custom/ftpd.passwd
AuthGroupFile /path/to/custom/ftpd.group
* AuthPAM
PAM authentication requires root privileges. This directive will need to be set off.
Example:
AuthPAM off
* PidFile
This directive will need to be used to cause the server to write its PID to some file writable by the user.
Example:
PidFile /home/bob/ftpd/proftpd.pid
* ScoreboardFile
This directive will need to be used to cause the server to write its scoreboard to some file writable by the user.
Example:
ScoreboardFile /home/bob/ftpd/proftpd.scoreboard
* WtmpLog
Logging to wtmp files requires root privileges. While it is not strictly necessary for this directive to be set to off, failure to do so will result in server log messages like:
host.domain.net (localhost[127.0.0.1]) - wtmpx /var/adm/wtmpx: Permission denied
Example:
WtmpLog off
* User, Group
The ability to switch the identity of the server process to those configured by the User and Group directives requires, of course, root privileges. It is best to configure User to be your username, and Group to be the name of your primary group (which is usually the first group listed by the groups command).
Example:
User bob
Group bob
Note that other configuration directives will be affected by the lack of root privileges: DefaultRoot will not work, nor will <Anonymous> sections, nor UserOwner. Basically any operation that requires root privileges will be disabled.
If using the SystemLog directive, make sure the file to which the server is to log can be written to by the configured daemon User or Group.
The daemon should now start successfully. Complaints about not being able to switch UIDs and such will be logged, but the daemon should still function properly.
Virtual Servers
Here are example virtual servers added to /usr/local/etc/proftpd.conf. These examples were taken straight from /usr/ports/ftp/proftpd/work/proftpd-1.2.0pre8/sample-configurations/.
The main changes are:
* Turned off PAM * Set the server name * Set the default root.
You'll also see that the two servers have files in different places. This is the main reason for running virtual servers. You can have them answer to different IP addresses (i.e. different hostnames) and present different file sets according to the server in question.
After modifying the config file, don't forget to HUP proftpd!
killall -HUP proftpd
Here are the configuration settings:
# First virtual server
<VirtualHost 192.168.0.200>
AuthPAMAuthoritative off
ServerName "This is the Virtual Server 192.168.0.200"
DefaultRoot /pub/ftp.192.168.0.200
MaxClients 10
# Next, create a "guest" account (which could be used
# by a customer to allow private access to their web site, etc)
<Anonymous /pub/ftp.192.168.0.200>
User ftp
Group ftp
# ### We want clients to be able to login with "anonymous"
# ### as well as "ftp"
UserAlias anonymous ftp
### It is wise when making an 'ftp' user that you either block it
### ability to login either via /etc/login.access or my giving it
### an invalid shell.
### Uncomment this if the 'ftp' user you made has an invalid shell
RequireValidShell off
### We want 'welcome.msg' displayed at login, and '.message'
### displayed in each newly chdired directory.
DisplayLogin welcome.msg
DisplayFirstChdir .message
AnonRequirePassword on
<Limit LOGIN>
AllowAll
</Limit>
# A private directory that we don't want the user getting in to.
<Directory logs>
<Limit READ WRITE DIRS>
DenyAll
</Limit>
</Directory>
</Anonymous>
</VirtualHost>
Second virtual server
<VirtualHost 192.168.0.201>
AuthPAMAuthoritative off
ServerName "This is the Virtual Server 192.168.0.201"
DefaultRoot /pub/ftp.192.168.0.201
MaxClients 10
# Next, create a "guest" account (which could be used
# by a customer to allow private access to their web site, etc)
<Anonymous /pub/ftp.192.168.0.201>
User ftp
Group ftp
# ### We want clients to be able to login with "anonymous" as
# ### well as "ftp"
UserAlias anonymous ftp
### It is wise when making an 'ftp' user that you either block its
### ability to login either via /etc/login.access or my giving it
### an invalid shell.
### Uncomment this if the 'ftp' user you made has an invalid shell
RequireValidShell off
### We want 'welcome.msg' displayed at login, and '.message'
### displayed in each newly chdired directory.
DisplayLogin welcome.msg
DisplayFirstChdir .message
AnonRequirePassword on
<Limit LOGIN>
AllowAll
</Limit>
# A private directory that we don't want the user getting in to.
<Directory logs>
<Limit READ WRITE DIRS>
DenyAll
</Limit>
</Directory>
</Anonymous>
</VirtualHost>
Limiting Access with ftpaccess
In the proftpd.conf file you would put:
<Directory /home/youruser/userdir/*>
<Limit ALL>
AllowUser username
</Limit>
</Directory>
.ftpaccess files
A .ftpaccess file is meant to function like Apache's .htaccess file. It's a file that acts as free-floating section of the server's configuration file. If a .ftpaccess file is present in a directory in which the server looks, it will parse that .ftpaccess file as a configuration file, and act accordingly. Only some configuration directives are allowed in the .ftpaccess context, though.
The server treats a directory that contains a .ftpaccess file exactly as if the configuration directives in that file had been placed in a <Directory> section in the main proftpd.conf file. For example, if there is a /home/users/bob directory on your system, and in that directory there was a .ftpaccess file that contained:
DirFakeUser on ~ DirFakeGroup on ~ Umask 0077
it would be treated exactly as if:
<Directory /home/users/bob> DirFakeUser on ~ DirFakeGroup on ~ Umask 0077 </Directory>
was written into proftpd.conf.
