[olug] vsftpd - only allow anonymous upload

[Jeff Hinrichs]

Carl Lundstedt wrote:
>>It appears that I've met my goal.
>>
>>Follow Up: Now that I've got it working, does anyone
>>A) see a flaw in my set up?
>>B) know of a better/easier way to accomplish the same?
>>
>>Thanks,
>>Jeff
>>
> 
> Do you care about overwrites?  
Yes, they should fail
> Does this prevent overwrites?  
Yes.
> Can anonymous download a "known" filename?  Can I delete a "known" file
> (i.e. one that was just uploaded)?
No and No
> If you prevent overwrites, then someone who REALLY wanted to could
> compile a list of "failures" and download/delete them (or just have a
> list of what's there, which is what you said you didn't want).
Yes, someone could compile a list of failures.  But they are unable to 
get/rm them.
> Can Anonymous mkdir?  Would that directory be readable?
No, mkdir is not allowed by anonymous
> I'm curious as to why you want to do this, but I understand if you don't
> feel like saying...
I can give a general reply.  Say that you were setting up a cataloging 
system for electronic documents for a number of geographically diverse 
offices. These documents are uploaded by dumb devices that only speak ftp.

Now I know that ftp is not a secure channel but the value of the data is 
as a collection and not the individual pieces that create it.  So a man 
in the middle, or sniffer attack would require the hacker to need the 
space and bandwidth to collect these pieces over time.  The real 
interest would be getting access to the collection or a portion of the 
collection.  By not allowing anonymous to list/get/rm/mkdir I can cut 
off an avenue of data collection.  Also, the ftp service doesn't allow 
users to logon to it, only anonymous connections are allowed.  This way 
I don't send even a smattering of info to an attacker.

I also use hosts.allow to limit access to known IPs.

The final obvious vector is a DOS by trying to swamp the machine with 
bogus data.  I have a cron job that inspects the upload directory and 
does away with files that are not of the correct type, or are the right 
type but above the predefined maxsize, or too many uploads from a given 
IP and finally monitors free space and takes drastic measures. i.e. 
shuts down the ftp service.

I hate being forced in to using ftp but most device manufacturers think 
ftp is the be all end all of open communications.  What I'd give to find 
  something that uses scp or such but they don't exist in the market 
segment I work with.  So I was trying to create the most secure, given 
the available resources, method of uploading files to a central area.

FYI, the ftp directory is not the final destination of the files but 
more of a rest stop.

-Jeff
p.s. If anyone sees something I've overlooked, I'd be greatful if you 
point it out.  I know there are a lot of smart people on the list and 
I'm always willing to learn a new trick :)