Subject: Anonymous FTP Abuses

From: Jean-Michel Augusto <[email-masked]>
Date: Tue, 19 Aug 1997 12:49:55 +0000

Hi,

	Yesterday, after 3 wonderful holiday weeks, I came back to my desk and 
after few minutes I discovered that some bad boys (or girls) have used 
my incoming directory to put some copyrighted software.

	Of course, I have removed them but I want a way to automatically 
detect this kind of anonymous abuses (creation of hidden directories or 
filenames like _ ...) and/or make an operation on them.

	I already check the FAQ Anonymous FTP Abuses and also Anonymous FTP 
Configuration Guidelines. It seems that there is no real solution if I 
want to keep an incoming space and I want such a thing.

	Several times, there are mention of 'Develop in-house tools to...'. 
So, my question is simply: is there somewhere something doing things 
like:
		-parse the log to make the list of today STOR operations
		-check for hidden files/directories
		-check for strange names
		
	If not, I think I will develop something in-house.

	Thanks for your help and attention.

Amicalement,

Jean-Michel AUGUSTO

---

From: "Brad G. Parks" <[email-masked]>
Date: Tue, 19 Aug 97 09:03:09 -0500

Same thing happened to me a few months ago.

> [...] It seems that there is no real solution if I  want to
> keep an incoming space and I want such a thing.

It depends on your definition of "real solution."  The real
solution I use is that anonymous users can place files in the
incoming directory but as the file is transferred, the ownership
of the file changes.  Any subsequent anonymous user will be
unable to retrieve that file until somebody on the staff here
changes the ownership to make it public.  I think this is by
far the best method for preventing abuse of the system.

Yes, this does require the intervention of a staff person on
the rare occaision that somebody wants to put something on our
ftp site.  But any tool that "checks for strange names" will
be easily fooled by somebody renaming their file(s) before they
transfer them.

-brad
(Speaking for myself again)

---

From: Kent Landfield <[email-masked]>
Date: Tue, 19 Aug 1997 09:19:04 -0500 (CDT)

Jean-Michel,

# 	Several times, there are mention of 'Develop in-house tools to...'. 
# So, my question is simply: is there somewhere something doing things 
# like:
# 		-parse the log to make the list of today STOR operations
# 		-check for hidden files/directories
# 		-check for strange names
# 		
# 	If not, I think I will develop something in-house.

I am starting to develop something that I'm planning on publicly releasing 
for possible inclusion in the standard wu-ftpd package (but at a minimum, 
available from the Resource Center).  I could sure use some help. ;)  I have 
written ftpck that checks the wu-ftpd configuration file and that portion of 
the setup.  I am now developing an FTP Directory Audit Checker. I separated 
the two so the latter could be used in non-wu-ftpd ftp sites.  Here is the 
tests that I'm looking to implement.  The tool will not be wu-ftpd specific 
but will have wu-ftpd extensions supported in the checker.

======================================================================== 
FTP Data Directory Auditing
----------------------------

- Check ownership/links/permissions/size/md5 of all ftpd root directory 
  required files and directories (~ftp, ~ftp/bin, ~ftp/etc ...)

- Check ftp directory passwd and group files do not have real info in them.

- Find all files and directories that are world-writable under the ftp 
  data directories

- Classify "error messages" as either Errors or Warnings or Informational

- Home directory for ftp should exist, and not be /

- Find files and directories that are suid.

- If NFS mounted, check and assure nosuid option used.

- check the gnu tar version in the ftp area does not allow arbitrary commands.

- Check to see if site exec disabled.

- Check for PASV problems.

- List binaries in _PATH_EXEC.

- List version of ftpd being run.

- List files in public incoming data directory.

- Assure space used in ftp incoming directory does not exceed 
  some site specified amount

- Need to build permlists for OS-specific files required in the ftp 
  directories, such as :
    the required timezone files/directories are in place (varies by OS)
    ~ftp/dev/tcp set to 666 otherwise passive connections fail (Solaris 2) 
     etc...  

- If user ftp exists in the system password file.
    - Assure a valid password is not specified in the password file for
      the ftp user.
    - Assure a valid shell is not specified in the password file for 
      the ftp user.

- Also if it could recursively check ~ftp for anything which could be 
  written to or altered by an anonymous user (unless it is defined in 
  an uploads directive in ftpaccess). I have found in the past that, 
  although these things are usually set up carefully at the outset, they 
  have a habit of slipping as time goes by. Since checking the whole of 
  ~ftp might be a long job, this would be better made a non-default option.

- Check for .rhosts files.
      owned by root and mode 0000

- Check for .forward files.
      owned by root and mode 0000

- Perhaps check where the logs are (and syslog.conf or what it's name is) ..

- The ~ftp/etc/{passwd|group} should not be the same as the real ones.
   
- For guest groups etc., check that usr/bin, usr/lib etc.  directories are
  visible from each user's chrooted home directory, and that they contain
  the same files as those under the ~ftp equivalents.  (You'd need to make
  this check in case the directories haven't been hard linked.)

- Check for "shells" file and see if the list of shells found in the 
  passwd file are in the shells file.

   * Also want to make sure that certain shells are _not_ listed, i.e.
     /bin/false, /bin/true, /bin/noftp, etc.

   * Make sure the shell the ftp user has in the passwd file is not in
     the shells file.

======================================================================== 

See anything missing here ?  (I'm sure there is lots missing...) I started 
on it but then I stopped when beta 14 was released. I'm in the process of 
gettting beta-14 incorporated into all the virtual-faq support and all its 
docs updated on the Resource Center.  Not sure this will be ready for you 
in your time frame needs, (now ;-)) but it will be there. Like I said, I 
could sure use some help. 

-- 
Kent Landfield                        Phone: 1-817-545-2502             
The Landfield Group                   FAX:   1-817-545-7650             
Email: [email-masked]             http://www.landfield.com/
Please send comp.sources.misc related mail to [email-masked].
Search the Usenet Hypertext FAQ Archive at http://www.faqs.org/faqs/

---

From: Andy Ellsworth <[email-masked]>
Date: Tue, 19 Aug 1997 10:56:53 -0500 (CDT)

> filenames like _ ...) and/or make an operation on them.

We've been battling this for some time at wuarchive, mainly in our
/pub/incoming directory, but elsewhere as well. Our solution has been a
relatively simple one: since we never have a reason for anyone to download
files directly from the incoming directory, we have all uploads be
unreadable (i.e. something like ----rw----, with group 'archive' being the
group with permissions).  This has solved our problems, since most
uploaders quickly realize that they can't download what they've just
uploaded :) 

+----------------------------------------------------------------------------+
| Andy Ellsworth  |  [email-masked] |  Admin/Cyberdiplomat, Wuarchive    |
+----------------------------------------------------------------------------+

---

From: [email-masked] (Albert Lunde)
Date: Tue, 19 Aug 1997 11:22:04 CDT

> filenames like _ ...) and/or make an operation on them.

I wrote a cron job that runs du periodically and mails me whenever there
are changes. But I don't have an incoming directory. (Another thing
the cron job does is reset permissions to make sure uploads are
not possible.)

I've hear that sites with incoming directories use cron jobs to move
the contents to holding directories outside the ftp directory tree.

--
    Albert Lunde                      [email-masked]