[ Pobierz całość w formacie PDF ]

all the network based parts of ftp, lets go over securing the user accounts and environment.
The main mechanism for user security in ftpd is the use of chroot. For example by default all
people logging in as anonymous have /home/ftp/ set as their 'root'. They cannot get out of this
and say look at the contents of /home/ or /etc/. The same can be applied to groups of users
and/or individuals, for example you could set all users to be chroot'ed to /home/ when they ftp
in, or in extreme cases of user privacy (say on a www server hosting multiple domains) set
each user chroot'ed to within their own home directory. This is accomplished through the use
of /etc/ftpaccess and /etc/passwd (man ftpaccess has all the info). I will give a few examples
of what needs to be done to accomplish this since it can be quite confusing at first. As well
ftpd checks /etc/ftpusers and if the user attempting to login is listed in that file (like root
should be) it will not let the user login via ftp.
To chroot users as they login into the ftp server is rather simple, but poorly documented. The
ftp server check ftpaccess for 'guestgroup's, which are simply "guestgroup some-group-on-
the-system" i.e. "guestgroup badusers", and the groupname needs to be defined in /etc/group
and have members added. As well you need to edit their passwd file line so that the ftp server
knows where to dump them. And since they are now chrooted into that directory on the
system, they do not have access to /lib, etc so you must copy certain files into their dir for
things like ls to work properly (always a nice touch).
Setting up a user (billybob) so that he can ftp in, and ends up chroot'ed in his home directory
(because he keeps threatening to take the sysadmin possum hunting). In addition to this
billybob can telnet in and change his password, but nothing else because he keeps trying to
run ircbots on the system. The system he is on uses shadowed passwords, so that's why there
is an 'x' in billybob's password field.
First off billybob needs a properly setup user account:
billybob:x:500:500:Billy Bob:/home/billybob/./:/usr/bin/passwd
this means that the ftp server will chroot billybob into /home/billybob/ and chdir him into
what is now / (/home/billybob to the rest of us). The ftpaccess man file covers this bit ok, and
of course /usr/sbin/passwd needs to be listed in /etc/shells
Secondly for the ftp server to know that he is being chrooted he needs to be a member of a
group (badusers, ftppeople, etc) that is defined in /etc/group. And then that group must be
listed in /etc/ftpaccess.
Now you need to copy some libs/binaries otherwise billybob won't be able to do a whole lot
once he has ftp'ed in. The files needed are available as packages (usually called  anonftp ),
once this is installed the files will be copied to /home/ftp/, you will notice there is an
etc/passwd, this is simply uses to map UID's to usernames, if you want billybob to see his
username and not UID, add a line for him (i.e. copy his line from the real /etc/passwd to this
one). The same applies to the group file.
without "billybob:*:500:500:::" in /home/billybob/etc/passwd:
drwxr-xr-x 2 500 500 1024 Jul 14 20:46 billybob
62
and with the line added:
drwxr-xr-x 2 billybob 500 1024 Jul 14 20:46 billybob
and with a line for billybob's group added to the group file:
drwxr-xr-x 2 billybob billybob 1024 Jul 14 20:46 billybob
Billybob can now ftp into the system, upload and download files from /home/billybob to his
hearts content, change his password all on his own, and do no damage to the system, nor
download the passwords file or other nasty things.
FTP is also a rather special protocol in that the clients connect to port 21 (typically) on the ftp
server, and then port 20 of the ftp server connects to the client and that is the connection that
the actual data is sent over. This means that port 20 has to make outgoing connections, keep
this in mind when setting up a firewall either to protect ftp servers or clients using ftp. As well
there is 'passive' ftp and usually used by www browsers/etc, and involves incoming
connections to the ftp server on high port numbers (instead of using 20 they agree on
something else). If you intend to have a public ftp server put up a machine that JUST does the
ftp serving, and nothing else, preferably outside of your internal LAN (see Practical Unix and
Internet Security for discussions of this 'DMZ' concept).
63
Apache
What can I say about securing Apache? Not much actually. By default Apache runs as the
user 'nobody', giving it very little access to the system, and by and large the Apache team has
done an excellent job of avoiding buffer overflows/etc. In general most www servers simply
retrieve data off of the system and send it out, most of the danger come not from Apache but
from sloppy programs that are executed via Apache (CGI's, server side includes, etc).
If going with Apache I would recommend using the 1.3 series unless you have some strange
reason for sticking to 1.2, the active development is now on 1.3, and includes many new
features from security, usability, stability and performance viewpoints. Most servers based
upon Apache (RedHat Secure Server, Stronghold, etc.) are generally just as bug free but there
are occasionally problems.
If you want to be paranoid I would suggest running Apache in a chrooted environment, this
however is sometimes more trouble then it is worth. Doing this will break a great many [ Pobierz całość w formacie PDF ]