From owner-freebsd-security Sun Dec 3 7:29:46 2000 From owner-freebsd-security@FreeBSD.ORG Sun Dec 3 07:29:45 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from prioris.mini.pw.edu.pl (prioris.mini.pw.edu.pl [148.81.80.7]) by hub.freebsd.org (Postfix) with ESMTP id EB81937B400 for ; Sun, 3 Dec 2000 07:29:44 -0800 (PST) Received: from pf39.warszawa.sdi.tpnet.pl (prioris.mini.pw.edu.pl [148.81.80.7]) by prioris.mini.pw.edu.pl (Postfix) with ESMTP id B7BB17D812 for ; Sun, 3 Dec 2000 16:29:37 +0100 (CET) Received: (from zaks@localhost) by pf39.warszawa.sdi.tpnet.pl (8.11.1/8.11.1) id eB3FI8D00944; Sun, 3 Dec 2000 16:18:08 +0100 (CET) (envelope-from zaks) Content-MD5: 7d6842e01bc8d359267ea22b75a6c03e From: Slawek Zak To: freebsd-security@freebsd.org Subject: Re: Rate Limiting syn-ack's References: <20001203012802.25514.qmail@web116.yahoomail.com> Date: 03 Dec 2000 16:18:08 +0100 In-Reply-To: <20001203012802.25514.qmail@web116.yahoomail.com> Message-ID: <87g0k55ya7.fsf@pf39.warszawa.sdi.tpnet.pl> Lines: 8 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Channel Islands) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Holtor writes: > Is there anyway I can limit outgoing syn-ack packets > my computer sends? With dummynet. It lets you limit any packets you can filter with ipfw. /S To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Dec 3 21:23: 1 2000 From owner-freebsd-security@FreeBSD.ORG Sun Dec 3 21:22:58 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from reddog.yi.org (cg632877-a.adubn1.nj.home.com [24.12.124.217]) by hub.freebsd.org (Postfix) with ESMTP id ADB3537B401 for ; Sun, 3 Dec 2000 21:22:57 -0800 (PST) Received: by reddog.yi.org (Postfix, from userid 1001) id 024F4D22D; Sun, 3 Dec 2000 19:28:02 -0500 (EST) Date: Sun, 3 Dec 2000 19:28:02 -0500 From: spectre To: Holtor Cc: freebsd-security@freebsd.org Subject: Re: Rate Limiting syn-ack's Message-ID: <20001203192802.A3502@reddog.yi.org> References: <20001203012802.25514.qmail@web116.yahoomail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001203012802.25514.qmail@web116.yahoomail.com>; from holtor@yahoo.com on Sat, Dec 02, 2000 at 05:28:02PM -0800 Sender: pika@reddog.yi.org Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, Dec 02, 2000 at 05:28:02PM -0800, Holtor wrote: > Hi all, > > Is there anyway I can limit outgoing syn-ack packets > my computer sends? I had a large syn flood which was > about 7 mbps incomming. The server also sent 7 mbps > outgoing to reply to those syn's. How can i stop that > or somehow rate limit to maybe 500 kbps or 1 mbps? > > I'm not able to find an option to do this using ipfw > and/or dummynet. > > Thanks. > > Holt Hello, I think you should be looking at denying denying incoming SYN packets instead of denying outoing SYN+ACK. There's lots of discussion going on about preventing SYN flooding and the general class thereof that's meant to consume network resources (look at CERT CA-2000-21). Basically the question comes down to: how to distinguish the valid SYNs from the invalid ones. And I for one don't know of a way to do this. What you *might* look into is something like: ipfw add pipe 10 tcp from any to any in setup ipfw pipe 10 config bw 1Mbit/s queue 150KBytes or if you could have a service that looks at how much traffic (SYNs) you are getting and then adds rules like: ipfw add pipe 20 tcp from any to any in setup ipfw pipe 10 config bw 5Mbit/s queue 150Kbytes plr 0.03 If you *must* doing outoing SYN-ACK, then just look at the first example given, and replace 'in' with 'out', and 'setup' with 'tcpflags syn,ack'. Again the problem is, how do you limit those 1Mbit/s incoming SYNs to _valid_ ones. I don't know of any good way. Perhaps you can look at this as another form of a bandwidth saturation attack, which, there really is no defense against without the help of your ISP. P.S. I thought this off the top of my head, so consule man ipfw, and note that this doesn't handle fragments. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Dec 3 23:35:46 2000 From owner-freebsd-security@FreeBSD.ORG Sun Dec 3 23:35:44 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from gera.nns.ru (gera.nns.ru [195.230.79.10]) by hub.freebsd.org (Postfix) with ESMTP id D886937B400 for ; Sun, 3 Dec 2000 23:35:42 -0800 (PST) Received: from falcon.nns.ru (root@falcon.nns.ru [195.230.79.70]) by gera.nns.ru (8.11.1/8.11.1) with ESMTP id eB47ZO852190; Mon, 4 Dec 2000 10:35:24 +0300 (MSK) (envelope-from abc@nns.ru) Received: from falcon.nns.ru (abc@localhost [127.0.0.1]) by falcon.nns.ru (8.11.1/8.11.1) with SMTP id eB47Ywi23924; Mon, 4 Dec 2000 10:35:00 +0300 (MSK) (envelope-from abc@nns.ru) From: "Andrey V. Sokolov" Reply-To: abc@nns.ru Organization: NEL Date: Mon, 4 Dec 2000 10:34:54 +0300 X-Mailer: KMail [version 1.1.99] Subject: The "to" keyword in IP-filter To: security@FreeBSD.ORG Cc: ipfilter@coombs.anu.edu.au MIME-Version: 1.0 Message-Id: <00120410345400.23843@falcon.nns.ru> Content-Type: multipart/mixed; boundary="eB47Ywi23924.975915300/falcon.nns.ru" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a MIME-encapsulated message. --eB47Ywi23924.975915300/falcon.nns.ru Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Hi! I have FreeBSD router running under 4.1-RELEASE with IP-filter 3.4.13. After upgrading to 4.2-RELEASE, the "to" method (in IP-filter) seems to f= ail=20 working properly. With it I still use IP-filter 3.4.13. =2E.. pass in quick on dc0 to dc3:195.170.224.33 proto udp from 195.170.250.0/2= 5 to any keep state keep frags group 10 =2E.. If I enable logging for this rule I see maching packets, but no packets g= o to the specified destination. What should I do to resolve the problem? Thanks. -- Best regards _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ Andrey V. Sokolov=09=09mailto:abc@nns.ru _/ National Electronic Library=09http://www.nns.ru _/ Moscow, Russia --eB47Ywi23924.975915300/falcon.nns.ru --eB47Ywi23924.975915300/falcon.nns.ru-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 4 3:49: 8 2000 From owner-freebsd-security@FreeBSD.ORG Mon Dec 4 03:49:05 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from expert.com.br (soure.expert.com.br [200.242.253.1]) by hub.freebsd.org (Postfix) with SMTP id F2E8037B400 for ; Mon, 4 Dec 2000 03:49:03 -0800 (PST) Received: (qmail 15139 invoked from network); 4 Dec 2000 11:48:06 -0000 Received: from unknown (HELO nirvana) (200.242.253.60) by soure.expert.com.br with SMTP; 4 Dec 2000 11:48:06 -0000 Message-ID: <00ae01c05de8$286509c0$3cfdf2c8@nirvana> From: "Roberto Samarone Araujo (RSA)" To: Subject: Email of FreeBSD security check Date: Mon, 4 Dec 2000 08:48:45 -0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, Every day a receive 2 emails from my FreeBSD 3.5 box about security, this emails says something about backup passwords and group files, disk status, dumps, cheking for user ID, ipfw and so. The subject of this emails are : server1.mydomain security check output server1.mydomais 12/03/00 22:00 system check I would like to know what's the program that send this messages, where I can change to send this emails to another account and how can I control the out put of this messages. thanks, Roberto Samarone Araujo To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 4 4:36:22 2000 From owner-freebsd-security@FreeBSD.ORG Mon Dec 4 04:36:20 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from area51.v-wave.com (area51.v-wave.com [24.108.173.252]) by hub.freebsd.org (Postfix) with SMTP id 4818437B402 for ; Mon, 4 Dec 2000 04:36:19 -0800 (PST) Received: (qmail 12013 invoked by uid 1001); 4 Dec 2000 12:36:18 -0000 Date: Mon, 4 Dec 2000 05:36:18 -0700 From: Chris Wasser To: "Roberto Samarone Araujo (RSA)" Cc: freebsd-security@FreeBSD.ORG Subject: Re: Email of FreeBSD security check Message-ID: <20001204053618.C7848@skunkworks.area51-arpa.mil> References: <00ae01c05de8$286509c0$3cfdf2c8@nirvana> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <00ae01c05de8$286509c0$3cfdf2c8@nirvana>; from sama@supridad.com.br on Mon, Dec 04, 2000 at 08:48:45AM -0300 X-Operating-System: FreeBSD 4.2-STABLE Sender: flatline@area51.v-wave.com Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon 04 Dec 2000, Roberto Samarone Araujo (RSA) wrote: > server1.mydomain security check output > server1.mydomais 12/03/00 22:00 system check > > I would like to know what's the program that send this messages, > where I can change to send this emails to another account and how can I > control the out put of this messages. The security output is done by /etc/security, the other one is done via periodic(8) which you can easily change/view by looking at /etc/periodic .. You can learn more about this by typing "man periodic" (no quotes) They're just simple shell scripts and it's quite easy to modify and add your own. HTHH, Chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 4 4:38:55 2000 From owner-freebsd-security@FreeBSD.ORG Mon Dec 4 04:38:54 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mail1.toronto.istar.net (mail1.toronto.istar.net [209.89.75.17]) by hub.freebsd.org (Postfix) with ESMTP id C482337B401 for ; Mon, 4 Dec 2000 04:38:52 -0800 (PST) Received: from ip60.kingston.dialup.canada.psi.net ([154.5.64.60]) by mail1.toronto.istar.net with esmtp (Exim 2.02 #1) id 142utd-0004fg-00; Mon, 4 Dec 2000 07:39:06 -0500 Date: Mon, 4 Dec 2000 07:45:04 -0500 (EST) From: Dru To: "Roberto Samarone Araujo (RSA)" Cc: freebsd-security@FreeBSD.ORG Subject: Re: Email of FreeBSD security check In-Reply-To: <00ae01c05de8$286509c0$3cfdf2c8@nirvana> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 4 Dec 2000, Roberto Samarone Araujo (RSA) wrote: > Hi, > > Every day a receive 2 emails from my FreeBSD 3.5 box about > security, this emails says something about backup passwords and group files, > disk status, dumps, cheking for user ID, ipfw and so. The subject of this > emails are : > > server1.mydomain security check output > server1.mydomais 12/03/00 22:00 system check > > I would like to know what's the program that send this messages, > where I can change to send this emails to another account and how can I > control the out put of this messages. > Hi Roberto, You may find this link useful: http://www.oreillynet.com/pub/a/bsd/2000/09/27/FreeBSD_Basics.html Cheers, Dru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 4 4:42:22 2000 From owner-freebsd-security@FreeBSD.ORG Mon Dec 4 04:42:21 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from area51.v-wave.com (area51.v-wave.com [24.108.173.252]) by hub.freebsd.org (Postfix) with SMTP id 6E98037B400 for ; Mon, 4 Dec 2000 04:42:20 -0800 (PST) Received: (qmail 12038 invoked by uid 1001); 4 Dec 2000 12:42:20 -0000 Date: Mon, 4 Dec 2000 05:42:19 -0700 From: Chris Wasser To: "Roberto Samarone Araujo (RSA)" Cc: freebsd-security@FreeBSD.ORG Subject: Re: FreeBSD security check --footnote Message-ID: <20001204054219.D7848@skunkworks.area51-arpa.mil> References: <00ae01c05de8$286509c0$3cfdf2c8@nirvana> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <00ae01c05de8$286509c0$3cfdf2c8@nirvana>; from sama@supridad.com.br on Mon, Dec 04, 2000 at 08:48:45AM -0300 X-Operating-System: FreeBSD 4.2-STABLE Sender: flatline@area51.v-wave.com Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Forgot to mention, the periodic process is controlled by by cron(8), type "man cron" for more information on how cron works and can be configured. You can view the process by looking at /etc/crontab, for example: # do daily/weekly/monthly maintenance 1 3 * * * root periodic daily 30 3 * * 6 root periodic weekly 30 5 1 * * root periodic monthly however, you shouldn't edit this file, but rather redirect all mail for root@yourhost.com to useraccount@yourhost.com (or elsewhere) using your mailing system (for example, I use qmail, so I have all mail destined for root/postmaster sent to my user account instead where I normally read email) Chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 4 9:29:21 2000 From owner-freebsd-security@FreeBSD.ORG Mon Dec 4 09:29:15 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from c004.sfo.cp.net (c004-h015.c004.sfo.cp.net [209.228.14.102]) by hub.freebsd.org (Postfix) with SMTP id CB88237B401 for ; Mon, 4 Dec 2000 09:29:14 -0800 (PST) Received: (cpmta 8631 invoked from network); 4 Dec 2000 09:29:14 -0800 Received: from dt1-blk1-hfc-0251-d1db0c19.rdc1.sdca.coxatwork.com (HELO localhost) (209.219.12.25) by smtp.dogparkcomm.com (209.228.14.102) with SMTP; 4 Dec 2000 09:29:13 -0800 X-Sent: 4 Dec 2000 17:29:13 GMT X-Sender: webmaster@GalaxyFree.com From: GalaxyFree To: FreeBSD-security@FreeBSD.org Date: Mon, 04 Dec 2000 09:28:28 -0800 Subject: Hacker Warning MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001__436747499_34108.7" Content-Transfer-Encoding: 7bit Message-Id: <20001204172914.CB88237B401@hub.freebsd.org> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a Multipart MIME message. ------=_NextPart_000_001__436747499_34108.7 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit ------=_NextPart_000_001__436747499_34108.7 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: base64 PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7Y2hh cnNldD1pc28tODg1OS0xIj4NCjwhRE9DVFlQRSBIVE1MIFBVQkxJQyAiLS8vVzNDLy9EVEQg SFRNTCA0LjAgVHJhbnNpdGlvbmFsLy9FTiI+DQo8SFRNTD48SEVBRD4NCjxNRVRBIGh0dHAt ZXF1aXY9Q29udGVudC1UeXBlIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1pc28tODg1 OS0xIj4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA1LjUwLjQyMDcuMjYwMSIgbmFtZT1HRU5F UkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVBRD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZm Zj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0K PERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5BcmUgeW91ciBwcml2YXRlIHBhc3N3b3Jk cyBiZWluZyBzdG9sZW4gYW5kIGFidXNlZD8gDQombmJzcDtJcyB5b3VyIGNvbXB1dGVyIHZ1 bG5lcmFibGUgPEJSPnRvIGhhY2tlcnMgYW5kIHZpcnVzZXM/PC9GT05UPjwvRElWPg0KPERJ Vj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48L0ZPTlQ+PEJSPjxGT05UIGZhY2U9QXJpYWwg c2l6ZT0yPk1vc3QgcGVvcGxlIA0Kc2ltcGx5IGNhbid0IGFuc3dlciB0aGVzZSB2aXRhbCBx dWVzdGlvbnMgd2l0aCBhbnkgZGVncmVlIG9mIA0KY29uZmlkZW5jZS48L0ZPTlQ+PC9ESVY+ DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjwvRk9OVD48QlI+PEZPTlQgZmFjZT1B cmlhbCBzaXplPTI+T3VyIDxTVFJPTkc+ZnJlZSANCjwvU1RST05HPnNvZnR3YXJlIENEIHdp bGwgc3RyZW5ndGhlbiB5b3VyIGNvbXB1dGVyJ3MgZGVmZW5zZXMgZmFyIGJleW9uZCANCnRo YXQmbmJzcDs8QlI+b2YgdGhlIGdhcmRlbi12YXJpZXR5IGFudGktdmlydXMgc29mdHdhcmUg bW9zdCBwZW9wbGUmbmJzcDtyZWx5IA0KdXBvbiBhcyB0aGVpciBvbmx5Jm5ic3A7PEJSPmxp bmUgb2YgZGVmZW5zZSBhZ2FpbnN0IG1hbGljaW91cyBhdHRhY2suIE91ciBmcmVlIA0KPEEg aHJlZj0iaHR0cDovL3d3dy5nYWxheHlmcmVlLmNvbSI+PFNUUk9ORz5IYWNrZXIgUHJvdGVj dGlvbiBTdWl0ZTwvU1RST05HPiANCjwvQT5jb21lcyZuYnNwOzxCUj5vbiBhIGhhbmR5IENE LCBhbmQgaXMgcmVhbGx5IDxTVFJPTkc+ZnJlZTwvU1RST05HPiAtLS0tLSBoYXJkIA0KdG8g YmVsaWV2ZSBidXQgdHJ1ZSAtLS0tLSB3ZSBldmVuIHBheSZuYnNwOzxCUj5zaGlwcGluZyBp bnNpZGUgdGhlIGNvbnRpbmVudGFsIA0KVS5TLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQg ZmFjZT1BcmlhbCBzaXplPTI+PC9GT05UPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjwvRk9O VD48QlI+PEZPTlQgDQpmYWNlPUFyaWFsIHNpemU9Mj5UaGlzIDxTVFJPTkc+ZnJlZTwvU1RS T05HPiBDRCBhcm1zIHlvdSB3aXRoIGFuIGFyc2VuYWwgb2YgDQphbnRpLWhhY2tlciB3ZWFw b25zLCBpbmNsdWRpbmcgPEEgDQpocmVmPSJodHRwOi8vd3d3LmdhbGF4eWZyZWUuY29tIj48 U1RST05HPmZpbGUmbmJzcDs8QlI+YW5kJm5ic3A7ZW1haWwgDQplbmNyeXB0aW9uLCBmaXJl d2FsbCwgY29tcHV0ZXIgbG9ja2Rvd24sIGRhdGEgc2hyZWRkaW5nLCANCnNlbGYtZGVzdHJ1 Y3QmbmJzcDs8QlI+ZW1haWwsIGF0dGFjayB0cmFjaW5nLCBhbm9ueW1vdXMgc3VyZmluZywg YW50aS12aXJ1cywgDQprZXlzdHJva2UgcmVjb3JkaW5nIGFuZCZuYnNwOzxCUj5tb3JlPC9T VFJPTkc+PC9BPjxTVFJPTkc+LjwvU1RST05HPiBUaGUgDQo8U1RST05HPmZyZWU8L1NUUk9O Rz4gQ0QgaXMgYWxsLWluY2x1c2l2ZSwgYW5kIHJlcXVpcmVzIG5vIHR5cGUgb2YgcHVyY2hh c2UgYXQgDQphbnkgdGltZS4mbmJzcDs8QlI+U28sIGxlYXZlIHlvdXIgY3JlZGl0IGNhcmQg d2hlcmUgaXQgaXMgaGFwcGllc3QgLS0gaW4geW91ciANCndhbGxldCE8L0ZPTlQ+PC9ESVY+ DQo8RElWPjxCUj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj4mbmJzcDtBcyBhIHNwZWNpYWwg Ym9udXMsIHdlIGluY2x1ZGUgYSB0dXRvcmlhbCANCm9uIDxTVFJPTkc+PEEgaHJlZj0iaHR0 cDovL3d3dy5nYWxheHlmcmVlLmNvbSI+UEFTU1dPUkQgSEFDS0lORy48L0E+PC9TVFJPTkc+ IElmIA0KeW91IG93biBhIHBhc3N3b3JkJm5ic3A7PEJSPnByb3RlY3RlZCB3ZWJzaXRlLCB5 b3UgY2FuIGdldCBzb21lIHJlYWwgcGVhY2Ugb2YgDQptaW5kIGJ5IHB1dHRpbmcgeW91ciBl eGlzdGluZyZuYnNwOzxCUj5kZWZlbnNlcyB0byB0aGUgdGVzdCwgc2VlaW5nIHdoZXJlIHRo ZXkgDQpkb24ndCBtZWFzdXJlIHVwLCBhbmQgdGFraW5nIHNvbWUgc2ltcGxlJm5ic3A7PEJS PmNvdW50ZXJtZWFzdXJlcy48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwg c2l6ZT0yPjwvRk9OVD48QlI+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+VG8gZ2V0IHRoZSBD RCwgDQpzaW1wbHkgdmlzaXQgb3VyIHdlYnNpdGUgPEEgDQpocmVmPSJodHRwOi8vd3d3Lkdh bGF4eUZyZWUuY29tIj5odHRwOi8vd3d3LkdhbGF4eUZyZWUuY29tPC9BPi4mbmJzcDsgSWYg eW91IA0Kc2tpbSB0aGUgaW5mb3JtYXRpb24mbmJzcDs8QlI+dGhlcmUsIHlvdSdsbCBiZSBh YmxlIHRvIHNpZ24gdXAgZm9yIHRoZSANCjxTVFJPTkc+ZnJlZTwvU1RST05HPiBDRCBpbiBs ZXNzIHRoYW4gNSBtaW51dGVzIChvaywmbmJzcDs8QlI+d2UgbWFrZSB5b3UgbG9vayANCmF0 IHNvbWUgYWR2ZXJ0aXNlbWVudHMgZm9yIDUgbWludXRlcywgdGhhdCdzIGhvdyB3ZSBwYXkg dGhlJm5ic3A7PEJSPmJpbGxzIA0KYXJvdW5kIGhlcmUpLiBCdXQgaWYgeW91IGFyZSBhIGRl dGFpbCBwZXJzb24sIHRoZXJlJ3MgZW5vdWdoIA0KZmFzY2luYXRpbmcmbmJzcDs8QlI+YW5k IHNvbGlkIGluZm9ybWF0aW9uIGFib3V0IGFudGktaGFja2VyIGRlZmVuc2VzIHRvIGtlZXAg DQp5b3Ugb2NjdXBpZWQgZm9yIHF1aXRlJm5ic3A7PEJSPmEgd2hpbGUuIEFORCwgaWYgeW91 IHJlYWxseSBoYXRlIHRvIGxvb2sgYXQgDQphZHZlcnRpc2VtZW50cywgYW5kIHJhdGhlciBq dXN0IHBheSZuYnNwOzxCUj5hIGZldyBidWNrcyBmb3IgdGhlIENEIGFuZCBza2lwIGFsbCAN CnRoZSBhZHMsIHRoYXQgb3B0aW9uIGlzIGF2YWlsYWJsZSB0b28uIFRoZSZuYnNwOzxCUj5j aG9pY2UgaXMgDQp5b3Vycy48L0ZPTlQ+PC9ESVY+DQo8RElWPjxCUj48Rk9OVCBmYWNlPUFy aWFsIHNpemU9Mj4mbmJzcDtJZiB5b3Ugd291bGQgbGlrZSB0byBiZSBkZWxldGVkIGZyb20g b3VyIA0KbWFpbGluZyBsaXN0LCBwbGVhc2UgPEEgaHJlZj0ibWFpbHRvOndlYm1hc3RlckBn YWxheHlmcmVlIj5yZXBseSB3aXRoIA0KdGhlJm5ic3A7PEJSPndvcmQgIkRlbGV0ZSIgb24g dGhlIHN1YmplY3QgbGluZTwvQT4uIElmIHlvdSB3b3VsZCBsaWtlIG1vcmUgDQppbmZvcm1h dGlvbiwgcGxlYXNlJm5ic3A7PEJSPjxBIGhyZWY9Im1haWx0bzp3ZWJtYXN0ZXJAZ2FsYXh5 ZnJlZS5jb20iPnJlcGx5IA0Kd2l0aCB0aGUgd29yZCAiSW5mbyIgaW4gdGhlIHN1YmplY3Qg bGluZTwvQT4uIElmIHlvdSB3b3VsZCBsaWtlIHRvIGdldCANCnRoZSZuYnNwOzxCUj5DRCBm b3IgZnJlZSwgaW5jbHVkaW5nIGZyZWUgc2hpcHBpbmcsIGdvIHRvIDxBIA0KaHJlZj0iaHR0 cDovL3d3dy5HYWxheHlGcmVlLmNvbSI+aHR0cDovL3d3dy5HYWxheHlGcmVlLmNvbTwvQT4u PEJSPiZuYnNwOzxCUj5TaW5jZXJlbHksPEJSPiZuYnNwOzxCUj48QSANCmhyZWY9Imh0dHA6 Ly93d3cuZ2FsYXh5ZnJlZS5jb20iPkdBTEFYWUZSRUU8QlI+PC9BPiZuYnNwOzxCUj48L0ZP TlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_001__436747499_34108.7-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 4 9:35:37 2000 From owner-freebsd-security@FreeBSD.ORG Mon Dec 4 09:35:31 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from dozer.gtmi.net (MAIL.TARGITMAIL.COM [206.152.189.43]) by hub.freebsd.org (Postfix) with ESMTP id 59EF437B400 for ; Mon, 4 Dec 2000 09:35:26 -0800 (PST) Received: by MAIL.TARGITMAIL.COM with Internet Mail Service (5.5.2650.21) id ; Mon, 4 Dec 2000 12:32:52 -0500 Message-ID: From: Nathan Paquin To: 'GalaxyFree' , FreeBSD-security@FreeBSD.org Subject: RE: Hacker Warning Date: Mon, 4 Dec 2000 12:32:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C05E18.3A5B36BA" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C05E18.3A5B36BA Content-Type: text/plain; charset="iso-8859-1" sending spam to a freeBSD security list cant be good... -----Original Message----- From: GalaxyFree [mailto:webmaster@GalaxyFree.com] Sent: Monday, December 04, 2000 12:28 PM To: FreeBSD-security@FreeBSD.org Subject: Hacker Warning Are your private passwords being stolen and abused? Is your computer vulnerable to hackers and viruses? Most people simply can't answer these vital questions with any degree of confidence. Our free software CD will strengthen your computer's defenses far beyond that of the garden-variety anti-virus software most people rely upon as their only line of defense against malicious attack. Our free Hacker Protection Suite comes on a handy CD, and is really free ----- hard to believe but true ----- we even pay shipping inside the continental U.S. This free CD arms you with an arsenal of anti-hacker weapons, including file and email encryption, firewall, computer lockdown, data shredding, self-destruct email, attack tracing, anonymous surfing, anti-virus, keystroke recording and more. The free CD is all-inclusive, and requires no type of purchase at any time. So, leave your credit card where it is happiest -- in your wallet! As a special bonus, we include a tutorial on PASSWORD HACKING. If you own a password protected website, you can get some real peace of mind by putting your existing defenses to the test, seeing where they don't measure up, and taking some simple countermeasures. To get the CD, simply visit our website http://www.GalaxyFree.com . If you skim the information there, you'll be able to sign up for the free CD in less than 5 minutes (ok, we make you look at some advertisements for 5 minutes, that's how we pay the bills around here). But if you are a detail person, there's enough fascinating and solid information about anti-hacker defenses to keep you occupied for quite a while. AND, if you really hate to look at advertisements, and rather just pay a few bucks for the CD and skip all the ads, that option is available too. The choice is yours. If you would like to be deleted from our mailing list, please reply with the word "Delete" on the subject line. If you would like more information, please reply with the word "Info" in the subject line. If you would like to get the CD for free, including free shipping, go to http://www.GalaxyFree.com . Sincerely, GALAXYFREE ------_=_NextPart_001_01C05E18.3A5B36BA Content-Type: text/html; charset="iso-8859-1"
sending spam to a freeBSD security list cant be good...
-----Original Message-----
From: GalaxyFree [mailto:webmaster@GalaxyFree.com]
Sent: Monday, December 04, 2000 12:28 PM
To: FreeBSD-security@FreeBSD.org
Subject: Hacker Warning

 
Are your private passwords being stolen and abused?  Is your computer vulnerable
to hackers and viruses?

Most people simply can't answer these vital questions with any degree of confidence.

Our free software CD will strengthen your computer's defenses far beyond that 
of the garden-variety anti-virus software most people rely upon as their only 
line of defense against malicious attack. Our free Hacker Protection Suite comes 
on a handy CD, and is really free ----- hard to believe but true ----- we even pay 
shipping inside the continental U.S.

This free CD arms you with an arsenal of anti-hacker weapons, including file 
and email encryption, firewall, computer lockdown, data shredding, self-destruct 
email, attack tracing, anonymous surfing, anti-virus, keystroke recording and 
more. The free CD is all-inclusive, and requires no type of purchase at any time. 
So, leave your credit card where it is happiest -- in your wallet!

 As a special bonus, we include a tutorial on PASSWORD HACKING. If you own a password 
protected website, you can get some real peace of mind by putting your existing 
defenses to the test, seeing where they don't measure up, and taking some simple 
countermeasures.

To get the CD, simply visit our website http://www.GalaxyFree.com.  If you skim the information 
there, you'll be able to sign up for the free CD in less than 5 minutes (ok, 
we make you look at some advertisements for 5 minutes, that's how we pay the 
bills around here). But if you are a detail person, there's enough fascinating 
and solid information about anti-hacker defenses to keep you occupied for quite 
a while. AND, if you really hate to look at advertisements, and rather just pay 
a few bucks for the CD and skip all the ads, that option is available too. The 
choice is yours.

 If you would like to be deleted from our mailing list, please reply with the 
word "Delete" on the subject line. If you would like more information, please 
reply with the word "Info" in the subject line. If you would like to get the 
CD for free, including free shipping, go to http://www.GalaxyFree.com.
 
Sincerely,
 
GALAXYFREE
 
