mairving — Fri, 27 Jul 2001 14:32:41 +0000

The Linksys router uses NAT, which is good. Are you allowing anon FTP or requiring a login? I assume that you have only port 21 open for ftp.

Here are some good ways to secure FTP;

/etc/ftpusers - this is a restricted access file. Any user whose name appears here will be denied access. You should add an entry for all of your system login services, root, bin, daemon, mail, nobody, etc to prevent someone logging on with that account.
/etc/ftphosts - this file can be used to prevent access via a specified host.
Example:
allow mhensler mhensler.com
deny mairving *mairving.com
Look at man ftphosts for more info.
/etc/ftpaccess - use this file to control how ftpd works.
Example:
class all real,guest,anonymous *
email root@localhost
loginfails 3
readme README* login
readme README* cwd=*
message /welcome.msg login
message .message cwd=*
compress yes all
tar yes all
chmod no guest, anonymous
delete no guest, anonymous
overwrite no guest, anonymous
rename no guest, anonymous
log transfers anonymous,real inbound,outbound
shutdown /etc/shutmsg
passwd-check rfc822 warn
Here is some info on the various directives.
class - Used to define special classes of users.
loginfails - Number of bad login attempts before a message is sent to logs.
Other directives like compress, tar, chmod, delete, overwrite, rename - in the above example, anyone can upload or download a tar file. Any user besides guest & anonymous can chmod a file.
Additional user security - Set the users home directory to 555 with root ownership.
Additional security issues - ftp is insecure in itself for a couple of reasons. One is that passwords are sent in plain text. So you have to look at security as preventin those users from doing any damage to your system.

Here is a draft focusing on ftp security that may help:

----------draft-allman-ftp-sec-consider-01.txt--------------

Internet Engineering Task Force Mark Allman
INTERNET DRAFT Shawn Ostermann
File: draft-allman-ftp-sec-consider-01.txt Ohio University
January 21, 1997
Expires: June 21, 1997

FTP Security Considerations

Status of this Memo

This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as ``work in
progress.´'

To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt´' listing contained in the Internet- Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).

Abstract

The specification for the File Transfer Protocol contains a number
of mechanisms that can be used to compromise network security. The
FTP specification allows a client to instruct a server to transfer
files to a third machine. This third-party mechanism, known as
proxy FTP, causes a well known security problem. The FTP
specification also allows an unlimited number of attempts at
entering a user´s password. This allows brute force "password
guessing" attacks. This document provides suggestions for system
administrators and those implementing FTP servers that will decrease
the security problems associated with FTP.

1 Introduction

The File Transfer Protocol specification [PR85] provides a mechanism
that allows a client to establish a data connection and transfer a
file between two FTP servers. This "proxy FTP" mechanism can be
used to decrease the amount of traffic on the network; the client
instructs one server to transfer a file to another server, rather
than transfering the file from the first server to the client and
then from the client to the second server. This is particularly
useful when the client connects to the network using a slow link
(e.g., a modem). While useful, proxy FTP also provides a security
problem, known as a "bounce attack". In addition to the bounce

Expires: June 21, 1997 [Page 1]
--------------------------------------------------------------------------------
draft-allman-ftp-sec-consider-01.txt January 21, 1997

attack, FTP servers can be used by attackers to guess passwords
using brute force.

This paper provides information for FTP server implementers and
system administrators, as follows. Section 2 describes the FTP
"bounce attack". Section 3 provides suggestions for minimizing the
bounce attack. Section 4 provides suggestions for servers which
limit access based on network address. Finally, section 5 provides
recommendations for limiting brute force "password guessing" by
clients.

2 The Bounce Attack

The version of FTP specified in the standard [PR85] provides a
method for attacking well known network servers, while making the
perpetrators difficult to track down. The attack involves sending
an FTP "PORT" command to an FTP server containing the network
address and the port number of the machine and service being
attacked. At this point, the original client can instruct the FTP
server to send a file to the service being attacked. Such a file
would contain commands relevant to the service being attacked (SMTP,
NNTP, etc.). Instructing a third party to connect to the service,
rather than connecting directly, makes tracking down the perpetrator
difficult and can circumvent network address based access
restrictions.

As an example, a client uploads a file containing SMTP commands to
an FTP server. Then, using an appropriate PORT command, the client
instructs the server to open a connection to a third machine´s SMTP
port. Finally, the client instructs the server to transfer the
uploaded file containing SMTP commands to the third machine. This
allows the client to forge mail on the third machine without making
a direct connection. This makes it difficult to track attackers.

3 Protecting Against the Bounce Attack

The original FTP specification [PR85] assumes that data connections
will be made using the Transmission Control Protocol (TCP) [Pos81].
TCP port numbers in the range 0 - 1023 are reserved for well known
services such as mail, network news and FTP control connections
[RP94]. The FTP specification makes no restrictions on the TCP port
number used for the data connection. Therefore, using proxy FTP,
clients have the ability to tell the server to attack a well known
service on any machine.

