FTP server security

The most important, obligatory steps

1. Run ftp on high port if possible.
2. TCP wrappers are obligatory.  FTP access can be restricted to specific IP addresses using FTP wrappers By limiting access to your FTP site to known entities, you can drastically reduce your exposure to unauthorized access.
3. Always use a separate disk partition for downloads; it always should be mounted nosuid and possibly noexec.
4. Switch to sftp whenever practical and when you process sensitive data. Remember in ftp password travels the internet in clear text.
5. Always run ftp that many users access chrooted. Sysadmins should not use ftp at all, only sftp. 
6. Ftp log should be processes by script and alert generated.
7. Ftp server should always have firewall enabled and in RHEL SELinux enabled.

General Steps

• Disable Anonymous Access.

  Anonymous Access is a method by which any user can gain access to your FTP site without the need of a user account.

  There are some customer facing services that can be served effectively by Anonymous FTP sites, but the majority of the time allowing anonymous access will result in the eventual hijacking of your site by individuals wanting to host illegal files and copyrighted material.

  By removing the capability for anonymous access, you are essentially limiting access to your FTP site to successful authentication by a predefined user account.
  

• Enable Logging.

  By enabling logging your FTP site, you can ensure that you will have an accurate record of which IP addresses and users accessed your site. Maintaining a practice of routine log review can enable you to assess your traffic patterns and identify any security threats and/or breaches.

  Frequent review of logs can alert you to suspicious activity that could be a malicious user trying to hack in. It can also be used as an effective method for intrusion detection by giving you a historical look into your FTP sites usage.
   

• Harden your permissions. If you just getting uploads, setup your FTP site as Blind Put.

  If you only need your users to transfer files to your server and not transfer files from your server, consider configuring your FTP site as a “blind put”. What this means is that users are allowed to write files without the having the ability to read from your FTP directory. This will protect the contents of your ftp site in case of an unauthorized user getting access to your ftp directory.

  Configuring Blind Puts should be done both at the FTP site and on the directory’s permissions.
  

• If each of your users need to  log in to the FTP server, in additional to using separate partition, you can also enable per user disk quotas. That also allows to allocate only a part of disk space to anonimous access, if such is used. 

  Most Unixes allow for the enforcement of Disk Quotas. Disk Quotas can effectively limit the amount of disk space a user can have ownership of.    You can also limit the total number of files (inodes) and some other parameters (Linux File System Quotas)

  edquota -u user_id
  Edit directly using vi editor commands. (See below for more info.)
  For example: edquota -u user1

  System Response (RH 7+):

  Disk quotas for user user1 (uid 501):
    Filesystem                   blocks       soft       hard     inodes     soft     hard
    /dev/hda5                      1944          0          0        120        0        0
        

  • blocks: 1k blocks
  • inodes: Number of entries in directory file
  • soft: Max number of blocks/inodes user may have on partition before warning is issued and grace persiod countdown begins.
    If set to "0" (zero) then no limit is enforced.
  • hard: Max number of blocks/inodes user may have on partition.
    If set to "0" (zero) then no limit is enforced.

• Use Logon Time Restrictions.

  This can be used creatively to limit access to your FTP site to only times that are authorized. If for instance you are using this Ftp site in an enterprise environment for business use, you could assess your availability needs to be limited to working hours. By denying logon during after hours, you would effectively secure your ftp site for most of the calendar day.
  