------_=_NextPart_001_01C05E18.3A5B36BA-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 4 10:45:19 2000 From owner-freebsd-security@FreeBSD.ORG Mon Dec 4 10:45:16 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from peak.mountin.net (peak.mountin.net [207.227.119.2]) by hub.freebsd.org (Postfix) with ESMTP id 7462F37B400 for ; Mon, 4 Dec 2000 10:45:13 -0800 (PST) Received: (from daemon@localhost) by peak.mountin.net (8.9.1/8.9.1) id MAA29599; Mon, 4 Dec 2000 12:45:11 -0600 (CST) (envelope-from jeff-ml@mountin.net) Received: from dial-84.max1.wa.cyberlynk.net(207.227.118.84) by peak.mountin.net via smap (V1.3) id sma029597; Mon Dec 4 12:44:54 2000 Message-Id: <4.3.2.20001204123906.00c5f870@207.227.119.2> X-Sender: jeff-ml@207.227.119.2 X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Mon, 04 Dec 2000 12:44:01 -0600 To: Nathan Paquin From: "Jeffrey J. Mountin" Subject: RE: Hacker Warning Cc: security@FreeBSD.ORG In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 12:32 PM 12/4/00 -0500, Nathan Paquin wrote: >sending spam to a freeBSD security list cant be good... And replying to such spam on the list is? Along with using a full quote of aforementioned spam. And using other than a plain text format. Let's try to keep it a bit more on-topic with this list. Jeff Mountin - jeff@mountin.net Systems/Network Administrator FreeBSD - the power to serve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 4 11:44:35 2000 From owner-freebsd-security@FreeBSD.ORG Mon Dec 4 11:44:34 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from smtp.nettoll.com (unknown [212.155.143.61]) by hub.freebsd.org (Postfix) with ESMTP id 627CF37B400 for ; Mon, 4 Dec 2000 11:44:33 -0800 (PST) Received: by smtp.nettoll.com; Mon, 4 Dec 2000 20:42:47 +0100 (MET) Message-Id: <4.3.0.20001204204204.04b31e90@pop.free.fr> X-Sender: usebsd@pop.free.fr X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Mon, 04 Dec 2000 20:48:38 +0100 To: security@FreeBSD.ORG From: mouss Subject: ipfw/dummy: memory leak or what? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi guys, while looking at the ip_input code, and more particularly at the dummy net stuff in the start, I saw the m = m->m_next; given that m is supposed to be freed wen delivered, I don't see when is the dummy net mbuf (the one containing the rule, and that is skipped by the ->m_next above) will be freed. Is this a memory leak opprotunity or am I missing something? regards, mouss To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 4 12:58:40 2000 From owner-freebsd-security@FreeBSD.ORG Mon Dec 4 12:58:39 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from lariat.org (lariat.org [12.23.109.2]) by hub.freebsd.org (Postfix) with ESMTP id 8EC7B37B402 for ; Mon, 4 Dec 2000 12:58:38 -0800 (PST) Received: from mustang.lariat.org (IDENT:ppp0.lariat.org@lariat.org [12.23.109.2]) by lariat.org (8.9.3/8.9.3) with ESMTP id NAA24353; Mon, 4 Dec 2000 13:58:27 -0700 (MST) Message-Id: <4.3.2.7.2.20001204135528.04cbfa70@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 04 Dec 2000 13:58:23 -0700 To: FreeBSD-security@FreeBSD.ORG From: Brett Glass Subject: Free Trojans (Was: Hacker Warning) Cc: GalaxyFree In-Reply-To: <20001204172914.CB88237B401@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org It just about goes without saying that anyone who gives away such software has an ulterior motive. Perhaps it's spyware -- or a Trojan horse itself -- or expires and leaves you hanging after a short time. In any event, one should not patronize spammers; it encourages them. --Brett Glass At 10:28 AM 12/4/2000, GalaxyFree wrote: > Are your private passwords being stolen and abused? Is your computer vulnerable >to hackers and viruses? [Remainder of spam omitted] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 4 13:53:26 2000 From owner-freebsd-security@FreeBSD.ORG Mon Dec 4 13:53:24 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from elvis.mu.org (elvis.mu.org [207.154.226.10]) by hub.freebsd.org (Postfix) with ESMTP id AFDA037B400 for ; Mon, 4 Dec 2000 13:53:24 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1098) id 501DC2B266; Mon, 4 Dec 2000 15:53:24 -0600 (CST) Date: Mon, 4 Dec 2000 15:53:24 -0600 From: Bill Fumerola To: mouss Cc: security@FreeBSD.ORG Subject: Re: ipfw/dummy: memory leak or what? Message-ID: <20001204155324.J75794@elvis.mu.org> References: <4.3.0.20001204204204.04b31e90@pop.free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.0.20001204204204.04b31e90@pop.free.fr>; from usebsd@free.fr on Mon, Dec 04, 2000 at 08:48:38PM +0100 X-Operating-System: FreeBSD 4.2-FEARSOME-20001103 i386 Sender: billf@elvis.mu.org Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Dec 04, 2000 at 08:48:38PM +0100, mouss wrote: > while looking at the ip_input code, and more particularly at the dummy net > stuff > in the start, I saw the > m = m->m_next; > > given that m is supposed to be freed wen delivered, I don't see when is the > dummy > net mbuf (the one containing the rule, and that is skipped by the ->m_next > above) > will be freed. > Is this a memory leak opprotunity or am I missing something? that line of code occurs 1328408120847192384719238128401382 times in the net code. you might want to give some context to what you're trying to say. -- Bill Fumerola - security yahoo / Yahoo! inc. - fumerola@yahoo-inc.com / billf@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 4 14:28:24 2000 From owner-freebsd-security@FreeBSD.ORG Mon Dec 4 14:28:22 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id E97E637B401 for ; Mon, 4 Dec 2000 14:28:21 -0800 (PST) Received: from laptop.baldwin.cx (root@dhcp246.osd.bsdi.com [204.216.28.246]) by pike.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id eB4MRvC18288; Mon, 4 Dec 2000 14:27:57 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20001204155324.J75794@elvis.mu.org> Date: Mon, 04 Dec 2000 14:28:32 -0800 (PST) From: John Baldwin To: Bill Fumerola Subject: Re: ipfw/dummy: memory leak or what? Cc: security@FreeBSD.org, mouss Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 04-Dec-00 Bill Fumerola wrote: > On Mon, Dec 04, 2000 at 08:48:38PM +0100, mouss wrote: >> while looking at the ip_input code, and more particularly at the dummy net >> stuff >> in the start, I saw the >> m = m->m_next; >> >> given that m is supposed to be freed wen delivered, I don't see when is the >> dummy >> net mbuf (the one containing the rule, and that is skipped by the ->m_next >> above) >> will be freed. >> Is this a memory leak opprotunity or am I missing something? > > that line of code occurs 1328408120847192384719238128401382 times in the net > code. you might want to give some context to what you're trying to say. He said ip_input, and at the start in the dummynet stuff: The only time m = m->next occurs in ip_input() is here: void ip_input(struct mbuf *m) { ... #if defined(IPFIREWALL) && defined(DUMMYNET) /* * dummynet packet are prepended a vestigial mbuf with * m_type = MT_DUMMYNET and m_data pointing to the matching * rule. */ if (m->m_type == MT_DUMMYNET) { rule = (struct ip_fw_chain *)(m->m_data) ; m = m->m_next ; ip = mtod(m, struct ip *); hlen = IP_VHL_HL(ip->ip_vhl) << 2; goto iphack ; } else rule = NULL ; #endif Looks like plenty of context to me. As to the actual question, I'm not a networking whiz I'm afraid. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 4 14:51:17 2000 From owner-freebsd-security@FreeBSD.ORG Mon Dec 4 14:51:14 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id 24D2137B400 for ; Mon, 4 Dec 2000 14:51:14 -0800 (PST) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id eB4Mmth64540; Mon, 4 Dec 2000 16:48:55 -0600 (CST) (envelope-from jlemon) Date: Mon, 4 Dec 2000 16:48:55 -0600 From: Jonathan Lemon To: freebsd-security@freebsd.org, mouss Subject: Re: ipfw/dummy: memory leak or what? Message-ID: <20001204164855.I56974@prism.flugsvamp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In , John Baldwin wrote: > > if (m->m_type == MT_DUMMYNET) { > rule = (struct ip_fw_chain *)(m->m_data) ; > m = m->m_next ; > ip = mtod(m, struct ip *); > hlen = IP_VHL_HL(ip->ip_vhl) << 2; > goto iphack ; > } else This isn't (theoretically) a leak. Dummynet works by prepending a private data structure onto the mbuf chain; this structure is not an mbuf, and should not be passed to m_freem(). Instead, look at the following fragment of code within ip_dummynet.c:transmit_event(), which takes care of freeing the data structure: switch (pkt->dn_dir) { case DN_TO_IP_IN : ip_input((struct mbuf *)pkt) ; break ; } FREE(pkt, M_IPFW); Although this is quite non-obvious, from my point of view. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 4 16:28:36 2000 From owner-freebsd-security@FreeBSD.ORG Mon Dec 4 16:28:17 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from secure.smtp.email.msn.com (cpimssmtpu07.email.msn.com [207.46.181.28]) by hub.freebsd.org (Postfix) with ESMTP id 0DFBE37B400 for ; Mon, 4 Dec 2000 16:28:17 -0800 (PST) Received: from x86nts4 - 216.103.48.12 by email.msn.com with Microsoft SMTPSVC; Mon, 4 Dec 2000 16:28:14 -0800 Message-ID: <00dd01c05e53$39c719e0$fd01a8c0@pacbell.net> From: "John Howie" To: Subject: Fw: NAPTHA Advisory Updated - BindView RAZOR Date: Mon, 4 Dec 2000 16:35:10 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1800 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1800 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Folks, Take note of how FreeBSD failed... john... ----- Original Message ----- From: "Steve Manzuik" To: Sent: Monday, December 04, 2000 3:09 PM Subject: NAPTHA Advisory Updated - BindView RAZOR > The NAPTHA DoS vulnerabilities > > Issue Date: November 30, 2000 > Contact: Robert Keyes > > Topic: > > Network DoS vulnerabilities > > Overview: > > A class of network DoS vulnerabilities has been discovered, and the name > NAPTHA is being used to describe them as a group. The NAPTHA > vulnerabilities are weaknesses in the way that TCP/IP stacks and network > applications handle the state of a TCP connection. > > Affected Systems: > > The Naptha DoS vulnerabilities "Tested Products" > > Impact: > > By creating a suitably large number of TCP connections and leaving them in > certain states, individual applications or the operating system itself can > be starved of resources to the point of failure. In the past, attacks that > would exploit TCP connections in this manner have not been implemented > because they would typically exhaust the resources of the attacker as > well. The innovation provided by the Naptha attack is that it is possible > to easily create a DoS on the target with little resource consumption on > the part of the attacker. > > Background: > > DoS > A denial of service attack is a purposeful action to significantly degrade > the quality and/or availability of services a system offers. > > DoS->RS > Resource Starvation is a type of denial of service attack. Here is where > we need to define the difference between an attack and a notable > vulnerability. With sufficient network resources available to the > attacker, any system is vulnerable to DoS->RS. > > What makes a method of DoS->RS notable is that it consumes far more > resources of the victim than resources of the attacker. A great differen ce > in resource levels indicate a vulnerability in the victim's system. The > software designed to expose this vulnerability can be called a DoS->RS > exploit. > > DoS->RS->TCP_STATE > The kernel keeps a record for every TCP connection. A large number of > connections, regardless of activity, require more memory and CPU time. It > is theoretically possible for a user on a machine with a large amount of > RAM, a fast processor, and a well-tuned operating system to overwhelm a > lesser system solely by using such standard programs as TELNET, however > the amount of resources consumed on the attacking system is large enough > so that this is not considered a serious vulnerability. > > An attack program utilizing a network API such as Berkeley Sockets is more > efficient and therefore more dangerous, but is not usually efficient > enough expose a dangerous vulnerability on the victim's system. > > Details: > > Naptha is a demonstration of an efficient DoS->RS->TCP_STATE exploit. It > is efficient because it does not use a traditional network API to set up a > TCP connection. Unlike a real TCP/IP stack, it does not keep any record of > connection state. It responds to a packet sent to it based on the flags in > that packet alone. When operated in a manner that will produce many > hundreds or thousands of connection records on the victim, it consumes > very little of the attacker's resources in comparison to the resources it > uses up on the victim's system. In this way, it can expose vulnerabilities > of a particular service, or the TCP/IP stack itself, on the victim's > system. > > Below are a few examples of the many possible Naptha weaknesses: > > - Novell's Netware 5.0 with sp1 installed locked up after 3000 > open connections on port 524. All 64MB of the system's RAM > became utilized and the CPU utilization as well maxed out at > 100%. The server still had not timed out connections and > recovered memory after 12 hours being left idle. > > - FreeBSD 4.0-REL became unusable after 495 connections to the > ssh port. Each connection started an instance of the daemon > which quickly exhausted available file handles; the system > reports "too many open files in system". After approximately 30 > minutes the connections start timing out and the system becomes > usable again. > > - Windows 2000 seems to be invulnerable. > > See the complete list of tested products at the end of this document. > > > The Workings of Naptha > ---------------------- > > The objective of this section is to describe the basic structure of > the Naptha attack so that researchers can verify our claim that such an > attack is possible and should be considered with all due seriousness. > > While there has been some previous work in this area, no one has > published or demonstrated a tool that can leave connections in any of > the various TCP states on the victim machine (ESTABLISHED and FIN-WAIT-1, > etc.) or that has a multi-component architecture (allowing one to hide > part of the attack on different hosts). > > Naptha gains much of its effectiveness through the fact that the attack > can be made in a distributed manner. > > The first part sends out a sequence of SYN packets from all possible > ports of a forged IP address to the victim. Depending on the requirements > of > the individual attack scenario, multiple copies of this program on the > same host could be used to attack different hosts, or multiple hosts could > attack a single victim. This sounds like a SYN flood, but there's more to > it. > > The second half runs on a LAN where the forged IP address would be, if it > were a real host. The program first makes sure that the router has an > entry > for this phantom host in its ARP table. Next, it listens in promiscuous > mode for a packet from the victim to the phantom host. The program > responds > with a packet with the appropriate flags and sequence numbers. Typically, > it listens for SYN/ACK packets and sends ACK. It could also set the FIN > flag and leave the connection in FIN-WAIT-1. To keep connections alive > longer, it can listen for 'regular' data packets or 'keep alive' packets > and send ACK in reply. Multiple victims could be targeted by a single > instance of this program. > > This 'phantom' nature makes it hard to track down and eliminate. > > In order to be successfully asymmetrical in its consumption of > resources, such an attack program must not set up any TCBs (Transmission > Control Blocks) in the kernel of the attacking machine. This helps to > ensure that the attacker's activities will not be directly constrained > by the client-side kernel limitations. It is also important that the > number of processes needed on the client side not grow with the number of > TCP > connections. Naptha does this by completely avoiding use of the OS's > TCP/IP stack, and instead crafts its own raw packets. In fact, in a high > rate Naptha attack, the network's bandwidth would typically be the > constraint rather than the attacking host's resources. > > Naptha also has connection rate limiting capabilities. In one variation of > the attack, connections are established at a high rate and the victim is > left with thousands of ports open, and all resources are consumed before > the connections time out. In another scenario, connections are > established at a slow rate to avoid SYN flood protections. > > The number of connections and the rate of establishment necessary to > create a DoS is dependant on a number of factors. Different operating > systems have different thresholds of connection numbers, file numbers, > process memory, etc. The application running on that port may also have > its own levels of resource control. Some applications spawn a new process > for each connection. The speed of the CPU and amount of memory in a system > also affects its resistance to a Naptha attack. Lastly, the network > itself plays its part. > > In conclusion, the Naptha attack shows how serious a resource starvation > attack can be. There is no single, clear, obvious fix for this problem > but a number of promising ideas. > > Recommendations: > > Unfortunately, most vendors are vulnerable to Naptha attacks, and until > some vendor patches come out, there is very little that can be done > outside of normal security practices. We do have a few recommendations: > > 1. Limit the amount of services running on any system you > suspect that might become victim to a Naptha attack, especially > public systems. > > 2. Limit access as to who can connect to exposed TCP ports on a > system via firewalling techniques. On public systems this may be > impractical, but it should be limited just the same if possible. > > 3. Ensure that all border equipment, such as routers and > firewalls, is properly configured and you are doing both ingress > and egress filtering. (See RFC 2267) > > 4. On Unix systems, use inetd or possibly Dan Bernstein's > tcpserver (http://cr.yp.to/ucspi-tcp.html) to limit spawned > daemon processes. While this will not prevent that particular > daemon's resources from being over utilized, it is possible to > prevent daemons from crashing the server. This may allow the > server to recover. > > 5. On systems that have adjustments for various TCP timeouts and > keepalives, these can be adjusted to potentially allow for > quicker recovery (assuming that the Naptha attack did not crash > the system). For example, the TCP keepalive settings on Linux > 2.2 kernels might help recovery time: > > # cat /proc/sys/net/ipv4/tcp_keepalive_time > 7200 > # cat /proc/sys/net/ipv4/tcp_keepalive_probes > 9 > # cat /proc/sys/net/ipv4/tcp_max_ka_probes > 5 > # echo 30 > /proc/sys/net/ipv4/tcp_keepalive_time > # echo 2 > /proc/sys/net/ipv4/tcp_keepalive_probes > # echo 100 > /proc/sys/net/ipv4/tcp_max_ka_probes > > In the above example the keepalive time is adjusted from 2 hours > to 30 seconds, and the number of keepalive probes is adjusted > from 9 to 2. It also adjusts the maximum number of probes sent > out to be 100 instead of just 5. These are suggested values -- > real world adjusts will almost certainly be required. > > 6. The programs written to demonstrate the attack have been > released only to the security contacts at OS vendors, through > CERT. The code will not be released to the public. However, the > information below will serve as a 'fingerprint' for IDS to > detect the demonstration code. Please note that the code itself > could be easily modified to change the fingerprint, so this is > NOT a failsafe method of detecting a Naptha attack. > > IP: > TOS = Low Delay > ID = 413 > TCP: > FLAGS = SYN > SEQ ID = 6060842 > WINDOW = 512 > > Snort (http://www.snort.org) is a free lightweight IDS. Here's a > Snort filter for Naptha: > > alert tcp any any <> any any (flags:S; seq: 6060842; > id: 413; msg: "Naptha DoS Attack, see > http://razor.bindview.com//publish/advisories/adv_NAPTHA.html";) > > ------------------------------------------------------------------------ > > References: > > CVE: > > The Common Vulnerabilities and Exposures (CVE) project has > assigned the name CAN-2000-1039 to this issue. This is a > candidate for inclusion in the CVE list (http://cve.mitre.org), > which standardizes names for security problems. > > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2000-1039 > > CERT Advisory: > > http://www.cert.org/advisories/CA-2000-21.html > > Microsoft's security bulletin: > > http://www.microsoft.com/technet/security/bulletin/MS00-091.asp > > Microsoft Security Patch: > > NT4: > http://www.microsoft.com/Downloads/Release.asp?ReleaseID=25114 > > RFC 2267: > > http://www.faqs.org/rfcs/rfc2267.html > > "Distributed Denial of Service Defense Tactics" security paper > > Author: Simple Nomad > http://razor.bindview.com/publish/papers/DDSA_Defense.html > > "Strategies for Defeating Distributed Attacks" security paper > > Author: Simple Nomad > http://razor.bindview.com/publish/papers/strategies.html > > Snort: > > http://www.snort.org > > Dan Bernstein's tcpserver: > > http://cr.yp.to/ucspi-tcp.html > > Simson Garfinkel on Process-Table Attack > > http://www.securityfocus.com/archive/1/12636 > > Stanislav Shulanov's Netkill > > http://www.securityfocus.com/archive/1/56462 > > Contact: advisory+naptha@razor.bindview.com > > Acknowledgements: Mark Loveless and the rest of the RAZOR team. > > > ---------------------------------------------- > > > > The Naptha DoS vulnerabilities > "Tested Products" > > Note: The RAZOR team has examined > two TCP states out of many. These > states are the FIN-WAIT-1 state and > the ESTABLISHED state. More research > in this area is underway. We expect > to find a majority of operating > systems affected to some extent. > > > > Vendor Product Vulnerable? TCP state > Patch/Workaround Available? Notes > > Compaq Tru64 UNIX Yes ESTABLISHED No patch or > workaround available at this time See > V4.0F See > Recommendations Notes > > FreeBSD FreeBSD Yes ESTABLISHED No patch or > workaround available at this time See > 4.0-REL See > Recommendations Notes > > Hewlett-Packard HP-UX 11.00 Yes ESTABLISHED No patch or > workaround available at this time See > See > Recommendations Notes > > Microsoft Windows Yes FIN-WAIT-1 Workaround > available at See > 95,98,98SE > http://www.microsoft.com/technet/security/bulletin/MS00-091.asp Notes > > Microsoft Windows NT Yes FIN-WAIT-1, Patch > available at See > 4.0 SP6a ESTABLISHED > http://www.microsoft.com/Downloads/Release.asp?ReleaseID=25114 Notes > > Microsoft Windows No N/A N/A > N/A > 2000 > > Novell Netware 5 Yes ESTABLISHED No patch or > workaround available at this time See > SP1 See > Recommendations Notes > > SGI IRIX 6.5.7m Yes ESTABLISHED No patch or > workaround available at this time See > See > Recommendations Notes > > Sun Solaris 7, Yes ESTABLISHED No patch or > workaround available at this time See > 8 See > Recommendations Notes > > > ------------------------------------------------------------------------ > > Notes: > > Compaq - Tru64 UNIX V4.0F > > Two services were tested, portmapper (tcp > port 111) and finger (tcp port 79). These > services were chosen because finger runs > from inetd and portmapper runs without it. > > The Tru64 UNIX kernel appears to be > somewhat robust against Naptha attacks. > Sending twenty thousand packets to tcp > port 111 caused no obvious performance > degradation on the Tru64 UNIX host > (except that other attempts to query the > portmapper became unsuccessful). The > netstat command showed a steady-state > value of 4100 ESTABLISHED connections. > > Sending a few hundred packets to tcp port > 79, however, resulted in creation of too > many finger daemon processes for the > system to continue normal operation. > Trying to start a new process from a login > shell resulted in the error "No more > processes". It is possible that the finger > daemon attack would have been less > effective with a different inetd > configuration, or with different kernel > parameters. We did not investigate this. > > ------------------------------------------- > > FreeBSD - FreeBSD 4.0-REL > > In testing FreeBSD, a few specific > daemons/ports were targeted. For some, the > stability of the system as a whole can be > affected. The daemons targeted in this > testing are not necessarily at fault for > the problems encountered. > > SSH: > Became unusable after 495 connections to > the ssh port. Each connection started an > instance of the daemon which quickly > exhausted available file handles; the > system reports "too many open files in > system". After approximately 30 minutes > the connections start timing out and the > system becomes usable again. > > NFS: > Stopped functioning after 964 packets to > the NFS port. While the rest of the system > did not seem affected, the connections did > not time out. > > BIND: > Took 961 TCP connections before the kernel > reported "file table is full", and TCP > services failed. UDP DNS seemed > unaffected. These connections look a long > time to time out, at least an hour. > > Note: These services/ports can be > similarly affected on other Linux and UNIX > variants. > > ------------------------------------------- > > Hewlett-Packard - HP-UX 11.00 > > Two services were tested, portmapper and > telnet. These services were chosen because > telnet runs from inetd and portmapper runs > without it. > > TELNET: > HP-UX appears to have some protection. It > stops responding to Naptha packets after > several hundred from the same IP address. > However, until that time it is possible to > make telnetd respond with; "Telnet device > drivers missing: No such device". This > does recover fairly quickly, however. > > PORTMAPPER: > After several hundred Naptha TCP sessions, > a telnet session to port 111 will > immediately be disconnected. This broken > state lingers for much longer than the > telnet problem. > > ------------------------------------------- > > Microsoft - Windows 95,98,98SE > > Leaving a large number of connections in > FIN-WAIT-1 causes the NetBIOS and WWW > services on Microsoft Windows 95, 98, and > 98SE to fail and not restart. > > ------------------------------------------- > > Microsoft - Windows NT 4.0 SP6a > > Exploiting ESTALISHED states on port 139 > (netbios-ssn), caused the service to die > after 1010 packets. Port 135 (loc-srv) > died after 7929 packets. Interestingly, if > port 139 had been previously killed by > Naptha, port 135 died after two packets. > If the Naptha attack was paused, port 135 > would recover but be immediately > unavailable if the Naptha attack was > resumed. When port 135 died, the CPU > utilization would eventually jump to 100% > and remain there until a reboot. > > Leaving a large number of connections in > FIN-WAIT-1 causes the NetBIOS and WWW > services on Microsoft Windows NT 4.0 to > fail and not restart. > > ------------------------------------------- > > Novell - Netware 5 SP1 > > Locked up after 3000 open connections on > port 524, utilized all 64MB of the > system's RAM, and CPU utilization became > 100%. The server still had not timed out > connections and recovered memory after 12 > hours being left idle. > > ------------------------------------------- > > SGI - IRIX 6.5.7m > > Two services were tested, portmapper (tcp > port 111) and sgi-dgl (tcp port 5232). > These services were chosen because sgi-dgl > runs from inetd and portmapper runs > without it. > > The IRIX kernel appears to be somewhat > robust against Naptha attacks. Sending > twenty thousand packets to tcp port 111 > caused no obvious performance degradation > on the IRIX host (except that other > attempts to query the portmapper became > unsuccessful). The netstat command showed > a steady-state value of 195 ESTABLISHED > connections. > > Sending a few hundred packets to tcp port > 5232, however, resulted in creation of too > many dgl daemon processes for the system > to continue normal operation. Trying to > start a new process from a login shell > resulted in the error "No more processes". > It is possible that the dgl daemon attack > would have been less effective with a > different inetd configuration, or with > different kernel parameters. We did not > investigate this. > > ------------------------------------------- > > Sun - Solaris 7, 8 > > Two services were tested, portmapper and > telnet. These services were chosen because > telnet runs from inetd and portmapper runs > without it. > > TELNET: > At around 700 Naptha TCP sessions, a > telnet session will be connected but then > gets the message "can't grant slave pty" > and is disconnected. At 1700 Naptha TCP > sessions, a telnet session will be > connected but nothing else happens. This > is not confined to the telnet port, it > effects every port. If the Naptha attack > is stopped, eventually telnet will > recover. How long it is broken is > dependant on the speed and length of the > Naptha assault and other factors. A > typical downtime was an hour. > > PORTMAPPER: > At around 300 Naptha TCP sessions, a > telnet session to port 111 is immediately > disconnected (normally, this is > disconnected when a user hit the enter > key). This fault does not effect other > services. Downtime variable but typically > two hours. > > ------------------------------------------- > > Contact: advisory+naptha@razor.bindview.com > > _____________________________________________________________________ > ** TO UNSUBSCRIBE, send the command "UNSUBSCRIBE win2ksecadvice" > ** FOR A WEEKLY DIGEST, send the command "SET win2ksecadvice DIGEST" > SEND ALL COMMANDS TO: listserv@listserv.ntsecurity.net > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 4 16:44:16 2000 From owner-freebsd-security@FreeBSD.ORG Mon Dec 4 16:44:00 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from faith.cs.utah.edu (faith.cs.utah.edu [155.99.198.108]) by hub.freebsd.org (Postfix) with ESMTP id 11B5C37B400 for ; Mon, 4 Dec 2000 16:44:00 -0800 (PST) Received: (from danderse@localhost) by faith.cs.utah.edu (8.9.3/8.9.3) id RAA27046; Mon, 4 Dec 2000 17:43:25 -0700 (MST) Message-Id: <200012050043.RAA27046@faith.cs.utah.edu> Subject: Re: Fw: NAPTHA Advisory Updated - BindView RAZOR To: JHowie@msn.com (John Howie) Date: Mon, 4 Dec 2000 17:43:25 -0700 (MST) Cc: freebsd-security@FreeBSD.ORG In-Reply-To: <00dd01c05e53$39c719e0$fd01a8c0@pacbell.net> from "John Howie" at Dec 04, 2000 04:35:10 PM From: "David G. Andersen" X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: danderse@cs.utah.edu Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This isn't a FreeBSD failure per se, but a resource control failure. Whether you want to point a finger at FreeBSD, ssh, or the operator of the box is entirely up to you. :-) Note, however, that with sufficient isolation of the system daemons, this attack can be mitigated: it is, and will likely continue to be, an effective attack against particular network services, but the effects can be constrained to the public services (e.g. my ssh daemon will report no FDs available, but the rest of the system will be peachy fine). See Robert Watson's mail from a few days ago describing some work he's doing that should help the problem: http://www.securityfocus.com/frames/?content=/templates/archive.pike%3Flist%3D47%26mid%3D148364 -Dave Lo and behold, John Howie once said: > > Folks, > > Take note of how FreeBSD failed... > > john... > > ----- Original Message ----- > From: "Steve Manzuik" > To: > Sent: Monday, December 04, 2000 3:09 PM > Subject: NAPTHA Advisory Updated - BindView RAZOR > > > > The NAPTHA DoS vulnerabilities > > > > Issue Date: November 30, 2000 > > Contact: Robert Keyes > > > > Topic: > > > > Network DoS vulnerabilities > > > > Overview: > > > > A class of network DoS vulnerabilities has been discovered, and the name > > NAPTHA is being used to describe them as a group. The NAPTHA > > vulnerabilities are weaknesses in the way that TCP/IP stacks and network > > applications handle the state of a TCP connection. > > > > Affected Systems: > > > > The Naptha DoS vulnerabilities "Tested Products" > > > > Impact: > > > > By creating a suitably large number of TCP connections and leaving them > in > > certain states, individual applications or the operating system itself > can > > be starved of resources to the point of failure. In the past, attacks > that > > would exploit TCP connections in this manner have not been implemented > > because they would typically exhaust the resources of the attacker as > > well. The innovation provided by the Naptha attack is that it is > possible > > to easily create a DoS on the target with little resource consumption on > > the part of the attacker. > > > > Background: > > > > DoS > > A denial of service attack is a purposeful action to significantly > degrade > > the quality and/or availability of services a system offers. > > > > DoS->RS > > Resource Starvation is a type of denial of service attack. Here is where > > we need to define the difference between an attack and a notable > > vulnerability. With sufficient network resources available to the > > attacker, any system is vulnerable to DoS->RS. > > > > What makes a method of DoS->RS notable is that it consumes far more > > resources of the victim than resources of the attacker. A great differen > ce > > in resource levels indicate a vulnerability in the victim's system. The > > software designed to expose this vulnerability can be called a DoS->RS > > exploit. > > > > DoS->RS->TCP_STATE > > The kernel keeps a record for every TCP connection. A large number of > > connections, regardless of activity, require more memory and CPU time. > It > > is theoretically possible for a user on a machine with a large amount of > > RAM, a fast processor, and a well-tuned operating system to overwhelm a > > lesser system solely by using such standard programs as TELNET, however > > the amount of resources consumed on the attacking system is large enough > > so that this is not considered a serious vulnerability. > > > > An attack program utilizing a network API such as Berkeley Sockets is > more > > efficient and therefore more dangerous, but is not usually efficient > > enough expose a dangerous vulnerability on the victim's system. > > > > Details: > > > > Naptha is a demonstration of an efficient DoS->RS->TCP_STATE exploit. It > > is efficient because it does not use a traditional network API to set up > a > > TCP connection. Unlike a real TCP/IP stack, it does not keep any record > of > > connection state. It responds to a packet sent to it based on the flags > in > > that packet alone. When operated in a manner that will produce many > > hundreds or thousands of connection records on the victim, it consumes > > very little of the attacker's resources in comparison to the resources > it > > uses up on the victim's system. In this way, it can expose > vulnerabilities > > of a particular service, or the TCP/IP stack itself, on the victim's > > system. > > > > Below are a few examples of the many possible Naptha weaknesses: > > > > - Novell's Netware 5.0 with sp1 installed locked up after 3000 > > open connections on port 524. All 64MB of the system's RAM > > became utilized and the CPU utilization as well maxed out at > > 100%. The server still had not timed out connections and > > recovered memory after 12 hours being left idle. > > > > - FreeBSD 4.0-REL became unusable after 495 connections to the > > ssh port. Each connection started an instance of the daemon > > which quickly exhausted available file handles; the system > > reports "too many open files in system". After approximately 30 > > minutes the connections start timing out and the system becomes > > usable again. > > > > - Windows 2000 seems to be invulnerable. > > > > See the complete list of tested products at the end of this document. > > > > > > The Workings of Naptha > > ---------------------- > > > > The objective of this section is to describe the basic structure of > > the Naptha attack so that researchers can verify our claim that such an > > attack is possible and should be considered with all due seriousness. > > > > While there has been some previous work in this area, no one has > > published or demonstrated a tool that can leave connections in any of > > the various TCP states on the victim machine (ESTABLISHED and > FIN-WAIT-1, > > etc.) or that has a multi-component architecture (allowing one to hide > > part of the attack on different hosts). > > > > Naptha gains much of its effectiveness through the fact that the attack > > can be made in a distributed manner. > > > > The first part sends out a sequence of SYN packets from all possible > > ports of a forged IP address to the victim. Depending on the > requirements > > of > > the individual attack scenario, multiple copies of this program on the > > same host could be used to attack different hosts, or multiple hosts > could > > attack a single victim. This sounds like a SYN flood, but there's more > to > > it. > > > > The second half runs on a LAN where the forged IP address would be, if > it > > were a real host. The program first makes sure that the router has an > > entry > > for this phantom host in its ARP table. Next, it listens in promiscuous > > mode for a packet from the victim to the phantom host. The program > > responds > > with a packet with the appropriate flags and sequence numbers. > Typically, > > it listens for SYN/ACK packets and sends ACK. It could also set the FIN > > flag and leave the connection in FIN-WAIT-1. To keep connections alive > > longer, it can listen for 'regular' data packets or 'keep alive' packets > > and send ACK in reply. Multiple victims could be targeted by a single > > instance of this program. > > > > This 'phantom' nature makes it hard to track down and eliminate. > > > > In order to be successfully asymmetrical in its consumption of > > resources, such an attack program must not set up any TCBs (Transmission > > Control Blocks) in the kernel of the attacking machine. This helps to > > ensure that the attacker's activities will not be directly constrained > > by the client-side kernel limitations. It is also important that the > > number of processes needed on the client side not grow with the number > of > > TCP > > connections. Naptha does this by completely avoiding use of the OS's > > TCP/IP stack, and instead crafts its own raw packets. In fact, in a high > > rate Naptha attack, the network's bandwidth would typically be the > > constraint rather than the attacking host's resources. > > > > Naptha also has connection rate limiting capabilities. In one variation > of > > the attack, connections are established at a high rate and the victim is > > left with thousands of ports open, and all resources are consumed before > > the connections time out. In another scenario, connections are > > established at a slow rate to avoid SYN flood protections. > > > > The number of connections and the rate of establishment necessary to > > create a DoS is dependant on a number of factors. Different operating > > systems have different thresholds of connection numbers, file numbers, > > process memory, etc. The application running on that port may also have > > its own levels of resource control. Some applications spawn a new > process > > for each connection. The speed of the CPU and amount of memory in a > system > > also affects its resistance to a Naptha attack. Lastly, the network > > itself plays its part. > > > > In conclusion, the Naptha attack shows how serious a resource starvation > > attack can be. There is no single, clear, obvious fix for this problem > > but a number of promising ideas. > > > > Recommendations: > > > > Unfortunately, most vendors are vulnerable to Naptha attacks, and until > > some vendor patches come out, there is very little that can be done > > outside of normal security practices. We do have a few recommendations: > > > > 1. Limit the amount of services running on any system you > > suspect that might become victim to a Naptha attack, especially > > public systems. > > > > 2. Limit access as to who can connect to exposed TCP ports on a > > system via firewalling techniques. On public systems this may be > > impractical, but it should be limited just the same if possible. > > > > 3. Ensure that all border equipment, such as routers and > > firewalls, is properly configured and you are doing both ingress > > and egress filtering. (See RFC 2267) > > > > 4. On Unix systems, use inetd or possibly Dan Bernstein's > > tcpserver (http://cr.yp.to/ucspi-tcp.html) to limit spawned > > daemon processes. While this will not prevent that particular > > daemon's resources from being over utilized, it is possible to > > prevent daemons from crashing the server. This may allow the > > server to recover. > > > > 5. On systems that have adjustments for various TCP timeouts and > > keepalives, these can be adjusted to potentially allow for > > quicker recovery (assuming that the Naptha attack did not crash > > the system). For example, the TCP keepalive settings on Linux > > 2.2 kernels might help recovery time: > > > > # cat /proc/sys/net/ipv4/tcp_keepalive_time > > 7200 > > # cat /proc/sys/net/ipv4/tcp_keepalive_probes > > 9 > > # cat /proc/sys/net/ipv4/tcp_max_ka_probes > > 5 > > # echo 30 > /proc/sys/net/ipv4/tcp_keepalive_time > > # echo 2 > /proc/sys/net/ipv4/tcp_keepalive_probes > > # echo 100 > /proc/sys/net/ipv4/tcp_max_ka_probes > > > > In the above example the keepalive time is adjusted from 2 hours > > to 30 seconds, and the number of keepalive probes is adjusted > > from 9 to 2. It also adjusts the maximum number of probes sent > > out to be 100 instead of just 5. These are suggested values -- > > real world adjusts will almost certainly be required. > > > > 6. The programs written to demonstrate the attack have been > > released only to the security contacts at OS vendors, through > > CERT. The code will not be released to the public. However, the > > information below will serve as a 'fingerprint' for IDS to > > detect the demonstration code. Please note that the code itself > > could be easily modified to change the fingerprint, so this is > > NOT a failsafe method of detecting a Naptha attack. > > > > IP: > > TOS = Low Delay > > ID = 413 > > TCP: > > FLAGS = SYN > > SEQ ID = 6060842 > > WINDOW = 512 > > > > Snort (http://www.snort.org) is a free lightweight IDS. Here's a > > Snort filter for Naptha: > > > > alert tcp any any <> any any (flags:S; seq: 6060842; > > id: 413; msg: "Naptha DoS Attack, see > > > http://razor.bindview.com//publish/advisories/adv_NAPTHA.html";) > > > > ------------------------------------------------------------------------ > > > > References: > > > > CVE: > > > > The Common Vulnerabilities and Exposures (CVE) project has > > assigned the name CAN-2000-1039 to this issue. This is a > > candidate for inclusion in the CVE list (http://cve.mitre.org), > > which standardizes names for security problems. > > > > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2000-1039 > > > > CERT Advisory: > > > > http://www.cert.org/advisories/CA-2000-21.html > > > > Microsoft's security bulletin: > > > > http://www.microsoft.com/technet/security/bulletin/MS00-091.asp > > > > Microsoft Security Patch: > > > > NT4: > > http://www.microsoft.com/Downloads/Release.asp?ReleaseID=25114 > > > > RFC 2267: > > > > http://www.faqs.org/rfcs/rfc2267.html > > > > "Distributed Denial of Service Defense Tactics" security paper > > > > Author: Simple Nomad > > http://razor.bindview.com/publish/papers/DDSA_Defense.html > > > > "Strategies for Defeating Distributed Attacks" security paper > > > > Author: Simple Nomad > > http://razor.bindview.com/publish/papers/strategies.html > > > > Snort: > > > > http://www.snort.org > > > > Dan Bernstein's tcpserver: > > > > http://cr.yp.to/ucspi-tcp.html > > > > Simson Garfinkel on Process-Table Attack > > > > http://www.securityfocus.com/archive/1/12636 > > > > Stanislav Shulanov's Netkill > > > > http://www.securityfocus.com/archive/1/56462 > > > > Contact: advisory+naptha@razor.bindview.com > > > > Acknowledgements: Mark Loveless and the rest of the RAZOR team. > > > > > > ---------------------------------------------- > > > > > > > > The Naptha DoS vulnerabilities > > "Tested Products" > > > > Note: The RAZOR team has examined > > two TCP states out of many. These > > states are the FIN-WAIT-1 state and > > the ESTABLISHED state. More research > > in this area is underway. We expect > > to find a majority of operating > > systems affected to some extent. > > > > > > > > Vendor Product Vulnerable? TCP state > > Patch/Workaround Available? Notes > > > > Compaq Tru64 UNIX Yes ESTABLISHED No patch or > > workaround available at this time See > > V4.0F See > > Recommendations Notes > > > > FreeBSD FreeBSD Yes ESTABLISHED No patch or > > workaround available at this time See > > 4.0-REL See > > Recommendations Notes > > > > Hewlett-Packard HP-UX 11.00 Yes ESTABLISHED No patch or > > workaround available at this time See > > See > > Recommendations Notes > > > > Microsoft Windows Yes FIN-WAIT-1 Workaround > > available at See > > 95,98,98SE > > http://www.microsoft.com/technet/security/bulletin/MS00-091.asp Notes > > > > Microsoft Windows NT Yes FIN-WAIT-1, Patch > > available at See > > 4.0 SP6a ESTABLISHED > > http://www.microsoft.com/Downloads/Release.asp?ReleaseID=25114 Notes > > > > Microsoft Windows No N/A N/A > > N/A > > 2000 > > > > Novell Netware 5 Yes ESTABLISHED No patch or > > workaround available at this time See > > SP1 See > > Recommendations Notes > > > > SGI IRIX 6.5.7m Yes ESTABLISHED No patch or > > workaround available at this time See > > See > > Recommendations Notes > > > > Sun Solaris 7, Yes ESTABLISHED No patch or > > workaround available at this time See > > 8 See > > Recommendations Notes > > > > > > ------------------------------------------------------------------------ > > > > Notes: > > > > Compaq - Tru64 UNIX V4.0F > > > > Two services were tested, portmapper (tcp > > port 111) and finger (tcp port 79). These > > services were chosen because finger runs > > from inetd and portmapper runs without it. > > > > The Tru64 UNIX kernel appears to be > > somewhat robust against Naptha attacks. > > Sending twenty thousand packets to tcp > > port 111 caused no obvious performance > > degradation on the Tru64 UNIX host > > (except that other attempts to query the > > portmapper became unsuccessful). The > > netstat command showed a steady-state > > value of 4100 ESTABLISHED connections. > > > > Sending a few hundred packets to tcp port > > 79, however, resulted in creation of too > > many finger daemon processes for the > > system to continue normal operation. > > Trying to start a new process from a login > > shell resulted in the error "No more > > processes". It is possible that the finger > > daemon attack would have been less > > effective with a different inetd > > configuration, or with different kernel > > parameters. We did not investigate this. > > > > ------------------------------------------- > > > > FreeBSD - FreeBSD 4.0-REL > > > > In testing FreeBSD, a few specific > > daemons/ports were targeted. For some, the > > stability of the system as a whole can be > > affected. The daemons targeted in this > > testing are not necessarily at fault for > > the problems encountered. > > > > SSH: > > Became unusable after 495 connections to > > the ssh port. Each connection started an > > instance of the daemon which quickly > > exhausted available file handles; the > > system reports "too many open files in > > system". After approximately 30 minutes > > the connections start timing out and the > > system becomes usable again. > > > > NFS: > > Stopped functioning after 964 packets to > > the NFS port. While the rest of the system > > did not seem affected, the connections did > > not time out. > > > > BIND: > > Took 961 TCP connections before the kernel > > reported "file table is full", and TCP > > services failed. UDP DNS seemed > > unaffected. These connections look a long > > time to time out, at least an hour. > > > > Note: These services/ports can be > > similarly affected on other Linux and UNIX > > variants. > > > > ------------------------------------------- > > > > Hewlett-Packard - HP-UX 11.00 > > > > Two services were tested, portmapper and > > telnet. These services were chosen because > > telnet runs from inetd and portmapper runs > > without it. > > > > TELNET: > > HP-UX appears to have some protection. It > > stops responding to Naptha packets after > > several hundred from the same IP address. > > However, until that time it is possible to > > make telnetd respond with; "Telnet device > > drivers missing: No such device". This > > does recover fairly quickly, however. > > > > PORTMAPPER: > > After several hundred Naptha TCP sessions, > > a telnet session to port 111 will > > immediately be disconnected. This broken > > state lingers for much longer than the > > telnet problem. > > > > ------------------------------------------- > > > > Microsoft - Windows 95,98,98SE > > > > Leaving a large number of connections in > > FIN-WAIT-1 causes the NetBIOS and WWW > > services on Microsoft Windows 95, 98, and > > 98SE to fail and not restart. > > > > ------------------------------------------- > > > > Microsoft - Windows NT 4.0 SP6a > > > > Exploiting ESTALISHED states on port 139 > > (netbios-ssn), caused the service to die > > after 1010 packets. Port 135 (loc-srv) > > died after 7929 packets. Interestingly, if > > port 139 had been previously killed by > > Naptha, port 135 died after two packets. > > If the Naptha attack was paused, port 135 > > would recover but be immediately > > unavailable if the Naptha attack was > > resumed. When port 135 died, the CPU > > utilization would eventually jump to 100% > > and remain there until a reboot. > > > > Leaving a large number of connections in > > FIN-WAIT-1 causes the NetBIOS and WWW > > services on Microsoft Windows NT 4.0 to > > fail and not restart. > > > > ------------------------------------------- > > > > Novell - Netware 5 SP1 > > > > Locked up after 3000 open connections on > > port 524, utilized all 64MB of the > > system's RAM, and CPU utilization became > > 100%. The server still had not timed out > > connections and recovered memory after 12 > > hours being left idle. > > > > ------------------------------------------- > > > > SGI - IRIX 6.5.7m > > > > Two services were tested, portmapper (tcp > > port 111) and sgi-dgl (tcp port 5232). > > These services were chosen because sgi-dgl > > runs from inetd and portmapper runs > > without it. > > > > The IRIX kernel appears to be somewhat > > robust against Naptha attacks. Sending > > twenty thousand packets to tcp port 111 > > caused no obvious performance degradation > > on the IRIX host (except that other > > attempts to query the portmapper became > > unsuccessful). The netstat command showed > > a steady-state value of 195 ESTABLISHED > > connections. > > > > Sending a few hundred packets to tcp port > > 5232, however, resulted in creation of too > > many dgl daemon processes for the system > > to continue normal operation. Trying to > > start a new process from a login shell > > resulted in the error "No more processes". > > It is possible that the dgl daemon attack > > would have been less effective with a > > different inetd configuration, or with > > different kernel parameters. We did not > > investigate this. > > > > ------------------------------------------- > > > > Sun - Solaris 7, 8 > > > > Two services were tested, portmapper and > > telnet. These services were chosen because > > telnet runs from inetd and portmapper runs > > without it. > > > > TELNET: > > At around 700 Naptha TCP sessions, a > > telnet session will be connected but then > > gets the message "can't grant slave pty" > > and is disconnected. At 1700 Naptha TCP > > sessions, a telnet session will be > > connected but nothing else happens. This > > is not confined to the telnet port, it > > effects every port. If the Naptha attack > > is stopped, eventually telnet will > > recover. How long it is broken is > > dependant on the speed and length of the > > Naptha assault and other factors. A > > typical downtime was an hour. > > > > PORTMAPPER: > > At around 300 Naptha TCP sessions, a > > telnet session to port 111 is immediately > > disconnected (normally, this is > > disconnected when a user hit the enter > > key). This fault does not effect other > > services. Downtime variable but typically > > two hours. > > > > ------------------------------------------- > > > > Contact: advisory+naptha@razor.bindview.com > > > > _____________________________________________________________________ > > ** TO UNSUBSCRIBE, send the command "UNSUBSCRIBE win2ksecadvice" > > ** FOR A WEEKLY DIGEST, send the command "SET win2ksecadvice DIGEST" > > SEND ALL COMMANDS TO: listserv@listserv.ntsecurity.net > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > -- work: dga@lcs.mit.edu me: dga@pobox.com MIT Laboratory for Computer Science http://www.angio.net/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 4 16:46:25 2000 From owner-freebsd-security@FreeBSD.ORG Mon Dec 4 16:46:23 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from alpha.simphost.com (unknown [216.253.163.10]) by hub.freebsd.org (Postfix) with ESMTP id 14A8637B400 for ; Mon, 4 Dec 2000 16:46:23 -0800 (PST) Received: by alpha.simphost.com (Postfix, from userid 1060) id B240E66B0A; Mon, 4 Dec 2000 17:46:30 -0700 (MST) Received: from localhost (localhost [127.0.0.1]) by alpha.simphost.com (Postfix) with ESMTP id A967A62D03; Mon, 4 Dec 2000 17:46:30 -0700 (MST) Date: Mon, 4 Dec 2000 17:46:30 -0700 (MST) From: "Jonathan M. Slivko" To: GalaxyFree Cc: FreeBSD-security@FreeBSD.org, abuse@galaxyfree.com Subject: Re: Hacker Warning In-Reply-To: <20001204172914.CB88237B401@hub.freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Now this is what I call spamming! Please DO NOT spam this list again, or I will call your uplink and have you pulled. Thank You. -- Jonathan M. Slivko ---- Jonathan M. Slivko Technical Support, CoreSync Corporation (http://www.coresync.net) Team Leader, SecureIRC Project (http://secureirc.sourceforge.net) Pager/Voicemail: (917) 388-5304 ---- On Mon, 4 Dec 2000, GalaxyFree wrote: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 4 16:49:36 2000 From owner-freebsd-security@FreeBSD.ORG Mon Dec 4 16:49:34 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id A21C537B400 for ; Mon, 4 Dec 2000 16:49:34 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eB50nWg78677; Mon, 4 Dec 2000 16:49:32 -0800 (PST) (envelope-from dillon) Date: Mon, 4 Dec 2000 16:49:32 -0800 (PST) From: Matt Dillon Message-Id: <200012050049.eB50nWg78677@earth.backplane.com> To: "David G. Andersen" Cc: JHowie@msn.com (John Howie), freebsd-security@FreeBSD.ORG Subject: Re: Fw: NAPTHA Advisory Updated - BindView RAZOR References: <200012050043.RAA27046@faith.cs.utah.edu> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :This isn't a FreeBSD failure per se, but a resource control :failure. Whether you want to point a finger at FreeBSD, ssh, or the :operator of the box is entirely up to you. :-) : I was under the impression that you could limit ssh's connection acceptance rate in sshd_config. # Rate-limit sshd connections to 5 connections per 10 seconds ConnectionsPerPeriod 5/10 Not only that, but it's turned on by default. You can also do the same thing with services run from inetd with appropriate options to inetd. It isn't perfect, but it should be sufficient. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 4 16:53:52 2000 From owner-freebsd-security@FreeBSD.ORG Mon Dec 4 16:53:51 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id 5524237B400 for ; Mon, 4 Dec 2000 16:53:51 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eB50rpT78744; Mon, 4 Dec 2000 16:53:51 -0800 (PST) (envelope-from dillon) Date: Mon, 4 Dec 2000 16:53:51 -0800 (PST) From: Matt Dillon Message-Id: <200012050053.eB50rpT78744@earth.backplane.com> To: Matt Dillon Cc: "David G. Andersen" , JHowie@MSN.com (John Howie), freebsd-security@FreeBSD.ORG Subject: Re: Fw: NAPTHA Advisory Updated - BindView RAZOR References: <200012050043.RAA27046@faith.cs.utah.edu> <200012050049.eB50nWg78677@earth.backplane.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I think the NFS attack mentioned at the end of the report is more of a concern, though typically NFS ports are not left open to the world. NFS currently has no timeouts whatsoever for TCP connections. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 4 17: 5:14 2000 From owner-freebsd-security@FreeBSD.ORG Mon Dec 4 17:05:11 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from rly-ip01.mx.aol.com (rly-ip01.mx.aol.com [205.188.156.49]) by hub.freebsd.org (Postfix) with ESMTP id 84BD337B6B6 for ; Mon, 4 Dec 2000 17:05:07 -0800 (PST) Received: from tot-mtc-tc.proxy.aol.com (tot-mtc-tc.proxy.aol.com [64.12.105.131]) by rly-ip01.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0) with ESMTP id UAA14870; Mon, 4 Dec 2000 20:05:01 -0500 (EST) Received: from pavilion (ACAF23B5.ipt.aol.com [172.175.35.181]) by tot-mtc-tc.proxy.aol.com (8.10.0/8.10.0) with SMTP id eB514wu23942; Mon, 4 Dec 2000 20:04:58 -0500 (EST) Message-ID: <012c01c05e57$617fb920$0101a8c0@pavilion> From: "Richard Ward" To: Cc: References: Subject: Re: Hacker Warning Date: Mon, 4 Dec 2000 20:04:53 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Apparently-From: Nis8840@aol.com Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Spam is not only extremely illegal, but is the number 3 reason that makes the Internet not worth being on now-a-days. The other two being DoS and new corrupt laws coming in to play. I have already gotten two half-assed wireless/cellular companies taken to court over them spaming my 24/7 fax line, and we've won both times because spam is wrong. Email, Fax, Snail Mail, etc.. none the less wrong, too. I highly suggest you put a halt to spaming this mailing list, many angry network administrators are most likely already plotting your death; myself included. Cheers. -- Richard Ward, Founder Neonsky Internet Services http://www.neonsky.net ----- Original Message ----- From: Jonathan M. Slivko To: GalaxyFree Cc: ; Sent: Monday, December 04, 2000 7:46 PM Subject: Re: Hacker Warning > Now this is what I call spamming! Please DO NOT spam this list again, or I > will call your uplink and have you pulled. Thank You. > > -- Jonathan M. Slivko > > ---- > Jonathan M. Slivko > Technical Support, CoreSync Corporation (http://www.coresync.net) > Team Leader, SecureIRC Project (http://secureirc.sourceforge.net) > Pager/Voicemail: (917) 388-5304 > ---- > > On Mon, 4 Dec 2000, GalaxyFree wrote: > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 4 17: 9: 3 2000 From owner-freebsd-security@FreeBSD.ORG Mon Dec 4 17:09:00 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from sunny.pacific.net.sg (sunny.pacific.net.sg [203.120.90.127]) by hub.freebsd.org (Postfix) with ESMTP id 0D8FD37B400 for ; Mon, 4 Dec 2000 17:08:59 -0800 (PST) Received: from pop2.pacific.net.sg (pop2.pacific.net.sg [203.120.90.86]) by sunny.pacific.net.sg with ESMTP id eB518uo21707; Tue, 5 Dec 2000 09:08:56 +0800 (SGT) Received: from gchang (spoff250.pacific.net.sg [203.120.94.250]) by pop2.pacific.net.sg with SMTP id JAA05045; Tue, 5 Dec 2000 09:08:55 +0800 (SGT) Message-ID: <010301c05e57$8e8943a0$fa5e78cb@gchang> From: "James Lim" To: "Richard Ward" , Cc: References: <012c01c05e57$617fb920$0101a8c0@pavilion> Subject: Re: Hacker Warning Date: Tue, 5 Dec 2000 09:06:10 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org To Hell with spam. I take the freebsd* mailing lists to be a "place" to learn. Spamming is definately not tolerated. =] James Lim Technical Support Executive Pacific Internet Limited 89 Science Park Drive #02-05/06 The Rutherford Singapore 118261 Finger evilfry@sg.freebsd.org for PGP key. ----- Original Message ----- From: "Richard Ward" To: Cc: Sent: Tuesday, December 05, 2000 9:04 AM Subject: Re: Hacker Warning > Spam is not only extremely illegal, but is the number 3 reason that makes > the Internet not worth being on now-a-days. The other two being DoS and new > corrupt laws coming in to play. I have already gotten two half-assed > wireless/cellular companies taken to court over them spaming my 24/7 fax > line, and we've won both times because spam is wrong. Email, Fax, Snail > Mail, etc.. none the less wrong, too. I highly suggest you put a halt to > spaming this mailing list, many angry network administrators are most likely > already plotting your death; myself included. Cheers. > -- > Richard Ward, Founder > Neonsky Internet Services > http://www.neonsky.net > > ----- Original Message ----- > From: Jonathan M. Slivko > To: GalaxyFree > Cc: ; > Sent: Monday, December 04, 2000 7:46 PM > Subject: Re: Hacker Warning > > > > Now this is what I call spamming! Please DO NOT spam this list again, or I > > will call your uplink and have you pulled. Thank You. > > > > -- Jonathan M. Slivko > > > > ---- > > Jonathan M. Slivko > > Technical Support, CoreSync Corporation (http://www.coresync.net) > > Team Leader, SecureIRC Project (http://secureirc.sourceforge.net) > > Pager/Voicemail: (917) 388-5304 > > ---- > > > > On Mon, 4 Dec 2000, GalaxyFree wrote: > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-security" in the body of the message > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 4 17:22: 3 2000 From owner-freebsd-security@FreeBSD.ORG Mon Dec 4 17:22:01 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from secure.smtp.email.msn.com (cpimssmtpu07.email.msn.com [207.46.181.28]) by hub.freebsd.org (Postfix) with ESMTP id 1E7B537B401 for ; Mon, 4 Dec 2000 17:22:01 -0800 (PST) Received: from x86nts4 - 216.103.48.12 by email.msn.com with Microsoft SMTPSVC; Mon, 4 Dec 2000 17:22:00 -0800 Message-ID: <011701c05e5a$bcfb3060$fd01a8c0@pacbell.net> From: "John Howie" To: "David G. Andersen" Cc: References: <200012050043.RAA27046@faith.cs.utah.edu> Subject: Re: Fw: NAPTHA Advisory Updated - BindView RAZOR Date: Mon, 4 Dec 2000 17:28:57 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1800 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1800 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org David Andersen wrote: > This isn't a FreeBSD failure per se, but a resource control > failure. Whether you want to point a finger at FreeBSD, ssh, or the > operator of the box is entirely up to you. :-) > I'm afraid I disagree - this is not purely a daemon problem. I wonder if you had time to read the whole advisory for the FreeBSD information near the end of the report (I've included it below). > > > ------------------------------------------- > > > > > > FreeBSD - FreeBSD 4.0-REL > > > > > > In testing FreeBSD, a few specific > > > daemons/ports were targeted. For some, the > > > stability of the system as a whole can be > > > affected. The daemons targeted in this > > > testing are not necessarily at fault for > > > the problems encountered. > > > > > > SSH: > > > Became unusable after 495 connections to > > > the ssh port. Each connection started an > > > instance of the daemon which quickly > > > exhausted available file handles; the > > > system reports "too many open files in > > > system". After approximately 30 minutes > > > the connections start timing out and the > > > system becomes usable again. > > > > > > NFS: > > > Stopped functioning after 964 packets to > > > the NFS port. While the rest of the system > > > did not seem affected, the connections did > > > not time out. > > > > > > BIND: > > > Took 961 TCP connections before the kernel > > > reported "file table is full", and TCP > > > services failed. UDP DNS seemed > > > unaffected. These connections look a long > > > time to time out, at least an hour. > > > > > > Note: These services/ports can be > > > similarly affected on other Linux and UNIX > > > variants. > > > > > > ------------------------------------------- If a daemon becomes unusable because it is subject to attack then that is, while not ideal, at least tolerable. When the whole system becomes unusable that points to problems in the kernel. Note that the tone of the report seems to imply that this kind of attack is new, it is not. It has been around for some time but not widely employed. All it took was for someone 'not in the know' to re-discover and publicize how the attack could be carried out without crippling the attacker's machine too. I first came across this kind of attack in 1991 and I am sure that it has been demonstrated in practice long before that. john... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 4 17:24:54 2000 From owner-freebsd-security@FreeBSD.ORG Mon Dec 4 17:24:52 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from backup.af.speednet.com.au (af.speednet.com.au [202.135.188.244]) by hub.freebsd.org (Postfix) with ESMTP id 627EF37B400 for ; Mon, 4 Dec 2000 17:24:50 -0800 (PST) Received: from backup.af.speednet.com.au (backup.af.speednet.com.au [172.22.2.4]) by backup.af.speednet.com.au (8.11.1/8.11.1) with ESMTP id eB51NWF47753; Tue, 5 Dec 2000 12:23:34 +1100 (EST) (envelope-from andyf@speednet.com.au) Date: Tue, 5 Dec 2000 12:23:32 +1100 (EST) From: Andy Farkas X-Sender: andyf@backup.af.speednet.com.au To: Chris Wasser Cc: "Roberto Samarone Araujo (RSA)" , freebsd-security@FreeBSD.ORG Subject: Re: FreeBSD security check --footnote In-Reply-To: <20001204054219.D7848@skunkworks.area51-arpa.mil> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 4 Dec 2000, Chris Wasser wrote: > ... but rather redirect all mail for > root@yourhost.com to useraccount@yourhost.com (or elsewhere) using your > mailing system You _should_ be able to send the output of periodic scripts to any user by setting ${daily|weekly|mothly}_output in your /etc/periodic.conf file. See http://www.freebsd.org/cgi/query-pr.cgi?pr=22150 -- :{ andyf@speednet.com.au Andy Farkas System Administrator Speednet Communications http://www.speednet.com.au/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 4 17:25:12 2000 From owner-freebsd-security@FreeBSD.ORG Mon Dec 4 17:25:07 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id A3A3737B400 for ; Mon, 4 Dec 2000 17:25:07 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eB51P7l25536 for security@freebsd.org; Mon, 4 Dec 2000 17:25:07 -0800 (PST) Date: Mon, 4 Dec 2000 17:25:07 -0800 From: Alfred Perlstein To: security@freebsd.org Subject: NAPTHA/RAZOR response. Message-ID: <20001204172505.D8051@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: bright@fw.wintelcom.net Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ok, I can't believe what a bunch of hosers these RAZOR/bindview guys are, thier "advisory" is nothing new, there was a news article about 3 years ago talking about this problem, all that RAZOR seems to have done is find a pretty lame and broken way of spoofing the source of the attack which doesn't really work. (it's trivial to find the source of the attack) Way to go being a bunch of attention grabbing lemurs guys, congrats on the ZDnet article! So on with my own response 'advisory', enjoy: fear**fear**fear**fear**fear**fear**fear**fear**fear**fear**fear**fear**fear ________ _______ ____________. .______ __________ _______ / | | .' \| | \ fear**/ | | : \ | \**fear / | | _______| | | \ / | | > / | \ .' | | : / | \ | | | ____| / | | | : | | | . / ______) | | | | | | | < | | | | | | | \ | | | | | | | | |\ \ | | | | |______:___ | \ \ ______) | f| | | ) | \ \ | |ear | Perlstein | /. | \ \ | | (______)_______)_______________/ |______| (______)_______|__________/ fear**fear**fear**fear**fear**fear**fear**fear**fear**fear**fear**fear**fear [ Dayam where's the sploitz at? ] [ Sploit...... NAPTHA 1.2 ] [ Dumbasses responsible...... RAZOR ] [ Analysis by..... Alfred Perlstein ] _________.. . . | : Summary ' RAZOR noticed that when you create a lot of connections to a service you effectively cause the remote side to fork bomb and/or consume resources waiting for the connections to time out. By slowly trickling expected ACKs back to the application/server one can also keep a lot of resources tied down in both the application and kernel levels. RAZOR wasn't the first bunch of tools to notice this effect, amazingly this effect is seen by a lot of first year computer science students when they take their first network programming class. What RAZOR doesn't seem to clue in on, or just pretends that it's not a big deal is that this attack requires local ethernet access to be spoofed . otherwise unless the victim OS has easy to predict TCP sequence numbers.. ...the attacker must reveal the source of the attack (his IP). : | .........____| _________.. . . | : Exploit (abstract) ' When NAPTHA is deployed remotely one can simply use tcpdump to figure the source location of the DoS. When NAPTHA is deployed locally using ARP tricks to hide one's IP one can simply log onto local switches and view the ARP cache to discover the source. After finding the source of the attack you'll need: 1) a crowbar 2) some duct tape 3) a gerbil Use 1 (the crowbar) to break the offender's legs and arms, then apply 2 (the duct tape) to offender, we'll leave the use of item 3 (the gerbil) to your imagination, I'm sure you'll figure it out. : | .........____| _________.. . . | : Workaround ' Drop idle connections faster and deal with resource shortages gracefully. (duh!) : | .........____| _________.. . . | : Shoutouts to: ' halah (u rul3 m3 b4by), j4mes, ps, pm (just kidding, n0 gr33t 4u), jba (el8warez 4 u) and jkh (journey rulez) Big :P go to: RAZOR (one word: lame) CERT (why'd you guys release this junk?) . SIIG (th3s3 h0s3rz package different chipsets in the same boxes) : billf@efnet (d00d, where's my O: ?) | This advisory crafted with vim, damn i miss TheDraw :/ .........____| *narf* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 4 17:31: 0 2000 From owner-freebsd-security@FreeBSD.ORG Mon Dec 4 17:30:56 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from secure.smtp.email.msn.com (cpimssmtpu07.email.msn.com [207.46.181.28]) by hub.freebsd.org (Postfix) with ESMTP id 9D81337B402 for ; Mon, 4 Dec 2000 17:30:55 -0800 (PST) Received: from x86nts4 - 216.103.48.12 by email.msn.com with Microsoft SMTPSVC; Mon, 4 Dec 2000 17:30:55 -0800 Message-ID: <012f01c05e5b$fb9450d0$fd01a8c0@pacbell.net> From: "John Howie" To: Subject: Fw: IDIOT Date: Mon, 4 Dec 2000 17:37:51 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1800 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1800 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org To the cowardly subscriber of this list who sent me the following email from an anonymous account I'd like to point out that MSN stands for the Microsoft Network and does not mean that I work for, or endorse, Microsoft or its products. The fact that I use them is irrelevant. I posted the original email about the BindView advisory as it *clearly* affects FreeBSD, which I happen to run on an AlphaStation - but that, too, is irrelevant. I also won't point out the nearly two decades of UNIX experience that I have, or my kernel development experience. What I will say is that the coward who sent me this should stand up for his convictions and face me from a real email address and allow our peers to decide. To everyone else on the list, I apologize for taking up bandwidth. john... ----- Original Message ----- From: To: Sent: Monday, December 04, 2000 4:59 PM Subject: IDIOT > Seriously dude. Your an idiot... this whole bindview is well > beyond something you can realistically hope to understand. > > All you see, or atleast you think you see is that it doens't effect > yoru dos, and effects others. Well lets talk about the counterless > other fucking millions of exploits that are windows specific. > > realistically speaking, msft is the biggest joke when it comes to security of > all time. > > And to be honest, windows2000 is not invulernable. It's only invulnerable > in regards to smb. Octopus style attacks (which bindview soo moronically > reinvented) have been around for a long time. Which is why most software > contains max connections. On other services like exchange, it's VERY > vulnerable. OFcourse I doubt you even understand what I'm talking about. > > The freebsd box in bindview's test had that option DISABLED. Meaning it wasn't > even a default install. This is yet another mindcraft, FIX... How sad, how > pathetic and how silly that an idiot such as yourself would even dare believe > something. Ahh I saw it online, in a microsoft mailing list, it MUST BE TRUE. > Cause windows2000 is soo well engineered, those 2000 chimps did such a good job > on the gui... oh yeah and those 3 guys working on the networking stuff... they > did good too! I GOT MY MCSE, LOOK AT ME!!!!!!!! > > Chances are your going to have to learn unix, if you wanna stay a systems > administrator. Thou I hear there are alot of helpdesk opennings. > > Face it... your a bitch... And a dumb one. > > MaxStartups is DEFAULT in freebsd release 4.0 within /etc/ssh/sshd_config > check your facts fuck. > > This is probably all over your head... So just sit happily in your little > world, resting assured in the fact that you dont have to learn anything new and > that your trival knowledge in a mickeymouse os will get you through life. > > Microsoft makes great os's for people who can't code, or are too stupid to ever > wanna understand what's happening under the broken ass gui. > > Oh that reminds me.... enjoy your next virus, you clearly deserve it. > > PS: this is one of those 'freebie' email accounts, dont > bother. > > --------------------------------------------- > This message was sent using Ottawa Online Mailbag. > http://www.ottawaonline.com > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 4 17:38:23 2000 From owner-freebsd-security@FreeBSD.ORG Mon Dec 4 17:38:19 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from faith.cs.utah.edu (faith.cs.utah.edu [155.99.198.108]) by hub.freebsd.org (Postfix) with ESMTP id 9170037B401 for ; Mon, 4 Dec 2000 17:38:18 -0800 (PST) Received: (from danderse@localhost) by faith.cs.utah.edu (8.9.3/8.9.3) id SAA03007; Mon, 4 Dec 2000 18:38:15 -0700 (MST) Message-Id: <200012050138.SAA03007@faith.cs.utah.edu> Subject: Re: [spam score 10.00/10.0 -pobox] Re: Fw: NAPTHA Advisory Updated - BindView RAZOR To: JHowie@msn.com (John Howie) Date: Mon, 4 Dec 2000 18:38:15 -0700 (MST) Cc: dga@pobox.com (David G. Andersen), freebsd-security@FreeBSD.ORG In-Reply-To: <011701c05e5a$bcfb3060$fd01a8c0@pacbell.net> from "John Howie" at Dec 04, 2000 05:28:57 PM From: "David G. Andersen" X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: danderse@cs.utah.edu Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Lo and behold, John Howie once said: > > I'm afraid I disagree - this is not purely a daemon problem. I wonder if you > had time to read the whole advisory for the FreeBSD information near the end > of the report (I've included it below). > > > > affected. The daemons targeted in this > > > > testing are not necessarily at fault for > > > > the problems encountered. That's where there may be some disagreement. I personally feel that a base system should provide more resource isolation between daemons than FreeBSD, Linux, and most other operating systems do, but that's a matter of opinion. ;-) > > > > NFS: > > > > Stopped functioning after 964 packets to > > > > the NFS port. While the rest of the system > > > > did not seem affected, the connections did > > > > not time out. This is the same problem as with SSH. > > > > BIND: > > > > Took 961 TCP connections before the kernel > > > > reported "file table is full", and TCP > > > > services failed. UDP DNS seemed > > > > unaffected. These connections look a long > > > > time to time out, at least an hour. Unsurprising that UDP DNS was unaffected. There's no way for an attacker to connect and say, "Oh, hang on, I'll send you the rest of that in a bit." > If a daemon becomes unusable because it is subject to attack then that is, > while not ideal, at least tolerable. When the whole system becomes unusable > that points to problems in the kernel. Nope. It wasn't a kernel problem you were encountering - it was a systemwide resource limit being reached. It's not that there's a _bug_ in the kernel, it's that the processes file table limits weren't isolated from each other. The right solution to this is more isolation of different processes (e.g. resource control). Like I said above: This isn't a bug in the sense of "a bad implementation" so much as a question of how the resource control can be done. As the advisory itself points out, this can be fixed by: a) Fixing the daemons to rate- and connection-limit themselves. b) Using tcpwrappers to do the above c) Providing a general, happy OS mechanism to provide resource controls at a fine granularity between applications. You can probably figure out which of these I think is the best solution, but just in case, I'll give you a hint: (c). Not many operating systems do this these days; see the maybe-about-to-be-released Flask kernel (NSA/TIS) for an example of a great way to do it. Of course, the problem is really more interesting than I've let on to so far: What one _really_ wants to do is start rate-limiting some clients without affecting the others (e.g. at an OS level, I can easily protect NFS from SSH, but I want to protect good web clients from the bad). That's where both RW's stuff and some networks research comes in; either use less state and be better about cleaning up (RW), or automatically stuff the "bad" clients in separate resource containers (see "Resource Containers" by Pai et al. at Rice). I don't propose that this is a functioning solution yet. > too. I first came across this kind of attack in 1991 and I am sure that it > has been demonstrated in practice long before that. Of course. It's just slicker version of: while (1) telnet www.foo.org 80 > /dev/null & ... I probably needn't bother pointing out that: a) It could be made better (exercise left to the reader; please don't.) b) It's fairly easy to detect and defend against a particular attacker because it requires the use of identifiable and relatively static IP addresses (blocking a few /16s would likely fix any given victim's problems for a while) The same problem has been seen before: - Syn floods - IP Fragmentation attacks (jolt) - ... I kinda like this one because it takes the attacks back into the arena where it affects actual servers (a more sophisticated attack could, for instance, cause a server to allocate even more resources; with sendmail, for instance, you might get more memory waste if you start sending a the DATA portion and then hang the connection, and so on). It's a nice reminder that the applications matter as well as the OS. -Dave -- work: dga@lcs.mit.edu me: dga@pobox.com MIT Laboratory for Computer Science http://www.angio.net/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 4 18: 5:17 2000 From owner-freebsd-security@FreeBSD.ORG Mon Dec 4 18:05:15 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from box29.westin33.flyingcroc.net (box29.westin33.flyingcroc.net [207.246.151.29]) by hub.freebsd.org (Postfix) with ESMTP id 16ABB37B400 for ; Mon, 4 Dec 2000 18:05:15 -0800 (PST) Received: from localhost (michael@localhost) by box29.westin33.flyingcroc.net (8.9.3/8.9.3) with ESMTP id SAA01846 for ; Mon, 4 Dec 2000 18:05:48 -0800 X-Authentication-Warning: box29.westin33.flyingcroc.net: michael owned process doing -bs Date: Mon, 4 Dec 2000 18:05:48 -0800 (PST) From: Michael Haney X-Sender: michael@box29.westin33.flyingcroc.net To: freebsd-security@FreeBSD.ORG Subject: LDAP module for PAM authentication. In-Reply-To: <200012050138.SAA03007@faith.cs.utah.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'd like to know if anyone has implemented the pam_ldap module and turned authentication over to this directory service. I'm installing OpenLDAP on a FreeBSD 4.2 machine, and the PAM clients will be FreeBSD 3.2-4.1.1 boxes, and some NT boxes. I'd like to know how well this works as a replacement to NIS and how it might be secured, either using SSL or Kerberos tickets or some other encryption wrapper, like over an ssh tunnel. Has anyone implemented other solutions to combine NT, Exchange and Unix logins across a network? I'm looking for an easy to manage central user database that will allow a user to login to various boxes on our net, regardless of their OS, and use the same password and/or certificate to authenticate. LDAP seems to be the way to go, and I'd sure appreciate any suggestions about whether or not this works or what else might. thanks, -michael To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 4 18: 9:10 2000 From owner-freebsd-security@FreeBSD.ORG Mon Dec 4 18:09:02 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mail.epylon.com (sf-gw.epylon.com [63.93.9.98]) by hub.freebsd.org (Postfix) with ESMTP id 521B637B400 for ; Mon, 4 Dec 2000 18:09:02 -0800 (PST) Received: by pluto.epylon.lan with Internet Mail Service (5.5.2650.21) id ; Mon, 4 Dec 2000 18:09:02 -0800 Message-ID: <657B20E93E93D4118F9700D0B73CE3EA0242E9@goofy.epylon.lan> From: Jason DiCioccio To: 'John Howie' , freebsd-security@FreeBSD.ORG Subject: RE: IDIOT Date: Mon, 4 Dec 2000 18:09:00 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C05E60.55F89B22" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C05E60.55F89B22 Content-Type: text/plain; charset="iso-8859-1" -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yes, his reply was indeed uncalled for.. And especially from an anonymous email address, he must've known that it was, which leads me to beleive that he won't admit to it. - -JD- - ------- Jason DiCioccio Evil Genius Unix BOFH mailto:jasond@epylon.com 415-593-2761 Direct & Fax 415-593-2900 Main Epylon Corporation 645 Harrison Street, Suite 200 San Francisco, CA 94107 www.epylon.com BSD is for people who love Unix - Linux is for people who hate Microsoft - -----Original Message----- From: John Howie [mailto:JHowie@msn.com] Sent: Monday, December 04, 2000 5:38 PM To: freebsd-security@FreeBSD.ORG Subject: Fw: IDIOT To the cowardly subscriber of this list who sent me the following email from an anonymous account I'd like to point out that MSN stands for the Microsoft Network and does not mean that I work for, or endorse, Microsoft or its products. The fact that I use them is irrelevant. I posted the original email about the BindView advisory as it *clearly* affects FreeBSD, which I happen to run on an AlphaStation - but that, too, is irrelevant. I also won't point out the nearly two decades of UNIX experience that I have, or my kernel development experience. What I will say is that the coward who sent me this should stand up for his convictions and face me from a real email address and allow our peers to decide. To everyone else on the list, I apologize for taking up bandwidth. john... - ----- Original Message ----- From: To: Sent: Monday, December 04, 2000 4:59 PM Subject: IDIOT > Seriously dude. Your an idiot... this whole bindview is well > beyond something you can realistically hope to understand. > > All you see, or atleast you think you see is that it doens't effect > yoru dos, and effects others. Well lets talk about the counterless > other fucking millions of exploits that are windows specific. > > realistically speaking, msft is the biggest joke when it comes to > security of > all time. > > And to be honest, windows2000 is not invulernable. It's only > invulnerable in regards to smb. Octopus style attacks (which > bindview soo moronically reinvented) have been around for a long > time. Which is why most software contains max connections. On > other services like exchange, it's VERY vulnerable. OFcourse I > doubt you even understand what I'm talking about. > > The freebsd box in bindview's test had that option DISABLED. > Meaning it wasn't > even a default install. This is yet another mindcraft, FIX... How > sad, how > pathetic and how silly that an idiot such as yourself would even > dare believe > something. Ahh I saw it online, in a microsoft mailing list, it > MUST BE TRUE. > Cause windows2000 is soo well engineered, those 2000 chimps did > such a good job > on the gui... oh yeah and those 3 guys working on the networking > stuff... they > did good too! I GOT MY MCSE, LOOK AT ME!!!!!!!! > > Chances are your going to have to learn unix, if you wanna stay a > systems administrator. Thou I hear there are alot of helpdesk > opennings. > > Face it... your a bitch... And a dumb one. > > MaxStartups is DEFAULT in freebsd release 4.0 within > /etc/ssh/sshd_config check your facts fuck. > > This is probably all over your head... So just sit happily in your > little world, resting assured in the fact that you dont have to > learn anything new and > that your trival knowledge in a mickeymouse os will get you through > life. > > Microsoft makes great os's for people who can't code, or are too > stupid to ever > wanna understand what's happening under the broken ass gui. > > Oh that reminds me.... enjoy your next virus, you clearly deserve > it. > > PS: this is one of those 'freebie' email accounts, dont > bother. > > --------------------------------------------- > This message was sent using Ottawa Online Mailbag. > http://www.ottawaonline.com > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.8 for non-commercial use iQA/AwUBOixOZ1CmU62pemyaEQJjkACeJRDjNBc+A3Z8/hmyFogZsXoofOcAn1SX sGQflQbsSe+XxChXhAqUbL13 =bItY -----END PGP SIGNATURE----- ------_=_NextPart_000_01C05E60.55F89B22 Content-Type: application/octet-stream; name="Jason DiCioccio.vcf" Content-Disposition: attachment; filename="Jason DiCioccio.vcf" BEGIN:VCARD VERSION:2.1 N:DiCioccio;Jason FN:Jason DiCioccio ORG:epylon.com;operations TITLE:UNIX ADMIN ADR;WORK:;;645 Harrison St;San Francisco;CA;94107;usa LABEL;WORK;ENCODING=QUOTED-PRINTABLE:645 Harrison St=0D=0ASan Francisco, CA 94107=0D=0Ausa EMAIL;PREF;INTERNET:Jason.DiCioccio@Epylon.com REV:19990105T135529Z END:VCARD ------_=_NextPart_000_01C05E60.55F89B22-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 4 18:11: 3 2000 From owner-freebsd-security@FreeBSD.ORG Mon Dec 4 18:10:59 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from secure.smtp.email.msn.com (cpimssmtpu07.email.msn.com [207.46.181.28]) by hub.freebsd.org (Postfix) with ESMTP id 231E737B400 for ; Mon, 4 Dec 2000 18:10:59 -0800 (PST) Received: from x86nts4 - 216.103.48.12 by email.msn.com with Microsoft SMTPSVC; Mon, 4 Dec 2000 18:10:58 -0800 Message-ID: <014a01c05e61$944b37d0$fd01a8c0@pacbell.net> From: "John Howie" To: "David G. Andersen" Cc: "David G. Andersen" , References: <200012050138.SAA03007@faith.cs.utah.edu> Subject: Re: [spam score 10.00/10.0 -pobox] Re: Fw: NAPTHA Advisory Updated - BindView RAZOR Date: Mon, 4 Dec 2000 18:17:55 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1800 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1800 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org David G. Andersen wrote: > Lo and behold, John Howie once said: > > > > I'm afraid I disagree - this is not purely a daemon problem. I wonder if you > > had time to read the whole advisory for the FreeBSD information near the end > > of the report (I've included it below). > > > > > > affected. The daemons targeted in this > > > > > testing are not necessarily at fault for > > > > > the problems encountered. > > That's where there may be some disagreement. I personally feel that a > base system should provide more resource isolation between daemons than > FreeBSD, Linux, and most other operating systems do, but that's a matter > of opinion. ;-) > Actually I don't believe that we are too far off the mark on this one. The concept of providing each isolated server process a virtual OS to run in is a good idea, and one worth investigating further. If a process exhausts its allocated resources in its virtual OS the rest of the system runs unaffected. Makes other aspects of security easier too. > > Unsurprising that UDP DNS was unaffected. There's no way for an > attacker to connect and say, "Oh, hang on, I'll send you the rest of that > in a bit." > I cut and pasted the whole section but you are right, I should have commented on this one - UDP being stateless would not be affected. > > If a daemon becomes unusable because it is subject to attack then that is, > > while not ideal, at least tolerable. When the whole system becomes unusable > > that points to problems in the kernel. > > Nope. It wasn't a kernel problem you were encountering - it was a > systemwide resource limit being reached. It's not that there's a _bug_ in > the kernel, it's that the processes file table limits weren't isolated > from each other. The right solution to this is more isolation of > different processes (e.g. resource control). > Another possibility which would work in some resource-depletion situations is the keeping of some kernel-only resources so no matter what happens in user-land the OS is able to carry on and do its work, even if user-land is hosed. I do not believe that would be applicable here, however. > > You can probably figure out which of these I think is the best > solution, but just in case, I'll give you a hint: (c). Not many > operating systems do this these days; see the maybe-about-to-be-released > Flask kernel (NSA/TIS) for an example of a great way to do it. > Agreed. > Of course, the problem is really more interesting than I've let on to so > far: What one _really_ wants to do is start rate-limiting some clients > without affecting the others (e.g. at an OS level, I can easily protect > NFS from SSH, but I want to protect good web clients from the > bad). Two models that I came across several years ago actually might have a solution, although neither were proposed as solutions for security problems - they were intended to handle bursts of data. The first, and this sounded daft at the time, was to employ a "market economy" type of network communication, whereby clients and servers could barter with each other for access to services. A client that "saved" its connection resources either by not sending data, or doing so at a low priority, could then use its banked credits to send high bursts of data or it could negotiate with another client or server to sell its credits. It was claimed that the pattern that emerged allowed most, but not all, clients and servers equal access to resources on an as-needed basis. I must confess I only read a paper on this and can't remember much more. The second approach used a heuristic learning model to look for bursts of activity and throttle back connections until OS resources could be allocated. Such a model would be the basis of today's IDS. john... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 4 18:29:35 2000 From owner-freebsd-security@FreeBSD.ORG Mon Dec 4 18:29:33 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from ariel.efis.ucr.ac.cr (ariel.efis.ucr.ac.cr [163.178.110.206]) by hub.freebsd.org (Postfix) with ESMTP id 4A1F437B401 for ; Mon, 4 Dec 2000 18:29:26 -0800 (PST) Received: from localhost (jmejia@localhost) by ariel.efis.ucr.ac.cr (8.9.3/8.9.3) with ESMTP id UAA65552; Mon, 4 Dec 2000 20:29:00 -0600 (CST) Date: Mon, 4 Dec 2000 20:29:00 -0600 (CST) From: =?X-UNKNOWN?Q?JImmy_M=2E_Fern=E1ndez=2E?= To: John Howie Cc: freebsd-security@FreeBSD.ORG Subject: Re: Fw: IDIOT In-Reply-To: <012f01c05e5b$fb9450d0$fd01a8c0@pacbell.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 4 Dec 2000, John Howie wrote: > To the cowardly subscriber of this list who sent me the following email from ...blah..blah...blah and ... > > Seriously dude. Your an idiot... this whole bindview is well > > beyond something you can realistically hope to understand. blah blah blah... It is patetic how much energy some peple can spend ofending other people, I know, it is very easy to take a keyboard behind a computer and to write a dirty letter to someone who does not have any chance for to do nothing. People like this guy who wrote this letter are not only fool, but also is missing very much culture and education. Probably is one of that kind of people who knowing nothing pretend to be very wise insulting other people. John, forget it, is not important at all... JImmy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 4 18:39:44 2000 From owner-freebsd-security@FreeBSD.ORG Mon Dec 4 18:39:42 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from epsilon.lucida.ca (epsilon.lucida.ca [216.95.146.6]) by hub.freebsd.org (Postfix) with SMTP id 0EF7737B400 for ; Mon, 4 Dec 2000 18:39:42 -0800 (PST) Received: (qmail 69797 invoked by uid 1000); 5 Dec 2000 02:39:40 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 5 Dec 2000 02:39:40 -0000 Date: Mon, 4 Dec 2000 21:39:39 -0500 (EST) From: Matt Heckaman X-Sender: matt@epsilon.lucida.ca To: "David G. Andersen" Cc: FreeBSD-SECURITY Subject: Re: [spam score 10.00/10.0 -pobox] Re: Fw: NAPTHA Advisory Updated - BindView RAZOR In-Reply-To: <200012050138.SAA03007@faith.cs.utah.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: localhost 1.6.2 0/1000/N Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 4 Dec 2000, David G. Andersen wrote: ... : Nope. It wasn't a kernel problem you were encountering - it was a : systemwide resource limit being reached. It's not that there's a _bug_ in : the kernel, it's that the processes file table limits weren't isolated : from each other. The right solution to this is more isolation of : different processes (e.g. resource control). It would be nice if one could set login.conf(5) style resource limits per daemon instead of per login. Thus we could say, well "{q,send}mail can have 1024 fds" while apache can have 4096.. etc. Maybe there is a way to do this (djb's tcpserver? xinetd?) but I'm not currently aware of one. One thing though, it would be nice to see FreeBSD's default fd & nmbcluster setting be raised, as it really isn't going to be enough for a lot of people in normal use, and damn sure won't stand up to any kind of attack like this. Just an opinion though :) * Matt Heckaman - mailto:matt@lucida.qc.ca http://www.lucida.qc.ca/ * * GPG fingerprint - A9BC F3A8 278E 22F2 9BDA BFCF 74C3 2D31 C035 5390 * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: http://www.lucida.qc.ca/pgp iD8DBQE6LFVsdMMtMcA1U5ARAkh/AKDmPOD28La1CY15lq/BiktuWW0kkACg3PN1 m/6arbHHdoLL412tfk8N6Hw= =vJij -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 4 18:54:30 2000 From owner-freebsd-security@FreeBSD.ORG Mon Dec 4 18:54:26 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from earth.backplane.com (placeholder-dcat-1076843399.broadbandoffice.net [64.47.83.135]) by hub.freebsd.org (Postfix) with ESMTP id 774BF37B400; Mon, 4 Dec 2000 18:54:26 -0800 (PST) Received: (from dillon@localhost) by earth.backplane.com (8.11.1/8.9.3) id eB52sQH79995; Mon, 4 Dec 2000 18:54:26 -0800 (PST) (envelope-from dillon) Date: Mon, 4 Dec 2000 18:54:26 -0800 (PST) From: Matt Dillon Message-Id: <200012050254.eB52sQH79995@earth.backplane.com> To: Alfred Perlstein Cc: security@FreeBSD.ORG Subject: Re: NAPTHA/RAZOR response. References: <20001204172505.D8051@fw.wintelcom.net> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm sorry (red faced), I just can't resist! -Matt Ok, ah' can't recon' whut some bunch uh hosers dese RAZOR/bindview guys are, dia' "adviso'y" be nodin' new, dere wuz some news article about 3 years ago rapin' about dis problem, all dat RAZOR seems to gots' done be find some pretty lame and bugger'd way uh spoofin' de source uh de attack which duzn't really wo'k. (it be trivial to find da damn source uh de attack) Way t'go bein' some bunch uh attenshun grabbin' lemurs guys, congrats on de ZDnet article. Right On! So on wid mah' own response 'adviso'y', enjoy, dig dis: fear**fear**fear**fear**fear**fear**fear**fear**fear**fear**fear**fear**fear ################ ################ ###### #### #### #### #### ## ## #### ## #### ## #### #### #### #### #### #### ## ## #### #### #### #### #### #### #### #### #### #### #### #### #### ## #### ## #### #### #### #### #### #### #### #### ############## ############## ###### #### #### #### ########## ###### #### #### #### #### #### ###### #### #### #### #### #### ###### #### #### #### #### ###### ###### #### #### #### #### #### #### #### #### #### #### #### #### #### #### #### #### ###### #### #### #### #### #### #### #### #### #### #### #### #### ## ## #### #### #### ###### #### #### #### ###### #### #### #### #### ############## ######## ######## ## fear**fear**fear**fear**fear**fear**fear**fear**fear**fear**fear**fear**fear [ Dayam where's de sploitz at? ] [ Sploit...... NAPTHA 1.2 ] [ Dumbasses responsible. What it is, Mama!..... RAZOR ] [ Analysis by. Slap mah fro!.... Alfred Perlstein ] _________.. . . | : Summary ' RAZOR noticed dat when ya' create some lot uh connecshuns t'a service ya' effectively cause da damn remote side t'fo'k bomb and/o' consume resources waitin' fo' de connecshuns t'time out. By slowly tricklin' 'espected ACKs back t'de applicashun/serva' one kin also keep some lot uh resources tied waaay down in bod de applicashun and kernel levels. RAZOR wuzn't da damn fust bunch uh tools t'notice dis effect, amazin'ly dis effect be seen by some lot uh fust year clunker science students when dey snatch deir fust netwo'k honky codemin' class. What RAZOR duzn't seem t'clue in on, o' plum pretends dat it be not a big-ass deal be dat dis attack requires local edernet access t'be spoofed . oderwise unless de victim OS gots'ta easy t'predict TCP sequence numbers.. ...de attacka' must reveal de source uh de attack (his IP). : | .........____| _________.. . . | : Exploit (abstract) ' When NAPTHA be deployed remotely one kin simply use tcpdump t'figure de source locashun uh de DoS. When NAPTHA be deployed locally usin' ARP tricks t'hide one's IP one kin simply log onto local switches and view de ARP cache to discova' de source. What it is, Mama! Afta' findin' de source uh de attack ya''ll need, dig dis: 1) some crowbar 2) some duct tape 3) some gerbil Use 1 (de crowbar) t'boogie de offender's legs and arms, den apply 2 (de duct tape) t'offender, we'll leave da damn use uh item 3 (de gerbil) t'yo' imaginashun, I's sho' nuff ya''ll figure it out. : | .........____| _________.. . . | : Wo'karound ' Drop idle connecshuns fasta' and deal wid resource sho'tages gracefully. Slap mah fro! (duh. Right On! ) : | .........____| _________.. . . | : Shoutouts to, dig dis: ' halah (u rul3 m3 b4by), j4mes, ps, pm (plum kiddin', n0 gr33t 4u), jba (el8warez 4 u) and jkh (journey rulez) Big :P go to, dig dis: RAZOR (one wo'd, dig dis: lame) CERT (why'd ya' guys release dis junk?) . SIIG (d3s3 h0s3rz package different chipsets in de same boxes) : billf@efnet (d00d, where's mah' O: ?) | Dis adviso'y crafted wid vim, damn ah' miss DeDraw :/ .........____| *narf* To Unsubscribe, dig dis: t'row mail t'majo'domo@FreeBSD.o'g wid "unsubscribe freebsd-security" in de body uh de message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 4 19: 5:48 2000 From owner-freebsd-security@FreeBSD.ORG Mon Dec 4 19:05:43 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mail.fpsn.net (mail.fpsn.net [63.224.69.57]) by hub.freebsd.org (Postfix) with ESMTP id 6B48F37B400 for ; Mon, 4 Dec 2000 19:05:43 -0800 (PST) Received: from fpsn.net (control.fpsn.net [63.224.69.60]) by mail.fpsn.net (8.9.3/8.9.3) with ESMTP id UAA04247; Mon, 4 Dec 2000 20:04:44 -0700 (MST) (envelope-from cfaber@fpsn.net) Message-ID: <3A2C5B47.32C93A3E@fpsn.net> Date: Mon, 04 Dec 2000 20:04:39 -0700 From: Colin Faber Reply-To: cfaber@fpsn.net Organization: fpsn.net, Inc. X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: James Lim Cc: Richard Ward , abuse@GalaxyFree.com, FreeBSD-security@FreeBSD.ORG Subject: Re: Hacker Warning References: <012c01c05e57$617fb920$0101a8c0@pavilion> <010301c05e57$8e8943a0$fa5e78cb@gchang> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Given how popular this list is from time to time you're going to see some spam on it, But i'm still very pleased with the lack their of on this list, Keep up the good work guys. James Lim wrote: > To Hell with spam. I take the freebsd* mailing lists to be a "place" to > learn. Spamming is definately not tolerated. =] > > James Lim > Technical Support Executive > > Pacific Internet Limited > 89 Science Park Drive > #02-05/06 The Rutherford > Singapore 118261 > > Finger evilfry@sg.freebsd.org for PGP key. > > ----- Original Message ----- > From: "Richard Ward" > To: > Cc: > Sent: Tuesday, December 05, 2000 9:04 AM > Subject: Re: Hacker Warning > > > Spam is not only extremely illegal, but is the number 3 reason that makes > > the Internet not worth being on now-a-days. The other two being DoS and > new > > corrupt laws coming in to play. I have already gotten two half-assed > > wireless/cellular companies taken to court over them spaming my 24/7 fax > > line, and we've won both times because spam is wrong. Email, Fax, Snail > > Mail, etc.. none the less wrong, too. I highly suggest you put a halt to > > spaming this mailing list, many angry network administrators are most > likely > > already plotting your death; myself included. Cheers. > > -- > > Richard Ward, Founder > > Neonsky Internet Services > > http://www.neonsky.net > > > > ----- Original Message ----- > > From: Jonathan M. Slivko > > To: GalaxyFree > > Cc: ; > > Sent: Monday, December 04, 2000 7:46 PM > > Subject: Re: Hacker Warning > > > > > > > Now this is what I call spamming! Please DO NOT spam this list again, or > I > > > will call your uplink and have you pulled. Thank You. > > > > > > -- Jonathan M. Slivko > > > > > > ---- > > > Jonathan M. Slivko > > > Technical Support, CoreSync Corporation (http://www.coresync.net) > > > Team Leader, SecureIRC Project (http://secureirc.sourceforge.net) > > > Pager/Voicemail: (917) 388-5304 > > > ---- > > > > > > On Mon, 4 Dec 2000, GalaxyFree wrote: > > > > > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > with "unsubscribe freebsd-security" in the body of the message > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-security" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 4 19: 6: 5 2000 From owner-freebsd-security@FreeBSD.ORG Mon Dec 4 19:06:04 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from giganda.komkon.org (giganda.komkon.org [209.125.17.66]) by hub.freebsd.org (Postfix) with ESMTP id 7ED3437B400; Mon, 4 Dec 2000 19:06:03 -0800 (PST) Received: (from str@localhost) by giganda.komkon.org (8.9.3/8.9.3) id WAA85505; Mon, 4 Dec 2000 22:06:02 -0500 (EST) (envelope-from str) Date: Mon, 4 Dec 2000 22:06:02 -0500 (EST) From: Igor Roshchin Message-Id: <200012050306.WAA85505@giganda.komkon.org> To: alfred@FreeBSD.ORG, dillon@earth.backplane.com Subject: Re: NAPTHA/RAZOR response. -- OT Cc: security@FreeBSD.ORG In-Reply-To: <200012050254.eB52sQH79995@earth.backplane.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Where can I get English <--> Geekish translator ? :) Is it in ports already ? Igor > Date: Mon, 4 Dec 2000 18:54:26 -0800 (PST) > From: Matt Dillon > To: Alfred Perlstein > Cc: security@FreeBSD.ORG > Subject: Re: NAPTHA/RAZOR response. > > I'm sorry (red faced), I just can't resist! > > -Matt > > > Ok, ah' can't recon' whut some bunch uh hosers dese RAZOR/bindview > guys are, dia' "adviso'y" be nodin' new, dere wuz some news article > about 3 years ago rapin' about dis problem, all dat RAZOR seems <..> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 4 19: 9:59 2000 From owner-freebsd-security@FreeBSD.ORG Mon Dec 4 19:09:54 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from femail3.sdc1.sfba.home.com (femail3.sdc1.sfba.home.com [24.0.95.83]) by hub.freebsd.org (Postfix) with ESMTP id E23A037B401; Mon, 4 Dec 2000 19:09:54 -0800 (PST) Received: from cx443070b ([24.0.36.170]) by femail3.sdc1.sfba.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20001205030832.ISTW18624.femail3.sdc1.sfba.home.com@cx443070b>; Mon, 4 Dec 2000 19:08:32 -0800 Message-ID: <002701c05e69$27ddfad0$aa240018@cx443070b> From: "Jeremiah Gowdy" To: "Alfred Perlstein" , Cc: References: <20001204172505.D8051@fw.wintelcom.net> Subject: A SECOND RAZOR/BINDVIEW ADVISORY !!! FreeBSD Admins ARE vulnerable !!! Date: Mon, 4 Dec 2000 19:12:09 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Topic: Network Administrator DoS vulnerabilities Overview: A class of vulnerabilities has been discovered, and the name LMAO is being used to describe them as a group. The LMAO vulnerabilities are weaknesses in the way that Razor restates the obvious and gets media attention. Affected Systems: Any and all Network Administrators who read Razor Advisories. Impact: By depriving the Network Administrator's brain of oxygen for an extended period of time, the admin's mental abilities may be reduced to levels even lower than their usual substandard state. This could result in even more work time spent on IRC than usual. Background: DoS A denial of service attack is a purposeful action to significantly degrade the quality and/or availability of services a system offers. DoS->OS Oxygen Starvation is a type of denial of service attack. DoS->OS->LAUGHING_STATE The Network Administrator has a diaphragm, which when exposed to Razor advisories, may activate uncontrollably causing possibly very serious damage due to lack of oxygen to the brain and possibly even more serious injures if the situation is severe enough to warrant a ROFL, because the transition from LMAO to LMFAO to ROFL usually involves the subject falling out of his or her chair. Details: LMAO is a demonstration of an efficient DoS->OS->LAUGHING_STATE exploit. It is efficient because it does not use traditional humor, involving things that are actually funny. Unlike a real joke, Razor Advisories are represented as being serious, which can actually increase the damage done to the Network Administrator. Here are a few examples of the many possible LMAO weaknesses: - FreeBSD Administrators, when told that too many connections to a port will consume resources, are immediately rendered useless as they quickly fall into the LMFAO state, very possibly resulting in a tipped chair, dumping the Admin onto the floor and there is even a remote possibility that the Admin's soft drink of choice is spilled on the floor, resulting in damages to the Administrator in the amount of $0.50 to $1.00 or more depending on how cheap the owners of said Administrator's company are. - Novel Netware Administrators, when told they are 45 years old, they have no life, and are using a product that should be quietly put to death, usually begin crying and are inconsolable for hours. The reason this qualifies as a LMAO attack is although the Netware Administrator is crying, all of the other Administrators who've been silently laughing at him for years are DoSed and unable to do their jobs resulting in a SMURF style LMAO attack. - Windows 2000 Administrators, usually MCSEs, are too busy trying to figure out what they paid $5,000 for and playing Solitaire to notice Razor Advisories. They seem to be invulnerable to this type of attack unless the Advisory is emailed to them with a VBS Trojan attachment. Recommendations: Unfortunately, most Administrators are vulnerable to LMAO attacks, and until some ignorance patches come out, there is very little that can be done outside of normal hiccup resolution practices. We do have a few recommendations: 1. Limit the amount of humorous emails the Administrator receives, because if the Administrator already has the hiccups when reading a Razor Advisory, the results can be fatal. 2. Limit who can speak to the Administrator using office partitions to avoid office humor. 3. Call the ISP and ask them to upstream filter all razor.bindview.com packets. 4. Replace the tile floors in the office with shag carpet for a much softer landing in the event of a LMFAO escalating to a ROFL. 5. Make certain that emergency hiccup stations are functioning properly, that the Administrator may quickly have a drink of water after reading Razor Advisories. References: CVE: The Common Vulnerabilities and Exposures (CVE) project has assigned the name LOL-31337 to this issue. CERT Advisory: http://www.cert.org/advisories/LOL-31337 Microsoft's Security Bulletin: http://www.microsoft.com/win2k Microsoft Security Patch http://www.microsoft.com/directx RFC 31337: http://www.faqs.org/rfcs/rfc31337.html "I can packet j00" security paper Author: ScriptHax0r http://razor.bindview/publish/papers/war-toolz.html "Strategies for getting your ISP to defend you after you've started a packet war" security paper Author: OopsIGotCaught http://razor.bindview.com/publish/papers/OhShit.html Snort, Sniff, Chew, Inject, but don't inhale. http://www.william-jefferson-clinton.com/depends-on-what-the-meaning-of-the- word-is-means.html Al Gore's voteserver: http://www.algore.com/cgi-bin/generatevotes.cgi?recount=YES BasharTeg's Forkbomb Process-Table Attack http://void.main.void/while/1/malloc/fork/disqualified/from/rootwars.html Stanislav's Script KiddieKill http://www.securityfocus.com/archive/101/ways-to-kill-a-script-kiddie.html Advisory Contact: advisory.lmao@razor.bindview.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 4 21: 7: 5 2000 From owner-freebsd-security@FreeBSD.ORG Mon Dec 4 21:06:49 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from smtprelay1.adelphia.net (smtprelay1.adelphia.net [64.8.25.6]) by hub.freebsd.org (Postfix) with ESMTP id 5908737B400 for ; Mon, 4 Dec 2000 21:06:49 -0800 (PST) Received: from pa-westmifflin1a-530.pit.adelphia.net ([24.48.239.18]) by smtprelay1.adelphia.net (Netscape Messaging Server 4.15) with ESMTP id G52WSG00.H4K; Tue, 5 Dec 2000 00:05:04 -0500 Date: Tue, 5 Dec 2000 00:00:38 -0500 (EST) From: pW X-Sender: packetwhore@beastie To: John Howie Cc: freebsd-security@FreeBSD.ORG Subject: Re: Fw: NAPTHA Advisory Updated - BindView RAZOR In-Reply-To: <00dd01c05e53$39c719e0$fd01a8c0@pacbell.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org If I am interpreting this the wrong way, I apologize in advance... You seem awfully eager to point out FreeBSD weaknesses... I notice the msn address and the fact that you got this from an NT security list. Well, while FreeBSD or ANY OS is perfect, FreeBSD seems to be good enough to run Hotmail's web servers and mail servers... something that couldn't be done with NT... hmmm.... just thought I would point that out before you take too much satisfaction from a FreeBSD weakness... pW On Mon, 4 Dec 2000, John Howie wrote: > Folks, > > Take note of how FreeBSD failed... > > john... > > ----- Original Message ----- > From: "Steve Manzuik" > To: > Sent: Monday, December 04, 2000 3:09 PM > Subject: NAPTHA Advisory Updated - BindView RAZOR > > > > The NAPTHA DoS vulnerabilities > > > > Issue Date: November 30, 2000 > > Contact: Robert Keyes > > > > Topic: > > > > Network DoS vulnerabilities > > > > Overview: > > > > A class of network DoS vulnerabilities has been discovered, and the name > > NAPTHA is being used to describe them as a group. The NAPTHA > > vulnerabilities are weaknesses in the way that TCP/IP stacks and network > > applications handle the state of a TCP connection. > > > > Affected Systems: > > > > The Naptha DoS vulnerabilities "Tested Products" > > > > Impact: > > > > By creating a suitably large number of TCP connections and leaving them > in > > certain states, individual applications or the operating system itself > can > > be starved of resources to the point of failure. In the past, attacks > that > > would exploit TCP connections in this manner have not been implemented > > because they would typically exhaust the resources of the attacker as > > well. The innovation provided by the Naptha attack is that it is > possible > > to easily create a DoS on the target with little resource consumption on > > the part of the attacker. > > > > Background: > > > > DoS > > A denial of service attack is a purposeful action to significantly > degrade > > the quality and/or availability of services a system offers. > > > > DoS->RS > > Resource Starvation is a type of denial of service attack. Here is where > > we need to define the difference between an attack and a notable > > vulnerability. With sufficient network resources available to the > > attacker, any system is vulnerable to DoS->RS. > > > > What makes a method of DoS->RS notable is that it consumes far more > > resources of the victim than resources of the attacker. A great differen > ce > > in resource levels indicate a vulnerability in the victim's system. The > > software designed to expose this vulnerability can be called a DoS->RS > > exploit. > > > > DoS->RS->TCP_STATE > > The kernel keeps a record for every TCP connection. A large number of > > connections, regardless of activity, require more memory and CPU time. > It > > is theoretically possible for a user on a machine with a large amount of > > RAM, a fast processor, and a well-tuned operating system to overwhelm a > > lesser system solely by using such standard programs as TELNET, however > > the amount of resources consumed on the attacking system is large enough > > so that this is not considered a serious vulnerability. > > > > An attack program utilizing a network API such as Berkeley Sockets is > more > > efficient and therefore more dangerous, but is not usually efficient > > enough expose a dangerous vulnerability on the victim's system. > > > > Details: > > > > Naptha is a demonstration of an efficient DoS->RS->TCP_STATE exploit. It > > is efficient because it does not use a traditional network API to set up > a > > TCP connection. Unlike a real TCP/IP stack, it does not keep any record > of > > connection state. It responds to a packet sent to it based on the flags > in > > that packet alone. When operated in a manner that will produce many > > hundreds or thousands of connection records on the victim, it consumes > > very little of the attacker's resources in comparison to the resources > it > > uses up on the victim's system. In this way, it can expose > vulnerabilities > > of a particular service, or the TCP/IP stack itself, on the victim's > > system. > > > > Below are a few examples of the many possible Naptha weaknesses: > > > > - Novell's Netware 5.0 with sp1 installed locked up after 3000 > > open connections on port 524. All 64MB of the system's RAM > > became utilized and the CPU utilization as well maxed out at > > 100%. The server still had not timed out connections and > > recovered memory after 12 hours being left idle. > > > > - FreeBSD 4.0-REL became unusable after 495 connections to the > > ssh port. Each connection started an instance of the daemon > > which quickly exhausted available file handles; the system > > reports "too many open files in system". After approximately 30 > > minutes the connections start timing out and the system becomes > > usable again. > > > > - Windows 2000 seems to be invulnerable. > > > > See the complete list of tested products at the end of this document. > > > > > > The Workings of Naptha > > ---------------------- > > > > The objective of this section is to describe the basic structure of > > the Naptha attack so that researchers can verify our claim that such an > > attack is possible and should be considered with all due seriousness. > > > > While there has been some previous work in this area, no one has > > published or demonstrated a tool that can leave connections in any of > > the various TCP states on the victim machine (ESTABLISHED and > FIN-WAIT-1, > > etc.) or that has a multi-component architecture (allowing one to hide > > part of the attack on different hosts). > > > > Naptha gains much of its effectiveness through the fact that the attack > > can be made in a distributed manner. > > > > The first part sends out a sequence of SYN packets from all possible > > ports of a forged IP address to the victim. Depending on the > requirements > > of > > the individual attack scenario, multiple copies of this program on the > > same host could be used to attack different hosts, or multiple hosts > could > > attack a single victim. This sounds like a SYN flood, but there's more > to > > it. > > > > The second half runs on a LAN where the forged IP address would be, if > it > > were a real host. The program first makes sure that the router has an > > entry > > for this phantom host in its ARP table. Next, it listens in promiscuous > > mode for a packet from the victim to the phantom host. The program > > responds > > with a packet with the appropriate flags and sequence numbers. > Typically, > > it listens for SYN/ACK packets and sends ACK. It could also set the FIN > > flag and leave the connection in FIN-WAIT-1. To keep connections alive > > longer, it can listen for 'regular' data packets or 'keep alive' packets > > and send ACK in reply. Multiple victims could be targeted by a single > > instance of this program. > > > > This 'phantom' nature makes it hard to track down and eliminate. > > > > In order to be successfully asymmetrical in its consumption of > > resources, such an attack program must not set up any TCBs (Transmission > > Control Blocks) in the kernel of the attacking machine. This helps to > > ensure that the attacker's activities will not be directly constrained > > by the client-side kernel limitations. It is also important that the > > number of processes needed on the client side not grow with the number > of > > TCP > > connections. Naptha does this by completely avoiding use of the OS's > > TCP/IP stack, and instead crafts its own raw packets. In fact, in a high > > rate Naptha attack, the network's bandwidth would typically be the > > constraint rather than the attacking host's resources. > > > > Naptha also has connection rate limiting capabilities. In one variation > of > > the attack, connections are established at a high rate and the victim is > > left with thousands of ports open, and all resources are consumed before > > the connections time out. In another scenario, connections are > > established at a slow rate to avoid SYN flood protections. > > > > The number of connections and the rate of establishment necessary to > > create a DoS is dependant on a number of factors. Different operating > > systems have different thresholds of connection numbers, file numbers, > > process memory, etc. The application running on that port may also have > > its own levels of resource control. Some applications spawn a new > process > > for each connection. The speed of the CPU and amount of memory in a > system > > also affects its resistance to a Naptha attack. Lastly, the network > > itself plays its part. > > > > In conclusion, the Naptha attack shows how serious a resource starvation > > attack can be. There is no single, clear, obvious fix for this problem > > but a number of promising ideas. > > > > Recommendations: > > > > Unfortunately, most vendors are vulnerable to Naptha attacks, and until > > some vendor patches come out, there is very little that can be done > > outside of normal security practices. We do have a few recommendations: > > > > 1. Limit the amount of services running on any system you > > suspect that might become victim to a Naptha attack, especially > > public systems. > > > > 2. Limit access as to who can connect to exposed TCP ports on a > > system via firewalling techniques. On public systems this may be > > impractical, but it should be limited just the same if possible. > > > > 3. Ensure that all border equipment, such as routers and > > firewalls, is properly configured and you are doing both ingress > > and egress filtering. (See RFC 2267) > > > > 4. On Unix systems, use inetd or possibly Dan Bernstein's > > tcpserver (http://cr.yp.to/ucspi-tcp.html) to limit spawned > > daemon processes. While this will not prevent that particular > > daemon's resources from being over utilized, it is possible to > > prevent daemons from crashing the server. This may allow the > > server to recover. > > > > 5. On systems that have adjustments for various TCP timeouts and > > keepalives, these can be adjusted to potentially allow for > > quicker recovery (assuming that the Naptha attack did not crash > > the system). For example, the TCP keepalive settings on Linux > > 2.2 kernels might help recovery time: > > > > # cat /proc/sys/net/ipv4/tcp_keepalive_time > > 7200 > > # cat /proc/sys/net/ipv4/tcp_keepalive_probes > > 9 > > # cat /proc/sys/net/ipv4/tcp_max_ka_probes > > 5 > > # echo 30 > /proc/sys/net/ipv4/tcp_keepalive_time > > # echo 2 > /proc/sys/net/ipv4/tcp_keepalive_probes > > # echo 100 > /proc/sys/net/ipv4/tcp_max_ka_probes > > > > In the above example the keepalive time is adjusted from 2 hours > > to 30 seconds, and the number of keepalive probes is adjusted > > from 9 to 2. It also adjusts the maximum number of probes sent > > out to be 100 instead of just 5. These are suggested values -- > > real world adjusts will almost certainly be required. > > > > 6. The programs written to demonstrate the attack have been > > released only to the security contacts at OS vendors, through > > CERT. The code will not be released to the public. However, the > > information below will serve as a 'fingerprint' for IDS to > > detect the demonstration code. Please note that the code itself > > could be easily modified to change the fingerprint, so this is > > NOT a failsafe method of detecting a Naptha attack. > > > > IP: > > TOS = Low Delay > > ID = 413 > > TCP: > > FLAGS = SYN > > SEQ ID = 6060842 > > WINDOW = 512 > > > > Snort (http://www.snort.org) is a free lightweight IDS. Here's a > > Snort filter for Naptha: > > > > alert tcp any any <> any any (flags:S; seq: 6060842; > > id: 413; msg: "Naptha DoS Attack, see > > > http://razor.bindview.com//publish/advisories/adv_NAPTHA.html";) > > > > ------------------------------------------------------------------------ > > > > References: > > > > CVE: > > > > The Common Vulnerabilities and Exposures (CVE) project has > > assigned the name CAN-2000-1039 to this issue. This is a > > candidate for inclusion in the CVE list (http://cve.mitre.org), > > which standardizes names for security problems. > > > > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2000-1039 > > > > CERT Advisory: > > > > http://www.cert.org/advisories/CA-2000-21.html > > > > Microsoft's security bulletin: > > > > http://www.microsoft.com/technet/security/bulletin/MS00-091.asp > > > > Microsoft Security Patch: > > > > NT4: > > http://www.microsoft.com/Downloads/Release.asp?ReleaseID=25114 > > > > RFC 2267: > > > > http://www.faqs.org/rfcs/rfc2267.html > > > > "Distributed Denial of Service Defense Tactics" security paper > > > > Author: Simple Nomad > > http://razor.bindview.com/publish/papers/DDSA_Defense.html > > > > "Strategies for Defeating Distributed Attacks" security paper > > > > Author: Simple Nomad > > http://razor.bindview.com/publish/papers/strategies.html > > > > Snort: > > > > http://www.snort.org > > > > Dan Bernstein's tcpserver: > > > > http://cr.yp.to/ucspi-tcp.html > > > > Simson Garfinkel on Process-Table Attack > > > > http://www.securityfocus.com/archive/1/12636 > > > > Stanislav Shulanov's Netkill > > > > http://www.securityfocus.com/archive/1/56462 > > > > Contact: advisory+naptha@razor.bindview.com > > > > Acknowledgements: Mark Loveless and the rest of the RAZOR team. > > > > > > ---------------------------------------------- > > > > > > > > The Naptha DoS vulnerabilities > > "Tested Products" > > > > Note: The RAZOR team has examined > > two TCP states out of many. These > > states are the FIN-WAIT-1 state and > > the ESTABLISHED state. More research > > in this area is underway. We expect > > to find a majority of operating > > systems affected to some extent. > > > > > > > > Vendor Product Vulnerable? TCP state > > Patch/Workaround Available? Notes > > > > Compaq Tru64 UNIX Yes ESTABLISHED No patch or > > workaround available at this time See > > V4.0F See > > Recommendations Notes > > > > FreeBSD FreeBSD Yes ESTABLISHED No patch or > > workaround available at this time See > > 4.0-REL See > > Recommendations Notes > > > > Hewlett-Packard HP-UX 11.00 Yes ESTABLISHED No patch or > > workaround available at this time See > > See > > Recommendations Notes > > > > Microsoft Windows Yes FIN-WAIT-1 Workaround > > available at See > > 95,98,98SE > > http://www.microsoft.com/technet/security/bulletin/MS00-091.asp Notes > > > > Microsoft Windows NT Yes FIN-WAIT-1, Patch > > available at See > > 4.0 SP6a ESTABLISHED > > http://www.microsoft.com/Downloads/Release.asp?ReleaseID=25114 Notes > > > > Microsoft Windows No N/A N/A > > N/A > > 2000 > > > > Novell Netware 5 Yes ESTABLISHED No patch or > > workaround available at this time See > > SP1 See > > Recommendations Notes > > > > SGI IRIX 6.5.7m Yes ESTABLISHED No patch or > > workaround available at this time See > > See > > Recommendations Notes > > > > Sun Solaris 7, Yes ESTABLISHED No patch or > > workaround available at this time See > > 8 See > > Recommendations Notes > > > > > > ------------------------------------------------------------------------ > > > > Notes: > > > > Compaq - Tru64 UNIX V4.0F > > > > Two services were tested, portmapper (tcp > > port 111) and finger (tcp port 79). These > > services were chosen because finger runs > > from inetd and portmapper runs without it. > > > > The Tru64 UNIX kernel appears to be > > somewhat robust against Naptha attacks. > > Sending twenty thousand packets to tcp > > port 111 caused no obvious performance > > degradation on the Tru64 UNIX host > > (except that other attempts to query the > > portmapper became unsuccessful). The > > netstat command showed a steady-state > > value of 4100 ESTABLISHED connections. > > > > Sending a few hundred packets to tcp port > > 79, however, resulted in creation of too > > many finger daemon processes for the > > system to continue normal operation. > > Trying to start a new process from a login > > shell resulted in the error "No more > > processes". It is possible that the finger > > daemon attack would have been less > > effective with a different inetd > > configuration, or with different kernel > > parameters. We did not investigate this. > > > > ------------------------------------------- > > > > FreeBSD - FreeBSD 4.0-REL > > > > In testing FreeBSD, a few specific > > daemons/ports were targeted. For some, the > > stability of the system as a whole can be > > affected. The daemons targeted in this > > testing are not necessarily at fault for > > the problems encountered. > > > > SSH: > > Became unusable after 495 connections to > > the ssh port. Each connection started an > > instance of the daemon which quickly > > exhausted available file handles; the > > system reports "too many open files in > > system". After approximately 30 minutes > > the connections start timing out and the > > system becomes usable again. > > > > NFS: > > Stopped functioning after 964 packets to > > the NFS port. While the rest of the system > > did not seem affected, the connections did > > not time out. > > > > BIND: > > Took 961 TCP connections before the kernel > > reported "file table is full", and TCP > > services failed. UDP DNS seemed > > unaffected. These connections look a long > > time to time out, at least an hour. > > > > Note: These services/ports can be > > similarly affected on other Linux and UNIX > > variants. > > > > ------------------------------------------- > > > > Hewlett-Packard - HP-UX 11.00 > > > > Two services were tested, portmapper and > > telnet. These services were chosen because > > telnet runs from inetd and portmapper runs > > without it. > > > > TELNET: > > HP-UX appears to have some protection. It > > stops responding to Naptha packets after > > several hundred from the same IP address. > > However, until that time it is possible to > > make telnetd respond with; "Telnet device > > drivers missing: No such device". This > > does recover fairly quickly, however. > > > > PORTMAPPER: > > After several hundred Naptha TCP sessions, > > a telnet session to port 111 will > > immediately be disconnected. This broken > > state lingers for much longer than the > > telnet problem. > > > > ------------------------------------------- > > > > Microsoft - Windows 95,98,98SE > > > > Leaving a large number of connections in > > FIN-WAIT-1 causes the NetBIOS and WWW > > services on Microsoft Windows 95, 98, and > > 98SE to fail and not restart. > > > > ------------------------------------------- > > > > Microsoft - Windows NT 4.0 SP6a > > > > Exploiting ESTALISHED states on port 139 > > (netbios-ssn), caused the service to die > > after 1010 packets. Port 135 (loc-srv) > > died after 7929 packets. Interestingly, if > > port 139 had been previously killed by > > Naptha, port 135 died after two packets. > > If the Naptha attack was paused, port 135 > > would recover but be immediately > > unavailable if the Naptha attack was > > resumed. When port 135 died, the CPU > > utilization would eventually jump to 100% > > and remain there until a reboot. > > > > Leaving a large number of connections in > > FIN-WAIT-1 causes the NetBIOS and WWW > > services on Microsoft Windows NT 4.0 to > > fail and not restart. > > > > ------------------------------------------- > > > > Novell - Netware 5 SP1 > > > > Locked up after 3000 open connections on > > port 524, utilized all 64MB of the > > system's RAM, and CPU utilization became > > 100%. The server still had not timed out > > connections and recovered memory after 12 > > hours being left idle. > > > > ------------------------------------------- > > > > SGI - IRIX 6.5.7m > > > > Two services were tested, portmapper (tcp > > port 111) and sgi-dgl (tcp port 5232). > > These services were chosen because sgi-dgl > > runs from inetd and portmapper runs > > without it. > > > > The IRIX kernel appears to be somewhat > > robust against Naptha attacks. Sending > > twenty thousand packets to tcp port 111 > > caused no obvious performance degradation > > on the IRIX host (except that other > > attempts to query the portmapper became > > unsuccessful). The netstat command showed > > a steady-state value of 195 ESTABLISHED > > connections. > > > > Sending a few hundred packets to tcp port > > 5232, however, resulted in creation of too > > many dgl daemon processes for the system > > to continue normal operation. Trying to > > start a new process from a login shell > > resulted in the error "No more processes". > > It is possible that the dgl daemon attack > > would have been less effective with a > > different inetd configuration, or with > > different kernel parameters. We did not > > investigate this. > > > > ------------------------------------------- > > > > Sun - Solaris 7, 8 > > > > Two services were tested, portmapper and > > telnet. These services were chosen because > > telnet runs from inetd and portmapper runs > > without it. > > > > TELNET: > > At around 700 Naptha TCP sessions, a > > telnet session will be connected but then > > gets the message "can't grant slave pty" > > and is disconnected. At 1700 Naptha TCP > > sessions, a telnet session will be > > connected but nothing else happens. This > > is not confined to the telnet port, it > > effects every port. If the Naptha attack > > is stopped, eventually telnet will > > recover. How long it is broken is > > dependant on the speed and length of the > > Naptha assault and other factors. A > > typical downtime was an hour. > > > > PORTMAPPER: > > At around 300 Naptha TCP sessions, a > > telnet session to port 111 is immediately > > disconnected (normally, this is > > disconnected when a user hit the enter > > key). This fault does not effect other > > services. Downtime variable but typically > > two hours. > > > > ------------------------------------------- > > > > Contact: advisory+naptha@razor.bindview.com > > > > _____________________________________________________________________ > > ** TO UNSUBSCRIBE, send the command "UNSUBSCRIBE win2ksecadvice" > > ** FOR A WEEKLY DIGEST, send the command "SET win2ksecadvice DIGEST" > > SEND ALL COMMANDS TO: listserv@listserv.ntsecurity.net > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 4 21:40:51 2000 From owner-freebsd-security@FreeBSD.ORG Mon Dec 4 21:40:49 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from silby.com (cb34181-c.mdsn1.wi.home.com [24.183.3.139]) by hub.freebsd.org (Postfix) with ESMTP id 2B28F37B400 for ; Mon, 4 Dec 2000 21:40:49 -0800 (PST) Received: (qmail 17214 invoked by uid 1000); 5 Dec 2000 05:40:47 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 5 Dec 2000 05:40:47 -0000 Date: Mon, 4 Dec 2000 23:40:47 -0600 (CST) From: Mike Silbersack To: pW Cc: John Howie , freebsd-security@FreeBSD.ORG Subject: Re: Fw: NAPTHA Advisory Updated - BindView RAZOR In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 5 Dec 2000, pW wrote: > If I am interpreting this the wrong way, I apologize in advance... You > seem awfully eager to point out FreeBSD weaknesses... I notice the msn > address and the fact that you got this from an NT security list. Well, > while FreeBSD or ANY OS is perfect, FreeBSD seems to be good enough to run > Hotmail's web servers and mail servers... something that couldn't be done > with NT... hmmm.... just thought I would point that out before you take > too much satisfaction from a FreeBSD weakness... > > pW Despite the oldness of the info contained in the advisory, I don't see a problem in John reposting it here. As other have stated, there is the possibility that FreeBSD could handle resource exhaustion better, and the information in the advisory could be useful in testing those improvements. If you believe so strongly in the divine nature of FreeBSD, you should be posting how the attack postulated in the advisory is false, or posting patches that fix the problem. Belittling Microsoft products doesn't solve anything. (Especially considering that Microsoft is transitioning hotmail over to w2k now.) Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 4 21:42:18 2000 From owner-freebsd-security@FreeBSD.ORG Mon Dec 4 21:42:16 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (unknown [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 16F3D37B400 for ; Mon, 4 Dec 2000 21:42:16 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.0/8.11.0) with ESMTP id eB55gEQ95049; Mon, 4 Dec 2000 22:42:14 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id WAA67217; Mon, 4 Dec 2000 22:42:14 -0700 (MST) Message-Id: <200012050542.WAA67217@harmony.village.org> To: Mike Silbersack Subject: Re: Fw: NAPTHA Advisory Updated - BindView RAZOR Cc: pW , John Howie , freebsd-security@FreeBSD.ORG In-reply-to: Your message of "Mon, 04 Dec 2000 23:40:47 CST." References: Date: Mon, 04 Dec 2000 22:42:14 -0700 From: Warner Losh Sender: imp@harmony.village.org Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message Mike Silbersack writes: : Belittling Microsoft products doesn't solve anything. (Especially : considering that Microsoft is transitioning hotmail over to w2k now.) With all due respect, I'll believe it when the transition is complete. They tried to transition to WinNT as well. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 4 21:45: 6 2000 From owner-freebsd-security@FreeBSD.ORG Mon Dec 4 21:45:04 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from sivka.rdy.com (sivka.rdy.com [207.33.166.86]) by hub.freebsd.org (Postfix) with ESMTP id 41E3837B400 for ; Mon, 4 Dec 2000 21:45:04 -0800 (PST) Received: (from dima@localhost) by sivka.rdy.com (8.11.1/8.11.1) id eB55iVb72562; Mon, 4 Dec 2000 21:44:31 -0800 (PST) (envelope-from dima) Message-Id: <200012050544.eB55iVb72562@sivka.rdy.com> Subject: Re: Fw: NAPTHA Advisory Updated - BindView RAZOR In-Reply-To: "from Mike Silbersack at Dec 4, 2000 11:40:47 pm" To: Mike Silbersack Date: Mon, 4 Dec 2000 21:44:30 -0800 (PST) Cc: pW , John Howie , freebsd-security@FreeBSD.ORG Organization: HackerDome Reply-To: dima@rdy.com From: dima@rdy.com (Dima Ruban) X-Mailer: ELM [version 2.4ME+ PL82 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: dima@sivka.rdy.com Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Mike Silbersack writes: > Belittling Microsoft products doesn't solve anything. (Especially > considering that Microsoft is transitioning hotmail over to w2k now.) Yeah, right. That's what they were saying when trying to convert hotmail to NT. > > Mike "Silby" Silbersack > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > -- dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 4 22: 0:48 2000 From owner-freebsd-security@FreeBSD.ORG Mon Dec 4 22:00:46 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from winston.osd.bsdi.com (winston.osd.bsdi.com [204.216.27.229]) by hub.freebsd.org (Postfix) with ESMTP id 8061737B400 for ; Mon, 4 Dec 2000 22:00:46 -0800 (PST) Received: from winston.osd.bsdi.com (jkh@localhost [127.0.0.1]) by winston.osd.bsdi.com (8.11.1/8.11.1) with ESMTP id eB560BM46240; Mon, 4 Dec 2000 22:00:11 -0800 (PST) (envelope-from jkh@winston.osd.bsdi.com) To: Warner Losh Cc: Mike Silbersack , pW , John Howie , freebsd-security@FreeBSD.ORG Subject: Re: Fw: NAPTHA Advisory Updated - BindView RAZOR In-Reply-To: Message from Warner Losh of "Mon, 04 Dec 2000 22:42:14 MST." <200012050542.WAA67217@harmony.village.org> Date: Mon, 04 Dec 2000 22:00:11 -0800 Message-ID: <46236.975996011@winston.osd.bsdi.com> From: Jordan Hubbard Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org With all due respect to everyone in this discussion, Hotmail completed its transition to Win2K about a month and a half ago and evicted the last FreeBSD machine from its premises. I'm sure this was neither easy or even particularly necessary from a technical perspective, but from a marketing perspective they were *very* tired of us making so much marketing hay over FreeBSD at hotmail and when the end finally came, it came very thoroughly. - Jordan > In message Mike Silbersack writes: > : Belittling Microsoft products doesn't solve anything. (Especially > : considering that Microsoft is transitioning hotmail over to w2k now.) > > With all due respect, I'll believe it when the transition is > complete. They tried to transition to WinNT as well. > > Warner > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 4 22: 4: 6 2000 From owner-freebsd-security@FreeBSD.ORG Mon Dec 4 22:04:05 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from daedalus.cs.brandeis.edu (daedalus.cs.brandeis.edu [129.64.3.179]) by hub.freebsd.org (Postfix) with ESMTP id 334B537B400 for ; Mon, 4 Dec 2000 22:04:04 -0800 (PST) Received: from localhost (meshko@localhost) by daedalus.cs.brandeis.edu (8.9.3/8.9.3) with ESMTP id BAA20744; Tue, 5 Dec 2000 01:03:19 -0500 Date: Tue, 5 Dec 2000 01:03:19 -0500 (EST) From: Mikhail Kruk To: Warner Losh Cc: Mike Silbersack , pW , John Howie , Subject: Re: Fw: NAPTHA Advisory Updated - BindView RAZOR In-Reply-To: <200012050542.WAA67217@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: meshko@daedalus.cs.brandeis.edu Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > In message Mike Silbersack writes: > : Belittling Microsoft products doesn't solve anything. (Especially > : considering that Microsoft is transitioning hotmail over to w2k now.) > > With all due respect, I'll believe it when the transition is > complete. They tried to transition to WinNT as well. this is very irrelevant, but Hotmail have been running 2000 for quite a while now and seem to be quite happy about it. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 4 22: 5:10 2000 From owner-freebsd-security@FreeBSD.ORG Mon Dec 4 22:05:07 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (unknown [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 1530F37B400; Mon, 4 Dec 2000 22:05:07 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.0/8.11.0) with ESMTP id eB55YOQ95030; Mon, 4 Dec 2000 22:34:53 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id WAA67175; Mon, 4 Dec 2000 22:34:23 -0700 (MST) Message-Id: <200012050534.WAA67175@harmony.village.org> To: Alfred Perlstein Subject: Re: NAPTHA/RAZOR response. Cc: security@FreeBSD.ORG In-reply-to: Your message of "Mon, 04 Dec 2000 17:25:07 PST." <20001204172505.D8051@fw.wintelcom.net> References: <20001204172505.D8051@fw.wintelcom.net> Date: Mon, 04 Dec 2000 22:34:23 -0700 From: Warner Losh Sender: imp@harmony.village.org Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <20001204172505.D8051@fw.wintelcom.net> Alfred Perlstein writes: : Ok, I can't believe what a bunch of hosers these RAZOR/bindview : guys are, thier "advisory" is nothing new, there was a news article : about 3 years ago talking about this problem, all that RAZOR seems : to have done is find a pretty lame and broken way of spoofing the : source of the attack which doesn't really work. (it's trivial to : find the source of the attack) Yes. We pointed that out to them when they first sent us the attack. It just pulled together some interesting tricks that had been floating around for a while. The arp poisoning was particularly interesting, but requires a machine on the same ethernet segment to be compromised. But I never got a response to these points.... But with enough DDoS boxes, this can present a problem... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 4 22:17:44 2000 From owner-freebsd-security@FreeBSD.ORG Mon Dec 4 22:17:42 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id BA87937B400 for ; Mon, 4 Dec 2000 22:17:42 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eB56Hfw02983; Mon, 4 Dec 2000 22:17:41 -0800 (PST) Date: Mon, 4 Dec 2000 22:17:41 -0800 From: Alfred Perlstein To: Warner Losh Cc: security@FreeBSD.ORG Subject: Re: NAPTHA/RAZOR response. Message-ID: <20001204221741.G8051@fw.wintelcom.net> References: <20001204172505.D8051@fw.wintelcom.net> <200012050534.WAA67175@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200012050534.WAA67175@harmony.village.org>; from imp@village.org on Mon, Dec 04, 2000 at 10:34:23PM -0700 Sender: bright@fw.wintelcom.net Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Warner Losh [001204 22:05] wrote: > In message <20001204172505.D8051@fw.wintelcom.net> Alfred Perlstein writes: > : Ok, I can't believe what a bunch of hosers these RAZOR/bindview > : guys are, thier "advisory" is nothing new, there was a news article > : about 3 years ago talking about this problem, all that RAZOR seems > : to have done is find a pretty lame and broken way of spoofing the > : source of the attack which doesn't really work. (it's trivial to > : find the source of the attack) > > Yes. We pointed that out to them when they first sent us the attack. > It just pulled together some interesting tricks that had been floating > around for a while. The arp poisoning was particularly interesting, > but requires a machine on the same ethernet segment to be compromised. > But I never got a response to these points.... > > But with enough DDoS boxes, this can present a problem... Honestly I had been sitting on the "response" sploit for about a week or so. I had already heard that they were going to release something like this and sent something like it to the person that informed me. Anyhow, after a week I thought that they realized how lame the advisory was and weren't going to release it, but some people... -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Dec 4 22:41: 8 2000 From owner-freebsd-security@FreeBSD.ORG Mon Dec 4 22:41:05 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from daedalus.cs.brandeis.edu (daedalus.cs.brandeis.edu [129.64.3.179]) by hub.freebsd.org (Postfix) with ESMTP id 4140437B401 for ; Mon, 4 Dec 2000 22:41:04 -0800 (PST) Received: from localhost (meshko@localhost) by daedalus.cs.brandeis.edu (8.9.3/8.9.3) with ESMTP id BAA22614; Tue, 5 Dec 2000 01:40:33 -0500 Date: Tue, 5 Dec 2000 01:40:33 -0500 (EST) From: Mikhail Kruk To: Jordan Hubbard Cc: Warner Losh , Mike Silbersack , pW , John Howie , Subject: Re: Fw: NAPTHA Advisory Updated - BindView RAZOR In-Reply-To: <46236.975996011@winston.osd.bsdi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: meshko@daedalus.cs.brandeis.edu Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org uh, sorry didn't see that Jordan already told about that. BTW, here is what I've noticed: if you look at netcraft's report about hotmail http://uptime.netcraft.com/graph/?host=www.hotmail.com it seems that they've added 2 more machines during the transition. Which, if I interpret data correctly, means that they had to increase their machine park by almost 30%. > With all due respect to everyone in this discussion, Hotmail completed > its transition to Win2K about a month and a half ago and evicted the > last FreeBSD machine from its premises. > > I'm sure this was neither easy or even particularly necessary from a > technical perspective, but from a marketing perspective they were > *very* tired of us making so much marketing hay over FreeBSD at > hotmail and when the end finally came, it came very thoroughly. > > - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Dec 5 1:16:52 2000 From owner-freebsd-security@FreeBSD.ORG Tue Dec 5 01:16:50 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from area51.v-wave.com (area51.v-wave.com [24.108.173.252]) by hub.freebsd.org (Postfix) with SMTP id D04B437B400 for ; Tue, 5 Dec 2000 01:16:49 -0800 (PST) Received: (qmail 20530 invoked by uid 1001); 5 Dec 2000 09:16:49 -0000 Date: Tue, 5 Dec 2000 02:16:49 -0700 From: Chris Wasser To: freebsd-security@FreeBSD.ORG Subject: Re: Fw: IDIOT Message-ID: <20001205021648.A20339@skunkworks.area51-arpa.mil> References: <012f01c05e5b$fb9450d0$fd01a8c0@pacbell.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <012f01c05e5b$fb9450d0$fd01a8c0@pacbell.net>; from JHowie@msn.com on Mon, Dec 04, 2000 at 05:37:51PM -0800 X-Operating-System: FreeBSD 4.2-STABLE Sender: flatline@area51.v-wave.com Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon 04 Dec 2000, John Howie wrote: > won't point out the nearly two decades of UNIX experience that I have, or my > kernel development experience. What I will say is that the coward who sent John, That's interesting, with two decades of UNIX experience and kernel development, that someone of your stated experience wouldn't see the obvious lunacy to the NAPTHA "advisory". This "Denial of Service" attack has existed for a VERY long time (anyone remember octopus?), and the FreeBSD install can be easily configured right out of the box (and other services such as ssh are pre-set to handle this problem out-of-the-box) to alleviate this problem. More advanced measures can also be employed (man dummynet(4) for example) To say, "FreeBSD failed" in this respect is not only uneducated, but ignorant of the real issue. Two decades of experience? As I see it, you're doing nothing but spreading F.U.D with a obvious lack of knowledge of the problem. Perhaps you should spend more time re-examining your "experience" and perhaps seek re-education before you start posting to the mailing lists (a good place to start on your journey would be by subscribing to freebsd-newbies@FreeBSD.ORG -- It's not too fast paced and you should have no problem keeping up.) There's a word for people like you, what's it called now? sincerely, Chris Wasser To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Dec 5 2:28:33 2000 From owner-freebsd-security@FreeBSD.ORG Tue Dec 5 02:28:32 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 1A61A37B400 for ; Tue, 5 Dec 2000 02:27:16 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id LAA23400; Tue, 5 Dec 2000 11:26:53 +0100 (CET) (envelope-from des@ofug.org) Sender: des@ofug.org X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Andy Farkas Cc: Chris Wasser , "Roberto Samarone Araujo (RSA)" , freebsd-security@FreeBSD.ORG Subject: Re: FreeBSD security check --footnote References: From: Dag-Erling Smorgrav Date: 05 Dec 2000 11:26:52 +0100 In-Reply-To: Andy Farkas's message of "Tue, 5 Dec 2000 12:23:32 +1100 (EST)" Message-ID: Lines: 10 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Andy Farkas writes: > You _should_ be able to send the output of periodic scripts to any user by > setting ${daily|weekly|mothly}_output in your /etc/periodic.conf file. Or simply by editing /etc/aliases to redirect root mail somewhere else. Don't forget to run newaliases afterwards. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Dec 5 2:46:18 2000 From owner-freebsd-security@FreeBSD.ORG Tue Dec 5 02:46:17 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from ringworld.nanolink.com (pool25-tch-1.Sofia.0rbitel.net [212.95.170.25]) by hub.freebsd.org (Postfix) with SMTP id 771F037B401 for ; Tue, 5 Dec 2000 02:45:29 -0800 (PST) Received: (qmail 2424 invoked by uid 1000); 5 Dec 2000 10:44:49 -0000 Date: Tue, 5 Dec 2000 12:44:48 +0200 From: Peter Pentchev To: freebsd-security@FreeBSD.org Subject: Re: [spam score 10.00/10.0 -pobox] Re: Fw: NAPTHA Advisory Updated - BindView RAZOR Message-ID: <20001205124448.A2404@ringworld.oblivion.bg> Mail-Followup-To: freebsd-security@FreeBSD.org References: <200012050138.SAA03007@faith.cs.utah.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from matt@ARPA.MAIL.NET on Mon, Dec 04, 2000 at 09:39:39PM -0500 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Dec 04, 2000 at 09:39:39PM -0500, Matt Heckaman wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Mon, 4 Dec 2000, David G. Andersen wrote: > ... > : Nope. It wasn't a kernel problem you were encountering - it was a > : systemwide resource limit being reached. It's not that there's a _bug_ in > : the kernel, it's that the processes file table limits weren't isolated > : from each other. The right solution to this is more isolation of > : different processes (e.g. resource control). > > It would be nice if one could set login.conf(5) style resource limits per > daemon instead of per login. Thus we could say, well "{q,send}mail can > have 1024 fds" while apache can have 4096.. etc. Maybe there is a way to > do this (djb's tcpserver? xinetd?) but I'm not currently aware of one. Not tcpserver by itself, but tcpserver in conjunction with the daemontools package can serve very well to place per-daemon limits. The dnscache/tinydns setup in the djbdns package is a nice example of how to use svscan and the related daemontools programs for resource usage control. G'luck, Peter -- If I had finished this sentence, To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Dec 5 8: 5:53 2000 From owner-freebsd-security@FreeBSD.ORG Tue Dec 5 08:05:50 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from homer.softweyr.com (bsdconspiracy.net [208.187.122.220]) by hub.freebsd.org (Postfix) with ESMTP id A078737B400 for ; Tue, 5 Dec 2000 08:05:49 -0800 (PST) Received: from [127.0.0.1] (helo=softweyr.com ident=Fools trust ident!) by homer.softweyr.com with esmtp (Exim 3.16 #1) id 143KeJ-0000Om-00; Tue, 05 Dec 2000 09:08:59 -0700 Sender: wes@FreeBSD.ORG Message-ID: <3A2D131B.2548F379@softweyr.com> Date: Tue, 05 Dec 2000 09:08:59 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: John Howie Cc: "David G. Andersen" , freebsd-security@FreeBSD.ORG Subject: Re: Fw: NAPTHA Advisory Updated - BindView RAZOR References: <200012050043.RAA27046@faith.cs.utah.edu> <011701c05e5a$bcfb3060$fd01a8c0@pacbell.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org John Howie wrote: > > David Andersen wrote: > > > This isn't a FreeBSD failure per se, but a resource control > > failure. Whether you want to point a finger at FreeBSD, ssh, or the > > operator of the box is entirely up to you. :-) > > > > I'm afraid I disagree - this is not purely a daemon problem. I wonder if you > had time to read the whole advisory for the FreeBSD information near the end > of the report (I've included it below). I'm sure he, just as I, read it and found it to report only daemon attacks: > > > > FreeBSD - FreeBSD 4.0-REL > > > > > > > > In testing FreeBSD, a few specific > > > > daemons/ports were targeted. For some, the > > > > stability of the system as a whole can be > > > > affected. The daemons targeted in this > > > > testing are not necessarily at fault for > > > > the problems encountered. > > > > > > > > SSH: > > > > > > > > NFS: > > > > > > > > BIND: > > > > > > > > Note: These services/ports can be > > > > similarly affected on other Linux and UNIX > > > > variants. > > If a daemon becomes unusable because it is subject to attack then that is, > while not ideal, at least tolerable. When the whole system becomes unusable > that points to problems in the kernel. They don't substantiate their vague claim of "the stability of the system as a whole can be affected." All of the specific instances they do list ARE daemon attacks. On the other hand, if they are attacking NFS, I can certainly see that making the system somewhat unstable, but it is better in 4.2. As David pointed out, NFS is usually NOT exposed outside your firewall. You do have a firewall, don't you? ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Dec 5 10:39: 7 2000 From owner-freebsd-security@FreeBSD.ORG Tue Dec 5 10:39:04 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 54E2337B401 for ; Tue, 5 Dec 2000 10:39:04 -0800 (PST) Received: from foo.osd.bsdi.com (root@foo.osd.bsdi.com [204.216.28.137]) by pike.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id eB5IcOC48413; Tue, 5 Dec 2000 10:38:24 -0800 (PST) (envelope-from jhb@foo.osd.bsdi.com) Received: (from jhb@localhost) by foo.osd.bsdi.com (8.11.1/8.11.0) id eB5IcSI43468; Tue, 5 Dec 2000 10:38:28 -0800 (PST) (envelope-from jhb) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200012050544.eB55iVb72562@sivka.rdy.com> Date: Tue, 05 Dec 2000 10:38:28 -0800 (PST) Organization: BSD, Inc. From: John Baldwin To: (Dima Ruban) Subject: Re: Fw: NAPTHA Advisory Updated - BindView RAZOR Cc: freebsd-security@FreeBSD.ORG, John Howie , pW , Mike Silbersack Sender: jhb@foo.osd.bsdi.com Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 05-Dec-00 Dima Ruban wrote: > Mike Silbersack writes: >> Belittling Microsoft products doesn't solve anything. (Especially >> considering that Microsoft is transitioning hotmail over to w2k now.) > > Yeah, right. That's what they were saying when trying to convert hotmail > to NT. Get your facts right: The site www.hotmail.com runs Microsoft-IIS/5.0 on Windows 2000 (from www.netcraft.com) -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Dec 5 11:59:29 2000 From owner-freebsd-security@FreeBSD.ORG Tue Dec 5 11:59:26 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from dh198-236.dhcp.sunysb.edu (dh198-236.dhcp.sunysb.edu [129.49.198.236]) by hub.freebsd.org (Postfix) with ESMTP id 4435137B401; Tue, 5 Dec 2000 11:59:25 -0800 (PST) Received: (from chris@localhost) by dh198-236.dhcp.sunysb.edu (8.9.3/8.9.3) id OAA58321; Tue, 5 Dec 2000 14:59:03 -0500 (EST) (envelope-from chris) From: Christopher Rued MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14893.18695.137802.231334@chris.xsb.com> Date: Tue, 5 Dec 2000 14:59:03 -0500 (EST) To: John Baldwin Cc: (Dima Ruban) , freebsd-security@FreeBSD.ORG, John Howie , pW , Mike Silbersack Subject: Re: Fw: NAPTHA Advisory Updated - BindView RAZOR In-Reply-To: References: <200012050544.eB55iVb72562@sivka.rdy.com> X-Mailer: VM 6.75 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid Sender: chris@dh198-236.dhcp.sunysb.edu Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org John Baldwin writes: > > On 05-Dec-00 Dima Ruban wrote: > > Mike Silbersack writes: > >> Belittling Microsoft products doesn't solve anything. (Especially > >> considering that Microsoft is transitioning hotmail over to w2k now.) > > > > Yeah, right. That's what they were saying when trying to convert hotmail > > to NT. > > Get your facts right: > > The site www.hotmail.com runs Microsoft-IIS/5.0 on Windows 2000 > > (from www.netcraft.com) But, lurking in the depths of hotmail, the daemon lives! :-) gfx.law10.hotmail.com, gfx.law9.hotmail.com, gfx.pav1.hotmail.com, and probably more all run FreeBSD... See: http://uptime.netcraft.com/hosted?netname=HOTMAIL,64.4.0.0,64.4.63.255 -Chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Dec 5 21:25:23 2000 From owner-freebsd-security@FreeBSD.ORG Tue Dec 5 21:25:14 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mail.iconz.co.nz (etrn.iconz.co.nz [210.48.22.36]) by hub.freebsd.org (Postfix) with ESMTP id 4A46837B69C; Tue, 5 Dec 2000 21:24:56 -0800 (PST) Received: from creativejuice.co.nz (ip-210-48-60-242.iconz.net.nz [210.48.60.242] (may be forged)) by mail.iconz.co.nz (8.9.3/8.9.3) with ESMTP id SAA043700976080139; Wed, 6 Dec 2000 18:22:19 +1300 (NZDT) From: tom@aba.com Message-Id: <200012060522.SAA043700976080139@mail.iconz.co.nz> Received: from [62.159.146.73] by [192.168.1.2] with SMTP (QuickMail Pro Server for Mac 2.0.1); 06-Dec-2000 18:23:08 +1300 To: Subject: Search Engine Optimization Kit-2001 24123 Date: Wed, 06 Dec 2000 00:16:29 -0500 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 1 X-MSMail-Priority: High Errors-To: X-Mailer: Outlook Express X-Originating-IP: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org
Get Top 10 Positions With The Search Engine Optimization Kit-2001

