🚀 go-pugleaf

   In article <drector.722195714@math.uci.edu> drector@math.uci.edu (David Rector) writes:
   ...
   >If you find it necessary to have an "incoming" directory, that is a
   >directory with write privileges, be sure to check it regularly for
   >unwanted material, or you might find yourself playing host to an
   >unwanted---or even illegal---bulletin board.  A favorite trick of
   >bb creators is to hide their files from the ls command by prefixing the
   >file names with periods or other unprintable characters.  Use the
   >-a option to ls, or use du, to search for unwanted files.
   >
   >I need hardly add that I am a recent victim of this scam.  I forgot
   >about the -a option.

   I, too, once had 100 FTP logins in 24 hours... my advice is to patch
   the ftp daemon so files uploaded by guests have to be chown'd or cp'd
   before they can be downloaded by guests.

We've installed a patch like this on an ftp server here, and it has
worked really well in stopping 3rd party transfers.

Basically, we brought up a ftp server which had writable directories,
no logging of transfers, and took a very casual approach to running the
machine (i.e. check it was still up every couple of days).  During
that period, we unwittingly hosted *lots* of transfers of files.  Once
it was discovered what was happening, the first option was to kill the
writable subdirectories, but that got overruled, since alot of valid
stuff gets put on the machine by external scientists wanting to
transfer files to some user here.  So, we basically tag each file as
"remotely uploaded" or "locally uploaded", and disallow "remotely
uploaded" files from being downloaded from a remote site.  We run the
logging, too, and basically, all problems have ceased for at least the
last year or so.  So we started with the basic berkeley ftpd, with
some logging patches applied (don't know who did these patches,
either), and about 100 or so lines of locally applied patches.

I'd  suggest that anyone starting up an anon-ftp server, should 
enable logging at the very least.

JHH



--
Jim Hudgens 			Supercomputer Computations Research Institute
hudgens@sun13.scri.fsu.edu