• Enable Strong Password Requirements.

  Using complex passwords is a good security practice whenever you are dealing with end user authentication. In the case of FTP, it can be a crucial component in securing your site.

  Linux allows for administrators to force users to comply with strong password requirements. By enabling the ‘Passwords Must Meet Complexity Requirements’ via PAM.  In this case FTP user accounts will be forced to adhere to following restrictions when selecting their passwords:

  • Must not contain all or part of the user's account name
  • Must be at least 6 characters in length
  • Contain characters from 3 of the following 4 categories:
    • English uppercase characters (A - Z)
    • English lowercase characters (a - z)
    • Base 10 digits (0 through 9)
    • Non-alphanumeric characters (e.g., !, $, #, %)

• Enable Account Lockout and Account Lockout Threshold.

  Security policies allow administrators to lock down the number of times failed logins can be attempted before an account is locked out. You should enable this option but never set it too low (5 or 7 are usable numbers, 3 is not). By enabling this option you dramatically limit exposure to password crackers.

Securing vsftp

Red Hat Linux provides vsftpd FTP servers - a standalone, security oriented implementation of the FTP service.

• FTP Greeting Banner.

  Before submitting a user name and password, all users are presented with a greeting banner. By default, this banner includes version information useful to crackers trying to identify weaknesses in a system.

  To change the greeting banner for vsftpd, add the following directive to /etc/vsftpd/vsftpd.conf:

  ftpd_banner=<insert_greeting_here>

  Replace <insert_greeting_here> in the above directive with the text of your greeting message.

  To change the greeting banner for wu-ftpd, add the following directives to /etc/ftpusers:

  greeting text <insert_greeting_here>

  Replace <insert_greeting_here> in the above directive with the text of your greeting message.

  For mutli-line banners, it is best to use a banner file. To simplify management of multiple banners, we will place all banners in a new directory called /etc/banners/. The banner file for FTP connections in this example will be /etc/banners/ftp.msg. Below is an example of what such a file may look like:

  ####################################################
  # Hello, all activity on ftp.example.com is logged.#
  ####################################################

  It is not necessary to begin each line of the file with 220 as specified in Section 5.1.1.1 TCP Wrappers and Connection Banners.

  To reference this greeting banner file for vsftpd, add the following directive to /etc/vsftpd/vsftpd.conf:

  banner_file=/etc/banners/ftp.msg

  To reference this greeting banner file for wu-ftpd, add the following directives to /etc/ftpusers:

  greeting terse
  banner /etc/banners/ftp.msg

  It also is possible to send additional banners to incoming connections using TCP wrappers.
  

  Anonymous Access.

  For both wu-ftpd and vsftpd, the presence of the /var/ftp/ directory activates the anonymous account.

  	Caution
  	If enabling anonymous access to an FTP server, be careful where you store sensitive data.

• Anonymous Upload.

  If you want to allow anonymous users to upload, it is recommended you create a write-only directory within /var/ftp/pub/.

  To do this type:

  mkdir /var/ftp/pub/upload

  Next change the permissions so that anonymous users cannot see what is within the directory by typing:

  chmod 730 /var/ftp/pub/upload

  A long format listing of the directory should look like this:

  drwx-wx---    2 root     ftp          4096 Feb 13 20:05 upload

  	Warning
  	Administrators who allow anonymous users to read and write in directories often find that their server become a repository of stolen software.

  Additionally, under vsftpd, add the following line to /etc/vsftpd/vsftpd.conf:

  anon_upload_enable=YES

• User Accounts

  Because FTP passes unencrypted usernames and passwords over insecure networks for authentication, it is a good idea to deny system users access to the server from their user accounts.

  To disable user accounts in wu-ftpd, add the following directive to /etc/ftpusers:

  deny-uid *

  To disable user accounts in vsftpd, add the following directive to /etc/vsftpd/vsftpd.conf:

  local_enable=NO

• Restricting User Accounts.

  The easiest way to disable a specific group of accounts, such as the root user and those with sudo privileges from accessing an FTP server is to use a PAM list file as described in Section 4.4.2.4 Disabling Root Using PAM. The PAM configuration file for wu-ftpd is /etc/pam.d/ftp. The PAM configuration file for vsftpd is /etc/pam.d/vsftpd.

  It is also possible to perform this test within each service directly.

  To disable specific user accounts in wu-ftpd, add the username to /etc/ftpusers:

  To disable specific user accounts in vsftpd, add the username to /etc/vsftpd.ftpusers:

• Use TCP Wrappers To Control Access

  You can use TCP wrappers to control access to either FTP daemon as outlined in

• Enhancing Security With TCP Wrappers
• Use xinetd To Control the Load

  If using wu-ftpd, you can use xinetd to limit the effects of denial of service attacks.

securing Wu-Ftpd server

• Anonymous logins

  Edit the file /etc/ftpaccess and delete all anonymous entries.
  This is an example of how the file ftpaccess would look like:

  class all real,guest *
  
  email [email protected]
  loginfails 3
  
  readme README* login 
  readme README* cwd=* 
  
  message /welcome.msg login
  message .message cwd=* 
  
  compress yes all
  tar yes all
  chmod no guest
  delete no guest
  overwrite no guest
  rename no guest
  
  log transfers anonymous,real inbound,outbound
  shutdown /etc/shutmsg 
  passwd-check rfc822 warn
  guestgroup FTPgroup
  greeting full
  
  

• Adding Users

  First of all create a special usergroup were you can put in all the users. For example FTPgroup

  >> groupadd FTPgroup
  

  Now you can create some users:

  >> adduser -g FTPgroup "username" 
  

  (if you choose not to give shell access to these users look at paragraph 4.)

  >> passwd "username"
  

  Make sure you copy "bin", "etc" and "lib" and the files in it from /home/ftp or /var/ftp to the homedirectory of the user. Use cp -R like this:

  >> cp -R /var/ftp/pub /home/username
  

  Create a directory called Download and Upload in the "pub"directory for the users to up- and download files from.

  >> mkdir /home/username/pub/download
  >> mkdir /home/username/pub/upload
  

  Be sure to set the rights and ownership onto these just created directory's.

  >> chown username:FTPgroup upload download
  >> chmod 500 /home/username/pub/download
  >> chmod 700 /home/username/pub/upload
  

  This will give the user read/write access to upload and read access for the download directory.
  

• Keep users in own Homedirectory

  To keep the users in their own homedirectory you can add "guestgroup FTPgroup" to the ftpaccess file.
  Open /etc/ftpacces with your favorite texteditor and add:
  

   guestgroup FTPgroup
  

• No shell access

  If you choose to deny your users to gain shell access via telnet or ssh all you have to do is create a dummy shell wich you can name NoAccess and place it under /etc/.
  

  >> touch /etc/NoAccess
  

  Open the file with your editor and put something in like this:

   #!/bin/sh
  
   #
  
   echo "             Shell Access denied!             "
   echo "                                              "
   echo " You don't have a valid login for this server "
   exit 0
  

  Save the file and make sure that the shell is executable:

  >> chmod +x /etc/NoAccess.
  

  Once you've done this edit the file /etc/shells and add the just created shell.
  The file /etc/shells would look like this:

   /bin/bash2
   /bin/bash
   /bin/sh
   /bin/ash
   /bin/bsh
   /bin/tcsh
   /etc/NoAccess
  

  If you added the user manually and did not use my shell-script you have to edit /etc/passwd and change the shell for the users.
  The entry would look like this:

  username:x:100:100::/home/username:/bin/bash
  

  Just change /bin/bash to /etc/NoAccess.
  If everything is up and you choose to add users manually you can add the user to the right shell with the next command.

  >> adduser -g FTPgroup -s /etc/NoAcces "username"
  

  In order to automate the creation of users I've created a small shell-script that will add an user to FTPgroup set the shell, creates upload en download and copy's the required dir's from the FTP directory.

   #!/usr/bin/perl
   print "Username: ";
   chomp ($Name =<STDIN>);
   system("adduser -g FTPgroup -s /etc/NoAccess $Name");
   system("cp -R /var/ftp/pub /home/$Name");
   system("cp -R /var/ftp/bin /home/$Name");
   system("cp -R /var/ftp/lib /home/$Name");
   system("cp -R /var/ftp/etc /home/$Name");
   system("mkdir /home/$Name/pub/upload");
   system("mkdir /home/$Name/pub/download");
   system("chown $Name:  $Name/pub/download");
   system("chown $Name:  $Name/pub/upload");
   system("chmod 500 /home/$Name/pub/download");
   system("chmod 700 /home/$Name/pub/upload");
   system("passwd $Name");
   print "Done! user $Name has been added.\n";
  

  You cannot create a textfile under windows and copy in onto your server. This will not work properly.

  Create a file called useradd and insert the lines. You can run the file from the command line like this but first set the rights as followed:

  >> chmod +x useradd
  >> chown root:root useradd

  Then,

  >> /usr/local/scripts/useradd 

  or whatever filepath you wish and start adding users automatically.

NEWS CONTENTS

• 20140110 : Yes, the BBC still uses FTP. And yes, a Russian crook hacked the server ( December 30, 2013 , The Register )
• 20140110 : Securing FTP (1/2) ( )
• 20140110 : Appendix F: Installing in a chroot Environment ( )

Old News ;-)

