From owner-freebsd-security Fri Aug 4 07:34:45 1995 Return-Path: security-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id HAA14037 for security-outgoing; Fri, 4 Aug 1995 07:34:45 -0700 Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id HAA14031 for ; Fri, 4 Aug 1995 07:34:39 -0700 Received: from localhost (localhost [127.0.0.1]) by precipice.shockwave.com (8.6.11/8.6.9) with SMTP id HAA02273; Fri, 4 Aug 1995 07:33:31 -0700 Message-Id: <199508041433.HAA02273@precipice.shockwave.com> To: William McVey - wam cc: security@freefall.cdrom.com Subject: Re: FTP data port restrictions In-reply-to: Your message of "Fri, 04 Aug 1995 09:19:37 CDT." <199508041418.AA05932@gateway.fedex.com> Date: Fri, 04 Aug 1995 07:33:31 -0700 From: Paul Traina Sender: security-owner@FreeBSD.org Precedence: bulk From: William McVey - wam Subject: Re: FTP data port restrictions Paul Traina wrote: >The basic idea here is that we leave 40000-44999 open, since no known >sane services reside there (yeah, sure...) at the firewalls, and can >therefore button down everything else. It's important for people to realize that allowing arbitrary connections into your inside network even if they are destined for these ranges is still not a safe thing to do. The problem is that although no *sane* services are running in this block of ports, we still have the problem of RPC dynamic port allocation, so for as far as we know nfsd or mountd could be running in this range. We can only go so far as to fix our own software. Services that don't -specificly- bind themselves to a port (i.e. anyone who calls bind with a 0 port, get assigned a range from 1024 to 5000), which is why you will never see floating RPC daemons in ports greater than 5000. Other RPC daemons, such as NFS, which do lock themselves down to a particular port can fall outside that range, but if they're locked down, you can block them. The feature of resticting port ranges may still be usefull for proxy services (since you know you aren't running any rpc services on your proxy host), but if a site's security depends on a screening router, I'd hate for people to get the idea that these ports are deemed "safe". I agree, and the documentation will say something to that effect, but given the unfortunate situation we currently have, where bloody daemons and user stuff share the same range of ports, we're seriously SOL. If we had it to do over again, we should have reserved the bottom 8k for privileged daemons, then next 8k for unprivileged services, then next 16k for floating services, and the top 32k for client sourced ports. Oh well..