FTP "securing"

[Kenneth E. Lussier]

On Thu, 2003-10-09 at 09:27, Larry Cook wrote:
> Hi Kenny,

> 
> It doesn't look like a solution has presented itself yet.  Maybe you could
> take a step back and look at the requirements and possibly come up with a
> non-FTP solution.
> 
> For starters, I present a few (naive) questions, not because I want an answer,
> but to generate some thought on the real requirements:
> 
> * Why are there seven FTP servers?

Location, location, location. We have servers around the world in
different offices so that people can dowload from a closer mirror.

> * Can anonymous FTP be used?

No. (more on this below)

 
> * Is FTP required, or could HTTP be used?

This is a possibility that I hadn't really considered. But, given all of
the responses indicating that it would be a good alternative, I am going
to look into it.
 
> * Are the patches small enough to be emailed?

No. Most patches are between 20 and 50M

> * Could you email the username/password or URL so it's not on the webpage?
> 
> * Why is this even an issue?  You don't want them to see the 
> username/password, but you give them the convenience to just click a link to 
> get the file.  So securing the file doesn't seem to be the issue, so why not 
> just mirror the patches on the website for HTTP download?

There is more to this problem then I stated originally, but I will come
clean now. The patches are only available to customers who are on
support contracts. The problem that we ran into was that using anonymous
FTP allowed some of the smarter users to bookmark the location, then
download patches after they went off maintenence. This remains somewhat
of a problem, because some of the smarter users have copied down the
username and password as well. I have no problem changing the passwords
weekly, but there is signifigant push-back from the other offices
because it is "too inconvenient". So, I would like a way to lock it down
so that people don't know the username and password for when they go off
maintenence. I have suggested putting the patches on the web server, but
then we get into authentication issues (users are authenticated against
a database that is located in England), as well as other company issues.

Thanks,
Kenny
-- 
----------------------------------------------------------------------------
"Tact is just *not* saying true stuff" -- Cordelia Chase

Kenneth E. Lussier
Sr. Systems Administrator
Zuken, USA
PGP KeyID CB254DD0 
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xCB254DD0