From owner-freebsd-net@FreeBSD.ORG Mon Jul 17 18:07:19 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6EED016A4DA; Mon, 17 Jul 2006 18:07:19 +0000 (UTC) (envelope-from ormandj@corenode.com) Received: from zone2.corenode.com (zone2.corenode.com [66.91.129.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id E6B9443D46; Mon, 17 Jul 2006 18:07:18 +0000 (GMT) (envelope-from ormandj@corenode.com) Received: from corenode.com ([127.0.0.1]) by zone2.corenode.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J2K00F3Z7RDAL10@zone2.corenode.com>; Mon, 17 Jul 2006 08:09:13 -1000 (HST) Received: from [132.160.192.10] by zone2.corenode.com (mshttpd); Mon, 17 Jul 2006 08:09:13 -1000 Date: Mon, 17 Jul 2006 08:09:13 -1000 From: "David J. Orman" In-reply-to: <200607171358.09943.mi+mx@aldan.algebra.com> To: Mikhail Teterin Message-id: MIME-version: 1.0 X-Mailer: Sun Java(tm) System Messenger Express 6.2-3.04 (built Jul 15 2005) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal References: <200607171306.01882.mi+mx@aldan.algebra.com> <200607171358.09943.mi+mx@aldan.algebra.com> Cc: isp@freebsd.org, net@freebsd.org Subject: Re: forcing FTP-uploaded files to be of certain types only X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2006 18:07:19 -0000 ----- Original Message ----- From: Mikhail Teterin Date: Monday, July 17, 2006 7:58 am Subject: Re: forcing FTP-uploaded files to be of certain types only > I was hoping for some sort of plugin-API for the server... > Determining the > file's type is not really hard -- file(1) does just that. I'm not > looking to > prevent _malicious_ users -- just the ignorant ones. Ok, I see what you're interested in. I don't believe the stock FBSD server has a plugin API. Try something like ProFTPD, if you are comfortable writing a module that accesses external programs. I wouldn't do that myself, too much room for exploits, but you could always use the algorithm from file(1) in your module, as it is BSD licensed. > We don't mind LARGE files -- some of those are legitimate. We just > want them > to be compressed before being uploaded. In fact, checking for this > is even > easier, than the usual byte-sniffing done by file(1) -- just try to > compress > those first 100K. If the result is smaller than 50K, the whole gets > rejected :-) That could lead to many DoS attacks, high load, etc - but as you said you trust the users, I suspect this is not an issue to you. I personally code with security in mind no matter the situation, but you decide what is best for you. :) > No, destruction is not an option :-) Awww, that's my favorite part! ;) > Yeah, and we are doing that now -- kind of. But I would like an > educational > message sent to the uploader instead: "Transfer aborted: please > compress > large files before uploading"... Now that I understand your situation better, I see what you are attempting to do. You'll likely need something like ProFTPD to accomplish what you're asking, I don't believe the stock FTP server has the functionality/modular design necessary. Something you might want to consider - simply compressing all files recieved on the ftp server, regardless of type/previous compression. Since it sounds like you wan't worry about DoSing, malicious users, etc - and I am assuming this is on the internal network only - and also security is not your concern - simply compressing all files wouldn't hurt anything. It'll only gain you a few % on the previously compressed files, but it will take care of the uncompressed files in the process. Re-training users can be quite dificult, CPU hours costs much less than human hours. :) Either way, it sounds like you can accomplish your task. I'd personally write a module with built in file(1) type functionality myself, and not access file(1) as an external program. All of the options above, should work - however. You'll need a different FTP daemon though if you want to write a module. :) Best wishes, David