🚀 go-pugleaf

In article <francis.722155745@monod> francis@monod.Biol.McGill.CA (Francis Ouellette) writes:
>   I have just installed anon ftp on my machine, and I was wonderring if
>   there is a checklist somewhere of things that have to be checked for
>   me to assure myself that everything is OK from a security point of
>   view.

  You can try running ftp.chk with the -a flag, which comes with cops
(available via anon-ftp, archive.cis.ohio-state.edu, ~pub/cops.)  The
comment header has some tips on how to set up anon-ftp securely; if
nothing else, you should look at that (I've enclosed it below.)

 -- d


#  Usage: ftp.chk [-a]
#
#   This shell script checks to see if you've set up (mainly anonymous)
# ftp correctly.  The "-a" option forces a check on your anon-ftp setup
# (without the flag, this will look in your /etc/passwd, to see if user
# ftp exists, and proceed onwards anyway) without that, this script 
# doesn't do a whole lot -- just check to see if your ftpusers file 
# doesn't have any root accounts in it.  There seems to be some different
# types of ftp's around; for instance, some allow "chmod" -- and if the home
# dir is owned by "ftp", you're toast.  So I've tried to err on the side of
# safety...
#
#   See the man page for a more detailed description, here's what this
# checks for:
#
# - User ftp exists in the password file.
# - root (or all root equivalents) are in ftpusers file.
# - Home directory for ftp should exist, and not be /
# - The ~ftp/etc/{passwd|group} should not be the same as the real ones.
# - Various critical files/directories should exist, and have correct
#   permissions and owners; variables "$primary" and "$secondary" can be set
# to whomever you want owning the files:
#
#  File/Dir          Perms           Owner      Other
#  =========         ======          ======     ======
#  ~ftp              non-w.w.        root
#           or
#  ~ftp              555             ftp	if no chmod command exists
#
#     All of these are ftp owned iff no chmod exists...
#
#  ~ftp/bin          non-w.w.        root/ftp
#           or
#  ~ftp/bin          non-w. and ftp w. ftp
#  ~ftp/bin/ls       111             root/ftp
#  ~ftp/etc          non-w.w.        root
#           or
#  ~ftp/etc          non-w. & ftp w. ftp
#  ~ftp/etc/passwd   non-w.w.        root/ftp   0 size or nonexistant
#  ~ftp/etc/group    non-w.w.        root/ftp   0 size or nonexistant
#  ~ftp/pub          non-w.w.        root/ftp
#  ~ftp/incoming     world-writable  root/ftp   This can be set to "pub"
#  ~ftp/.rhosts      non-w.w.        root       0 size, is optional
#  ~ftp/*            non-w.w.                   other dirs/files in ~ftp
#

francis@monod.Biol.McGill.CA (Francis Ouellette) writes:

>Dear csm readers,

>I have just installed anon ftp on my machine, and I was wonderring if
>there is a checklist somewhere of things that have to be checked for
>me to assure myself that everything is OK from a security point of
>view.

>Any pointers would be most appreciated,

>regards to all,

>francis


>--
>| B.F. Francis Ouellette  
>| manager, yeast chromosome I project
>| dept of biology, McGill university, Montreal, Qc, Canada
>| francis@monod.biol.mcgill.ca

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.


--
David L. Rector				drector@math.uci.edu
Dept. of Math.				U. C. Irvine, Irvine CA 92717

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.

If you only need an "incoming" directory for outside users to drop files
off for users of the machine, try this trick:

d-wxr-xr-x  2 ftp      nobody        512 Oct 11 12:08 incoming/

Anonymous users can write files, but can't list or read them, while users
on the machine can do directory listings and read the files.  You still
need to clean out junk, but no "bulletin board" problems.  Note that
this doesn't work if you have some brain-dead "ftpd" that doesn't make
anonymous ftp files world readable (Convex).

Heck, might as well mention everything as long as I'm here.  On the flip side
of "incoming" would be "pub":

dr-xrwxrwt  2 ftp      nobody        512 Nov 10 17:23 pub/

Where anonymous users can list and read but not write, while local users
can do anything (except delete each others' files).

As for the rest, most should be mode 555:  the parent directory, as well as
bin, and any other needed stuff (etc, dev, ...), owned by root.  Depending
on how much info you want to give out, you can either omit etc/passwd and
etc/group altogether, or include modified versions (passwd: no passwords,
groups, home directories, shell of /bin/false just in case;  group: no
passwords or user lists).  The "ftpd" man page usually gives some info about
which other files are needed, for shared libraries, etc.

Anybody else have any helpful hints?

--
Bill Stapleton
     wls@csd4.csd.uwm.edu
     uwmcsd4!wls

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.

The change is easy enough, you insert something like this immediately
after the check for special files (search for 'plain file' in ftpd.c):
    if ((guest)&&(st.st_uid==(getpwnam("ftp")->pw_uid))) {
        reply(550, "%s: not retrievable by guests.", name);
        goto done;
    }
This may not be perfect C, I typed it from memory, but you get the
drift.

--Arnt

   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