Subject: WU-FTP Hooks and file uploads

From: "Perry Edward (tsp2emp)" <[email-masked]>
Date: Thu, 8 Apr 1999 16:33:38 -0400

If someone could tell me if this is a good idea or bad idea. It would
also be helpful if you would me some of the functions that would help
me to implement this.

I am looking to add the ability to upload a file from one FTP server
to another FTP server (I guess build a basic FTP client in the
server). The idea is that a customer would FTP to ftp server A. and
upload a file. Then ftp server  A. would open an intranet connection
to ftp server B and login is using the user id and password that was
used by the user to login on to system A. At this point Server A would
transfer the file to ftp system B. When the transfer from A to B was
finished it would then return control to the customer terminal or it
could release the terminal and do the transfer in the background. Then
files would exist on both system right away. I know something like
this could be done by a script (like Mirror) but then  passwords would
be listed in an unencrypted state  or I would have to make the script
to run as setuid on the target system.

---

From: Gregory A Lundberg <[email-masked]>
Date: Thu, 8 Apr 1999 16:54:23 -0400 (EDT)

On Thu, 8 Apr 1999, Perry Edward  (tsp2emp) wrote:

> upload a file. Then ftp server A. would open an intranet connection to
> ftp server B and login is using the user id and password that was used
> by the user to login on to system A. At this point Server A would

Sounds like you need to look at 'mirror' or an FTP proxy.

Don't know what you're trying to do but the way I read it, it looks
perillous.  If you're trying to allow outside customers to drop off files
for inside users, leave them on the outsode server and have the insiders
come get them.  I would NEVER allow ANYTHING from the outside world past a
firewall/proxy without someone on the inside coming to pick it up.

Think of it like a letter-bomb .. should the mail room deliver it to the
board room, or make the CFO come pick it up?  Damage will be bad either
way.  It may mean the CFO has to walk a bit, and he may make life hard on
your for making him do it, but at least there's _something_ left of the
executive board after the smoke clears.  You question, though, sounds even
worse .. you want to let the bomber have the keys to the board room so
it's easier for him to drop off the letter where it will do the most
damage.  What you should be doing is bomb-proofing the mail room.

-- 

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

---

From: "Alex Yu" <[email-masked]>
Date: Thu, 8 Apr 1999 17:20:20 -0400

> to another FTP server (I guess build a basic FTP client in the

Why don't you use NFS?

Alex

---

From: Gregory A Lundberg <[email-masked]>
Date: Thu, 8 Apr 1999 17:30:21 -0400 (EDT)

> Why don't you use NFS?

Up-side: solves the problem quickly, if your systems support it.

Down-side: yet another security risk on the bastion host, and one which
has special privilege allowing it to cross from the DMZ to the secured
area at the bidding of an outsider.

--

---

From: Ted Keller <[email-masked]>
Date: Thu, 8 Apr 1999 17:41:04 -0400 (EDT)

If you are going between an external network and an internal network, nfs
raises several severe security issues.  It would require your firewall
administrator to open several rpc ports - many of which have known
vulnerabilities.  The risk to your internal network makes this not
desirable.

One of my folks "found" a perl ftp script somewhere which would allow a
scripted login and transfer of data bewteen two servers using ftp (I can
supply the source if desired).  One potential idea would be to have the
internal machine "ftp" the files from the external machine (a data pull -
not a push) based on sometype of cron schedule.   Just some thoughts.

ted keller - bfg.com

---

From: "Auteria Wally Winzer Jr." <[email-masked]>
Date: Thu, 08 Apr 1999 19:05:53 -0700

I know this is not part of the wu-ftpd list, but here's something
to think about:

Instead of using wu-ftpd, setup the 2 servers for strict ssh authentication,
then use rsync with the -e ssh option.  This will accomplish 2 things:
1. The 2 hosts involved will ONLY have authentication between themselves
    (ONLY if the hosts you set up are TRUSTED)
2. The data between the 2 hosts will be encrypted, therefore the pipe is
    secured and the data cannot be decrypted.

Just a thought, even though this doesn't pertain to wu-ftpd.

Greg, have you ever though of adding ssh with wu-ftpd?  That would be
way cool. The tunnel/pipeline is secure and the data...  well, you know the
rest.

- Wally Winzer Jr.

---

From: Gregory A Lundberg <[email-masked]>
Date: Thu, 8 Apr 1999 23:27:09 -0400 (EDT)

On Thu, 8 Apr 1999, Auteria Wally Winzer Jr. wrote:

> way cool. The tunnel/pipeline is secure and the data...  well, you
> know the rest.

tunnelling FTP without a smart proxy or custom client/server is
problematic.

I'd love to add SSL to wu-ftpd, but that will have to be done outside the
US/Canada since it seems our silly governments consider the protocols to
be nuclear weaponry.

--

---

From: "Alex Yu" <[email-masked]>
Date: Fri, 9 Apr 1999 00:14:35 -0400

> I'd love to add SSL to wu-ftpd, but that will have to be done
   > US/Canada since it seems our silly governments consider the

To have SSL is good, but there is no such client for both Mac and PC.  I
would rather see SFTP for Mac and PC, not command prompt, but GUI interface!

But anyway, there is another a ssl-ftpd, which can be downloaded from
ftp.replay.com, includes RPM and SRPM packages.  Anyone wanna hack it?

Alex