From owner-freebsd-security Tue Aug 17 10:21:15 1999 Delivered-To: freebsd-security@freebsd.org Received: from granite.sentex.net (granite.sentex.ca [199.212.134.1]) by hub.freebsd.org (Postfix) with ESMTP id 2C98214F32 for ; Tue, 17 Aug 1999 10:21:10 -0700 (PDT) (envelope-from mike@sentex.net) Received: from simoeon (simeon.sentex.ca [209.112.4.47]) by granite.sentex.net (8.8.8/8.6.9) with SMTP id NAA27019; Tue, 17 Aug 1999 13:18:48 -0400 (EDT) Message-Id: <3.0.5.32.19990817131742.02a5f6c0@staff.sentex.ca> X-Sender: mdtpop@staff.sentex.ca X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Tue, 17 Aug 1999 13:17:42 -0400 To: Matthew Dillon From: Mike Tancsa Subject: Re: Any work around for this FreeBSD bug/DoS ? Cc: freebsd-security@FreeBSD.ORG In-Reply-To: <199908170527.WAA13380@apollo.backplane.com> References: <4.1.19990816203409.05989960@granite.sentex.ca> <4.1.19990816213403.05a3b540@granite.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 10:27 PM 8/16/99 -0700, Matthew Dillon wrote: >:Thanks for the quick response Matt. But to what value, and what are the >:implications / trade offs ? Sorry, was this discussed before somewhere ? I >:didnt see any followup in stable where I originally saw it posted. Doing a >:search in Dejanews through the mailing lists, I only see three old >:references to this particular param from 6 months ago. >: >: ---Mike > > Well, the problem you are trying to avoid is allowing the user to > over-allocate network mbufs for sockets. It will be a combination of > the maximum buffer size allowed for sockets x 2 ( there are separate > read and write buffers ) and the maximum number of descriptors the user > can allocate. In addition to that sysctl you need to look at the > 'maxproc' and 'descriptors' resource limits in /etc/login.conf, which > can be set differently depending on the user id or user class (a field > in the password file, see 'man 5 passwd'). > > So, for example, if you limit normal users to 30 processes and 40 > file descriptors per process you wind up with a maximum of 1200 open > descriptors. If you limit the socket buffer to 16384, that's 32K > per descriptor and around 38MB of ram. The system would have to be > configured with a sufficient number of network mbufs such that a single > user allocating 38MB of ram does not run the system out. It is possible > to adjust the number of mbuf clusters in the kernel config using the > NMBCLUSTERS options (see /usr/src/sys/i386/conf/LINT). I think each > cluster represents either 8K or 16K. I forget. Thanks for the extended info. What I am suprised at is that even with MAXUSERS set to 128, I have to use something as restrictive as dialu:\ :copyright=/etc/COPYRIGHT:\ :welcome=/etc/motd:\ :setenv=MAIL=/var/mail/$,BLOCKSIZE=K:\ :path=~/bin /bin /usr/bin /usr/local/bin /usr/X11R6/bin:\ :nologin=/var/run/nologin:\ :cputime=unlimited:\ :datasize=unlimited:\ :stacksize=unlimited:\ :memorylocked-cur=10M:\ :memoryuse-max=30M:\ :maxproc-cur=9:\ :maxproc-max=15:\ :openfiles-max=16:\ :filesize=unlimited:\ :coredumpsize=unlimited:\ :priority=0:\ :ignoretime@:\ :umask=022: It seems anything above 16 files open (e.g. 32), and they are able to panic the system. > > There are many ways a user can crash the system... eating network mbufs > isn't the easiest. My experience is that as long as you cover most of > the bases, the few that remain will not cause enough of a problem to > become endemic. Crashing a machine through a user account is not > really satisfactory to most hackers since it is so easy to do -- and > also relatively easy to trace. Well, hackers are one thing, but script kiddies are another. They like to try these sorts of things :-( Sort of 'pissing in the global village well' as my friend says... No real point to it, they just like to cause damage :-( ---Mike ------------------------------------------------------------------------ Mike Tancsa, tel 01.519.651.3400 Network Administrator, mike@sentex.net Sentex Communications www.sentex.net Cambridge, Ontario Canada To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message