From owner-freebsd-security Sun Jan 10 07:10:28 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA29938 for freebsd-security-outgoing; Sun, 10 Jan 1999 07:10:28 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from prom.priovtb.ryazan.ru (mail.priovtb.ryazan.ru [195.9.65.14]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA29933 for ; Sun, 10 Jan 1999 07:10:25 -0800 (PST) (envelope-from alex@priovtb.ryazan.ru) Received: from prom (prom.priovtb.ryazan.ru [192.168.1.1]) by prom.priovtb.ryazan.ru with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2232.9) id Z07BY069; Sun, 10 Jan 1999 18:09:52 +0300 Message-ID: <00a601be3cab$45ee6c80$0101a8c0@prom.priovtb.ryazan.ru> From: "Alexander Avanesov" To: Subject: Need help with IPSec Date: Sun, 10 Jan 1999 18:09:52 +0300 X-FTN-Tearline: MS Fidolook Express 4.72.2106.4 - V1.1eng MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello. Maybe dummy question, but I want to find a solution. I have two FreeBSD-2.2.6R connected via RadioEthernet. So, I want to establish a virtual channel. My network is look like this: 1st LAN: 192.168.1.0/24 (This one is fron one side of Radio) 2nd LAN: 192.168.2.0/24 (It's here too) 3rd LAN: 192.168.3.0/24 (This is from another side) 192.168.222.100 <--> 192.168.222.101 (That's a Radiolink) 1st, 2nd, and 192.168.222.100 is on one FreeBSD and 3rd and 192.168.222.101 is on another FreeBSD So, I try to implement a virtual channel between them. I got a ipsec distribution from www.r4k.net and built it. A question is: how to setup ipsecadm and rt to get a tunnel? Thanks in advance. --- Cheers, Alexander ICQ UIN 16607548 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jan 10 20:40:12 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA00650 for freebsd-security-outgoing; Sun, 10 Jan 1999 20:40:12 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from atdot.dotat.org (atdot.dotat.org [203.23.150.35]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA00639 for ; Sun, 10 Jan 1999 20:40:07 -0800 (PST) (envelope-from newton@atdot.dotat.org) Received: (from newton@localhost) by atdot.dotat.org (8.9.1/8.7) id PAA16078; Mon, 11 Jan 1999 15:04:50 +1030 (CST) From: Mark Newton Message-Id: <199901110434.PAA16078@atdot.dotat.org> Subject: Re: About chroot To: Don.Lewis@tsc.tdk.com (Don Lewis) Date: Mon, 11 Jan 1999 15:04:49 +1030 (CST) Cc: robert+freebsd@cyrus.watson.org, newton@camtech.com.au, eivind@yes.no, casper@acc.am, freebsd-security@FreeBSD.ORG In-Reply-To: <199901071001.CAA03365@salsa.gv.tsc.tdk.com> from "Don Lewis" at Jan 7, 99 02:01:41 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 Don Lewis wrote: > } > > kern/9183 > } > > } > It seems like a neat idea. However, enabling vfs.hard_chroot may break > } > security in certain environments--in particular, environments where a > } > chroot is used as part of the system bootup, and where existing > } > services will try to use chroot to create sandboxes. > } > } Agreed. I figured those cases would make up a minority. > > There's at least one place where I need two levels of chroot(). The hack > that I'm currently using added another rdir-like entry to struct filedesc. > I'm currently in the process of reimplementing this as a stack. The main > main problem I'm having is a lack of time to work on the code. > One tricky thing is that once you allow more than one level of chroot(), > you create the possibility of breaking out of the jail. I've got some > ideas on how to protect against this. Care to share? Although multiple recursive levels of chroot() are one of those things that would be "nice to have", do you think the implementational complexity of an in-kernel root directory stack are worth it considering that people have been able to work around chroot() limitations for the last 20 years or so? [ ooooh, I'm gonna get it in the neck for that question... ] > } Of course -- But that's relatively easy: The same check for > } p_rdir that's used to work out whether chroot() should fail can also > } be placed into mknod(2) and mount(2). I wouldn't even need to > } unstaticize hard_chroot to make those changes happen. > > I did something like this a couple years ago (don't forget about umount()). > My current preference would be to set a flag in struct proc that disables > access to these. The process that puts the suspect process in jail would > do the chroot() and set the flag. I've modified my initial patch to vfs_syscalls.c; It now affects the syscalls described below if the caller's root directory is not the same as init's root directory AND vfs.hard_chroot != 0 AND if an additional supplementary condition evaluates to true, regardless of the uid of the caller: system call supplementary condition ------------------------------------------------------------------ mount true (:-) umount true chroot true mknod true (only affects mknod(2); FIFOs are still allowed) chmod mode & S_ISUID lchmod mode & S_ISUID fchmod mode & S_ISUID The last three are to prevent a chroot'ed user from making setuid binaries of any kind regardless of who owns them. The vfs.hard_chroot test is performed by means of a macro called FAIL_HARD_CHROOT() defined in the same place as the hard_chroot sysctl. It takes one parameter, which is the supplementary conditional used to fail the syscall. FHC_ALWAYS is defined to 1 for the cases marked as "true" in the table above. > Even better would be finer grained access control. It's too bad that POSIX > wasn't able to standardize something. IRIX, HP-UX and Solaris have ACLs. Mind you, they also have filesystems which support multiple "forks" per file to support them... > } We'd probably also want to restrict a user's ability to access LKM/KLD > } interfaces, assuming they're in the kernel in the first place. reboot(2) > } should also be restricted. Are there any others? (deny bind()ing to > } privileged ports? nah, that'd break ftpd, which is part of the > } intended audience of the patch, with very few security benefits). > > I disabled access to lkms, blocked access to processes outside the > jail by kill() and ptrace(). On further reflection, the lkm (or kld) and ptrace cases are already covered by kern.securelevel. The kill case could be covered by unstaticizing hard_chroot, putting the FAIL_HARD_CHROOT() macro into a .h file, and putting something like the following (untested code) at the front of kill()/killpg()/etc in kern_sig.c: FAIL_HARD_CHROOT((pfind(uap->pid))->p_fd->fd_rdir != cp->p_fd->fd_rdir); i.e.: fail the kill() operation if the root directory of the target is not the same as the root directory of the caller. This would mean that processes in one jail couldn't kill processes in other jails on the same system too. vfs_syscalls.c patch against 3.0-RELEASE follows (sans documentation). - mark *** vfs_syscalls.c.3.0-R Thu Dec 24 17:01:07 1998 --- vfs_syscalls.c Mon Jan 11 14:34:52 1999 *************** *** 86,92 **** --- 86,107 ---- static int setutimes __P((struct proc *, struct vnode *, struct timeval *, int)); static int usermount = 0; /* if 1, non-root can mount fs. */ + /* + * hard_chroot - If 1, we can fail some syscalls with EPERM for any processes + * which are chroot()ed. + */ + #define FAIL_HARD_CHROOT(when) if (hard_chroot) { \ + if (p->p_fd->fd_rdir != initproc->p_fd->fd_rdir) \ + if ((when)) { \ + return(EPERM); \ + } \ + } + #define FHC_ALWAYS 1 + + static int hard_chroot = 0; + SYSCTL_INT(_vfs, OID_AUTO, usermount, CTLFLAG_RW, &usermount, 0, ""); + SYSCTL_INT(_vfs, OID_AUTO, hard_chroot, CTLFLAG_RW, &hard_chroot, 0, ""); /* * Virtual File System System Calls *************** *** 123,128 **** --- 138,145 ---- struct nameidata nd; char fstypename[MFSNAMELEN]; + FAIL_HARD_CHROOT(FHC_ALWAYS); + if (usermount == 0 && (error = suser(p->p_ucred, &p->p_acflag))) return (error); *************** *** 400,405 **** --- 417,424 ---- int error; struct nameidata nd; + FAIL_HARD_CHROOT(FHC_ALWAYS); + NDINIT(&nd, LOOKUP, FOLLOW | LOCKLEAF, UIO_USERSPACE, SCARG(uap, path), p); if (error = namei(&nd)) *************** *** 832,837 **** --- 851,858 ---- int error; struct nameidata nd; + FAIL_HARD_CHROOT(FHC_ALWAYS); + error = suser(p->p_ucred, &p->p_acflag); if (error) return (error); *************** *** 1017,1022 **** --- 1038,1045 ---- int whiteout = 0; struct nameidata nd; + FAIL_HARD_CHROOT(FHC_ALWAYS); + error = suser(p->p_ucred, &p->p_acflag); if (error) return (error); *************** *** 1920,1925 **** --- 1943,1950 ---- int error; struct nameidata nd; + FAIL_HARD_CHROOT(uap->mode & S_ISUID); + NDINIT(&nd, LOOKUP, FOLLOW, UIO_USERSPACE, SCARG(uap, path), p); if (error = namei(&nd)) return (error); *************** *** 1949,1954 **** --- 1974,1981 ---- int error; struct nameidata nd; + FAIL_HARD_CHROOT(uap->mode & S_ISUID); + NDINIT(&nd, LOOKUP, NOFOLLOW, UIO_USERSPACE, SCARG(uap, path), p); if (error = namei(&nd)) return (error); *************** *** 1977,1982 **** --- 2004,2011 ---- { struct file *fp; int error; + + FAIL_HARD_CHROOT(uap->mode & S_ISUID); if (error = getvnode(p->p_fd, SCARG(uap, fd), &fp)) return (error); -------------------------------------------------------------------- I tried an internal modem, newton@atdot.dotat.org but it hurt when I walked. Mark Newton ----- Voice: +61-4-1958-3414 ------------- Fax: +61-8-83034403 ----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jan 10 20:56:37 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA02562 for freebsd-security-outgoing; Sun, 10 Jan 1999 20:56:37 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from fledge.watson.org (FLEDGE.RES.CMU.EDU [128.2.93.229]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA02555 for ; Sun, 10 Jan 1999 20:56:35 -0800 (PST) (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 XAA12877; Sun, 10 Jan 1999 23:52:40 -0500 (EST) Date: Sun, 10 Jan 1999 23:52:39 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Mark Newton cc: Don Lewis , newton@camtech.com.au, eivind@yes.no, casper@acc.am, freebsd-security@FreeBSD.ORG Subject: Re: About chroot In-Reply-To: <199901110434.PAA16078@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 Mon, 11 Jan 1999, Mark Newton wrote: > Although multiple recursive levels of chroot() are one of those things > that would be "nice to have", do you think the implementational > complexity of an in-kernel root directory stack are worth it considering > that people have been able to work around chroot() limitations for the > last 20 years or so? I'd really like to see truly nested sandboxing in a general sense :). The Java people summarily failed to manage it in their 1.2 security model; they have no concept of nested sandboxes. A great example of a nested sandbox would be netscape running as an application under an operating system (that is, in a sandbox preventing privileged access, etc), and then an applet running under netscape in a further restricted sandbox. Or active code running in an execution environment on an active network router, etc. However! This doesn't mean I think it belongs in UNIX. Nested chroot is clearly desirable--that is, I chroot at boot time to bump me from my CD-ROM / to an MFS-mounted / or something, but then ftpd or httpd makes use of chroot to restrict users to specific directories. Only the inner-most chroot needs to be 'hard' by your definition of hard, I think (or perhaps I have it backwards--I spent most of the day traveling :). > [ ooooh, I'm gonna get it in the neck for that question... ] Deep question, but FreeBSD in my view should not be an outlet for it. The whole syscall things and privileged processor stuff doesn't really make it appropriate. Mach and Trusted Mach were a nice thought but having a universal 'file system' with a universal 'name space' is really not going to fly, I think. So I think we should drop the question for now and raise it another day, and possibly another operating system. By appropriately writing userland libraries to allow 'services' mach-style, and not trying to have a syscall interface per se, you could have quite a spiffy nest sandbox. > > Even better would be finer grained access control. It's too bad that POSIX > > wasn't able to standardize something. > > IRIX, HP-UX and Solaris have ACLs. I would have implemented this long ago in FreeBSD if I could just get the d*mn POSIX draft describing them. Someone find me a copy (fax it, email it, mail it, something -- I'll pay postage, shipping, etc) and I'll do it :-). That and POSIX capabilities. Not that either is ideal in my view (I prefer AFS-style directory ACLs myself, and I think that capabilities POSIX-style (as I understand them, not having seen the spec) are really just a gross hack). > Mind you, they also have filesystems which support multiple "forks" per > file to support them... Well, it depends how you do it. Someone's thesis at UCLA (I have a copy around here somewhere and will dig it up) involved using a multi-fork layered file system to add ACL support, but I wasn't impressed (they forgot to include a biobliography in the masters thesis). Terry also talks fairly frequently about ACLfs. I'm not convinced this is the long-term solution, although it would be great for an initial implementation if layering worked. If you really want ACLs, I suspect it should be built into the base file system, as they are designed as a suplement to permissions. Again, not having seen the spec, I can't judge how realistic that suggestion is. Without user-defined groups, ACLs are a real pain to manage. > > } We'd probably also want to restrict a user's ability to access LKM/KLD > > } interfaces, assuming they're in the kernel in the first place. reboot(2) > > } should also be restricted. Are there any others? (deny bind()ing to > > } privileged ports? nah, that'd break ftpd, which is part of the > > } intended audience of the patch, with very few security benefits). > > > > I disabled access to lkms, blocked access to processes outside the > > jail by kill() and ptrace(). > > On further reflection, the lkm (or kld) and ptrace cases are already > covered by kern.securelevel. > > The kill case could be covered by unstaticizing hard_chroot, putting > the FAIL_HARD_CHROOT() macro into a .h file, and putting something like > the following (untested code) at the front of kill()/killpg()/etc in > kern_sig.c: > > FAIL_HARD_CHROOT((pfind(uap->pid))->p_fd->fd_rdir != cp->p_fd->fd_rdir); > > i.e.: fail the kill() operation if the root directory of the target > is not the same as the root directory of the caller. This would > mean that processes in one jail couldn't kill processes in other > jails on the same system too. But I'd like my restricted environment manager to be able to kill processes running in the environment without actually being in it. And that harps back to the whole nested thing. I'm not convinced that chroot is really particularly compatible with such a hackish operating system as UNIX. Too much is based in the file system, and there are so many ways of doing everything, especially once you through in sysV shared memory, mmaping, device nodes, etc. What a pain securelevels are to do right, and they provide such basic functionality. So much is based on uid--one might do better to simply replace the underlying authorization system all over the place than try to hack in support. Robert N Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C 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 Sun Jan 10 23:03:51 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA17480 for freebsd-security-outgoing; Sun, 10 Jan 1999 23:03:51 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from atdot.dotat.org (atdot.dotat.org [203.23.150.35]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA17475 for ; Sun, 10 Jan 1999 23:03:47 -0800 (PST) (envelope-from newton@atdot.dotat.org) Received: (from newton@localhost) by atdot.dotat.org (8.9.1/8.7) id RAA19654; Mon, 11 Jan 1999 17:29:08 +1030 (CST) From: Mark Newton Message-Id: <199901110659.RAA19654@atdot.dotat.org> Subject: Re: About chroot To: robert+freebsd@cyrus.watson.org Date: Mon, 11 Jan 1999 17:29:08 +1030 (CST) Cc: Don.Lewis@tsc.tdk.com, newton@camtech.com.au, eivind@yes.no, casper@acc.am, freebsd-security@FreeBSD.ORG In-Reply-To: from "Robert Watson" at Jan 10, 99 11:52:39 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 Robert Watson wrote: > On Mon, 11 Jan 1999, Mark Newton wrote: > > Although multiple recursive levels of chroot() are one of those things > > that would be "nice to have", do you think the implementational > > complexity of an in-kernel root directory stack are worth it considering > > that people have been able to work around chroot() limitations for the > > last 20 years or so? > > I'd really like to see truly nested sandboxing in a general sense :). Ah, that's different from the design goals of hard_chroot All I'm trying to achieve is a hardening of the concept of chroot() which will suit the majority of cases people use it for *at present* (i.e.: anonymous ftpd, httpd, jails for shells, etc). Nested sandboxing will no doubt open up whole new vistas of applications that hard_chroot is ill-suited for, but they're kinda not quite here yet :-) In the meantime, I know quite a few people who don't need nested sandboxing who have itches in hard to reach places as nervous reactions against chroot(). > Nested chroot is clearly desirable--that is, I chroot at boot time to bump > me from my CD-ROM / to an MFS-mounted / or something, but then ftpd or > httpd makes use of chroot to restrict users to specific directories. > Only the inner-most chroot needs to be 'hard' by your definition of hard, > I think. That's a degenerate case: The chroot happens before init starts, so all non-jailed processes running off the CD-ROM or MFS will have the same fd_rdir as init unless they're specifically chroot()ed, hence they'll be unrestricted by vfs.hard_chroot unless you actually invest effort in restricting them. > > > Even better would be finer grained access control. It's too bad > > > that POSIX wasn't able to standardize something. > > > > IRIX, HP-UX and Solaris have ACLs. > > I would have implemented this long ago in FreeBSD if I could just get the > d*mn POSIX draft describing them. Terry doesn't have a reference? [ or an alias? :-) ] > > the following (untested code) at the front of kill()/killpg()/etc in > > kern_sig.c: > > > > FAIL_HARD_CHROOT((pfind(uap->pid))->p_fd->fd_rdir != cp->p_fd->fd_rdir); > > > > i.e.: fail the kill() operation if the root directory of the target > > is not the same as the root directory of the caller. This would > > mean that processes in one jail couldn't kill processes in other > > jails on the same system too. > > But I'd like my restricted environment manager to be able to kill > processes running in the environment without actually being in it. You could do that if your restricted environment manager wasn't running in a jail (remember, FAIL_HARD_CHROOT(x) only fails if x is true *AND* the process calling it is in a jail (*AND* vfs.hard_chroot is nonzero) -- Hence normal process killing semantics apply for unjailed processes, including the ability for an unjailed process to kill a jailed one). A jailed process can kill any other process which is in the same jail. An unjailed process can kill anyone as per the original semantics of kill(2). It sounds like what you really want is machine partitioning. IRIX 6.5 does this as a hardware/software bundle on ORIGIN architectures (allowing you to set up partitions on ORIGIN module boundries), but I don't think FreeBSD is quite in that league yet. Know any grad students looking for a project? :-) In the meantime, are we going to do anything about chroot() ? - mark -------------------------------------------------------------------- I tried an internal modem, newton@atdot.dotat.org but it hurt when I walked. Mark Newton ----- Voice: +61-4-1958-3414 ------------- Fax: +61-8-83034403 ----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jan 10 23:19:49 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA19794 for freebsd-security-outgoing; Sun, 10 Jan 1999 23:19:49 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from hotmail.com (f48.hotmail.com [207.82.250.59]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id XAA19789 for ; Sun, 10 Jan 1999 23:19:48 -0800 (PST) (envelope-from madrapour@hotmail.com) Received: (qmail 19304 invoked by uid 0); 11 Jan 1999 07:19:15 -0000 Message-ID: <19990111071915.19303.qmail@hotmail.com> Received: from 208.218.169.25 by www.hotmail.com with HTTP; Sun, 10 Jan 1999 23:19:15 PST X-Originating-IP: [208.218.169.25] From: "N. N.M" To: freebsd-security@FreeBSD.ORG Subject: Need help with IPFW Date: Sun, 10 Jan 1999 23:19:15 PST Mime-Version: 1.0 Content-Type: text/plain Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, Is there anybody around who knows what the following log (related to ipfw) means: ipfw -1 Refuse TCP X.X.X.X:80 Y.Y.Y.Y:2047 in via ed1 or this one ipfw -1 Refuse TCP X.X.X.X Y.Y.Y.Y in via edi Fragment=1 Naturally, I don't have any rule with number -1 and also not any rule involves any of the source or destination address mentioned in the above rules. Please let me know if any of you knows something about it. Thanks, Nazila N. ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 11 02:42:26 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA13128 for freebsd-security-outgoing; Mon, 11 Jan 1999 02:42:26 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA13123 for ; Mon, 11 Jan 1999 02:42:25 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id CAA19371; Mon, 11 Jan 1999 02:35:19 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id CAA28654; Mon, 11 Jan 1999 02:35:18 -0800 (PST) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id CAA15251; Mon, 11 Jan 1999 02:35:16 -0800 (PST) From: Don Lewis Message-Id: <199901111035.CAA15251@salsa.gv.tsc.tdk.com> Date: Mon, 11 Jan 1999 02:35:16 -0800 In-Reply-To: Mark Newton "Re: About chroot" (Jan 11, 3:04pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Mark Newton , Don.Lewis@tsc.tdk.com (Don Lewis) Subject: Re: About chroot Cc: robert+freebsd@cyrus.watson.org, newton@camtech.com.au, eivind@yes.no, casper@acc.am, freebsd-security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Jan 11, 3:04pm, Mark Newton wrote: } Subject: Re: About chroot } Don Lewis wrote: } } > } > > kern/9183 } > } > } > } > It seems like a neat idea. However, enabling vfs.hard_chroot may break } > } > security in certain environments--in particular, environments where a } > } > chroot is used as part of the system bootup, and where existing } > } > services will try to use chroot to create sandboxes. } > } } > } Agreed. I figured those cases would make up a minority. } > } > There's at least one place where I need two levels of chroot(). The hack } > that I'm currently using added another rdir-like entry to struct filedesc. } > I'm currently in the process of reimplementing this as a stack. The main } > main problem I'm having is a lack of time to work on the code. } > One tricky thing is that once you allow more than one level of chroot(), } > you create the possibility of breaking out of the jail. I've got some } > ideas on how to protect against this. } } Care to share? I'm hoping that I can post a patch in the next week or so. The problem is that I've been hoping the same thing for quite a while :-( } Although multiple recursive levels of chroot() are one of those things } that would be "nice to have", do you think the implementational } complexity of an in-kernel root directory stack are worth it considering } that people have been able to work around chroot() limitations for the } last 20 years or so? It's worthwhile for me. The implementation isn't too bad. Unfortunately it requires some tweaks to fstat, lsof, etc. } } [ ooooh, I'm gonna get it in the neck for that question... ] } } > } Of course -- But that's relatively easy: The same check for } > } p_rdir that's used to work out whether chroot() should fail can also } > } be placed into mknod(2) and mount(2). I wouldn't even need to } > } unstaticize hard_chroot to make those changes happen. } > } > I did something like this a couple years ago (don't forget about umount()). } > My current preference would be to set a flag in struct proc that disables } > access to these. The process that puts the suspect process in jail would } > do the chroot() and set the flag. } } I've modified my initial patch to vfs_syscalls.c; It now affects the } syscalls described below if the caller's root directory is not the } same as init's root directory AND vfs.hard_chroot != 0 AND if an additional } supplementary condition evaluates to true, regardless of the uid of } the caller: } } system call supplementary condition } ------------------------------------------------------------------ } mount true (:-) } umount true } chroot true } mknod true (only affects mknod(2); FIFOs are still } allowed) } chmod mode & S_ISUID } lchmod mode & S_ISUID } fchmod mode & S_ISUID } } The last three are to prevent a chroot'ed user from making setuid } binaries of any kind regardless of who owns them. Good idea. I didn't need to do this because all the writeable areas of my sandboxes are mounted noexec. This could relax this to nosuid if necessary. } The vfs.hard_chroot test is performed by means of a macro called } FAIL_HARD_CHROOT() defined in the same place as the hard_chroot sysctl. } It takes one parameter, which is the supplementary conditional used } to fail the syscall. FHC_ALWAYS is defined to 1 for the cases marked } as "true" in the table above. } } > Even better would be finer grained access control. It's too bad that POSIX } > wasn't able to standardize something. } } IRIX, HP-UX and Solaris have ACLs. I wasn't thinking of file ACLs, which would also be nice to have, but rather a flag that controls whether or not you can mount(), etc. What would be really cool is phk's sandbox stuff. } > } We'd probably also want to restrict a user's ability to access LKM/KLD } > } interfaces, assuming they're in the kernel in the first place. reboot(2) } > } should also be restricted. Are there any others? (deny bind()ing to } > } privileged ports? nah, that'd break ftpd, which is part of the } > } intended audience of the patch, with very few security benefits). } > } > I disabled access to lkms, blocked access to processes outside the } > jail by kill() and ptrace(). } } On further reflection, the lkm (or kld) and ptrace cases are already } covered by kern.securelevel. You can't ptrace the init process when securelevel > 0, but I think everything else is wide open. } The kill case could be covered by unstaticizing hard_chroot, putting } the FAIL_HARD_CHROOT() macro into a .h file, and putting something like } the following (untested code) at the front of kill()/killpg()/etc in } kern_sig.c: } } FAIL_HARD_CHROOT((pfind(uap->pid))->p_fd->fd_rdir != cp->p_fd->fd_rdir); } } i.e.: fail the kill() operation if the root directory of the target } is not the same as the root directory of the caller. This would } mean that processes in one jail couldn't kill processes in other } jails on the same system too. This is pretty much the same as what I implemented. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 11 03:29:24 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA19014 for freebsd-security-outgoing; Mon, 11 Jan 1999 03:29:24 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from enya.clari.net.au (enya.clari.net.au [203.8.14.116]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA19008 for ; Mon, 11 Jan 1999 03:29:20 -0800 (PST) (envelope-from danny@enya.clari.net.au) Received: from localhost (danny@localhost) by enya.clari.net.au (8.8.8/8.8.7) with SMTP id WAA23282; Mon, 11 Jan 1999 22:28:37 +1100 (EST) (envelope-from danny@enya.clari.net.au) Date: Mon, 11 Jan 1999 22:28:37 +1100 (EST) From: "Daniel O'Callaghan" To: "N. N.M" cc: freebsd-security@FreeBSD.ORG Subject: Re: Need help with IPFW In-Reply-To: <19990111071915.19303.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 Sun, 10 Jan 1999, N. N.M wrote: > Is there anybody around who knows what the following log (related to > ipfw) means: > > ipfw -1 Refuse TCP X.X.X.X:80 Y.Y.Y.Y:2047 in via ed1 > > or this one > > ipfw -1 Refuse TCP X.X.X.X Y.Y.Y.Y in via edi Fragment=1 This one is covered by the man page. *All* tcp packets with Fragment offset=1 are rejected because they are only used to circumvent firewalls. The first packet was probably the first packet in the attack, and had something odd about it which caused the ip_fw code to refuse it as a bogus fragment. Danny To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 11 07:22:48 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA17239 for freebsd-security-outgoing; Mon, 11 Jan 1999 07:22:48 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from fledge.watson.org (FLEDGE.RES.CMU.EDU [128.2.93.229]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA17233 for ; Mon, 11 Jan 1999 07:22:45 -0800 (PST) (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 KAA15109; Mon, 11 Jan 1999 10:16:47 -0500 (EST) Date: Mon, 11 Jan 1999 10:16:47 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Mark Newton cc: Don.Lewis@tsc.tdk.com, newton@camtech.com.au, eivind@yes.no, casper@acc.am, freebsd-security@FreeBSD.ORG, terry@lambert.org Subject: Re: About chroot In-Reply-To: <199901110659.RAA19654@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 Mon, 11 Jan 1999, Mark Newton wrote: > > Nested chroot is clearly desirable--that is, I chroot at boot time to bump > > me from my CD-ROM / to an MFS-mounted / or something, but then ftpd or > > httpd makes use of chroot to restrict users to specific directories. > > Only the inner-most chroot needs to be 'hard' by your definition of hard, > > I think. > > That's a degenerate case: The chroot happens before init starts, so > all non-jailed processes running off the CD-ROM or MFS will have > the same fd_rdir as init unless they're specifically chroot()ed, hence > they'll be unrestricted by vfs.hard_chroot unless you actually invest > effort in restricting them. For common use today, that is a degenerate case. But in the event of more sophisticated network file systems (such as AFS, Coda, Samba, etc) in the boot process, it might be desirable for userland daemons to support the file system later used as /. For example, Coda and AFS both require a userland process that acts as a cache manager. The cache manager attaches to a device in /dev and uses it for up/downcalls from the kernel. When the kernel sees a reference to a section of the file system maintained by the cache manager, it will proxy some of the request to the userland process so that files can be transfered from file servers, and user interaction can occur in the event of failure or a requirement for authentication, etc. But for all this to work, you have to have a userland process running that also has access to space on disk to have a file cache and, in Coda's case, log space for disconnected operation. I can see the case where after boot, you would want / to be in AFS or Coda for reasons of scalability and management (not to mention consistency from the user's point of view--having one kind of ACL everywhere makes a lot of sense). The easiest way to do that might be to have a multi-phase boot, in which first the kernel loads up off a local file system, runs the cache manager via the rc scripts from init, and when all is ready, something (rc or init or someone) chroots before continuing on to the rest of the interesting boot stuff. This would probably require a more structured rc sequence, possibly with runlevels, etc, but seems like a useful goal. > > > > Even better would be finer grained access control. It's too bad > > > > that POSIX wasn't able to standardize something. > > > > > > IRIX, HP-UX and Solaris have ACLs. > > > > I would have implemented this long ago in FreeBSD if I could just get the > > d*mn POSIX draft describing them. > > Terry doesn't have a reference? > > [ or an alias? :-) ] I don't know--Terry, do you have a reference? :) I've been searching, and someone finally pointed me at a site for discussing IEEE computer science drafts, but it requires a subscription, and it wasn't even clear to me that the draft would be available there if I did have a subscription. If anyone knows for sure where it is, I'll get a subscription, but I'm reluctant to shell out without knowing more about what I'm getting. I'll do more research this week and see what I can dig up (the reference librarian's at CMU's library were, unfortunately, not very useful :-). > You could do that if your restricted environment manager wasn't running > in a jail (remember, FAIL_HARD_CHROOT(x) only fails if x is true *AND* > the process calling it is in a jail (*AND* vfs.hard_chroot is nonzero) > -- Hence normal process killing semantics apply for unjailed processes, > including the ability for an unjailed process to kill a jailed one). > > A jailed process can kill any other process which is in the same > jail. An unjailed process can kill anyone as per the original semantics > of kill(2). sounds great :). That is what I had hoped for, but misinterpretted as not being there. > It sounds like what you really want is machine partitioning. IRIX 6.5 > does this as a hardware/software bundle on ORIGIN architectures (allowing > you to set up partitions on ORIGIN module boundries), but I don't think > FreeBSD is quite in that league yet. > > Know any grad students looking for a project? :-) Sounds like a great project, but quite time consuming. I don't think I have the time :-). I don't have enough time for my own projects, let alone any new ones... Some of the Sun servers can do this also, always seemed like a great idea, albeit a complicated one. I suspect that rather than hacking this support into FreeBSD, you'd want to base it on something else and stick a BSD syscall interface on top, and a POSIX library set. > In the meantime, are we going to do anything about chroot() ? It looks spiffy, but I'd want to try it out for a while before anyone put it in. Want to put together a tarball of the patches, and a couple of sample programs that demonstrate the effectiveness of the chroot environment, as well as the signal behavior, etc? :) That way I can drop it in and play with it on a machine. Robert N Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C 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 Mon Jan 11 07:58:53 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA21827 for freebsd-security-outgoing; Mon, 11 Jan 1999 07:58:53 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from hosting.doublesquare.com (hosting.doublesquare.com [195.5.128.151]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA21818 for ; Mon, 11 Jan 1999 07:58:41 -0800 (PST) (envelope-from ark@eltex.ru) From: ark@eltex.ru Received: from eltex.ru (eltex-spiiras.nw.ru [195.19.204.46] (may be forged)) by hosting.doublesquare.com (8.8.8/8.8.8) with ESMTP id SAA02294; Mon, 11 Jan 1999 18:58:04 +0300 (MSK) Received: from border.eltex.spb.ru (root@border.eltex.ru [195.19.198.2]) by eltex.ru (8.8.8/8.8.8) with SMTP id SAA04034; Mon, 11 Jan 1999 18:58:09 +0300 (MSK) Received: by border.eltex.spb.ru (ssmtp TIS-0.5alpha, 19 Oct 1998); Mon, 11 Jan 1999 18:58:02 +0300 Received: from undisclosed-intranet-sender id xma001363; Mon, 11 Jan 99 18:57:43 +0300 Date: Mon, 11 Jan 1999 18:56:36 +0300 Message-Id: <199901111556.SAA12215@paranoid.eltex.spb.ru> In-Reply-To: <19990106095543.B28727@tversu.ru> from "Vadim Kolontsov " Organization: "Klingon Imperial Intelligence Service" Subject: Re: kernel/syslogd hack To: vadim@tversu.ru Cc: freebsd-security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org -----BEGIN PGP SIGNED MESSAGE----- nuqneH, Yep, realtime is a problem (and always will be a problem if we use UDP). nsyslogd can use TCP at least to ensure no data were lost. Vadim Kolontsov said : > > > Of course this patch doesn't solve problem with syslog/514 UDP. I > > > know it > > > > Have you looked at ssyslog from the guys in Brazil ? It takes the opposite > > approach by making the trusted machine download in a secure way the logs > > from each machine. > > Yes, I tried it. It tries to make network transfer secure, but does > nothing for local logs (gathered via UNIX domain socket). > > And their solution isn't best for real-time analyzing: it doesn't send > logs string by string (or at least nK-buffer by buffer). You can, of course, > configure it to download logs to log server every 2 minutes, and analyze them > then.. > And it deletes local logs after uploading to log server :) (this behaviour > can be changed, probably) > > But I think that ssyslog is good thing, anyway :) > > Regards, > V. > > P.S. I'm amazed - it seems that nobody (except ssyslogd and nsyslog people) > is working on more reliable/secure syslog replacement.. may be because > the whole protocol should be changed.. _ _ _ _ _ _ _ {::} {::} {::} CU in Hell _| o |_ | | _|| | / _||_| |_ |_ |_ (##) (##) (##) /Arkan#iD |_ o _||_| _||_| / _| | o |_||_||_| [||] [||] [||] Do i believe in Bible? Hell,man,i've seen one! -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBNpofM6H/mIJW9LeBAQFZNQP/QlxpfcW2zq7zggy5kHyRJ9LmMJtgZL9D Dx3zis40UU6Gy9tm4LJsRTbFMnjA9VrZDR07TGdsp4UO63VmoFJoX7uuABVzj+66 shfsPOcfKT9JngyUkuwCqhknfQDdGS2cjxI5b1vrdtBrlel4WK34dFKzZOc0974X gyowFIpz4zo= =Iz8L -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 12 00:21:58 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA14844 for freebsd-security-outgoing; Tue, 12 Jan 1999 00:21:58 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from bcgrizzly.com (bcgrizzly.com [207.34.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id AAA14838 for ; Tue, 12 Jan 1999 00:21:57 -0800 (PST) (envelope-from forger@bcgrizzly.com) Received: (qmail 28713 invoked from network); 12 Jan 1999 08:21:05 -0000 Received: from bcgrizzly.com (207.34.136.10) by bcgrizzly.com with SMTP; 12 Jan 1999 08:21:05 -0000 Date: Tue, 12 Jan 1999 00:21:05 -0800 (PST) From: Brook Miles To: freebsd-security@FreeBSD.ORG Subject: Quick ipfw question 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 Is there some reason that ipfw /my/file works but ipfw -q /my/file doesn't? It gives "ipfw: error: Bad Arguments" FreeBSD/i386 3.0-RELEASE +--- | Brook Miles | A spec of cosmic dust... with attitude. +-------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 12 04:24:56 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA11395 for freebsd-security-outgoing; Tue, 12 Jan 1999 04:24:56 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from shell6.ba.best.com (shell6.ba.best.com [206.184.139.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA11390 for ; Tue, 12 Jan 1999 04:24:55 -0800 (PST) (envelope-from jkb@shell6.ba.best.com) Received: (from jkb@localhost) by shell6.ba.best.com (8.9.1/8.9.0/best.sh) id EAA01790; Tue, 12 Jan 1999 04:23:58 -0800 (PST) Message-ID: <19990112042358.C303@best.com> Date: Tue, 12 Jan 1999 04:23:58 -0800 From: "Jan B. Koum " To: "Brian W. Buchanan" , Patrick Barmentlo Cc: security@FreeBSD.ORG Subject: Re: examples rules ipfw References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Brian W. Buchanan on Mon, Jan 11, 1999 at 02:56:44PM -0800 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [redirect from -hackers to -security] On Mon, Jan 11, 1999 at 02:56:44PM -0800, "Brian W. Buchanan" wrote: > On Mon, 11 Jan 1999, Patrick Barmentlo wrote: > > > Can someone please point me out to some good examples for the rc.firewall > > file (ipfw )?? > > (with most variant of opties/features...) > > > > i have to set up some filtering, but still having some difficulties with > > it after checking freebsd.org.... > > > add 00501 allow tcp from any to smarter 1024-65535 > > This allows all traffic to ports 1024 through 65535 (to let FTP work > correctly) This is not good! There are way MANY evil things running on ports greater then 1024. Take X windows (6000), take nfsd (2049). Most of the insecure solaris rpc crap runs in that range. This list could go on forever. You would be much better off using passive ftp (ftp -p) then opening up all those holes into your network. Just MHO. -- Yan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 12 05:35:16 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA19174 for freebsd-security-outgoing; Tue, 12 Jan 1999 05:35:16 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from hotmail.com (f252.hotmail.com [207.82.251.143]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id FAA19169 for ; Tue, 12 Jan 1999 05:35:15 -0800 (PST) (envelope-from madrapour@hotmail.com) Received: (qmail 13072 invoked by uid 0); 12 Jan 1999 13:34:36 -0000 Message-ID: <19990112133436.13071.qmail@hotmail.com> Received: from 208.218.169.84 by www.hotmail.com with HTTP; Tue, 12 Jan 1999 05:34:36 PST X-Originating-IP: [208.218.169.84] From: "N. N.M" To: freebsd-security@FreeBSD.ORG, forger@bcgrizzly.com Subject: Re: Quick ipfw question Date: Tue, 12 Jan 1999 05:34:36 PST Mime-Version: 1.0 Content-Type: text/plain Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The reason is simple: as the manual mentions, the argument "-q" is valid only with the following commands: - flush - zero no. - add ...... As you see, if you wanna use a file as ipfw's argument, you can't use "-q". Alternatively, you can use -q in each line (or each ipfw commands) in your file (/myfile). So the rules in this file are added "quietly". Nazila N. >Date: Tue, 12 Jan 1999 00:21:05 -0800 (PST) >From: Brook Miles >To: freebsd-security@FreeBSD.ORG >Subject: Quick ipfw question > > >Is there some reason that > ipfw /my/file >works but > ipfw -q /my/file >doesn't? > >It gives "ipfw: error: Bad Arguments" > >FreeBSD/i386 3.0-RELEASE > >+--- >| Brook Miles >| A spec of cosmic dust... with attitude. >+-------------------------------------- > > >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 Tue Jan 12 09:42:14 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA16818 for freebsd-security-outgoing; Tue, 12 Jan 1999 09:42:14 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from mired.eh.local (kstreet.interlog.com [198.53.146.171]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA16813 for ; Tue, 12 Jan 1999 09:42:12 -0800 (PST) (envelope-from street@iname.com) Received: (from kws@localhost) by mired.eh.local (8.9.1/8.9.1) id MAA00922; Tue, 12 Jan 1999 12:40:00 -0500 (EST) (envelope-from kws) From: Kevin Street MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <13979.35056.652849.117334@mired.eh.local> Date: Tue, 12 Jan 1999 12:40:00 -0500 (EST) To: Brook Miles Cc: freebsd-security@FreeBSD.ORG Subject: Re: Quick ipfw question In-Reply-To: References: X-Mailer: VM 6.63 under 20.4 "Emerald" XEmacs Lucid Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Brook Miles writes: > >Is there some reason that > ipfw /my/file >works but > ipfw -q /my/file >doesn't? > >It gives "ipfw: error: Bad Arguments" > >FreeBSD/i386 3.0-RELEASE It works in 3.0 -current. There were some bug fixes and additional capabilities added around 11/23. One of the comments in CVS says that it fixed a bug with blank lines in the file when using -q. The original support for -q with a file was added around 08/04 according to CVS. -- Kevin Street street@iName.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 12 11:14:05 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA27362 for freebsd-security-outgoing; Tue, 12 Jan 1999 11:14:05 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from bcgrizzly.com (bcgrizzly.com [207.34.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id LAA27355 for ; Tue, 12 Jan 1999 11:14:02 -0800 (PST) (envelope-from forger@bcgrizzly.com) Received: (qmail 3788 invoked from network); 12 Jan 1999 19:13:14 -0000 Received: from bcgrizzly.com (207.34.136.10) by bcgrizzly.com with SMTP; 12 Jan 1999 19:13:14 -0000 Date: Tue, 12 Jan 1999 11:13:14 -0800 (PST) From: Brook Miles To: "N. N.M" cc: freebsd-security@FreeBSD.ORG Subject: Re: Quick ipfw question In-Reply-To: <19990112133436.13071.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, 12 Jan 1999, N. N.M wrote: Well..the first example command line in my man page reads: ipfw [-q] file And so I rather expected it to work. But from the other responses it appears this is only a temporary bug, so I guess I'll just put up with it untill I get around to updating. Thanks for the help all, Brook > The reason is simple: as the manual mentions, the argument "-q" is valid > only with the following commands: > > - flush > - zero no. > - add ...... > > As you see, if you wanna use a file as ipfw's argument, you can't use > "-q". Alternatively, you can use -q in each line (or each ipfw commands) > in your file (/myfile). So the rules in this file are added "quietly". > > Nazila N. > > > >Date: Tue, 12 Jan 1999 00:21:05 -0800 (PST) > >From: Brook Miles > >To: freebsd-security@FreeBSD.ORG > >Subject: Quick ipfw question > > > > > >Is there some reason that > > ipfw /my/file > >works but > > ipfw -q /my/file > >doesn't? > > > >It gives "ipfw: error: Bad Arguments" > > > >FreeBSD/i386 3.0-RELEASE +--- | Brook Miles | A spec of cosmic dust... with attitude. +-------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 12 12:32:19 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA07218 for freebsd-security-outgoing; Tue, 12 Jan 1999 12:32:19 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from smarter.than.nu (thought.calbbs.com [207.71.213.16]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA07207 for ; Tue, 12 Jan 1999 12:32:16 -0800 (PST) (envelope-from brian@CSUA.Berkeley.EDU) Received: from localhost (localhost [127.0.0.1]) by smarter.than.nu (8.9.1/8.9.1) with ESMTP id MAA13948; Tue, 12 Jan 1999 12:30:14 -0800 (PST) (envelope-from brian@CSUA.Berkeley.EDU) Date: Tue, 12 Jan 1999 12:30:14 -0800 (PST) From: "Brian W. Buchanan" X-Sender: brian@smarter.than.nu To: "Jan B. Koum " cc: Patrick Barmentlo , security@FreeBSD.ORG Subject: Re: examples rules ipfw In-Reply-To: <19990112042358.C303@best.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, 12 Jan 1999, Jan B. Koum wrote: > [redirect from -hackers to -security] > > On Mon, Jan 11, 1999 at 02:56:44PM -0800, "Brian W. Buchanan" wrote: > > On Mon, 11 Jan 1999, Patrick Barmentlo wrote: > > > > > Can someone please point me out to some good examples for the rc.firewall > > > file (ipfw )?? > > > (with most variant of opties/features...) > > > > > > i have to set up some filtering, but still having some difficulties with > > > it after checking freebsd.org.... > > > > > > add 00501 allow tcp from any to smarter 1024-65535 > > > > This allows all traffic to ports 1024 through 65535 (to let FTP work > > correctly) > > > This is not good! There are way MANY evil things running on ports > greater then 1024. Take X windows (6000), take nfsd (2049). Most of > the insecure solaris rpc crap runs in that range. This list could > go on forever. Well, I have nfsd listening for UDP only, and that's firewalled off earlier; I selectively unfirewall hosts for NFS as a specific need arises. I don't actually have anything running in the 1024+ port range except X11, and you're right, I should firewall that, but otherwise this doesn't introduce any security vulnerabilities into my particular system. For a network firewall, though, that is dangerous, and I agree that passive FTP is the way to go. -- 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 Wed Jan 13 00:56:09 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA05645 for freebsd-security-outgoing; Wed, 13 Jan 1999 00:56:09 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from smtp01.wxs.nl (smtp01.wxs.nl [195.121.6.61]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA05627 for ; Wed, 13 Jan 1999 00:56:07 -0800 (PST) (envelope-from asmodai@wxs.nl) Received: from daemon.ninth-circle.org ([195.121.56.43]) by smtp01.wxs.nl (Netscape Messaging Server 3.6) with ESMTP id AAA2592 for ; Wed, 13 Jan 1999 09:55:29 +0100 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Date: Wed, 13 Jan 1999 10:02:59 +0100 (CET) Organization: Ninth Circle Enterprises From: Jeroen Ruigrok/Asmodai To: FreeBSD Security Subject: GIDs for new default system `users' Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi guys, I have a question/remark I am very well concerned with... In the latest CURRENT /usr/src/etc/master.passwd there exist two new users, mainly tty-sandbox and kmem-sandbox. These users are given the GID of nogroup(65533). I recently had a whole discussion about user and group id's with our local Unix guru and what he told me made perfect sense to me. What he said was basically that every user or group can never be nobody or no-one since they have an entry in the group or master.passwd file. He also told me that alot of people make something like Squid and Apache members of nogroup/nobody because these aren't accounts. IMHO that's completely wrong since they belong to a group and can thus always be compromised and if alot of programs are members of one group that means a lot of potential holes. Is there something specific about nogroup btw, that it has this explicit name? If not, if it's bascially the same as nobody, then I am all in favor of moving those tty-sandbox and kmem-sandbox to their own group id's for the sake of security... Comments? --- Jeroen Ruigrok van der Werven A veil of smoke is what I am, asmodai(at)wxs.nl I wait and I wait... Network/Security Specialist BSD & picoBSD: The Power to Serve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jan 13 11:05:12 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA02022 for freebsd-security-outgoing; Wed, 13 Jan 1999 11:05:12 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from brooklyn.slack.net (brooklyn.slack.net [206.41.21.102]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA01916 for ; Wed, 13 Jan 1999 11:04:52 -0800 (PST) (envelope-from andrewr@brooklyn.slack.net) Received: from localhost (andrewr@localhost) by brooklyn.slack.net (8.8.7/8.8.7) with SMTP id IAA09729; Wed, 13 Jan 1999 08:54:06 -0500 (EST) Date: Wed, 13 Jan 1999 08:54:06 -0500 (EST) From: andrewr To: Jeroen Ruigrok/Asmodai cc: FreeBSD Security Subject: Re: GIDs for new default system `users' In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 13 Jan 1999, Jeroen Ruigrok/Asmodai wrote: > Hi guys, > > I have a question/remark I am very well concerned with... > > Is there something specific about nogroup btw, that it has this explicit > name? If not, if it's bascially the same as nobody, then I am all in favor > of moving those tty-sandbox and kmem-sandbox to their own group id's for > the sake of security... IMHO, just like qmail, any important service that is running on a machine, should have their own gid. I agree with you on this completely.. however it does seem kind of crazy to just go out and be throwing gid's around to everyone and every thing. -Andrew > > Comments? > > --- > Jeroen Ruigrok van der Werven A veil of smoke is what I am, > asmodai(at)wxs.nl I wait and I wait... > Network/Security Specialist > BSD & picoBSD: The Power to Serve > > 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 Jan 13 11:17:21 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA05514 for freebsd-security-outgoing; Wed, 13 Jan 1999 11:17:21 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from hotmail.com (f63.hotmail.com [207.82.251.197]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id LAA05463 for ; Wed, 13 Jan 1999 11:17:05 -0800 (PST) (envelope-from madrapour@hotmail.com) Received: (qmail 11081 invoked by uid 0); 13 Jan 1999 13:49:16 -0000 Message-ID: <19990113134916.11078.qmail@hotmail.com> Received: from 208.218.169.84 by www.hotmail.com with HTTP; Wed, 13 Jan 1999 05:49:14 PST X-Originating-IP: [208.218.169.84] From: "N. N.M" To: freebsd-security@FreeBSD.ORG Subject: Re [2]: Quick ipfw question Date: Wed, 13 Jan 1999 05:49:14 PST Mime-Version: 1.0 Content-Type: text/plain Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I think mine is rather old. It is run on Freebsd 2.2.6! Nazila >Date: Tue, 12 Jan 1999 11:13:14 -0800 (PST) >From: Brook Miles >To: "N. N.M" >cc: freebsd-security@FreeBSD.ORG >Subject: Re: Quick ipfw question > >On Tue, 12 Jan 1999, N. N.M wrote: > >Well..the first example command line in my man page reads: > > ipfw [-q] file > >And so I rather expected it to work. >But from the other responses it appears this is only a temporary bug, so I >guess I'll just put up with it untill I get around to updating. > >Thanks for the help all, >Brook > >> The reason is simple: as the manual mentions, the argument "-q" is valid >> only with the following commands: >> >> - flush >> - zero no. >> - add ...... >> >> As you see, if you wanna use a file as ipfw's argument, you can't use >> "-q". Alternatively, you can use -q in each line (or each ipfw commands) >> in your file (/myfile). So the rules in this file are added "quietly". >> >> Nazila N. >> >> >> >Date: Tue, 12 Jan 1999 00:21:05 -0800 (PST) >> >From: Brook Miles >> >To: freebsd-security@FreeBSD.ORG >> >Subject: Quick ipfw question >> > >> > >> >Is there some reason that >> > ipfw /my/file >> >works but >> > ipfw -q /my/file >> >doesn't? >> > >> >It gives "ipfw: error: Bad Arguments" >> > >> >FreeBSD/i386 3.0-RELEASE > >+--- >| Brook Miles >| A spec of cosmic dust... with attitude. >+-------------------------------------- > ______________________________________________________ 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 Jan 13 11:28:30 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA04131 for freebsd-security-outgoing; Wed, 13 Jan 1999 05:40:58 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from fledge.watson.org (FLEDGE.RES.CMU.EDU [128.2.93.229]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA03982 for ; Wed, 13 Jan 1999 05:39:48 -0800 (PST) (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 IAA28176; Wed, 13 Jan 1999 08:38:56 -0500 (EST) Date: Wed, 13 Jan 1999 08:38:56 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Jeroen Ruigrok/Asmodai cc: FreeBSD Security Subject: Re: GIDs for new default system `users' 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 In my view, the kmem sandbox does not prevent a bug in a kmem utility from gaining root access. Kmem allows access to kernel memory, and kernel memory buffers are used to transfer sensitive date (such as keyboard input) meaning kmem access could be used to retrieve passwords, cryptographic material, etc, destined to and from other processes without authorization. As such, kmem would almost always imply root access eventually and with appropriate monitoring of kernel memory space. Kmem utilities should really be using /proc, sysctl, or some other carefully designed mechanism to mediate access to kernel data structures, not the general purpose file system interface of /dev/kmem, which should probably eventually go away in any securelevel, as it constites a violation of seperation of kernel and root privileges. Like a lot of other pseudo-security features involving uids, kmem gives you a false sense of comfort :). On the other hand, the bind sandbox sounds useful, as it reduces the need for a long-running uid 0 process that could have bugs in its large associated program (bind). Only small portions of bind actually require privileges operation (to bind the domain port for incoming and outgoing connections), so giving up those privileges and executing as the bind-sandbox user reduces the scope of attacks based on security wholes elsewhere in the bind source code. Some operating systems make a distinction between the nobody/nogroup users and other users, but I believe that FreeBSD does not. For example, I believe that some operating systems do not allow nobody to own files in the file system (I don't recall which); this is clearly not the case under FreeBSD/apache as CGI scripts can modify/create files if directory permissions are set appropriately. Running apache as nobody may be a mistake if someone believes this places it in a unique sandbox--at least one program (fingerd) is run by inetd as the nobody uid, meaning that a bug in fingerd could allow interference with web server execution, etc. More likely, of course, the web server contains a bug, as it is significantly more complex a program. nobody is nobody by virtue of not a) being associated with any files, and b) being used by applications that may not have authenticated their users (anonymous ftp uses the ftp account instead though :). It might be better, given that nobody ends up being the uid for CGI, if we formally introduced a 'www' user and used that instead (or apache-sandbox or something). Clearly, there is a difference between AFS's or Coda's concept of System:Anyuser and nobody: System:Anyuser is unauthenticated by definition; nobody is unauthenticated by convention, and it's not clear how well-followed the convention is. (this is my belief anyway, people should feel free to correct me :) On Wed, 13 Jan 1999, Jeroen Ruigrok/Asmodai wrote: > Hi guys, > > I have a question/remark I am very well concerned with... > > In the latest CURRENT /usr/src/etc/master.passwd there exist two new > users, mainly tty-sandbox and kmem-sandbox. These users are given the GID > of nogroup(65533). > > I recently had a whole discussion about user and group id's with our local > Unix guru and what he told me made perfect sense to me. What he said was > basically that every user or group can never be nobody or no-one since they > have an entry in the group or master.passwd file. He also told me that alot > of people make something like Squid and Apache members of nogroup/nobody > because these aren't accounts. IMHO that's completely wrong since they > belong to a group and can thus always be compromised and if alot of > programs are members of one group that means a lot of potential holes. > > Is there something specific about nogroup btw, that it has this explicit > name? If not, if it's bascially the same as nobody, then I am all in favor > of moving those tty-sandbox and kmem-sandbox to their own group id's for > the sake of security... > > Comments? > > --- > Jeroen Ruigrok van der Werven A veil of smoke is what I am, > asmodai(at)wxs.nl I wait and I wait... > Network/Security Specialist > BSD & picoBSD: The Power to Serve > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > Robert N Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C 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 Wed Jan 13 12:00:49 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA17021 for freebsd-security-outgoing; Wed, 13 Jan 1999 12:00:49 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from smtp01.wxs.nl (smtp01.wxs.nl [195.121.6.61]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA16990 for ; Wed, 13 Jan 1999 12:00:38 -0800 (PST) (envelope-from asmodai@wxs.nl) Received: from daemon.ninth-circle.org ([195.121.56.150]) by smtp01.wxs.nl (Netscape Messaging Server 3.6) with ESMTP id AAA9DB; Wed, 13 Jan 1999 19:30:44 +0100 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Wed, 13 Jan 1999 19:38:27 +0100 (CET) Organization: Ninth Circle Enterprises From: Jeroen Ruigrok/Asmodai To: andrewr Subject: Re: GIDs for new default system `users' Cc: FreeBSD Security Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 13-Jan-99 andrewr wrote: > > > On Wed, 13 Jan 1999, Jeroen Ruigrok/Asmodai wrote: > >> Hi guys, >> >> I have a question/remark I am very well concerned with... >> >> Is there something specific about nogroup btw, that it has this explicit >> name? If not, if it's bascially the same as nobody, then I am all in >> favor of moving those tty-sandbox and kmem-sandbox to their own group >> id's for the sake of security... > > IMHO, just like qmail, any important service that is running on a machine, > should have their own gid. I agree with you on this completely.. however > it does seem kind of crazy to just go out and be throwing gid's around to > everyone and every thing. Well, I think that depends. The average system has at least 65535 gids available, of which roughly 20-30 are in use by default. That leaves us with 65500 gids free. Of these lets say about 1000 might be in use by active users and 2000 in use by inactive users. That still leaves us with 62000 gids to use... I frankly don't see the problem, in fact I see more benefits, except from a slight administration point of view it might be more problematic at start. --- Jeroen Ruigrok van der Werven A veil of smoke is what I am, asmodai(at)wxs.nl I wait and I wait... Network/Security Specialist BSD & picoBSD: The Power to Serve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 14 02:07:04 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA17030 for freebsd-security-outgoing; Thu, 14 Jan 1999 02:07:04 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from aniwa.sky (whangaroa.igrin.co.nz [202.49.245.97]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA17019 for ; Thu, 14 Jan 1999 02:06:56 -0800 (PST) (envelope-from andrew@squiz.co.nz) Received: from localhost (andrew@localhost) by aniwa.sky (8.8.8/8.8.7) with ESMTP id XAA00679; Thu, 14 Jan 1999 23:01:56 +1300 (NZDT) (envelope-from andrew@squiz.co.nz) Date: Thu, 14 Jan 1999 23:00:41 +1300 (NZDT) From: Andrew McNaughton X-Sender: andrew@aniwa.sky Reply-To: andrew@squiz.co.nz To: "Jan B. Koum " cc: "Brian W. Buchanan" , Patrick Barmentlo , security@FreeBSD.ORG Subject: Re: examples rules ipfw In-Reply-To: <19990112042358.C303@best.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, 12 Jan 1999, Jan B. Koum wrote: > > add 00501 allow tcp from any to smarter 1024-65535 > > > > This allows all traffic to ports 1024 through 65535 (to let FTP work > > correctly) > > > This is not good! There are way MANY evil things running on ports > greater then 1024. Take X windows (6000), take nfsd (2049). Most of > the insecure solaris rpc crap runs in that range. This list could > go on forever. Depending on what you are shielding of course. If you are only shielding a single host, or a small number, it may be possible to comprehensively list the ports you need to be careful of (eg netstat -a). > You would be much better off using passive ftp (ftp -p) then opening > up all those holes into your network. I connect to specific hosts which disallow passive ftp, so I don't use this approach. I'd be curious to know how common this is? Andrew McNaughton To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 14 06:38:23 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA12400 for freebsd-security-outgoing; Thu, 14 Jan 1999 06:38:23 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA12391 for ; Thu, 14 Jan 1999 06:38:19 -0800 (PST) (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 PAA14616; Thu, 14 Jan 1999 15:37:09 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id PAA88824; Thu, 14 Jan 1999 15:37:09 +0100 (MET) Date: Thu, 14 Jan 1999 15:37:09 +0100 From: Eivind Eklund To: Andrew McNaughton Cc: "Jan B. Koum " , security@FreeBSD.ORG Subject: Re: examples rules ipfw Message-ID: <19990114153709.A88792@bitbox.follo.net> References: <19990112042358.C303@best.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: ; from Andrew McNaughton on Thu, Jan 14, 1999 at 11:00:41PM +1300 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Jan 14, 1999 at 11:00:41PM +1300, Andrew McNaughton wrote: > > You would be much better off using passive ftp (ftp -p) then opening > > up all those holes into your network. > > I connect to specific hosts which disallow passive ftp, so I don't use > this approach. I'd be curious to know how common this is? If you need another secure approach, look at libalias. It contains my code for automatically creating tiny 'holes' in the firewall just allowing one specific connection through. Unfortunately, there are not any clients in FreeBSD that use that as of today, but you should be able to build it into natd and ppp fairly easily (it is only two function calls to enable it; one to set the rule number range in the firewall rules to use for creating 'holes', and one to enable the flag). I guess the code could be adapted to be usable in environments without NAT, but I haven't really looked into it. I don't really approve of using pure packet filters for a firewall. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 14 08:06:51 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA23182 for freebsd-security-outgoing; Thu, 14 Jan 1999 08:06:51 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from Thingol.KryptoKom.DE (Thingol.KryptoKom.DE [194.245.91.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA23174 for ; Thu, 14 Jan 1999 08:06:42 -0800 (PST) (envelope-from debruin@KryptoKom.DE) Received: (from mail@localhost) by Thingol.KryptoKom.DE (8.8.7/8.8.4) id RAA19910 for ; Thu, 14 Jan 1999 17:06:35 +0100 Received: from cirdan.kryptokom.de by via smtpp (Version 1.1.1beta6) id kwa19908; Thu Jan 14 17:06:25 1999 Received: by Cirdan.KryptoKom.DE (8.8.5/8.8.5) with ESMTP id QAA15408 for ; Thu, 14 Jan 1999 16:56:47 +0100 Original: Received: from kryptokom.de (localhost [127.0.0.1]) by borg.kryptokom.de (8.8.8/8.8.8) with ESMTP id RAA18996 for ; Thu, 14 Jan 1999 17:18:43 +0100 (CET) (envelope-from eT@kryptokom.de) Message-ID: <369E18DF.1C690E4B@kryptokom.de> Date: Thu, 14 Jan 1999 17:18:39 +0100 From: eT Organization: KryptoKom GmbH X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-19980804-SNAP i386) X-Accept-Language: en MIME-Version: 1.0 To: security@FreeBSD.ORG Subject: IPSEC Implementations Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Greets... IPSEC is on my mind. Do you guys know which implementations of IPSEC exist? I know about SSH and KAME. I also wonder which of the two implementations will be beter or most 'standard'. I know that SSH is commercial and KAME free (for now) but the preliminary tests I did on KAME was quite dissapointing as far as throughput speed is concerned. But i'm sure it will improve. anyways... let's discuss? eT -- Etienne de Bruin; eT@kryptokom.de; edebruin@iname.com "i am in your hands under your command like a puppet on a string" - dc talk, consume me. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 14 08:55:15 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA28482 for freebsd-security-outgoing; Thu, 14 Jan 1999 08:55:15 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from kamna.i.cz (kamna.i.cz [193.85.255.30]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id IAA28477 for ; Thu, 14 Jan 1999 08:55:12 -0800 (PST) (envelope-from mm@i.cz) Received: (qmail 11618 invoked from network); 14 Jan 1999 16:54:02 -0000 Received: from woody.i.cz (@193.85.255.60) by kamna.i.cz with SMTP; 14 Jan 1999 16:54:02 -0000 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <19990114153709.A88792@bitbox.follo.net> Date: Thu, 14 Jan 1999 17:54:01 +0100 (MET) Reply-To: mm@i.cz From: Martin Machacek To: security@FreeBSD.ORG Subject: Re: examples rules ipfw Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 14-Jan-99 Eivind Eklund wrote: > On Thu, Jan 14, 1999 at 11:00:41PM +1300, Andrew McNaughton wrote: > If you need another secure approach, look at libalias. > > It contains my code for automatically creating tiny 'holes' in the > firewall just allowing one specific connection through. > > Unfortunately, there are not any clients in FreeBSD that use that as > of today, but you should be able to build it into natd and ppp fairly > easily (it is only two function calls to enable it; one to set the > rule number range in the firewall rules to use for creating 'holes', > and one to enable the flag). > > I guess the code could be adapted to be usable in environments without > NAT, but I haven't really looked into it. I don't really approve of > using pure packet filters for a firewall. Do you think that this feature could be used to run rsh from net with private IP addresses (RFC 1918) over NAT "firewall" (using natd) to machine in front of the firewall with public IP address? Of course it would require natd to be modified to utilize the PUNCH_FW feature. At present it is not possible to use rsh over natd because there is no application specific processing for rsh in libalias, so it does not allow the reverse channel carrying stderr data through (at least if you have the deny_incoming feature of natd on - which I definitely want to have). I could eventualy do the necessary mod to natd/libalias (using PUNCH_FW). On the other hand I'm afraid that I don't have enough time to implement (and test) the full application specific processing for rsh in libalias. If the PUNCH_FW feature of libalias could make it easier, I may try it. I've briefly looked at it and it seems to be pretty straight forward, but I'm not sure that it could be used for this purpose. Martin --- [PGP KeyID F3F409C4]] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 14 09:50:34 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA07311 for freebsd-security-outgoing; Thu, 14 Jan 1999 09:50:34 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from hosting.doublesquare.com (hosting.doublesquare.com [195.5.128.151]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA07291 for ; Thu, 14 Jan 1999 09:50:22 -0800 (PST) (envelope-from ark@eltex.ru) From: ark@eltex.ru Received: from eltex.ru (eltex-spiiras.nw.ru [195.19.204.46] (may be forged)) by hosting.doublesquare.com (8.8.8/8.8.8) with ESMTP id UAA03310; Thu, 14 Jan 1999 20:49:08 +0300 (MSK) Received: from border.eltex.spb.ru (root@border.eltex.ru [195.19.198.2]) by eltex.ru (8.8.8/8.8.8) with SMTP id UAA19748; Thu, 14 Jan 1999 20:49:14 +0300 (MSK) Received: by border.eltex.spb.ru (ssmtp TIS-0.5alpha, 19 Oct 1998); Thu, 14 Jan 1999 20:49:00 +0300 Received: from undisclosed-intranet-sender id xma006923; Thu, 14 Jan 99 20:48:52 +0300 Date: Thu, 14 Jan 1999 20:47:44 +0300 Message-Id: <199901141747.UAA25352@paranoid.eltex.spb.ru> In-Reply-To: from "Martin Machacek " Organization: "Klingon Imperial Intelligence Service" Subject: Re: examples rules ipfw To: mm@i.cz Cc: security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org nuqneH, More than strange way to do. natd is ugly. why not to use TIS fwtk instead? Martin Machacek said : > > On 14-Jan-99 Eivind Eklund wrote: > > On Thu, Jan 14, 1999 at 11:00:41PM +1300, Andrew McNaughton wrote: > > If you need another secure approach, look at libalias. > > > > It contains my code for automatically creating tiny 'holes' in the > > firewall just allowing one specific connection through. > > > > Unfortunately, there are not any clients in FreeBSD that use that as > > of today, but you should be able to build it into natd and ppp fairly > > easily (it is only two function calls to enable it; one to set the > > rule number range in the firewall rules to use for creating 'holes', > > and one to enable the flag). > > > > I guess the code could be adapted to be usable in environments without > > NAT, but I haven't really looked into it. I don't really approve of > > using pure packet filters for a firewall. > > Do you think that this feature could be used to run rsh from net with > private IP addresses (RFC 1918) over NAT "firewall" (using natd) to machine > in front of the firewall with public IP address? Of course it would require natd > to be modified to utilize the PUNCH_FW feature. At present it is not possible to > use rsh over natd because there is no application specific processing for > rsh in libalias, so it does not allow the reverse channel carrying stderr data > through (at least if you have the deny_incoming feature of natd on - which I > definitely want to have). I could eventualy do the necessary mod > to natd/libalias (using PUNCH_FW). On the other hand I'm afraid that I don't > have enough time to implement (and test) the full application specific > processing for rsh in libalias. If the PUNCH_FW feature of libalias could make > it easier, I may try it. I've briefly looked at it and it seems to be pretty > straight forward, but I'm not sure that it could be used for this purpose. > > Martin > > --- > [PGP KeyID F3F409C4]] > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > _ _ _ _ _ _ _ {::} {::} {::} CU in Hell _| o |_ | | _|| | / _||_| |_ |_ |_ (##) (##) (##) /Arkan#iD |_ o _||_| _||_| / _| | o |_||_||_| [||] [||] [||] Do i believe in Bible? Hell,man,i've seen one! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 14 10:19:03 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA11042 for freebsd-security-outgoing; Thu, 14 Jan 1999 10:19:03 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from kamna.i.cz (kamna.i.cz [193.85.255.30]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id KAA11017 for ; Thu, 14 Jan 1999 10:18:55 -0800 (PST) (envelope-from mm@i.cz) Received: (qmail 12306 invoked from network); 14 Jan 1999 18:17:45 -0000 Received: from woody.i.cz (@193.85.255.60) by kamna.i.cz with SMTP; 14 Jan 1999 18:17:45 -0000 Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199901141747.UAA25352@paranoid.eltex.spb.ru> Date: Thu, 14 Jan 1999 19:17:45 +0100 (MET) Reply-To: mm@i.cz From: Martin Machacek To: ark@eltex.ru Subject: Re: examples rules ipfw Cc: security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 14-Jan-99 ark@eltex.ru wrote: > nuqneH, > > More than strange way to do. natd is ugly. Agreed. Maybe I should try ipfilter. Does anybody know whether NAT that comes with ipfilter handles rsh correctly. > why not to use TIS fwtk instead? Because of license. I unfortunately need it for a customer as a temporary solution until they gather enough budget to buy Gauntlet (which is not the greatest solution either). Martin --- [PGP KeyID F3F409C4]] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 14 11:13:57 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA20725 for freebsd-security-outgoing; Thu, 14 Jan 1999 11:13:57 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA20717 for ; Thu, 14 Jan 1999 11:13:53 -0800 (PST) (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 UAA19353; Thu, 14 Jan 1999 20:12:43 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA90029; Thu, 14 Jan 1999 20:12:41 +0100 (MET) Date: Thu, 14 Jan 1999 20:12:40 +0100 From: Eivind Eklund To: Martin Machacek Cc: security@FreeBSD.ORG Subject: Re: examples rules ipfw Message-ID: <19990114201240.B88792@bitbox.follo.net> References: <19990114153709.A88792@bitbox.follo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: ; from Martin Machacek on Thu, Jan 14, 1999 at 05:54:01PM +0100 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Jan 14, 1999 at 05:54:01PM +0100, Martin Machacek wrote: > > On 14-Jan-99 Eivind Eklund wrote: > > On Thu, Jan 14, 1999 at 11:00:41PM +1300, Andrew McNaughton wrote: > > If you need another secure approach, look at libalias. > > > > It contains my code for automatically creating tiny 'holes' in the > > firewall just allowing one specific connection through. > > > > Unfortunately, there are not any clients in FreeBSD that use that as > > of today, but you should be able to build it into natd and ppp fairly > > easily (it is only two function calls to enable it; one to set the > > rule number range in the firewall rules to use for creating 'holes', > > and one to enable the flag). > > > > I guess the code could be adapted to be usable in environments without > > NAT, but I haven't really looked into it. I don't really approve of > > using pure packet filters for a firewall. > > Do you think that this feature could be used to run rsh from net with > private IP addresses (RFC 1918) over NAT "firewall" (using natd) to machine > in front of the firewall with public IP address? I don't know - I've not looked at the rsh protocol at all. I didn't even know it was an active protocol (ie, used backward connections). Any reason you can't use ssh? Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 14 11:36:57 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA24635 for freebsd-security-outgoing; Thu, 14 Jan 1999 11:36:57 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from mail1.WorldMediaCo.com ([207.252.121.17]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA24617 for ; Thu, 14 Jan 1999 11:36:55 -0800 (PST) (envelope-from opsys@open-systems.net) Received: from freebsd.omaha.com ([207.252.122.237]) by mail1.WorldMediaCo.com (Post.Office MTA v3.5.3 release 223 ID# 0-55573U2500L250S0V35) with SMTP id com; Thu, 14 Jan 1999 13:30:46 -0600 Date: Thu, 14 Jan 1999 13:35:45 -0600 (CST) From: "Open Systems Inc." X-Sender: opsys@freebsd.omaha.com To: ark@eltex.ru cc: mm@i.cz, security@FreeBSD.ORG Subject: Re: examples rules ipfw In-Reply-To: <199901141747.UAA25352@paranoid.eltex.spb.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 14 Jan 1999 ark@eltex.ru wrote: > nuqneH, > > More than strange way to do. natd is ugly. why not to use TIS fwtk > instead? Ugly? Define ugly. NATD works great, and is loads easier to configure than FWTK for the average user. Chris -- "Join Team-FreeBSD on cracking RC5-64! grab you client now and HELP OUT! http://www.distributed.net/cgi/select.cgi" ===================================| Open Systems FreeBSD Consulting. FreeBSD 2.2.8 is available now! | Phone: 402-573-9124 -----------------------------------| 3335 N. 103 Plaza #14, Omaha, NE 68134 FreeBSD: The power to serve! | E-Mail: opsys@open-systems.net http://www.freebsd.org | Consulting, Network Engineering, Security ===================================| http://open-systems.net -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQENAzPemUsAAAEH/06iF0BU8pMtdLJrxp/lLk3vg9QJCHajsd25gYtR8X1Px1Te gWU0C4EwMh4seDIgK9bzFmjjlZOEgS9zEgia28xDgeluQjuuMyUFJ58MzRlC2ONC foYIZsFyIqdjEOCBdfhH5bmgB5/+L5bjDK6lNdqD8OAhtC4Xnc1UxAKq3oUgVD/Z d5UJXU2xm+f08WwGZIUcbGcaonRC/6Z/5o8YpLVBpcFeLtKW5WwGhEMxl9WDZ3Kb NZH6bx15WiB2Q/gZQib3ZXhe1xEgRP+p6BnvF364I/To9kMduHpJKU97PH3dU7Mv CXk2NG3rtOgLTEwLyvtBPqLnbx35E0JnZc0k5YkABRO0JU9wZW4gU3lzdGVtcyA8 b3BzeXNAb3Blbi1zeXN0ZW1zLm5ldD4= =BBjp -----END PGP PUBLIC KEY BLOCK----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 15 03:53:46 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA28505 for freebsd-security-outgoing; Fri, 15 Jan 1999 03:53:46 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from hosting.doublesquare.com (hosting.doublesquare.com [195.5.128.151]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA28497 for ; Fri, 15 Jan 1999 03:53:36 -0800 (PST) (envelope-from ark@eltex.ru) From: ark@eltex.ru Received: from eltex.ru (eltex-spiiras.nw.ru [195.19.204.46] (may be forged)) by hosting.doublesquare.com (8.8.8/8.8.8) with ESMTP id OAA01659; Fri, 15 Jan 1999 14:50:15 +0300 (MSK) Received: from border.eltex.spb.ru (root@border.eltex.ru [195.19.198.2]) by eltex.ru (8.8.8/8.8.8) with SMTP id OAA22946; Fri, 15 Jan 1999 14:50:08 +0300 (MSK) Received: by border.eltex.spb.ru (ssmtp TIS-0.5alpha, 19 Oct 1998); Fri, 15 Jan 1999 14:49:53 +0300 Received: from undisclosed-intranet-sender id xma007704; Fri, 15 Jan 99 14:49:43 +0300 Date: Fri, 15 Jan 1999 14:48:34 +0300 Message-Id: <199901151148.OAA28702@paranoid.eltex.spb.ru> In-Reply-To: from ""Open Systems Inc." " Organization: "Klingon Imperial Intelligence Service" Subject: Re: examples rules ipfw To: opsys@open-systems.net Cc: ark@eltex.ru, mm@i.cz, security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org -----BEGIN PGP SIGNED MESSAGE----- nuqneH, Look at the code. See the way it works. Take a look at ipfilter, after all. Can you tell that again? fwtk. fwtk is application level thingie. it is easier to configure, more flexible and provides better functionality. "Open Systems Inc." said : > On Thu, 14 Jan 1999 ark@eltex.ru wrote: > > > nuqneH, > > > > More than strange way to do. natd is ugly. why not to use TIS fwtk > > instead? > > Ugly? Define ugly. NATD works great, and is loads easier to configure than > FWTK for the average user. > > Chris > _ _ _ _ _ _ _ {::} {::} {::} CU in Hell _| o |_ | | _|| | / _||_| |_ |_ |_ (##) (##) (##) /Arkan#iD |_ o _||_| _||_| / _| | o |_||_||_| [||] [||] [||] Do i believe in Bible? Hell,man,i've seen one! -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBNp8rEKH/mIJW9LeBAQHmVAP/Su/8dev/H91VthYBA4nIGEZdLFDwjaC+ B9qpzDRdNWgEjQTgQ3ka0xvVwy4wsmNf3TqHF3+TAKNqztN2DygK9N+NBM+ZrhPm z8f1hGW4SyyfZXCdsEbgYCw4KV4Ud2OBVm12tUAZGVL1TgwI7YfUNyfJ0toQTAo/ +dkIc0jfwTk= =DFe7 -----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 Fri Jan 15 04:04:44 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA00176 for freebsd-security-outgoing; Fri, 15 Jan 1999 04:04:44 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from hosting.doublesquare.com (hosting.doublesquare.com [195.5.128.151]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA00155 for ; Fri, 15 Jan 1999 04:04:40 -0800 (PST) (envelope-from ark@eltex.ru) From: ark@eltex.ru Received: from eltex.ru (eltex-spiiras.nw.ru [195.19.204.46] (may be forged)) by hosting.doublesquare.com (8.8.8/8.8.8) with ESMTP id PAA01768; Fri, 15 Jan 1999 15:03:27 +0300 (MSK) Received: from border.eltex.spb.ru (root@border.eltex.ru [195.19.198.2]) by eltex.ru (8.8.8/8.8.8) with SMTP id PAA23052; Fri, 15 Jan 1999 15:03:27 +0300 (MSK) Received: by border.eltex.spb.ru (ssmtp TIS-0.5alpha, 19 Oct 1998); Fri, 15 Jan 1999 15:03:14 +0300 Received: from undisclosed-intranet-sender id xma007720; Fri, 15 Jan 99 15:03:08 +0300 Date: Fri, 15 Jan 1999 15:02:00 +0300 Message-Id: <199901151202.PAA28751@paranoid.eltex.spb.ru> In-Reply-To: from "Martin Machacek " Organization: "Klingon Imperial Intelligence Service" Subject: Re: examples rules ipfw To: mm@i.cz Cc: ark@eltex.ru, security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org -----BEGIN PGP SIGNED MESSAGE----- nuqneH, Martin Machacek said : > > More than strange way to do. natd is ugly. > > Agreed. Maybe I should try ipfilter. Does anybody know whether NAT that comes > with ipfilter handles rsh correctly. Not for now. But - there is an API that is defenitely better than natd's. So it could be done.. > > > why not to use TIS fwtk instead? > > Because of license. Things could change, TIS definitely did not like that, NAI can have different view on those things - have you try to ask them about "temporary commercial license" or something alike..? There are more funny details about that. See your mail. > I unfortunately need it for a customer as a temporary > solution until they gather enough budget to buy Gauntlet (which is not the > greatest solution either). Gauntlet is the best firewall on the market i've seen. Sometimes too expensive, although. _ _ _ _ _ _ _ {::} {::} {::} CU in Hell _| o |_ | | _|| | / _||_| |_ |_ |_ (##) (##) (##) /Arkan#iD |_ o _||_| _||_| / _| | o |_||_||_| [||] [||] [||] Do i believe in Bible? Hell,man,i've seen one! -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBNp8uN6H/mIJW9LeBAQFzmgP/a744UnchXLBKJytBa8Doizx+bKCYa2TG WNPFWH+qH3sHreWtzYKO425299+mTbWZIYMG3aNP1VqtBZVAouIx+aYr2dbP+dHn PzV+DDZXTED8aK4LCdjaM64RdoHkQR0IzAdeNPlzcNCm+xJuiHmH+o2MHm3TNfs6 22sdi2eaBkQ= =aMRq -----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 Fri Jan 15 05:09:19 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA11704 for freebsd-security-outgoing; Fri, 15 Jan 1999 05:09:19 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from mail.euroweb.hu (mail.euroweb.hu [193.226.220.4]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA11696 for ; Fri, 15 Jan 1999 05:09:08 -0800 (PST) (envelope-from hu006co@mail.euroweb.hu) Received: (from hu006co@localhost) by mail.euroweb.hu (8.8.5/8.8.5) id OAA22524 for freebsd-security@freebsd.org; Fri, 15 Jan 1999 14:07:49 +0100 (MET) Received: (from zgabor@localhost) by CoDe.hu (8.8.8/8.8.8) id NAA00746 for freebsd-security@freebsd.org; Fri, 15 Jan 1999 13:54:56 +0100 (CET) (envelope-from zgabor) From: Zahemszky Gabor Message-Id: <199901151254.NAA00746@CoDe.hu> Subject: Secuity hole with perl (suidperl) and nosuid mounts on Linux (fwd) To: freebsd-security@FreeBSD.ORG Date: Fri, 15 Jan 1999 13:54:56 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I've got it today from bugtraq. Most of it is documented on my 2.2.7's mount(8) manpage, but ... Bye, Gabor ZGabor at CoDe dot HU ----- Forwarded message from Brian McCauley ----- >From owner-bugtraq@NETSPACE.ORG Fri Jan 15 12:36:03 1999 Approved-By: aleph1@UNDERGROUND.ORG Refernences: X-Newsreader: Gnus v5.5/Emacs 20.2 Lines: 34 Posted-To: comp.os.linux.misc,comp.os.linux.development.system,comp.lang.perl.misc Message-ID: Date: Thu, 14 Jan 1999 17:58:15 +0000 Reply-To: Brian McCauley Sender: Bugtraq List From: Brian McCauley Organization: University of Birmingham Subject: Secuity hole with perl (suidperl) and nosuid mounts on Linux X-To: perlbug@perl.com, security-audit@ferret.lmh.ox.ac.uk, submission@rootshell.com To: BUGTRAQ@NETSPACE.ORG The following message is a courtesy copy of an article that has been posted to comp.os.linux.misc,comp.os.linux.development.system,comp.lang.perl.misc as well. The suid script emulation in Perl 5.0004_4 (as found in SuSE Linux 5.3 and doubtless other Linux distributions) fails to take account of the nosuid mount option on filesystems. This means that it is trivial for a resourceful user to hide a setuid perl script on a CD or floppy and then use it to become root. Many systems are (even by default) configured to allow users mount floppys and CDs nosuid. The most obvious fix to Perl for this would be (where available) to use fstatvfs() (as defined in SUSv2) to determine if the script is on a filesystem that is mounted with the nosuid option. Unfortunately fstatvfs() is not implemented in Linux (as of 2.2pre1). It would not be difficult to add the new system call. Indeed the existing fstatfs() implementation could simply be modified to implement fstatvfs() semantics and both syscalls could then point to the same code. This vulerability will exist in all Unicies that use a user-space implementation of suid-scripts and impelment a nosuid mount option in such a way that it does not modify the values returned by fstat(). It is worth noting that that other suid-aware script-interpreters will probalby also display this vulnerability on Linux because of the absense of fstatvfs(). -- \\ ( ) No male bovine | Email: B.A.McCauley@bham.ac.uk . _\\__[oo faeces from | Phones: +44 121 471 3789 (home) .__/ \\ /\@ /~) /~[ /\/[ | +44 121 627 2173 (voice) 2175 (fax) . l___\\ /~~) /~~[ / [ | PGP-fp: D7 03 2A 4B D8 3A 05 37... # ll l\\ ~~~~ ~ ~ ~ ~ | http://www.wcl.bham.ac.uk/~bam/ ###LL LL\\ (Brian McCauley) | ----- End of forwarded message from Brian McCauley ----- -- #!/bin/ksh Z='21N16I25C25E30, 40M30E33E25T15U!' ;IFS=' ABCDEFGHIJKLMNOPQRSTUVWXYZ ';set $Z ;for i { [[ $i = ? ]]&&print $i&&break;[[ $i = ??? ]]&&j=$i&&i=${i%?};typeset -i40 i=8#$i;print -n ${i#???};[[ "$j" = ??? ]]&&print -n "${j#??} "&&j=;typeset +i i;};IFS=' 0123456789 ';set $Z;X=;for i { [[ $i = , ]]&&i=2;[[ $i = ?? ]]||typeset -l i;X="$X $i";typeset +l i;};print "$X" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 15 05:50:38 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA16058 for freebsd-security-outgoing; Fri, 15 Jan 1999 05:50:38 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from shell6.ba.best.com (shell6.ba.best.com [206.184.139.137]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA16051 for ; Fri, 15 Jan 1999 05:50:37 -0800 (PST) (envelope-from jkb@shell6.ba.best.com) Received: (from jkb@localhost) by shell6.ba.best.com (8.9.2/8.9.2/best.sh) id FAA04106; Fri, 15 Jan 1999 05:48:38 -0800 (PST) Message-ID: <19990115054837.A2069@best.com> Date: Fri, 15 Jan 1999 05:48:37 -0800 From: "Jan B. Koum " To: Zahemszky Gabor , freebsd-security@FreeBSD.ORG Subject: Re: Secuity hole with perl (suidperl) and nosuid mounts on Linux (fwd) References: <199901151254.NAA00746@CoDe.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199901151254.NAA00746@CoDe.hu>; from Zahemszky Gabor on Fri, Jan 15, 1999 at 01:54:56PM +0100 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Jan 15, 1999 at 01:54:56PM +0100, Zahemszky Gabor wrote: > I've got it today from bugtraq. Most of it is documented on my 2.2.7's > mount(8) manpage, but ... > > Bye, Gabor > > ZGabor at CoDe dot HU > > ----- Forwarded message from Brian McCauley ----- > I already sent an eMail to the author and bugtraq which just said that this is documented in FreeBSD man page is not at all new. -- Yan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 15 06:16:42 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA19565 for freebsd-security-outgoing; Fri, 15 Jan 1999 06:16:42 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA19560 for ; Fri, 15 Jan 1999 06:16:35 -0800 (PST) (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 PAA20476; Fri, 15 Jan 1999 15:15:17 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id PAA03800; Fri, 15 Jan 1999 15:15:15 +0100 (MET) Date: Fri, 15 Jan 1999 15:15:15 +0100 From: Eivind Eklund To: ark@eltex.ru Cc: opsys@open-systems.net, mm@i.cz, security@FreeBSD.ORG Subject: Re: examples rules ipfw Message-ID: <19990115151514.A3694@bitbox.follo.net> References: <199901151148.OAA28702@paranoid.eltex.spb.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <199901151148.OAA28702@paranoid.eltex.spb.ru>; from ark@eltex.ru on Fri, Jan 15, 1999 at 02:48:34PM +0300 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Jan 15, 1999 at 02:48:34PM +0300, ark@eltex.ru wrote: > Look at the code. See the way it works. Take a look at ipfilter, > after all. Can you tell that again? The code in libalias was written as a pragmatic solution for a specific need. The proxies here just check for some items at the beginning of packets, instead of parsing the entire stream, and this is a disgusting hack - but it gives a pretty large speed advantage, and I've _never_ seen or heard of these breaking down. Given that my e-mail address is listed in all the man-pages, I hope I would get some e-mail if it didn't work :-) There are of course a lot of things I'd like to do with libalias, and making the proxies conformant is one of these - but this will require both re-writing of most of the proxies, and significant changes to the libalias API, and it isn't really something that is high on my priority-list. Eivind. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 15 11:54:30 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA02862 for freebsd-security-outgoing; Fri, 15 Jan 1999 11:54:30 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from hotmail.com (hm1.hotmail.com [207.82.250.80]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id LAA02857 for ; Fri, 15 Jan 1999 11:54:29 -0800 (PST) (envelope-from kerMIT1994@hotmail.com) Received: (qmail 19788 invoked from network); 15 Jan 1999 19:54:24 -0000 Received: from nic-c52s01-l045.spidernet.net (HELO yiango) (194.154.136.113) by hm1.hotmail.com with SMTP; 15 Jan 1999 19:54:24 -0000 Message-Id: <3.0.6.32.19990115215626.007996e0@pop.hotmail.cwebmail.com> X-Sender: kerMIT1994@pop.hotmail.cwebmail.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Fri, 15 Jan 1999 21:56:26 +0200 To: security@FreeBSD.ORG From: KerMIT Subject: poppassd and wwwpass? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello guys, Can someone please make me feel safer by assuring to me how safe the use of 'wwwpass' script and poppasswd is on our systems? Are there any known security bugs? They seem to be available at: http://www.westnet.com/providers/ - kerMIT To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 15 12:31:54 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA06976 for freebsd-security-outgoing; Fri, 15 Jan 1999 12:31:54 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA06962 for ; Fri, 15 Jan 1999 12:31:47 -0800 (PST) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.9.1/frmug-2.3/nospam) with UUCP id VAA13923 for freebsd-security@FreeBSD.ORG; Fri, 15 Jan 1999 21:31:26 +0100 (CET) (envelope-from roberto@keltia.freenix.fr) Received: by keltia.freenix.fr (Postfix, from userid 101) id A859F1573; Fri, 15 Jan 1999 20:37:31 +0100 (CET) Date: Fri, 15 Jan 1999 20:37:31 +0100 From: Ollivier Robert To: freebsd-security@FreeBSD.ORG Subject: Re: Secuity hole with perl (suidperl) and nosuid mounts on Linux (fwd) Message-ID: <19990115203731.A13815@keltia.freenix.fr> Mail-Followup-To: freebsd-security@FreeBSD.ORG References: <199901151254.NAA00746@CoDe.hu> <19990115054837.A2069@best.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <19990115054837.A2069@best.com>; from Jan B. Koum on Fri, Jan 15, 1999 at 05:48:37AM -0800 X-Operating-System: FreeBSD 3.0-CURRENT/ELF ctm#4931 AMD-K6 MMX @ 200 MHz Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org According to Jan B. Koum : > I already sent an eMail to the author and bugtraq which just said > that this is documented in FreeBSD man page is not at all new. Before 5.004_04 was due, I submitted a patch to perl5-porters, unfortunately 1. it was too late for release and 2. it was too FreeBSD specific. There was talk to expand the patch for other OSes but it got lost somehow on the list. The patch is in perl5's ports in /usr/ports/lang/perl5 anyway and in contrib/perl5. See /usr/ports/lang/perl5/patches/patch-ad. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #67: Tue Dec 29 20:24:02 CET 1998 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 15 13:37:08 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA17338 for freebsd-security-outgoing; Fri, 15 Jan 1999 13:37:08 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from thumper.tmisnet.com (thumper.tmisnet.com [209.218.174.7]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA17332 for ; Fri, 15 Jan 1999 13:37:03 -0800 (PST) (envelope-from gryphon@tmisnet.com) Received: (from gryphon@localhost) by thumper.tmisnet.com (8.9.0.Beta5/8.9.0.Beta5) id NAA00223; Fri, 15 Jan 1999 13:37:02 -0800 (PST) Date: Fri, 15 Jan 1999 13:37:02 -0800 (PST) From: Coranth Gryphon Message-Id: <199901152137.NAA00223@thumper.tmisnet.com> To: freebsd-security@FreeBSD.ORG, roberto@keltia.freenix.fr Subject: Re: Secuity hole with perl (suidperl) and nosuid mounts on Linux (fwd) Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ollivier Robert said: > The patch is in perl5's ports in /usr/ports/lang/perl5 anyway and Does the perl5.005.02 package (as distributed on the CD) also include the patch? Actually, in general, is is safe to assume that all packages are built from the /usr/ports tree and thus include the same patches? -coranth To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 15 14:51:31 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA27404 for freebsd-security-outgoing; Fri, 15 Jan 1999 14:51:31 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA27333 for ; Fri, 15 Jan 1999 14:51:14 -0800 (PST) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.9.1/frmug-2.3/nospam) with UUCP id XAA19836 for freebsd-security@FreeBSD.ORG; Fri, 15 Jan 1999 23:51:02 +0100 (CET) (envelope-from roberto@keltia.freenix.fr) Received: by keltia.freenix.fr (Postfix, from userid 101) id 7CA511573; Fri, 15 Jan 1999 23:35:42 +0100 (CET) Date: Fri, 15 Jan 1999 23:35:42 +0100 From: Ollivier Robert To: freebsd-security@FreeBSD.ORG Subject: Re: Secuity hole with perl (suidperl) and nosuid mounts on Linux (fwd) Message-ID: <19990115233542.C40255@keltia.freenix.fr> Mail-Followup-To: freebsd-security@FreeBSD.ORG References: <199901152137.NAA00223@thumper.tmisnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <199901152137.NAA00223@thumper.tmisnet.com>; from Coranth Gryphon on Fri, Jan 15, 1999 at 01:37:02PM -0800 X-Operating-System: FreeBSD 3.0-CURRENT/ELF ctm#4931 AMD-K6 MMX @ 200 MHz Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org According to Coranth Gryphon: > Does the perl5.005.02 package (as distributed on the CD) also include > the patch? Actually, in general, is is safe to assume that all packages > are built from the /usr/ports tree and thus include the same patches? I think so, it was committed after 2.2.7. RCS file: /spare/FreeBSD-current/ports/lang/perl5/patches/patch-ad,v Working file: patches/patch-ad head: 1.4 branch: locks: strict access list: symbolic names: RELEASE_2_2_8: 1.4 RELEASE_3_0_0: 1.4 RELEASE_2_2_7: 1.3 RELEASE_2_2_6: 1.3 RELEASE_2_2_5: 1.3 RELEASE_2_2_1: 1.2 RELEASE_2_2_2: 1.2 keyword substitution: kv total revisions: 4; selected revisions: 4 description: ---------------------------- revision 1.4 date: 1998/08/06 10:43:21; author: markm; state: Exp; lines: +17 -17 Update to Perl 5.005_01. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #67: Tue Dec 29 20:24:02 CET 1998 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 15 21:18:44 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA04606 for freebsd-security-outgoing; Fri, 15 Jan 1999 21:18:44 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from cheops.anu.edu.au (cheops.anu.edu.au [150.203.149.24]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA04601 for ; Fri, 15 Jan 1999 21:18:40 -0800 (PST) (envelope-from avalon@cheops.anu.edu.au) Received: (from avalon@localhost) by cheops.anu.edu.au (8.9.1/8.9.1) id QAA02945; Sat, 16 Jan 1999 16:18:03 +1100 (EDT) From: Darren Reed Message-Id: <199901160518.QAA02945@cheops.anu.edu.au> Subject: Re: examples rules ipfw To: mm@i.cz Date: Sat, 16 Jan 1999 16:18:03 +1100 (EDT) Cc: ark@eltex.ru, security@FreeBSD.ORG In-Reply-To: from "Martin Machacek" at Jan 14, 99 07:17:45 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 Martin Machacek, sie said: > > > On 14-Jan-99 ark@eltex.ru wrote: > > nuqneH, > > > > More than strange way to do. natd is ugly. > > Agreed. Maybe I should try ipfilter. Does anybody know whether NAT that comes > with ipfilter handles rsh correctly. The latest beta (3.2.11beta2) has a proxy for rcmd (i.e. rsh) in it. I've not tested it a lot, yet. ftp://coombs.anu.edu.au/pub/net/ip-filter/ip_fil3.2.11beta2.tgz Darren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 15 22:14:19 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA09499 for freebsd-security-outgoing; Fri, 15 Jan 1999 22:14:19 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from burka.carrier.kiev.ua (burka.carrier.kiev.ua [193.193.193.107]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA09493 for ; Fri, 15 Jan 1999 22:14:15 -0800 (PST) (envelope-from snar@lucky.net) Received: (from snar@localhost) by burka.carrier.kiev.ua (8.Who.Cares/8.Who.Cares) id IAA09731; Sat, 16 Jan 1999 08:14:12 +0200 (EET) (envelope-from snar) Message-ID: <19990116081412.D7209@lucky.net> Date: Sat, 16 Jan 1999 08:14:12 +0200 From: Alexandre Snarskii To: freebsd-security@FreeBSD.ORG Subject: libparanoia-port Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.90.11i Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi! If anyone interested in libparanoia, presented as a part of freebsd ports collection, he can look to http://www.freebsd.org/cgi/query-pr.cgi?9279 - there is submitted port, or to ftp://ftp.lexa.ru/pub/domestic/snar/paranoia-port.tar.gz - there is a tarball with port files. -- Alexander Snarskii the source code is included. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 16 19:58:29 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA28233 for freebsd-security-outgoing; Sat, 16 Jan 1999 19:58:29 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from fulcrum (fulcrum.ie.cw.net [204.70.128.22]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA28228 for ; Sat, 16 Jan 1999 19:58:27 -0800 (PST) (envelope-from yjj@cw.net) Received: from cletus.cw.net ([204.71.41.1]) by cw.net (PMDF V5.2-29 #34495) with SMTP id <0F5O0075LR11WQ@cw.net> for freebsd-security@FreeBSD.ORG; Sat, 16 Jan 1999 22:58:13 -0500 (EST) Received: by cletus.cw.net (SMI-8.6/SMI-SVR4) id WAA29400; Sat, 16 Jan 1999 22:58:13 -0500 Date: Sat, 16 Jan 1999 22:58:13 -0500 From: yjj@cw.net (Yuan John Jiang) Subject: How to do DOS checking without crashing the system? To: freebsd-security@FreeBSD.ORG Message-id: <199901170358.WAA29400@cletus.cw.net> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm think of using a vulnerability scanner, e.g. ISS, CyberCop, SATA or a homemade, to automate part of my security auditing of the boxes in service. However, how should I check for denial-of-service type of vulnerabilities, such as Land or Teardrop without crashing boxes and disrupting the service? I guess a simple thing to do is to check the OS version. However, I hope someone can suggest something more reliable. John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message