[Jan 10, 2014] Yes, the BBC still uses FTP. And yes, a Russian crook hacked the server

December 30, 2013 | The Register

A BBC FTP server ftp.bbc.co.uk was compromised by a Russian hacker and access to it touted online, say computer security researchers.

The miscreant behind the attack on the internet-facing file store tried to sell access to the infiltrated system to other crims on Christmas Day, we're told. Hold Security – which this year has helped break news of data heists at Adobe and a top-flight limo company – spotted someone trying to sell access to ftp.bbc.co.uk, according to Reuters.

FTP is a 1970s vintage protocol for transferring information in bulk over the internet; its use is discouraged because usernames and passwords to log into accounts are sent over the network unencrypted, although there are ways to establish secure connections.

The hacked service was used by reporters to file material from the field, and by advertisers to upload video to BBC Worldwide channels. The invaded computer was cleaned up over the weekend.

Right now the system appears to be running ProFTPD 1.3.3g on Solaris, but there's nothing to indicate that was the vulnerable software. However, versions of ProFTPD prior to 1.3.3g suffer from a use-after-free bug (CVE-2011-4130) that allows an attacker to execute code remotely on the machine hosting the server; a flaw that's been known about since 2011.

"The only other information that I can offer is that the hacker was offering a screenshot proving that he had administrative access to the BBC server," Alex Holden, chief information security officer at Hold Security, told BBC News.

It is not clear how deep the hacker managed to penetrate Auntie: specifically, whether the miscreant obtained just an FTP admin account login, gained control of the user account running the FTP daemon, or gained full control of the machine running the file-transfer server. Don't forget, a compromised computer could have acted as a stepping stone to other systems within the Beeb's network.

If it's not broke...

See title. Just because it's old, doesn't mean it doesn't work. And with very much less overhead than sending big files via HTTP.

Though granted, a restricted-access FTP site should really be sFTP.

Re: If it's not broke...

"should be living on the DMZ"

Should be on A DMZ, not THE DMZ. Why should my FTP server be anywhere near the web server or mail server? Modern firewall design allows individual dirty networks for services so why only have a single big dirty network playground for hackers? The fewer systems they can access from the compromised one the less likely it is they will spread to the internal networks.

I also hate the term DMZ since the dirtiest network after internet is often the internal client one, and DMZ sits next to the internal networks rather than between them and internet these days so DMZ is very outdated.

Re: If it's not broke...

