From owner-freebsd-security@FreeBSD.ORG Mon Jun 23 11:02:42 2003 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2ED9137B47B for ; Mon, 23 Jun 2003 11:02:42 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id B7DD943FF5 for ; Mon, 23 Jun 2003 11:02:41 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h5NI2fUp001799 for ; Mon, 23 Jun 2003 11:02:41 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h5NI2fgC001793 for security@freebsd.org; Mon, 23 Jun 2003 11:02:41 -0700 (PDT) Date: Mon, 23 Jun 2003 11:02:41 -0700 (PDT) Message-Id: <200306231802.h5NI2fgC001793@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: security@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2003 18:02:42 -0000 Current FreeBSD problem reports No matches to your query From owner-freebsd-security@FreeBSD.ORG Mon Jun 23 15:47:06 2003 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1D78237B401 for ; Mon, 23 Jun 2003 15:47:06 -0700 (PDT) Received: from mail.secureworks.net (mail.secureworks.net [209.101.212.155]) by mx1.FreeBSD.org (Postfix) with SMTP id 3589943FAF for ; Mon, 23 Jun 2003 15:47:05 -0700 (PDT) (envelope-from mdg@secureworks.net) Received: (qmail 34210 invoked from network); 23 Jun 2003 22:44:11 -0000 Received: from unknown (HELO HOST-192-168-17-31.internal.secureworks.net) (63.239.86.253) by mail.secureworks.net with SMTP; 23 Jun 2003 22:44:11 -0000 Date: Mon, 23 Jun 2003 18:47:04 -0400 (EDT) From: Matthew George X-X-Sender: mdg@localhost To: Michael Collette In-Reply-To: <200306201219.14573.metrol@metrol.net> Message-ID: <20030623184332.U13040@localhost> References: <200306201219.14573.metrol@metrol.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: FreeBSD Security Subject: Re: IPFW: combining "divert natd" with "keep-state" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2003 22:47:06 -0000 On Fri, 20 Jun 2003, Michael Collette wrote: > BTW, is there a way to give certain IPs permissions to reloading IPFW's > rules? > There's some stuff I'd like to be able to admin remotely. Darn box > won't let > me reload rules, but it will let me reboot. I've done this quite a bit > in > the past to force new rules to load. I was rather hoping there was a > more > elegant solution to this. > > Later on, > if you have 'flush' at the top of your ruleset, you can (sometimes) get away with an `ipfw -q`. I find screen windows (ports/misc/screen) to be most effective, though ... even if the connection dies, the screen will detach and continue processing the rules file. -- Matthew George SecureWorks Technical Operations From owner-freebsd-security@FreeBSD.ORG Mon Jun 23 18:21:13 2003 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DAB0B37B401 for ; Mon, 23 Jun 2003 18:21:13 -0700 (PDT) Received: from a2.scoop.co.nz (aurora.scoop.co.nz [203.96.152.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 781BE43FA3 for ; Mon, 23 Jun 2003 18:21:12 -0700 (PDT) (envelope-from andrew@scoop.co.nz) Received: from localhost (localhost [127.0.0.1]) by a2.scoop.co.nz (8.12.9/8.12.2) with ESMTP id h5O1L7bu021075; Tue, 24 Jun 2003 13:21:10 +1200 (NZST) (envelope-from andrew@scoop.co.nz) Date: Tue, 24 Jun 2003 13:21:07 +1200 (NZST) From: Andrew McNaughton To: Matthew George In-Reply-To: <20030623184332.U13040@localhost> Message-ID: <20030624131059.D45252@a2.scoop.co.nz> References: <200306201219.14573.metrol@metrol.net> <20030623184332.U13040@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: FreeBSD Security cc: Michael Collette Subject: Re: IPFW: combining "divert natd" with "keep-state" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2003 01:21:14 -0000 On Mon, 23 Jun 2003, Matthew George wrote: > On Fri, 20 Jun 2003, Michael Collette wrote: > > > BTW, is there a way to give certain IPs permissions to reloading > > IPFW's rules? There's some stuff I'd like to be able to admin > > remotely. Darn box won't let me reload rules, but it will let me > > reboot. I've done this quite a bit in the past to force new rules to > > load. I was rather hoping there was a more elegant solution to this. > if you have 'flush' at the top of your ruleset, you can (sometimes) get > away with an `ipfw -q`. I find screen windows (ports/misc/screen) to be > most effective, though ... even if the connection dies, the screen will > detach and continue processing the rules file. nohup sh /etc/rc.firewall CONFIG & It leaves the nohup.out file lying around which can be useful or annoying. nohup is otherwise a tidy approach to processes you don't want to be dependent on the terminal. This one with the firewall script output is a longstanding issue though. I wonder if the script could detect use of a remote tty and behave better. Maybe it could direct its output to a temp file while changing rules, then cat the output file and remove it when done changing rules. Andrew McNaughton -- No added Sugar. Not tested on animals. If irritation occurs, discontinue use. ------------------------------------------------------------------- Andrew McNaughton In Sydney Working on a Product Recommender System andrew@scoop.co.nz Mobile: +61 422 753 792 http://staff.scoop.co.nz/andrew/cv.doc From owner-freebsd-security@FreeBSD.ORG Tue Jun 24 09:56:10 2003 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9A3D037B401 for ; Tue, 24 Jun 2003 09:56:10 -0700 (PDT) Received: from highland.isltd.insignia.com (highland.isltd.insignia.com [195.74.141.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6192443F85 for ; Tue, 24 Jun 2003 09:56:09 -0700 (PDT) (envelope-from subscriber@insignia.com) Received: from dailuaine.isltd.insignia.com (dailuaine.isltd.insignia.com [172.16.64.11])h5OGu7BH072625 for ; Tue, 24 Jun 2003 17:56:07 +0100 (BST) (envelope-from subscriber@insignia.com) Received: from tomatin (tomatin [172.16.64.128])h5OGtPD0077385 for ; Tue, 24 Jun 2003 17:56:07 +0100 (BST) (envelope-from subscriber@insignia.com) From: Jim Hatfield To: freebsd-security@freebsd.org Date: Tue, 24 Jun 2003 17:55:25 +0100 Organization: Insignia Solutions Message-ID: References: <3203DF3DDE57D411AFF4009027B8C367444536@exchange-uk.isltd.insignia.com> In-Reply-To: <3203DF3DDE57D411AFF4009027B8C367444536@exchange-uk.isltd.insignia.com> X-Mailer: Forte Agent 1.91/32.564 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.33 (www . roaringpenguin . com / mimedefang) Subject: Re: IPFW: combining "divert natd" with "keep-state" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2003 16:56:11 -0000 On Wed, 11 Jun 2003 12:20:20 +0100, in local.freebsd.security you wrote: > >Attached is the conversation I had with Luigi Rizzo exactly >three years ago on this topic. Maybe it is still helpful. Well it was indeed. The use of skipto was the clue. I didn't go with any of the setups suggested but rolled my own using that idea. Here it is, in use so far for four days with no problems: >#!/bin/sh ># ># rc.firewall for NAT'ing firewall router - dynamic rules version. ># ># JPH -- 20th Jun 2003 Created. ># >fw=3D"/sbin/ipfw -q" ># ># Interface and address definitions ># >eint=3Drl0 # External interface >iint=3Dsis0 # Internal interface >inet=3D"192.168.100.0/24" # Internal net ># ># Clear existing ruleset ># >$fw flush ># ># Transparent proxy: TCP packets to port 80 forwarded to Squid proxy ># >$fw add fwd 127.0.0.1,3128 tcp from $inet to any 80 in via $iint ># ># Internal interface and loopback interface are open ># >$fw add allow ip from any to any via $iint >$fw add allow ip from any to any via lo0 ># ># Packets still being processed are traversing the external interface ># De-NAT incoming packets to get back true destination address and port ># >$fw add divert natd ip from any to any in ># ># Dynamic rules: all outgoing packets create dynamic rules which are = matched ># by both outgoing and incoming. Matching packets skip to rule 10000 ># >$fw add check-state >$fw add skipto 10000 ip from any to any out keep-state ># ># Here we handle unsolicited incoming packets. Allow selected ones in ># and block the rest. Our first reply will create a dynamic rule. ># >$fw add allow tcp from any to any 25 in setup >$fw add allow icmp from any to any in icmptype 0,3,4,11 >$fw add allow udp from any 67 to 255.255.255.255 68 in >$fw add deny log ip from any to any ># ># Packets matched by dynamic rules are tested here. ># Since they have matched a rule they can be passed. ># Outgoing packets still need to be NAT'ed first. ># >$fw add 10000 divert natd ip from $inet to any out >$fw add allow ip from any to any I have a few extras in there that a "pure" router wouldn't need, ie the forwarding of http to a Squid cache and the acceptance of incoming SMTP, plus I have a Linksys DSL modem/bridge which broadcasts DHCPACK packets once a=20 minute so I let them in to avoid polluting the logs. The driver behind this is that I wanted to be able to pass UDP safely so I could then move on to get linuxigd working, so I can use Windows Messenger=20 to have free voice conversations with a friend a few thousand miles away. What a shame that when I finally get round to looking at linuxigd I realise that it is written to use ipf and not ipfw :-(( From owner-freebsd-security@FreeBSD.ORG Tue Jun 24 23:55:43 2003 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5877137B401 for ; Tue, 24 Jun 2003 23:55:43 -0700 (PDT) Received: from techno.sub.ru (webmail.sub.ru [213.247.139.22]) by mx1.FreeBSD.org (Postfix) with SMTP id CD4B243FF2 for ; Tue, 24 Jun 2003 23:55:41 -0700 (PDT) (envelope-from tarkhil@webmail.sub.ru) Received: (qmail 60778 invoked by uid 0); 25 Jun 2003 06:55:34 -0000 Received: from unknown (HELO tarkhil.over.ru) (217.150.60.67) by webmail.sub.ru with SMTP; 25 Jun 2003 06:55:34 -0000 Date: Wed, 25 Jun 2003 10:54:09 +0400 From: Alex Povolotsky To: freebsd-security@freebsd.org Message-Id: <20030625105409.0e139577.tarkhil@webmail.sub.ru> In-Reply-To: <3EF06DFB.3020906@bimel.com.tr> References: <3EE9BC71.9000400@bimel.com.tr> <3EF06DFB.3020906@bimel.com.tr> Organization: sub.ru X-Mailer: Sylpheed version 0.8.10claws (GTK+ 1.2.10; i386-portbld-freebsd4.6) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: Gigabit Ethernet Security With Ipfilter X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2003 06:55:43 -0000 On Wed, 18 Jun 2003 16:49:47 +0300 Murat USTUNTAS wrote: MU> Local Area ========+-----------------+----------------> MU> (May be Giga Net) | Transparent | 2 Mbit Internet MU> | IpFilter | MU> +-----------------' MU> | MU> | MU> |_> (Giga Net) Servers MU> MU> And, take the information on NMBCLUSTERS , IPSTATE_SIZE and MU> IPSTATE_MAX in ip_state.h. MU> MU> Or must I write this mail about ipfilter to ipfilter's mailing list. I only wonder if two (incoming/outgoing) gigabit flows will leave anything from PCI bus bandwidth. 100 MHz, 32-bit bus can pass 3.2 gigabit per second AT MOST. Too little bus bandwidth can be left for any processing of data. -- Alex. From owner-freebsd-security@FreeBSD.ORG Fri Jun 27 07:48:46 2003 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6569C37B401 for ; Fri, 27 Jun 2003 07:48:46 -0700 (PDT) Received: from banzai.gnarst.net (banzai.gnarst.net [193.79.248.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id D413043F93 for ; Fri, 27 Jun 2003 07:48:44 -0700 (PDT) (envelope-from brendan@gnarst.net) Received: from localhost (localhost [127.0.0.1])h5REmh7m054532 for ; Fri, 27 Jun 2003 16:48:43 +0200 (CEST) (envelope-from brendan@gnarst.net) Received: from gnarst.net (localhost [127.0.0.1])h5REmfOc054525 for ; Fri, 27 Jun 2003 16:48:42 +0200 (CEST) (envelope-from brendan@gnarst.net) Message-Id: <200306271448.h5REmfOc054525@banzai.gnarst.net> From: Brendan Bank To: freebsd-security@freebsd.org Date: Fri, 27 Jun 2003 16:48:41 +0200 Sender: brendan@gnarst.net X-Virus-Scanned: by amavisd-new at gnarst.net Subject: Problems with the pam_opieaccess PAM module X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2003 14:48:46 -0000 Hi, I've configured opie (one time passwords) under FreeBSD and I came across the following problem. It looks like libpam does not stop the authentication process when a 'requisite' module fails. I find this strange as the pam 'requisite' is defined in the man pages as: requisite - failure of such a PAM results in the immediate termination of the authentication process; Here is what I did. I've setup opie for my account. I've configured pam_opieaccess (/etc/opieaccess) to allow my home network to use static passwords: permit 10.0.0.0 255.255.255.0 And in /etc/pam.conf I added: sshd auth required pam_opie.so sshd auth requisite pam_opieaccess.so sshd auth required /usr/lib/pam_krb5.so.1 try_first_pass forwardable The module pam_opieaccess is supposed to send a PAM_SUCCESS under the following conditions: 1. The user does not have OPIE enabled 2. The user has OPIE enabled, and the remote host is listed as a trusted host in /etc/opieaccess, and the user does not have a file named opiealways in his home directory. I read this as: If pam_opieaccess fails it returns PAM_AUTH_ERR and the authentication process should stop. However when it impent this sshd or the pam library does not take the PAM_AUTH_ERR and stop the authentication process but it just continues to with the pam_krb5 module. (btw I typed the wrong pw in the example bellow). eunoc25:[~] % ssh banzai otp-md5 442 ba4387 ext Password: pam_opieaccess: pam_sm_authenticate: Refused; remote host is not in opieaccess Last login: Fri Jun 27 16:26:41 2003 from eunoc25 Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.8-STABLE (BANZAI) #0: Thu Jun 5 23:39:01 CEST 2003 The 'pam_opieaccess: pam_sm_authenticate: Refused; remote host is not in opieaccess' indicates that the pam module failed. But it did let me log in. (brrrr) src/lib/libpam/modules/pam_opieaccess/pam_opieaccess.c ... PAM_VERBOSE_ERROR("Refused; remote host is not in opieaccess"); return (PAM_AUTH_ERR); ... I'm not sure if this is a bug but the results may be very dangerous. It looks like libpam does not stop the authentication process when a 'requisite' module fails. I'm running 4.8-STABLE. Regards, - Brendan