Softpanorama May the source be with you, but remember the KISS principle ;-)
	Contents	Bulletin	Latest	Last year	Top visited	Scriptorama

FTP server security

For Solaris

1. WU-FTPD supplied with Solaris 9 and 10 is OK
2. TCP wrappers are obligatory
3. Separate disk partition for downloads is obligatory; should be mounted nosuid

General Steps

• Disable Anonymous Access.

  Anonymous access is enabled by default when you first install FTP services in Windows 2000. 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.


• Harden your permissions.
• 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.
  

• Enable Disk Quotas.

  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. By default, ownership is granted to whichever user wrote the file. By enabling disk quotas and checking the deny disk space to users exceeding disk quota, you can effectively limit the possible damage caused in case your FTP site gets hijacked. One worst scenario is the abuse of an FTP site to the point that the disk fills up. This of course can have disastrous consequences to other services that might share the partition with the FTP site.

  Also, by limiting the amount of disk space each FTP user can have, your site becomes an unattractive target for hackers looking for someplace to share their media files.
  

• 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 shut down and secure your ftp site for most of the calendar day.
  

• Restrict Access by IP using TCP wrappers
  

  FTP accesscan 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.
  

• Enable Logs .

  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.
  

• 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’ field in Local Security Policy or Group Policy, 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. By enabling this option and configuring the threshold, administrators can limit their 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 control the amount of resources the FTP server consumes and to limit the effects of denial of service attacks. See

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 your@email.com
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.

Old News

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