Yup, nothing wrong with FTP if you ask me. It's simple, robust and can be made as secure as a remote connection can be. Certainly the method of choice for the Beeb's field reporters, safer and more robust than pretty much anything more "current", bar sFTP (which ain't that "current" itself, if a good 20 years younger).

Re: If it's not broke...

"safer and more robust than pretty much anything more "current""

There is also FTPS which predates SFTP by a few years while using the actual FTP protocol and daemons. Of course, the protocol isn't what the problem was here, it was a software bug leading to rights escalation and so could just as easily affect SCP/SFTP. It's less likely that anyone would find the bugs in the FTP/S daemon these days when compared to SFTP due to lower usage but if someone wants your system there is usually a way.

Re: If it's not broke...

"FTP is a 1970s vintage protocol".

Yes, like TCP and IP and many others in everyday use. What's your point?

Re: If it's not broke...

> There is also FTPS

I don't usually consider FTPS a separate protocol; it's still FTP

> a software bug leading to rights escalation and so could just as easily affect SCP/SFTP.

Indeed. Especially SCP, which is known to be vulnerable (which is why most "scp" clients actually use SFTP under the hood).

Re: If it's not broke...

The problem with the "If its not broke, don't fit it" attitude is that, when it infects management, it is used as an excuse to deny or delay all preventative maintenance, patching, and so on. Resulting in, eventually, system failures and security breaches due to outdated, bugged, and vulnerable versions of software or sub-optimal configuration. Management would often prefer to have failures they can blame on software bugs or attackers to having a failed modification or patch being blamed on their own department.

Yes, FTP is a relatively lightweight and efficient protocol, but you still need to keep up with the patching and improve security (such as switching to sFTP or FTPS as you mentioned).

Re: If it's not broke...

The problem with the "If its not broke, don't fit it" attitude

And when the Damagement have the desire to fix everything regardless of whether it's broke, we end up with the Windows 8 UI. The problem is in how to educate the bosses enough that they understand what "maintenance" is without going batshit crazy on "new". Or worse, "better because it's newer".

Siemens

Why blame the BBC? This stuff was outsourced to Siemens in 2004. I should know, I was one of the poor sods who was sold!

That said from the sounds of it, the ftp access pre-dates even BBC Technology back to the days of the beardy wierdy geniuses at Kingswood Warren.

Re: Siemens

The service part of Siemens was bought out by Atos.

There are many parts of BBC IT outsourced to Atos (BBC Desktop for example) but much is run in house as well by BBC Technology / Tech Ops (most of the web based services and as noted above, BBC Worldwide).

There will probably be much finger pointing as there often is with these things. That's if there was any serious threat. A "stepping stone" it may have been, but into what exactly? And let's face it, the Beeb is just a media organisation, not a bank or a holder of huge amounts of important personal data.

Maybe someone could have done us a favour and taken Radio 1 off the air.

Re: Siemens: To be fair...

It's pretty safe to say that the BBC have enormous amounts of personal data.

Given the prevalence of password reuse, they hold plenty of concern even if you only think in terms of email/password pairs. That said, I do see your point. Anybody with best practices in mind when watching "World's Craziest Fools," is fine.

*nips off to change some passwords*

Anon5000

The 1337day site has an exploit for sale which claims to be for ProFTPD 3.3.3g and quotes the BBC FTP site. Some of their exploits for sale have been a bit dubious in the past so rather than it being a new ProFTPD vulnerability it may just be instructions on a misconfiguration of that particular server.

Always have loved the simplicity and stability of FTP personally and added secure SSL functionality has been available for years on many clients/servers. FxP'ing between servers still happens!

"account running the ftp daemon"

Since this was the bbc, what are the chances that ftp was running as root?

Anonymous Coward

Many of our clients still use ftp to send data to us every few minutes throughout the day (Gas Industry). This is all over Europe and beyond not just in the UK so FTP is very far from dead. As for the attack itself, shocker, an FTP account where the username and password are sent in plain text was compromised (although it seems the attacker here had it even easier). That is why an FTP box just does FTP and sits out on its own in the DMZ and only has the required ports open to the outside (in other words was SSH available to the Outside). I do also wonder if they restrict user accounts, I only allow 3rd parties FTP and FTPS access (and that FTPS access is not run by my SSH daemon either), they have no shell so would have to find a vulnerability in order to elevate themselves somehow. Even if they did compromise the box, it wouldn't help them much here as it has no access to anything else.

I live under the assumption I have been hacked or will be, makes it much easier to manage risk. I hope the BBC do the same.

Anonymous Coward

Software Clients - pass the blame

Maybe this is something to do with Microsoft, having failed to support sftp clients/servers as part as their supplied install packages, whilst maintaining support for ftp.

Anonymous Coward

Re: Software Clients - pass the blame

Erm, but Microsoft has supplied and supported an RFC based FTPS (FTP over SSL) server ever since IIS7....

AJ MacLeod

Re: Software Clients - pass the blame

FTPS != SFTP (which is far more widely used IME)

Anonymous Coward

aspera

They use a pretty convoluted aspera based ingest system for almost everything important, content wise anyway.

That said, the bbc is a loose collection of individuals who basically hate each other and are allowed to operate as virtually separate companies.

There are hundreds of FTP servers operating internally and externally for various puropses, getting files on and off the system for engineering purposes, providing logs to suppliers for support, just the usual mash up.

They use a broad range of operating systems ranging from windows 3.11 all the way up to win8 and a whole host of x like systems. Nothing gets patched, in case the patch upsets some of the unsupported 15 year old mission critical software that Dave from FM&T wrote in 1999.

I swear, only a few years ago, I looked after ceefax that has only just been switched off, when asked to find out why it kept falling over, I found the servers in a cupboard and they were a rag tag assortment of 386's the occasional Pentium 1 and, well, you can imagine the rest.

They do take perimeter network security reasonably seriously though so I very much doubt that this FTP server will have made an easy stepping stone into the rest of the network.

caffn8me

ITN hacked via FTP too

Many years ago (about 1999/2000) I was called in to deal with a hack via FTP which defaced ITN's web ste. That was a Solaris box to - a Sun E450.

It wasn't a technically difficult hack though. FTP was world available, the username was ITN and the password ITN. This account had root privilege. Doh!

Securing FTP (1/2)

Jim has written a great article on how you can upgrade your FTP site's security through simple configuration changes.Securing FTP

This document contains information about securing the Internet File Transfer Protocol (FTP) server. While there are a variety of daemons around, most of the material covered here pertains only to wu-ftpd.

In the past there have been bugs found in older versions of various ftpd daemons. Crackers have exploited these bugs and will continue to do so. See http://www.netect.com/advisory_0209.html for the latest attack exploiting a problem in the realpath() function. So, the first order of business is to upgrade that server to the latest version! My favorite site for finding wu-ftpd is at ftp://ftp.vr.net/pub/wu-ftpd/wu-ftpd/, which also includes "vr" patches; they're in my mind akin to the Linux kernel's "ac" patches.

Now on to some really fun steps (as if compiling ftp isn't already fun):

1. Check your /etc/ftpusers (a misnomer in my opinion).

   This file includes the login names of those users who are NOT allowed to login to your site. This file may look something like:

   ~[root(lindstrom)1]: cat /etc/ftpusers
   root
   bin
   daemon
   adm
   lp
   sync
   shutdown
   halt
   mail
   news
   uucp
   operator
   games
   nobody
   

   At the very least, this file should contain root, system accounts, and nobody. Other possible users will include anonymous and ftp. Adding those accounts will effectively disable anonymous ftp. Removing the ftp user from /etc/passwd will also disable anonymous ftp.

Lets take a peek at /etc/ftpaccess as well

This file configures ftpd, but only if ftpd is called with -a. I recommend using this handy feature. Discussing all the possibilities of this file is out of the scope of this document. I urge you to man ftpaccess to get a better understanding of it.

• Every happy server should do some logging.

  In order to do such things we'll use the "log" directive. Typically you'll want to log transfers and violations of security rules. I also log commands as well. To achieve this, I've added: log transfers anonymous,real,guest inbound,outbound
  log security anonymous,guest,real
  log commands real,anonymous,guest Logging of incoming and outgoing transfers will go to /var/log/xferlog, unless otherwise changed by adding: log syslog
  

• Well isn't that a funny-looking file..

  Path-filters are useful, particularly if you have your site setup for "drop-off" areas where uploading is permitted. Path-filters use regular expressions to determine what a file can or cannot be. /etc/pathmsg will be displayed when a filename is unacceptable according to the following filters: path-filter anonymous /etc/pathmsg ^[-A-Za-z0-9_\\.]*$ ^\\. ^-
  path-filter guest /etc/pathmsg ^[-A-Za-z0-9_\\.]*$ ^\\. ^-
  path-filter real /etc/pathmsg ^[-A-Za-z0-9_\\.]*$ ^- These filters permit anonymous and guest users to create only files containing A-Z, a-z, 0-9, a period, an underscore or a dash, but NOT beginning with a period or dash. Now these users will no longer be able to create directories that contain spaces, special characters, con trol characters, or the like. Directories of this nature are often used to hide pirated software. Real users have almost the same rules as anonymous and guest, except a real user can create a file beginning with a period.
  

• Noretrieve and the wonderful world of uploads

  To prevent certain files from being retrieved, use the noretrieve directive. Some examples might include: noretrieve .notar
  noretrieve /home/ftp/incoming/
  noretrieve /home/ftp/incoming/lost+found
  Marking the file ".notar" noretrieve will prevent it from confusing some clients. I'll talk about its purpose later on. The incoming directory shouldn't allow downloads until the admin has had a chance to inspect the files and move them to an appropriate public place for downloading. If your /incoming directory is on its own partition/drive (which is good practice to prevent Denial of Service attacks on the filesystem, and you might also consider mountin g it with the "nodev" and "noexec" options), there will be a lost+found directory. The contents of this directory shouldn't be downloaded.

  wu-ftpd by default doesn't allow anonymous uploads, so this will have to be changed if you so desire. For this example, we'll assume that the upload directory in the chroot environment is /incoming. This is what a typical configuration may look: upload /home/ftp * no
  upload /home/ftp /bin no
  upload /home/ftp /etc no
  upload /home/ftp /lib no
  upload /home/ftp /incoming yes ftpadmin ftpadmin 0440 nodirs
  Here we've explicitly said that uploads are denied everywhere except for /incoming. Files uploaded will have owner and group of ftpadmin, permissions set to 0440. Users will not be able to make directories by adding "nodir." I don't recommend allowing users to make directories.

  One note about directories and incoming: You may like to setup your incoming directory to something like /incoming/[some dir], where "some dir" is a directory known only to your local users and those you want to have upload access to your site. This way the occasional passer-byer who logs in wont be able to upload anything unless th e correct directory is known. Granted, this is like a weak password in many ways.

  Sometimes it may be desirable to set a umask for uploaded files. This can easily be accomplished by using "defmask" or calling ftpd with the -u option. The following sets a umask of 0377 for everyone:

  defumask 0377 or this sets a umask of 0377 for class remote only: defumask 0377 remote

  
  
• Everybody loves guests!
Let's talk about guestgroup for a moment. When a real user is a member of a guestgroup (as defined in ftpaccess), the user is treated like an anonymous user and the session is chrooted. This also requires a little bit /etc/passwd fun! Let's say we put: guestgroup ftpguest in our ftpaccess file. Any user logging in as a member of "ftpguest" will be setup as a guest. However, before we can rejoice, we need to do that passwd editing. For this example, user bob is a member of "ftpguest" and we want bob to be chrooted. Normally his passwd line would look like bob:x:1051:502:mister the bob:/home/bob/:/bin/ftpshell so instead we change it to bob:x:1051:502:mister the bob:/home/bob/./:/bin/ftpshell

The path specified before the /./ tells the daemon where to chroot to. The path that follows the /./ is the user's home directory in the chrooted environment. Now, when bob logs in, he will be chrooted to /home/bob, and his current directory will be / (which, outside of the chrooted environment is /home/bob).
Also, since the user is chrooted to /home/bob, he will require an ls binary inorder to be able to do a dir listing, just like how any anonymous user will require the same thing. necessary binaries and the structure of ~ftp/ is the next topic.


• I'm sorry I can't allow you to do that, Dave.
While it's the default in most wu-ftpd configurations, it's a good idea to explicitly disallow anonymous/guest users any privileges. So, to revoke these rights, add to ftpaccess:

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

Setting up the FTP area file structures

Finally we setup restrictions at the file level.

The root directory and every directory under it should not be owned by the same user/group of the ftp account. We certainly don't want anonymous users writing to just anywhere.

d--x--x--x 2 ftpadmin ftpadmin 1024 Feb 12 18:34 bin/
d--x--x--x 2 ftpadmin ftpadmin 1024 Jul 11 06:36 etc/
drwxr-xr-x 2 ftpadmin ftpadmin 1024 Feb 5 14:48 lost+found/
drwxr-xr-x 7 ftpadmin ftpadmin 1024 Mar 31 17:04 pub/
drwxrws-wt 2 ftpadmin ftpadmin 1024 Jul 18 01:00 incoming or if you want to use the 'secret' directory approach for uploads: drwxr-x--x 3 ftpadmin ftpadmin 1024 Jan 2 1999 incoming/
drwxrws-wt 3 ftpadmin ftpadmin 1024 Jan 2 1999 incoming/secret_upload_dir

• /bin

  ls, tar, and gzip live here. tar and gzip are optional and used for on-the-fly compression. All files should be compiled statically, mode 111, and owned by root. NEVER put any command interpreters in here.

• /etc

  Passwd and group files go in here, and possibly other needed files like pathmsg (see above). Please note, however, these should NOT be the same files from /etc/passwd and /etc/group. This would permit anyone to retrieve a copy of your account information. Instead, they should contain only the usernames and groups of files in t he FTP directories, and NO password information. An example might be

  lindstrom(root):/home/ftp# cat ./etc/passwd
  root:*:0:0:::
  bin:*:1:1:::
  ftpadmin:*:111:111:::
  ftp:*:14:50:::
  
  lindstrom(root):/home/ftp# cat ./etc/group
  root::0:
  bin::1:
  ftpadmin::111:
  ftp::50:
  

• So what about the rest of those directories?

  If you've done everything concerning /incoming you should be fine. There is no need for a /lib because all of our binaries are compiled statically. However, if you weren't able to compile your binaries static, the libs that they require would live here. /lost+found we've talked about earlier, (remember it's that directo ry you magically get when you create a partition) and /pub will also be fine as long as sane user/group/permissions are used, as talked about in this section.
  

• Odds and Ends..

  Adding .forward .rhosts to the FTP root would be a good idea to prevent these from being added later by some other means, such as an exploit. The justifiably paranoid may chattr +i these files. /home/ftp[root(lindstrom)2]: touch .forward .rhosts
  /home/ftp[root(lindstrom)3]: chmod 0 .forward .rhosts
  /home/ftp[root(lindstrom)4]: chattr +i .forward .rhosts
  Also, its a good idea to add ".notar" as well to your incoming directories so as to prevent keen users from downloading files using on-the-fly tarring.
  

Other points of interest

For the paranoid, wu-ftpd has something just for you. Define paranoid in config.h and "questionable functions" will be disabled. Check out FIXES-2.4-HOBBIT from wu-ftpd source for more info on this.

Support for S/Key and OPIE are included in wu-ftpd, and I've seen patches for SSL and SRP floating around the internet. SSL for wu-ftpd is at ftp://ftp2.replay.com/pub/crypto/crypto/SSLapps/. However, it's a bit dated as far as keeping up with recent versions of wu-ftpd. There i s also edssl (a non SSL to SSL translator) in the /pub/crypto/crypto/SSLapps/SSLlynx/ directory on that site. SRP patches can be found at MrWizard's homepage along with some other nifty things.

Appendix F: Installing in a chroot Environment

This appendix provides instructions for installing and running Sun^™ ONE Identity Server in a chroot environment. This appendix contains the following sections:

• Overview
• Before Creating chroot
• Creating a chroot Environment
• Installing Identity Server Under chroot
• Starting Identity Server In chroot
• Identity Server Log Files In chroot

Chroot comes from the change root function in Unix®. When Identity Server is installed in a chroot environment, a named directory becomes the root directory. The new chroot directory then becomes the starting point in the path for all Identity Server searches. The chroot prevents malicious programs from accessing the real root file system, providing an added measure of security for the Web Server and Directory Server processes that power Identity Server.

Before beginning the chroot creation process, the following points should be noted:

• You must have root privileges in UNIX or Administrator privileges in Windows® to install Identity Server in a chroot environment.
• Patches cannot be automatically installed in the chroot environment. If any patches have been installed to your system, they must be manually copied to the appropriate locations:
• Sun ONE Directory Server
• Sun ONE Web Server
• Sun ONE Identity Server
• Solaris

Identity Server processes that serve requests cannot see or access files outside the chroot directory so the appropriate Identity Server files must be copied into the chroot directory structure. The first step is to create the user root environment for Identity Server. This new root must contain everything that Identity Server expects from the natural root (/).

Note	$CHROOT is the variable name for the chroot directory.

1. Create the following system directories on the computer system that will host Identity Server.

/dev

/etc

/sbin

/usr

/var

/proc

/opt

/etc/lib

/usr/platform

/usr/bin

/usr/sbin

/usr/lib

/usr/openwin/lib

/var/opt

/var/tmp

/usr/share

/usr/share/lib

2. Create system soft links using the command ln -s.

The following soft links should be created:

• /usr/bin -> bin
• /usr/lib -> lib
• /var/tmp -> tmp
3. Create devices under $CHROOT using the command mknod.

Tip	For example, to create the device /dev/tcp under the $CHROOT directory, enter: mknod dev/tcp c 11 42

The following devices should be created under the $CHROOT directory:

• /dev/null
• /dev/tcp
• /dev/ticots
• /dev/ticlts
• /dev/ticotsord
• /dev/tty
• /dev/udp
• /dev/zero
• /dev/conslog
4. Copy files from directory /etc to corresponding locations under the $CHROOT directory. (For example, copy /etc/hosts to $CHROOT/etc/hosts.)

The following files should be copied:

• /etc/hosts
• /etc/nsswitch.conf
• /etc/vfstab
• /etc/group
• /etc/passwd
• /etc/shadow
• /etc/hosts
• /etc/resolv.conf
• /etc/nsswitch.conf
5. Copy binaries to the corresponding locations under the $CHROOT directory. (For example, copy /usr/bin/sh to $CHROOT/usr/bin/sh.)

The following files should be copied:

• /usr/bin/sh
• /usr/bin/ls
• /usr/bin/cat
• /usr/bin/date
• /usr/bin/dirname
• /usr/bin/mv
• /usr/bin/expr
• /usr/bin/file
• /usr/bin/awk
• /usr/bin/grep
• /usr/bin/gettext
• /usr/bin/echo
• /usr/bin/rm
• /usr/bin/sed
• /usr/bin/sleep
• /usr/bin/hostname
• /usr/bin/domainname
• /usr/bin/cut
• /usr/bin/uname
• /usr/bin/ksh
• /usr/bin/basename
• /usr/bin/id
• /usr/bin/chmod
• /usr/bin/nohup
• /usr/bin/pkginfo
• /usr/bin/su
• /usr/bin/chown
• /usr/bin/ftp
• /usr/bin/isainfo
• /usr/bin/ldd
• /usr/bin/truss
• /usr/bin/rm
• /usr/xpg4/bin/id
6. Copy libraries to corresponding locations under the $CHROOT directory. (For example, copy /usr/lib/libc.so* to $CHROOT/usr/lib/.)

Note	If the computer system in which Identity Server is installed is a 64-bit machine, the libraries from /usr/lib/64 and /usr/lib/lwp/64 need to be copied to $CHROOT/usr/lib/64 and $CHROOT/usr/lib/lwp/64, respectively.

The following files should be copied:

• /usr/lib/libc.so*
• /usr/lib/ld.so*
• /usr/lib/libdl.so*
• /usr/lib/libintl.so*
• /usr/lib/libnsl.so*
• /usr/lib/libsocket.so*
• /usr/lib/librpcsvc.so*
• /usr/lib/libw.so*
• /usr/lib/libproject*
• /usr/lib/libproc*
• /usr/lib/libsecdb*
• /usr/lib/libcmd*
• /usr/lib/libmp.so*
• /usr/lib/libm.so*
• /usr/lib/libresolv.so*
• /usr/lib/nss_dns.so*
• /usr/lib/nss_files.so*
• /usr/lib/nss_nis.so*
• /usr/lib/nss_nisplus.so*
• /usr/lib/straddr.so*
• /usr/lib/libthread.so*
• /usr/lib/libposix4.so*
• /usr/lib/libC.so*
• /usr/lib/librt.so*
• /usr/lib/libaio.so*
• /usr/lib/libelf.so*
• /usr/lib/libgen.so*
• /usr/lib/libpthread.so*
• /usr/lib/libadm.so*
• /usr/lib/libX*
• /usr/lib/libCrun.so*
• /usr/lib/libatomic.so*
• /usr/lib/libdhcpagent.so*
• /usr/lib/libproject.so*
• /usr/lib/libpam.so*
• /usr/lib/libbsm.so*
• /usr/lib/libsldap.so*
• /usr/lib/libldap.so*
• /usr/lib/libdoor.so*
• /usr/lib/libz.so*
• /usr/lib/libkstat*
• /usr/lib/libld.so*
• /usr/lib/liblddbg.so*
• /usr/lib/librtld.so*
• /usr/lib/libsh.so*
• /usr/lib/lddstub*
• /usr/lib/librtld_db.so*
• /usr/lib/libmd5.so*
• /usr/lib/locale
• /usr/lib/libCstd.so*
7. Copy the zoneinfo files to corresponding locations under the $CHROOT directory. (For example, copy /usr/share/lib/zoneinfo/* to $CHROOT/usr/share/lib/.)
8. Copy the locale files to corresponding locations under the $CHROOT directory. (For example, copy /usr/lib/locale/* to $CHROOT/usr/lib/locale.)

Installing Identity Server Under chroot

1. Install Identity Server 6.1 in a directory other than $CHROOT.

If an installation directory is not specified, Identity Server is installed, by default, in /opt/IdentityServer_base .

2. Stop the instance of Sun ONE Web Server.

./WebServer_base/https-instanceName/https-stop

3. Stop the instance of Sun ONE Directory Server.

./DirectoryServer_base/slapd-instanceName/stop-slapd

4. Copy the entire Identity Server directly from IdentityServer_base to the $CHROOT directory using the same structure.
5. Copy files from the following locations to the corresponding directories under $CHROOT:
• /etc/opt/SUNWam
• /var/opt/SUNWam
• /etc/init.d/amserver
6. Create a loopback mount for Java.

The following command makes Identity Server ready to run under chroot environment:

mount -F lofs /usr/j2se $CHROOT/usr/j2se

7. Create a loopback mount for /usr/share/lib and /usr/lib/mps.

Examples:

mount -F lofs /usr/share/lib $CHROOT/usr/share/lib

mount -F lofs /usr/lib/mps $CHROOT/usr/lib/mps

Starting Identity Server In chroot

To start Identity Server in the chroot environment, both Directory Server and Web Server must be started.

1. Start Directory Server using the chroot command:

chroot $ROOT $IS_ROOT/DSServers/slapd-hostName/start-slapd

2. Start Web Server using the chroot command:

chroot $ROOT $IS_ROOT/SUNWam/servers/https-instanceName/https-start

Identity Server Log Files In chroot

Identity Server normally creates log files (Error Log, Debug, etc.) in the following directory:

/var/opt/SUNWam/debug and /var/opt/SUNWam/logs

Under chroot these log files will be created at the following locations:

$CHROOT/var/opt/SUNWam/log

$CHROOT/var/opt/SUNWam/debug

Setup an FTP user account minus shells

It's important to give to your strictly FTP users no real shell account on the Linux system. In this manner, if for any reasons someone could successfully get out of the FTP chrooted environment, it would not have the possibility of executing any user tasks since it doesn't have a bash shell. First, create new users for this purpose;

These users will be the users allowed to connect to your FTP server.

This has to be separate from a regular user account with unlimited access because of how the chroot environment works. Chroot makes it appear from the user's perspective as if the level of the file system you've placed them in is the top level of the file system.

Use the following command to create users in the /etc/passwd file. This step must be done for each additional new user you allow to access your FTP server.

[root@deep ] /# mkdir /home/ftp [root@deep ] /# useradd -d /home/ftp/ftpadmin/ -s /dev/null ftpadmin > /dev/null 2>&1 [root@deep ] /# passwd ftpadmin

Changing password for user ftpadmin New UNIX password: Retype new UNIX password: passwd: all authentication tokens updated successfully

• The mkdir command will create the ftp directory under the /home directory to handle all FTP users' home directories we'll have on the server.
• The useradd command will add the new user named ftpadmin to our Linux server.
• Finally, the passwd command will set the password for this user ftpadmin.

Once the home/ftp/ directory has been created you don't have to use this command again for additional FTP users.

1. Edit the /etc/shells file, vi /etc/shells and add a non-existent shell name like null, for example. This fake shell will limit access on the system for FTP users.

   [root@deep ] /# vi /etc/shells

   /bin/bash /bin/sh /dev/null

   /dev/null, This is our added no-existent shell. With Red Hat Linux, a special device name /dev/null exists for purposes such as these.

2. Now, edit your /etc/passwd file and add manually the /./ line to divide the /home/ftp directory with the /ftpadmin directory where the user ftpadmin should be automatically chdir'd to. This step must be done for each FTP user you add to your passwd file.

   ftpadmin:x:502:502::/home/ftp/ftpadmin/:/dev/null

   To read:

   ftpadmin:x:502:502::/home/ftp/./ftpadmin/:/dev/null ^^

   The account is ftpadmin, but you'll notice the path to the home directory is a bit odd. The first part /home/ftp/ indicates the filesystem that should be considered their new root directory. The dot . divides that from the directory they should be automatically chdir'd. change directory'd into, /ftpadmin/.

Once again, the /dev/null part disables their login as a regular user. With this modification, the user ftpadmin now has a fake shell instead of a real shell resulting in properly limited access on the system.

Setup a chroot user environment

What you're essentially doing is creating a skeleton root file system with enough components necessary, binaries, password files, etc. to allow Unix to do a chroot when the user logs in. Note that if you use the --enable-ls option during compilation as seen above, the /home/ftp/bin, and /home/ftp/lib directories are not required since this new option allows Wu-ftpd to use its own ls function. We still continue to demonstrate the old method for people that prefer to copy /bin/ls to the chroot'd FTP directory, /home/ftp/bin and create the appropriated library related to ls.

The following are the necessary steps to run Wu-ftpd software in a chroot jail:

First create all the necessary chrooted environment directories as shown below:

[root@deep ] /# mkdir /home/ftp/dev [root@deep ] /# mkdir /home/ftp/etc [root@deep ] /# mkdir /home/ftp/bin [root@deep ] /# mkdir /home/ftp/lib

The last two are required only if you are not using the --enable-ls option.

Change the new directories permission to 0511 for security reasons: The chmod command will make our chrooted dev, etc, bin, and lib directories readable and executable by the super-user root and executable by the user-group and all users.

[root@deep ] /# chmod 0511 /home/ftp/dev/ [root@deep ] /# chmod 0511 /home/ftp/etc/ [root@deep ] /# chmod 0511 /home/ftp/bin [root@deep ] /# chmod 0511 /home/ftp/lib

1. Copy the /bin/ls binary to /home/ftp/bin directory and change the permission of the ls program to 0111. You don't want users to be able to modify the binaries:

   [root@deep ] /# cp /bin/ls /home/ftp/bin [root@deep ] /# chmod 0111 /bin/ls /home/ftp/bin/ls

   This step is necessary only if you're not using the --enable-ls option during the configure time of Wu-ftpd. See the Compile and Optimize section in this chapter for more information.

2. Find the shared library dependencies of the ls Linux binary program:

   1. [root@deep ] /# ldd /bin/ls

      libc.so.6 => /lib/libc.so.6 (0x00125000) /lib/ld-linux.so.2 =7gt; /lib/ld-linux.so.2 (0x00110000)

   2. Copy the shared libraries identified above to your new lib directory under /home/ftp directory:

      [root@deep ] /# cp /lib/libc.so.6 /home/ftp/lib/ [root@deep ] /# cp /lib/ld-linux.so.2 /home/ftp/lib/

   3. These library are needed to make ls work. Also, steps 3 and 4 above are required only if you want to use the ls Linux binary program instead of the --enable-ls option that uses the new internal ls capability of Wu-ftpd.

3. Create your /home/ftp/dev/null file:

                 [root@deep ] /# mknod /home/ftp/dev/null c 1 3
                 [root@deep ] /# chmod 666 /home/ftp/dev/null           

4. Copy the group and passwd files in /home/ftp/etc directory. This should not be the same as your real ones. For this reason, we'll remove all non FTP users except for the super-user root in both of these files, passwd and group.

   1.                 [root@deep ] /# cp /etc/passwd /home/ftp/etc/
                      [root@deep ] /# cp /etc/group /home/ftp/etc/
                    

   2. Edit the passwd file, vi /home/ftp/etc/passwd and delete all entries except for the super-user root and your allowed FTP users. It is very important that the passwd file in the chroot environment has entries like:

                      root:x:0:0:root:/:/dev/null
                      ftpadmin:x:502:502::/ftpadmin/:/dev/null             

   3. : We can notice two things here: first, the home directory for all users inside this modified passwd file are now changed to reflect the new chrooted FTP directory i.e. /home/ftp/./ftpadmin/ begins /ftpadmin/, and also, the name of the user's login shell for the root account has been changed to /dev/null.

   4. Edit the group file, vi /home/ftp/etc/group and delete all entries except for the super-user root and all your allowed FTP users. The group file should correspond to your normal group file:

                      root:x:0:root
                      ftpadmin:x:502:             

5. Now we must set passwd, and group files in the chroot jail directory immutable for better security.

   1.                 [root@deep ] /# cd /home/ftp/etc/
                      [root@deep ] /# chattr +i passwd             

   2. Set the immutable bit on group file:

                      [root@deep ] /# cd /home/ftp/etc/
                      [root@deep ] /# chattr +i group             

Configure the /etc/ftphosts file

The /etc/ftphosts file is used to define whether users are allowed to log in from certain hosts or whether there are denied access.

1. Create the ftphosts file, touch /etc/ftphosts and add for example in this file the following lines:

             # Example host access file
             #
             # Everything after a '#' is treated as comment,
             # empty lines are ignored
             allow ftpadmin 208.164.186.1 208.164.186.2 208.164.186.4
             deny ftpadmin 208.164.186.5
           

   In the example below, we allow the user ftpadmin to connect via FTP from the explicitly listed addresses 208.164.186.1 208.164.186.2 208.164.186.4, and deny the specified ftpadmin user to connect from the site 208.164.186.5.

2. Now, change its default permission to be 600:

             [root@deep ] /# chmod 600 /etc/ftphosts        

Configure the /etc/ftpusers file

The /etc/ftpusers/ file specifies those users that are NOT allowed to connect to your FTP server.

1. Create the ftpusers file, touch /etc/ftpusers and add in this file the following users for security reasons:

               root
               bin
               daemon
               adm
               lp
               sync
               shutdown
               halt
               mail
               news
               uucp
               operator
               games
               nobody
             

2. Now, change its default permission to be 600:

               [root@deep ] /# chmod 600 /etc/ftpusers          

Configure the /etc/pam.d/ftp file

Configure your /etc/pam.d/ftp file to use pam authentication by creating the /etc/pam.d/ftp file and add the following lines:

          #%PAM-1.0
          auth       required     /lib/security/pam_listfile.so item=user sense=deny file=/etc/ftpusers onerr=succeed
          auth       required     /lib/security/pam_pwdb.so shadow nullok
          auth       required     /lib/security/pam_shells.so
          account    required     /lib/security/pam_pwdb.so
          session    required     /lib/security/pam_pwdb.so