Subject: Re: your mail

From: Daniel Nowak <[email-masked]>
Date: Sun, 7 Feb 1999 22:37:27 -0800 (PST)

I have two questions first i would like to limit users to only one
connection per ip address at a time. is this possable? 

second I would like to have two guest groups 
Co-workers and clients
and I would like to limit clients to 5 connections and coworkers to 10
connections can I limit user conections buy the group name? 

Thank you for you time

Daniel Nowak

_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com

---

From: Gregory A Lundberg <[email-masked]>
Date: Mon, 8 Feb 1999 02:09:56 -0500 (EST)

> connection per ip address at a time. is this possable?

Not yet.  It's been a feature request for some time.  I've not heard of
anyone offering a patch for this.

> second I would like to have two guest groups Co-workers and clients

Unix group?  No.

> DO YOU YAHOO!?

No.

-- 

Gregory A Lundberg		Senior Partner, VRnet Company
1441 Elmdale Drive              [email-masked]
Kettering, OH 45409-1615 USA    1-800-809-2195

---

From: Bret McDanel <[email-masked]>
Date: Mon, 8 Feb 1999 11:02:24 -0500

Welp, again this reared its head, and so with it came an exploit for
this..  Someone released a paper detailing how ftpd doesnt check to see if
the person connecting via PASV is from the same IP as the person actually
connecting..  Since there is now a program floating around to let people
do this, and a new paper that was released so that people can learn about
it, it may be time to address this..

Basically here is the problem:
When a client issues a PASV request, the server replies with the port to
connect to.  Using guessing techniques an attacker could connect to the
server, and if they get there before the client, they could get the data
(RETR,LIST,NLST ...) that the server was sending to the client.  Becuase
more and more people are using web browsers to download, which only use
PASV mode transfers, and some are forced to transfer PASV because of
firewalls, etc, this is a growing concern..  

Some more information can be obtained from:
http://www.nai.com/products/security/ballista/interface/modules/module2003.html
http://www.infowar.com/iwftp/iw_sec/iw_sec_01.txt

There are some suggestions on how to make this problem more minimal on
those sites as well..

-- 
Bret McDanel                                    http://www.rehost.com
Realistic Technologies, Inc.                             973-514-1144

     These opinions are mine, and may not be the same as my employer

---

From: Gregory A Lundberg <[email-masked]>
Date: Mon, 8 Feb 1999 11:24:49 -0500 (EST)

On Mon, 8 Feb 1999, Bret McDanel wrote:

> this..  Someone released a paper detailing how ftpd doesnt check to
> see if the person connecting via PASV is from the same IP as the
> person actually connecting..  Since there is now a program floating
> around to let people do this, and a new paper that was released so
> that people can learn about it, it may be time to address this..
> 
> Basically here is the problem: When a client issues a PASV request,
> the server replies with the port to connect to.  Using guessing
> techniques an attacker could connect to the server, and if they get
> there before the client, they could get the data (RETR,LIST,NLST ...)
> that the server was sending to the client.  Becuase more and more
> people are using web browsers to download, which only use PASV mode
> transfers, and some are forced to transfer PASV because of firewalls,
> etc, this is a growing concern..
> 

The only thing close to a workable solution I see on the nai.com site is
the following quote:

	The problem with these auxiliary connections is that the existing
	FTP protocol lacks any method of assuring that the client or
	server which initiates the connection is really the one attached
	to the associated control connection.

In other words, they don't have one which will work.  Their only proposal
would require a change to existing clients and servers which is unlikely
to be widely deployed anytime soon.

It is important to realize what is said at inforwar.com:

	The ability for this attack to be performed is not 100%
	guaranteed. The higher the volume of traffic an FTP server sees,
	the higher the potential for a successful attack. This attack has
	not yet been observed in the wild.

They point out:

	Solving the problem requires careful thought. Server programmers
	can program a server to identify the client address associated
	with the control port and only allow data port connections from
	the client address, however this server would not be RFC compliant.

The only currently viable solution is RFC2228 to which infowar.com rightly
points out:

	Through the use of a secured data channel, the Pizza Thief threat
	is reduced to a simple denial of service attack.

--