Re: [SAGE] incoming file transfers, and collaborative environmentsin general

[Ruth Milner <rmilner@nmt.edu>]

Doug Hughes wrote:

> I've used a twist on this where you set the ftp server (usually wietse's,
> and usually with the -u flag) to set it so that the owner (ftp) could
> not read the file once it was put.
> 
> Thus, external people could drop of files to internal people, but
> no other external people could then subsequently fetch the files.
> This avoids the 'warez' problem because they quickly realize that
> while they can store stuff there, it doesn't do them any good
> because they can't fetch it afterwards.

If the original poster is looking for a simple solution to allow
file drops from external people, this arrangement works very well.
They just use anonymous ftp. A common setup is to have an "incoming"
subdirectory, which the ftpd config file specifies as the only place
where anonymous writes are allowed. As Doug says, it is critical to
make sure that files cannot subsequently be retrieved via anonymous
ftp. Warez adherents are well aware of this technique, and in my
experience generally put a test file there when they find the site;
if retrieval fails, they move on.[1]

A variation on this is to have individual subdirectories for staff
members beneath the incoming area, where the files intended for
them are deposited. If they own the subdirectory (group ftp needs
write privileges), then they can retrieve the files directly via
cp from an NFS- or samba-mounted path (e.g. /home/ftp/incoming/<user>
or \\<server>\ftp\incoming\<user>). It is trivial then to have
standardized, simple instructions for both parties to the file
exchange. Your staff can also - but won't always :-) - delete the
files after they've copied them.

Be sure to warn everyone about the possibility of malware showing
up there, and check the area for viruses regularly: distribution
of pirated software is not the only malicious use of writeable
anonymous ftp areas.

Any time you have an open service, you need to be vigilant about
monitoring it. Make sure you get a regular report of incoming (and
preferably also outgoing) ftp traffic. This makes it easier to spot
anomalous activity that might result from, say, ftpd misconfiguration.

Ruth Milner
[1] Be aware that occasionally they may get pissed off about it. One
of my former employer's ftp servers was the target of a DDoS which
began shortly after someone tried a put/get of an obviously pirated
program and was unable to retrieve the file. Of course, it may have
been a coincidence, though we couldn't think of any other motivation
besides random malice; a typo is unlikely since the attack followed
the name rather than the IP. The server was totally unavailable for
over a week while we tried to stem the flood. We were able to get a
response from a few of the larger organizations whose systems were
being used in the usual sort of hacked-drone DDoS network, and
ultimately one of the sysadmins was able to restore general access
by denying connections to large IP ranges covering most of the
hundreds of offending systems (the ranges later had to be tweaked
to allow a grand total of three legitimate users to retrieve files).
But it's worth noting that while the bombardment declined over time,
three years later there were still some systems attempting to flood
the server; so sometimes these drone networks are activated and
then forgotten. It's another demonstration that running any service
entails risk, although I don't think this was a typical Warez case:
many, many ftp servers are configured the same way without being
targeted in this manner.