No hype ... no gimmicks ... just the facts ... and only $59!

Hello Friend,

We created the Search Engine Optimization Kit-2001 to achieve high positions in search engines. This unique Kit includes:
  • Detailed information about how search engines work,

  • Step-by-step instructions to create, high-ranking,"search-= engine-friendly" pages,

  • All the tools and resources you need to create pages, submit to= engines and track your placements, and

  • Ongoing personal support by email and phone.

Click to receive Free In= formation about Search Engines and the Kit, or call direct to 937-640-2762.

We reply promptly to all inquires.

Dr. Jerry R. Perrich, Director
The Internet Marketing Institute, Inc.
Helping You Be Successful Online
937-640-2762


PS - Please forward this email to any of your business associates or friends who may benefit from it.

REMOVAL INSTRUCTIONS=
Per federal legislation, you can be removed from this mailing list at no c= ost to you by simply clicking here Remove Ple= ase. You will be promptly removed. Please note that interfering with this feder= ally approved method of removal will deny others the opportunity to be removed.

<= p>

To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Dec 5 23:15:55 2000 From owner-freebsd-security@FreeBSD.ORG Tue Dec 5 23:15:52 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from eeyore.sebster.com (e163161.upc-e.chello.nl [213.93.163.161]) by hub.freebsd.org (Postfix) with SMTP id 173BF37B400 for ; Tue, 5 Dec 2000 23:15:51 -0800 (PST) Received: (qmail 50328 invoked by uid 1000); 6 Dec 2000 07:15:49 -0000 Date: Wed, 6 Dec 2000 08:15:49 +0100 From: Sebastiaan van Erk To: freebsd-security@freebsd.org Subject: rx list Message-ID: <20001206081549.A49341@sebster.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: sebster@eeyore.sebster.com Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Good morning everybody!! I have a question. Yesterday two production firewalls were (probably) attacked using a DoS attack. One of them is running 4.1.1-RELEASE, the other is running 3.4-STABLE. I get these kind of messages in the syslog of both machines. Dec 6 00:09:43 hobbes /kernel: Out of mbuf clusters - adjust NMBCLUSTERS or inc rease maxusers! Dec 6 00:09:43 hobbes /kernel: xl2: no memory for rx list -- packet dropped! Dec 6 00:09:43 hobbes /kernel: xl1: no memory for rx list -- packet dropped! I checked on the net, but it seems to suggest that systems after 3.2 and 4.0 should be safe. Also I don't see any patches. How likely is it that this is a DoS attack (note that we also get the message on the internal interface!)? And how do I go about fixing it? (I can increase maxusers and NMBCLUSTERS, but then how do I know it's not going to happen again?). Thanks in advance, Sebastiaan van Erk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Dec 5 23:23:35 2000 From owner-freebsd-security@FreeBSD.ORG Tue Dec 5 23:23:32 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from sunny.pacific.net.sg (sunny.pacific.net.sg [203.120.90.127]) by hub.freebsd.org (Postfix) with ESMTP id 508C837B400 for ; Tue, 5 Dec 2000 23:23:31 -0800 (PST) Received: from pop1.pacific.net.sg (pop1.pacific.net.sg [203.120.90.85]) by sunny.pacific.net.sg with ESMTP id eB67NTo05458; Wed, 6 Dec 2000 15:23:29 +0800 (SGT) Received: from gchang (spoff250.pacific.net.sg [203.120.94.250]) by pop1.pacific.net.sg with SMTP id PAA05564; Wed, 6 Dec 2000 15:23:26 +0800 (SGT) Message-ID: <002801c05f55$0a492ac0$fa5e78cb@gchang> From: "James Lim" To: "Sebastiaan van Erk" , References: <20001206081549.A49341@sebster.com> Subject: Re: rx list Date: Wed, 6 Dec 2000 15:20:40 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi there, You could try increasing the maxusers to 512 and later increase your NMBCLUSTERS to prolly 50000. How much ram does your machine has as well as the CPU speed? Btw i was wondering whether the new accept filter helps in DoS attacks. options ACCEPT_FILTER_DATA options ACCEPT_FILTER_HTTP options TCP_DROP_SYNFIN #drop TCP packets with SYN+FIN options TCP_RESTRICT_RST #restrict emission of TCP RST options ICMP_BANDLIM to the newsgroup, correct me if I am wrong, thank you! James Lim Technical Support Executive Pacific Internet Limited 89 Science Park Drive #02-05/06 The Rutherford Singapore 118261 Finger evilfry@sg.freebsd.org for PGP key. ----- Original Message ----- From: "Sebastiaan van Erk" To: Sent: Wednesday, December 06, 2000 3:15 PM Subject: rx list > Good morning everybody!! > > I have a question. Yesterday two production firewalls were (probably) > attacked using a DoS attack. > > One of them is running 4.1.1-RELEASE, the other is running 3.4-STABLE. > > I get these kind of messages in the syslog of both machines. > > Dec 6 00:09:43 hobbes /kernel: Out of mbuf clusters - adjust NMBCLUSTERS or inc > rease maxusers! > Dec 6 00:09:43 hobbes /kernel: xl2: no memory for rx list -- packet dropped! > Dec 6 00:09:43 hobbes /kernel: xl1: no memory for rx list -- packet dropped! > > I checked on the net, but it seems to suggest that systems after 3.2 and 4.0 > should be safe. Also I don't see any patches. > > How likely is it that this is a DoS attack (note that we also get the message > on the internal interface!)? And how do I go about fixing it? (I can increase > maxusers and NMBCLUSTERS, but then how do I know it's not going to happen > again?). > > Thanks in advance, > Sebastiaan van Erk > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Dec 5 23:26: 4 2000 From owner-freebsd-security@FreeBSD.ORG Tue Dec 5 23:26:01 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from pilikia.net (pilikia.net [12.36.98.183]) by hub.freebsd.org (Postfix) with ESMTP id 57D5537B400 for ; Tue, 5 Dec 2000 23:26:00 -0800 (PST) Received: from gecko (gecko.local.pilikia.net [192.168.0.9]) by pilikia.net (8.11.1/8.11.1) with ESMTP id eB67PxK29323 for ; Tue, 5 Dec 2000 21:25:59 -1000 (HST) (envelope-from art@pilikia.net) Message-ID: <200012052125590600.07C1781E@smtp> X-Mailer: Calypso Version 3.10.03.02 (3) Date: Tue, 05 Dec 2000 21:25:59 -1000 Reply-To: art@pilikia.net From: "Arthur W. Neilson III" To: freebsd-security@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hey guys, take a look at the headers from this posting to freebsd-security. It apparently is from tom@pilikia.net however there is no "tom" at= pilikia.net, no one uses my system except for me. Looks like someone at 62.159.146.73 (mail.soan.de) knows how to forge the from line, whoopie. So what's the= best way to deal with this problem? Thanks! > Return-Path: > Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by >= pilikia.net (8.11.1/8.11.1) with ESMTP id eB65QvK28925 for= ; Tue, 5 > Dec 2000 19:26:57 -1000 (HST) (envelope-from= owner-freebsd-> security@FreeBSD.ORG) > Received: from hub.freebsd.org (hub.FreeBSD.org [216.136.204.18]) by >= mx1.FreeBSD.org (Postfix) with ESMTP id 68D1E6E2E34; Tue, 5 Dec 2000 >= 21:25:26 -0800 (PST) > Received: by hub.freebsd.org (Postfix, from userid 538) id 4900037B6B7;= Tue, 5 > Dec 2000 21:25:23 -0800 (PST) > Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org= (Postfix) with > SMTP id BE47F2E8183; Tue, 5 Dec 2000 21:25:22 -0800= (PST) > Received: by hub.freebsd.org (bulk_mailer v1.12); Tue, 5 Dec 2000= 21:25:22 -0800 > Delivered-To: freebsd-security@freebsd.org > Received: from mail.iconz.co.nz (etrn.iconz.co.nz [210.48.22.36]) by >= hub.freebsd.org (Postfix) with ESMTP id 4A46837B69C; Tue, 5 Dec 2000= 21:24:56 -> 0800 (PST) > Received: from creativejuice.co.nz (ip-210-48-60-242.iconz.net.nz= [210.48.60.242] > (may be forged)) by mail.iconz.co.nz (8.9.3/8.9.3) with= ESMTP id > SAA043700976080139; Wed, 6 Dec 2000 18:22:19 +1300 (NZDT) > From: tom@pilikia.net > Message-Id: <200012060522.SAA043700976080139@mail.iconz.co.nz> > Received: from [62.159.146.73] by [192.168.1.2] with SMTP (QuickMail Pro= Server for > Mac 2.0.1); 06-Dec-2000 18:23:08 +1300 > To: > Subject: Search Engine Optimization Kit-2001= 24123 > Date: Wed, 06 Dec 2000 00:16:29 -0500 > MIME-Version: 1.0 > Content-Type: text/html; charset=3D"iso-8859-1" > Content-Transfer-Encoding: quoted-printable > X-Priority: 1 > X-MSMail-Priority: High > X-Mailer: Outlook Express > X-Originating-IP: > Sender: owner-freebsd-security@FreeBSD.ORG > X-Loop: FreeBSD.org > Precedence: bulk -- __ / ) _/_ It is a capital mistake to theorise before one has data. /--/ __ / Insensibly one begins to twist facts to suit theories, / (_/ (_<__ Instead of theories to suit facts. -- Sherlock Holmes, "A Scandal in Bohemia" Arthur W. Neilson III, WH7N - FISTS #7448 Bank of Hawaii Tech Support http://www.pilikia.net art@pilikia.net, aneilson@boh.com, wh7n@arrl.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 6 1:17:23 2000 From owner-freebsd-security@FreeBSD.ORG Wed Dec 6 01:17:21 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 7E4AC37B400 for ; Wed, 6 Dec 2000 01:17:20 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id KAA28415; Wed, 6 Dec 2000 10:17:08 +0100 (CET) (envelope-from des@ofug.org) Sender: des@ofug.org X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: "James Lim" Cc: "Sebastiaan van Erk" , Subject: Re: rx list References: <20001206081549.A49341@sebster.com> <002801c05f55$0a492ac0$fa5e78cb@gchang> From: Dag-Erling Smorgrav Date: 06 Dec 2000 10:17:07 +0100 In-Reply-To: "James Lim"'s message of "Wed, 6 Dec 2000 15:20:40 +0800" Message-ID: Lines: 19 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "James Lim" writes: > You could try increasing the maxusers to 512 and later increase > your NMBCLUSTERS to prolly 50000. Maxusers is practically meaningless nowadays. It controls MAXFILES, NMBCLUSTERS, NPROC and NSFBUFS, but MAXFILES and NMBCLUSTERS are sysctl-settable (MAXFILES at runtime and NMBCLUSTERS at boot time), and there's no reason why NPROC and NSFBUFS couldn't also be set at boot time (patches are welcome!). To solve the specific problem of running out of mbufs, add kern.ipc.nmbclusters="large_number" to your /boot/loader.conf. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 6 1:33:39 2000 From owner-freebsd-security@FreeBSD.ORG Wed Dec 6 01:33:36 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from ns.1dz.cz (ns.1dz.cz [195.47.13.161]) by hub.freebsd.org (Postfix) with ESMTP id 267B437B400 for ; Wed, 6 Dec 2000 01:33:34 -0800 (PST) Received: from 1dz-ova-gate.1dz.cz (ns2.ova.1dz.cz [195.47.13.165]) by ns.1dz.cz (8.9.3/8.9.3) with SMTP id KAA07169; Wed, 6 Dec 2000 10:56:56 +0100 Received: from 1Cust125.tnt1.canoga-park.ca.da.uu.net ([63.22.174.125]) by 1dz-ova-gate.1dz.cz (602Pro INTERNET SERVER v3.32c) id 00267fd6; Wed, 6 Dec 2000 9:54:56 +0100 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT Date: Wed, 06 Dec 2000 00:55:01 -0800 From: LikeOnTV@asean-mail.com Message-Id: <1w151r0ih.f5q7vp7@mx2.mail.yahoo.com> To: vomelg@portableoffice.com Subject: Do Your Own Background Checks! X-Mailer: Mozilla 4.61 [en] (Win95; I) Sender: babsknow@bangkok.com Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org THIS NEW AMAZING SOFTWARE TOOL HELPS YOU FIND OUT ALMOST ANYTHING ABOUT ANYONE - CLICK ON URL BELOW TO VISIT OUR WEBSITE http://home.netcitizen.com/nesyten/ ********************************************************** Find out almost EVERYTHING you ever wanted to know about: Your friends Your family Your enemies Your employees Yourself - Is Someone Using Your Identity? Even your boss! DID YOU KNOW you can search for ANYONE, ANYTIME, ANYWHERE, right on the Internet.. This mammoth COLLECTION of Internet investigative tools & research sites will provide you with NEARLY 400 GIGANTIC SEARCH RESOURCES to locate information on: People you trust Screen new tenants or roommates Housekeepers Current or past employment People you work with License plate number with name and address Unlisted phone numbers Long lost friends A new or old LOVE INTEREST You can even VERIFY your own CREDIT REPORTS so you can correct WRONG information These are only a few things you can do, There is no limit to the power of this information tool!! CLICK ON URL BELOW TO VISIT OUR WEBSITE http://home.netcitizen.com/nesyten/ ****************************************************** To be removed from our mailing list, send a message to abotmdnite@ninfan.com with the word "Remove" in the subject. mailto:newmemat@bolt.com?subject=remove To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 6 1:58:50 2000 From owner-freebsd-security@FreeBSD.ORG Wed Dec 6 01:58:47 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from adm.sci-nnov.ru (adm.sci-nnov.ru [195.122.226.2]) by hub.freebsd.org (Postfix) with ESMTP id B49C937B400; Wed, 6 Dec 2000 01:58:44 -0800 (PST) Received: from anonymous.sandy.ru (anonymous.sandy.ru [195.122.226.40]) by adm.sci-nnov.ru (8.9.3/Dmiter-4.1-AGK-0.3) with ESMTP id MAA32960; Wed, 6 Dec 2000 12:57:14 +0300 (MSK) Date: Wed, 6 Dec 2000 12:57:14 +0300 From: Vladimir Dubrovin X-Mailer: The Bat! (v1.47 Halloween Edition) Reply-To: Vladimir Dubrovin Organization: Sandy Info X-Priority: 3 (Normal) Message-ID: <9862415618.20001206125714@sandy.ru> To: freebsd-security@freebsd.org Cc: owner-freebsd-security@FreeBSD.ORG Subject: All this SPAM... Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello freebsd-security, Since the amount of SPAM in the list exceeds amount of useful information, may be it's a time to make this list slightly moderated? I mean minimal moderation - only against SPAM and unrelated topics. -- Vladimir Dubrovin Sandy, ISP Sandy CCd chief Customers Care dept http://www.sandy.ru Nizhny Novgorod, Russia http://www.security.nnov.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 6 2:43:17 2000 From owner-freebsd-security@FreeBSD.ORG Wed Dec 6 02:43:13 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from aurora.scoop.co.nz (aurora.scoop.co.nz [203.96.152.68]) by hub.freebsd.org (Postfix) with ESMTP id EBB7037B400 for ; Wed, 6 Dec 2000 02:43:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by aurora.scoop.co.nz (8.9.3/8.9.3) with SMTP id XAA11689; Wed, 6 Dec 2000 23:42:58 +1300 (NZDT) Date: Wed, 6 Dec 2000 23:42:57 +1300 (NZDT) From: Andrew McNaughton Reply-To: andrew@scoop.co.nz To: "Arthur W. Neilson III" Cc: freebsd-security@FreeBSD.ORG Subject: Re: your mail In-Reply-To: <200012052125590600.07C1781E@smtp> Message-ID: Priority: Normal MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org It's tempting when reading mail headers to start working up from the last Recieved header, but this is unreliable. It is becoming common place to see forged Recieved headers. In this case, starting from the top, each line looks credible above the 'From:' line. The next 3 lines are worth a bit of thought. I believe the line saynig that the server which knows itself as mail.iconz.co.nz, but is known to the world as etrn.iconz.co.nz (iconz.co.nz primary mail exchanger) recieved the mail. If it had assigned the Message-Id, I would expect that to appear above the 'Recieved' line. I very much doubt that it assigned the 'From' address either. The line below these two is also forged. How on earth could a machine on Iconz network in new zealand recieve a message from germany on a private IP number? I figure this is simply forged. The IPs could have resulted from someone using an open relay behind an network address translating gateway, and I don't know enough about "QuickMail Pro Server for Mac 2.0.1" to be sure that it doesn't have a bug which means it can pass on messages without adding a Message-ID header when required, but I don't see any innocent explanations for the location of the From header. Therefore, my reading of these headers is that the originator was the user who was on iconz dialup line with IP 210.48.60.242 at Wed, 6 Dec 2000 18:22:19 +1300. I've dealt with iconz staff over mail abuse issues in the past and found them pretty responsive. I suggest you get in touch with them. They have been bought out by asiaonline, and I seem to remember finding one or other of the abuse@ addresses was missing last time I needed to contact them. Try abuse@asiaonline.co.nz. Andrew McNaughton On Tue, 5 Dec 2000, Arthur W. Neilson III wrote: > Date: Tue, 05 Dec 2000 21:25:59 -1000 > From: "Arthur W. Neilson III" > To: freebsd-security@FreeBSD.ORG > > Hey guys, take a look at the headers from this posting to freebsd-security. > It apparently is from tom@pilikia.net however there is no "tom" at pilikia.net, > no one uses my system except for me. Looks like someone at 62.159.146.73 > (mail.soan.de) knows how to forge the from line, whoopie. So what's the best > way to deal with this problem? > > Thanks! > > > Return-Path: > > Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by > pilikia.net (8.11.1/8.11.1) with ESMTP id eB65QvK28925 for ; Tue, 5 > Dec 2000 19:26:57 -1000 (HST) (envelope-from owner-freebsd-> security@FreeBSD.ORG) > > Received: from hub.freebsd.org (hub.FreeBSD.org [216.136.204.18]) by > mx1.FreeBSD.org (Postfix) with ESMTP id 68D1E6E2E34; Tue, 5 Dec 2000 > 21:25:26 -0800 (PST) > > Received: by hub.freebsd.org (Postfix, from userid 538) id 4900037B6B7; Tue, 5 > Dec 2000 21:25:23 -0800 (PST) > > Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with > SMTP id BE47F2E8183; Tue, 5 Dec 2000 21:25:22 -0800 (PST) > > Received: by hub.freebsd.org (bulk_mailer v1.12); Tue, 5 Dec 2000 21:25:22 -0800 > > Delivered-To: freebsd-security@freebsd.org > > Received: from mail.iconz.co.nz (etrn.iconz.co.nz [210.48.22.36]) by > hub.freebsd.org (Postfix) with ESMTP id 4A46837B69C; Tue, 5 Dec 2000 21:24:56 -> 0800 (PST) > > Received: from creativejuice.co.nz (ip-210-48-60-242.iconz.net.nz [210.48.60.242] > (may be forged)) by mail.iconz.co.nz (8.9.3/8.9.3) with ESMTP id > SAA043700976080139; Wed, 6 Dec 2000 18:22:19 +1300 (NZDT) > > From: tom@pilikia.net > > Message-Id: <200012060522.SAA043700976080139@mail.iconz.co.nz> > > Received: from [62.159.146.73] by [192.168.1.2] with SMTP (QuickMail Pro Server for > > Mac 2.0.1); 06-Dec-2000 18:23:08 +1300 > > To: > > Subject: Search Engine Optimization Kit-2001 24123 > > Date: Wed, 06 Dec 2000 00:16:29 -0500 > > MIME-Version: 1.0 > > Content-Type: text/html; charset="iso-8859-1" > > Content-Transfer-Encoding: quoted-printable > > X-Priority: 1 > > X-MSMail-Priority: High > > X-Mailer: Outlook Express > > X-Originating-IP: > > Sender: owner-freebsd-security@FreeBSD.ORG > > X-Loop: FreeBSD.org > > Precedence: bulk > > -- > __ > / ) _/_ It is a capital mistake to theorise before one has data. > /--/ __ / Insensibly one begins to twist facts to suit theories, > / (_/ (_<__ Instead of theories to suit facts. > -- Sherlock Holmes, "A Scandal in Bohemia" > Arthur W. Neilson III, WH7N - FISTS #7448 > Bank of Hawaii Tech Support > http://www.pilikia.net > art@pilikia.net, aneilson@boh.com, wh7n@arrl.net > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > -- Andrew McNaughton Scoop Media Ltd andrew@scoop.co.nz To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 6 2:59:24 2000 From owner-freebsd-security@FreeBSD.ORG Wed Dec 6 02:59:22 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from aurora.scoop.co.nz (aurora.scoop.co.nz [203.96.152.68]) by hub.freebsd.org (Postfix) with ESMTP id 98B7437B400 for ; Wed, 6 Dec 2000 02:59:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by aurora.scoop.co.nz (8.9.3/8.9.3) with SMTP id XAA11972; Wed, 6 Dec 2000 23:59:15 +1300 (NZDT) Date: Wed, 6 Dec 2000 23:59:14 +1300 (NZDT) From: Andrew McNaughton Reply-To: andrew@scoop.co.nz To: "Arthur W. Neilson III" Cc: freebsd-security@FreeBSD.ORG Subject: Re: your mail In-Reply-To: <200012052125590600.07C1781E@smtp> Message-ID: Priority: Normal MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Depending on the behaviour of your own mail server, you might find that if it recieves mail with 'From: tom' in the headers, it adds its local domain name to the address. That said, I seem to have a similar message which says it is from tom@aba.com. My domain is not aba.com, and this doesn't match any server the message has passed on the way. Andrew McNaughton On Tue, 5 Dec 2000, Arthur W. Neilson III wrote: > Hey guys, take a look at the headers from this posting to freebsd-security. > It apparently is from tom@pilikia.net however there is no "tom" at pilikia.net, > no one uses my system except for me. Looks like someone at 62.159.146.73 > (mail.soan.de) knows how to forge the from line, whoopie. So what's the best > way to deal with this problem? > > Thanks! -- Andrew McNaughton Scoop Media Ltd andrew@scoop.co.nz To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 6 5:35:54 2000 From owner-freebsd-security@FreeBSD.ORG Wed Dec 6 05:35:53 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from haba.uven.ru (haba.uven.ru [62.76.35.176]) by hub.freebsd.org (Postfix) with ESMTP id E930737B400 for ; Wed, 6 Dec 2000 05:35:46 -0800 (PST) Received: (from agv@localhost) by haba.uven.ru (8.11.1/8.11.1) id eB6DWDl03448 for freebsd-security@FreeBSD.ORG; Wed, 6 Dec 2000 16:32:13 +0300 (MSK) (envelope-from agv) Date: Wed, 6 Dec 2000 16:32:13 +0300 (MSK) From: Alexander Gavrilov Message-Id: <200012061332.eB6DWDl03448@haba.uven.ru> To: freebsd-security@FreeBSD.ORG Subject: TIS Firewall Tookit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi people! What do you think about TIS Firewall Toolkit? Thanks. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 6 6: 3:45 2000 From owner-freebsd-security@FreeBSD.ORG Wed Dec 6 06:03:42 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from saturn.innonet.at (saturn.innonet.at [194.152.190.3]) by hub.freebsd.org (Postfix) with ESMTP id DE2F437B401 for ; Wed, 6 Dec 2000 06:03:40 -0800 (PST) Received: from saturn.innonet.at (IDENT:pm@saturn.innonet.at [194.152.190.3]) by saturn.innonet.at (8.10.1/8.10.1) with ESMTP id eB6E33s20503; Wed, 6 Dec 2000 15:03:03 +0100 Date: Wed, 6 Dec 2000 15:03:03 +0100 (MET) From: Manfred Petz X-Sender: pm@saturn.innonet.at To: Alexander Gavrilov Cc: freebsd-security@FreeBSD.ORG Subject: Re: TIS Firewall Tookit In-Reply-To: <200012061332.eB6DWDl03448@haba.uven.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 6 Dec 2000, Alexander Gavrilov wrote: | Hi people! | What do you think about TIS Firewall Toolkit? | Thanks. I've been using it for years and I regret it. I had to apply tons of patches to fix various problems with http-gw and smap (3rd party relay). A couple of times I even had to debug and fix problems by myself because either there was no patch or I couldn't find out where to get a patch. TIS is supporting only it's commercial version, Gauntlet. And understandably they have no great ambitions for FWTK. If you dont't want to or can't use SOCKS then for a proxy based firewall you may take a look at delegate(1). I'm using it at one site (though I don't have much experience with it). pm To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 6 6: 4:11 2000 From owner-freebsd-security@FreeBSD.ORG Wed Dec 6 06:04:10 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from smtp.nettoll.com (unknown [212.155.143.61]) by hub.freebsd.org (Postfix) with ESMTP id ABA1E37B401 for ; Wed, 6 Dec 2000 06:04:08 -0800 (PST) Received: by smtp.nettoll.com; Wed, 6 Dec 2000 15:01:45 +0100 (MET) Message-Id: <4.3.0.20001206150604.05998d30@pop.free.fr> X-Sender: usebsd@pop.free.fr X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Wed, 06 Dec 2000 15:07:10 +0100 To: Matt Heckaman , "David G. Andersen" From: mouss Subject: Re: [spam score 10.00/10.0 -pobox] Re: Fw: NAPTHA Advisory Updated - BindView RAZOR Cc: FreeBSD-SECURITY In-Reply-To: References: <200012050138.SAA03007@faith.cs.utah.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 21:39 04/12/00 -0500, Matt Heckaman wrote: >It would be nice if one could set login.conf(5) style resource limits per >daemon instead of per login. Thus we could say, well "{q,send}mail can >have 1024 fds" while apache can have 4096.. etc. Maybe there is a way to >do this (djb's tcpserver? xinetd?) but I'm not currently aware of one. isn't enough to create an account for each server or group of servers, and use login.conf for the users? >One thing though, it would be nice to see FreeBSD's default fd & >nmbcluster setting be raised, as it really isn't going to be enough for a >lot of people in normal use, and damn sure won't stand up to any kind of >attack like this. Just an opinion though :) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 6 6:10:18 2000 From owner-freebsd-security@FreeBSD.ORG Wed Dec 6 06:10:16 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id 18CF137B400 for ; Wed, 6 Dec 2000 06:10:16 -0800 (PST) Received: by gw.nectar.com (Postfix, from userid 1001) id AC1EA193E1; Wed, 6 Dec 2000 08:10:15 -0600 (CST) Date: Wed, 6 Dec 2000 08:10:15 -0600 From: "Jacques A. Vidrine" To: Manfred Petz Cc: Alexander Gavrilov , freebsd-security@FreeBSD.ORG Subject: Re: TIS Firewall Tookit Message-ID: <20001206081015.B61027@spawn.nectar.com> Mail-Followup-To: "Jacques A. Vidrine" , Manfred Petz , Alexander Gavrilov , freebsd-security@FreeBSD.ORG References: <200012061332.eB6DWDl03448@haba.uven.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from pm@aber.warum.net on Wed, Dec 06, 2000 at 03:03:03PM +0100 X-Url: http://www.nectar.com/ Sender: nectar@nectar.com Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Dec 06, 2000 at 03:03:03PM +0100, Manfred Petz wrote: > I've been using it for years and I regret it. I had to apply tons of > patches to fix various problems with http-gw and smap (3rd party relay). A > couple of times I even had to debug and fix problems by myself because > either there was no patch or I couldn't find out where to get a patch. YMMV. This toolkit is useful, but it _is_ a toolkit -- not a ready-to-run full-featured firewall. The included parts are all small and easily understood -- a huge bonus from the security point-of-view. [snip] > If you dont't want to or can't use SOCKS then for a proxy based firewall > you may take a look at delegate(1). I'm using it at one site (though I > don't have much experience with it). Neither SOCKS nor delegate are firewall software. The latter, in particular, is probably one of the least secure pieces of proxy software ever written. -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 6 6:52:46 2000 From owner-freebsd-security@FreeBSD.ORG Wed Dec 6 06:52:44 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from saturn.innonet.at (saturn.innonet.at [194.152.190.3]) by hub.freebsd.org (Postfix) with ESMTP id 9380337B400 for ; Wed, 6 Dec 2000 06:52:42 -0800 (PST) Received: from saturn.innonet.at (IDENT:pm@saturn.innonet.at [194.152.190.3]) by saturn.innonet.at (8.10.1/8.10.1) with ESMTP id eB6Eovs21485; Wed, 6 Dec 2000 15:50:57 +0100 Date: Wed, 6 Dec 2000 15:50:56 +0100 (MET) From: Manfred Petz X-Sender: pm@saturn.innonet.at To: "Jacques A. Vidrine" Cc: Alexander Gavrilov , freebsd-security@FreeBSD.ORG Subject: Re: TIS Firewall Tookit In-Reply-To: <20001206081015.B61027@spawn.nectar.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 6 Dec 2000, Jacques A. Vidrine wrote: | Neither SOCKS nor delegate are firewall software. The latter, in | particular, is probably one of the least secure pieces of proxy software | ever written. Accepted. Do you know a (free) alternative to FWTK which is comparable in terms of ease of use, straightforward source and which implements similar functionality (e.g. the permit/deny rules in netperm-table)? pm To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 6 6:59:22 2000 From owner-freebsd-security@FreeBSD.ORG Wed Dec 6 06:59:20 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from firefly.prairienet.org (firefly.prairienet.org [192.17.3.3]) by hub.freebsd.org (Postfix) with ESMTP id BF37137B400; Wed, 6 Dec 2000 06:59:19 -0800 (PST) Received: from sherman.spotnet.org (slip-82.prairienet.org [192.17.3.102]) by firefly.prairienet.org (8.9.3/8.9.3) with ESMTP id IAA26555; Wed, 6 Dec 2000 08:59:04 -0600 (CST) Date: Wed, 6 Dec 2000 08:59:03 -0600 (CST) From: David Talkington X-Sender: dtalk@sherman.spotnet.org To: Vladimir Dubrovin Cc: freebsd-security@FreeBSD.ORG, owner-freebsd-security@FreeBSD.ORG Subject: Re: All this SPAM... In-Reply-To: <9862415618.20001206125714@sandy.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org ...and/or perhaps it would be appropriate to at least only allow posts from subscribed email addresses? -- David Talkington Community Networking Initiative dtalk@prairienet.org 217-244-1962 PGP key: http://www.prairienet.org/~dtalk/dt000823.asc Vladimir Dubrovin wrote: >Hello freebsd-security, > > Since the amount of SPAM in the list exceeds amount of useful > information, may be it's a time to make this list slightly moderated? > I mean minimal moderation - only against SPAM and unrelated topics. > > >-- > Vladimir Dubrovin Sandy, ISP > Sandy CCd chief Customers Care dept > http://www.sandy.ru Nizhny Novgorod, Russia > >http://www.security.nnov.ru > > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 6 7: 2:33 2000 From owner-freebsd-security@FreeBSD.ORG Wed Dec 6 07:02:31 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from ringworld.nanolink.com (pool30-tch-1.Sofia.0rbitel.net [212.95.170.30]) by hub.freebsd.org (Postfix) with SMTP id 5048D37B400 for ; Wed, 6 Dec 2000 07:02:28 -0800 (PST) Received: (qmail 20793 invoked by uid 1000); 6 Dec 2000 15:01:48 -0000 Date: Wed, 6 Dec 2000 17:01:48 +0200 From: Peter Pentchev To: David Talkington Cc: Vladimir Dubrovin , freebsd-security@FreeBSD.ORG, owner-freebsd-security@FreeBSD.ORG Subject: Re: All this SPAM... Message-ID: <20001206170147.D17399@ringworld.oblivion.bg> Mail-Followup-To: David Talkington , Vladimir Dubrovin , freebsd-security@FreeBSD.ORG, owner-freebsd-security@FreeBSD.ORG References: <9862415618.20001206125714@sandy.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from dtalk@prairienet.org on Wed, Dec 06, 2000 at 08:59:03AM -0600 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Dec 06, 2000 at 08:59:03AM -0600, David Talkington wrote: > > ...and/or perhaps it would be appropriate to at least only allow posts > from subscribed email addresses? This is not necessarily a good thing - many people need assistance with one particular issue, and do not feel like plodding through the traffic from all the other threads. G'luck, Peter -- If I had finished this sentence, To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 6 7:50:10 2000 From owner-freebsd-security@FreeBSD.ORG Wed Dec 6 07:50:08 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from bsdie.rwsystems.net (bsdie.rwsystems.net [209.197.223.2]) by hub.freebsd.org (Postfix) with ESMTP id EA86C37B400 for ; Wed, 6 Dec 2000 07:50:07 -0800 (PST) Received: from bsdie.rwsystems.net([209.197.223.2]) (1720 bytes) by bsdie.rwsystems.net via sendmail with P:esmtp/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) id for ; Wed, 6 Dec 2000 09:48:58 -0600 (CST) (Smail-3.2.0.111 2000-Feb-17 #1 built 2000-Jun-25) Date: Wed, 6 Dec 2000 09:48:49 -0600 (CST) From: James Wyatt To: David Talkington Cc: Vladimir Dubrovin , freebsd-security@FreeBSD.ORG Subject: Re: All this SPAM... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Uh, some of us receive with one address and post with one or two others. I already have this problem with the Lyris(sp?, tm?) mailing list for stuff for some EDI mailing lists I'm on. After seeing that package in several places, I'm *not* thrilled with it. - Jy@ On Wed, 6 Dec 2000, David Talkington wrote: > ...and/or perhaps it would be appropriate to at least only allow posts > from subscribed email addresses? > > -- > David Talkington > Community Networking Initiative > dtalk@prairienet.org > 217-244-1962 > > PGP key: http://www.prairienet.org/~dtalk/dt000823.asc > > Vladimir Dubrovin wrote: > > >Hello freebsd-security, > > > > Since the amount of SPAM in the list exceeds amount of useful > > information, may be it's a time to make this list slightly moderated? > > I mean minimal moderation - only against SPAM and unrelated topics. > > > >-- > > Vladimir Dubrovin Sandy, ISP > > Sandy CCd chief Customers Care dept > > http://www.sandy.ru Nizhny Novgorod, Russia > > > >http://www.security.nnov.ru To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 6 8: 0: 4 2000 From owner-freebsd-security@FreeBSD.ORG Wed Dec 6 07:59:59 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from epsilon.lucida.ca (epsilon.lucida.ca [216.95.146.6]) by hub.freebsd.org (Postfix) with SMTP id ED91A37B400 for ; Wed, 6 Dec 2000 07:59:58 -0800 (PST) Received: (qmail 76269 invoked by uid 1000); 6 Dec 2000 15:59:57 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 6 Dec 2000 15:59:57 -0000 Date: Wed, 6 Dec 2000 10:59:55 -0500 (EST) From: Matt Heckaman X-Sender: matt@epsilon.lucida.ca To: mouss Cc: FreeBSD-SECURITY Subject: Re: [spam score 10.00/10.0 -pobox] Re: Fw: NAPTHA Advisory Updated - BindView RAZOR In-Reply-To: <4.3.0.20001206150604.05998d30@pop.free.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: localhost 1.6.2 0/1000/N Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 6 Dec 2000, mouss wrote: : isn't enough to create an account for each server or group of servers, : and use login.conf for the users? For some things yes, but not for most. The daemons that must run as root? It would be somewhat detrimental to put a restrictive fd limit on root. I can picture finding a problem, switching to root, and not being able to type a command because it's out of procs. :) * Matt Heckaman - mailto:matt@lucida.qc.ca http://www.lucida.qc.ca/ * * GPG fingerprint - A9BC F3A8 278E 22F2 9BDA BFCF 74C3 2D31 C035 5390 * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: http://www.lucida.qc.ca/pgp iD8DBQE6LmJ9dMMtMcA1U5ARAhFzAJ9ZpbjwvvJf1ofXpTZI+bI0MClFHgCffhDu QWpcBaJYACBD37A5791nLzk= =WkjR -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 6 8: 4:44 2000 From owner-freebsd-security@FreeBSD.ORG Wed Dec 6 08:04:41 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from peak.mountin.net (peak.mountin.net [207.227.119.2]) by hub.freebsd.org (Postfix) with ESMTP id 5424D37B400; Wed, 6 Dec 2000 08:04:40 -0800 (PST) Received: (from daemon@localhost) by peak.mountin.net (8.9.1/8.9.1) id KAA10977; Wed, 6 Dec 2000 10:04:25 -0600 (CST) (envelope-from jeff-ml@mountin.net) Received: from dial-104.max1.wa.cyberlynk.net(207.227.118.104) by peak.mountin.net via smap (V1.3) id sma010975; Wed Dec 6 10:04:17 2000 Message-Id: <4.3.2.20001206093926.00b7a670@207.227.119.2> X-Sender: jeff-ml@207.227.119.2 X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Wed, 06 Dec 2000 10:02:57 -0600 To: Peter Pentchev , David Talkington From: "Jeffrey J. Mountin" Subject: Re: All this SPAM... Cc: Vladimir Dubrovin , freebsd-security@FreeBSD.ORG, owner-freebsd-security@FreeBSD.ORG In-Reply-To: <20001206170147.D17399@ringworld.oblivion.bg> References: <9862415618.20001206125714@sandy.ru> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 05:01 PM 12/6/00 +0200, Peter Pentchev wrote: >On Wed, Dec 06, 2000 at 08:59:03AM -0600, David Talkington wrote: > > > > ...and/or perhaps it would be appropriate to at least only allow posts > > from subscribed email addresses? > >This is not necessarily a good thing - many people need assistance with >one particular issue, and do not feel like plodding through the traffic >from all the other threads. While I am all for closing the list(s) there is this reason you mention. However, can only recall 2 such occurrences this year where a non-subscriber had a question and asked for a CC (there may be others, but these were implicit). On *both* occasions the question was *not* pertinent to -security, so see little actual usefulness to the policy. Am only pointing this out since years back I made the same wish. I think. Do know that I wasn't happy about the subscriber lists being obtainable. Eventually that did change (Hi jmb!). To forestall a useless and OT debate on this, it would be best to hear from -core on a possible policy change. Doubt it will happen, but one can always hope. 8-) (was tempted to CC core, but can live with the current policy) Aw hell. One idea for closing the lists and still allow non-subscribers would use to use an e-mail gateway from the support web pages. Not that I am volunteering code, but just to make a point, since they are in the list of things one should do before contacting a list with questions and then they might do so to the proper list. As for a moderated list, who wants to play babysittter? Didn't think so. ;) Pardon my ramblings, but have been here before, so only thought to present the dead horse for viewing and will bury it once more. Jeff Mountin - jeff@mountin.net Systems/Network Administrator FreeBSD - the power to serve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 6 8: 8:29 2000 From owner-freebsd-security@FreeBSD.ORG Wed Dec 6 08:08:27 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from epsilon.lucida.ca (epsilon.lucida.ca [216.95.146.6]) by hub.freebsd.org (Postfix) with SMTP id 7D98F37B400 for ; Wed, 6 Dec 2000 08:08:26 -0800 (PST) Received: (qmail 76315 invoked by uid 1000); 6 Dec 2000 16:08:25 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 6 Dec 2000 16:08:25 -0000 Date: Wed, 6 Dec 2000 11:08:24 -0500 (EST) From: Matt Heckaman X-Sender: matt@epsilon.lucida.ca To: mouss Cc: FreeBSD-SECURITY Subject: Re: nmbclusters (was: the lame advisory) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: localhost 1.6.2 0/1000/N Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 6 Dec 2000, Matt Heckaman wrote: ... : For some things yes, but not for most. The daemons that must run as root? : It would be somewhat detrimental to put a restrictive fd limit on root. I : can picture finding a problem, switching to root, and not being able to : type a command because it's out of procs. :) As I hit send, I realize just how stupid this is. I could simply create another uid 0 account with a different login class. duh! Maybe I should not have erased toor from all my machines after all. :) * Matt Heckaman - mailto:matt@lucida.qc.ca http://www.lucida.qc.ca/ * * GPG fingerprint - A9BC F3A8 278E 22F2 9BDA BFCF 74C3 2D31 C035 5390 * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: http://www.lucida.qc.ca/pgp iD8DBQE6LmR5dMMtMcA1U5ARAo5OAKCZIKQGwb213MFR5//AxYK/biC19gCgg+ZD HwqRwu5CpLU/X2Yai7aw3jg= =TfAY -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 6 8:19: 3 2000 From owner-freebsd-security@FreeBSD.ORG Wed Dec 6 08:19:01 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from elvis.mu.org (elvis.mu.org [207.154.226.10]) by hub.freebsd.org (Postfix) with ESMTP id 570D037B400 for ; Wed, 6 Dec 2000 08:19:01 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1098) id CB2DE2B284; Wed, 6 Dec 2000 10:18:55 -0600 (CST) Date: Wed, 6 Dec 2000 10:18:55 -0600 From: Bill Fumerola To: Sebastiaan van Erk Cc: freebsd-security@freebsd.org Subject: Re: rx list Message-ID: <20001206101855.L86825@elvis.mu.org> References: <20001206081549.A49341@sebster.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001206081549.A49341@sebster.com>; from sebster@sebster.com on Wed, Dec 06, 2000 at 08:15:49AM +0100 X-Operating-System: FreeBSD 4.2-FEARSOME-20001103 i386 Sender: billf@elvis.mu.org Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Dec 06, 2000 at 08:15:49AM +0100, Sebastiaan van Erk wrote: > Dec 6 00:09:43 hobbes /kernel: Out of mbuf clusters - adjust NMBCLUSTERS or inc > rease maxusers! > Dec 6 00:09:43 hobbes /kernel: xl2: no memory for rx list -- packet dropped! > Dec 6 00:09:43 hobbes /kernel: xl1: no memory for rx list -- packet dropped! > > I checked on the net, but it seems to suggest that systems after 3.2 and 4.0 > should be safe. Also I don't see any patches. > > How likely is it that this is a DoS attack (note that we also get the message > on the internal interface!)? And how do I go about fixing it? (I can increase > maxusers and NMBCLUSTERS, but then how do I know it's not going to happen > again?). Uhm. How are you going to know you're not getting DoSed again? You don't. Increase NMBCLUSTERS, rate limit the bad mojo further upstream, use icmplim, use tcpdump. In other words, be a sysadmin. -- Bill Fumerola - security yahoo / Yahoo! inc. - fumerola@yahoo-inc.com / billf@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 6 8:20:26 2000 From owner-freebsd-security@FreeBSD.ORG Wed Dec 6 08:20:24 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from elvis.mu.org (elvis.mu.org [207.154.226.10]) by hub.freebsd.org (Postfix) with ESMTP id 06E6537B400 for ; Wed, 6 Dec 2000 08:20:24 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1098) id AF7B52B28B; Wed, 6 Dec 2000 10:20:23 -0600 (CST) Date: Wed, 6 Dec 2000 10:20:23 -0600 From: Bill Fumerola To: James Lim Cc: Sebastiaan van Erk , freebsd-security@FreeBSD.ORG Subject: Re: rx list Message-ID: <20001206102023.M86825@elvis.mu.org> References: <20001206081549.A49341@sebster.com> <002801c05f55$0a492ac0$fa5e78cb@gchang> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <002801c05f55$0a492ac0$fa5e78cb@gchang>; from jameslpin@pacific.net.sg on Wed, Dec 06, 2000 at 03:20:40PM +0800 X-Operating-System: FreeBSD 4.2-FEARSOME-20001103 i386 Sender: billf@elvis.mu.org Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Dec 06, 2000 at 03:20:40PM +0800, James Lim wrote: > > You could try increasing the maxusers to 512 and later increase > your NMBCLUSTERS to prolly 50000. How much ram does your machine has as well > as the CPU speed? Btw i was wondering whether the new accept filter helps > in DoS attacks. > > options ACCEPT_FILTER_DATA > options ACCEPT_FILTER_HTTP It doesn't help all (most) DoS attacks, but it might help in the 'netkill' type attacks (where many connections are opened to the machine and never used). -- Bill Fumerola - security yahoo / Yahoo! inc. - fumerola@yahoo-inc.com / billf@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 6 8:26:11 2000 From owner-freebsd-security@FreeBSD.ORG Wed Dec 6 08:26:10 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from fffhp003.dhcmc.com (unknown [206.100.227.2]) by hub.freebsd.org (Postfix) with ESMTP id D3D9F37B400 for ; Wed, 6 Dec 2000 08:26:09 -0800 (PST) Received: by fffhp003.dhcmc.com with Internet Mail Service (5.5.2650.21) id ; Wed, 6 Dec 2000 11:26:01 -0500 Message-ID: <20A772A20B51D411B48F006008F5F65330019B@fffhp003.dhcmc.com> From: "Henley, Wayne" To: freebsd-security@FreeBSD.ORG Subject: Date: Wed, 6 Dec 2000 11:26:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org unsubscribe freebsd-security To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 6 8:26:35 2000 From owner-freebsd-security@FreeBSD.ORG Wed Dec 6 08:26:32 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from peak.mountin.net (peak.mountin.net [207.227.119.2]) by hub.freebsd.org (Postfix) with ESMTP id D1CF037B401 for ; Wed, 6 Dec 2000 08:26:31 -0800 (PST) Received: (from daemon@localhost) by peak.mountin.net (8.9.1/8.9.1) id KAA11091; Wed, 6 Dec 2000 10:26:29 -0600 (CST) (envelope-from jeff-ml@mountin.net) Received: from dial-104.max1.wa.cyberlynk.net(207.227.118.104) by peak.mountin.net via smap (V1.3) id sma011058; Wed Dec 6 10:25:53 2000 Message-Id: <4.3.2.20001206101651.0285d4b0@207.227.119.2> X-Sender: jeff-ml@207.227.119.2 X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Wed, 06 Dec 2000 10:24:49 -0600 To: Marc Rassbach From: "Jeffrey J. Mountin" Subject: Re: Move along, nothing to see here. Re: Important!! Vulnerabili ty in standard ftpd Cc: freebsd-security@FreeBSD.ORG In-Reply-To: References: <20001202144502.A1968@ringworld.oblivion.bg> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 09:23 AM 12/2/00 -0600, Marc Rassbach wrote: >I've seen it also. 3 Linux boxes, and one FreeBSD 2.2.7 The 3 linux >boxes were trojaned in different ways (different people). 2 of them had >ssh *ADDED* just so they could start capturing passwords. (the client >wasn't using ssh) Password >sniffing, etc la. They had the root password for the FreeBSD box for >about a month. > >They kept placing Linux binaries on the FreeBSD box. The box would run >"wierd" according to the customer. They were going to move over to a new >FreeBSD box....so fixing the 2.2.7 box wasn't important :-) Another reason why many should use binary upgrades for a fresh start. When in doubt nuke it. Even so, I like to do a drive swap upgrade to start completely fresh. >After the linux boxen were used to portscan other boxes, did I get to >scrub the BSD box :-) The Linux boxes....they were all re-installed from >scratch. They couldn't find ALL the trojans with the linux box. From >the BSD side.... make world and the script kiddies were gone. Audits suck, period. No matter the tools used. Hopefully you didn't trust the sources on the compromised server without being sure they were clean. Not a good impression to give. Imagine the tool chain could be used, but you did say script kiddies. ;) In light of that, one should always protect local source code. Jeff Mountin - jeff@mountin.net Systems/Network Administrator FreeBSD - the power to serve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 6 9:32:58 2000 From owner-freebsd-security@FreeBSD.ORG Wed Dec 6 09:32:55 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 7814B37B698; Wed, 6 Dec 2000 09:32:53 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id SAA30027; Wed, 6 Dec 2000 18:32:48 +0100 (CET) (envelope-from des@ofug.org) Sender: des@ofug.org X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: David Talkington Cc: Vladimir Dubrovin , freebsd-security@FreeBSD.ORG, owner-freebsd-security@FreeBSD.ORG Subject: Re: All this SPAM... References: From: Dag-Erling Smorgrav Date: 06 Dec 2000 18:32:47 +0100 In-Reply-To: David Talkington's message of "Wed, 6 Dec 2000 08:59:03 -0600 (CST)" Message-ID: Lines: 9 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org David Talkington writes: > ...and/or perhaps it would be appropriate to at least only allow posts > from subscribed email addresses? No. This has been discussed to death on numerous previous occasions. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 6 10:42:56 2000 From owner-freebsd-security@FreeBSD.ORG Wed Dec 6 10:42:53 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from kira.epconline.net (kira.epconline.net [209.83.132.2]) by hub.freebsd.org (Postfix) with ESMTP id 8988537B401 for ; Wed, 6 Dec 2000 10:42:40 -0800 (PST) Received: from therock (betterguard.epconline.net [209.83.132.193]) by kira.epconline.net (8.11.1/8.11.1) with SMTP id eB6Igcf30539 for ; Wed, 6 Dec 2000 12:42:39 -0600 (CST) (envelope-from carock@epconline.net) From: "Chuck Rock" To: Subject: RE: All this SPAM... Date: Wed, 6 Dec 2000 12:43:22 -0600 Message-ID: <002901c05fb4$68cde590$1805010a@epconline.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The bottom line is unsolicited E-mail is SPAM, and not "everyone" hates it, but the majority of people, I believe, do not want SPAM using their bandwidth and taking their time. I think that by joining this list, you know SPAM can be sent to you through it, and if you don't want that to happen, then unsubscribe. As a list administrator, you must decide whether or not closing it is in the best interest of it's users and it's purpose. As a user, you have control over the SPAM that comes to you from this list by staying or going. By talking about SPAM, this list has used up more time and bandwidth than the original SPAM caused to begin with. I think we should all ignore the SPAM, and wait for the administrators of the lists and mail servers to make it stop. My 2 cents. Chuck Rock > -----Original Message----- > From: des@ofug.org [mailto:des@ofug.org] > Sent: Wednesday, December 06, 2000 11:33 AM > To: David Talkington > Cc: Vladimir Dubrovin; freebsd-security@FreeBSD.ORG; > owner-freebsd-security@FreeBSD.ORG > Subject: Re: All this SPAM... > > > David Talkington writes: > > ...and/or perhaps it would be appropriate to at least only allow posts > > from subscribed email addresses? > > No. This has been discussed to death on numerous previous occasions. > > DES > -- > Dag-Erling Smorgrav - des@ofug.org > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 6 11: 6:12 2000 From owner-freebsd-security@FreeBSD.ORG Wed Dec 6 11:06:09 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from winston.osd.bsdi.com (winston.osd.bsdi.com [204.216.27.229]) by hub.freebsd.org (Postfix) with ESMTP id 7E5DC37B401 for ; Wed, 6 Dec 2000 11:06:09 -0800 (PST) Received: from winston.osd.bsdi.com (jkh@localhost [127.0.0.1]) by winston.osd.bsdi.com (8.11.1/8.11.1) with ESMTP id eB6J5uw03251; Wed, 6 Dec 2000 11:05:56 -0800 (PST) (envelope-from jkh@winston.osd.bsdi.com) To: andrew@scoop.co.nz Cc: "Arthur W. Neilson III" , freebsd-security@FreeBSD.ORG Subject: Re: your mail In-Reply-To: Message from Andrew McNaughton of "Wed, 06 Dec 2000 23:42:57 +1300." Date: Wed, 06 Dec 2000 11:05:56 -0800 Message-ID: <3247.976129556@winston.osd.bsdi.com> From: Jordan Hubbard Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I believe the line saynig that the server which knows itself as > mail.iconz.co.nz, but is known to the world as etrn.iconz.co.nz I tried responding to this site (sending to both abuse and postmaster) but my mail was rejected. I'm tempted to have them added to the spam blocks for this reason alone. :( - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 6 11: 9:26 2000 From owner-freebsd-security@FreeBSD.ORG Wed Dec 6 11:09:24 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from joe.pythonvideo.com (joe.pythonvideo.com [209.226.29.94]) by hub.freebsd.org (Postfix) with ESMTP id 3432C37B400 for ; Wed, 6 Dec 2000 11:09:24 -0800 (PST) Received: from localhost (joe@localhost) by joe.pythonvideo.com (8.11.1/8.11.0) with ESMTP id eB6J8xx85843; Wed, 6 Dec 2000 14:09:00 -0500 (EST) (envelope-from joe@advancewebhosting.com) X-Authentication-Warning: joe.pythonvideo.com: joe owned process doing -bs Date: Wed, 6 Dec 2000 14:08:59 -0500 (EST) From: Joe Oliveiro X-Sender: joe@joe.pythonvideo.com To: Jordan Hubbard Cc: andrew@scoop.co.nz, "Arthur W. Neilson III" , freebsd-security@FreeBSD.ORG Subject: Re: your mail In-Reply-To: <3247.976129556@winston.osd.bsdi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org You should try spamcop.net. Microsoft: "Where would you like to go to today" Linux: "Where would you like to go tomorrow" FreeBSD: "Hey,when are you guys going to catch up" On Wed, 6 Dec 2000, Jordan Hubbard wrote: > > I believe the line saynig that the server which knows itself as > > mail.iconz.co.nz, but is known to the world as etrn.iconz.co.nz > > I tried responding to this site (sending to both abuse and postmaster) > but my mail was rejected. I'm tempted to have them added to the spam > blocks for this reason alone. :( > > - Jordan > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 6 12:54:25 2000 From owner-freebsd-security@FreeBSD.ORG Wed Dec 6 12:54:24 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mail1.rdc1.az.home.com (mail1.rdc1.az.home.com [24.1.240.75]) by hub.freebsd.org (Postfix) with ESMTP id 6208B37B400 for ; Wed, 6 Dec 2000 12:54:24 -0800 (PST) Received: from spam ([24.177.147.31]) by mail1.rdc1.az.home.com (InterMail vM.4.01.03.00 201-229-121) with SMTP id <20001206205424.EYMN1817.mail1.rdc1.az.home.com@spam> for ; Wed, 6 Dec 2000 12:54:24 -0800 Message-ID: <000f01c05f8a$ce586900$1f93b118@spam> From: "Dom" To: References: <20A772A20B51D411B48F006008F5F65330019B@fffhp003.dhcmc.com> Subject: Date: Wed, 6 Dec 2000 13:45:33 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org unsubscribe freebsd-security To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 6 14: 8:19 2000 From owner-freebsd-security@FreeBSD.ORG Wed Dec 6 14:08:17 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mailhost02.quios.com (unknown [64.41.231.105]) by hub.freebsd.org (Postfix) with ESMTP id BB28F37B400 for ; Wed, 6 Dec 2000 14:08:17 -0800 (PST) Received: (from root@localhost) by mailhost02.quios.com (8.9.3/8.8.7) id OAA03258; Wed, 6 Dec 2000 14:08:10 -0800 Received: from eeyore.sebster.com (e163161.upc-e.chello.nl [213.93.163.161]) by mailhost02.quios.com (8.9.3/8.8.7) with SMTP id BAA11940 for ; Wed, 6 Dec 2000 01:17:24 -0800 Received: (qmail 67717 invoked by uid 1000); 6 Dec 2000 09:17:23 -0000 Received: (qmail 67691 invoked from network); 6 Dec 2000 09:17:22 -0000 Received: from flood.ping.uio.no (root@129.240.78.31) by e163161.upc-e.chello.nl with SMTP; 6 Dec 2000 09:17:22 -0000 Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id KAA28415; Wed, 6 Dec 2000 10:17:08 +0100 (CET) (envelope-from des@ofug.org) Sender: des@ofug.org X-Url: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: bitbucket@sebster.com Cc: "Sebastiaan van Erk" , Subject: Re: rx list References: <20001206081549.A49341@sebster.com> <002801c05f55$0a492ac0$fa5e78cb@gchang> From: Dag-Erling Smorgrav Date: 06 Dec 2000 10:17:07 +0100 In-Reply-To: "James Lim"'s message of "Wed, 6 Dec 2000 15:20:40 +0800" Message-Id: Lines: 19 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Quios: 0AAB286 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org ---------------------------------------------------------------------- This message forwarded to you via Qmail - visit www.quios.com today! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 6 15: 8:15 2000 From owner-freebsd-security@FreeBSD.ORG Wed Dec 6 15:08:13 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from eken.vxu.se (eken.vxu.se [194.47.65.11]) by hub.freebsd.org (Postfix) with ESMTP id EE1A937B400 for ; Wed, 6 Dec 2000 15:08:12 -0800 (PST) Received: from xgod (aaldv97.idet.vxu.se [194.47.111.20]) by eken.vxu.se (8.8.7/8.8.7) with SMTP id AAA22163 for ; Thu, 7 Dec 2000 00:08:02 +0100 (MET) Message-ID: <002d01c05fd9$617651e0$6400a8c0@xgod> From: "David Andreas Alderud" To: "_Security" References: <3247.976129556@winston.osd.bsdi.com> Subject: Re: your mail Date: Thu, 7 Dec 2000 00:07:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org JKH wrote: > > I believe the line saynig that the server which knows itself as > > mail.iconz.co.nz, but is known to the world as etrn.iconz.co.nz > > I tried responding to this site (sending to both abuse and postmaster) > but my mail was rejected. I'm tempted to have them added to the spam > blocks for this reason alone. :( > > - Jordan I didn't look into it that hard since I was short on time I deleted it almost right away, when I took a peak at the header it seamed like <> just was used to bounce the mail. It looked like the mail originated from <> if I recall correctly, though I can't check that because as I said, I deleted it once I got it. /Kind regards, David A. Alderud To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 6 15:13:41 2000 From owner-freebsd-security@FreeBSD.ORG Wed Dec 6 15:13:40 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from coresync.com (ns1.coresync.net [64.71.131.2]) by hub.freebsd.org (Postfix) with SMTP id 2734437B400 for ; Wed, 6 Dec 2000 15:13:40 -0800 (PST) Received: (qmail 2388 invoked by uid 1268); 6 Dec 2000 23:13:34 -0000 Date: Wed, 6 Dec 2000 15:13:34 -0800 From: "Jonathan M. Slivko" To: freebsd-security@freebsd.org Subject: Too much spam! Message-ID: <20001206151334.A10767@coresync.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: jonms@coresync.com Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org To the list owners/maintainers: Could you guys please do a little something about the volume of spam we have been receiving in our e-mail boxes as a result of being on this list? It's really starting to become annoying to have atleast 1 or 2 e-mails that are spam in a 24 hour period. Thanks. P.S. Anyone else can jump on the bandwagon. -- Jonathan M. Slivko To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 6 15:43:25 2000 From owner-freebsd-security@FreeBSD.ORG Wed Dec 6 15:43:21 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from relay4.inwind.it (unknown [212.141.53.75]) by hub.freebsd.org (Postfix) with ESMTP id 78A1F37B401 for ; Wed, 6 Dec 2000 15:43:21 -0800 (PST) Received: from bartequi.ottodomain.org (62.98.162.50) by relay4.inwind.it (5.1.046) id 3A12695300356B4E; Thu, 7 Dec 2000 00:42:42 +0100 From: Salvo Bartolotta Date: Wed, 06 Dec 2000 23:44:07 GMT Message-ID: <20001206.23440700@bartequi.ottodomain.org> Subject: Wildly OT Re: Too much spam! To: "Jonathan M. Slivko" Cc: freebsd-security@freebsd.org References: <20001206151334.A10767@coresync.net> X-Mailer: SuperCalifragilis X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [ follow-ups, if any, to -chat, please] >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<< On 12/7/00, 12:13:34 AM, "Jonathan M. Slivko" wrote= regarding Too much spam!: > To the list owners/maintainers: > Could you guys please do a little something about the volume of spam we > have been receiving in our e-mail boxes as a result of being on this > list? It's really starting to become annoying to have atleast 1 or 2 > e-mails that are spam in a 24 hour period. Thanks. > P.S. Anyone else can jump on the bandwagon. > -- Jonathan M. Slivko What if somebody on the list cracked the spamming site(s) (say, Rude Spammer), leaving such a signature as "This site was deliberately cracked in response to the spamming of security@freebsd.org on the part of Rude Spammer" This would soon deter other potential spammers... ok, ok, ok, I was just kidding :-)) Best regards, Salvo To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 6 15:54: 8 2000 From owner-freebsd-security@FreeBSD.ORG Wed Dec 6 15:54:07 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from lucifer.techometer.net (techometer.net [216.240.169.101]) by hub.freebsd.org (Postfix) with ESMTP id 8A44D37B401 for ; Wed, 6 Dec 2000 15:54:06 -0800 (PST) Received: (from emechler@localhost) by lucifer.techometer.net (8.11.0/8.11.1) id eB6Nrwa03384; Wed, 6 Dec 2000 15:53:58 -0800 (PST) Date: Wed, 6 Dec 2000 15:53:58 -0800 From: Erick Mechler To: Salvo Bartolotta Cc: freebsd-security@FreeBSD.ORG Subject: Re: Wildly OT Re: Too much spam! Message-ID: <20001206155358.A3357@lucifer.techometer.net> References: <20001206151334.A10767@coresync.net> <20001206.23440700@bartequi.ottodomain.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001206.23440700@bartequi.ottodomain.org>; from Salvo Bartolotta on Wed, Dec 06, 2000 at 11:44:07PM +0000 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Don't know anything about Postfix, but it's got to have something similar to the access.db in Sendmail, right? The next time we get spam from someone, reject all future mail from their address. --Erick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 6 21: 1:57 2000 From owner-freebsd-security@FreeBSD.ORG Wed Dec 6 21:01:56 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from battery.yi.org (rn081014.mrs.umn.edu [146.57.81.14]) by hub.freebsd.org (Postfix) with ESMTP id 5215537B401 for ; Wed, 6 Dec 2000 21:01:56 -0800 (PST) Received: from localhost (root@localhost) by battery.yi.org (8.9.3/8.9.3) with ESMTP id WAA47175 for ; Wed, 6 Dec 2000 22:53:18 -0600 (CST) (envelope-from root@battery.yi.org) Date: Wed, 6 Dec 2000 22:53:18 -0600 (CST) From: Brad Mace To: freebsd-security@freebsd.org Subject: mrtg through firewall Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I've been trying to setup my firewall rules to allow mrtg to run. It seems to use different udp ports each time. Is there a way i can allow it without allowing all udp packets? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 6 21: 5:12 2000 From owner-freebsd-security@FreeBSD.ORG Wed Dec 6 21:05:10 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from faith.cs.utah.edu (faith.cs.utah.edu [155.99.198.108]) by hub.freebsd.org (Postfix) with ESMTP id C18EA37B401 for ; Wed, 6 Dec 2000 21:05:09 -0800 (PST) Received: (from danderse@localhost) by faith.cs.utah.edu (8.9.3/8.9.3) id WAA03558; Wed, 6 Dec 2000 22:05:07 -0700 (MST) Message-Id: <200012070505.WAA03558@faith.cs.utah.edu> Subject: Re: mrtg through firewall To: root@battery.yi.org (Brad Mace) Date: Wed, 6 Dec 2000 22:05:07 -0700 (MST) Cc: freebsd-security@FreeBSD.ORG In-Reply-To: from "Brad Mace" at Dec 06, 2000 10:53:18 PM From: "David G. Andersen" X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: danderse@cs.utah.edu Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Not really. You're going to basically have to allow UDP from the snmp port back to any of your high UDP ports, but you can at least limit it to that. You'll still be able to block most of the reserved UDP ports. Similar problems exist with many DNS resolvers, so it likely won't be a big change for your firewall rules. -Dave Lo and behold, Brad Mace once said: > > I've been trying to setup my firewall rules to allow mrtg to run. It > seems to use different udp ports each time. Is there a way i can allow it > without allowing all udp packets? > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > -- work: dga@lcs.mit.edu me: dga@pobox.com MIT Laboratory for Computer Science http://www.angio.net/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 6 21:28:35 2000 From owner-freebsd-security@FreeBSD.ORG Wed Dec 6 21:28:33 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from shrubbery.satx.bikeworld.net (shrubbery.satx.bikeworld.net [209.142.99.220]) by hub.freebsd.org (Postfix) with ESMTP id 8E0E937B401 for ; Wed, 6 Dec 2000 21:28:33 -0800 (PST) Received: from roscoe ([10.0.0.2] helo=roscoe.ah.bikeworld.net ident=mailserv) by shrubbery.satx.bikeworld.net with esmtp (Exim 3.16 #1) id 143tbL-0001hd-00; Wed, 06 Dec 2000 23:28:15 -0600 Received: from roscoe.ah.bikeworld.net ([10.0.0.2] ident=root) by roscoe.ah.bikeworld.net with esmtp (Exim 3.16 #1) id 143tbK-0000M2-00; Wed, 06 Dec 2000 23:28:14 -0600 Date: Wed, 6 Dec 2000 23:28:14 -0600 (CST) From: Chris Snell X-Sender: chris@roscoe.ah.bikeworld.net To: Brad Mace Cc: freebsd-security@freebsd.org Subject: Re: mrtg through firewall In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 6 Dec 2000, Brad Mace wrote: > I've been trying to setup my firewall rules to allow mrtg to run. It > seems to use different udp ports each time. Is there a way i can allow it > without allowing all udp packets? Another alternative is to move from MRTG to Bronc (http://bronc.blueaspen.com) and then use Colt (see the Bronc homepage for more info on Colt) to pass the SNMP data through the firewall (by direct HTTP or HTTP through a proxy) to your network monitoring box. I plan on releasing a version of the Bronc collector (badger.pl) that has Colt support built-in. Chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 6 23:25:22 2000 From owner-freebsd-security@FreeBSD.ORG Wed Dec 6 23:25:20 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from jamus.xpert.com (jamus.xpert.com [199.203.132.17]) by hub.freebsd.org (Postfix) with ESMTP id 62DE537B400 for ; Wed, 6 Dec 2000 23:25:16 -0800 (PST) Received: from roman (helo=localhost) by jamus.xpert.com with local-esmtp (Exim 3.12 #5) id 143vPK-0001zm-00; Thu, 07 Dec 2000 09:23:58 +0200 Date: Thu, 7 Dec 2000 09:23:58 +0200 (IST) From: Roman Shterenzon To: Cy Schubert - ITSD Open Systems Group Cc: Dominick LaTrappe , Subject: Re: filtering ipsec traffic In-Reply-To: <200011291519.eATFJSN20826@cwsys.cwsent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 29 Nov 2000, Cy Schubert - ITSD Open Systems Group wrote: > In message , > Dominick > LaTrappe writes: > > It seems that, on the way in, ipfilter on FreeBSD gets packets before KAME > > does, and on the way out, after. This limits ipfilter to inspecting > > traffic from IPsec peers on on layer 3 only. Since I see no > > packet-filtering mechanism in KAME itself, this presents a severe > > limitation, namely that I must trust my IPsec peers enough for their > > traffic to bypass any layer-4 filters. > > > > Is there some way to give ipfilter two passes, pre-KAME and post-KAME? > > The even better fix, I suppose, would be to have 4 ipfilter rulesets > > instead of 2 -- pre-KAME in, pre-KAME out, post-KAME in, post-KAME out. > > > > In the mean time, I'm using tcpwrappers as a last-line-of-defense where I > > can, but it's not enough. > > Looking at the source, I don't see any references to IPFW either, > meaning this is not a simple copy-the-code change. > > One option would be to set up a point-to-point IPSec tunnel between the > two gateways, then use an IP tunnel within it. Alternatively you > could pipsecd which sets up an IPSec tunnel and defines a tun > interface, which can be filtered using IP Filter or IPFW. Sorry for late reply; Then you'll have to bear in mind that everything is done in the userspace, thus limiting it to low traffic cases. (Does it need two cs per packet, or more?) Perpaps it is the "move code" from here to there? May it be possible to make ipf pass before KAME in both directions, or I'm completely missing the point? --Roman Shterenzon, UNIX System Administrator and Consultant [ Xpert UNIX Systems Ltd., Herzlia, Israel. Tel: +972-9-9522361 ] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Dec 6 23:54:22 2000 From owner-freebsd-security@FreeBSD.ORG Wed Dec 6 23:54:20 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from jamus.xpert.com (jamus.xpert.com [199.203.132.17]) by hub.freebsd.org (Postfix) with ESMTP id A337637B400 for ; Wed, 6 Dec 2000 23:54:18 -0800 (PST) Received: from roman (helo=localhost) by jamus.xpert.com with local-esmtp (Exim 3.12 #5) id 143vsa-00021n-00; Thu, 07 Dec 2000 09:54:12 +0200 Date: Thu, 7 Dec 2000 09:54:12 +0200 (IST) From: Roman Shterenzon To: Bill Fumerola Cc: Subject: Re: Danger Ports In-Reply-To: <20001201003102.I83422@elvis.mu.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 1 Dec 2000, Bill Fumerola wrote: > On Thu, Nov 30, 2000 at 10:07:05PM -0800, Rodney W. Grimes wrote: > > > > I wouldn't go as far as BCP. > > > > Well, RFC1918, aka BCP5 is pretty darn clear in section 3 paragraph 8: > > > > Because private addresses have no global meaning, routing information > > about private networks shall not be propagated on inter-enterprise > > links, and packets with private source or destination addresses > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > should not be forwarded across such links. Routers in networks not > > ^^^^^^^^^^^^^^^^^^^^^^^ > > using private address space, especially those of Internet service > > providers, are expected to be configured to reject (filter out) > > routing information about private networks. If such a router receives > > such information the rejection shall not be treated as a routing > > protocol error. > > You're mistaking "should" for "must". RFCs are very anal about pointing out > the difference between these words. Noncompliance is different then behavior > deemed suboptimal. > > > The problem is that the other RFC/BCP's (2827, 3013 in particular) only > > talk about ingress filtering on source address, totally ignoreing what > > RFC1918 says about these addresses :-( > > > > See nanog archives. > > > > Can you be more specific? > > In the interest of ego (and proof that I am consistant if nothing else): > http://www.merit.edu/mail.archives/nanog/msg03756.html > In the interest of completeness: > http://www.merit.edu/mail.archives/nanog/msg03754.html > > A search of "RFC1918" revealed these. A question here is if we all agree that using private addresses and "unassigned" router interfaces is a bad practice and should be avoided? Another question is what are the benefits and misgivings of filtering private ip originated traffic (keeping in mind that it might get dropped even before it reaches your routers). --Roman Shterenzon, UNIX System Administrator and Consultant [ Xpert UNIX Systems Ltd., Herzlia, Israel. Tel: +972-9-9522361 ] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 7 2:59: 7 2000 From owner-freebsd-security@FreeBSD.ORG Thu Dec 7 02:59:05 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from innocence.interface-business.de (unknown [193.101.57.202]) by hub.freebsd.org (Postfix) with ESMTP id 9998637B401 for ; Thu, 7 Dec 2000 02:59:03 -0800 (PST) Received: from interface-business.de (uucp@localhost) by innocence.interface-business.de with UUCP id LAA52839 for freebsd-security@freebsd.org; Thu, 7 Dec 2000 11:59:01 +0100 (CET) Received: (from j@localhost) by B7173150.deutschepost.de id LAA70600 for freebsd-security@freebsd.org; Thu, 7 Dec 2000 11:58:35 +0100 (CET) Date: Thu, 7 Dec 2000 11:58:35 +0100 From: J Wunsch To: freebsd-security@freebsd.org Subject: Please review a change to lock(1) Message-ID: <20001207115835.V4709@B7173150.DeutschePost.de> Reply-To: Joerg Wunsch Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i X-Phone: +49-351-31809-14 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Organization: interface business GmbH, Dresden Sender: j@interface-business.de Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, i think everybody's happy when seeing those dead processes running around forever, eating up all CPU time -- since they are too stupid to notice the tty they're trying to read from is gone. lock(1) is one of those culprits, as i just noticed. You can easily prove this by logging into a plain tty, starting "lock -np", and killing the shell e. g. with SIGABRT (or SIGKILL to be sure). The shell is gone, but lock is still there, trying to lock nothing now... I see the intention that lock should never exit except after having seen the correct password, but a process eating up all CPU is not all that good either... Please review the following, and make a better suggestion if you think i didn't honor all security-related issues here. Btw., after the tty is gone, fread() returns NULL but ferror() doesn't return 1 (!), and isatty(fileno(stdin)) also still yields 1. So the only way i found was to justify based on errno. Maybe the event should be syslogged? Index: lock.c =================================================================== RCS file: /home/ncvs/src/usr.bin/lock/lock.c,v retrieving revision 1.8 diff -u -r1.8 lock.c --- lock.c 1999/10/12 13:53:30 1.8 +++ lock.c 2000/12/07 10:49:28 @@ -61,6 +61,7 @@ #include #include #include +#include #include #include #include @@ -189,7 +190,11 @@ for (;;) { (void)printf("Key: "); + errno = 0; if (!fgets(s, sizeof(s), stdin)) { + if (errno == EIO) + /* Our terminal is gone; good-bye. */ + exit(1); clearerr(stdin); hi(); continue; -- Joerg Wunsch NIC hdl: JW11-RIPE On the air: DL8DTL See http://www.interface-business.de/~j/ for more information. Some addresses in the headers might be wrong (sorry - I'm not the admin here). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 7 6:16:22 2000 From owner-freebsd-security@FreeBSD.ORG Thu Dec 7 06:16:20 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mail.rookie.org (mail.rookie.org [212.43.72.181]) by hub.freebsd.org (Postfix) with ESMTP id 8E7EC37B400 for ; Thu, 7 Dec 2000 06:16:20 -0800 (PST) Received: by mail.rookie.org (Postfix, from userid 1000) id C2332F805; Thu, 7 Dec 2000 15:17:03 +0100 (CET) Date: Thu, 7 Dec 2000 15:17:03 +0100 From: Stephan Holtwisch To: freebsd-security@freebsd.org Subject: Re: TIS Firewall Tookit Message-ID: <20001207151703.A57521@rookie.org> References: <20001206081015.B61027@spawn.nectar.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from pm@aber.warum.net on Wed, Dec 06, 2000 at 03:50:56PM +0100 Sender: dfens@rookie.org Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Dec 06, 2000 at 03:50:56PM +0100, Manfred Petz wrote: > Accepted. Do you know a (free) alternative to FWTK which is comparable in > terms of ease of use, straightforward source and which implements similar > functionality (e.g. the permit/deny rules in netperm-table)? That depends on the proxy functions needed. The Juniper Firewall Toolkit (http://www.obtuse.com/juniper) looks promising, however i have not checked it yet. Besides, the smtp proxy of that Toolkit is part of the freebsd ports tree. Stephan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 7 6:30:25 2000 From owner-freebsd-security@FreeBSD.ORG Thu Dec 7 06:30:23 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from bsdie.rwsystems.net (bsdie.rwsystems.net [209.197.223.2]) by hub.freebsd.org (Postfix) with ESMTP id 35EE337B401 for ; Thu, 7 Dec 2000 06:30:23 -0800 (PST) Received: from bsdie.rwsystems.net([209.197.223.2]) (1466 bytes) by bsdie.rwsystems.net via sendmail with P:esmtp/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) id for ; Thu, 7 Dec 2000 08:29:03 -0600 (CST) (Smail-3.2.0.111 2000-Feb-17 #1 built 2000-Jun-25) Date: Thu, 7 Dec 2000 08:29:03 -0600 (CST) From: James Wyatt To: Joerg Wunsch Cc: freebsd-security@freebsd.org Subject: Re: Please review a change to lock(1) In-Reply-To: <20001207115835.V4709@B7173150.DeutschePost.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Maybe you could see if it's PPID becomes 1 as init inherits it as an orphan from the dead parent process. I would *definately* syslog the error as a simple error *could* be an attempt to trick lock. Some programs deserve paranoia due to their use and level of users' blind trust. - Jy@ On Thu, 7 Dec 2000, J Wunsch wrote: > i think everybody's happy when seeing those dead processes running > around forever, eating up all CPU time -- since they are too stupid to > notice the tty they're trying to read from is gone. lock(1) is one of > those culprits, as i just noticed. You can easily prove this by > logging into a plain tty, starting "lock -np", and killing the shell > e. g. with SIGABRT (or SIGKILL to be sure). The shell is gone, but > lock is still there, trying to lock nothing now... [ ... wish more folks would trim posts ... ] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 7 6:58:19 2000 From owner-freebsd-security@FreeBSD.ORG Thu Dec 7 06:58:17 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from innocence.interface-business.de (innocence.interface-business.de [193.101.57.202]) by hub.freebsd.org (Postfix) with ESMTP id E805537B400 for ; Thu, 7 Dec 2000 06:58:15 -0800 (PST) Received: from interface-business.de (uucp@localhost) by innocence.interface-business.de with UUCP id PAA35420 for freebsd-security@freebsd.org; Thu, 7 Dec 2000 15:58:14 +0100 (CET) Received: (from j@localhost) by B7173150.deutschepost.de id PAA12713 for freebsd-security@freebsd.org; Thu, 7 Dec 2000 15:57:50 +0100 (CET) Date: Thu, 7 Dec 2000 15:57:50 +0100 From: J Wunsch To: freebsd-security@freebsd.org Subject: Re: Please review a change to lock(1) Message-ID: <20001207155750.E4709@B7173150.DeutschePost.de> Reply-To: Joerg Wunsch References: <20001207115835.V4709@B7173150.DeutschePost.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from James Wyatt on Thu, Dec 07, 2000 at 08:29:03AM -0600 X-Phone: +49-351-31809-14 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Organization: interface business GmbH, Dresden Sender: j@interface-business.de Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As James Wyatt wrote: > Maybe you could see if it's PPID becomes 1 as init inherits it as an > orphan from the dead parent process. I would *definately* syslog the error > as a simple error *could* be an attempt to trick lock. Some programs > deserve paranoia due to their use and level of users' blind trust. - Jy@ OK, point taken, new suggestion. (Btw., please leave me in the Cc list when replying, i'm not subscribed to -security.) Index: lock.c =================================================================== RCS file: /home/ncvs/src/usr.bin/lock/lock.c,v retrieving revision 1.8 diff -u -r1.8 lock.c --- lock.c 1999/10/12 13:53:30 1.8 +++ lock.c 2000/12/07 14:54:48 @@ -61,6 +61,7 @@ #include #include #include +#include #include #include #include @@ -189,7 +190,15 @@ for (;;) { (void)printf("Key: "); + errno = 0; if (!fgets(s, sizeof(s), stdin)) { + if (errno == EIO && getppid() == 1) { + /* Our terminal is gone; good-bye. */ + syslog(LOG_NOTICE, + "exiting due to IO error on terminal (UID %d@%s on %s)", + getuid(), ttynam, hostname); + exit(1); + } clearerr(stdin); hi(); continue; -- Joerg Wunsch NIC hdl: JW11-RIPE On the air: DL8DTL See http://www.interface-business.de/~j/ for more information. Some addresses in the headers might be wrong (sorry - I'm not the admin here). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 7 7:31:25 2000 From owner-freebsd-security@FreeBSD.ORG Thu Dec 7 07:31:23 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from jamus.xpert.com (jamus.xpert.com [199.203.132.17]) by hub.freebsd.org (Postfix) with ESMTP id 69EBE37B400 for ; Thu, 7 Dec 2000 07:31:09 -0800 (PST) Received: from roman (helo=localhost) by jamus.xpert.com with local-esmtp (Exim 3.12 #5) id 1442zs-0003mP-00; Thu, 07 Dec 2000 17:30:12 +0200 Date: Thu, 7 Dec 2000 17:30:12 +0200 (IST) From: Roman Shterenzon To: John Howie Cc: Subject: Re: Defeating SYN flood attacks In-Reply-To: <00a101c05bdf$4e6e9b00$fd01a8c0@pacbell.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 1 Dec 2000, John Howie wrote: > Given that you know the plaintext (the Client IP Address), the cipher text > (SISN - CISN) and the algorithm, you can work out the key used (eventually). > If the key is only changed at system startup, the longer the system is > running, the more likely it will be that the key is computed. We all talk > about how long our boxes are up and running for (compared to NT/2000) and we > usually talk in months, if not years. The key needs to be changed more > often - perhaps hourly (which still might not be enough). AFAIK, it's still very nontrivial task to deduce the key given the plaintext and the ciphertext, especially when talking about 16 rounds, thing that makes differential cryptanalysis difficult (Or I'm completely lost and need to reread the Applied Cryptography; if so, please remind me). Of course the key should be changed from time to time, perhaps once a day. --Roman Shterenzon, UNIX System Administrator and Consultant [ Xpert UNIX Systems Ltd., Herzlia, Israel. Tel: +972-9-9522361 ] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 7 7:41:40 2000 From owner-freebsd-security@FreeBSD.ORG Thu Dec 7 07:41:38 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from jamus.xpert.com (jamus.xpert.com [199.203.132.17]) by hub.freebsd.org (Postfix) with ESMTP id 59ACB37B400 for ; Thu, 7 Dec 2000 07:41:34 -0800 (PST) Received: from roman (helo=localhost) by jamus.xpert.com with local-esmtp (Exim 3.12 #5) id 1443AU-0003nM-00; Thu, 07 Dec 2000 17:41:10 +0200 Date: Thu, 7 Dec 2000 17:41:10 +0200 (IST) From: Roman Shterenzon To: Marc Rassbach Cc: Subject: Re: Move along, nothing to see here. Re: Important!! Vulnerabili ty in standard ftpd In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 2 Dec 2000, Marc Rassbach wrote: > After the linux boxen were used to portscan other boxes, did I get to > scrub the BSD box :-) The Linux boxes....they were all re-installed from > scratch. They couldn't find ALL the trojans with the linux box. From > the BSD side.... make world and the script kiddies were gone. The book "Practical UNIX And Internet Security" from O'reilly describes a real case when the backdoor was implemented in the binary of the compiler; Then, the compiler produced with the backdored compiler produced a backdored /bin/login (or whatever it was) and the backdoor wasn't in source of any of the above (anymore). And, of course the /bin/login created with the backdoored compiler contained the backdoor. Clever trick, huh? --Roman Shterenzon, UNIX System Administrator and Consultant [ Xpert UNIX Systems Ltd., Herzlia, Israel. Tel: +972-9-9522361 ] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 7 13:35:32 2000 From owner-freebsd-security@FreeBSD.ORG Thu Dec 7 13:35:30 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from databits.net (analog.databits.net [207.29.192.55]) by hub.freebsd.org (Postfix) with SMTP id 8A28737B400 for ; Thu, 7 Dec 2000 13:35:29 -0800 (PST) Received: (qmail 10154 invoked by uid 1000); 7 Dec 2000 21:35:18 -0000 Date: Thu, 7 Dec 2000 16:35:18 -0500 From: Pete Fritchman To: "David G. Andersen" Cc: Brad Mace , freebsd-security@FreeBSD.ORG Subject: Re: mrtg through firewall Message-ID: <20001207163518.A3794@databits.net> References: <200012070505.WAA03558@faith.cs.utah.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200012070505.WAA03558@faith.cs.utah.edu>; from dga@pobox.com on Wed, Dec 06, 2000 at 10:05:07PM -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org No, you don't. You can allow any UDP with the source port of snmp to talk to your mrtg box. -pete ++ 06/12/00 22:05 -0700 - David G. Andersen: >Not really. You're going to basically have to allow UDP from the snmp >port back to any of your high UDP ports, but you can at least limit it to >that. You'll still be able to block most of the reserved UDP ports. > >Similar problems exist with many DNS resolvers, so it likely won't be a >big change for your firewall rules. > > -Dave > >Lo and behold, Brad Mace once said: >> >> I've been trying to setup my firewall rules to allow mrtg to run. It >> seems to use different udp ports each time. Is there a way i can allow it >> without allowing all udp packets? >> >> >> >> To Unsubscribe: send mail to majordomo@FreeBSD.org >> with "unsubscribe freebsd-security" in the body of the message >> > > >-- >work: dga@lcs.mit.edu me: dga@pobox.com > MIT Laboratory for Computer Science http://www.angio.net/ > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-security" in the body of the message -- Pete Fritchman Databits Network Services, Inc http://www.databits.net finger: petef@analog.databits.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 7 14:33:53 2000 From owner-freebsd-security@FreeBSD.ORG Thu Dec 7 14:33:50 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from faith.cs.utah.edu (faith.cs.utah.edu [155.99.198.108]) by hub.freebsd.org (Postfix) with ESMTP id C68C237B400 for ; Thu, 7 Dec 2000 14:33:49 -0800 (PST) Received: (from danderse@localhost) by faith.cs.utah.edu (8.9.3/8.9.3) id PAA10695; Thu, 7 Dec 2000 15:33:38 -0700 (MST) Message-Id: <200012072233.PAA10695@faith.cs.utah.edu> Subject: Re: mrtg through firewall To: petef@databits.net (Pete Fritchman) Date: Thu, 7 Dec 2000 15:33:38 -0700 (MST) Cc: dga@pobox.com (David G. Andersen), root@battery.yi.org (Brad Mace), freebsd-security@FreeBSD.ORG In-Reply-To: <20001207163518.A3794@databits.net> from "Pete Fritchman" at Dec 07, 2000 04:35:18 PM From: "David G. Andersen" X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: danderse@cs.utah.edu Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Um. How does this differ from "allow UDP from the snmp back to any of your high UDP ports?" That's exactly what I said. MRTG will open a random high UDP port and send data out to the remote SNMP port, from which it will get replies... -Dave Lo and behold, Pete Fritchman once said: > > No, you don't. You can allow any UDP with the source port of snmp to talk to > your mrtg box. > > -pete > > ++ 06/12/00 22:05 -0700 - David G. Andersen: > >Not really. You're going to basically have to allow UDP from the snmp > >port back to any of your high UDP ports, but you can at least limit it to > >that. You'll still be able to block most of the reserved UDP ports. > > > >Similar problems exist with many DNS resolvers, so it likely won't be a > >big change for your firewall rules. > > > > -Dave > > > >Lo and behold, Brad Mace once said: > >> > >> I've been trying to setup my firewall rules to allow mrtg to run. It > >> seems to use different udp ports each time. Is there a way i can allow it > >> without allowing all udp packets? > >> > >> > >> > >> To Unsubscribe: send mail to majordomo@FreeBSD.org > >> with "unsubscribe freebsd-security" in the body of the message > >> > > > > > >-- > >work: dga@lcs.mit.edu me: dga@pobox.com > > MIT Laboratory for Computer Science http://www.angio.net/ > > > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org > >with "unsubscribe freebsd-security" in the body of the message > -- > Pete Fritchman > Databits Network Services, Inc > http://www.databits.net > finger: petef@analog.databits.net > > > -- work: dga@lcs.mit.edu me: dga@pobox.com MIT Laboratory for Computer Science http://www.angio.net/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 7 14:49:30 2000 From owner-freebsd-security@FreeBSD.ORG Thu Dec 7 14:49:27 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from obivon.nren.nasa.gov (obivon.nren.nasa.gov [198.10.1.39]) by hub.freebsd.org (Postfix) with ESMTP id 3CFC237B400 for ; Thu, 7 Dec 2000 14:49:22 -0800 (PST) Received: from localhost (matt@localhost) by obivon.nren.nasa.gov (8.10.2/8.10.2) with ESMTP id eB7MnLQ11849 for ; Thu, 7 Dec 2000 14:49:21 -0800 (PST) X-Authentication-Warning: obivon.nren.nasa.gov: matt owned process doing -bs Date: Thu, 7 Dec 2000 14:49:21 -0800 (PST) From: Matt Chew Spence To: Subject: toor account Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org If: 1) I am running a relatively fast machine (no vaxen here) 2) I am not worried about forgetting the root password or corrupting root's shell 3) The box is not production and can be taken into single user mode w/o impacting much of anyone would the toor account have any useful purpose, or can I just blow it away? Bonus question: Are the root restrictions (ie no tty login, no console login, no ssh login) and logging automatically relevant to toor, or do I need to configure all that stuff explicitly for toor? Thanks, Matt _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Matt Chew Spence Network Engineer/Systems Engineer matt@nren.nasa.gov NASA Research & Education Network (650) 604-4550 (voice) Ames Research Center Mail Stop 233-21 (650) 604-3080 (fax) Moffett Field, CA 94035-1000 _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 7 15: 8:16 2000 From owner-freebsd-security@FreeBSD.ORG Thu Dec 7 15:08:14 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from rodan.water-programs.com (unknown [130.86.77.19]) by hub.freebsd.org (Postfix) with ESMTP id D551F37B400 for ; Thu, 7 Dec 2000 15:08:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by rodan.water-programs.com (8.11.1/8.11.1) with ESMTP id eB7N74l18544; Thu, 7 Dec 2000 15:07:04 -0800 (PST) (envelope-from joseph@randomnetworks.com) Date: Thu, 7 Dec 2000 15:07:04 -0800 (PST) From: joseph@randomnetworks.com X-Sender: scottj@rodan.water-programs.com To: Matt Chew Spence Cc: freebsd-security@FreeBSD.ORG Subject: Re: toor account In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 7 Dec 2000, Matt Chew Spence wrote: # # If: # 1) I am running a relatively fast machine (no vaxen here) # 2) I am not worried about forgetting the root password or corrupting # root's shell # 3) The box is not production and can be taken into single user mode w/o # impacting much of anyone # # would the toor account have any useful purpose, or can I just blow it # away? My feeling would be that you could blow it away if you so desired. # Bonus question: Are the root restrictions (ie no tty login, no console # login, no ssh login) and logging automatically relevant to toor, or do I # need to configure all that stuff explicitly for toor? I was originally going to say it shouldn't be a problem because toor and root both have uid 0. Although the default install gives toor an * in the master.passwd so toor can't login through those methods even if uid 0 was given permissions to do so. -------------------------------------------------------------------- | Joseph Scott The Office Of Water Programs | | joseph@randomnetworks.com joseph.scott@owp.csus.edu | -------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 7 17:52: 3 2000 From owner-freebsd-security@FreeBSD.ORG Thu Dec 7 17:52:01 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from firefly.prairienet.org (firefly.prairienet.org [192.17.3.3]) by hub.freebsd.org (Postfix) with ESMTP id 2A9C237B400 for ; Thu, 7 Dec 2000 17:52:01 -0800 (PST) Received: from sherman.prairienet.org ([192.17.3.8]) by firefly.prairienet.org (8.9.3/8.9.3) with ESMTP id TAA06145 for ; Thu, 7 Dec 2000 19:51:57 -0600 (CST) Date: Thu, 7 Dec 2000 19:51:56 -0600 (CST) From: David Talkington To: freebsd-security@freebsd.org Subject: CTM: checksums? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi folks -- The handbook mentions future plans for some sort of authentication for CTM updates. A PGP key'd be wonderful ... meantime, I'd sure be grateful for at least a text file full of md5 sums at the official site. Is that doable, or have I overlooked some other means of verifying the integrity of deltas? Thank you -d -- David Talkington Community Networking Initiative dtalk@prairienet.org 217-244-1962 PGP key: http://www.prairienet.org/~dtalk/dt000823.asc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 7 20:15:27 2000 From owner-freebsd-security@FreeBSD.ORG Thu Dec 7 20:15:25 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from citusc.usc.edu (citusc.usc.edu [128.125.38.123]) by hub.freebsd.org (Postfix) with ESMTP id 8445537B400 for ; Thu, 7 Dec 2000 20:15:25 -0800 (PST) Received: (from kris@localhost) by citusc.usc.edu (8.9.3/8.9.3) id UAA28502; Thu, 7 Dec 2000 20:16:38 -0800 Date: Thu, 7 Dec 2000 20:16:38 -0800 From: kris@citusc.usc.edu To: David Talkington Cc: freebsd-security@FreeBSD.ORG Subject: Re: CTM: checksums? Message-ID: <20001207201638.A28486@citusc.usc.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from dtalk@prairienet.org on Thu, Dec 07, 2000 at 07:51:56PM -0600 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Dec 07, 2000 at 07:51:56PM -0600, David Talkington wrote: > > Hi folks -- > > The handbook mentions future plans for some sort of authentication for > CTM updates. A PGP key'd be wonderful ... meantime, I'd sure be > grateful for at least a text file full of md5 sums at the official > site. Is that doable, or have I overlooked some other means of > verifying the integrity of deltas? It's my understanding the deltas are now signed with GPG - see the manpages. Can you submit a PR pointing to the out of date documentation, better yet one including a fix? Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Dec 7 21:55:36 2000 From owner-freebsd-security@FreeBSD.ORG Thu Dec 7 21:55:34 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from firefly.prairienet.org (firefly.prairienet.org [192.17.3.3]) by hub.freebsd.org (Postfix) with ESMTP id 2D10637B400 for ; Thu, 7 Dec 2000 21:55:34 -0800 (PST) Received: from sherman.spotnet.org (slip-62.prairienet.org [192.17.3.82]) by firefly.prairienet.org (8.9.3/8.9.3) with ESMTP id XAA24943; Thu, 7 Dec 2000 23:52:09 -0600 (CST) Date: Thu, 7 Dec 2000 23:52:07 -0600 (CST) From: David Talkington X-Sender: dtalk@sherman.spotnet.org To: kris@citusc.usc.edu Cc: freebsd-security@FreeBSD.ORG Subject: Re: CTM: checksums? In-Reply-To: <20001207201638.A28486@citusc.usc.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> The handbook mentions future plans for some sort of authentication for >> CTM updates. A PGP key'd be wonderful ... meantime, I'd sure be >> grateful for at least a text file full of md5 sums at the official >> site. Is that doable, or have I overlooked some other means of >> verifying the integrity of deltas? > >It's my understanding the deltas are now signed with GPG - see the manpages. >Can you submit a PR pointing to the out of date documentation, better yet >one including a fix? Happy to ... I'm swamped right now, but will look at this after the holidays (I'm not yet familiar with the procedure). Thanks for the response -d To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Dec 8 0:10:43 2000 From owner-freebsd-security@FreeBSD.ORG Fri Dec 8 00:10:41 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from ocis.ocis.net (ocis.ocis.net [209.52.173.1]) by hub.freebsd.org (Postfix) with ESMTP id 84F7237B400 for ; Fri, 8 Dec 2000 00:10:41 -0800 (PST) Received: from localhost (vdrifter@localhost) by ocis.ocis.net (8.9.3/8.9.3) with ESMTP id AAA28031 for ; Fri, 8 Dec 2000 00:10:40 -0800 Date: Fri, 8 Dec 2000 00:10:40 -0800 (PST) From: John F Cuzzola To: security@freebsd.org Subject: pipsecd+ipfw fwd Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello all, I'm using pipsecd from the ports collection and it seems to do the job (for my purposes anyway). I've noticed however that when configuring the tunnel device the author recommends a MTU of 1440. Recently I added a firewall rule like: ipfw add fwd ip from to any to force the next hop through the tunnel. Well it didn't work, it did for small amounts of data but not larger ones which lead me to suspect a path MTU discovery problem. I reconfigured the tunnel device for a MTU of 1500 and it works great. My question is when using ipfw fwd what happens if the size of the packet exceeds the MTU of the device? When IPFW FWDing does ICMP 3.4 messages get sent back for large packets whos dont fragment bit is set? or does that packet just get dropped? It would appear the icmp 3.4 message doesn't get sent back but that could be because of the pipsecd port. Kindof curious & thanks, John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Dec 8 2:35:54 2000 From owner-freebsd-security@FreeBSD.ORG Fri Dec 8 02:35:51 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 9E02A37B401 for ; Fri, 8 Dec 2000 02:35:45 -0800 (PST) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id LAA38099; Fri, 8 Dec 2000 11:35:41 +0100 (CET) (envelope-from des@ofug.org) Sender: des@ofug.org X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Matt Chew Spence Cc: Subject: Re: toor account References: From: Dag-Erling Smorgrav Date: 08 Dec 2000 11:35:40 +0100 In-Reply-To: Matt Chew Spence's message of "Thu, 7 Dec 2000 14:49:21 -0800 (PST)" Message-ID: Lines: 11 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matt Chew Spence writes: > would the toor account have any useful purpose, or can I just blow it > away? You can. I understand the only reason there's a toor account in the first place is so C-shell and Bourne-shell lovers can both have their favorite shell as root shell. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Dec 8 6: 2:28 2000 From owner-freebsd-security@FreeBSD.ORG Fri Dec 8 06:02:27 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from apollo.ocsny.com (apollo.ocsny.com [204.107.76.2]) by hub.freebsd.org (Postfix) with ESMTP id 9403F37B400 for ; Fri, 8 Dec 2000 06:02:26 -0800 (PST) Received: from upan.org (fw234.ocsny.com [204.107.76.234]) by apollo.ocsny.com (8.9.2/8.9.3) with ESMTP id JAA28740; Fri, 8 Dec 2000 09:02:38 -0500 (EST) Message-ID: <3A30E982.202E82A2@upan.org> Date: Fri, 08 Dec 2000 09:00:34 -0500 From: mikel X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Matt Chew Spence Cc: freebsd-security@FreeBSD.ORG Subject: Re: toor account References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org toor does not have the same login restrictions as root...refer to /etc/login.access The account is linked to bash. Use it. Delete it. Ignor it. recommend atleast you set your own password for it. cheers, mikel Matt Chew Spence wrote: > If: > 1) I am running a relatively fast machine (no vaxen here) > 2) I am not worried about forgetting the root password or corrupting > root's shell > 3) The box is not production and can be taken into single user mode w/o > impacting much of anyone > > would the toor account have any useful purpose, or can I just blow it > away? > > Bonus question: Are the root restrictions (ie no tty login, no console > login, no ssh login) and logging automatically relevant to toor, or do I > need to configure all that stuff explicitly for toor? > > Thanks, > > Matt > > _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ > Matt Chew Spence Network Engineer/Systems Engineer > matt@nren.nasa.gov NASA Research & Education Network > (650) 604-4550 (voice) Ames Research Center Mail Stop 233-21 > (650) 604-3080 (fax) Moffett Field, CA 94035-1000 > _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Dec 8 6:18:49 2000 From owner-freebsd-security@FreeBSD.ORG Fri Dec 8 06:18:46 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from ns1.arch.bellsouth.net (ns1.arch.bellsouth.net [205.152.173.2]) by hub.freebsd.org (Postfix) with ESMTP id 4D00437B400 for ; Fri, 8 Dec 2000 06:18:46 -0800 (PST) Received: from bar (ckhome [24.31.106.127]) by ns1.arch.bellsouth.net (8.9.1a/8.9.1) with SMTP id JAA22976 for ; Fri, 8 Dec 2000 09:18:36 -0500 (EST) From: "Christian Kuhtz" To: Subject: RE: toor account Date: Fri, 8 Dec 2000 09:17:09 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <3A30E982.202E82A2@upan.org> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Can somebody explain to my why this account exists in the first place? Is there a historic significance to it? Will anything be hurt if we remove this account from all installations by default? Doesn't seem like there's any point in having it hang around, so, why not just get rid of it. -- Christian Kuhtz -wk, -hm Sr. Architect, Engineering & Architecture, BellSouth.net, Atlanta, GA, U.S. "I speak for myself only." > -----Original Message----- > From: owner-freebsd-security@FreeBSD.ORG > [mailto:owner-freebsd-security@FreeBSD.ORG]On Behalf Of mikel > Sent: Friday, December 08, 2000 9:01 AM > To: Matt Chew Spence > Cc: freebsd-security@FreeBSD.ORG > Subject: Re: toor account > > > toor does not have the same login restrictions as root...refer to > /etc/login.access The account is linked to bash. Use it. Delete it. Ignor > it. recommend atleast you set your own password for it. > > cheers, > mikel > > Matt Chew Spence wrote: > > > If: > > 1) I am running a relatively fast machine (no vaxen here) > > 2) I am not worried about forgetting the root password or corrupting > > root's shell > > 3) The box is not production and can be taken into single user mode w/o > > impacting much of anyone > > > > would the toor account have any useful purpose, or can I just blow it > > away? > > > > Bonus question: Are the root restrictions (ie no tty login, no console > > login, no ssh login) and logging automatically relevant to toor, or do I > > need to configure all that stuff explicitly for toor? > > > > Thanks, > > > > Matt > > > > _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ > > Matt Chew Spence Network Engineer/Systems Engineer > > matt@nren.nasa.gov NASA Research & Education Network > > (650) 604-4550 (voice) Ames Research Center Mail Stop 233-21 > > (650) 604-3080 (fax) Moffett Field, CA 94035-1000 > > _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-security" in the body of the message > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Dec 8 6:40:44 2000 From owner-freebsd-security@FreeBSD.ORG Fri Dec 8 06:40:41 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mail.norlight.com (mail.norlight.com [207.170.3.35]) by hub.freebsd.org (Postfix) with ESMTP id 6BE1837B400 for ; Fri, 8 Dec 2000 06:40:41 -0800 (PST) Received: from lotus.norlight.com (lotus [89.87.145.18]) by mail.norlight.com (8.9.3/8.9.3) with ESMTP id IAA20109; Fri, 8 Dec 2000 08:38:36 -0600 Subject: Re: toor account To: Dag-Erling Smorgrav Cc: freebsd-security@FreeBSD.ORG X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Hyunseog Ryu" Date: Fri, 8 Dec 2000 08:39:48 -0600 X-MIMETrack: Serialize by Router on Lotus/Norlight(Release 5.0.5 |September 22, 2000) at 12/08/2000 08:39:49 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Yes, and if you prefer, you can use toor account as backup account of root just in case of forgetting root password. ;> Hyun ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Hyunseog Ryu / CCDA, MCSE Network Engineer/Applications Engineering Norlight Telecommunications, Inc. The Guardians of Data 275 North Corporate Drive Brookfield, WI 53045-5818 Tel. +1.262.792.7965 Fax. +1.262.792.7733 Dag-Erling Smorgrav To: Matt Chew Spence , (bcc: Hyunseog > Ryu/Brookfield/Norlight) Sent by: Fax to: des@ofug.org Subject: Re: toor account 12/08/2000 04:35 AM Matt Chew Spence writes: > would the toor account have any useful purpose, or can I just blow it > away? You can. I understand the only reason there's a toor account in the first place is so C-shell and Bourne-shell lovers can both have their favorite shell as root shell. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Dec 8 6:50:19 2000 From owner-freebsd-security@FreeBSD.ORG Fri Dec 8 06:50:16 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from ns1.arch.bellsouth.net (ns1.arch.bellsouth.net [205.152.173.2]) by hub.freebsd.org (Postfix) with ESMTP id F3FE737B401 for ; Fri, 8 Dec 2000 06:50:15 -0800 (PST) Received: from bar (ckhome [24.31.106.127]) by ns1.arch.bellsouth.net (8.9.1a/8.9.1) with SMTP id JAA23399 for ; Fri, 8 Dec 2000 09:50:14 -0500 (EST) From: "Christian Kuhtz" To: Subject: RE: toor account Date: Fri, 8 Dec 2000 09:48:43 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Inconsisten site policy is a bad practice. Chose one. Worse, never have to role accounts for the same function. -- Christian Kuhtz -wk, -hm Sr. Architect, Engineering & Architecture, BellSouth.net, Atlanta, GA, U.S. "I speak for myself only." > -----Original Message----- > From: owner-freebsd-security@FreeBSD.ORG > [mailto:owner-freebsd-security@FreeBSD.ORG]On Behalf Of Hyunseog Ryu > Sent: Friday, December 08, 2000 9:40 AM > To: Dag-Erling Smorgrav > Cc: freebsd-security@FreeBSD.ORG > Subject: Re: toor account > > > > Yes, and if you prefer, you can use toor account as backup account of root > just in case of forgetting root password. ;> > > Hyun > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Hyunseog Ryu / CCDA, MCSE > Network Engineer/Applications Engineering > Norlight Telecommunications, Inc. > The Guardians of Data > 275 North Corporate Drive > Brookfield, WI 53045-5818 > Tel. +1.262.792.7965 > Fax. +1.262.792.7733 > > > > > Dag-Erling > > Smorgrav To: Matt Chew Spence > > , (bcc: Hyunseog > > Ryu/Brookfield/Norlight) > > Sent by: Fax to: > > des@ofug.org Subject: Re: toor > account > > > > > 12/08/2000 > > 04:35 AM > > > > > > > > > > Matt Chew Spence writes: > > would the toor account have any useful purpose, or can I just blow it > > away? > > You can. I understand the only reason there's a toor account in the > first place is so C-shell and Bourne-shell lovers can both have their > favorite shell as root shell. > > DES > -- > Dag-Erling Smorgrav - des@ofug.org > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Dec 8 6:51:48 2000 From owner-freebsd-security@FreeBSD.ORG Fri Dec 8 06:51:44 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from ns1.arch.bellsouth.net (ns1.arch.bellsouth.net [205.152.173.2]) by hub.freebsd.org (Postfix) with ESMTP id 6849837B400 for ; Fri, 8 Dec 2000 06:51:44 -0800 (PST) Received: from bar (ckhome [24.31.106.127]) by ns1.arch.bellsouth.net (8.9.1a/8.9.1) with SMTP id JAA23422; Fri, 8 Dec 2000 09:51:43 -0500 (EST) From: "Christian Kuhtz" To: "Christian Kuhtz" , Subject: RE: toor account Date: Fri, 8 Dec 2000 09:50:12 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Sorry, no coffee yet. Let's try this again. Inconsistent site policy is a bad practice. Choose one. Worse, never have two role accounts for the same function. -- Christian Kuhtz -wk, -hm Sr. Architect, Engineering & Architecture, BellSouth.net, Atlanta, GA, U.S. "I speak for myself only." > -----Original Message----- > From: owner-freebsd-security@FreeBSD.ORG > [mailto:owner-freebsd-security@FreeBSD.ORG]On Behalf Of Christian Kuhtz > Sent: Friday, December 08, 2000 9:49 AM > To: security@FreeBSD.ORG > Subject: RE: toor account > > > > Inconsisten site policy is a bad practice. Chose one. Worse, never have to > role accounts for the same function. > > -- > Christian Kuhtz -wk, -hm > Sr. Architect, Engineering & Architecture, BellSouth.net, Atlanta, GA, U.S. > "I speak for myself only." > > > -----Original Message----- > > From: owner-freebsd-security@FreeBSD.ORG > > [mailto:owner-freebsd-security@FreeBSD.ORG]On Behalf Of Hyunseog Ryu > > Sent: Friday, December 08, 2000 9:40 AM > > To: Dag-Erling Smorgrav > > Cc: freebsd-security@FreeBSD.ORG > > Subject: Re: toor account > > > > > > > > Yes, and if you prefer, you can use toor account as backup account of root > > just in case of forgetting root password. ;> > > > > Hyun > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Hyunseog Ryu / CCDA, MCSE > > Network Engineer/Applications Engineering > > Norlight Telecommunications, Inc. > > The Guardians of Data > > 275 North Corporate Drive > > Brookfield, WI 53045-5818 > > Tel. +1.262.792.7965 > > Fax. +1.262.792.7733 > > > > > > > > > > Dag-Erling > > > > Smorgrav To: Matt Chew Spence > > > > > , (bcc: Hyunseog > > > Ryu/Brookfield/Norlight) > > > > Sent by: Fax to: > > > > des@ofug.org Subject: Re: toor > > account > > > > > > > > > > 12/08/2000 > > > > 04:35 AM > > > > > > > > > > > > > > > > > > > > Matt Chew Spence writes: > > > would the toor account have any useful purpose, or can I just blow it > > > away? > > > > You can. I understand the only reason there's a toor account in the > > first place is so C-shell and Bourne-shell lovers can both have their > > favorite shell as root shell. > > > > DES > > -- > > Dag-Erling Smorgrav - des@ofug.org > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-security" in the body of the message > > > > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-security" in the body of the message > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Dec 8 7: 4:54 2000 From owner-freebsd-security@FreeBSD.ORG Fri Dec 8 07:04:53 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from east.isi.edu (east.isi.edu [38.245.76.2]) by hub.freebsd.org (Postfix) with ESMTP id 6DE0637B400 for ; Fri, 8 Dec 2000 07:04:52 -0800 (PST) Received: from ipce-adm.east.isi.edu (ipce-adm.east.isi.edu [38.245.76.213]) by east.isi.edu (8.9.2/8.9.2) with ESMTP id KAA23707; Fri, 8 Dec 2000 10:04:52 -0500 (EST) Date: Fri, 8 Dec 2000 10:04:51 -0500 (Eastern Standard Time) From: Forrest Houston To: Christian Kuhtz Cc: security@FreeBSD.ORG Subject: RE: toor account In-Reply-To: Message-ID: X-X-Sender: fhouston@ale.east.isi.edu MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Personally I've found the toor account helpful on "shared" machines. So if there a group that has primary sysadmin responsibility for the machine they get the root password. However as the network admin there might be times things need to change/fix something so the netadmin has the toor password. That way each group can use their own password schemes, which will also hopefully eliminate the need for password lists. Just a thought Forrest On Fri, 8 Dec 2000, Christian Kuhtz wrote: > > Sorry, no coffee yet. Let's try this again. > > Inconsistent site policy is a bad practice. Choose one. Worse, never have > two > role accounts for the same function. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Dec 8 7: 6:58 2000 From owner-freebsd-security@FreeBSD.ORG Fri Dec 8 07:06:55 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from ns1.arch.bellsouth.net (ns1.arch.bellsouth.net [205.152.173.2]) by hub.freebsd.org (Postfix) with ESMTP id 9ACA337B401 for ; Fri, 8 Dec 2000 07:06:54 -0800 (PST) Received: from bar (ckhome [24.31.106.127]) by ns1.arch.bellsouth.net (8.9.1a/8.9.1) with SMTP id KAA23688; Fri, 8 Dec 2000 10:06:52 -0500 (EST) From: "Christian Kuhtz" To: "Forrest Houston" Cc: Subject: RE: toor account Date: Fri, 8 Dec 2000 10:05:19 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Still bad policy. Seen this exact thing blow up too many times. If you need distributed admin rights, use sudo. -- Christian Kuhtz -wk, -hm Sr. Architect, Engineering & Architecture, BellSouth.net, Atlanta, GA, U.S. "I speak for myself only." > -----Original Message----- > From: Forrest Houston [mailto:fhouston@east.isi.edu] > Sent: Friday, December 08, 2000 10:05 AM > To: Christian Kuhtz > Cc: security@FreeBSD.ORG > Subject: RE: toor account > > > Personally I've found the toor account helpful on "shared" machines. So > if there a group that has primary sysadmin responsibility for the machine > they get the root password. However as the network admin there might be > times things need to change/fix something so the netadmin has the toor > password. That way each group can use their own password schemes, which > will also hopefully eliminate the need for password lists. > > Just a thought > Forrest > > On Fri, 8 Dec 2000, Christian Kuhtz wrote: > > > > > Sorry, no coffee yet. Let's try this again. > > > > Inconsistent site policy is a bad practice. Choose one. Worse, > never have > > two > > role accounts for the same function. > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Dec 8 9:22:55 2000 From owner-freebsd-security@FreeBSD.ORG Fri Dec 8 09:22:51 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 5AB7E37B400 for ; Fri, 8 Dec 2000 09:22:49 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id EAA27646; Sat, 9 Dec 2000 04:22:36 +1100 Date: Sat, 9 Dec 2000 04:22:19 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Joerg Wunsch Cc: freebsd-security@FreeBSD.ORG Subject: Re: Please review a change to lock(1) In-Reply-To: <20001207115835.V4709@B7173150.DeutschePost.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 7 Dec 2000, J Wunsch wrote: > i think everybody's happy when seeing those dead processes running > around forever, eating up all CPU time -- since they are too stupid to > notice the tty they're trying to read from is gone. lock(1) is one of > those culprits, as i just noticed. You can easily prove this by > ... Please review the following, and make a better > suggestion if you think i didn't honor all security-related issues > here. Btw., after the tty is gone, fread() returns NULL but ferror() > doesn't return 1 (!), This is correct. read(2) on a dead terminal should return 0/no-error (i.e., EOF). and isatty(fileno(stdin)) also still yields 1. I think isatty() should work. isatty() is implemented using tcgetattr() which is implented using an ioctl. I'm not sure what dead_ioctl() does. > So the only way i found was to justify based on errno. > Index: lock.c > =================================================================== > RCS file: /home/ncvs/src/usr.bin/lock/lock.c,v > retrieving revision 1.8 > diff -u -r1.8 lock.c > --- lock.c 1999/10/12 13:53:30 1.8 > +++ lock.c 2000/12/07 10:49:28 > @@ -61,6 +61,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -189,7 +190,11 @@ > > for (;;) { > (void)printf("Key: "); > + errno = 0; > if (!fgets(s, sizeof(s), stdin)) { > + if (errno == EIO) > + /* Our terminal is gone; good-bye. */ > + exit(1); > clearerr(stdin); > hi(); > continue; > This should have no effect :-). It can only work if the VISTTY test in dead_read() is broken again. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Dec 8 11: 6:37 2000 From owner-freebsd-security@FreeBSD.ORG Fri Dec 8 11:06:35 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from modemcable101.200-201-24.mtl.mc.videotron.ca (modemcable140.61-201-24.mtl.mc.videotron.ca [24.201.61.140]) by hub.freebsd.org (Postfix) with SMTP id CDD6537B402 for ; Fri, 8 Dec 2000 11:06:34 -0800 (PST) Received: (qmail 56756 invoked from network); 8 Dec 2000 19:06:33 -0000 Received: from patrak.local.mindstep.com (HELO PATRAK) (192.168.10.4) by jacuzzi.local.mindstep.com with SMTP; 8 Dec 2000 19:06:33 -0000 From: "Patrick Bihan-Faou" To: Cc: Subject: Re: pipsecd+ipfw fwd Date: Fri, 8 Dec 2000 14:07:13 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, It sounds to me that you would be better served by configuring the IP routing tables rather than doing this with ipfw fwd rules. Also for the PMTU problem, tcpmssd (from the ports) can help you there. The issue is no different that the one experience by PPPoE users. The reason why you want to reduce the MTU of the IPSec link is that IPSec headers take some space. If you leave the MTU as 1500, the resulting IPSec packets may need to be fragmented and that will not help the performance of your link. Patrick. "John F Cuzzola" wrote in message news:... > Hello all, > I'm using pipsecd from the ports collection and it seems to do the job > (for my purposes anyway). I've noticed however that when configuring the > tunnel device the author recommends a MTU of 1440. Recently I added a > firewall rule like: > > ipfw add fwd ip from to any > > to force the next hop through the tunnel. Well it didn't work, it did for > small amounts of data but not larger ones which lead me to suspect a path > MTU discovery problem. I reconfigured the tunnel device for a MTU of 1500 > and it works great. My question is when using ipfw fwd what happens if the > size of the packet exceeds the MTU of the device? When IPFW FWDing does > ICMP 3.4 messages get sent back for large packets whos dont fragment > bit is set? or does that packet just get dropped? It > would appear the icmp 3.4 message doesn't get sent back but that could be > because of the pipsecd port. > > Kindof curious & thanks, > John > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Dec 8 11: 9:23 2000 From owner-freebsd-security@FreeBSD.ORG Fri Dec 8 11:09:20 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from smtp.nettoll.com (unknown [212.155.143.61]) by hub.freebsd.org (Postfix) with ESMTP id A8BAE37B400 for ; Fri, 8 Dec 2000 11:09:19 -0800 (PST) Received: by smtp.nettoll.com; Fri, 8 Dec 2000 20:03:41 +0100 (MET) Message-Id: <4.3.0.20001208200512.0577a150@pop.free.fr> X-Sender: usebsd@pop.free.fr X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Fri, 08 Dec 2000 20:10:00 +0100 To: Manfred Petz , "Jacques A. Vidrine" From: mouss Subject: Re: TIS Firewall Tookit Cc: Alexander Gavrilov , freebsd-security@FreeBSD.ORG In-Reply-To: References: <20001206081015.B61027@spawn.nectar.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 15:50 06/12/00 +0100, Manfred Petz wrote: >On Wed, 6 Dec 2000, Jacques A. Vidrine wrote: > >| Neither SOCKS nor delegate are firewall software. The latter, in >| particular, is probably one of the least secure pieces of proxy software >| ever written. > >Accepted. Do you know a (free) alternative to FWTK which is comparable in >terms of ease of use, straightforward source and which implements similar >functionality (e.g. the permit/deny rules in netperm-table)? the plug-gw, from the FWTK, is just far better than delegate! don't let htto-gw and smap descrepancies make you conclude that the whole thing is to throw away... for smtp, smap approach breaks much things, and your best way is to use a secure server instead. you can then put a plug-gw to only accept mail that goes through this server... cheers, mouss To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Dec 8 12:33:31 2000 From owner-freebsd-security@FreeBSD.ORG Fri Dec 8 12:33:29 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id C765037B400 for ; Fri, 8 Dec 2000 12:33:29 -0800 (PST) Received: from hamlet.nectar.com (hamlet.nectar.com [10.0.1.102]) by gw.nectar.com (Postfix) with ESMTP id 4AAAA193E9; Fri, 8 Dec 2000 14:33:29 -0600 (CST) Received: (from nectar@localhost) by hamlet.nectar.com (8.11.1/8.9.3) id eB8KXTE98103; Fri, 8 Dec 2000 14:33:29 -0600 (CST) (envelope-from nectar@spawn.nectar.com) Date: Fri, 8 Dec 2000 14:33:29 -0600 From: "Jacques A. Vidrine" To: mouss Cc: Manfred Petz , Alexander Gavrilov , freebsd-security@FreeBSD.ORG Subject: Re: TIS Firewall Tookit Message-ID: <20001208143329.B94411@hamlet.nectar.com> Mail-Followup-To: "Jacques A. Vidrine" , mouss , Manfred Petz , Alexander Gavrilov , freebsd-security@FreeBSD.ORG References: <20001206081015.B61027@spawn.nectar.com> <4.3.0.20001208200512.0577a150@pop.free.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.0.20001208200512.0577a150@pop.free.fr>; from usebsd@free.fr on Fri, Dec 08, 2000 at 08:10:00PM +0100 X-Url: http://www.nectar.com/ Sender: nectar@nectar.com Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Dec 08, 2000 at 08:10:00PM +0100, mouss wrote: > for smtp, smap approach breaks much things, and your best way is to > use a secure server instead. you can then put a plug-gw to only accept > mail that goes through this server... Funny, IMHO smapd is one of the best parts of the toolkit. It doesn't ``break'' anything, to my knowledge, though perhaps there are some SMTP extensions that are not supported. -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Dec 8 14:37:40 2000 From owner-freebsd-security@FreeBSD.ORG Fri Dec 8 14:37:39 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from grok.example.net (a0g1355ly34tj.bc.hsia.telus.net [216.232.254.227]) by hub.freebsd.org (Postfix) with ESMTP id 2F78437B400 for ; Fri, 8 Dec 2000 14:37:39 -0800 (PST) Received: by grok.example.net (Postfix, from userid 1000) id 16C39212EC6; Fri, 8 Dec 2000 14:37:37 -0800 (PST) Date: Fri, 8 Dec 2000 14:37:37 -0800 From: Steve Reid To: Dag-Erling Smorgrav Cc: Matt Chew Spence , freebsd-security@FreeBSD.ORG Subject: Re: toor account Message-ID: <20001208143737.A90180@grok.bc.hsia.telus.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from Dag-Erling Smorgrav on Fri, Dec 08, 2000 at 11:35:40AM +0100 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Dec 08, 2000 at 11:35:40AM +0100, Dag-Erling Smorgrav wrote: > You can. I understand the only reason there's a toor account in the > first place is so C-shell and Bourne-shell lovers can both have their > favorite shell as root shell. I normally set toor to my shell of choice (zsh) and keep root around as /bin/sh in case something should ever go wrong that would stop zsh from working. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Dec 9 23:36: 7 2000 From owner-freebsd-security@FreeBSD.ORG Sat Dec 9 23:36:05 2000 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from citi.umich.edu (citi.umich.edu [141.211.92.141]) by hub.freebsd.org (Postfix) with ESMTP id 6AE9137B400; Sat, 9 Dec 2000 23:36:01 -0800 (PST) Received: from citi.umich.edu (ssh-mapper.citi.umich.edu [141.211.92.147]) by citi.umich.edu (Postfix) with ESMTP id C536E207C1; Sun, 10 Dec 2000 02:35:50 -0500 (EST) Subject: Re: Re[2]: OpenSSH 2.3.0 pre-upgrade From: Niels Provos In-Reply-To: Boris, Sat, 25 Nov 2000 11:05:04 PST To: Boris Cc: Kris Kennaway , "Brian F. Feldman" , security@FreeBSD.ORG Date: Sun, 10 Dec 2000 02:35:50 -0500 Sender: provos@citi.umich.edu Message-Id: <20001210073550.C536E207C1@citi.umich.edu> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <7885578635.20001125110504@x-itec.de>, Boris writes: >How to recreate these numbers? I do not like static factors for >encryption, they are always a security risc But you like the one single static group that is being used in the basic DH key exchange? That does not make much sense. The primes were generated with a program written by Phil Karn and Bill Simpson. You can find the programs used to generate them at http://www.citi.umich.edu/u/provos/tmp/prime.tar.gz Niels. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message