From owner-freebsd-security Sun Sep 15 5:24:49 2002 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 38BDD37B400 for ; Sun, 15 Sep 2002 05:24:46 -0700 (PDT) Received: from antalya.lupe-christoph.de (pD9E8815C.dip0.t-ipconnect.de [217.232.129.92]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0565A43E75 for ; Sun, 15 Sep 2002 05:24:44 -0700 (PDT) (envelope-from lupe@lupe-christoph.de) Received: by antalya.lupe-christoph.de (Postfix, from userid 1000) id 685E75F0; Sun, 15 Sep 2002 14:24:40 +0200 (CEST) Date: Sun, 15 Sep 2002 14:24:40 +0200 To: "Scot W. Hetzel" Cc: Greg Panula , freebsd-security@FreeBSD.ORG Subject: Re: asmtp 587 - quickie faq submission Message-ID: <20020915122440.GF23222@lupe-christoph.de> References: <002b01c25930$f4627270$0100a8c0@soap> <3D7F3726.958781C8@dolaninformation.com> <20020911153003.GD19536@lupe-christoph.de> <20020911161018.GE19536@lupe-christoph.de> <008e01c25b58$2a2eb930$11fd2fd8@ADMIN00> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <008e01c25b58$2a2eb930$11fd2fd8@ADMIN00> User-Agent: Mutt/1.4i From: lupe@lupe-christoph.de (Lupe Christoph) Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Friday, 2002-09-13 at 14:02:52 -0500, Scot W. Hetzel wrote: > From: "Lupe Christoph" > > On Wednesday, 2002-09-11 at 17:30:03 +0200, lupe wrote: > > > We still need an explanation for sendmail! I found nothing better than > > > http://www.sendmail.org/~ca/email/auth.html which doesn't look very > > > /usr/friendly to me ;-) > > > The default sendmail in FreeBSD is not compiled with SASL and does not > > > do ASMTP. I suppose one must install the sendmail-sasl port for this. > > > I'm doing that next, but can't test very much with it, due to my setup. > Or you can compile the default sendmail w/SASL support during a buildworld. The latest version of this is: Q: Ok, how about with Sendmail? A: To implement ASMTP, you must install a sendmail with SASL compiled in. This requires the installation of the cyrus-sasl port. You can then either recompile the system's sendmail as detailed in /etc/defaults/make.conf (look for SASL) or install the sendmail-sasl port, and replace the default sendmail with the one from that port. Add the following to your config.mc and recreate your sendmail.cf define(`confAUTH_MECHANISMS', `PLAIN DIGEST-MD5')dnl This allow use of Plain-text and DIGEST-MD5. Valid options are: GSSAPI KERBEROS_V4 DIGEST-MD5 CRAM-MD5 PLAIN Some help for this can be obtained from: http://www.sendmail.org/~ca/email/auth.html More background is contained in http://www.sendmail.org/~gshapiro/security.pdf > > Ok, I've installed the port. First thing /usr/local/sbin/sendmail > > complains about: > > error: safesasl(/usr/local/etc/sasldb.db) failed: Group readable file > > Chmodding to 600 gives: > > error: safesasl(/usr/local/etc/sasldb.db) failed: Permission denied > > Sigh. > Read PREFIX/doc/cyrus-sasl/Sendmail.README, It has all the information you > need to setup Sendmail w/SASL, and to configure the *.mc file. Greg, can you modify thusly, please: A: To implement ASMTP, you must install a sendmail with SASL compiled in. This requires the installation of the cyrus-sasl port. After you have installed cyrus-sasl, documentation for the modification of sendmail can be found in /usr/local/share/doc/cyrus-sasl/Sendmail.README. Starting with Sendmail 8.12, you can also use the security/cyrus-sasl2 port. The documentation for this version ends up in .../doc/cyrus-sasl2. You can then either recompile the system's sendmail as described in /usr/local/share/doc/cyrus-sasl*/Sendmail.README or in /etc/defaults/make.conf (look for SASL) or install the sendmail-sasl port, and replace the default sendmail with the one from that port. > Scot W. Hetzel > Cyrus-SASL v1 Maintainer The definitive source ;-) Thanks, Scot! Lupe -- | lupe@lupe-christoph.de | http://www.lupe-christoph.de/ | | Big Misunderstandings #6398: The Titanic was not supposed to be | | unsinkable. The designer had a speech impediment. He said: "I have | | thith great unthinkable conthept ..." | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Sep 15 15:42: 7 2002 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 43EE837B400 for ; Sun, 15 Sep 2002 15:42:03 -0700 (PDT) Received: from alcanet.com.au (mail3.alcanet.com.au [208.178.117.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id A98C743E75 for ; Sun, 15 Sep 2002 15:42:01 -0700 (PDT) (envelope-from peter.jeremy@alcatel.com.au) Received: from sydsmtp01.alcatel.com.au (IDENT:root@localhost.localdomain [127.0.0.1]) by alcanet.com.au (8.12.4/8.12.4/Alcanet1.3) with ESMTP id g8FMfuRS019840; Mon, 16 Sep 2002 08:41:56 +1000 Received: from gsmx07.alcatel.com.au ([139.188.20.247]) by sydsmtp01.alcatel.com.au (Lotus Domino Release 5.0.10) with ESMTP id 2002091608415501:41570 ; Mon, 16 Sep 2002 08:41:55 +1000 Received: from gsmx07.alcatel.com.au (localhost [127.0.0.1]) by gsmx07.alcatel.com.au (8.12.5/8.12.5) with ESMTP id g8FMfs2t012597; Mon, 16 Sep 2002 08:41:54 +1000 (EST) (envelope-from peter.jeremy@alcatel.com.au) Received: (from jeremyp@localhost) by gsmx07.alcatel.com.au (8.12.5/8.12.5/Submit) id g8FMfs5E012596; Mon, 16 Sep 2002 08:41:54 +1000 (EST) (envelope-from peter.jeremy@alcatel.com.au) Date: Mon, 16 Sep 2002 08:41:54 +1000 From: Peter Jeremy To: freebsd-security@freebsd.org Subject: Unexpected keep state behaviour in ipfw Message-ID: <20020915224154.GD495@gsmx07.alcatel.com.au> Mail-Followup-To: freebsd-security@freebsd.org Mime-Version: 1.0 User-Agent: Mutt/1.4i X-MIMETrack: Itemize by SMTP Server on SYDSMTP01/AlcatelAustralia(Release 5.0.10 |March 22, 2002) at 16/09/2002 08:41:55 AM, Serialize by Router on SYDSMTP01/AlcatelAustralia(Release 5.0.10 |March 22, 2002) at 16/09/2002 08:41:56 AM, Serialize complete at 16/09/2002 08:41:56 AM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I've been putting together a firewall and bumped into an oddity in the ipfw keep-state behaviour. In particular, the TCP state information for connections through the firewall appears to be being lost so that the connection disappears. I've used keep-state in the past and I'm sure it has worked as expected. Also, my ssh connection from an internal host to the firewall host remains up even after extended periods of inactivity (like overnight). Either ipfw doesn't like a back-to-back keep-state configuration or I've done something silly but I can't see what. I was initially using ipfw1 in -STABLE from about a week ago. When I switched to ipfw2 in -STABLE as of last Friday, the problem remained. (In both cases, I did a complete build and installworld). Configuration: +-------+ +-------+ +-------+ | | internal | | Internet | | | hosta |------------| fwall |------------| hostb | | | ed0| |ed1 | | +-------+ +-------+ +-------+ fwall is using ipnat for address translation and was initially using both IPFilter and ipfw rules, but the problem remained after I changed IPFilter to do nothing (pass {in,out} all). [I wanted to use ipfw because I am more familiar with it and I wanted to use ipnat because the firewall box is relatively underpowered and I didn't want all the traffic to have to go through the kernel/userland interface to natd(8)]. My ipfw rules were initially: 00100 allow ip from any to any via lo0 00200 deny ip from any to 127.0.0.0/8 00300 deny ip from 127.0.0.0/8 to any 00600 check-state 00650 deny log tcp from any to any established 01200 allow ip from internal-net/24 to any in recv ed0 keep-state 01300 skipto 30000 ip from any to internal-net/24 out xmit ed0 11000 allow tcp from me to any out xmit ed1 keep-state 11005 allow udp from me to any dst-port 53 out xmit ed1 keep-state 11005 allow udp from me to any dst-port 123 out xmit ed1 11005 allow udp from me 68 to any dst-port 67 out xmit ed1 keep-state 11005 allow icmp from me to any out xmit ed1 icmptypes 0,3,4,8,11,12 11005 allow icmp from any to me in recv ed1 icmptypes 0,3,4,8,11,12 11010 allow udp from any 123 to me in recv ed1 13000 deny log ip from any to any 30020 allow udp from me to any dst-port 123 30030 allow icmp from me to any icmptypes 0,3,4,8,11,12 31000 deny log ip from any to any 65535 deny ip from any to any I initially thought there might be a problem with duplicate FIN packets and added the following rule but it made no difference: 00610 allow tcp from any to any tcpflags fin The following is an example of the problem showing up on an FTP control connection. 'fwall-ed1' is the internet-visible address. /var/log/security: 07:08:02 fwall /kernel: ipfw: 650 Deny TCP fwall-ed1:1112 hostb:21 out via ed1 07:08:03 fwall /kernel: ipfw: 650 Deny TCP fwall-ed1:1112 hostb:21 out via ed1 07:08:05 fwall /kernel: ipfw: 650 Deny TCP fwall-ed1:1112 hostb:21 out via ed1 07:08:10 fwall /kernel: ipfw: 650 Deny TCP fwall-ed1:1112 hostb:21 out via ed1 07:08:20 fwall /kernel: ipfw: 650 Deny TCP fwall-ed1:1112 hostb:21 out via ed1 07:08:40 fwall /kernel: ipfw: 650 Deny TCP fwall-ed1:1112 hostb:21 out via ed1 07:09:19 fwall /kernel: ipfw: 650 Deny TCP fwall-ed1:1112 hostb:21 out via ed1 07:10:19 fwall /kernel: ipfw: 650 Deny TCP fwall-ed1:1112 hostb:21 out via ed1 07:11:19 fwall /kernel: ipfw: 650 Deny TCP fwall-ed1:1112 hostb:21 out via ed1 07:12:19 fwall /kernel: ipfw: 650 Deny TCP fwall-ed1:1112 hostb:21 out via ed1 07:13:20 fwall /kernel: ipfw: 650 Deny TCP fwall-ed1:1112 hostb:21 out via ed1 07:14:14 fwall /kernel: ipfw: 650 Deny TCP fwall-ed1:1112 hostb:21 out via ed1 07:14:20 fwall /kernel: ipfw: 650 Deny TCP hostb:21 hosta:1112 in via ed1 fwall# tcpdump -i ed0 07:04:01.863247 hosta.1112 > hostb.ftp: P 147:157(10) ack 662 win 57964 (DF) [tos 0x10] 07:04:02.104378 hostb.ftp > hosta.1112: P 662:715(53) ack 157 win 17524 07:04:02.198438 hosta.1112 > hostb.ftp: . ack 715 win 57964 (DF) [tos 0x10] 07:04:02.428996 hostb.ftp > hosta.1112: P 715:745(30) ack 157 win 17524 07:04:02.528507 hosta.1112 > hostb.ftp: . ack 745 win 57964 (DF) [tos 0x10] 07:08:02.190741 hostb.ftp > hosta.1112: P 745:782(37) ack 157 win 17524 07:08:02.291580 hosta.1112 > hostb.ftp: . ack 782 win 57927 (DF) [tos 0x10] 07:08:03.417151 hostb.ftp > hosta.1112: . 745:782(37) ack 157 win 17524 07:08:03.417888 hosta.1112 > hostb.ftp: . ack 782 win 57927 (DF) [tos 0x10] 07:08:05.877990 hostb.ftp > hosta.1112: . 745:782(37) ack 157 win 17524 07:08:05.878703 hosta.1112 > hostb.ftp: . ack 782 win 57927 (DF) [tos 0x10] 07:08:10.798902 hostb.ftp > hosta.1112: . 745:782(37) ack 157 win 17524 07:08:10.799621 hosta.1112 > hostb.ftp: . ack 782 win 57927 (DF) [tos 0x10] 07:08:20.651400 hostb.ftp > hosta.1112: . 745:782(37) ack 157 win 17524 07:08:20.652125 hosta.1112 > hostb.ftp: . ack 782 win 57927 (DF) [tos 0x10] 07:08:40.366279 hostb.ftp > hosta.1112: . 745:782(37) ack 157 win 17524 07:08:40.367120 hosta.1112 > hostb.ftp: . ack 782 win 57927 (DF) [tos 0x10] 07:09:19.796673 hostb.ftp > hosta.1112: . 745:782(37) ack 157 win 17524 07:09:19.797487 hosta.1112 > hostb.ftp: . ack 782 win 57927 (DF) [tos 0x10] 07:10:19.808705 hostb.ftp > hosta.1112: . 745:782(37) ack 157 win 17524 07:10:19.809477 hosta.1112 > hostb.ftp: . ack 782 win 57927 (DF) [tos 0x10] 07:11:19.821934 hostb.ftp > hosta.1112: . 745:782(37) ack 157 win 17524 07:11:19.822731 hosta.1112 > hostb.ftp: . ack 782 win 57927 (DF) [tos 0x10] 07:12:19.835383 hostb.ftp > hosta.1112: . 745:782(37) ack 157 win 17524 07:12:19.836158 hosta.1112 > hostb.ftp: . ack 782 win 57927 (DF) [tos 0x10] 07:13:19.849184 hostb.ftp > hosta.1112: . 745:782(37) ack 157 win 17524 07:13:19.850012 hosta.1112 > hostb.ftp: . ack 782 win 57927 (DF) [tos 0x10] 07:14:13.879800 hosta.1112 > hostb.ftp: P 157:163(6) ack 782 win 57927 (DF) [tos 0x10] 07:14:13.879993 hosta.1112 > hostb.ftp: F 163:163(0) ack 782 win 57964 (DF) [tos 0x10] 07:14:14.113211 hostb.ftp > hosta.1112: R 2194364317:2194364317(0) win 0 (DF) fwall# tcpdump -i ed1 07:04:02.103450 hostb.ftp > fwall-ed1.1112: P 662:715(53) ack 157 win 17524 07:04:02.122875 hostb.59915 > fwall-ed1.1115: P 1:223(222) ack 1 win 17524 07:04:02.122972 hostb.59915 > fwall-ed1.1115: F 223:223(0) ack 1 win 17524 07:04:02.125752 fwall-ed1.1115 > hostb.59915: . ack 224 win 57964 (DF) [tos 0x8] 07:04:02.140270 fwall-ed1.1115 > hostb.59915: F 1:1(0) ack 224 win 57964 (DF) [tos 0x8] 07:04:02.199236 fwall-ed1.1112 > hostb.ftp: . ack 715 win 57964 (DF) [tos 0x10] 07:04:02.369724 hostb.59915 > fwall-ed1.1115: . ack 2 win 17524 07:04:02.428304 hostb.ftp > fwall-ed1.1112: P 715:745(30) ack 157 win 17524 07:04:02.529223 fwall-ed1.1112 > hostb.ftp: . ack 745 win 57964 (DF) [tos 0x10] 07:08:02.189388 hostb.ftp > fwall-ed1.1112: P 745:782(37) ack 157 win 17524 07:08:03.416245 hostb.ftp > fwall-ed1.1112: . 745:782(37) ack 157 win 17524 07:08:05.876702 hostb.ftp > fwall-ed1.1112: . 745:782(37) ack 157 win 17524 07:08:10.797991 hostb.ftp > fwall-ed1.1112: . 745:782(37) ack 157 win 17524 07:08:20.650392 hostb.ftp > fwall-ed1.1112: . 745:782(37) ack 157 win 17524 07:08:40.364907 hostb.ftp > fwall-ed1.1112: . 745:782(37) ack 157 win 17524 07:09:19.795268 hostb.ftp > fwall-ed1.1112: . 745:782(37) ack 157 win 17524 07:10:19.807132 hostb.ftp > fwall-ed1.1112: . 745:782(37) ack 157 win 17524 07:11:19.820499 hostb.ftp > fwall-ed1.1112: . 745:782(37) ack 157 win 17524 07:12:19.834029 hostb.ftp > fwall-ed1.1112: . 745:782(37) ack 157 win 17524 07:13:19.847717 hostb.ftp > fwall-ed1.1112: . 745:782(37) ack 157 win 17524 07:14:13.882752 fwall-ed1.1112 > hostb.ftp: F 163:163(0) ack 782 win 57964 (DF) [tos 0x10] 07:14:14.112270 hostb.ftp > fwall-ed1.1112: R 2194364317:2194364317(0) win 0 (DF) 07:14:19.861397 hostb.ftp > fwall-ed1.1112: . 745:782(37) ack 157 win 17524 07:15:19.875126 hostb.ftp > fwall-ed1.1112: . 745:782(37) ack 157 win 17524 Why does ipfw close the outgoing path from hosta to hostb after 4 minutes of inactivity? According to the ipfw man page, ipfw2 will generate keep-alive packets when a keep-state rule is about to expire. Why don't I see any in the tcpdump traces? Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Sep 15 15:56:46 2002 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 CDCDB37B400 for ; Sun, 15 Sep 2002 15:56:44 -0700 (PDT) Received: from walter.dfmm.org (walter.dfmm.org [209.151.233.240]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6FD4443E6A for ; Sun, 15 Sep 2002 15:56:44 -0700 (PDT) (envelope-from jason-fbsd-security@shalott.net) Received: (qmail 87921 invoked by uid 1000); 15 Sep 2002 22:56:44 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 15 Sep 2002 22:56:44 -0000 Date: Sun, 15 Sep 2002 15:56:43 -0700 (PDT) From: Jason Stone X-X-Sender: To: Subject: Administrivia In-Reply-To: <200209142209.g8EM92B5043544@drugs.dv.isc.org> Message-ID: <20020915154303.N76675-100000@walter> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Please remember that posting on this list is now limited to subscribers, so when replying to a message, please reply only to the list. If you reply to both the list and the sender, the sender gets multiple copies. Thank you. -Jason ----------------------------------------------------------------------- I worry about my child and the Internet all the time, even though she's too young to have logged on yet. Here's what I worry about. I worry that 10 or 15 years from now, she will come to me and say "Daddy, where were you when they took freedom of the press away from the Internet?" -- Mike Godwin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: See https://private.idealab.com/public/jason/jason.gpg iD8DBQE9hRAsswXMWWtptckRAiDpAKDKKJ6KAlG7dw0H+TdbZ6RS9MDH4gCfRjMw sYPOST2BkrlCEDi0JQyvO9g= =h9s+ -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Sep 15 23:44:36 2002 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 7381037B400 for ; Sun, 15 Sep 2002 23:44:35 -0700 (PDT) Received: from alcanet.com.au (mail3.alcanet.com.au [208.178.117.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id E68D043E65 for ; Sun, 15 Sep 2002 23:44:33 -0700 (PDT) (envelope-from peter.jeremy@alcatel.com.au) Received: from sydsmtp01.alcatel.com.au (IDENT:root@localhost.localdomain [127.0.0.1]) by alcanet.com.au (8.12.4/8.12.4/Alcanet1.3) with ESMTP id g8G6iRRS031204 for ; Mon, 16 Sep 2002 16:44:28 +1000 Received: from gsmx07.alcatel.com.au ([139.188.20.247]) by sydsmtp01.alcatel.com.au (Lotus Domino Release 5.0.10) with ESMTP id 2002091616442663:47750 ; Mon, 16 Sep 2002 16:44:26 +1000 Received: from gsmx07.alcatel.com.au (localhost [127.0.0.1]) by gsmx07.alcatel.com.au (8.12.5/8.12.5) with ESMTP id g8G6iQ2t014453 for ; Mon, 16 Sep 2002 16:44:26 +1000 (EST) (envelope-from peter.jeremy@alcatel.com.au) Received: (from jeremyp@localhost) by gsmx07.alcatel.com.au (8.12.5/8.12.5/Submit) id g8G6iQ2r014452 for freebsd-security@freebsd.org; Mon, 16 Sep 2002 16:44:26 +1000 (EST) (envelope-from peter.jeremy@alcatel.com.au) Date: Mon, 16 Sep 2002 16:44:26 +1000 From: Peter Jeremy To: freebsd-security@freebsd.org Subject: IPSec/XAuth Message-ID: <20020916064426.GA14444@gsmx07.alcatel.com.au> Mail-Followup-To: freebsd-security@freebsd.org Mime-Version: 1.0 User-Agent: Mutt/1.4i X-MIMETrack: Itemize by SMTP Server on SYDSMTP01/AlcatelAustralia(Release 5.0.10 |March 22, 2002) at 16/09/2002 04:44:26 PM, Serialize by Router on SYDSMTP01/AlcatelAustralia(Release 5.0.10 |March 22, 2002) at 16/09/2002 04:44:28 PM, Serialize complete at 16/09/2002 04:44:28 PM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Is anyone working on an XAuth implementation for IPSec? For background information on XAuth, have a look at http://www.nwfusion.com/news/tech/2000/0828tech.html (This is nothing to do with X11 xauth). Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Sep 16 23:55:53 2002 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 8B94C37B400 for ; Mon, 16 Sep 2002 23:55:46 -0700 (PDT) Received: from smtp.comcast.net (smtp.comcast.net [24.153.64.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id E490743E3B for ; Mon, 16 Sep 2002 23:55:45 -0700 (PDT) (envelope-from dfolkins@comcast.net) Disposition-notification-to: dfolkins@comcast.net Received: from groovy3xp (pcp01731796pcs.selrsv01.pa.comcast.net [68.83.131.193]) by mtaout01.icomcast.net (iPlanet Messaging Server 5.1 HotFix 1.4 (built Aug 5 2002)) with SMTP id <0H2K00A4DLWWFK@mtaout01.icomcast.net> for freebsd-security@freebsd.org; Tue, 17 Sep 2002 02:55:45 -0400 (EDT) Date: Tue, 17 Sep 2002 02:55:36 -0400 From: dfolkins Subject: Re: Unexpected keep state behaviour in ipfw To: freebsd-security@freebsd.org Message-id: <001a01c25e17$39edcde0$0a00a8c0@groovy3xp> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20020915224154.GD495@gsmx07.alcatel.com.au> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > I've been putting together a firewall and bumped into an oddity in the > ipfw keep-state behaviour. In particular, the TCP state information > for connections through the firewall appears to be being lost so that > the connection disappears. I've used keep-state in the past and I'm > sure it has worked as expected. Also, my ssh connection from an > internal host to the firewall host remains up even after extended > periods of inactivity (like overnight). Either ipfw doesn't like a > back-to-back keep-state configuration or I've done something silly but > I can't see what. > > I was initially using ipfw1 in -STABLE from about a week ago. When I > switched to ipfw2 in -STABLE as of last Friday, the problem remained. > (In both cases, I did a complete build and installworld). > please note right away that i have no experience with ipfw2 and its automatic keep-alive, my response is targeted to ipfw only. first, your "idle time" for standard tcp connections is controlled by a sysctl variable named net.inet.ip.fw.dyn_ack_lifetime. if it is set too short (default is 300 seconds, i think) you can always just reset it to a longer value, either from command prompt or from sysctl.conf. just set it to a number you think appropriate for idle established connections to remain active. e.g. if you want your idle ftp connections to stay alive for 10 minutes, set that variable to 600. there are a bunch of related variables. to see them all just do a "sysctl -a |grep dyn". as to why your ssh connection stays alive even through the night - i suspect that is because your ssh server on your firewall has a configuration setting that makes it send keep-alives, i.e. your clientaliveinterval in sshd_config is set to some value which is less than your net.inet.ip.fw.dyn_ack_lifetime value. that might be keeping your idle ssh connections up. sorry, cant tell you anything about ipfw2's keepalive packets. -- dfolkins > > Configuration: > > +-------+ +-------+ +-------+ > | | internal | | Internet | | > | hosta |------------| fwall |------------| hostb | > | | ed0| |ed1 | | > +-------+ +-------+ +-------+ > > fwall is using ipnat for address translation and was initially using > both IPFilter and ipfw rules, but the problem remained after I changed > IPFilter to do nothing (pass {in,out} all). [I wanted to use ipfw > because I am more familiar with it and I wanted to use ipnat because > the firewall box is relatively underpowered and I didn't want all > the traffic to have to go through the kernel/userland interface to > natd(8)]. > > My ipfw rules were initially: > 00100 allow ip from any to any via lo0 > 00200 deny ip from any to 127.0.0.0/8 > 00300 deny ip from 127.0.0.0/8 to any > 00600 check-state > 00650 deny log tcp from any to any established > 01200 allow ip from internal-net/24 to any in recv ed0 keep-state > 01300 skipto 30000 ip from any to internal-net/24 out xmit ed0 > 11000 allow tcp from me to any out xmit ed1 keep-state > 11005 allow udp from me to any dst-port 53 out xmit ed1 keep-state > 11005 allow udp from me to any dst-port 123 out xmit ed1 > 11005 allow udp from me 68 to any dst-port 67 out xmit ed1 keep-state > 11005 allow icmp from me to any out xmit ed1 icmptypes 0,3,4,8,11,12 > 11005 allow icmp from any to me in recv ed1 icmptypes 0,3,4,8,11,12 > 11010 allow udp from any 123 to me in recv ed1 > 13000 deny log ip from any to any > 30020 allow udp from me to any dst-port 123 > 30030 allow icmp from me to any icmptypes 0,3,4,8,11,12 > 31000 deny log ip from any to any > 65535 deny ip from any to any > > I initially thought there might be a problem with duplicate FIN > packets and added the following rule but it made no difference: > 00610 allow tcp from any to any tcpflags fin > > The following is an example of the problem showing up on an FTP > control connection. 'fwall-ed1' is the internet-visible address. > > /var/log/security: > 07:08:02 fwall /kernel: ipfw: 650 Deny TCP fwall-ed1:1112 hostb:21 out via ed1 > 07:08:03 fwall /kernel: ipfw: 650 Deny TCP fwall-ed1:1112 hostb:21 out via ed1 > 07:08:05 fwall /kernel: ipfw: 650 Deny TCP fwall-ed1:1112 hostb:21 out via ed1 > 07:08:10 fwall /kernel: ipfw: 650 Deny TCP fwall-ed1:1112 hostb:21 out via ed1 > 07:08:20 fwall /kernel: ipfw: 650 Deny TCP fwall-ed1:1112 hostb:21 out via ed1 > 07:08:40 fwall /kernel: ipfw: 650 Deny TCP fwall-ed1:1112 hostb:21 out via ed1 > 07:09:19 fwall /kernel: ipfw: 650 Deny TCP fwall-ed1:1112 hostb:21 out via ed1 > 07:10:19 fwall /kernel: ipfw: 650 Deny TCP fwall-ed1:1112 hostb:21 out via ed1 > 07:11:19 fwall /kernel: ipfw: 650 Deny TCP fwall-ed1:1112 hostb:21 out via ed1 > 07:12:19 fwall /kernel: ipfw: 650 Deny TCP fwall-ed1:1112 hostb:21 out via ed1 > 07:13:20 fwall /kernel: ipfw: 650 Deny TCP fwall-ed1:1112 hostb:21 out via ed1 > 07:14:14 fwall /kernel: ipfw: 650 Deny TCP fwall-ed1:1112 hostb:21 out via ed1 > 07:14:20 fwall /kernel: ipfw: 650 Deny TCP hostb:21 hosta:1112 in via ed1 > > fwall# tcpdump -i ed0 > 07:04:01.863247 hosta.1112 > hostb.ftp: P 147:157(10) ack 662 win 57964 (DF) [tos 0x10] > 07:04:02.104378 hostb.ftp > hosta.1112: P 662:715(53) ack 157 win 17524 > 07:04:02.198438 hosta.1112 > hostb.ftp: . ack 715 win 57964 (DF) [tos 0x10] > 07:04:02.428996 hostb.ftp > hosta.1112: P 715:745(30) ack 157 win 17524 > 07:04:02.528507 hosta.1112 > hostb.ftp: . ack 745 win 57964 (DF) [tos 0x10] > 07:08:02.190741 hostb.ftp > hosta.1112: P 745:782(37) ack 157 win 17524 > 07:08:02.291580 hosta.1112 > hostb.ftp: . ack 782 win 57927 (DF) [tos 0x10] > 07:08:03.417151 hostb.ftp > hosta.1112: . 745:782(37) ack 157 win 17524 > 07:08:03.417888 hosta.1112 > hostb.ftp: . ack 782 win 57927 (DF) [tos 0x10] > 07:08:05.877990 hostb.ftp > hosta.1112: . 745:782(37) ack 157 win 17524 > 07:08:05.878703 hosta.1112 > hostb.ftp: . ack 782 win 57927 (DF) [tos 0x10] > 07:08:10.798902 hostb.ftp > hosta.1112: . 745:782(37) ack 157 win 17524 > 07:08:10.799621 hosta.1112 > hostb.ftp: . ack 782 win 57927 (DF) [tos 0x10] > 07:08:20.651400 hostb.ftp > hosta.1112: . 745:782(37) ack 157 win 17524 > 07:08:20.652125 hosta.1112 > hostb.ftp: . ack 782 win 57927 (DF) [tos 0x10] > 07:08:40.366279 hostb.ftp > hosta.1112: . 745:782(37) ack 157 win 17524 > 07:08:40.367120 hosta.1112 > hostb.ftp: . ack 782 win 57927 (DF) [tos 0x10] > 07:09:19.796673 hostb.ftp > hosta.1112: . 745:782(37) ack 157 win 17524 > 07:09:19.797487 hosta.1112 > hostb.ftp: . ack 782 win 57927 (DF) [tos 0x10] > 07:10:19.808705 hostb.ftp > hosta.1112: . 745:782(37) ack 157 win 17524 > 07:10:19.809477 hosta.1112 > hostb.ftp: . ack 782 win 57927 (DF) [tos 0x10] > 07:11:19.821934 hostb.ftp > hosta.1112: . 745:782(37) ack 157 win 17524 > 07:11:19.822731 hosta.1112 > hostb.ftp: . ack 782 win 57927 (DF) [tos 0x10] > 07:12:19.835383 hostb.ftp > hosta.1112: . 745:782(37) ack 157 win 17524 > 07:12:19.836158 hosta.1112 > hostb.ftp: . ack 782 win 57927 (DF) [tos 0x10] > 07:13:19.849184 hostb.ftp > hosta.1112: . 745:782(37) ack 157 win 17524 > 07:13:19.850012 hosta.1112 > hostb.ftp: . ack 782 win 57927 (DF) [tos 0x10] > 07:14:13.879800 hosta.1112 > hostb.ftp: P 157:163(6) ack 782 win 57927 (DF) [tos 0x10] > 07:14:13.879993 hosta.1112 > hostb.ftp: F 163:163(0) ack 782 win 57964 (DF) [tos 0x10] > 07:14:14.113211 hostb.ftp > hosta.1112: R 2194364317:2194364317(0) win 0 (DF) > > fwall# tcpdump -i ed1 > 07:04:02.103450 hostb.ftp > fwall-ed1.1112: P 662:715(53) ack 157 win 17524 > 07:04:02.122875 hostb.59915 > fwall-ed1.1115: P 1:223(222) ack 1 win 17524 > 07:04:02.122972 hostb.59915 > fwall-ed1.1115: F 223:223(0) ack 1 win 17524 > 07:04:02.125752 fwall-ed1.1115 > hostb.59915: . ack 224 win 57964 (DF) [tos 0x8] > 07:04:02.140270 fwall-ed1.1115 > hostb.59915: F 1:1(0) ack 224 win 57964 (DF) [tos 0x8] > 07:04:02.199236 fwall-ed1.1112 > hostb.ftp: . ack 715 win 57964 (DF) [tos 0x10] > 07:04:02.369724 hostb.59915 > fwall-ed1.1115: . ack 2 win 17524 > 07:04:02.428304 hostb.ftp > fwall-ed1.1112: P 715:745(30) ack 157 win 17524 > 07:04:02.529223 fwall-ed1.1112 > hostb.ftp: . ack 745 win 57964 (DF) [tos 0x10] > 07:08:02.189388 hostb.ftp > fwall-ed1.1112: P 745:782(37) ack 157 win 17524 > 07:08:03.416245 hostb.ftp > fwall-ed1.1112: . 745:782(37) ack 157 win 17524 > 07:08:05.876702 hostb.ftp > fwall-ed1.1112: . 745:782(37) ack 157 win 17524 > 07:08:10.797991 hostb.ftp > fwall-ed1.1112: . 745:782(37) ack 157 win 17524 > 07:08:20.650392 hostb.ftp > fwall-ed1.1112: . 745:782(37) ack 157 win 17524 > 07:08:40.364907 hostb.ftp > fwall-ed1.1112: . 745:782(37) ack 157 win 17524 > 07:09:19.795268 hostb.ftp > fwall-ed1.1112: . 745:782(37) ack 157 win 17524 > 07:10:19.807132 hostb.ftp > fwall-ed1.1112: . 745:782(37) ack 157 win 17524 > 07:11:19.820499 hostb.ftp > fwall-ed1.1112: . 745:782(37) ack 157 win 17524 > 07:12:19.834029 hostb.ftp > fwall-ed1.1112: . 745:782(37) ack 157 win 17524 > 07:13:19.847717 hostb.ftp > fwall-ed1.1112: . 745:782(37) ack 157 win 17524 > 07:14:13.882752 fwall-ed1.1112 > hostb.ftp: F 163:163(0) ack 782 win 57964 (DF) [tos 0x10] > 07:14:14.112270 hostb.ftp > fwall-ed1.1112: R 2194364317:2194364317(0) win 0 (DF) > 07:14:19.861397 hostb.ftp > fwall-ed1.1112: . 745:782(37) ack 157 win 17524 > 07:15:19.875126 hostb.ftp > fwall-ed1.1112: . 745:782(37) ack 157 win 17524 > > Why does ipfw close the outgoing path from hosta to hostb after 4 > minutes of inactivity? > > According to the ipfw man page, ipfw2 will generate keep-alive packets > when a keep-state rule is about to expire. Why don't I see any in the > tcpdump traces? > > Peter > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Sep 17 6:22:28 2002 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 A1EFB37B401 for ; Tue, 17 Sep 2002 06:22:25 -0700 (PDT) Received: from host185.dolanmedia.com (host185.dolanmedia.com [209.98.197.185]) by mx1.FreeBSD.org (Postfix) with SMTP id B1CB543E6A for ; Tue, 17 Sep 2002 06:22:24 -0700 (PDT) (envelope-from greg.panula@dolaninformation.com) Received: (qmail 78485 invoked by uid 0); 17 Sep 2002 13:22:24 -0000 Received: from greg.panula@dolaninformation.com by proxy with qmail-scanner-0.96 (. Clean. Processed in 0.489811 secs); 17 Sep 2002 13:22:24 -0000 X-Qmail-Scanner-Mail-From: greg.panula@dolaninformation.com via proxy X-Qmail-Scanner-Rcpt-To: freebsd-security@freebsd.org X-Qmail-Scanner: 0.96 (No viruses found. Processed in 0.489811 secs) Received: from unknown (HELO mail.dolanmedia.com) (10.1.1.23) by host185.dolanmedia.com with SMTP; 17 Sep 2002 13:22:23 -0000 Received: from dolaninformation.com (10.1.1.135) by mail.dolanmedia.com (Worldmail 1.3.167) for freebsd-security@freebsd.org; 17 Sep 2002 08:22:23 -0500 Message-ID: <3D872C8E.C0D318DD@dolaninformation.com> Date: Tue, 17 Sep 2002 08:22:22 -0500 From: Greg Panula Reply-To: greg.panula@dolaninformation.com Organization: Dolan Information Center Inc X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: asmtp 587 - quickie faq submission References: <002b01c25930$f4627270$0100a8c0@soap> <3D7F3726.958781C8@dolaninformation.com> <20020911153003.GD19536@lupe-christoph.de> <20020911161018.GE19536@lupe-christoph.de> <008e01c25b58$2a2eb930$11fd2fd8@ADMIN00> <20020915122440.GF23222@lupe-christoph.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Ok, here is the latest&greatest version: FAQ Submission: ASMTP Q: What is ASMTP? A: Authenticated SMTP, as explained in RFC 2554 Q: What is ASMTP good for? A: Allow the SMTP server to authenticate users before allowing them to use the smtp service for sending mail. Useful if you have roaming users that connect from foreign networks (e.g. hotel somewhere). Q: How do I or my users make use of ASMTP? A: The user's email client needs to be configured to authenticate themselves to the smtp server. Earthlink has a FAQ section explaining various email client configurations at http://support.earthlink.net/mu/1/psc/img/walkthroughs/Help_FAQ/7280.psc.html Q: How do I implement ASMTP on my mail server? A: Depends on your MTA. Q: Ok, how about with Postfix? A: For information about configuring ASMTP&Postfix checkout: http://howto.state-of-mind.de/ Q: Ok, how about with Sendmail? A: To implement ASMTP, you must install a sendmail with SASL compiled in. This requires the installation of the cyrus-sasl port. After you have installed cyrus-sasl, documentation for the modification of sendmail can be found in /usr/local/share/doc/cyrus-sasl/Sendmail.README. Starting with Sendmail 8.12, you can also use the security/cyrus-sasl2 port. The documentation for this version ends up in .../doc/cyrus-sasl2. You can then either recompile the system's sendmail as described in /usr/local/share/doc/cyrus-sasl*/Sendmail.README or in /etc/defaults/make.conf (look for SASL) or install the sendmail-sasl port, and replace the default sendmail with the one from that port. Some additional information can be found at: http://www.sendmail.org/~ca/email/auth.html http://www.sendmail.org/~gshapiro/security.pdf FAQ Submission: Sendmail & port 587 Q: Why does Sendmail listen on Port 587? A: For compliance with RFC 2476 which states that separating the different parts of mail handling (submissions&transfers) is a good thing and port 587 was deemed to be the port for handling submissions. Sendmail 8.10.0 introduced DaemonPortOptions to support this. Checkout http://www.sendmail.org/~gshapiro/8.10.Training/DaemonPortOptions.html for some quick info about DaemonPortOptions. Q: How do I turn off the Message Submission Agent aka stop Sendmail from listening on port 587? A: A: Add FEATURE(`no_default_msa') your config.mc config file and recreate your sendmail.cf file. Brief example of recreating your sendmail.cf can be found at: http://www.sendmail.org/m4/intro.html Comments, suggestions, corrections? Thanks, Greg To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Sep 17 6:59:37 2002 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 B4CB237B401 for ; Tue, 17 Sep 2002 06:59:35 -0700 (PDT) Received: from HAL9000.homeunix.com (12-232-220-15.client.attbi.com [12.232.220.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C0C643E65 for ; Tue, 17 Sep 2002 06:59:35 -0700 (PDT) (envelope-from dschultz@uclink.Berkeley.EDU) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.6/8.12.5) with ESMTP id g8HDxYX4002258 for ; Tue, 17 Sep 2002 06:59:34 -0700 (PDT) (envelope-from dschultz@uclink.Berkeley.EDU) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.6/8.12.5/Submit) id g8HDxYmU002257 for security@FreeBSD.ORG; Tue, 17 Sep 2002 06:59:34 -0700 (PDT) (envelope-from dschultz@uclink.Berkeley.EDU) Date: Tue, 17 Sep 2002 06:59:34 -0700 From: David Schultz To: security@FreeBSD.ORG Subject: race in i386_set_ldt(2) Message-ID: <20020917135934.GA2215@HAL9000.homeunix.com> Mail-Followup-To: security@FreeBSD.ORG Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org There seems to be a nasty exploitable race in i386_set_ldt(2), as David Xu pointed out some months ago in i386/38021. As this is a vulnerability when the kernel is compiled with the USER_LDT option, I thought I'd do my part to try to convince someone to commit a fix. Although David's patch has a few nits in it, his basic approach of copying the descriptors into a temporary kernel buffer is necessary if i386_set_ldt() is to be both safe and transactional. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Sep 17 7:17:11 2002 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 45B8437B401 for ; Tue, 17 Sep 2002 07:17:09 -0700 (PDT) Received: from CPE0004761ac738-CM00109515bc65.cpe.net.cable.rogers.com (CPE0004761ac738-CM00109515bc65.cpe.net.cable.rogers.com [24.103.39.131]) by mx1.FreeBSD.org (Postfix) with SMTP id C54AA43E75 for ; Tue, 17 Sep 2002 07:17:07 -0700 (PDT) (envelope-from miro@cybershade.us) Received: (qmail 22611 invoked from network); 17 Sep 2002 14:17:17 -0000 Received: from unknown (HELO vsivyoung) (66.46.21.253) by cpe0004761ac738-cm00109515bc65.cpe.net.cable.rogers.com with SMTP; 17 Sep 2002 14:17:17 -0000 Message-ID: <002801c25e54$ebfd3920$c801a8c0@vsivyoung> From: "Miroslav Pendev" To: "FreeBSD Security" Subject: Re: asmtp 587 - quickie faq submission Date: Tue, 17 Sep 2002 10:17:07 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > Q: How do I implement ASMTP on my mail server? > A: Depends on your MTA. > > Q: Ok, how about with Postfix? > A: For information about configuring ASMTP&Postfix checkout: > http://howto.state-of-mind.de/ > There is SMTP AUTH patch for qmail, too. http://www.nimh.org/dl/qmail-smtpd.c Although, it is not in the port for qmail it can be added like WITH_SMTP_AUTH=yes, I can submit that as PR if nobody else want. Works pretty well for me. Miro -------- -Maniac in the field of Quantum Electronics! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Sep 17 7:33: 4 2002 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 459F537B401 for ; Tue, 17 Sep 2002 07:33:02 -0700 (PDT) Received: from antalya.lupe-christoph.de (pD9E88050.dip0.t-ipconnect.de [217.232.128.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2DAE443E42 for ; Tue, 17 Sep 2002 07:33:01 -0700 (PDT) (envelope-from lupe@lupe-christoph.de) Received: by antalya.lupe-christoph.de (Postfix, from userid 1000) id 848C45F0; Tue, 17 Sep 2002 16:32:58 +0200 (CEST) Date: Tue, 17 Sep 2002 16:32:58 +0200 To: Miroslav Pendev Cc: FreeBSD Security Subject: Re: asmtp 587 - quickie faq submission Message-ID: <20020917143258.GB1238@lupe-christoph.de> References: <002801c25e54$ebfd3920$c801a8c0@vsivyoung> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002801c25e54$ebfd3920$c801a8c0@vsivyoung> User-Agent: Mutt/1.4i From: lupe@lupe-christoph.de (Lupe Christoph) Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tuesday, 2002-09-17 at 10:17:07 -0400, Miroslav Pendev wrote: > > Q: How do I implement ASMTP on my mail server? > > A: Depends on your MTA. > > Q: Ok, how about with Postfix? > > A: For information about configuring ASMTP&Postfix checkout: > > http://howto.state-of-mind.de/ > There is SMTP AUTH patch for qmail, too. > http://www.nimh.org/dl/qmail-smtpd.c > Although, it is not in the port for qmail it can be added like > WITH_SMTP_AUTH=yes, I can submit that as PR if nobody else want. > Works pretty well for me. Why don't you write up how to do it? Here's the question: Q: Ok, how about with qmail? You just need to write the answer ;-). Please provide a little more detail. Your information above is just a little on the brief side... Thanks, Lupe Christoph -- | lupe@lupe-christoph.de | http://www.lupe-christoph.de/ | | Big Misunderstandings #6398: The Titanic was not supposed to be | | unsinkable. The designer had a speech impediment. He said: "I have | | thith great unthinkable conthept ..." | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Sep 17 8:34:13 2002 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 8897A37B401 for ; Tue, 17 Sep 2002 08:34:10 -0700 (PDT) Received: from CPE0004761ac738-CM00109515bc65.cpe.net.cable.rogers.com (CPE0004761ac738-CM00109515bc65.cpe.net.cable.rogers.com [24.103.39.131]) by mx1.FreeBSD.org (Postfix) with SMTP id 64E2043E4A for ; Tue, 17 Sep 2002 08:34:09 -0700 (PDT) (envelope-from miro@cybershade.us) Received: (qmail 775 invoked from network); 17 Sep 2002 15:34:23 -0000 Received: from unknown (HELO vsivyoung) (66.46.21.253) by cpe0004761ac738-cm00109515bc65.cpe.net.cable.rogers.com with SMTP; 17 Sep 2002 15:34:23 -0000 Message-ID: <004c01c25e5f$af194c50$c801a8c0@vsivyoung> From: "Miroslav Pendev" To: "FreeBSD Security" References: <002801c25e54$ebfd3920$c801a8c0@vsivyoung> <20020917143258.GB1238@lupe-christoph.de> Subject: Re: asmtp 587 - quickie faq submission Date: Tue, 17 Sep 2002 11:34:16 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > On Tuesday, 2002-09-17 at 10:17:07 -0400, Miroslav Pendev wrote: > > > Q: How do I implement ASMTP on my mail server? > > > A: Depends on your MTA. > > > > Q: Ok, how about with Postfix? > > > A: For information about configuring ASMTP&Postfix checkout: > > > http://howto.state-of-mind.de/ > > > There is SMTP AUTH patch for qmail, too. > > > http://www.nimh.org/dl/qmail-smtpd.c > > > Although, it is not in the port for qmail it can be added like > > WITH_SMTP_AUTH=yes, I can submit that as PR if nobody else want. > > > Works pretty well for me. > > Why don't you write up how to do it? Here's the question: > > Q: Ok, how about with qmail? > > You just need to write the answer ;-). Please provide a little more > detail. Your information above is just a little on the brief side... OK, I am on it. I can make a patch-ad for qmail/files, because it should be better to explain how to build qmail with smtp auth instead of: 'make extract, now copy qmail-smtpd.c into the work folder... etc ' Note: The qmail auth patch is not mine, but nihm's. I was planing to write a small qmail virus check 'how-to', too but my english is not native. :-| Miro -------- -Maniac in the field of Quantum Electronics! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Sep 17 14: 0:20 2002 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 41FBD37B444 for ; Tue, 17 Sep 2002 14:00:18 -0700 (PDT) Received: from alcanet.com.au (mail3.alcanet.com.au [208.178.117.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE7FB43E86 for ; Tue, 17 Sep 2002 14:00:16 -0700 (PDT) (envelope-from peter.jeremy@alcatel.com.au) Received: from sydsmtp01.alcatel.com.au (IDENT:root@localhost.localdomain [127.0.0.1]) by alcanet.com.au (8.12.4/8.12.4/Alcanet1.3) with ESMTP id g8HL07RS022484; Wed, 18 Sep 2002 07:00:08 +1000 Received: from gsmx07.alcatel.com.au ([139.188.20.247]) by sydsmtp01.alcatel.com.au (Lotus Domino Release 5.0.10) with ESMTP id 2002091807000689:62777 ; Wed, 18 Sep 2002 07:00:06 +1000 Received: from gsmx07.alcatel.com.au (localhost [127.0.0.1]) by gsmx07.alcatel.com.au (8.12.5/8.12.5) with ESMTP id g8HL062t020528; Wed, 18 Sep 2002 07:00:06 +1000 (EST) (envelope-from peter.jeremy@alcatel.com.au) Received: (from jeremyp@localhost) by gsmx07.alcatel.com.au (8.12.5/8.12.5/Submit) id g8HL05rT020527; Wed, 18 Sep 2002 07:00:05 +1000 (EST) (envelope-from peter.jeremy@alcatel.com.au) Date: Wed, 18 Sep 2002 07:00:04 +1000 From: Peter Jeremy To: dfolkins Cc: freebsd-security@FreeBSD.ORG Subject: Re: Unexpected keep state behaviour in ipfw Message-ID: <20020917210004.GW495@gsmx07.alcatel.com.au> Mail-Followup-To: dfolkins , freebsd-security@FreeBSD.ORG References: <20020915224154.GD495@gsmx07.alcatel.com.au> <001a01c25e17$39edcde0$0a00a8c0@groovy3xp> Mime-Version: 1.0 In-Reply-To: <001a01c25e17$39edcde0$0a00a8c0@groovy3xp> User-Agent: Mutt/1.4i X-MIMETrack: Itemize by SMTP Server on SYDSMTP01/AlcatelAustralia(Release 5.0.10 |March 22, 2002) at 18/09/2002 07:00:06 AM, Serialize by Router on SYDSMTP01/AlcatelAustralia(Release 5.0.10 |March 22, 2002) at 18/09/2002 07:00:08 AM, Serialize complete at 18/09/2002 07:00:08 AM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 2002-Sep-17 02:55:36 -0400, dfolkins wrote: >first, your "idle time" for standard tcp connections is controlled by a >sysctl variable named net.inet.ip.fw.dyn_ack_lifetime. if it is set too >short (default is 300 seconds, i think) you can always just reset it to a >longer value, either from command prompt or from sysctl.conf. just set it >to a number you think appropriate for idle established connections to >remain >active. e.g. if you want your idle ftp connections to stay alive for 10 >minutes, set that variable to 600. there are a bunch of related variables. >to see them all just do a "sysctl -a |grep dyn". net.inet.ip.fw.dyn_ack_lifetime is a tradeoff between keeping active connections alive and minimising the impact of massive numbers of dynamic rules. I also feel that 300 seconds is too short (note that IPFilter uses 120 hours, which I think is far too long). My problem is that the connections are being dropped after less than net.inet.ip.fw.dyn_ack_lifetime seconds of idle time. I have tried juggling net.inet.tcp.keepidle, net.inet.tcp.keepintvl and net.inet.ip.fw.dyn_ack_lifetime so that the latter is longer than the former (in ipfw) and this still didn't work. It would appear that the dynamic rule timers are never being reset. >as to why your ssh connection stays alive even through the night - i >suspect that is because your ssh server on your firewall has a >configuration setting that makes it send keep-alives, i.e. your >clientaliveinterval in sshd_config is set to some value which is less >than your net.inet.ip.fw.dyn_ack_lifetime value. Nope. I'm using the default ClientAliveInterval value (ie disabled). Based on comments in another thread here, I suspect the underlying problem is that ipfw dynamic rules don't work with ipnat. (Though I don't understand why - ipnat should be invisible to ipfw). My ssh connectins remain working courtesy of either normal or ipfw2 keepalives (since that connection isn't NAT'd). Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Sep 17 22:51: 3 2002 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 DF0D737B401 for ; Tue, 17 Sep 2002 22:51:00 -0700 (PDT) Received: from smtp.comcast.net (smtp.comcast.net [24.153.64.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 584A243E77 for ; Tue, 17 Sep 2002 22:51:00 -0700 (PDT) (envelope-from dfolkins@comcast.net) Disposition-notification-to: dfolkins@comcast.net Received: from groovy3xp (pcp01731796pcs.selrsv01.pa.comcast.net [68.83.131.193]) by mtaout02.icomcast.net (iPlanet Messaging Server 5.1 HotFix 1.4 (built Aug 5 2002)) with SMTP id <0H2M0032T7W9GA@mtaout02.icomcast.net> for freebsd-security@FreeBSD.ORG; Tue, 17 Sep 2002 23:48:09 -0400 (EDT) Date: Tue, 17 Sep 2002 23:48:01 -0400 From: dfolkins Subject: Re: Unexpected keep state behaviour in ipfw To: freebsd-security@FreeBSD.ORG Message-id: <001601c25ec6$2fd4dc90$0a00a8c0@groovy3xp> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20020915224154.GD495@gsmx07.alcatel.com.au> <001a01c25e17$39edcde0$0a00a8c0@groovy3xp> <20020917210004.GW495@gsmx07.alcatel.com.au> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > net.inet.ip.fw.dyn_ack_lifetime is a tradeoff between keeping active > connections alive and minimising the impact of massive numbers of > dynamic rules. I also feel that 300 seconds is too short (note that > IPFilter uses 120 hours, which I think is far too long). My problem > is that the connections are being dropped after less than > net.inet.ip.fw.dyn_ack_lifetime seconds of idle time. I have tried > juggling net.inet.tcp.keepidle, net.inet.tcp.keepintvl and > net.inet.ip.fw.dyn_ack_lifetime so that the latter is longer than > the former (in ipfw) and this still didn't work. It would appear > that the dynamic rule timers are never being reset. > > >as to why your ssh connection stays alive even through the night - i > >suspect that is because your ssh server on your firewall has a > >configuration setting that makes it send keep-alives, i.e. your > >clientaliveinterval in sshd_config is set to some value which is less > >than your net.inet.ip.fw.dyn_ack_lifetime value. > > Nope. I'm using the default ClientAliveInterval value (ie disabled). > > Based on comments in another thread here, I suspect the underlying > problem is that ipfw dynamic rules don't work with ipnat. (Though > I don't understand why - ipnat should be invisible to ipfw). My > ssh connectins remain working courtesy of either normal or ipfw2 > keepalives (since that connection isn't NAT'd). > well, given this description, i guess maybe you are right, and its having problems with ipnat. i had some problems with natd/ipfw myself (cf recent thread in -security), so its possible ipfw doesnt behave well with ipnat either. maybe the solution is to switch to ipfilter after all... sorry i couldnt be more helpful. -- dfolkins To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Sep 18 13:13:42 2002 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 26D4637B401 for ; Wed, 18 Sep 2002 13:13:37 -0700 (PDT) Received: from web10101.mail.yahoo.com (web10101.mail.yahoo.com [216.136.130.51]) by mx1.FreeBSD.org (Postfix) with SMTP id 9F85443E42 for ; Wed, 18 Sep 2002 13:13:36 -0700 (PDT) (envelope-from twigles@yahoo.com) Message-ID: <20020918201336.17551.qmail@web10101.mail.yahoo.com> Received: from [68.5.49.41] by web10101.mail.yahoo.com via HTTP; Wed, 18 Sep 2002 13:13:36 PDT Date: Wed, 18 Sep 2002 13:13:36 -0700 (PDT) From: twig les Subject: Re: Password Security Policy Question To: Crispin Cowan , Nate Lawson Cc: freebsd-security@FreeBSD.ORG In-Reply-To: <3D87C2B5.9000305@wirex.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org While we're on the subject of passwords, I'm considering setting up a semi-dedicated box to do some password cracking at work. Is there a good paper on how to set up some good libraries? I have john the ripper running right now but the default ability to crack passwds isn't very good (I threw it some obvious ones...didn't get them). Also, is there anything involved in this process aside from raw CPU time? For the next time I get to build a box, it'd be good to know. --- Crispin Cowan wrote: > Nate Lawson wrote: > > > At 11:36 AM 9/10/2002 -0500, L. Adrian Griffis > wrote: > > > I am aware of a company that has instituted a > policy that limits a > > > specific character in people's passwords to > being a numeric character. > > This policy, as described, does seem to be a very > bad idea. I can't tell > whether it is because the policy has not been > faithfully described. > > > This is a bad idea. Ross Anderson's group did a > good study on different > > password selection approaches: > > http://www.cl.cam.ac.uk/ftp/users/rja14/tr500.pdf > > Interesting paper. Good to see some solid empirical > study in this > critical area. Some commentary on the conclusions: > > 1. The first folk belief is that users have > difficulty remembering > random passwords. This belief is confirmed. > 2. The second folk belief is that passwords based > on mnemonic phrases > are harder for an attacker to guess than > naively selected > passwords. This belief is confirmed. > 3. The third folk belief is that random passwords > are better than > those based on mnemonic phrases. However, each > appeared to be just > as strong as the other. So this belief is > debunked. > 4. The fourth folk belief is that passwords based > on mnemonic phrases > are harder to remember than naively selected > passwords. However, > each ap- peared to be just as easy to remember > as the other. So > this belief is de- bunked. > 5. The fifth folk belief is that by educating > users to use random > passwords or mnemonic passwords, we can gain a > significant > improvement in security. However, both random > passwords and > mnemonic passwords su ered from a > non-compliance rate of about 10% > (including both too-short passwords and > passwords not chosen > according to the instructions). While this is > better than the 35% > or so of users who choose bad passwords with > only cursory > instruction, it is not really a huge > improvement. The attacker may > have to work three times harder, but in the > absence of password > policy enforcement mechanisms there seems no > way to make the > attacker work a thousand times harder. In > fact, our experimental > group may be about the most compliant a > systems administrator can > expect to get. So this belief appears to be > de- bunked. > > I like most of these conclusions. Confirming most of > the common folk > beliefs is good. #5 is particularly significant: > password policy > enforcement is critical. > > The only one I have trouble with is #3: the study > found passphrase > passwords to be just as strong as random pass > phrases. I submit that > this conclusion is primarily a function of the > strength of the cracking > software employed, and will change. It is unclear > whether the study used > a standard password cracker (Crack, John the Ripper, > etc.) or rolled > their own. But in any case, if we convince all users > to use pass > phrases, then crack software will evolve to attempt > to crack pass > phrases. How hard would it be to encode the first > letter of the popular > quotations from Bartlett's Quotations into a crack > dictionary? > > Disclaimer: none the less, I believe that pass > phrases is the most > cost-effective form of password discipline. Random > is just too hard for > most humans to remember. > > Crispin > > -- > Crispin Cowan, Ph.D. > Chief Scientist, WireX > http://wirex.com/~crispin/ > Security Hardened Linux Distribution: > http://immunix.org > Available for purchase: > http://wirex.com/Products/Immunix/purchase.html > > > ATTACHMENT part 2 application/pgp-signature ===== ----------------------------------------------------------- Heavy metal made me do it. ----------------------------------------------------------- __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Sep 18 13:56:45 2002 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 C7AEA37B404 for ; Wed, 18 Sep 2002 13:56:40 -0700 (PDT) Received: from finland.ispro.net.tr (finland.ispro.net.tr [217.21.68.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 616D643E72 for ; Wed, 18 Sep 2002 13:56:37 -0700 (PDT) (envelope-from yurtesen@ispro.net.tr) Received: from finland.ispro.net.tr (localhost [127.0.0.1]) by finland.ispro.net.tr (8.12.6/8.12.5) with ESMTP id g8IKuFhI029693; Wed, 18 Sep 2002 23:56:15 +0300 (EEST) (envelope-from yurtesen@ispro.net.tr) Received: from localhost (yurtesen@localhost) by finland.ispro.net.tr (8.12.6/8.12.6/Submit) with ESMTP id g8IKuDni029688; Wed, 18 Sep 2002 23:56:14 +0300 (EEST) X-Authentication-Warning: finland.ispro.net.tr: yurtesen owned process doing -bs Date: Wed, 18 Sep 2002 23:56:13 +0300 (EEST) From: Evren Yurtesen To: twig les Cc: Crispin Cowan , Nate Lawson , Subject: Re: Password Security Policy Question In-Reply-To: <20020918201336.17551.qmail@web10101.mail.yahoo.com> Message-ID: <20020918235353.O28015-100000@finland.ispro.net.tr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org you can always set the priority of the process to use more cpu time or less. there is this slurpie port in freebsd ports but obviously it doesnt work I just got segmentation faults on freebsd and linux. and the slurp daemon was conecting to wrong port. if it works its supposed to do distributed password cracking. also on the web I have found medussa program but it wasnt compiling even, complaining about pthread library. if you can get any of these programs to work please let me know =) Evren On Wed, 18 Sep 2002, twig les wrote: > While we're on the subject of passwords, I'm > considering setting up a semi-dedicated box to do some > password cracking at work. Is there a good paper on > how to set up some good libraries? I have john the > ripper running right now but the default ability to > crack passwds isn't very good (I threw it some obvious > ones...didn't get them). > > Also, is there anything involved in this process aside > from raw CPU time? For the next time I get to build a > box, it'd be good to know. > > > --- Crispin Cowan wrote: > > Nate Lawson wrote: > > > > > At 11:36 AM 9/10/2002 -0500, L. Adrian Griffis > > wrote: > > > > I am aware of a company that has instituted a > > policy that limits a > > > > specific character in people's passwords to > > being a numeric character. > > > > This policy, as described, does seem to be a very > > bad idea. I can't tell > > whether it is because the policy has not been > > faithfully described. > > > > > This is a bad idea. Ross Anderson's group did a > > good study on different > > > password selection approaches: > > > http://www.cl.cam.ac.uk/ftp/users/rja14/tr500.pdf > > > > Interesting paper. Good to see some solid empirical > > study in this > > critical area. Some commentary on the conclusions: > > > > 1. The first folk belief is that users have > > difficulty remembering > > random passwords. This belief is confirmed. > > 2. The second folk belief is that passwords based > > on mnemonic phrases > > are harder for an attacker to guess than > > naively selected > > passwords. This belief is confirmed. > > 3. The third folk belief is that random passwords > > are better than > > those based on mnemonic phrases. However, each > > appeared to be just > > as strong as the other. So this belief is > > debunked. > > 4. The fourth folk belief is that passwords based > > on mnemonic phrases > > are harder to remember than naively selected > > passwords. However, > > each ap- peared to be just as easy to remember > > as the other. So > > this belief is de- bunked. > > 5. The fifth folk belief is that by educating > > users to use random > > passwords or mnemonic passwords, we can gain a > > significant > > improvement in security. However, both random > > passwords and > > mnemonic passwords su ered from a > > non-compliance rate of about 10% > > (including both too-short passwords and > > passwords not chosen > > according to the instructions). While this is > > better than the 35% > > or so of users who choose bad passwords with > > only cursory > > instruction, it is not really a huge > > improvement. The attacker may > > have to work three times harder, but in the > > absence of password > > policy enforcement mechanisms there seems no > > way to make the > > attacker work a thousand times harder. In > > fact, our experimental > > group may be about the most compliant a > > systems administrator can > > expect to get. So this belief appears to be > > de- bunked. > > > > I like most of these conclusions. Confirming most of > > the common folk > > beliefs is good. #5 is particularly significant: > > password policy > > enforcement is critical. > > > > The only one I have trouble with is #3: the study > > found passphrase > > passwords to be just as strong as random pass > > phrases. I submit that > > this conclusion is primarily a function of the > > strength of the cracking > > software employed, and will change. It is unclear > > whether the study used > > a standard password cracker (Crack, John the Ripper, > > etc.) or rolled > > their own. But in any case, if we convince all users > > to use pass > > phrases, then crack software will evolve to attempt > > to crack pass > > phrases. How hard would it be to encode the first > > letter of the popular > > quotations from Bartlett's Quotations into a crack > > dictionary? > > > > Disclaimer: none the less, I believe that pass > > phrases is the most > > cost-effective form of password discipline. Random > > is just too hard for > > most humans to remember. > > > > Crispin > > > > -- > > Crispin Cowan, Ph.D. > > Chief Scientist, WireX > > http://wirex.com/~crispin/ > > Security Hardened Linux Distribution: > > http://immunix.org > > Available for purchase: > > http://wirex.com/Products/Immunix/purchase.html > > > > > > > ATTACHMENT part 2 application/pgp-signature > > > > ===== > ----------------------------------------------------------- > Heavy metal made me do it. > ----------------------------------------------------------- > > __________________________________________________ > Do You Yahoo!? > Yahoo! Health - Feel better, live better > http://health.yahoo.com > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Sep 18 16:49:45 2002 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 432C037B401 for ; Wed, 18 Sep 2002 16:49:43 -0700 (PDT) Received: from walter.dfmm.org (walter.dfmm.org [209.151.233.240]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA4FC43E75 for ; Wed, 18 Sep 2002 16:49:42 -0700 (PDT) (envelope-from jason@shalott.net) Received: (qmail 3356 invoked by uid 1000); 18 Sep 2002 23:49:37 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 18 Sep 2002 23:49:37 -0000 Date: Wed, 18 Sep 2002 16:49:37 -0700 (PDT) From: Jason Stone X-X-Sender: To: Subject: Re: Password Security Policy Question In-Reply-To: <20020918201336.17551.qmail@web10101.mail.yahoo.com> Message-ID: <20020918162641.P76675-100000@walter> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > While we're on the subject of passwords, I'm considering setting up a > semi-dedicated box to do some password cracking at work. Is there a > good paper on how to set up some good libraries? I have john the > ripper running right now but the default ability to crack passwds > isn't very good (I threw it some obvious ones...didn't get them). > > Also, is there anything involved in this process aside from raw CPU > time? For the next time I get to build a box, it'd be good to know. If you're just brute forcing sequentially or randomly, then no, it's all about the CPU. Usually, though, it's possible to be a little bit smarter by using dictionaries. I've used crack for this in the past - you feed it one or more big dictionaries, and it applies a bunch of mangling rules to each dictionary entry to generate a really big list which it then tries against the password file. It allows you to supply your own sets of mangling rules and supports weighted spreading of the work across multiple hosts if you have ssh access to all of them (and preferably nfs, though it's not necesary). It's in ports/security/crack if you want to have a go, but be aware of any corporate or university policies that may affect you as well as the legal ramifications of running a program like this. More than one well meaning sysadmin has been sacked, fined, sued or worse just for running crack.... -Jason ----------------------------------------------------------------------- I worry about my child and the Internet all the time, even though she's too young to have logged on yet. Here's what I worry about. I worry that 10 or 15 years from now, she will come to me and say "Daddy, where were you when they took freedom of the press away from the Internet?" -- Mike Godwin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: See https://private.idealab.com/public/jason/jason.gpg iD8DBQE9iRERswXMWWtptckRAkl7AJ48s6BIS0dEp45rJalVgvlnRKIxzACfZ75G 0P8Fxk95GTbFwkQvcrXQxBA= =Knre -----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 Thu Sep 19 17:50:33 2002 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 3513E37B401; Thu, 19 Sep 2002 17:50:31 -0700 (PDT) Received: from wso-h001.wsonline.net (12-254-8-189.client.attbi.com [12.254.8.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 913F743E4A; Thu, 19 Sep 2002 17:50:30 -0700 (PDT) (envelope-from seahorse51@attbi.com) Received: from seahorse.attbi.com (trilluser@seahorse [192.168.1.101]) by wso-h001.wsonline.net (8.12.5/8.12.5) with ESMTP id g8K0oS55003159; Thu, 19 Sep 2002 18:50:29 -0600 (MDT) (envelope-from seahorse51@attbi.com) Message-Id: <5.1.1.6.0.20020919154959.02f7b008@mail.seahorse.wsonline.net> X-Sender: seahorse@mail.seahorse.wsonline.net X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 19 Sep 2002 16:00:58 -0600 To: freebsd-questions@freebsd.org, freebsd-security@freebsd.org From: Andy Subject: options SUIDDIR Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I have been researching the use of "options SUDIDIR" in the kernel. I have noted several warnings about the use of this option being a security issue, but I have as of yet to read or see any explanation as to what kind of security issue its use represents. Any assistance in an explanation concerning this would be very much appreciated. Andy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Sep 20 15:51:45 2002 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 11B0537B401; Fri, 20 Sep 2002 15:51:43 -0700 (PDT) Received: from wso-h001.wsonline.net (12-254-8-189.client.attbi.com [12.254.8.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F71C43E42; Fri, 20 Sep 2002 15:51:42 -0700 (PDT) (envelope-from seahorse51@attbi.com) Received: from seahorse.attbi.com (trilluser@seahorse [192.168.1.101]) by wso-h001.wsonline.net (8.12.5/8.12.5) with ESMTP id g8KMpepI002906; Fri, 20 Sep 2002 16:51:41 -0600 (MDT) (envelope-from seahorse51@attbi.com) Message-Id: <5.1.1.6.0.20020920164541.03859bb8@mail.seahorse.wsonline.net> X-Sender: seahorse@mail.seahorse.wsonline.net X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Fri, 20 Sep 2002 16:51:39 -0600 To: "Jack L. Stone" , freebsd-questions@FreeBSD.ORG, freebsd-security@FreeBSD.ORG From: Andy Subject: Re: options SUIDDIR In-Reply-To: <3.0.5.32.20020920173328.00e8d428@mail.sage-one.net> References: <5.1.1.6.0.20020919154959.02f7b008@mail.seahorse.wsonline.n et> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org At 16:33 09/20/2002, Jack L. Stone wrote: >At 04:00 PM 9.19.2002 -0600, Andy wrote: > >I have been researching the use of "options SUDIDIR" in the kernel. I have > >noted several warnings about the use of this option being a security issue, > >but I have as of yet to read or see any explanation as to what kind of > >security issue its use represents. > > > >Any assistance in an explanation concerning this would be very much > >appreciated. > > > >Andy > > > > > >I have this in my kernel from when I used the base system FTP server, but >since swithing to ProFTP, I have not seen a use for it and was planning to >remove on next compile of the kernel..... > >What uses do you have in mind. Maybe I'll leave it in if really useful for >some other app. > >Best regards, >Jack L. Stone, >Administrator I would like to be able to use it to ensure that file ownerships are correct in user home directories. Most files that are created via scripts and the web server take on the ownership of whatever the Web server is being run as. This makes it difficult for someone to remove them if they so desire. The only warnings I have seen indicate that it is a security risk in the event, that shell access is permitted on servers that use the SUIDDIR option. I have not as of yet been able to discover what kind of security risk this represents and/or how it can be exploited. As with anything, one can not make an educated decision without having all of the facts or details concerning the issue in question. Andy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message