To avoid such bounce attacks, it is SUGGESTED that servers not open
data connections to TCP ports less than 1024. If a server receives
a PORT command containing a TCP port number less than 1024, the
SUGGESTED response is 504 (defined as "Command not implemented for
that parameter" by [PR85]). Note this leaves non-well known servers
(those running on ports greater than 1023) vulnerable to bounce
attacks.

Expires: June 21, 1997 [Page 2]
--------------------------------------------------------------------------------
draft-allman-ftp-sec-consider-01.txt January 21, 1997

Several proposals (e.g., [AO96] and [Pis94]) provide a mechanism
that would allow data connections to be made using a transport
protocol other than TCP. Similar precautions should be taken to
protect well known services when using these protocols.

4 Restricted Access

For some FTP servers, it is desirable to restrict access based on
network address. For example, a server might want to restrict
access to certain files from certain places (e.g., a certain file
should not be transferred out of an organization). In such a
situation, the server SHOULD confirm that the network address of the
remote hosts on both the control connection and the data connection
are within the organization before sending a restricted file. By
checking both connections, a server is protected against the case
when the control connection is established with a trusted host and
the data connection is not. Note that restricting access based on
network address leaves the FTP server vulernable to "spoof" attacks.
In a spoof attack, for example, an attacking machine could assume
the host address of another machine inside an organization and
download files that are not accessible from outside the
organization.

5 Protecting Passwords

To minimize the risk of brute force password guessing through the
FTP server, it is SUGGESTED that servers limit the number of
attempts which can be made at sending a correct password. After a
small number of attempts (3-5), the server SHOULD close the control
connection with the client. In addition, it is SUGGESTED that the
server impose a 5 second delay before replying to an invalid "PASS"
command. If available, mechanisms already provided by the target
operating system should be used to implement the above suggestions.

Standard FTP [PR85] sends passwords in clear text using the "PASS"
command. It is SUGGESTED that FTP clients and servers use alternate
authentication mechanisms that are not subject to eavesdropping
(such as the mechanisms being developed by the IETF Common
Authentication Technology Working Group [HL96]).

6 Conclusion

Using the above suggestions can decrease the security problems
associated with FTP servers without eliminating functionality.

Acknowledgments

We would like to thank Alex Belits, Jim Bound, William Curtin,
Robert Elz, Paul Hethmon, Alun Jones and Stephen Tihor for their
helpful comments on this paper.

Expires: June 21, 1997 [Page 3]
--------------------------------------------------------------------------------
draft-allman-ftp-sec-consider-01.txt January 21, 1997

References

[AO96] Mark Allman and Shawn Ostermann. FTP Extensions for Variable
Protocol Specification, November 1996. I-D
draft-allman-ftp-variable-03.txt (work in progress).

[HL96] M. Horowitz and S. J. Lunt. FTP Security Extensions,
November 1996. I-D draft-ietf-cat-ftpsec-09.txt (work in
progress).

[Pis94] D. Piscitello. FTP Operation Over Big Address Records
(FOOBAR), June 1994. RFC 1639.

[Pos81] J. Postel. Transmission Control Protocol, September 1981.
RFC 793.

[PR85] J. Postel and J. Reynolds. File Transfer Protocol (FTP),
October 1985. RFC 959.

[RP94] J. Reynolds and J. Postel. Assigned Numbers, October 1994.
RFC 1700.

Author´s Addresses:

Mark Allman and Shawn Ostermann
School of Electrical Engineering and Computer Science
Ohio University
416 Morton Hall
Athens, OH 45701
mallman@cs.ohiou.edu
ostermann@cs.ohiou.edu
------------------------------------------------------------

Mark Hensler — Fri, 27 Jul 2001 04:41:34 +0000

The FTP was slow connecting, and browsing folders. I don't remember how it was downloading/uploading files.

I think I'm using a 'medium' security. I am behind a Linksys router, with a build in firewall. Is that sufficient?

Would you recommend using inetd over the standalone?

mairving — Fri, 27 Jul 2001 02:45:07 +0000

I am not sure what is causing your slowdown. What kind of connection are you on? Is it slow on connecting or slow to upload/download. The ftp daemon doesn't degrade over time either. I really can't tell that much difference between the two.

The inetd daemon is a so called super daemon. So rather than loading ftp, telnet, tcp, udp separately, it would load them as one super daemon. The only real advantage to having a separate ftp daemon would be that you could start and stop it without having to kill all of the other processes. As far as providing you with some examples, I not running a ftp server. I will check around and see what I can come up with.

What kind of security will you be setting up on it? If you need a nice firewall, try Bastille Linux. I believe that it comes on the Mandrake 8.0 CD. It will do a lot towards securing your box.

Mark Hensler — Fri, 27 Jul 2001 00:06:34 +0000

Also, I've been reading lots of docs on configuring both proftpd an wu-ftpd, and it seems that there are two ways to configure FTP servers. Some show configs for a server using Inetd and other using Standalone.

I'll be hosting about 5 low traffic personal sites. Which would be better for me?

PS: Working personal config examples would be much appreciated.